수년에 걸쳐,OOM 킬러운영 체제가 제대로 작동하지 않아 시스템이 정지됩니다.
메모리 사용량이 매우 높으면 전체 시스템이 "정지"되는 경향이 있습니다(실제로는극도로천천히)시간심지어하늘, 메모리를 확보하기 위해 프로세스를 종료하는 대신.
내가 기록한 가장 긴 기간은 7일이었고 그 후 재설정을 위해 종료했습니다.
OOM에 도달하려고 할 때,기다리다측정할 수 없게 되기 전에는 매우 매우 높습니다(~70%).
이 도구는 iotop매우 높은 처리량(수십 MB/초)으로 내 하드 드라이브에서 읽는 각 프로그램을 보여줍니다.
그 프로그램은 무엇을 읽고 있나요?
- 디렉토리 계층?
- 실행 가능한 코드 자체?
지금은 잘 모르겠습니다.
[편집됨] 이 글을 쓰는 시점(2017)에서는 최신 ArchLinux(4.9.27-1-lts)를 사용하고 있지만 몇 년 전에 이 문제가 발생했습니다.
다른 Linux 배포판과 다른 하드웨어 구성에서 동일한 문제가 발생했습니다.
현재(2019) 나는 최신 Debian 9.6(4.9.0)을 사용하고 있습니다.16 기가 바이트물리적 RAM, OS가 설치된 SSD, 없음교환분할.
내가 가지고 있는 메모리 양 때문에 스왑 파티션을 활성화하고 싶지 않습니다. 스왑 파티션은 문제 발생을 지연시킬 뿐이기 때문입니다.
또한 SSD를 너무 자주 교체하면 디스크 수명이 단축될 수 있습니다.
그런데, 스왑 파티션을 사용하거나 사용하지 않고 이것을 시도했는데 문제가 해결되지 않고 지연될 뿐이라는 것이 밝혀졌습니다.
나에게 있어 이 문제는 Linux가 중요한 데이터를 삭제했기 때문에 발생했습니다.은닉처, 매번 하드 드라이브의 모든 내용을 읽어야 하기 때문에 시스템이 정지됩니다.
Linux가 실행 중인 프로그램의 실행 가능한 코드 페이지를 삭제하지 않는지 궁금합니다. 이는 일반적으로 많은 양의 데이터를 읽지 않는 프로그램이 이 경우에 이런 식으로 동작하는 이유를 설명합니다.
이 문제를 해결하기 위해 여러 가지 방법을 시도했습니다. 하나는 (1GB) 로
설정됩니다 . 이것 때문에/proc/sys/vm/min_free_kbytes1000000
1GB무료로 유지되어야 하며, 이 메모리는 Linux에서 중요한 데이터를 캐시하기 위해 예약되어 있다고 가정합니다.
그러나 그것은 작동하지 않았습니다.
또한 이론상으로는 좋아 보이지만 to를 정의하여 가상 메모리의 크기를 실제 메모리의 크기로 제한하는 것은 기술적으로 /proc/sys/vm/overcommit_memory때문에일부 점을 덧붙이는 것이 유용하다고 생각합니다. 2어떤 이유에서인지 내가 사용하고 있는 가상 메모리에는 효과적으로 사용할 수 있는 것보다 더 많은 가상 메모리가 필요합니다.
문서에 따르면 /proc/meminfo이 Commited_AS값은 일반적으로 내 시스템의 물리적 메모리(16GB,제출_AS일반적으로 >32GB).
/proc/sys/vm/overcommit_memory나는 기본값에 이 문제가 있었습니다: 0그리고 잠시 동안 나는 그것을 다음과 같이 정의했습니다. 1왜냐하면 나는 프로그램을 다음과 같이 선호했기 때문입니다.OOM 킬러malloc할당이 거부될 때 반환 값을 확인하지 않기 때문에 잘못 동작하는 대신 .
온라인에서 이 이야기를 할 때IRC, 같은 문제를 겪고 있는 다른 Linux 사용자들을 본 적이 있어서 많은 사용자들이 이 문제에 대해 걱정하고 있는 것 같습니다.
나에게는 Windows조차도 높은 메모리 사용량을 더 잘 처리하기 때문에 이것은 용납될 수 없습니다.
더 많은 정보가 필요하거나 제안 사항이 있으면 알려주시기 바랍니다.
문서:
https://en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www.kernel.org/doc/Documentation/sysctl/vm.txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/317814/
그들은 그것에 대해 이야기합니다 :
Linux OOM(메모리 부족) 킬러가 자동으로 실행되지 않고 sysrq-key에 대해 작동하는 이유는 무엇입니까?
OOM-killer가 때때로 자원 점유자를 죽이지 못하는 이유는 무엇입니까?
OOM Killer 사전 로드
스왑을 강제할 때 OOM-killer를 실행할 수 있습니까?
OOM과 가까운 대기 시간이 긴 상황을 피하는 방법은 무엇입니까?
https://lwn.net/Articles/104179/
https://bbs.archlinux.org/viewtopic.php?id=233843
답변1
kswapd0이 디스크에서 계속 읽는 이유에 대한 두 가지 설명(같은 것)을 찾았습니다.발생하다OOM-killer가 문제가 있는 프로세스를 종료하기 전에:
- 답변 및 댓글 보기이 askubuntu SE 답변
- 답변 및 David Schwartz의 의견 보기이 답변은 유닉스 SE에 있습니다
여기에 1.의 의견을 인용하겠습니다. 모든 것이 괜찮았는데 왜 디스크에서 계속 읽었는지 눈을 뜨게 했습니다.겨울 왕국:
예를 들어, 스왑 공간이 없고 시스템의 RAM이 거의 부족한 상황을 생각해 보십시오. 커널은 예를 들어 Firefox에서 메모리를 가져옵니다(Firefox가 디스크에서 로드된 실행 코드를 실행하고 있기 때문에 이를 수행할 수 있습니다. 코드는 필요한 경우 디스크에서 다시 로드할 수 있습니다). Firefox가 N초 후에 해당 RAM에 다시 액세스해야 하는 경우, CPU는 Linux가 일부 RAM을 확보하고(예: 다른 프로세스에서 일부 가져옴) 디스크에서 누락된 데이터를 로드한 다음 Firefox가 계속 실행되도록 하는 "하드 오류"를 생성합니다. 대개. 이는 kswapd0이 수행하는 일반 스왑과 매우 유사합니다. – Mikko Rantalainen 2월 15일, 13:08
누구든지 이 동작을 비활성화하는 방법을 알고 있다면(어쩌면커널을 다시 컴파일하는 데 어떤 옵션이 사용됩니까?), 가능한 한 빨리 알려주세요! 매우 감사합니다!
고쳐 쓰다:지금까지 내가 찾은 유일한 방법은 커널을 패치하는 것입니다. 이는 스왑이 비활성화된 상태에서(예 CONFIG_SWAP is not set:) 작동했지만 스왑이 활성화된 다른 사용자에게는 작동하지 않았습니다.~인 것 같다;안쪽의 패치를 보세요이것질문.
답변2
EarlyOOM 유틸리티는 이 문제에 대한 실용적인 솔루션입니다. https://fedoraproject.org/wiki/Changes/EnableEarlyoom
유틸리티는 메모리 사용량을 모니터링하고 총 메모리 사용량이 구성 가능한 임계값(예: 95%)을 초과하기 전에 대규모 소비자를 종료합니다.
Arch Linux용으로 패키지되어 earlyoom있으며 systemd 서비스가 함께 제공되므로 빠르게 설치할 수 있습니다.
pacman -S earlyoom
systemctl enable earlyoom
systemctl start earlyoom
몇 주 동안 사용했는데 밤낮이 다릅니다. 메모리를 많이 사용하는 일부 응용 프로그램(Java, Electron 및 브라우저)으로 시스템을 한계까지 밀어붙였음에도 불구하고 시스템이 더 이상 정지되지 않습니다. 나는 이론적으로 일어날 수 있다고 생각하는 잘못된 프로세스가 종료되는 것을 개인적으로 목격하지 못했습니다. 온라인에 많은 설명이 작성되어 있기 때문에 이론상으로는 해결 불가능한 문제일 수도 있지만 실제로는 간단한 경험적 방법이 매우 잘 작동합니다.
답변3
memory.min메모리 컨트롤러의 매개변수가 cgroups-v2도움이 될 것입니다.
즉, 다음을 인용하겠습니다.
하드 메모리 보호. cgroup의 메모리 사용량이 유효 최소 범위 내에 있으면 어떤 상황에서도 cgroup의 메모리가 회수되지 않습니다. 보호되지 않은 회수 가능한 메모리가 없으면 OOM 킬러가 호출됩니다.
원천:https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html