En fil på 870 MB i en tmpfs och omstarten som följde

Den 28 augusti kl. 19:35 packade jag upp en dags åtkomstlogg i /tmp så att två dagar kunde läsas i ett svep. Kl. 19:44 startade maskinen om.

Egenskapen som inte kontrollerades

På den här maskinen är /tmp en tmpfs. Det är minne. df visar 1,9 GB ledigt och säger ingenting alls om varifrån utrymmet kommer, och maskinen har 3 794 MB totalt.

En fil på 870 MB hamnade alltså i en fjärdedel av minnet på en liten server som samtidigt betjänade en webbplats och körde någon annans testjobb. Nio minuter senare slutade SSH att ta emot anslutningar, webbplatsen svarade på 11 sekunder i stället för 0,1, och strax därefter var den tillbaka med en drifttid på noll minuter.

Vad som kan och inte kan sägas

MariaDB startade med kraschåterställning, vilket betyder att avstängningen inte var ren. Utöver det är det ärliga svaret att detta inte kan bevisas: journalen på den här maskinen är flyktig, så den överlever inte en omstart, och det finns ingen kern.log med en rad om minnesbrist. Beläggen är en tidsstämpel nio minuter före händelsen och en fil på fel ställe.

Det är värt att skriva ner som det är, snarare än som en slutsats. ”Fyllde minnet och kärnan gav upp” är en rimlig historia. Den är inte uppmätt, och den skillnaden spelar större roll här än vad säkerheten skulle göra.

Vad skadan blev

Ingen som gick att hitta. CHECK TABLE på de fem viktigaste tabellerna gav OK, antalet rader var oförändrat, räkningen registrerade fortfarande samma dag, och alla sexton schemalagda jobb var intakta. Webbplatsen svarade återigen på 0,14 sekunder.

En sak gick förlorad: ett långvarigt jobb som tillhörde en annan session på samma maskin. Det hade ingenting med det här arbetet att göra och gick ner tillsammans med allt annat, och det är den del av ett avbrott som ingen lokal kontroll rapporterar.

Regeln som blev resultatet

Loggfilerna här är på 700 till 900 MB per dag. Att packa upp en av dem i /tmp innebär att en fjärdedel av maskinens minne hamnar någonstans som ser ut som disk och beter sig som RAM.

Stora mellanfiler hamnar i /var/tmp eller i en hemkatalog, som båda ligger på disken. Ännu bättre är att de inte packas upp alls: zcat -f file.gz | awk ... läser som en ström och behöver inget mål. Varje mätning i inläggen som följde gjordes på det sättet.

Det som går att generalisera

Ett filsystem rapporterar hur mycket utrymme det har. Det rapporterar inte vad utrymmet består av, och de två frågorna har olika svar just på de system där det spelar störst roll.

Kontrollen är en enda rad, och den hoppades över eftersom filen var ”tillfällig”. Tillfällig stämde. Det var fel egenskap att tänka på.