Een bestand van 870 MB in een tmpfs, en de herstart die volgde
Over de inhoud en de controle ervan
In dit artikel
Op 28 augustus om 19:35 pakte ik een dag toegangslogboek uit in /tmp zodat twee dagen in één keer gelezen konden worden. Om 19:44 startte de machine opnieuw op.
De eigenschap die niet nagekeken was
Op deze machine is /tmp een tmpfs. Het is geheugen. df toont 1,9 GB vrij en zegt helemaal niets over waar die ruimte vandaan komt, en de machine heeft er in totaal 3.794 MB.
Er ging dus een bestand van 870 MB in een kwart van het geheugen van een kleine server die tegelijk een site bediende en andermans testtaak draaide. Negen minuten later nam SSH geen verbindingen meer aan, antwoordde de site in 11 seconden in plaats van 0,1, en kort daarna was hij terug met een uptime van nul minuten.
Wat er wel en niet te zeggen valt
MariaDB kwam op met crash recovery, en dat betekent dat de afsluiting niet netjes was. Verder is het eerlijke antwoord dat dit niet te bewijzen is: het journaal op deze machine is vluchtig, dus het overleeft geen herstart, en er is geen kern.log met een out-of-memory-regel. Het bewijs is een tijdstempel negen minuten voor de gebeurtenis en een bestand op de verkeerde plaats.
Dat verdient opgeschreven te worden zoals het is, en niet als conclusie. «Het geheugen volgemaakt en de kernel gaf het op» is een geloofwaardig verhaal. Het is geen gemeten verhaal, en het verschil doet er hier meer toe dan de zekerheid zou doen.
Wat de schade was
Geen die te vinden was. CHECK TABLE op de vijf belangrijkste tabellen kwam OK terug, de regelaantallen waren ongewijzigd, het tellen legde diezelfde dag nog vast, en alle zestien ingeplande taken waren heel. De site antwoordde weer in 0,14 seconde.
Eén ding ging verloren: een langlopende taak van een andere sessie op dezelfde machine. Die had niets met dit werk te maken en ging met alles mee onderuit, en dat is het deel van een storing dat geen enkele plaatselijke controle meldt.
De regel die eruit voortkwam
Logboekbestanden lopen hier 700 tot 900 MB per dag. Er een uitpakken in /tmp betekent een kwart van het geheugen van de machine ergens neerzetten dat eruitziet als schijf en zich gedraagt als RAM.
Grote tussenbestanden gaan naar /var/tmp of een thuismap, en die staan allebei op de schijf. Beter nog: ze worden helemaal niet uitgepakt: zcat -f file.gz | awk ... leest in een stroom en heeft geen bestemming nodig. Elke meting in de berichten die volgden, is zo gedaan.
Wat in het algemeen geldt
Een bestandssysteem meldt hoeveel ruimte het heeft. Het meldt niet waar die ruimte van gemaakt is, en de twee vragen hebben verschillende antwoorden op precies de systemen waar het het meest uitmaakt.
De controle is één regel en ze is overgeslagen omdat het bestand «tijdelijk» was. Tijdelijk klopte. Het was de verkeerde eigenschap om aan te denken.