@dunxd가 언급 한 문서의 섹션 9.6 "오버 커밋 및 OOM"은 특히 오버 커밋을 허용하는 위험에 대한 그래픽입니다. 그러나 80나에게도 흥미로워 보였으므로 몇 가지 테스트를 수행했습니다.
내가 찾은 것은 overcommit_ratio모든 프로세스에 사용 가능한 총 RAM에 영향을 미친다 는 것입니다 . 루트 프로세스는 일반 사용자 프로세스와 다르게 취급되지 않는 것 같습니다.
비율 100이하로 설정하면 반환 값 malloc/sbrk이 신뢰할 수있는 클래식 시맨틱을 제공해야합니다 . 100캐싱 등과 같은 비 프로세스 활동에 더 많은 RAM을 예약하는 방법 보다 비율을 낮게 설정하십시오 .
그래서, 스왑과 RAM의 24 지브, 내 컴퓨터로, 9 지브 사용에서 사용 안 함 top을 보여주는
Mem: 24683652k total, 9207532k used, 15476120k free, 19668k buffers
Swap: 0k total, 0k used, 0k free, 241804k cached
다음은 overcommit_ratio램 소비 프로그램이 잡을 수있는 RAM 용량과 각 페이지를 터치하는 RAM 양 malloc입니다.
50 ~680 MiB
60 ~2900 MiB
70 ~5200 MiB
100 ~12000 MiB
루트 사용자 인 경우에도 한 번에 여러 개를 실행해도 함께 소비 한 총량은 변경되지 않았습니다. 마지막 3+ GiB 정도를 소비 할 수 없다는 것이 흥미 롭습니다. 이 free많은 여기에 표시된 무슨 이하로 떨어지지 않았다 :
Mem: 24683652k total, 20968212k used, 3715440k free, 20828k buffers
많은 프로그래머가 C에서 malloc 오류를 확인하는 데 끔찍하고 일부 인기있는 콜렉션 라이브러리는 완전히 무시하고 C ++ 및 기타 여러 언어는 보다 나쁜.
내가 본 가상 RAM의 초기 구현의 대부분은 매우 큰 경우를 처리하는 것이 었습니다. 가용 메모리의 51 % +와 같은 하나의 큰 프로세스 fork()가 exec()일부 지원 프로그램 (보통 훨씬 훨씬 작은 프로세스) 을 위해 필요했습니다 . COW (copy-on-write) 시맨틱이있는 OS는을 허용 fork()하지만 포크 프로세스가 실제로 너무 많은 메모리 페이지를 수정하려고 시도한 경우 (각각 초기 초기 프로세스와 독립적 인 새 페이지로 인스턴스화해야 함) 결국 살해 당할 것입니다. 상위 프로세스는 더 많은 메모리를 할당하고 일부 경우 다른 프로세스가 종료 될 때까지 기다렸다가 계속해서 부족을 처리 할 수있는 경우에만 위험에 처했습니다. 자식 프로세스는 일반적으로 다음을 통해 (일반적으로 작은) 프로그램으로 대체되었습니다.exec() 그리고 나서 프로 비소가 없었습니다.
Linux의 오버 커밋 개념은 fork()단일 프로세스를 전체적으로 대량으로 처리 할 수있을뿐만 아니라 발생 을 허용하는 극단적 인 접근 방식 입니다. OOM 킬러로 인한 사망 은 메모리 할당을 책임감있게 처리 하는 프로그램에서도 비동기 적으로 발생 합니다. 나는 개인적으로 시스템 전반의 오버 커밋과 특히 옴 킬러를 개인적으로 싫어 합니다. 라이브러리를 감염시키는 메모리 관리 및 라이브러리를 사용하는 모든 앱을 통해 악마 관리 접근 방식을 장려합니다.
비율을 100으로 설정하고 스왑 파티션을 사용하여 일반적으로 거대한 프로세스에서 사용하게되는 스왑 파티션을 사용하는 것이 좋습니다. 스왑 파티션은 스왑에 들어가는 부분의 작은 부분 만 사용하므로 종종 대부분의 프로세스를 OOM 킬러의 잘못된 기능으로부터 보호하십시오. 이렇게하면 웹 서버가 무작위로 사망 malloc하지 않도록 안전하게 보호해야하며 책임 있게 처리하도록 작성된 경우 자체를 죽이지 않아도 안전합니다 (그러나 후자는 내기하지 마십시오).
이것은 내가 이것을 사용하고 있음을 의미합니다. /etc/sysctl.d/10-no-overcommit.conf
vm.overcommit_memory = 2
vm.overcommit_ratio = 100