{"id":183001,"date":"2026-08-15T10:53:29","date_gmt":"2026-08-15T08:53:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/v-systemd-journald-spustya-6-let-priznali-problemu-izbytochnoj-nagruzki-na-nakopiteli"},"modified":"2026-08-15T10:53:32","modified_gmt":"2026-08-15T08:53:32","slug":"systemd-journald-acknowledges-excessive-disk-load-problem-after-6-years","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/systemd-journald-acknowledges-excessive-disk-load-problem-after-6-years","title":{"rendered":"En systemd-journald, tras 6 a\u00f1os, se ha reconocido el problema de la carga excesiva en los dispositivos de almacenamiento","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Los desarrolladores del proyecto systemd han comenzado a investigar y corregir un antiguo problema arquitect\u00f3nico en el componente \u00absystemd-journald\u00bb, que provoca una notable amplificaci\u00f3n de escritura en comparaci\u00f3n con el volumen real de registros en disco. <\/p>\n
La historia se remonta a marzo de 2020, cuando se registr\u00f3 un informe en el sistema de seguimiento de errores que demostraba que la generaci\u00f3n de aproximadamente 500 KB de registros de texto resultaba en m\u00e1s de 700 MB de operaciones de escritura f\u00edsicas en un SSD. En ese momento, los desarrolladores de systemd se negaron rotundamente a reconocer el problema, respondieron con la actitud de \u00abno entienden c\u00f3mo funcionan los sistemas de archivos\u00bb, rechazaron llevar a cabo un perfilado y cerraron la solicitud con el veredicto \u00abnot actionable\u00bb. Los comentarios de los desarrolladores recibieron cientos de calificaciones negativas de los usuarios, sin embargo, la posici\u00f3n del proyecto se mantuvo inflexible. <\/p>\n
A principios de 2026, se envi\u00f3 un informe reiterando el problema, durante cuya discusi\u00f3n el desarrollador independiente ValdikSS realiz\u00f3 un perfilado detallado utilizando cgroup aislados y dispositivos loop, demostrando claramente el mecanismo de origen del problema: debido al uso de archivos mapeados en memoria (mmap) y tablas hash binarias, la escritura de un solo mensaje de texto de 750 bytes provoca la modificaci\u00f3n de las huellas en memoria, provocando el volcado en disco de p\u00e1ginas completas de 4 KB y generando de 50 a 70 KB de entrada\/salida final a nivel de dispositivo de bloque. <\/p>\n
Tras la publicaci\u00f3n de ayer del informe sobre el problema en la p\u00e1gina principal de Hacker News y la publicaci\u00f3n de pruebas sint\u00e9ticas irrefutables, los mantenedores del proyecto han cambiado su ret\u00f3rica y han comenzado a trabajar en la optimizaci\u00f3n de los mecanismos de volcado de cach\u00e9 y la estructura de almacenamiento de los \u00edndices de journald. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"