oom-killer에 의해 종료 된 프로세스의 핵심 덤프 / 디버깅 받기

10

oom-killer에 의해 강제 종료 된 프로세스를 코어 덤프하거나 디버그 할 수있는 방법이 있습니까?

아니면 ABRT를 사용하여 프로세스를 강제 종료하도록 oom-killer를 설정합니까?

oom dump

— 트랩 앨리스
소스

5

온전한 유사성을 메모리 관리로 복원하려면 :

OOM Killer 비활성화 ( vm.oom-kill = 0/etc/sysctl.conf에 넣기 )

비활성화 메모리 오버 커밋 (넣어 vm.overcommit_memory = 2에서 /etc/sysctl.conf)

이러한 설정은 Linux를 전통적인 방식으로 작동하게합니다 (프로세스가 사용 가능한 malloc()것 보다 많은 메모리를 요청 하면 실패하고 메모리를 요청하는 프로세스는 해당 실패에 대처할 것으로 예상됩니다).
이것은 삼항 값입니다.

0 = "RAM이 충분한 지 추정하십시오"

1 = "항상 예"

2 = "메모리가 없으면 아니오"

이로 인해 응용 프로그램이 메모리 부족을 처리하게되고 로그 / 코어 덤프 등이 유용한 정보를 제공 할 수 있습니다.

업데이트 # 1

참고 : 시스템 메모리가 부족하면 새로운 프로세스를 생성 할 수 없습니다! 시스템이 잠겨있을 수 있습니다.

— nishantjr
소스

이것은 끔찍한 생각입니다. 시스템에서 실행되는 대부분의 소프트웨어는 메모리 할당 실패의 반환 값을 올바르게 처리하지 못할 수 있습니다. 이렇게하면 실제로는 아무도 실행하지 않는 코드 경로가 발생하며 최악의 경우 시스템에서 테스트되지 않은 예기치 않은 코드 경로를 실행하는 데 보안 취약점이 발생할 수 있습니다.

— KJ Tsanaktsidis

4

echo 1 > /proc/sys/vm/oom_dump_tasks

커널이 메모리 부족 오류에 표시 될 수있는 최대 값에 대한 것 같습니다.

https://www.kernel.org/doc/Documentation/sysctl/vm.txt

커널이 OOM-killing을 수행 할 때 시스템 전체 작업 덤프 (커널 스레드 제외)를 생성 할 수 있으며 pid, uid, tgid, vm 크기, rss, nr_ptes, swapents, oom_score_adj 점수 및 이름과 같은 정보가 포함됩니다. 이는 OOM 킬러가 호출 된 이유를 판별하고, 그 원인이되는 불량 작업을 식별하고, OOM 킬러가 종료 한 작업을 선택한 이유를 판별하는 데 도움이됩니다.

이것이 0으로 설정되면이 정보는 억제됩니다. 수천 개의 작업이있는 매우 큰 시스템에서는 각 시스템의 메모리 상태 정보를 덤프하지 못할 수 있습니다. 이러한 시스템은 정보가 필요하지 않을 때 OOM 조건에서 성능 저하를 강요해서는 안됩니다.

이것이 0이 아닌 값으로 설정되면이 정보는 OOM 킬러가 실제로 메모리 호깅 작업을 종료 할 때마다 표시됩니다.

— HBruijn
소스