Dlaczego OOM-Killer nie może po prostu zabić procesu, który wymaga zbyt wiele?

Wyjaśniono tutaj, że OOM-Killer można skonfigurować za pomocą overcommit_memoryi że:

2 = bez nadmiernego zaangażowania. Przydziały kończą się niepowodzeniem, jeśli prosi się o zbyt wiele.
0, 1 = nadmierne zaangażowanie (heurystycznie lub zawsze). Zabij niektóre procesy oparte na heurystyce, gdy faktycznie uzyskuje się zbyt dużo pamięci.

Teraz mogę całkowicie to zrozumieć, ale dlaczego nie ma opcji (lub dlaczego nie jest to ustawienie domyślne) zabicia samego procesu, który faktycznie próbuje uzyskać dostęp do zbyt dużej ilości przydzielonej pamięci?

linux out-of-memory

— Martin Ba
źródło

Co się stanie, jeśli krytyczny proces systemowy poprosi o zbyt dużo pamięci?

— Lawrence

Po pierwsze - potrafi to zrobić. Ale największym problemem z tym pytaniem jest to, że najprawdopodobniej, jeśli proces prosi o pamięć, to jest on nowo wykonywany - lub innymi słowy, jest to nowy proces zaangażowany w bardzo bieżące przetwarzanie. Czy wolisz, aby OOM pozwolił swojemu klientowi, który nie otwierał na 3 dni, marnowanie pamięci systemowej, czy wolałbyś, żeby YouTube rzeczywiście załadował trochę czasu w tym roku? linuxatemyram.com

— mikeserv

Tak właśnie działa no overcommitopcja. Jeśli proces wymaga zbyt dużej ilości pamięci, kończy się niepowodzeniem. Jeśli sprawdzi błąd, zwykle sam się zabije; jeśli nie, prawdopodobnie pojawi się błąd segmentacji, gdy spróbuje wyłuskać zwracany wskaźnik zerowy malloc(), i zawiesi się.

— Barmar

Zauważ, że 2 to tak naprawdę no overcommittryb, zgodnie z cytowanymi źródłami (takimi jak kernel.org/doc/Documentation/vm/overcommit-accounting ). Myślę, że odpowiednio zmodyfikuję twoje pytanie.

— hans_meine

Rozważ ten scenariusz:

Masz 4 GB wolnej pamięci.
Wadliwy proces przydziela 3,999 GB.
Otwierasz menedżera zadań, aby zabić niekontrolowany proces. Menedżer zadań przydziela 0,002 GB.

Jeśli proces, który został zabity, był ostatnim procesem żądania pamięci, menedżer zadań zginie.

Lub:

Masz 4 GB wolnej pamięci.
Wadliwy proces przydziela 3,999 GB.
Otwierasz menedżera zadań, aby zabić niekontrolowany proces. Serwer X przydziela 0,002 GB do obsługi okna menedżera zadań.

Teraz twój serwer X zostaje zabity. Nie spowodowało problemu; było po prostu „w niewłaściwym miejscu w niewłaściwym czasie”. Był to pierwszy proces przydzielania większej ilości pamięci, gdy jej nie było, ale to nie był proces, który wykorzystywał całą pamięć na początek.

— użytkownik253751
źródło

Rozszerzając przykład, oznacza to, że jeśli proces zużywał 99,999% pamięci, nigdy nie byłbyś w stanie go zabić, ponieważ wszystko, co mogłoby go zabić, wymagałoby pamięci, a tym samym zabiłoby się, zanim zabłądziłby błędny proces!

— Sled

Pamiętaj, to jest filozofia Linuksa, a nie konieczny fakt. System Windows 3.0 rozwiązał go, rezerwując wystarczającą ilość pamięci do obsługi OOM, w tym niezbędnych okien dialogowych.

— MSalters

@MSalters: Jednak tak naprawdę nie dotyczy to przykładu; Przykład dotyczył procesu, który zarezerwował prawie całą pamięć, tj. nie wystarczy, by zabić OOM. Oczywiście musi być wystarczająca ilość pamięci zarezerwowanej do obsługi OOM w dowolnym systemie operacyjnym. Ale proces wywołujący obsługę OOM byłby kolejnym procesem, który ma miejsce w celu zarezerwowania pamięci, a nie niewłaściwym. Chyba że oczywiście chodziło o to, że system Windows 3.0 zawsze miał wystarczająco dużo pamięci zarezerwowanej do uruchomienia menedżera zadań lub że program obsługi OOM zawsze monitował użytkownika o zakończenie procesu. (Co! = Zabicie przestępcy)

— Aleksi Torhamo

@AleksiTorhamo: Rzeczywiście miałem na myśli to drugie. Windows 3.0 nie miał pełnego menedżera zadań, miał słynne niebieskie ekrany, których pamięć została wstępnie przydzielona.

— MSalters