Dit artikel beschrijft een technisch probleem waarbij systemd-journald op Debian 13 zorgt voor een disproportioneel hoge I/O-belasting. Bij het schrijven van slechts twee regels log per seconde voert een virtuele machine ongeveer 50 IOPS uit, wat veel hoger is dan bij syslog.
De auteur stelt dat dit probleem niet voortkomt uit kernelmechanismen, maar uit de inefficiëntie van het journald-bestandsformaat. Daarnaast wordt opgemerkt dat de bestanden aanzienlijk groter zijn dan de werkelijke inhoud en gevoelig kunnen zijn voor corruptie bij onschone reboots.
Overmatige I/O veroorzaakt door systemd-journald (Issue #40262)
Systeeminformatie
- Systemd versie: 257.9
- Gebruikte distributie: Debian 13
- Linux kernel versie: 6.12.57+deb13-amd64
- Component: systemd-journald
Probleembeschrijving
Verwacht gedrag
Onverwacht gedrag
Een virtuele machine (VM) voert ongeveer 50 IOPS uit bij het schrijven van slechts twee regels log per seconde.
Stappen om het probleem te reproduceren
Dit is exact hetzelfde probleem als beschreven in issue #15292, die zonder goede reden is gesloten.
- Gebruik
journald in een modus waarin gegevens naar de harde schijf worden geschreven. Het gebruikte bestandssysteem is XFS.
- Zorg voor een constante stroom van logvermeldingen op een VM:
Jan 03 13:37:01 cthylla haproxy[727]: 192.168.1.1:48550 [03/Jan/2026:13:37:01.392] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:03 cthylla haproxy[727]: 192.168.1.1:36892 [03/Jan/2026:13:37:03.403] f_www b_icinga/web 0/0/0/7/7 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:05 cthylla haproxy[727]: 192.168.1.1:36904 [03/Jan/2026:13:37:05.416] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:07 cthylla haproxy[727]: 192.168.1.1:36906 [03/Jan/2026:13:37:07.427] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:09 cthylla haproxy[727]: 192.168.1.1:36912 [03/Jan/2026:13:37:09.439] f_www b_icinga/web 0/0/0/7/8 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:11 cthylla haproxy[727]: 192.168.1.1:36918 [03/Jan/2026:13:37:11.454] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:13 cthylla haproxy[727]: 192.168.1.1:45832 [03/Jan/2026:13:37:13.465] f_www b_icinga/web 0/0/0/7/7 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:15 cthylla haproxy[727]: 192.168.1.1:45848 [03/Jan/2026:13:37:15.476] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:17 cthylla haproxy[727]: 192.168.1.1:45856 [03/Jan/2026:13:37:17.488] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:19 cthylla haproxy[727]: 192.168.1.1:45862 [03/Jan/2026:13:37:19.500] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
- Observe het I/O-verkeer van de VM.
Analyse en opmerkingen
Er is een VM als voorbeeld gebruikt omdat in issue #15292 werd beweerd dat iotop niet accuraat is (wat aannemelijk is, aangezien dit plaatsvindt vóór elke OS write coalescing). Deze test laat echter duidelijk het verkeer zien nadat elk kernelmechanisme is toegepast. Het probleem is dus niet dat de kernel veel IOPS genereert, maar dat het proces traag is.
Journald maakt gebruik van een extreem inefficiënt formaat; bovendien zijn de bestanden meerdere malen groter dan de werkelijk geschreven inhoud. Daarnaast is er genoeg bewijs bij onschone reboots om te concluderen dat het formaat niet erg veerkrachtig is en corrupt kan raken.
Overmatige I/O veroorzaakt door systemd-journald (Issue #40262)
Systeeminformatie
- Systemd versie: 257.9
- Gebruikte distributie: Debian 13
- Linux kernel versie: 6.12.57+deb13-amd64
- Component: systemd-journald
Probleembeschrijving
Verwacht gedrag
Onverwacht gedrag
Een virtuele machine (VM) voert ongeveer 50 IOPS uit bij het schrijven van slechts twee regels log per seconde.
Stappen om het probleem te reproduceren
Dit is exact hetzelfde probleem als beschreven in issue #15292, die zonder goede reden is gesloten.
- Gebruik
journald in een modus waarin gegevens naar de harde schijf worden geschreven. Het gebruikte bestandssysteem is XFS.
- Zorg voor een constante stroom van logvermeldingen op een VM:
Jan 03 13:37:01 cthylla haproxy[727]: 192.168.1.1:48550 [03/Jan/2026:13:37:01.392] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:03 cthylla haproxy[727]: 192.168.1.1:36892 [03/Jan/2026:13:37:03.403] f_www b_icinga/web 0/0/0/7/7 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:05 cthylla haproxy[727]: 192.168.1.1:36904 [03/Jan/2026:13:37:05.416] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:07 cthylla haproxy[727]: 192.168.1.1:36906 [03/Jan/2026:13:37:07.427] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:09 cthylla haproxy[727]: 192.168.1.1:36912 [03/Jan/2026:13:37:09.439] f_www b_icinga/web 0/0/0/7/8 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:11 cthylla haproxy[727]: 192.168.1.1:36918 [03/Jan/2026:13:37:11.454] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:13 cthylla haproxy[727]: 192.168.1.1:45832 [03/Jan/2026:13:37:13.465] f_www b_icinga/web 0/0/0/7/7 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:15 cthylla haproxy[727]: 192.168.1.1:45848 [03/Jan/2026:13:37:15.476] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:17 cthylla haproxy[727]: 192.168.1.1:45856 [03/Jan/2026:13:37:17.488] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:19 cthylla haproxy[727]: 192.168.1.1:45862 [03/Jan/2026:13:37:19.500] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
- Observe het I/O-verkeer van de VM.
Analyse en opmerkingen
Er is een VM als voorbeeld gebruikt omdat in issue #15292 werd beweerd dat iotop niet accuraat is (wat aannemelijk is, aangezien dit plaatsvindt vóór elke OS write coalescing). Deze test laat echter duidelijk het verkeer zien nadat elk kernelmechanisme is toegepast. Het probleem is dus niet dat de kernel veel IOPS genereert, maar dat het proces traag is.
Journald maakt gebruik van een extreem inefficiënt formaat; bovendien zijn de bestanden meerdere malen groter dan de werkelijk geschreven inhoud. Daarnaast is er genoeg bewijs bij onschone reboots om te concluderen dat het formaat niet erg veerkrachtig is en corrupt kan raken.
Groetjes,