버그로 인해 매우 많은 스레드를 생성하고 메모리를 소모하며 스왑 파티션에 대한 과도한 스왑을 유발하는 프로세스에 문제가 있었습니다. 따라서 버그가 있는 프로그램이 조기에 실패할 수 있도록 서버 클러스터에서 권장되는 스왑을 끄었습니다. 놀랍게도 이것은 상황이 전혀 개선되지 않았습니다! 마찬가지로 vm.swappiness0으로 설정해도 도움이 되지 않았습니다. iotop무겁게 드러났다독서디스크에서(쓰기가 거의 없음)
나는 Linux 커널이 여전히 메모리에서 코드 페이지를 교환하고 필요할 때 디스크에서 덮어쓴 코드 페이지를 다시 읽는다고 의심합니다. RAM이 매우 낮으면 이러한 현상이 자주 발생하여 스래싱이 발생하고 컴퓨터가 거의 응답하지 않게 됩니다.
이 불행하고 잠재적으로 위험한 상황을 어떻게 예방할 수 있습니까? 나는 스왑, 해당 프로세스에 대한 메모리 및 CPU 제약 조건에 대한 cgroup, 최대에 대한 ulimit를 끄려고 했습니다. 30개의 프로세스. 아무것도 상황을 개선하지 못했습니다. (음, 이것은 전적으로 사실이 아닙니다. 수백 MB를 영구적으로 사용하지 않는 RAM 제한이 도움이 되었습니다.)
특히: 메모리에서 코드 세그먼트를 교환하는 것을 방지하고 RAM을 요청하는 프로세스가 다음 malloc에 대해 NULL을 얻도록 할 수 있습니까?
답변1
메모리 오버커밋 계정을 조정하고 이를 기본 옵션 0(경험적 오버커밋) 대신 옵션 2(오버커밋하지 않음)로 설정하는 것은 어떻습니까? 해당 상태에 대한 설명
Don't overcommit. The total address space commit
for the system is not permitted to exceed swap + a
configurable amount (default is 50%) of physical RAM.
Depending on the amount you use, in most situations
this means a process will not be killed while accessing
pages but will receive errors on memory allocation as
appropriate.
위의 스 니펫은커널 문서
정책은 vm.overcommittunable을 사용하여 설정할 수 있습니다.