Ustalenie, który proces został zabity przez zabójcę Linux OOM

172

Kiedy Linuxowi zabraknie pamięci (OOM), zabójca OOM wybiera proces do zabicia w oparciu o pewne heurystyki (jest to interesująca lektura: http://lwn.net/Articles/317814/ ).

Jak można programowo określić, które procesy zostały niedawno zabite przez zabójcę OOM?

linux linux-kernel

— Yang
źródło

171

Wypróbuj to:

grep -i 'killed process' /var/log/messages

— John Feminella
źródło

18

FWIW, dostaję te wiadomości w syslog lub kern.log, ale nie / var / log / messages

— jberryman

36

Możesz użyć "egrep -i -r 'zabity proces' / var / log /", aby przeszukać go także w innych miejscach.

— metdos

5

@jberryman: Z jakiegoś powodu syslog jest dostępny /var/log/syslogw niektórych dystrybucjach i /var/log/messagesinnych. Myślę, że to Debian dla pierwszego i Red Hat dla drugiego, BICBW.

— Tom Anderson,

5

„dmesg | egrep -i 'zabity proces'” i możesz przeszukiwać dzienniki w dowolnym miejscu (w tym zarchiwizowane) :)

— John D

2

egrepnie ma tu sensu. Zwykły stary grep, lub jeśli jesteśmy konkretni fgrep, ma znacznie więcej sensu. (Odpowiednio

— edytując

148

Spróbuj tego, aby nie martwić się o to, gdzie są Twoje dzienniki

dmesg | egrep -i 'killed process'

— Jose Fernandez
źródło

1

Jest to również przydatne, ale chociaż niestety nie mogę tego wyjaśnić, widzę wyniki /var/log/messages, które nie pojawiają się w dmesg/ /var/log/dmesg. Może to być błąd w konfiguracji, ale warto zauważyć, że użycie obu podejść może być dobrym pomysłem.

— kungphu

3

Nie mam pewności co do pliku dziennika, ale wyjście dmesg pochodzi z bufora pierścieniowego o ograniczonym rozmiarze. Jeśli inne rzeczy wypełniły bufor od czasu zabójcy oom, stracisz wyjście zabójcy oom.

— Dan Pritts,

To był jedyny sposób, w jaki znalazłem, jak zobaczyć, że proces został zabity w kontenerze OpenVZ

— igo

16

Sugerowałbym również użycie dmesg -Tw celu uzyskania czytelnych znaczników czasu

— gukoff

2

W porównaniu z / var / log / messages ma to tę zaletę, że nie wymaga uprawnień roota

— Kineolyan,

52

Teraz dstat udostępnia funkcję sprawdzania w uruchomionym systemie, który proces może zostać zabity przez mechanizm oom

dstat --top-oom
 --out-of-memory---
  kill score
 java           77
 java           77
 java           77

i zgodnie ze stroną podręcznika

  --top-oom
          show process that will be killed by OOM the first

— Prashant Lakhera
źródło

Ta informacja jest bez znaczenia, jeśli nie wiesz, co oznacza wynik i nie jest nigdzie udokumentowana. Wszystko, co możesz zobaczyć, to wzrost wyniku, a następnie proces zostaje zabity, więc może to był zabójca oom, a może to było coś innego, nie ma sposobu, aby być pewnym.

— laurent

18

Wypróbuj to:

grep "Killed process" /var/log/syslog

— Praveen
źródło