odbierać sygnał, zanim proces zostanie zabity przez OOM killer / cgroups

11

W naszym klastrze ograniczamy zasoby naszych procesów, np. Pamięć ( memory.limit_in_bytes).

Myślę, że ostatecznie jest to również obsługiwane przez zabójcę OOM w jądrze Linuksa (wygląda to tak, czytając kod źródłowy ).

Czy jest jakiś sposób na uzyskanie sygnału, zanim mój proces zostanie zabity? (Podobnie jak -notifyopcja dla SGEqsub , które wyślą SIGUSR1przed zakończeniem procesu).

Czytam o tym /dev/mem_notify tutaj, ale nie mam tego - czy jest coś jeszcze w dzisiejszych czasach? Przeczytałem również to, co wydaje się dość istotne.

Chcę być w stanie przynajmniej zrzucić ślad małego stosu i może jakieś inne przydatne informacje debugowania - ale może uda mi się nawet odzyskać, zwalniając trochę pamięci.

Jednym z obejść, których obecnie używam, jest ten mały skrypt, który często sprawdza, czy jestem blisko (95%) limitu, a jeśli tak, wysyła proces a SIGUSR1. W Bash uruchamiam ten skrypt w tle ( cgroup-mem-limit-watcher.py &), aby szukał on innych procesów w tej samej grupie i automatycznie kończy działanie po śmierci nadrzędnego procesu Bash.

— Albert
źródło

Nie mogłem znaleźć żadnych źródeł uprawnień, ani nie mogłem znaleźć sposobu, aby ręcznie wywołać OOM Killer dla określonego procesu (w celu przetestowania pomysłu) , ale z tego, co znalazłem, wydaje się, że OOM Killer po prostu wysyła SIGTERM, więc musisz ustawić moduł obsługi tego sygnału.

— Hi-Angel,

5

@ Hi-Angel: Z kodu źródłowego Linuksa wydaje się, że wysyła SIGKILL.

— Albert,

@Albert Po przeczytaniu kodu źródłowego, myślę również, że OOM Killer wyśle bezpośrednio sygnał SIGKILL.

— andy

5

Możliwe jest zarejestrowanie się, aby otrzymywać powiadomienia o przekroczeniu przez pamięć grupy pamięci wartości progowej. Zasadniczo ustawienie progu w odpowiednim punkcie poniżej faktycznego limitu umożliwi wysłanie sygnału lub podjęcie innych działań.

Widzieć:

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

— Chris Emerson
źródło

5

OOM Killer wysyła SIGKILL, ponieważ w przeciwnym razie niepraktyczne byłoby pozostawienie problematycznemu programowi wyboru kontynuacji.

Oznacza to, że proces nie ma absolutnie żadnej wiedzy, kiedy ma zostać zabity.

Zarządzanie takimi problemami zwykle oznacza dokonywanie poprawek w programach lub ich konfiguracji. Czasami, w zależności od konfiguracji systemu, zwykłe zwiększenie przestrzeni wymiany może dać systemowi operacyjnemu większą elastyczność zarządzania pamięcią, aby uniknąć tak drastycznych środków.

— Julie Pelletier
źródło