Zrozumieć działanie OOM Killer: kiedy system Linux kończy procesy

W artykule wyjaśniono, w jaki sposób oom killer linux jak reaguje w przypadku nagłych ograniczeń pamięci operacyjnej i dlaczego siłowo zamyka usługi, aby utrzymać serwer w stanie gotowości do pracy. Pokażę krok po kroku, jak rozpoznaję czynniki wyzwalające, jak rozumiem system punktacji oraz jak za pomocą ukierunkowanych ustawień kontroluję zachowanie systemu w warunkach obciążenia pamięci.

Punkty centralne

• Wyzwalacz: Zdarzenia OOM występują, gdy pamięć RAM jest zapełniona, obszar wymiany jest wyczerpany, a próby odzyskania pamięci kończą się niepowodzeniem.
• Ocena punktowa: Jądro przydziela oom_score i zamyka procesy zajmujące dużo pamięci.
• Uznanie: Informacje na ten temat można znaleźć w dmesg z komunikatami „Out of memory“ i „Killed process“.
• System sterowaniaZ oom_score_adj Ustalam priorytety usług w oparciu o ich znaczenie.
• Zapobieganie: Monitorowanie, limity, strategia swapowa i analiza wycieków zapobiegają brutalnym zabójstwom.

Czym jest OOM Killer w jądrze systemu Linux?

OOM Killer to ostatnia Linia bezpieczeństwa jądra i kończy procesy, gdy nie ma już dostępnych stron pamięci. Postrzegam to jako kontrolowane wyłączenie awaryjne, które zapobiega całkowitej awarii i natychmiast zwalnia pamięć RAM. Wcześniej system próbuje przenieść strony do pamięci wymiany lub opróżnić pamięć podręczną, ale przy utrzymującym się obciążeniu pozostaje już tylko radykalne rozwiązanie. W logach rozpoznaję ten moment po wpisach typu „Out of memory“ i „Killed process“, często którym towarzyszy sygnał SIGKILL. Funkcja ta jest domyślnie włączona i działa automatycznie, co w środowiskach produkcyjnych często powoduje nieprzyjemne niespodzianki, gdy ważne usługi znikają bez ostrzeżenia.

Kiedy uruchamia się ten mechanizm?

Zdarzenia OOM występują, gdy fizyczna pamięć RAM jest prawie całkowicie zajęta, obszar wymiany nie zapewnia już bufora, a żądania dotyczące nowych stron kończą się niepowodzeniem. W tej sytuacji jądro ocenia, czy możliwe jest odzyskanie pamięci z Pamięć podręczna strony i dopóki wymiana pamięci jeszcze pomaga, uruchamia „zabójcę” dopiero w sytuacji beznadziejnej. Krótkotrwałe skoki obciążenia nie uruchamiają tego mechanizmu bezpośrednio; potrzebna jest długotrwała presja i daremne próby zwolnienia pamięci. W analizie pomaga mi spojrzenie na RSS, wykorzystanie pamięci wymiany, udział pamięci podręcznej stron oraz przydziały na grupę kontrolną. Kto chce głębiej zrozumieć, jak działa wypieranie pamięci podręcznej, może zapoznać się z podstawami dotyczącymi Usuwanie danych z pamięci podręcznej stron przejrzeć i zmierzyć efekty we własnym systemie.

W jaki sposób jądro wybiera „ofiarę“?

Wybór odbywa się zgodnie z Ocena punktowa, w którym Linux jako oom_score obliczane dla każdego procesu. Duży udział w całkowitej pamięci, duża ilość pamięci RSS oraz niekrytyczna rola prowadzą do wyższego wyniku. Procesy związane z systemem, takie jak init, otrzymują obniżkę, podczas gdy procesy robocze lub pamięci podręczne, które zużywają dużo pamięci, często zajmują czołowe pozycje. Poprzez oom_score_adj mogę celowo zmienić wynik i w ten sposób sterować łańcuchem ofiar. Zazwyczaj jądro kończy proces o najwyższym wyniku za pomocą sygnału SIGKILL, aby jednym ruchem zwolnić jak najwięcej pamięci RAM.

Rozpoznawanie śladów: logi i sygnały

Po nagłym zakończeniu pracy najpierw sprawdzam dmesg oraz logi jądra. Jeśli pojawiają się tam komunikaty „Out of memory“ i „Killed process“, zapisuję PID, nazwę procesu, użytkownika oraz obliczony wynik. Często w samej aplikacji brakuje logu błędów, ponieważ sygnał SIGKILL nie pozwala na przeprowadzenie fazy sprzątania. Porównuję ten moment z danymi z monitoringu, aby prześledzić wzrost zużycia pamięci RAM, przestrzeni wymiany i RSS dla każdego procesu. W ten sposób niezawodnie i szybko identyfikuję wycieki pamięci, zbyt duże sterty lub brakujące limity.

Zyskaj kontrolę dzięki oom_score i oom_score_adj

Każdy proces posiada w /proc/[PID]/oom_score aktualny Wartość ze względu na jego sytuację zagrożenia. Z /proc/[PID]/oom_score_adj zmniejszam lub zwiększam prawdopodobieństwo, że jądro zakończy ten proces. Usługi krytyczne, takie jak bazy danych, chronię za pomocą ujemnego parametru Adj, natomiast mniej istotne procesy robocze ustawiam jako „poświęcalne“ za pomocą dodatniego parametru Adj. Zmiana działa natychmiast, co jest szczególnie przydatne podczas wdrażania aktualizacji lub testów obciążeniowych. W ten sposób przekształcam nieprzewidywalny mechanizm awaryjny w narzędzie, które działa zgodnie z moimi priorytetami.

Typowe scenariusze hostingowe w warunkach ograniczonej przestrzeni dyskowej

W środowiskach, w których występuje wiele kontenerów, baz danych i pamięci podręcznych, szczególnie często spotykam się z mechanizmem OOM Killer. Baza danych, która rośnie w sposób niekontrolowany, wypiera inne usługi z RAM i prowadzi do poważnych awarii. Wycieki pamięci w aplikacjach internetowych powodują narastanie obciążenia przez wiele godzin, aż do momentu, gdy żadne odzyskiwanie pamięci już nie pomaga. Zbyt hojne limity kontenerów na zbyt małym serwerze dodatkowo pogarszają sytuację. Kto zna te schematy, ustawia alarmy z odpowiednim wyprzedzeniem i podejmuje działania, zanim problem przejmie kontrolę.

Najlepsze praktyki pozwalające uniknąć brutalnych zabójstw

Realistycznie planuję pamięć, uwzględniam rezerwę na obciążenia szczytowe i ustalam jasne limity dla poszczególnych usług. Monitorowanie rejestruje dla każdego procesu RSS, wykorzystanie pamięci wymiany oraz oom_score, aby ostrzeżenia pojawiały się przed wystąpieniem sytuacji krytycznej. W konfiguracjach kontenerowych ustalam limity cgroup, aby poszczególne usługi nie dominowały nad hostem. Rozsądna strategia swapowania pozwala złagodzić szczyty obciążenia bez trwałego spowolnienia systemu. Aby lepiej zrozumieć te zagadnienia i ułatwić planowanie, korzystam z praktycznych przewodników dotyczących zarządzanie pamięcią wirtualną, aby obciążenia miały zapewniony odpowiedni przepływ powietrza.

Ustrukturyzowany przebieg postępowania w przypadku wystąpienia błędu OOM

Po tym zdarzeniu najpierw pobieram wpisy z dziennika dmesg oraz plik kern.log i porządkuję je chronologicznie. W narzędziu monitorującym sprawdzam wykresy dotyczące pamięci RAM, obszaru swap, RSS i pamięci podręcznej stron, aby prześledzić przebieg obciążenia. Następnie sprawdzam limity ulimits, limity Cgroup i kontenerów, a także parametry aplikacji, takie jak sterty JVM. Na koniec dostosowuję oom_score_adj aby to, co ważniejsze, pozostało, a to, co zbędne, zostało usunięte w pierwszej kolejności. Na koniec usuwam przyczynę: naprawiam wycieki, ograniczam pamięć podręczną, zmniejszam równoległość i prawidłowo dobieram pojemność.

Szczególne cechy środowisk VPS i chmury

W przypadku maszyn wirtualnych dochodzi jeszcze drugi poziom ograniczeń, wynikający na przykład z działania hiperwizora lub systemu orkiestracji. Dlatego znam przydzieloną RAM-Dokładnie określ ilość i odpowiednio ustaw limity Kubernetes lub kontenerów. Mechanizm OOM Killer w systemie Linux nadal działa zgodnie z opisem, jednak mechanizmy dostawcy mogą powodować dodatkowe ograniczenia wydajności. Szczególnie w przypadku dużej liczby podów pomocne jest jasne ustalenie priorytetów: ważne wdrożenia otrzymują rezerwy, natomiast zadania o mniejszym znaczeniu są wykonywane z mniejszymi zasobami. Dokumentacja dostawcy platformy oraz własne testy pozwalają uniknąć niespodzianek podczas pracy produkcyjnej.

Precyzyjna regulacja pamięci: overcommit, swappiness i pamięci podręczne

Kto chce opanować ryzyko związane z OOM, powinien rozważnie dostosowywać parametry jądra i rozumieć ich wzajemne oddziaływanie. vm.overcommit_memory oraz vm.overcommit_ratio kontrolować, na ile Linux zezwala na hojne przydziały pamięci wirtualnej, podczas gdy vm.swappiness wpływa na stosunek swapowania do odzyskiwania. vm.vfs_cache_pressure reguluje poziom agresywności przy zwalnianiu pamięci podręcznej i-nodów i d-entrów, wpływając w ten sposób bezpośrednio na dostępną przestrzeń pamięci podręcznej stron. Zawsze sprawdzam efekty w realistycznych warunkach Obciążenie, rejestruj wskaźniki i wprowadzaj zmiany stopniowo. Jeśli chodzi o kontekst i scenariusze, warto zapoznać się z Przekroczenie pojemności pamięci, aby rozsądnie dobrać własne ustawienia domyślne.

Parametr/wskaźnik	Rola w systemie	Gdzie sprawdzić	Typowy kierunek
Wolna pamięć RAM	Zabezpieczenie przed trudnymi zabójstwami	free, /proc/meminfo	Zadbać o wystarczające rezerwy
Korzystanie z swapów	Amortyzatory do Peaks	free, vmstat	Niski do umiarkowanego
vm.overcommit_memory	Przydział wirtualny	sysctl	0/2 w zależności od ryzyka
vm.overcommit_ratio	Limit dla overcommit	sysctl	Dopasowane do obciążenia
vm.swappiness	Skłonność do swapów	sysctl	Średnia zamiast wartości skrajnej
vm.vfs_cache_pressure	Odzyskiwanie pamięci podręcznej VFS	sysctl	100 jako punkt wyjścia

Globalny OOM a Cgroup-OOM: co dokładnie ulega zakończeniu?

W nowoczesnych konfiguracjach z wykorzystaniem Cgroups (v1/v2) zdarzenie OOM może lokalny w grupie pamięci (Memory-Cgroup) lub Globalny uruchamiane na hoście. Jeśli proces działa w kontenerze ze ścisłym memory.max (lub limit), jądro zazwyczaj kończy tylko procesy w tej grupie C („memcg OOM“), podczas gdy cały system nadal działa. W dmesg rozpoznaję to po takich wskazówkach, jak constraint=CONSTRAINT_MEMCG lub odniesienia do danej grupy C. Dopiero gdy żadna grupa C nie może już udostępnić pamięci RAM, a pamięć globalna zostanie wyczerpana, uruchamia się obejmujące cały system OOM Killer. Aby zapewnić stabilność, ważne jest dla mnie ustawienie limitów w taki sposób, aby usługa przekraczająca limity zawiodła w swojej grupie Cgroup, zamiast powodować awarię całego hosta. W Cgroups v2 mogę dodatkowo za pomocą memory.high ustawić łagodne ograniczenia i za pomocą memory.oom.group określić, że w razie awarii cała grupa zostanie zakończona – jest to rozwiązanie bardziej przejrzyste niż częściowo działający proces resztkowy.

Narzędzia i wskaźniki w praktyce

Aby szybko ustalić przyczyny, gromadzę dane liczbowe, które można odtworzyć. Te narzędzia regularnie mi w tym pomagają:

• Przegląd procesów: ps -eo pid,ppid,cmd,%mem,rss --sort=-rss | head wskazuje programy, które zajmują dużo pamięci.
• Podsumowanie Smaps: cat /proc//smaps_rollup zwraca wartości RSS/PSS/Swap procesu bez konieczności długiego parsowania.
• pmap: pmap -x | sort -nrk3 | head wyświetla mapowania wraz z rozmiarem i RSS, co sprawdza się w przypadku stert i dużych segmentów.
• Wykorzystanie płyt: slabtop -o pokazuje pamięci podręczne jądra, które mogą się powiększać przy dużym obciążeniu.
• Ciśnienie w układzie: vmstat 1 oraz sar -r 1 przedstawiają kontekst dotyczący paginacji, operacji swap-I/O oraz zwolnień pamięci.
• Statystyki cgroupów: W wersji 2 sprawdzam /sys/fs/cgroup/memory.current, memory.swap.current oraz memory.stat danego serwisu.

Wygodne przeglądanie śladów OOM #
dmesg -T | egrep -i 'out of memory|oom-kill|killed process'

# Sortowanie najlepszych kandydatów według oom_score
for p in /proc/[0-9]*; do
  pid=${p##*/}
  [ -r "$p/oom_score" ] || continue
  printf "%6s  %5s  %-30s\n" \
    "$(cat $p/oom_score)" \
    "$(cat $p/oom_score_adj 2>/dev/null || echo 0)" \
    "$(tr -d '\0' < $p/comm)"
done | sort -nr | head -n 20

Jeśli wielokrotnie pojawiają się komunikaty OOM, dokumentuję je Linia bazowa wartości te w warunkach normalnej pracy i porównaj je z danymi z okresu zdarzenia. Odchylenia od razu rzucają się w oczy, na przykład niekontrolowany wzrost PSS lub nieproporcjonalnie duże spadki.

Systemd, kontenery i koordynacja: precyzyjne sterowanie

W systemd ustawiam priorytety i limity zadeklarowane w plikach Unit:

[Usługa]
# – ochrona procesu lub umożliwienie jego zakończenia
OOMScoreAdjust=-900

# – twarde/miękkie limity pamięci (cgroup v2)
MemoryMax=8G
MemoryHigh=6G
# Opcjonalnie: Ograniczenie pamięci wymiany
MemorySwapMax=2G

# Zachowanie w przypadku OOM w systemd
# (np. wymuszenie ponownego uruchomienia)
Restart=on-failure
RestartSec=5

W środowiskach kontenerowych dbam o jasno określone limity dla poszczególnych usług. Ważne jest dla mnie rozróżnienie między Żądanie (planowana rezerwacja) oraz Limit (sztywny limit górny). Kontenery z odpowiednimi żądaniami/limitami otrzymują lepsze oceny QoS; obciążenia typu „BestEffort“ są narażone na błąd OOM. Szczegół z praktyki: jeśli jądro zamyka kontener z powodu błędu Cgroup OOM, często widzę kod wyjścia 137 oraz wydarzenia z OOMKilled; w host‑dmesg można to ze sobą powiązać. W klastrach produkcyjnych planuję wdrożenia krytyczne jako „Guaranteed“, podczas gdy zadania wsadowe celowo działają w krótszym czasie i w ten sposób ustępują miejsca jako pierwsze.

Szczegóły dotyczące jądra: OOM Reaper, THP i fragmentacja

Po zabiciu przeciwnika OOM Reaper: wątek jądra jak najszybciej usuwa mapowanie pamięci procesu ofiary, aby pamięć RAM została faktycznie zwolniona. To wyjaśnia, dlaczego pamięć czasami dopiero do widocznie powraca w wpisie Kille. Równolegle można Kompaktowanie pamięci napotyka ograniczenia – jeśli pamięć RAM jest silnie fragmentowana, brakuje spójnych obszarów na duże alokacje (na przykład przy użyciu Transparent Huge Pages, THP). THP zapewnia wysoką wydajność, ale pod obciążeniem może utrudniać przydzielanie pamięci. W przypadku obciążeń, w których opóźnienia mają kluczowe znaczenie, wyłączam lub ograniczam THP na próbę i mierzę skutki tych zmian.

Kolejnym czynnikiem są Pamięci podręczne typu slab oraz pamięć podręczna stron: w przypadku obciążeń wymagających intensywnej obsługi wejścia/wyjścia pamięci te znacznie się powiększają. Dzięki vm.vfs_cache_pressure a dzięki ukierunkowanemu odzyskiwaniu danych można regulować ich udział; masowe opróżnianie (Drop-Caches) stosuję co najwyżej jako narzędzie diagnostyczne, a nie jako trwałe rozwiązanie. Ponadto zwracam uwagę na NUMA: Jeśli węzeł pamięci jest zapełniony, proces w tej strefie NUMA może zakończyć się niepowodzeniem, mimo że w pamięci RAM ogólnej jest wolne miejsce. Odpowiednie komunikaty pojawiają się również w logach jądra.

Pogłębienie wiedzy na temat strategii swapowania: swappiness, ZRAM/Zswap, budżet operacji wejścia/wyjścia

Swap nie jest czymś złym, lecz Amortyzatory. Najważniejsze jest, aby mądrze z niego korzystać. Dzięki vm.swappiness reguluję, jak wcześnie jądro zaczyna korzystać z pamięci wymiany. Zbyt niskie wartości powodują, że pamięć podręczna stron dominuje i mogą wcześniej wywołać błędy OOM; zbyt wysokie wartości przenoszą obciążenie na operacje wejścia/wyjścia pamięci wymiany i spowalniają system. Na niewielkich serwerach chętnie korzystam z ZRAM lub Zswap, aby utworzyć skompresowany bufor, który przejmuje szczyty obciążenia bez przeciążania dysku. Należy jednak pamiętać: pamięć wymiany nie zastępuje brakującej pojemności. Pozwala jedynie zyskać czas, dzięki czemu mechanizm OOM-Killer nie musi w ogóle zadziałać.

Przypadki szczególne: mlock, RLIMITS, pułapki związane z overcommitem

Niektóre warunki brzegowe zwiększają ryzyko wystąpienia błędu OOM lub zmieniają zachowanie:

• Zablokowana pamięć: Procesy, które odbywają się za pośrednictwem mlock() Przypinając strony, odbierasz je Reclaimowi. Przy wysokim wskaźniku można spowolnić tempo Reapera.
• RLimits: RLIMIT_AS oraz RLIMIT_RSS ustalają limity dla każdego procesu i zapobiegają nadmiernemu rozrostowi poszczególnych usług – to jeden z elementów zapobiegających wystąpieniu błędów OOM.
• Nadmierne zaangażowanie: Zbyt hojne ustawienia overcommit pozwalają na utworzenie dużej przestrzeni adresowej wirtualnej, której później nie da się pokryć fizycznie. Właśnie szczytowe obciążenia związane z alokacją pamięci przez wiele wątków prowadzą wówczas jednocześnie do błędów alokacji i przyspieszają wystąpienie zdarzeń OOM.
• panic_on_oom: W przypadku systemów o bardzo wysokim poziomie krytyczności istnieje możliwość zareagowania na sytuację OOM poprzez wywołanie paniki jądra. Ma to sens jedynie w ściśle określonych scenariuszach zapewnienia wysokiej dostępności (HA), a w pozostałych przypadkach przynosi efekt przeciwny do zamierzonego.
• „Nie do zabicia“ to ryzykowne: oom_score_adj=-1000 Chociaż chroni przed „killerem”, może jednak zablokować cały system. Używam tego rozwiązania wyłącznie w przypadku absolutnie niezbędnych, niewielkich procesów (np. init), a nie w przypadku usług serwerowych wymagających dużej ilości pamięci.

W praktyce: ustalanie priorytetów i zabezpieczanie zmian

W zespole definiuję Ranking usług: co musi pozostać, a co można wyeliminować w pierwszej kolejności? Ten porządek przekładam na oom_score_adj, limity Cgroup oraz (tam, gdzie są dostępne) zasady restartowania. Zmiany są wprowadzane jako kod do manifestów jednostek lub wdrożeń, wraz z punktami pomiarowymi w systemie monitorowania. W testach obciążeniowych symuluję obciążenie pamięci: zwiększam ilość danych, podnoszę poziom równoległości, pozwalam na rozrost pamięci podręcznej – i obserwuję, czy to właśnie procesy, które można „poświęcić“, ulegają awarii, podczas gdy kluczowe elementy pozostają aktywne. Dopiero gdy proces ten działa w sposób powtarzalny, konfiguracja trafia do środowiska produkcyjnego.

Wzory diagnostyczne: rozróżnianie wycieków, stert i fragmentacji

Nie każdy wzrost liczby subskrypcji RSS oznacza wyciek informacji. Systematycznie rozróżniam:

• Wyciek: RSS/PSS rosną monotonicznie, nawet bez wzrostu obciążenia; smaps_rollup rośnie równomiernie, cykle GC (w przypadku zarządzanych środowisk uruchomieniowych) nie pomagają.
• Szczyty sterty: RSS rośnie wraz z obciążeniem, a następnie ponownie spada; pamięć podręczna stron wykazuje korelację z wzorcami operacji wejścia/wyjścia.
• Fragmentacja: Wystarczająca ilość wolnej pamięci RAM, ale nie udaje się przydzielić dużych bloków; logi wskazują na próby kompaktowania, przydziały THP częściej kończą się niepowodzeniem.

W przypadku obciążeń JVM lub Node sprawdzam, czy środowisko uruchomieniowe rozpoznaje limity kontenerów. Zbyt duże rozmiary sterty lub pamięci podręcznej kodu JIT mogą przekroczyć limit i spowodować błędy OOM, mimo że pozornie jest jeszcze wolne miejsce. Ustawiam rozmiary sterty wraz z nadmiarem tak, aby poniżej MemoryMax pozostaje jeszcze bufor na części natywne, stosy wątków i pamięć podręczną stron.

Podręcznik dotyczący wdrażania i testów obciążeniowych w warunkach ograniczonej pamięci

1. Pomiar wartości bazowej: RSS/PSS na usługę, udziały w slabach, wskaźnik swapowania, rozmiary pamięci podręcznej, oom_score.
2. Wyznaczanie granic: Pamięć – maksymalna/najwyższa lub zdefiniować limity kontenerów z realistycznym marginesem bezpieczeństwa; OOMScoreAdjust przydzielone według priorytetu.
3. Wywoływać stres: objętość danych, współbieżność, wzrost pamięci podręcznej; zanotować profile operacji wejścia/wyjścia i procesora.
4. Obserwować: dmesg -T, wskaźniki hosta i grup C; sprawdź, który z nich pierwszy znajdzie się pod presją.
5. Iteracja: Wyregulować limity/Adj, dostosować współczynnik swappiness, przetestować ustawienia THP, ponownie wykonać pomiar.
6. Automatyzacja: Wdrożenie testów w ramach CI/CD, alerty przy przekroczeniu wartości progowych, zasady ponownego uruchamiania usług, które uległy awarii.

Krótko mówiąc: konkretne działania

Rozumiem, że OOM Killer to Sygnał, że mój system miał wcześniej zbyt mały bufor lub procesy miały nieprawidłowe priorytety. Dzięki monitorowaniu, realistycznym limitom, przemyślanej strategii swapowania oraz świadomemu wykorzystaniu oom_score_adj Znacznie ograniczam gwałtowne wyłączenia. W środowiskach produkcyjnych chronię kluczowe procesy, sprawiam, że usługi drugorzędne stają się zbędne, i monitoruję każdą zmianę. W przypadku kontenerów ściśle ustalam limity Cgroup, aby żadna usługa nie blokowała całego systemu hosta. Kto zachowuje tę dyscyplinę, zapewnia responsywność systemu Linux nawet pod presją i znacznie skraca czas potrzebny do zidentyfikowania przyczyny problemu.