☰

Linux OOM(메모리 부족) 킬러가 자동으로 실행되지 않고 sysrq-key에 대해 작동하는 이유는 무엇입니까?

tag-icon • tag-icon linux out-of-memory
Linux OOM(메모리 부족) 킬러가 자동으로 실행되지 않고 sysrq-key에 대해 작동하는 이유는 무엇입니까?

메모리 부족 OOM 상황이 발생하면 Linux 박스 UI가 오랫동안 완전히 정지되는 것을 발견했습니다.

Magic-sysrq-key를 설정한 후 OOM->UI 응답이 없는 상황이 발생하여 로그에 표시된 대로 OOM이 프로세스를 종료/종료하게 하여 OOM 상황을 해결할 echo 1 | tee /proc/sys/kernel/sysrq수 있었습니다 .Alt-Sysrq-fdmesg

내 문제는 지금입니다. GUI가 정지되는 것처럼 Linux가 응답하지 않지만 Alt-Sysrq-f키 조합을 통해 수동으로 실행하는 것과 동일한 OOM-Killer를 실행하지 않는 이유는 무엇입니까 ?

OOM "정지" 상황에서 시스템이 응답하지 않고 시기적절한(<10초) 응답(tty3으로 전환)도 허용하지 않는다는 점을 고려하면 커널이 응답 없음을 인식해야 하지만 여전히 그렇지 않다고 가정해야 합니다. OOM Ctrl-Alt-F3자체 호출 -Alt-Sysrq-f

다음은 설명된 동작에 영향을 미칠 수 있는 일부 설정입니다.

$> mount | grep memory
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
$> cat /sys/fs/cgroup/memory/memory.oom_control 
oom_kill_disable 0
under_oom 0
oom_kill 0

내가 이해하는 한, 메모리 cgroup은 OOM을 활성화하거나 비활성화하지 않습니다(분명히 OOM_kill을 활성화하고 비활성화하는 데에는 타당한 이유가 있어야 합니다. 아니면 출력을 올바르게 해석하지 않아서 under_oom 0여전히 약간 불분명할 수 있습니다).

답변1

OOM-killer가 자동으로 호출되지 않는 이유는 시스템이 완전히 느리고 응답이 없음에도 불구하고메모리가 거의 부족함y, 실제로 메모리 부족 상황에 도달하지 않았습니다.

지나치게 단순화하면 거의 가득 찬 메모리에는 3가지 유형의 데이터가 포함됩니다.

  1. 필수적인 커널 데이터
  2. 기본 프로세스 데이터 페이지(즉, RAM에서만 프로세스에 의해 생성된 모든 데이터)
  3. 필수적이지 않은 프로세스 데이터 페이지(디스크/파일 시스템에 복사본이 있고 현재 메모리에 매핑되어 있으며 사용 시 디스크에서 "다시 읽을" 수 있는 실행 코드 등과 같은 데이터)

메모리 부족의 경우, 제가 아는 한, Linux 커널은 kswapd0데이터 손실 및 기능 손실을 방지하기 위해 1.과 2.를 버릴 수 없지만 매핑된 항목을 최소한 일시적으로 자유롭게 삭제할 수 있는 커널 스레드 입니다. RAM의 메모리 파일 현재 실행되지 않는 프로세스 형태의 데이터입니다.

여기에는디스크 스래싱지속적으로 데이터를 삭제하고 디스크에서 다시 읽는 것은 필요한 프로세스 삭제/종료 및 해제뿐만 아니라 메모리 손실도 방지하거나 최소한 연기하므로 도움이 될 수 있습니다.높은가격: 성능.

[load pages from disk to ram with code of executable of process 1]
[ run process 1 ] 
[evict pages with binary of process 1 from ram]
[load pages from disk to ram with code of executable of process 2]
[ run process 2 ] 
[evict pages with binary of process 2 from ram]
[load pages from disk to ram with code of executable of process 3]
[ run process 3 ] 
[evict pages with binary of process 3 from ram]
....
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ] 
[evict pages with binary of process 1 from ram]

기술적으로는 IO 비용이 높고 시스템이 응답하지 않을 수 있습니다.아직 완전히 소모되지 않았습니다메모리.

그러나 사용자 관점에서 볼 때 정지/정지 및 결과적으로 응답하지 않는 UI는 단순히 프로세스(예: 메모리 사용량이 근본 원인/범인일 가능성이 가장 높은 브라우저 탭의 프로세스)를 종료하는 것보다 나을 수 없습니다. 첫 번째. )

질문에서 알 수 있듯이 이것은매직 SysRq 키Magic SysRq는 시스템 무응답의 영향을 덜 받기 때문에 OOM에 대한 트리거를 수동으로 시작하는 것이 좋습니다.

프로세스를 보존하는 것이 중요한 사용 사례가 있을 수 있지만(성능) 비용, 데스크톱 사용자의 경우 고정된 UI 대신 OOM 킬러를 선호할 수 있습니다. 이 상황에서 메모리에서 깔끔하게 매핑된 파일 시스템 지원 파일을 제외한다고 주장하는 패치가 있습니다.stackoverflow에 대한 답변.

답변2

스트레스 테스트 중에 /sys/fs/cgroup/memory/memory.oom_control 파일을 볼 수 있습니다.

또는

마지막 수정 날짜를 확인하여 마지막으로 잠긴 시간쯤에 변경되었는지 확인할 수 있습니다. 이는 작업을 수행하려고 하는지 여부를 알려줍니다.

under_oom 0

그게 당신의 문제입니다:

under_oom    0 or 1 (if 1, the memory cgroup is under OOM, tasks may
             be stopped.)

1로 설정하면 oom에 의해 제어된다는 의미입니다. 활성화되었습니다.
0으로 설정하면 oom에 의해 제어되지 않습니다. 장애인.

관련 정보