Un archivo de 870 MB en un tmpfs y el reinicio que siguió
El 28 de agosto a las 19:35 descomprimí un día de registro de accesos en /tmp para poder leer dos días de una pasada. A las 19:44 la máquina se reinició.
La propiedad que no se comprobó
En esta máquina /tmp es un tmpfs. Es memoria. df muestra 1,9 GB libres y no dice ni una palabra sobre de dónde sale ese sitio, y la máquina tiene 3.794 MB en total.
Así que un archivo de 870 MB fue a parar a una cuarta parte de la memoria de un servidor pequeño que además servía un sitio y cargaba con la prueba de otra persona. Nueve minutos después SSH dejó de aceptar conexiones, la página respondía en 11 segundos en vez de 0,1, y poco después estaba de vuelta con un tiempo de actividad de cero minutos.
Lo que se puede decir y lo que no
MariaDB arrancó con recuperación tras caída, así que el apagado no fue limpio. Más allá de eso, la respuesta honesta es que no se puede demostrar: el journal de esta máquina es volátil y no sobrevive a un reinicio, y no hay ningún kern.log con una línea de falta de memoria. La prueba es una marca de tiempo nueve minutos antes del suceso y un archivo en el sitio equivocado.
Conviene escribirlo así y no como conclusión. «Llenó la memoria y el núcleo se rindió» es una historia verosímil. Medida no lo es, y esa diferencia pesa aquí más que la certeza.
Cuál fue el daño
Ninguno que se pudiera encontrar. CHECK TABLE sobre las cinco tablas más importantes volvió con OK, los recuentos de filas no cambiaron, el conteo seguía escribiendo ese mismo día y las dieciséis tareas programadas estaban intactas. La página volvió a responder en 0,14 segundos.
Se perdió una cosa: un proceso largo que pertenecía a otra sesión en la misma máquina. No tenía nada que ver con este trabajo y se hundió con todo lo demás, que es justo la parte de una caída que ninguna comprobación local informa.
La regla que salió de aquí
Los registros aquí ocupan de 700 a 900 MB al día. Descomprimir uno en /tmp significa poner una cuarta parte de la memoria de la máquina en un sitio que parece disco y se comporta como RAM.
Los archivos intermedios grandes van a /var/tmp o a un directorio personal, ambos en el disco. Mejor aún: no se descomprimen. zcat -f file.gz | awk ... lee en flujo y no necesita destino. Todas las mediciones de las entradas posteriores se hicieron así.
Lo que se generaliza
Un sistema de archivos informa de cuánto sitio tiene. No informa de qué está hecho ese sitio, y las dos preguntas tienen respuestas distintas justo en los sistemas donde más importa.
La comprobación es una línea y se omitió porque el archivo era «temporal». Temporal era cierto. Solo que era la propiedad equivocada en la que pensar.