Un fichier de 870 Mo dans un tmpfs, et le redémarrage qui a suivi
Le 28 août à 19h35, j’ai décompressé une journée de journal d’accès dans /tmp pour pouvoir lire deux jours d’un coup. À 19h44, la machine a redémarré.
La propriété qui n’a pas été vérifiée
Sur cette machine, /tmp est un tmpfs. C’est de la mémoire. df affiche 1,9 Go libres et ne dit pas un mot d’où vient cette place, et la machine dispose de 3 794 Mo en tout.
Un fichier de 870 Mo est donc allé occuper un quart de la mémoire d’un petit serveur qui servait par ailleurs un site et portait le test de quelqu’un d’autre. Neuf minutes plus tard, SSH n’acceptait plus de connexions, la page répondait en 11 secondes au lieu de 0,1, et peu après elle était de retour, avec une durée de fonctionnement de zéro minute.
Ce qui peut être affirmé et ce qui ne le peut pas
MariaDB est repartie avec une récupération après incident : l’arrêt n’a donc pas été propre. Au-delà, la réponse honnête est que cela ne se démontre pas. Le journal de cette machine est volatil et ne survit pas à un redémarrage, et il n’existe aucun kern.log portant une ligne de manque de mémoire. La preuve, c’est un horodatage neuf minutes avant l’événement et un fichier au mauvais endroit.
Cela mérite d’être écrit ainsi, et non comme une conclusion. « Il a rempli la mémoire et le noyau a abandonné » est une histoire plausible. Elle n’est pas mesurée, et cette différence pèse ici plus lourd que la certitude.
Quels ont été les dégâts
Aucun n’a été trouvé. CHECK TABLE sur les cinq tables les plus importantes est revenu avec OK, les nombres de lignes étaient inchangés, le comptage écrivait encore le jour même, et les seize tâches planifiées étaient intactes. La page répondait de nouveau en 0,14 seconde.
Une chose a été perdue : un long traitement appartenant à une autre session sur la même machine. Il n’avait rien à voir avec ce travail et il a coulé avec le reste, ce qui est précisément la partie d’une panne qu’aucun contrôle local ne signale.
La règle qui en est sortie
Les journaux font ici 700 à 900 Mo par jour. En décompresser un dans /tmp, c’est poser un quart de la mémoire de la machine dans un endroit qui ressemble à du disque et se comporte comme de la RAM.
Les gros fichiers intermédiaires vont dans /var/tmp ou dans un répertoire personnel, tous deux sur le disque. Mieux encore : pas de décompression du tout. zcat -f file.gz | awk ... lit en flux et n’a besoin d’aucune destination. Toutes les mesures des billets qui ont suivi ont été prises ainsi.
Ce qui se généralise
Un système de fichiers indique combien de place il a. Il n’indique pas de quoi cette place est faite, et les deux questions ont des réponses différentes précisément sur les systèmes où cela compte le plus.
La vérification tient en une ligne et elle a été sautée parce que le fichier était « temporaire ». Temporaire était vrai. C’était simplement la mauvaise propriété à laquelle penser.