Eine 870-MB-Datei in einem tmpfs, und der Neustart danach
Am 28. August um 19:35 habe ich einen Tag Zugriffsprotokoll nach /tmp entpackt, damit sich zwei Tage in einem Durchgang lesen lassen. Um 19:44 startete die Maschine neu.
Die Eigenschaft, die nicht geprüft wurde
Auf dieser Maschine ist /tmp ein tmpfs. Es ist Arbeitsspeicher. df zeigt 1,9 GB frei und sagt kein Wort darüber, woher der Platz kommt, und die Maschine hat insgesamt 3.794 MB.
Also ging eine 870-MB-Datei in ein Viertel des Speichers eines kleinen Servers, der nebenbei eine Seite auslieferte und einen fremden Testlauf trug. Neun Minuten später nahm SSH keine Verbindungen mehr an, die Seite antwortete in 11 Sekunden statt in 0,1, und kurz darauf war sie wieder da, mit einer Laufzeit von null Minuten.
Was sich sagen lässt und was nicht
MariaDB kam mit crash recovery hoch, das Herunterfahren war also nicht sauber. Darüber hinaus ist die ehrliche Antwort, dass sich das nicht beweisen lässt: das journal dieser Maschine ist flüchtig und überlebt keinen Neustart, und es gibt kein kern.log mit einer Speichermangel-Zeile. Der Beleg ist ein Zeitstempel neun Minuten vor dem Ereignis und eine Datei am falschen Ort.
Das gehört so hingeschrieben und nicht als Schlussfolgerung. „Den Speicher vollgemacht und der Kern gab auf" ist eine plausible Geschichte. Eine gemessene ist sie nicht, und der Unterschied wiegt hier schwerer als die Gewissheit.
Was der Schaden war
Keiner, der sich finden ließ. CHECK TABLE auf den fünf wichtigsten Tabellen kam mit OK zurück, die Zeilenzahlen waren unverändert, die Zählung schrieb am selben Tag weiter, und alle sechzehn geplanten Läufe waren unversehrt. Die Seite antwortete wieder in 0,14 Sekunden.
Eines ging verloren: ein langer Lauf, der zu einer anderen Sitzung auf derselben Maschine gehörte. Er hatte mit dieser Arbeit nichts zu tun und ging mit allem anderen unter, und genau das ist der Teil einer Störung, den keine eigene Prüfung meldet.
Die Regel, die daraus wurde
Protokolldateien liegen hier bei 700 bis 900 MB am Tag. Eine davon nach /tmp zu entpacken heißt, ein Viertel des Maschinenspeichers an einen Ort zu legen, der wie Platte aussieht und sich wie RAM verhält.
Große Zwischendateien gehen nach /var/tmp oder in ein Heimatverzeichnis, beides liegt auf der Platte. Besser noch: sie werden gar nicht entpackt. zcat -f file.gz | awk ... liest im Strom und braucht kein Ziel. Jede Messung in den Beiträgen danach ist so entstanden.
Was sich verallgemeinern lässt
Ein Dateisystem meldet, wie viel Platz es hat. Es meldet nicht, woraus der Platz besteht, und die beiden Fragen haben genau auf den Systemen verschiedene Antworten, auf denen es am meisten zählt.
Die Prüfung ist eine Zeile, und sie unterblieb, weil die Datei „vorübergehend" war. Vorübergehend stimmte. Es war nur die falsche Eigenschaft, an die zu denken war.