Contact met ondersteuning

Wij antwoorden per e-mail, meestal binnen twee dagen.

Google reCAPTCHA controleert deze inzending op misbruik; daarbij worden gegevens naar Google gestuurd. Het script laadt pas wanneer dit formulier wordt geopend.

← Alle berichten

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.

wat de machine heeft, en wat één bestand innam 3.794 MB geheugen, waarvan /tmp er 1.900 kan bevatten 870 MB erin geschreven om 19:35 19:35 — een dag logboek uitgepakt in /tmp om twee dagen tegelijk te lezen 19:44 — SSH antwoordt niet meer, de site doet er 11 s over in plaats van 0,1 s 19:47 — de machine is terug, uptime 0 minuten MariaDB komt op met crash recovery: het was geen nette afsluiting het journaal overleeft geen herstart, dus dit is niet te bewijzen — alleen te dateren

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.

Advertentie