OOM 킬러 / cgroup에 의해 프로세스가 종료되기 전에 신호 수신

11

클러스터에서 프로세스 리소스 (예 : 메모리 ( memory.limit_in_bytes))를 제한하고 있습니다 .

결국, 이것은 Linux 커널에서 OOM 킬러를 통해 처리된다고 생각합니다. 소스 코드 ).

프로세스가 종료되기 전에 신호를받을 수있는 방법이 있습니까? ( SGE의-notify 옵션 과 마찬가지로qsubSIGUSR1프로세스가 종료되기 전에 전송되는 .

나는 /dev/mem_notify 여기 에 대해 읽었 지만 그것을 가지고 있지 않습니다. 요즘 다른 것이 있습니까? 나도 읽었다 다소 관련 이 있는 것으로 .

최소한 작은 스택 추적과 다른 유용한 디버그 정보를 덤프 할 수 있기를 원하지만 메모리를 확보하여 복구 할 수도 있습니다.

현재 사용중인 한 가지 해결 방법은 이 작은 스크립트 입니다. 이 스크립트 는 내가 한계에 가까이 있는지 (95 %) 자주 확인하고 그렇다면 그렇다면 프로세스를 보냅니다 SIGUSR1. Bash에서는이 스크립트를 백그라운드 ( cgroup-mem-limit-watcher.py &) 에서 시작 하여 동일한 cgroup에서 다른 프로세스를 감시하고 부모 Bash 프로세스가 종료되면 자동으로 종료됩니다.

— 앨버트
소스

권한 소스를 찾을 수 없었거나 특정 프로세스에 대해 수동으로 OOM 킬러를 호출하는 방법을 찾지 못했습니다 (아이디어를 테스트하기 위해) . 그러나 내가 찾은 것에서 OOM 킬러는 단순히 SIGTERM을 전송하는 것으로 보입니다. 이 시그널의 핸들러

— Hi-Angel

5

@ Hi-Angel : Linux 소스 코드 에서 SIGKILL을 보내는 것 같습니다.

— Albert

@Albert 소스 코드를 읽은 후에는 OOM Killer가 SIGKILL 신호를 직접 보낼 것이라고 생각합니다.

— andy

5

cgroup의 메모리 사용량이 임계 값을 초과 할 때 알림을 등록 할 수 있습니다. 원칙적으로 임계 값을 실제 한계 아래의 적절한 지점에 설정하면 신호를 보내거나 다른 조치를 취할 수 있습니다.

보다:

https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt

— 크리스 에머슨
소스

5

OOM 킬러는 SIGKILL을 보내지 않습니다. 그렇지 않으면 문제가있는 프로그램이 계속 선택할 수 있도록 반 생산적입니다.

이는 프로세스가 프로세스에 의해 언제 종료되는지 알 수있는 방법이 전혀 없음을 의미합니다.

이러한 문제를 관리하는 것은 대개 프로그램이나 구성을 수정하는 것을 의미합니다. 때때로 시스템 구성에 따라 스왑 공간을 늘리기 만하면 OS에 더 많은 메모리 관리 유연성을 부여하여 그러한 과감한 조치를 피할 수 있습니다.

— 줄리 펠티에
소스