Chtěl jsme zkusit Immich a první spuštění dopadlo tak, že někdy v noci prostě sestřelil QNAP NAS kde běžel v Dockeru. Při vytváření thumbnailů sežral veškerou dostupnou paměť a NAS zemřel. Tvrdě.
Což je, důležité vědět, opakovaně zdokumentovaná chyba, ale to by člověk před implementací musel aktivně hledat. Ani Codex to “dopředu” neobjevil, až po události, při analýze logů – ale až poté co kontejner dostal omezení paměti i využití CP zároveň s daleko pomalejším během. Po pár hodinách umřel, ale tentokrát jen onen kontejner.
Pak se ještě ukázalo, že Immich nepřežije tvorbu thumbnail pro poškozené JPG/HEIC soubory a jakmile jich chce zpracovat víc po sobě, tak hádejte co. Opět prostě spadne.
Celé je to jedním zásadním poučením. Cokoliv máte v Dockeru, nedávejte tomu k dispozici kompletní paměť a ani kompletní procesor. Protože pokud se ta věc v kontejneru zblázní, tak vyčerpá vše co stroj na kterém máte Docker má k dispozici. A logicky, s 100% vytížení procesoru ten stroj moc fungovat nebude a jakmile dojde paměť, tak to špatně dopadne.
Zásadní věc: kontejner není virtuální počítač
Docker kontejner sice izoluje souborový systém, síť a procesy, ale uvnitř stále běží obyčejné procesy hostitelského systému. Ve výchozím nastavení nemá kontejner omezenou paměť ani procesor a může použít prakticky tolik prostředků, kolik mu hostitelský systém dovolí. Takže:
- kontejner není automaticky „malý virtuální počítač“;
- instalace aplikace do Dockeru sama o sobě nechrání NAS nebo server;
- izolace aplikace neznamená automaticky izolaci spotřeby prostředků;
- chyba uvnitř kontejneru může výrazně ovlivnit vše ostatní na hostiteli.
Zcela jistě a vždy tedy platí, že minimálně nový a nevyzkoušený kontejner nikdy nespouštějte bez limitů, zejména pokud bude něco indexovat, převádět, analyzovat, komprimovat, generovat náhledy nebo zpracovávat velké množství dat.
Ale i to co už máte “vyzkoušené” se vyplatí omezit.
Co se stane, když dojde paměť
Pokud kontejner nemá nastavený limit, může postupně spotřebovat veškerou dostupnou RAM hostitele. Linux pak vyvolá stav Out of Memory a začne ukončovat procesy, aby paměť uvolnil. Nemusí přitom zemřít jen problematická aplikace – zasažen může být Docker, databáze, souborové služby nebo jiný důležitý proces. Docker proto výslovně doporučuje kontejnery paměťově omezovat.
A pozor: Samotný restart NAS (v mém případě) samozřejmě neznamená, že je problém vyřešen. Pokud se kontejner po startu automaticky spustí a pokračuje ve stejné úloze, může systém sestřelit znovu.
Takže je tu ještě další poučení: Nové/nevyzkoušené věci do Dockeru nedávajte s automatických spuštěním po re/startu Dockeru.
Tvrdý limit paměti
Tvrdý limit určuje maximum, přes které se kontejner nemá dostat. Po dosažení limitu už kontejner další paměť nedostane. Výsledkem může být chyba uvnitř aplikace nebo ukončení procesů v kontejneru prostřednictvím OOM mechanismu. To je nepříjemné pro aplikaci, ale zpravidla podstatně lepší než ztráta celého hostitele. Docker označuje –memory jako hard limit.
Praktické doporučení: Tvrdý limit by měl mít každý dlouhodobě běžící kontejner. U nového kontejneru je lepší začít opatrněji a limit později zvýšit než nechat aplikaci při prvním spuštění obsadit všechnu RAM.
Rezervace paměti není skutečná rezervace
Docker nabízí také “–memory-reservation”. Jde o měkký limit, který se projeví při nedostatku paměti nebo soupeření kontejnerů o RAM. Není to záruka, že kontejner 2 GB vždy dostane, ani zákaz použít více. Pro skutečnou ochranu hostitele je nutné nastavit také tvrdý limit.
Rezervace vlastně říká, jaké množství paměti považujete za běžné. Maximum říká, kam až smí kontejner v nejhorším případě dojít.
Pozor na swap
Paměťový limit a swap jsou dvě související, ale odlišné věci. Něco jako
-memory=4g
–memory-swap=4g
znamená 4 GB RAM a žádný další swap. Pokud nastavíte
–memory=4g
–memory-swap=6g
může kontejner použít 4 GB RAM a k tomu až 2 GB swapu. Pokud –memory-swap vynecháte, může Docker při dostupném hostitelském swapu povolit další swap až do výše nastaveného paměťového limitu.
Praktické doporučení: U kritických (NAS) zařízení je často vhodné nastavit memory-swap stejně jako memory, případně povolit jen malou swapovou rezervu. Neomezený swap problém neřeší – pouze může oddálit pád za cenu velmi pomalého systému.
Proč omezit také procesor
Vyčerpání procesoru obvykle nezpůsobí okamžitý pád jako nedostatek paměti. Stroj ale může být prakticky nepoužitelný:
- administrace reaguje se zpožděním
- zpomalí se síťové sdílení
- ostatní kontejnery nedostanou dost času procesoru
- databáze nestíhají odpovídat
- prodlužují se zálohy a systémové úlohy
- NAS může mít problém včas obsloužit RAID, šifrování nebo souborové služby
I tady je k dispozici tvrdý CPU limit, napříkald jako –cpus=2 (povolí využití maximálně dvou logických procesorů) – a logicky musíte vědět kolik jader má vaše zařízení ve výbavě. Můžete použít –cpus=0.5 (prostě půl kapacity jádra).
cpu_shares není tvrdý limit
cpu_shares nebo Compose položka cpu_shares pouze mění relativní prioritu kontejneru vůči jiným kontejnerům. Pokud procesor nikdo jiný nepotřebuje, kontejner může stále použít všechen dostupný výkon. Omezení se projeví až při soupeření o procesor.
Jde i připnutí ke konkrétním jádrům
Pomocí –cpuset-cpus lze určit konkrétní logická CPU, parametr za rovnítkem dostane seznam čísel jader.
Jak určit správné limity
Univerzální číslo neexistuje. Webový server, databáze, mediální server a AI aplikace mají zcela odlišné nároky.
Rozumný postup:
- Zjistěte, kolik paměti a CPU používá samotný hostitel bez daného kontejneru.
- Sledujte běžné systémové služby, zálohy, RAID operace a ostatní kontejnery.
- Nechte hostiteli skutečnou rezervu – nepočítejte pouze rozdíl mezi instalovanou a právě použitou RAM.
- Nový kontejner spusťte s konzervativním limitem.
- Proveďte nejtěžší očekávanou operaci.
- Sledujte paměť, CPU, počet procesů a diskové I/O.
- Limit zvyšujte jen tehdy, pokud aplikace padá kvůli nedostatku prostředků a její spotřeba je jinak stabilní.
Důležité: Součet limitů všech kontejnerů může být vyšší než fyzická RAM. Limity nejsou automatickou rezervací. Pokud deset kontejnerů dostane maximum 4 GB, neznamená to, že čtyřicet gigabajtů skutečně existuje. Při souběžné špičce může být hostitel stále v problémech.
Jak ověřit, že limity opravdu fungují
Základní nástroje je docker stats a případně jakékoliv další software pro správu dockeru. Třeba i povedený terminálový ctop.
dockers stats umí sledovat i jednu konkrétníi aplikaci, stačí přidat jméno kontejneru. A celé to funguje jednoduše:
Uvidíte:
- CPU;
- využitou paměť a limit;
- síťový provoz;
- diskové I/O;
- počet procesů a vláken.
Pokud sloupec MEM USAGE / LIMIT ukazuje jako limit prakticky celou paměť hostitele, kontejner pravděpodobně žádný vlastní limit nemá.
Hodit se může i jednorázový výpis : docker stats –no-stream
Možná vhodn nástroj je i docker inspect opět doplněný o název aplikace (kontejneru). Tady je ale výpisem spousta strukturovaných údajů. Pro zjednodušení pak například:
docker inspect \
–format ‚Memory={{.HostConfig.Memory}} NanoCPUs={{.HostConfig.NanoCpus}} PIDs={{.HostConfig.PidsLimit}}‘ \
moje-aplikace
A samozřejmě nezapomeňte na docker logs kde se můžete podívat na záznamy – ideálně třeba s “–tail 200 moje aplikace”
Restart policy může problém zhoršit
Něco co už bylo řečeno výše. Klasické restart: unless-stopped znamená, že problematický kontejner se bude pokaždé znovu spouštět. A také mo nejspíš znovu dělat problémy.
Takže buď ruční spouštění s restart: „no“ nebo využít on-failure:3, povolí maximálně tři spuštnění po pádech kontejneru.
Počet procesů a vláken
Chybná aplikace může vytvářet tisíce procesů nebo vláken. K ochraně slouží: pids_limit: 512. A pokud v dockers stats vidíte velké číslo v PIDS, tak váš kontejner asi bude pěkně hlasový.
Diskové I/O
Kontejner může mít omezené CPU a RAM, ale přesto zahltit disky. Na NAS bývá právě diskové I/O stejně důležité jako CPU. Docker nabízí také nastavení blkio_config, ale jejich dostupnost a účinnost závisí na platformě, použitém úložišti a kernelu.
A nezapomenout: Logy mohou zaplnit disk
Kontejner v chybové smyčce může produkovat obrovské množství logů. Výchozí ovladač json-file nemá bez konfigurace rotace omezenou maximální velikost jednoho logu. Docker umožňuje nastavit například max-size a max-logging:
driver: local
options:
max-size: „10m“
max-file: „3“
GPU a videopaměť
CPU limit neomezuje využití GPU ani VRAM. U AI, transkódování nebo hardwarového rozpoznávání je nutné sledovat prostředky grafické karty samostatně. Přidělení GPU kontejneru zpravidla určuje, ke kterému zařízení má přístup, nikoliv kolik procent jeho výkonu nebo paměti smí použít.
Nejčastější chyby
- Předpoklad, že Docker automaticky přidělí „rozumné“ množství RAM.
- Omezení pouze CPU, ale nikoliv paměti.
- Použití cpu_shares v domnění, že jde o tvrdý strop.
- Nastavení memory_reservation bez skutečného mem_limit.
- Ignorování swapu.
- Přidělení téměř veškeré fyzické RAM jednomu kontejneru.
- Součet limitů všech kontejnerů výrazně převyšující možnosti hostitele.
- Použití restart: always u neotestované aplikace.
- Zvýšení limitu po každém pádu bez hledání skutečné příčiny.
- Změna Compose souboru následovaná pouze příkazem docker compose restart.
- Spoléhání na deploy.resources, aniž by se ověřilo, zda ho použitá platforma respektuje.
- Sledování pouze běžného provozu, nikoliv prvotního importu nebo indexování.
- Zapomenutí na diskové I/O, PIDs a růst logů.
- Testování velké dávky dat přes noc bez monitoringu a upozornění.
Další tipy týkající se Dockeru
