Keď má domáci server desiatky kontajnerov: prečo napájanie a I/O nie sú detail
Pokračovanie sľubu z článku o Frigate na Orange Pi 5 — kde to bolo zámerne len jednou vetou, tu je celý príbeh.
Prečo tento článok vznikol
Keď na jednom malom SBC beží dvadsaťdeväť docker kontajnerov naraz — media stack, domáca automatizácia, AI kamerová detekcia, vlastné appky — je lákavé pri akomkoľvek probléme hľadať príčinu v softvéri. Veď je toho tam toľko, že niečo muselo prekypieť.
Presne to sa stalo aj mne. Server bol občas nedostupný, po fyzickom reštarte znova v poriadku, a prvé podozrenie smerovalo na kontajnery. Skutočná príčina bola nakoniec dvojitá — a ani jedna z nich nebola v Dockeri.
Prvý príznak: kernel panic, ktorý vyzeral ako softvér
Server prestal odpovedať. Fotka konzoly ukázala:
Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
Po fyzickom power-cycle bol server späť. Prvá kontrola ukázala niečo presvedčivé: dve služby v nekonečnej reštart-slučke — jedna appka, ktorej port už držal iný proces, a druhá čakajúca na USB zariadenie, ktoré nebolo pripojené. Obe reštartovali každých päť sekúnd, spolu už niekoľko tisíckrát. Load systému klesol z 15 na 8 hneď po ich vypnutí.
Vyzeralo to vyriešené. Nebolo.
Keď sa zdanlivá príčina nepotvrdí, treba ísť hlbšie
O pár dní neskôr panic prišiel znova — bez tých dvoch služieb. Čas na systematickejšie hľadanie:
- Pamäťová stopa (pstore) bola prázdna — kernel síce má
CONFIG_PSTORE_RAM=y, ale device tree nemal vyhradenú pamäť na uloženie panic logu. Takže po každom páde zmizol presne ten záznam, ktorý by najviac pomohol. - História kernelových verzií naznačovala koreláciu s jednou konkrétnou vetvou, no po prepnutí späť na pôvodný kernel sa pády opakovali aj tam — takže to nebol kernel sám osebe.
- SMART dáta oboch diskov boli čisté, žiadne rastúce chyby, žiadny dôkaz čerstvého zlyhania disku.
- USB topológia ukázala, že oba disky (systémový aj dátový) visia na tom istom USB3 hube pod jedným radičom — potenciálny zdroj kontencie, ale zatiaľ len hypotéza.
Až fyzická kontrola fotky napájacieho adaptéra priniesla presvedčivý nález: dvojportový PD adaptér síce mal na štítku veľké „30 W", ale pri 5 V (napätí, ktoré SBC skutočne potrebuje) dokázal dodať len 5V/3A — 15 W, a pri súbežnom použití oboch portov ešte menej. Doska pritom pri špičkách vyžaduje až 5V/4A, teda 20 W. Veľké číslo na štítku platilo len pri vyšších napätiach z USB-C PD profilov, ktoré sa na 5V napájanie jednodoskového počítača vôbec nevzťahujú.
Presne ten typ detailu, ktorý sa dá pri kúpe ľahko prehliadnuť — adaptér vyzerá dostatočne silný, ale číslo na krabičke a skutočný výkon pri požadovanom napätí sú dve rozdielne veci.
Neveriť dohadu, overiť dátami
Namiesto špekulácie, či je adaptér naozaj vinník, som siahol po dátach, ktoré už beztak existovali — Home Assistant s inteligentnou zásuvkou meral príkon serverovej vetvy dlhodobo. Porovnanie pred a po výmene adaptéra ukázalo presne to, čo teória predpovedala: špičky, ktoré predtým narážali na strop starého zdroja (~15 W), sa po výmene bez problémov zobrazili ako reálnych 12–17 W — nový 27 W/5,1V-5A zdroj mal pri tom stále takmer tretinovú rezervu.
Nový adaptér (rovnaký typ ako oficiálny Raspberry Pi 27W zdroj) sa zapojil, a odvtedy žiadny kernel panic, žiadna undervoltage hláška v logoch. Ako doplnkovú poistku — nie náhradu za skutočnú opravu — som ešte nastavil kernel.panic=15 (automatický reštart namiesto večného zamrznutia) a hardvérový watchdog. Keby sa nabudúce niečo podobné stalo, server sa aspoň sám spamätá, kým sa nájde príčina.
Druhý, nezávislý problém pod tou istou nálepkou „nestabilita"
Tu prichádza časť, ktorá ma prekvapila najviac: aj po výmene adaptéra zostal na stole samostatný problém, ktorý sa predtým skrýval pod rovnakou hlavičkou „nečisté štarty" — pomalý disk.
Databázový kontajner (Joplin/Postgres) mal checkpoint časy, ktoré sa mesiac predtým skokovo zhoršili z 2–9 sekúnd na stabilných 10–12 sekúnd. Benchmark priamo na dátovom disku ukázal fsync okolo 75–100 ms a len 11–13 IOPS pri jednom vlákne — pri súbežnom zaťažení štyrmi procesmi priemer vyskočil na 200 ms, špičky až na 1,5 sekundy. Pre porovnanie, systémový SSD disk na tom istom stroji zvládal rovnaký typ zápisu pri 290 IOPS (cca 3,4 ms na zápis) — asi 25 až 30-krát rýchlejšie.
Dôvod: viacero databázových kontajnerov zapisovalo na pomalší, cez USB pripojený disk, ktorý navyše zdieľal radič s druhým diskom. Riešenie nebolo v tweaknutí parametrov, ale v presune deviatich služieb s vlastnou databázou (Sonarr, Radarr, Prowlarr, Jellyseerr, Bazarr, Navidrome a ďalšie) na rýchlejší systémový SSD. Po presune checkpoint čas klesol na 0,027 sekundy — stovky-násobné zrýchlenie skutočného zápisu na disk.
Kľúčové poučenie z tejto časti: napájanie a I/O boli dva úplne nezávislé problémy, ktoré sa oba prejavovali ako všeobecná „nestabilita systému". Vyriešenie jedného nevyriešilo druhý — a keby som sa zastavil po výmene adaptéra a vyhlásil víťazstvo, databázy by ďalej trpeli pomalými zápismi.
Aj samotné disky si niekedy pýtajú vlastné napájanie
Netýka sa to len jedného SBC — rovnaký princíp sa ukázal aj pri fyzickom externom disku, ktorý slúži ako hlavné úložisko zálohy dát. Pri výkonových špičkách (napríklad keď kamerová AI detekcia bežala súčasne so štyrmi 4K kamerami) server pod záťažou padal, kým disk nešiel cez samostatný napájaný USB hub. Po presune na napájaný hub problém zmizol. Rovnaký vzorec, iný komponent: keď je odber pri špičke vyšší než to, čo daná USB zbernica/port reálne vie dodať, výsledok vyzerá ako softvérová nestabilita, hoci je čisto elektrický.
Čo si z toho odniesť, ak beží veľa služieb na jednom stroji
- Neponáhľaj sa k softvéru ako prvému podozrivému. Reštartujúce sa služby môžu byť príznak zaneprázdneného systému, nie príčina pádu.
- Napájací štítok s veľkým číslom nie je záruka. Over reálny výkon pri napätí, ktoré zariadenie skutočne používa — nie len maximum, ktoré adaptér niekde v inom profile dokáže dodať.
- Ak máš možnosť merať reálny odber (napr. inteligentná zásuvka), použi to. Dáta z týždňa prevádzky sú presvedčivejšie než akákoľvek teória.
- Viacero diskov na jednom USB radiči/hube je kontencia, ktorá čaká na svoju chvíľu. Prejaví sa práve vtedy, keď je záťaž najvyššia — teda presne vtedy, keď to najviac bolí.
- Dva rôzne problémy sa vedia tváriť ako jeden. Systematické vylučovanie (SMART, logy, benchmark, história) je pomalšie než uveriť prvej presvedčivej teórii, ale len tak sa dá s istotou povedať „hotovo".
Ak beží tvoj homelab na podobne malom, ale nabitom stroji — oplatí sa raz za čas prejsť presne tento zoznam, ešte predtým, než ťa k tomu donúti ďalší kernel panic o polnoci.