单个日志行 systemd-journald 磁盘写入量为 49KB+ (ext4) / 110KB+ (btrfs)

systemd 版本 257.9 中已出现该问题 使用的发行版 Debian 13 Linux 内核版本使用 6.12.57+deb13-amd64 组件 systemd-journald 您未看到的预期行为 日志写入应在 syslog 的数量级内 每秒写入 2 行日志时，您看到虚拟机执行 ~50 IOPS 的意外行为 重现问题的步骤 这与之前的问题完全相同 #15292无正当理由关闭 步骤 1. 在写入硬盘驱动器的模式下使用日志。 FS 是 XFS 步骤 2. 在虚拟机上有持续的日志条目流 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”1月3日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 “获取/ 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" 步骤 3. 观察虚拟机 IO 流量。我使用 VM 作为示例，因为 #15292 中的抱怨是“iotop 不准确”（我可以相信，它是在任何操作系统写入合并之前），但这清楚地显示了使用每个内核机制后的流量。所以不，它不是“内核从中产生大量的 iops”，它很慢。 Journald 只是使用极其低效的格式（而且我已经看到它在不干净的重新启动时损坏了足够多次，以声明它甚至没有那么有弹性），因为文件的大小也是实际写入文件大小的数倍。