it-swarm-ko.tech

RAM에 충분한 여유 공간이있을 때 스왑을 사용하는 이유는 무엇입니까?

RAM 대신 swap 공간을 사용하면 대폭 느려질 수 있음 PC가됩니다.

그렇다면 왜 충분한 RAM 이상) Linux 시스템 (아치)이 스왑을 사용합니까?

아래의 conky 출력을 확인하십시오.

conky output

또한 이것이 속도 및 시스템 응답 문제의 원인 일 수 있습니까?

free -m 출력 :

$ free -m
             total       used       free     shared    buffers     cached
Mem:          1257       1004        252          0         51        778
-/+ buffers/cache:        174       1082
Swap:          502        144        357
132
Stefan

Linux 시스템이 여전히 RAM free) 있어도 some 스왑을 사용하는 것이 일반적입니다. Linux 커널은 거의 사용되지 않는 스왑 메모리 페이지로 이동합니다 (예 : , X11 만 사용하는 경우 getty 인스턴스 및 일부 다른 비활성 데몬).

스왑 공간 사용이 문제가됩니다 RAM available,가 충분하지 않고 커널이 메모리 페이지를 계속해서 스왑 및 RAM으로 다시 이동하도록 강제 설정 한 경우에만) 이 경우 시스템 모니터 응용 프로그램에는 많은 디스크 I/O 작업이 표시됩니다.

비교를 위해, 그놈 데스크탑을 실행하는 X11 세션으로 로그인 한 두 명의 사용자가있는 Ubuntu 10.04 시스템은 ~ 600MB의 스왑과 ~ 1GB의 RAM (버퍼 및 fs 캐시는 계산하지 않음)을 사용하므로 스왑 사용에 대한 귀하의 수치가 정상적으로 보인다고 말하고 싶습니다.

96
Riccardo Murri

이 동작은 다음 값을 설정하여 구성 할 수 있습니다.

/proc/sys/vm/swappiness

기본값은 60입니다. 0으로 설정하면 여전히 RAM이 남아 있고 100이 가능한 빨리 메모리를 스왑 아웃 할 때 스왑을 사용하지 않음을 의미합니다.

값을 일시적으로 변경하려면 (재부트시 손실) :

Sudo sysctl vm.swappiness=10

값을 영구적으로 변경하려면 파일을 편집하십시오.

/etc/sysctl.conf

루트로 (예 : Sudo nano /etc/sysctl.conf)하고 행을 변경하거나 추가하십시오 (없는 경우).

vm.swappiness

원하는 값으로. 이 파일이 없으면 (예 : Arch Linux에) /etc/sysctl.d/99-sysctl.conf 대신에.

사용 가능한 여유 메모리로 교체하는 것이 좋은지 나쁜지에 대한 논쟁이 있었지만 우분투 도움말은 실제로 데스크탑 시스템의 경우 10을 권장합니다 . CentOS 용 Digital Ocean에 대한이 자습서 도 참조하십시오.

96
Marcel Stimberg

RAM이 채워지기 전에 Linux가 스와핑을 시작합니다. 성능과 응답 성을 향상시키기 위해 수행됩니다.

  • 때때로 RAM가 프로그램 메모리를 저장하는 것보다 디스크 캐시에 더 잘 사용되기 때문에 성능이 향상됩니다. 은닉처.

  • 메모리가 가득 차고 일부 프로그램이 실행 중일 때 작업을 완료하기 위해 더 많은 RAM을 요청하는 경우가 아니라 시스템이 유휴 상태 일 때 페이지를 스왑 아웃함으로써 응답 성이 향상됩니다.

스와핑은 물론 시스템 속도를 늦추지 만 스와핑의 대안은 스와핑이 아니라 더 많은 RAM 또는 더 적은 RAM 사용)입니다.

이것은 오래된 게시물이지만 여전히 여기에 내 생각을 자유롭게 할 수 있습니다.

아래에서 시작하여 Linux는 먼저 메모리를 페이지 (일반적으로 x86_64 시스템의 페이지 당 4K)로 나눕니다. 그 후, MMU (메모리 관리 장치)를 사용하여 물리적 메모리로 매핑이 수행되는 가상 메모리가 생성됩니다.

프로세스에는 가상 메모리 영역에서 메모리가 할당되므로/proc/meminfo가 표시되면 VMalloc *가 가상 메모리 세부 정보로 표시됩니다.

메모리를 요청하는 프로세스 (예 : 300MB-웹 브라우저)가 있다고 가정 해 봅시다. 프로세스는 가상 메모리에서 300MB로 할당되지만 메모리 매핑 (실제 메모리에 매핑) 일 필요는 없습니다. 메모리 관리를위한 "Copy on Write"개념이 있는데, 프로세스가 실제로 가상 메모리에서 할당 된 메모리를 사용하는 경우 (즉, 메모리에서 일부 쓰기를 수행하는 경우) 물리적 메모리에만 매핑됩니다. 이를 통해 커널이 다중 프로세스 환경에서 효율적으로 올바르게 작동 할 수 있습니다.

캐시 란 무엇입니까?

프로세스가 사용하는 많은 메모리가 공유됩니다. glibc 라이브러리는 거의 모든 프로세스에서 사용됩니다. 모든 프로세스가 동일한 메모리 위치에 액세스하여 작업을 수행 할 수있을 때 glibc의 여러 복사본을 메모리에 보관하는 시점은 무엇입니까? 이와 같이 자주 사용되는 리소스는 캐시에 보관되므로 프로세스 요구시 동일한 메모리 위치를 참조 할 수 있습니다. 디스크에서 glibc 등을 다시 읽고 읽는 데 시간이 오래 걸리므로 프로세스 속도를 높이는 데 도움이됩니다.

위의 내용은 공유 라이브러리에 대한 것이며 파일 읽기와 유사합니다. 큰 파일 (100-200MB)을 처음 읽으면 시간이 많이 걸립니다. 그러나 동일한 읽기를 다시 시도하면 더 빠릅니다. 데이터가 메모리에 캐시되었으며 모든 블록에 대해 다시 읽기가 수행되지 않았습니다.

버퍼 란?

버퍼와 관련하여 프로세스가 파일 I/O를 수행 할 때 디스크의 데이터를 쓰기 위해 커널 버퍼에 의존합니다. 프로세스는 커널에게 작업을 수행하도록 요청합니다. 따라서 프로세스를 대신하여 커널은 데이터를 "버퍼"에 기록하고 프로세스에 쓰기가 완료되었음을 알립니다. 비동기 방식으로 커널은 버퍼의이 데이터를 디스크와 계속 동기화합니다. 이런 식으로 프로세스는 커널에 의존하여 데이터를 디스크에 동기화 할 정확한 시간을 선택하고 프로세스는 계속 진행될 수 있습니다. 이것은 일반적인 프로세스가 수행하는 일반적인 I/O입니다. 그러나 실제로 디스크에서 I/O가 수행되는지 확인해야하는 특수 프로세스는 다른 메커니즘을 사용하여 디스크에서 I/O를 수행 할 수 있습니다. 오픈 소스 유틸리티 중 일부는 libaio입니다. 또한 프로세스 컨텍스트에서 열린 FD에 대한 명시 적 동기화를 호출하여 커널이 데이터 쓰기를 위해 디스크에 데이터를 동기화하도록 강제 할 수 있습니다.

다음 페이지 결함은 무엇입니까?

바이너리가 약 300MB 인 프로세스 (예 : 웹 브라우저)를 시작할 때의 예를 고려하십시오. 그러나 전체 300MB의 웹 브라우저 바이너리가 즉시 작동하지 않습니다. 프로세스는 코드에서 함수 간 이동을 계속합니다. 앞에서 언급했듯이 가상 메모리는 300MB를 소비하지만 모든 메모리가 실제 메모리에 매핑되는 것은 아닙니다 (RSS-상주 메모리가 적을 수 있습니다. 상단 출력 참조). 메모리가 실제로 물리적으로 매핑되지 않은 지점에 코드 실행이 도달하면 페이지 오류가 발생합니다. 커널은이 메모리를 물리적으로 매핑하고 메모리 페이지를 프로세스에 연결합니다. 이러한 페이지 오류를 "사소한 페이지 오류"라고합니다. 마찬가지로 프로세스가 파일 I/O를 수행 할 때 주요 페이지 결함이 발생합니다.

스왑 아웃은 언제 그리고 왜 발생합니까?

상황 1 :

위의 세부 사항과 함께, 많은 양의 메모리가 메모리 매핑되는 시나리오를 고려하십시오. 이제 메모리가 필요한 프로세스가 시작됩니다. 위에서 논의한 바와 같이, 커널은 일부 메모리 매핑을 수행 할 것입니다. 그러나 메모리를 매핑 할 수있는 물리적 RAM)가 충분하지 않습니다. 이제 커널은 먼저 캐시를 살펴보고 사용하지 않는 오래된 메모리 페이지를 갖게됩니다. 디스크 쓰기가 솔리드 스테이트 RAM보다 훨씬 느리기 때문에이 프로세스에는 많은 시간이 걸리므로 속도가 느려집니다. 보인다.

상황 2 :

시스템에서 사용 가능한 많은 여유 메모리를 볼 수 있다고 가정합니다. 그럼에도 불구하고 많은 스왑 아웃이 발생하고 있음을 알 수 있습니다. 메모리 조각화 문제가있을 수 있습니다. 커널에서 50MB의 연속 메모리가 필요한 프로세스를 고려하십시오. (인접을 명심하십시오). 분명히 커널은 다른 프로세스에 무작위로 페이지를 할당하고 그 중 일부를 해제했을 것입니다. 그러나 연속 메모리를 요구할 때는 프로세스 요구를 만족시키는 청크를 찾아야합니다. 그러한 메모리를 확보 할 수없는 경우 일부 오래된 메모리 페이지를 교체 한 다음 연속적인 페이지를 할당해야합니다. 그러한 경우에도 SWAP가 발생합니다. 커널 버전 2.6 이상부터는 이러한 조각화 문제가 상당히 줄었습니다. 그러나 시스템이 오랫동안 실행되는 경우에도 여전히 이러한 문제가 발생할 수 있습니다.

이 예를 참조하십시오 (vmstat output)

2016-10-29 03:55:32 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
2016-10-29 03:55:32  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
2016-10-30 03:56:04 19 23 2914752 4692144 3344908 12162628 1660    1  8803 12701 4336 37487 14  7 40 38  0
2016-10-30 03:56:34  3 20 2889296 4977580 3345316 12026752 2109    2  8445 14665 4656 36294 12  7 46 34  0
2016-10-30 03:57:04  1 11 3418868 4939716 3347804 11536356  586 4744  2547  9535 3086 24450  6  3 59 33  0  <<<-----
2016-10-30 03:57:34  3 19 3456252 5449884 3348400 11489728 3291 13371  6407 17957 2997 22556  6  4 66 24  0
2016-10-30 03:58:04  7  6 4194500 5663580 3349552 10857424 2407 12240  3824 14560 2295 18237  4  2 65 29  0
2016-10-30 03:58:34  2 16 4203036 5986864 3348908 10838492 4601 16639  7219 18808 2575 21563  6  4 60 31  0
2016-10-30 03:59:04  3 14 4205652 6059196 3348760 10821448 6624 1597  9431  4357 1750 20471  6  2 60 31  0
2016-10-30 03:59:34  2 24 4206968 6053160 3348876 10777216 5221 2067 10106  7377 1731 19161  3  3 62 32  0
2016-10-30 04:00:04  0 13 4205172 6005084 3348932 10785896 6236 1609 10330  6264 1739 20348  4  2 67 26  0
2016-10-30 04:00:34  4 11 4206420 5996396 3348976 10770220 6554 1253 10382  4896 1964 42981 10  5 58 27  0
2016-10-30 04:01:04  6  4 4177176 5878852 3348988 10825840 8682  765 10126  2716 1731 32949  8  4 69 19  0

@ 2016-10-30 03:57:04, 여전히 충분한 양의 free RAM 가용하지만 스왑 아웃이 발생했음을 알 수 있습니다. 그러나이 시점에서 프로세스 트리를 확인했습니다. , 우리는 메모리가 많은 메모리를 필요로하는 프로세스가 나오지 않는 것을 보았습니다. -이를 확인하기 위해 트리거하면 출력은 syslogs로 이동합니다.

우리 시스템의 일반적인 시스템의 경우 영역 정보를 비교하면 다음과 같습니다. 캐시/프리/로우 메모리에 대한 그래프도 아래에 언급되어 있습니다.

zone info

swap free low free

정보를 보면 노드 0 및 노드 1 정상에 메모리 조각화가 있음이 분명합니다 (노드는 NUMA 기반 시스템이므로 여러 노드 (시스템의 정보를 확인하려면 numactl 참조)).

메모리 조각화는 사용 가능한 메모리가있는 경우에도 스왑 사용량이 증가 할 수있는 이유입니다.

15
Anugraha Sinha

사용 가능한 메모리가 더 있음

모든 사람들이 말했듯이, 예 스왑은 사용하지 않는 메모리를 제거하는 데 도움이되므로 더 많은 메모리를 사용할 수 있습니다.

최대 절전 모드

그러나 스왑은 hibernating에도 사용할 수 있습니다. 랩톱이 있거나 에너지를 절약하고 컴퓨터를 사용하고 작업을 떠나기 전에 최대 절전 모드로 전환하려는 경우에 유용합니다. 따라서 아침마다 더 빨리 시작할 수 있습니다.

최대 절전 모드 기능을 사용하는 것이 요즘 여전히 스왑의 크기 RAM)를 권장하는 주된 이유 중 하나입니다. 이렇게하면 시스템에서 사용 된 모든 RAM 스왑으로 들어가면 최대 절전 모드로 들어갑니다.

짧은 방문

스왑이 암호화 된 경우가 아니라면 스왑 된 프로세스 데이터는 스왑 후에도 종료 후에도 스왑에서 읽을 수 있습니다.

최대 절전 모드에서 암호화 된 스왑을 사용하면 모든 배포에서 기본적으로 작동하지 않습니다. 다시 시작하기 전에 일정한 암호화 키 (일부 설정에서는 각 부팅시 스왑 공간 암호화 키를 임의로 생성)와 initrd/initramfs를 사용하여 암호화 된 볼륨을 활성화해야합니다.

5
Huygens

buntu Swap F.A.Q. 에서 Marcel이 링크 한

기본적으로 스왑 공간은 실제 메모리 양 (RAM)과 같아야합니다. 또한 스왑 공간은 하드 디스크 양에 따라 실제 메모리 양 (RAM)의 두 배인 것이 좋습니다.

시스템에서 스왑 공간을 늘려야한다고 생각합니다. 스왑은 이미 페이징 된 데이터를 버림으로써 RAM 메모리 할당 속도를 높입니다.

3
Jader Dias

많은 현대적인 프로그램은 프로그램을 실행하기 위해 실제로 필요하지 않은 많은 쓰레기를 끌어들이는 부풀린 프레임 워크를 기반으로합니다. 사용되지 않는 페이지를 바꾸면 실제로 RAM을 사용할 수있는 캐시 및 프로그램에 대해 RAM)이 해제됩니다.

나는 여기에서 고통스러운 개인적인 경험에서 말합니다.

작년에 웹 사이트 중 하나를 Firefox 위에 구축 된 유망한 새 웹 서버 프레임 워크로 전환했습니다. Firefox와 같은 클라이언트 중심의 프로그램 위에 서버 측 시스템을 구축하는 것은 이상하게 들릴지 모르지만 큰 이점이 있습니다. Firefox는 매우 강력하고 매우 인상적인 내부 서비스를 제공하며 서버와 클라이언트 간의 임피던스 불일치를 줄여서 유사한 플랫폼을 실행합니다.

그러나 단점은 파이어 폭스가 크다는 것입니다. 매우 큰. 이것은 버전 1.x 종류의 프로젝트 였으므로 GUI 지원을 제거하는 등의 일에 신경 쓰지 않았습니다. [*] 내 사이트에는 필요가 없었지만 호스팅 제공 업체가 사용한 VPS 기술 때문에 ' 스왑 공간, GUI 코드 및 Firefox의 다른 모든 부분은 실제 RAM을 사용하지 않았습니다. 512MB RAM 최소 메모리 부족으로 인해 사이트가 중단되지 않고 사이트를 실행하기 만하면됩니다. VPS에 스왑 공간이 있으면 아마 256MB 요금제로.

[*] 서버 측 프레임 워크가 다른 사이트에서 웹 페이지를 다운로드하고 사용자가 원하는대로 조작 할 수 있기 때문에이 플랫폼의 장점 중 하나는 충실도 높은 웹 스크래핑 이었기 때문에 프레임 워크에서 GUI 코드를 제거하는 것은 바람직하지 않았을 수도 있습니다. 클라이언트 쪽에서. 매시업을 생각하십시오. 웹 페이지를 일부 그래픽 컨텍스트로 "렌더링"할 수 없으면 많은 종류의 문제가 발생합니다.

그건 그렇고,이 웹 프레임 워크는 본질적으로 죽었으므로 이름을 짓고 감칠 필요가 없습니다. 더 넓은 교훈을 기억하는 것이 가장 좋습니다. 예. 여유 RAM이 많은 경우에도 스왑은 여전히 ​​유용합니다.

3
Warren Young

"Gilles"는 이미 충분한 RAM을 보유하고 있지만 특정 "약점"동안 스왑이 유용 할뿐만 아니라 종료 후에도 일부 데이터를 지속적으로 저장하는 데 유용 할 수 있다는 사실을 이미 언급했다고 생각합니다. RAM 재부팅 후 플러시됩니다) 이후 12GB의 RAM 사용 가능한 시스템에서 사용 가능하며,이 질문에 대해서도 이전에 생각해 보았습니다. 모든 스왑을 비활성화하고 RAM에만 의존 할 때 시스템 종료 후 일부 시스템 오류 또는 충돌 등을 디버깅하는 데 어려움이 있었기 때문에 스왑 파티션을 다시 활성화했습니다.

2
ILMostro_7