[번역] 리눅스 커널 튜닝 – swappiness and overcommit_memory

이 문서는 다음 주소의 내용을 발 번역한 것입니다.

• http://tonylixu.blogspot.kr/2014/01/linux-kernel-tuning-swappiness-and.html

리눅스 커널 튜닝 – swappiness and overcommit_memory

리눅스 커널  튜닝가능한 파라메터 vm.swappiness (/proc/sys/vm/swappiness) 는 어떻게 메모리 페이지들이(memory pages) 적극적으로 디스크에 스왑(swap)되어질 수 있는지를 정의하는데 사용되어질 수 있습니다. 리눅스는 활용할 수 있는 free 메모리양이 충분하더라도 오랫동안 메모리 페이지에 접근하지 않는 것들을 스왑 공간으로 이동시킵니다. 이러한  동작은 “swappiness” 커널 파라메터 값을 /proc/sys/vm/swappiness 에서 변경할 수 있습니다.

높은 swappiness 값은 커널은 매핑된 페이지를 좀 더 해제하라는 의미 입니다. 낮은 swappiness 값은 반대의 의미로 커널은 매핑된 페이지를 덜 해제하도록 하라는 의미 입니다. 바꿔말해서, vm.swappiness 값이 높을 수록 시스템은 좀 더 많이 스왑을 할 것입니다.

vm.swappiness 는 스와핑 활동과 freeing 캐쉬사이의 균형을 바꾸기 위해서 0 에서 100 사이의 값을 가집니다. 100 은 커널이 항상 비활성 페이지를 찾게되고 그것들을 스왑 합니다. 다른 말로, 스왑의 발생은 애플리케이션이 메모리를 얼마나 많이 사용하는지, 어떻게 부족한 캐쉬가 찾기 활동을하고  비활성 아이템을 릴리즈하는가에 의존합니다.

일반적으로 프로세스들은 함수 malloc() 를 호출함으로서 메모리를 할당 합니다. 커널은 충분한 메모리가 활용가능한지 판단하고 할당요청을 허용하거나 거부할지를 결정합니다. 리눅스는 메모리 오버커밋(overcommit memory) 할 수 있는 기능을 지원 합니다. 그것은 물리적 램과 스왑을 합쳐 더 많은 메모리를 할당되어질 수 있도록 허용하는 것 입니다. 이것은 무섭지만, 때때로 애플리케이션이 최악의 케이스 시나리오로 메모리를 할당하는 경우에 필요하지만 절대로 이러한 케이스를 사용해서는 안됩니다. (애플리케이션이 메모리를 많이 잡아먹도록 만들지 말라는 이야기 입니다.)

vm.overcommit_memory 는 3가지 가능한 세팅 값이 있습니다.

• 0 (heuristic overcommit) : 충분한 메모리가 활용가능하지 체크하고, 만약 그렇다면, 할당을 허용한다. 만약 메모리가 충분하지 않다면, 요청을 거부하거나 애플리케이션에 에러를 리턴한다.
• 1 (always overcommit) :  커널은 “모든 돈을 걸어라”는 것과 같다. 1로 세팅하는 것은 커널에게 애플리케이션의 메모리에 대한 요청을 항상 성공으로 리턴하라고 명령하는 것이다. 이것은 듣기에따라서 섬뜩하고 무서운 것이다.
• 2 (strict covercommit) : 메모리에 물리적 메모리와 스왑을 합쳐 초과 할당을 vm.overcommit_ratio 에 정의되어진 것만큼 할당하도록 허용하라. vm.overcommit_ratio 파라메터는 비율로서 얼마나 커널이 오버커밋을 할 수 있는지를 결정할때에 추가할 메모리의 양이다. 예를들어, vm.overcommit_ratio 가 50 이고 1GB 의 램을 가지고 있따면 커널은 요청이 실페하기전에 0.5GB 의 물리메모리와 스왑을 더해서 할당되어질 수 있도록 허용하게 된다. 결국 물리메모리를 낭비하게 된다.

프로세스가 포크(fork)될때나 fork()함수를 호출할때, 이것은 전체 페이지 테이블(page table)이 복제된다. 다른 말로하면, 작식 프로세스는 완벽하게 부모의 메모리공간의 복사본을 가진다는 것이며 이는 당신이 예상한대로 두배의 메모리양을 필요로한다. (부모 메모리, 자식 메모리) 만약 그 자식들의 의도가 즉각적으로 exec()를 호출하는 것이라면( 하나의 프로세스가 다른것으로 교체되는) 부모의 메모리를 복제하는 활동은 시간을 낭비한다. 왜냐하면 이러한 패턴은 아주 일반적인것으로, fork()와 달리 vfork()로 생성은 부모 메모리를 복제하지 않으며 대신에 자식 프로세스가 exec() 를 호출하거나 사라질때까지 그것을 블럭킹한다.  The problem is that the HotSpot JVM developers implemented Java’s fork operation using fork() rather than vfork()

영구적으로 바꾸기.