49KB por una línea de log: la ineficiencia de systemd que tu SSD ya está pagando

Tu servidor no está escribiendo logs: está escribiendo una novela por cada línea de log. Y tu SSD es quien paga la factura.

Un issue en el repositorio oficial de systemd explotó hoy en Hacker News con 140 puntos y 90 comentarios en cuestión de horas. El título lo dice todo: "Una sola línea de log genera 49KB+ de escrituras en ext4, y 110KB+ en btrfs".

Sí, leíste bien. Una línea. Ese GET / HTTP/1.1" 200 de toda la vida le cuesta al disco lo mismo que una imagen comprimida entera.

El número que debería darte escalofríos

El reporte (issue #40262, "Excessive IO caused by systemd-journald", con systemd 257.9 sobre Debian 13) es brutal: una VM haciendo nada más que escribir 2 líneas de log por segundo genera ~50 IOPS constantes. Cincuenta operaciones de entrada/salida por segundo. Para nada.

Y eso no es todo. El mismo usuario que reportó el problema señala que los archivos del journal son varias veces más grandes que el contenido real escrito. El formato es tan ineficiente que el almacenamiento se infla como si cada log fuera un PDF escaneado.

El dato duele todavía más cuando descubres que este problema ya se reportó en 2020 (issue #15292) y se cerró "sin una buena razón". Seis años después, el journald sigue gastando disco igual de mal.

Por qué esto es una guerra (y no un bug)

Hablar mal de systemd es casi un deporte nacional en Linux. Pero ojo: aquí no estamos en el terreno de la opinión, sino en el de los bytes. 49KB por línea de log no es una preferencia estética: es un costo medible en IOPS, en desgaste de SSD y en factura de cloud.

Piensa en contexto LATAM: tu VPS barato con disco de 40GB, tu Raspberry Pi corriendo servicios 24/7, tu servidor casero con un HDD reciclado. El journald no discrimina: quema disco igual en un bare metal de $200/mes que en un VPS de $5.

Y la ironía máxima: todo esto pasa mientras Linux presume de ser el sistema operativo más eficiente del planeta.

Qué puedes hacer HOY para dejar de quemar disco

La buena noticia es que hay mitigaciones inmediatas, sin necesidad de abandonar journald:

• Limita el tamaño del journal: en /etc/systemd/journald.conf pon SystemMaxUse=100M. Tu journal dejará de crecer hasta llenar el disco.
• Comprime: verifica que Compress=yes esté activo. Los logs se guardan comprimidos, pero no está de más confirmarlo.
• Reduce la sincronización: SyncIntervalSec=5m evita que cada entrada fuerce escrituras constantes al disco.
• Modo volátil: Storage=volatile manda los logs a tmpfs (RAM). Se pierden al reiniciar, pero si no los necesitas persistentes, tu disco respira.
• Limpia ahora mismo: journalctl --vacuum-size=100M recorta el journal al tamaño indicado al instante.

Y si quieres la solución radical: vuelve al syslog clásico. Menos features, cero drama, y el log de tu nginx ocupa exactamente lo que ocupa.

La opinión que nadie quiere escuchar

Systemd resolvió un problema real: la fragmentación del arranque y la gestión de servicios en Linux. Pero el journald es el ejemplo perfecto de un monolito que hace el 80% de las cosas bien y un 20% de manera absurda. Y ese 20% te cuesta disco, IOPS y dolores de cabeza todos los días.

Lo peor no es que sea ineficiente. Lo peor es que lleva años siéndolo, se ha reportado dos veces, y nadie con poder dentro del proyecto parece tener prisa. Mientras tanto, cada línea de log sigue escribiendo 49KB en tu disco.

Corre journalctl --disk-usage ahora mismo. Si el número te sorprende, ya sabes quién tiene la culpa. 🔥

Comparte esto con ese amigo que todavía dice que "systemd es perfecto y ya está".

¿Tu servidor también escribe 49KB por log, o ya encontraste una configuración que lo reduce? Cuéntamelo en los comentarios.