Uzyskaj zrzut główny / debugowanie procesu zabitego przez oom-killera

10

Czy jest jakiś sposób, aby uzyskać zrzut główny lub mieć możliwość debugowania procesu, który został zabity przez Oom-Killera?

A może nawet ustawić program Oom-Killer na próbę zabicia procesu za pomocą ABRT?

oom dump

— TrapAlice
źródło

5

Innym podejściem jest wyłączenie nadmiernego zaangażowania pamięci.

Aby przywrócić odrobinę zdrowia psychicznego do zarządzania pamięcią:

Wyłącz OOM Killer ( vm.oom-kill = 0wstaw w /etc/sysctl.conf)

Wyłącz overcommitu pamięci (Put vm.overcommit_memory = 2w /etc/sysctl.conf)

Te ustawienia sprawią, że Linux będzie się zachowywał w tradycyjny sposób (jeśli proces zażąda więcej pamięci niż jest dostępna malloc(), zakończy się niepowodzeniem, a proces żądający pamięci poradzi sobie z tym niepowodzeniem).
Zauważ, że jest to wartość potrójna:

0 = „oszacuj, czy mamy wystarczającą ilość pamięci RAM”

1 = „Zawsze mów tak”

2 = „powiedz nie, jeśli nie mamy pamięci”

Wymusi to, że aplikacja sama poradzi sobie z brakiem pamięci, a być może jej dzienniki / coredump / itp. Mogą dać ci coś pożytecznego.

AKTUALIZACJA # 1

UWAGA: Kiedy w twoim systemie zabraknie pamięci, nie będziesz w stanie odrodzić nowych procesów! Możesz zostać zablokowany w systemie.

— nishantjr
źródło

To okropny pomysł. Większość oprogramowania działającego w systemie prawdopodobnie nie obsługuje poprawnie wartości zwracanej w przypadku niepowodzenia alokacji pamięci. Spowoduje to uruchomienie ścieżek kodu, które praktycznie nigdy nie zostaną wykonane przez nikogo, aw najgorszym przypadku mogą nawet wprowadzić w systemie luki w zabezpieczeniach związane z uruchomieniem tych nieprzetestowanych i nieoczekiwanych ścieżek kodu.

— KJ Tsanaktsidis

4

echo 1 > /proc/sys/vm/oom_dump_tasks

co wydaje się maksymalne, że jądro może wyświetlać błędy braku pamięci.

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

Umożliwia generowanie zrzutu zadań w całym systemie (z wyłączeniem wątków jądra), gdy jądro wykonuje zabijanie OOM i zawiera takie informacje, jak pid, uid, tgid, rozmiar vm, rss, nr_ptes, swapents, wynik oom_score_adj i nazwa. Pomaga to ustalić, dlaczego wywołano zabójcę OOM, zidentyfikować nieuczciwe zadanie, które go spowodowało, i ustalić, dlaczego zabójca OOM wybrał zadanie, które miał zabić.

Jeśli jest ustawiony na zero, informacje te są pomijane. W bardzo dużych systemach z tysiącami zadań zrzucenie informacji o stanie pamięci dla każdego z nich może być niewykonalne. Takie systemy nie powinny być zmuszane do ponoszenia kary wydajnościowej w warunkach OOM, gdy informacje mogą nie być pożądane.

Jeśli ta wartość jest ustawiona na niezerową, ta informacja jest wyświetlana za każdym razem, gdy zabójca OOM faktycznie zabija zadanie zapamiętywania pamięci.

— HBruijn
źródło