Kontajner sa reštartuje. Je príčinou nedostatok pamäte?

Zachyťte stav skôr, než sa stratí súvislosť

Použite docker inspect --format '{{.Id}} {{json .State}}' web, pričom web nahraďte názvom kontajnera. Zaznamenajte OOMKilled, ExitCode, StartedAt a FinishedAt spolu s jeho ID. OOMKilled sa vzťahuje na obdobie od posledného štartu; nie je archívom všetkých starších pádov. Výpis uložte s časom pozorovania a porovnajte ho s konkrétnym zlyhaním služby.

Samotný exit kód 137 nedokazuje OOM. Môže súvisieť so SIGKILL aj pri ručnom ukončení procesu alebo použití docker kill. V časovej osi preto preverte tiež nasadenie a administrátorské zásahy. Zvyšovať limit iba podľa čísla vo výpise znamená meniť konfiguráciu bez potvrdenej príčiny. Najprv určte, ktorý beh kontajnera práve skúmate.

Spojte udalosti Dockeru so záznamami jadra

V docker events vyhľadajte pre príslušné ID udalosti oom, die a start. Parametre --since a --until ohraničia obdobie; pri časových značkách uveďte pásmo. História udalostí je obmedzená, preto dôležité záznamy priebežne ukladajte. Neprítomnosť starého záznamu sama nevyvracia udalosť. Časy porovnávajte s požiadavkou, ktorá zlyhala, nie iba s aktuálnym stavom kontajnera.

Na hostiteľovi so systemd použite journalctl -k na prehľad správ jadra. Štandardne sa tým vyberie aktuálny boot; po reštarte hostiteľa určte správny boot a časové okno. Pri OOM zázname porovnajte proces, čas a uvedený kontext s dotknutým kontajnerom. Ak údaje nemáte alebo k nim nemáte oprávnenie, označte príčinu ako nepotvrdenú a doplňte zber pre ďalší výskyt.

Porovnajte limit kontajnera aj stav hostiteľa

Docker umožňuje obmedziť pamäť cez --memory. Voľná RAM hostiteľa preto sama nepotvrdzuje dostatočný limit kontajnera. V jeho správnej cgroup v2 porovnajte memory.max a memory.current: tvrdý limit a aktuálnu spotrebu vrátane potomkov. V memory.events.local položka oom_kill počíta procesy skupiny ukončené OOM killerom. Sama nerozlíši lokálny a celosystémový nedostatok pamäte; vráťte sa aj k správam jadra.

Priebežný prehľad poskytne docker stats --no-stream web. Na Linuxe tento výpis odpočítava časť cache, preto jeho číslo nemusí byť zhodné so surovým údajom pamäťového radiča. Ukladajte trend pred incidentom a označte zdroj metriky. Jedna vzorka po návrate služby nevysvetlí jej predchádzajúcu špičku. Pre porovnanie pred zmenou a po nej používajte rovnaké meranie.

Opravu overte rovnakou prácou, ktorá zlyhávala

V oddelenom prostredí zopakujte zodpovedajúci objem dát a súbeh operácií. Preverte, či pomôže menšia dávka, obmedzenie súbehu alebo oprava správy pamäte v aplikácii. Rastúca spotreba je podnet na profilovanie, nie automatický dôkaz úniku. Ak treba zvýšiť limit, najprv posúďte kapacitu hostiteľa a ostatné služby. Vypnutie OOM ochrany nepoužívajte ako náhradu diagnostiky.

Reštartovacia politika môže kontajner spustiť znova, no neodstráni príčinu jeho ukončenia. Po oprave sledujte opakované pády, pamäťový trend a výsledok pôvodnej operácie. Externú kontrolu dostupnosti doplňte internými údajmi o pamäti a reštartoch. Za potvrdenie opravy považujte aj úspešné dokončenie spracovania súboru pri porovnateľnej záťaži, nie iba opätovné spustenie procesu.

• Zachyťte ID kontajnera, stav a čas dotknutého behu.
• Porovnajte udalosti Dockeru so záznamami jadra.
• Overte limit, trend spotreby a kapacitu hostiteľa.
• Zopakujte pôvodnú operáciu a sledujte ďalšie pády.