OOM 킬러가 작동하지 않습니까?

41

내가 이해하는 바에 따르면, 시스템에 여유 메모리가 없을 때 커널은 프로세스를 강제 종료하여 메모리를 다시 확보해야합니다. 그러나 내 시스템에서 이것은 전혀 일어나지 않습니다.

시스템에서 사용 가능한 것보다 훨씬 더 많은 메모리를 할당하는 간단한 스크립트 (예 : 수백만 개의 문자열이있는 배열)를 가정하십시오. 이와 같은 스크립트를 일반 사용자로 실행하면 시스템이 완전히 정지 할 때까지 모든 메모리를 가져옵니다 (SysRQ REISUB 만 작동).

여기서 이상한 부분은 컴퓨터가 멈 추면 하드 드라이브 LED가 켜지고 스왑 파티션이 마운트되어 있는지 여부에 관계없이 컴퓨터가 재부팅 될 때까지 계속 유지된다는 것입니다!

그래서 내 질문은 :

이 동작이 정상입니까? 일반 사용자로 실행 된 응용 프로그램이 시스템을 이런 식으로 중단시킬 수있는 것은 이상합니다.
메모리가 너무 많거나 가장 많을 때 우분투가 자동으로 응용 프로그램을 죽일 수있는 방법이 있습니까?

추가 정보

우분투 12.04.3
커널 3.5.0-44

RAM : 4GB에서 ~ 3.7GB (그래픽 카드와 공유). *

$ tail -n+1 /proc/sys/vm/overcommit_*
==> /proc/sys/vm/overcommit_memory <==
0

==> /proc/sys/vm/overcommit_ratio <==
50

$ cat /proc/swaps
Filename                Type        Size    Used    Priority
/dev/dm-1                               partition   4194300 344696  -1

kernel

— 살렘
소스

왜 작동하지 않는지 잘 모르겠습니다. tail -n+1 /proc/sys/vm/overcommit_*출력을 시도 하고 추가하십시오. 여기 참조 : 작업 방법 구성 움 킬러

— 키리

스왑 공간은 어떻게 되나요? #vmstat 1 100 또는 이와 유사한 vmstat 출력을 게시 할 수 있습니까? 또한 cat / etc / fstab를 보여줍니다. 메모리 사용량이 일정 할 때 스왑을 작성해야합니다. 메모리와 스왑 공간이 "풀"이 될 때까지 강제 종료 프로세스가 발생하지 않아야합니다.

— j0h

또한 -a #swapon 시도

— j0h

@ j0h 스왑을 사용하면 제대로 작동하는 것 같습니다 (시간이 지나면 프로세스가 충돌했습니다 Allocation failed). 그러나 스왑이 없으면 컴퓨터가 정지됩니다. 이 방법으로 작동해야합니다 (스왑을 사용할 때만 죽이십시오)?

— Salem

2

SysRq를 사용하면 OOM (SysRq + F iirc)을 호출 할 수도 있습니다.

— Lekensteyn

36

로부터 공식 /proc/sys/vm/*문서 :

oom_kill_allocating_task

메모리 부족 상황에서 OOM 트리거 작업 종료를 활성화 또는 비활성화합니다.

이 값을 0으로 설정하면 OOM 킬러가 전체 작업 목록을 검색하여 휴리스틱을 기반으로 죽일 작업을 선택합니다. 이것은 일반적으로 죽일 때 많은 양의 메모리를 확보하는 불량 메모리 호깅 작업을 선택합니다.

이것이 0이 아닌 값으로 설정되면 OOM 킬러는 단순히 메모리 부족 조건을 트리거 한 작업을 종료합니다. 이것은 비싼 작업리스트 스캔을 피합니다.

panic_on_oom을 선택하면 oom_kill_allocating_task에 사용 된 값보다 우선합니다.

기본값은 0입니다.

설정시, 요약하기 위해 oom_kill_allocating_task에 1대신 비용과 느린 작업입니다 죽일 수있는 프로세스를 찾고 당신의 시스템을 스캔, 커널은 시스템의 메모리가 부족를 일으킨 프로세스를 종료합니다.

내 경험에 따르면, OOM이 트리거되면 커널은 더 이상 "강도"가 남지 않아 시스템을 완전히 사용할 수 없게됩니다.

또한 문제를 일으킨 작업을 죽이는 것이 더 분명하므로 0기본적으로 왜 설정되어 있는지 이해하지 못합니다 .

테스트를 위해에 적절한 의사 파일 /proc/sys/vm/을 작성하면 다음에 다시 부팅 할 때 실행 취소됩니다.

echo 1 | sudo tee /proc/sys/vm/oom_kill_allocating_task

영구 수정의 경우 확장자 /etc/sysctl.conf아래 ( 예 :) 아래에 새 파일에 또는 새 파일에 다음을 쓰십시오 ./etc/sysctl.d/.conf/etc/sysctl.d/local.conf

vm.oom_kill_allocating_task = 1

— 테레사와 주니어
소스

2

우분투에서 항상 0으로 설정 되었습니까? 자동으로 죽이는 것을 기억했지만 몇 가지 버전으로 인해 중단되었습니다.

— skerit 2016 년

1

@skerit 이것은 잘 모르겠지만 2010 년에 다시 사용했던 커널 (Debian, Liquorix 및 GRML)에서는 0으로 설정되었습니다.

— Teresa e Junior

"또한 문제를 일으킨 작업을 죽이는 것이 더 분명하므로 0기본적으로 설정되어있는 이유를 이해할 수 없습니다 ." -메모리를 요청한 프로세스가 반드시 "문제를 일으킨"프로세스는 아니기 때문입니다. 프로세스 A가 시스템 메모리의 99 %를 차지하지만 0.9 %를 사용하는 프로세스 B가 불운으로 OOM 킬러를 트리거하는 프로세스 인 경우 B는 "문제를 일으킨"것이 아니며 의미가 없습니다. kill B. 정책이 다른 프로세스의 런 어웨이 메모리 사용량으로 인해 완전히 문제가없는 메모리 부족 프로세스가 우연히 종료 될 위험이 있습니다.

— Mark Amery

1

@MarkAmery 실제 문제는 리눅스가 필요한 프로세스를 죽이는 대신 128MB로vm.admin_reserve_kbytes 증가 하더라도 지연처럼 스레 싱을 시작 한다는 것 입니다. 설정 은 문제를 완화시키는 것으로 보이지만 실제로 해결하지는 못합니다 (우분투는 이미 기본적으로 포크 폭탄을 처리합니다). vm.oom_kill_allocating_task = 1

— Teresa e Junior

1

아마 더 우아하다sudo sysctl -w vm.oom_kill_allocating_task=1

— Pablo A

9

업데이트 : 버그가 수정되었습니다.

Teresa의 답변 은 문제를 해결하기에 충분하며 좋습니다.

또한 버그 보고서를 제출 했습니다. 버그 보고서 는 분명히 동작이 깨지기 때문입니다.

— int_ua
소스

왜 다운 보트를 받았는지 모르겠지만 커널 버그처럼 들립니다. 나는 오늘 큰 대학 서버에 충돌을 일으켜 몇 주 동안 실행중인 일부 프로세스를 죽였습니다 ...하지만 버그 보고서를 제출해 주셔서 감사합니다!

— shapecatcher

7

OOM 킬러는 아직 2014 년에 2018 년 (18.04)에 수정되었을 수도 있습니다.

— skerit

0

사용자 공간에서 작동하고 OOM 상황에서 가장 큰 프로세스를 종료하려고 시도하는 OOM 킬러 인 earlyoom 을 시도 할 수 있습니다 .

— qwr
소스

-1

우선 13.10으로의 업데이트를 권장합니다 (새로 설치, 데이터 저장).

업데이트하지 않으려면 vm.swappiness를 10으로 변경하고 램 설치 zRAM에 문제가있는 경우

— Brask
소스

2

나는 당신을 억압 한 사람이 아니었지만 일반적으로 vm.swappiness낮은 메모리 문제로 고통받는 시스템에서 더 많은 해를 끼치는 것이 좋습니다.

— Teresa e Junior

램을 먼저 압축 할 때가 아니라 디스크 사용을 피하면 속도가 훨씬 느려지고 컴퓨터가 정지 될 수 있습니다.

— Brask

이론적으로 zRAM은 좋은 것이지만 CPU가 배가 고프 며 일반적으로 비용이 들지 않습니다. 메모리는 일반적으로 전기보다 훨씬 저렴합니다. 그리고 RAM 업그레이드가 더 비싼 랩톱에서는 CPU 사용이 바람직하지 않습니다.

— Teresa e Junior

그가 요구하는 것은보다 안정적인 시스템 zRAM을 가지고 교환 스왑을 변경하면 시스템이 더 많은 CPU 리소스를 사용하게 될 것입니다. 그러나 atm이 제한되어 있고 오류가있는 것은 메모리입니다. 이론이 아닌 문제를 해결하고 싶습니다 zRAM을 설치할 때 발생하는 상황.

— Brask

그의 질문에서 그는 자신이해야 할 것보다 더 많이 먹는 부적절한 스크립트를 작성할 수 있다는 것이 분명합니다. 이와 같은 상황에서는 몇 초 만에 기가 바이트의 RAM을 잡는 스크립트를 볼 수 있으며 스크립트가 충분히 만족스럽지 않기 때문에 zRAM이 구조되지 않습니다.

— Teresa e Junior