데비안 9.4, 리눅스 4.9
가끔 RAM에 거의 맞지 않는 것을 컴파일하거나, 루저 프로세스가 갑자기 사용 가능한 것보다 많은 메모리를 먹기 시작합니다. 프로세스가 사용 가능한 RAM을 초과하면 Linux는 제로 스왑이 활성화되어 있어도 디스크 스래싱을 시작합니다(이를 피하기 위한 스왑은 없었습니다). mmap현재 실행 중인 바이너리의 ped 부분 과 같은 항목을 버리고 다시 로드하기 시작하는 것 같아요 .
이 시점에서 내 X 세션은 빠르게 응답하지 않게 되며, 내가 할 수 있는 일은 전체 X 세션이 종료되어 다시 로그인할 수 있을 때까지 수십 분을 기다리는 것뿐입니다.
해결책을 찾아보았지만 아무것도 작동하지 않는 것 같습니다. OOM 킬러는 이 프로세스를 포착하지 못하며 vm.overcommit_memory=2GDM 및 Gnome으로 로그인할 수도 없습니다.
방법이 있나요?리눅스에게 전혀 스왑하지 말라고 지시하기? 그렇게 하면 적어도 루즈 프로세스가 failed 에 의해 종료될 기회를 얻을 수 있으며 malloc, 그렇지 않더라도 적어도 응답하지 않는 시스템을 쳐다보면서 기다릴 필요는 없습니다.
아니면 이 시나리오를 관리하는 방법에 대한 다른 힌트가 있나요?
답변1
거의 모든 사용 가능한 RAM이 필요한 소스를 컴파일하는 경우 아마도 유일한 성능 솔루션은 실제 RAM을 추가하는 것입니다. 그렇다면 매우 많은 양의 스왑(예: RAM의 2배 또는 3배)을 추가하고 /proc/sys/vm/swappiness1과 같은 낮은 값으로 설정할 수 있습니다(커널 3.5+에서는 0으로 설정하면 스왑이 완전히 비활성화됩니다). 효과적으로 필요한 경우에만 사용됩니다. 이렇게 하면 스래싱이 최소화됩니다.
답변2
사람들이 RAM을 더 추가하거나 스왑 공간을 더 추가하라고 어떻게 권장할 수 있는지 이해가 되지 않습니다. 오작동하는 응용 프로그램은 모든 것을 먹어치우고 문제를 재현할 수 있습니다.
이러한 종류의 정지는 Linux 커널의 심각한 아키텍처 버그입니다. 정지된 후 복구하는 유일한 방법은 마법 키(alt+sysrq+f)를 사용하여 OOM을 강제로 실행하는 것입니다. 커널 로그는 나중에 무엇이 죽었는지, 왜 죽었는지 알려줄 것입니다.
여러 프로젝트에서 사용자 공간이 정지되는 것을 방지하려고 노력하고 있습니다. 예를 들어 earlyOOM을 참조하세요.