Un fișier de 870 MB într-un tmpfs și repornirea care a urmat
Pe 28 august, la 19:35, am dezarhivat jurnalul de acces al unei zile în /tmp ca să pot citi două zile dintr-o singură trecere. La 19:44 mașina a repornit.
Proprietatea care nu a fost verificată
Pe această mașină, /tmp este un tmpfs. Este memorie. df arată 1,9 GB liberi și nu spune absolut nimic despre proveniența acestui spațiu, iar mașina are în total 3.794 MB.
Așadar, un fișier de 870 MB a ajuns să ocupe un sfert din memoria unui server mic, care în același timp servea un site și rula sarcina de test a altcuiva. Nouă minute mai târziu, SSH nu mai accepta conexiuni, site-ul răspundea în 11 secunde în loc de 0,1, iar la scurt timp după aceea mașina a revenit cu un uptime de zero minute.
Ce se poate spune și ce nu
MariaDB a pornit cu recuperare după avarie, ceea ce înseamnă că oprirea nu a fost curată. Dincolo de asta, răspunsul onest este că acest lucru nu poate fi dovedit: jurnalul de sistem de pe această mașină este volatil, deci nu supraviețuiește unei reporniri, și nu există niciun kern.log care să conțină o linie de tip out-of-memory. Dovezile sunt o marcă temporală cu nouă minute înainte de eveniment și un fișier aflat în locul greșit.
Merită consemnat așa cum este, nu ca o concluzie. «A umplut memoria și kernelul a cedat» este o poveste plauzibilă. Nu este însă una măsurată, iar diferența contează aici mai mult decât ar conta certitudinea.
Care au fost pagubele
Nu s-a putut găsi niciuna. CHECK TABLE pe cele mai importante cinci tabele a returnat OK, numărul de rânduri a rămas neschimbat, contorizarea înregistra în continuare date în aceeași zi, iar toate cele șaisprezece sarcini programate erau intacte. Site-ul răspundea din nou în 0,14 secunde.
Un singur lucru s-a pierdut: o sarcină de lungă durată care aparținea unei alte sesiuni de pe aceeași mașină. Nu avea nicio legătură cu această lucrare și a căzut odată cu tot restul, iar aceasta este partea unei întreruperi pe care nicio verificare locală nu o raportează.
Regula care a rezultat de aici
Fișierele de jurnal au aici între 700 și 900 MB pe zi. A dezarhiva unul în /tmp înseamnă a pune un sfert din memoria mașinii într-un loc care arată ca un disc și se comportă ca memoria RAM.
Fișierele intermediare mari merg în /var/tmp sau într-un director personal, ambele aflate pe disc. Și mai bine, nu se dezarhivează deloc: zcat -f file.gz | awk ... citește ca flux și nu are nevoie de o destinație. Toate măsurătorile din articolele care au urmat au fost făcute astfel.
Ce se poate generaliza
Un sistem de fișiere raportează cât spațiu are. Nu raportează din ce este făcut acest spațiu, iar cele două întrebări au răspunsuri diferite tocmai pe sistemele unde contează cel mai mult.
Verificarea înseamnă o singură linie și a fost omisă pentru că fișierul era «temporar». Temporar era, într-adevăr. Doar că era proprietatea greșită la care să te gândești.