{"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\/de\/blog\/news\/systemd-journald-acknowledges-excessive-disk-load-problem-after-6-years","title":{"rendered":"Im systemd-journald wurde nach 6 Jahren ein Problem mit \u00fcberm\u00e4\u00dfiger Belastung der Speicher anerkannt.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Entwickler des Projekts systemd haben begonnen, ein langfristiges architektonisches Problem im Komponenten «systemd-journald» zu untersuchen und zu beheben, das zu einer erheblichen Steigerung des auf die Disk geschriebenen Datenvolumens (Write Amplification) im Vergleich zum tats\u00e4chlichen Volumen der Protokolle f\u00fchrt. <\/p>\n
Die Geschichte reicht bis M\u00e4rz 2020 zur\u00fcck, als im Fehlerverfolgungssystem ein Bericht registriert wurde, der zeigte, dass das Erzeugen von etwa 500 KB Textprotokollen in mehr als 700 MB physischen Schreibvorg\u00e4ngen auf SSD resultiert. Die Entwickler von systemd weigerten sich damals kategorisch, das Problem anzuerkennen, antworteten mit der Aussage, «Sie verstehen nicht, wie Dateisysteme funktionieren», lehnten eine Profilierung ab und schlossen das Ticket mit dem Urteil «not actionable». Die Kommentare der Entwickler erhielten Hunderte von negativen Bewertungen von Nutzern, doch die Position des Projekts blieb unnachgiebig. <\/p>\n
Zu Beginn des Jahres 2026 wurde ein erneuter Bericht \u00fcber das Problem eingereicht, in dessen Verlauf der unabh\u00e4ngige Entwickler ValdikSS ein detailliertes Profiling unter Verwendung isolierter cgroup- und Loop-Ger\u00e4te durchf\u00fchrte, das anschaulich den Mechanismus des Problems beweiste: Aufgrund der Nutzung von in den Speicher gemappten Dateien (mmap) und bin\u00e4ren Hash-Tabellen f\u00fchrt das Schreiben selbst einer einzigen Textnachricht von 750 Bytes zur Modifizierung von Fingerabdr\u00fccken im Speicher und verursacht einen Schreibvorgang von vollst\u00e4ndigen 4-Kilobyte-Seiten auf die Festplatte, was zu 50 bis 70 KB Gesamteingaben\/Ausgaben auf Blockger\u00e4t-Ebene f\u00fchrt. <\/p>\n