Kontaktovat podporu

Odpovíme e-mailem, obvykle do dvou dnů.

Google reCAPTCHA kontroluje toto odeslání kvůli ochraně před zneužitím; data se přitom předávají společnosti Google. Skript se načte až při otevření tohoto formuláře.

← Všechny články

Soubor o 870 MB v tmpfs a restart, který následoval

Dne 28. srpna v 19:35 jsem rozbalil přístupový log za jeden den do /tmp tak, abych mohl přečíst dva dny jedním průchodem. V 19:44 se stroj restartoval.

co stroj má a co zabral jeden soubor 3 794 MB paměti, z toho /tmp pojme 1 900 870 MB zapsáno v 19:35 19:35 — log za den rozbalen do /tmp, aby šly číst dva dny najednou 19:44 — SSH přestává odpovídat, web odpovídá 11 s místo 0,1 s 19:47 — stroj je zpět, uptime 0 minut MariaDB startuje s obnovou po pádu: vypnutí nebylo čisté journal restart nepřežije, takže to nejde dokázat — jen datovat

Vlastnost, která se nezkontrolovala

Na tomto stroji je /tmp typu tmpfs. Je to paměť. df ukazuje 1,9 GB volného místa a neříká vůbec nic o tom, odkud se to místo bere, přičemž stroj má celkem 3 794 MB.

Soubor o 870 MB tedy skončil ve čtvrtině paměti malého serveru, který zároveň obsluhoval web a běžela na něm cizí testovací úloha. O devět minut později SSH přestalo přijímat spojení, web odpovídal za 11 sekund místo 0,1 a krátce nato byl zpět s uptime nula minut.

Co se dá říct a co ne

MariaDB naběhla s obnovou po pádu, což znamená, že vypnutí nebylo čisté. Nad rámec toho zní poctivá odpověď tak, že to nejde dokázat: journal je na tomto stroji nestálý, takže restart nepřežije, a neexistuje žádný kern.log s řádkem o nedostatku paměti. Důkazem je časový údaj devět minut před událostí a soubor na špatném místě.

To stojí za to zapsat tak, jak to je, a ne jako závěr. «Zaplnilo to paměť a jádro to vzdalo» je věrohodný příběh. Není to příběh změřený a ten rozdíl je tu důležitější, než by byla jistota.

Jaká byla škoda

Žádná, kterou by šlo najít. CHECK TABLE na pěti nejdůležitějších tabulkách vrátil OK, počty řádků se nezměnily, počítání ještě týž den zaznamenávalo a všech šestnáct naplánovaných úloh bylo v pořádku. Web zase odpovídal za 0,14 sekundy.

Jedna věc se ztratila: dlouho běžící úloha jiné relace na stejném stroji. S touto prací neměla nic společného a spadla se vším ostatním, což je ta část výpadku, kterou žádná místní kontrola nenahlásí.

Pravidlo, které z toho vzešlo

Logy tu mají 700 až 900 MB denně. Rozbalit jeden do /tmp znamená uložit čtvrtinu paměti stroje někam, co vypadá jako disk a chová se jako RAM.

Velké mezisoubory patří do /var/tmp nebo do domovského adresáře; obojí leží na disku. Ještě lepší je nerozbalovat je vůbec: zcat -f file.gz | awk ... čte proudově a žádný cíl nepotřebuje. Tak bylo pořízeno každé měření v následujících článcích.

Co z toho plyne obecně

Souborový systém hlásí, kolik má místa. Nehlásí, z čeho to místo je, a obě otázky mají různé odpovědi právě na systémech, kde na tom záleží nejvíc.

Kontrola má jeden řádek a vynechala se, protože soubor byl «dočasný». Dočasný opravdu byl. Jen to byla špatná vlastnost, na kterou myslet.

Reklama