单条日志在 systemd-journald 磁盘写入中占用 49KB+ (ext4) / 110KB+ (btrfs) 的空间。

单条日志在 systemd-journald 磁盘写入中占用 49KB+ (ext4) / 110KB+ (btrfs) 的空间。
Single log line is 49KB+ (ext4) / 110KB+ (btrfs) of systemd-journald disk writes

原始链接: https://github.com/systemd/systemd/issues/40262

**问题摘要：systemd-journald 磁盘 I/O 过高** 用户反映在 Debian 13/XFS 系统（systemd-journald 版本 257.9）上，`systemd-journald` 存在严重的低效磁盘 I/O 问题。尽管日志记录量仅为每秒两条，系统却表现出约 50 IOPS 的负载。报告者认为，这种行为（此前在已关闭的 issue #15292 中已有记录）并非源于内核级的写入合并机制，而是 journald 文件格式本身固有的低效所致。此外，报告者还对文件体积膨胀及数据恢复能力不足表示担忧，指出在非正常重启后曾发生数据损坏。当前产生的 I/O 影响与其生成的日志量不成比例，远超传统 syslog 的性能表现。

这篇 Hacker News 的讨论重点介绍了关于 `systemd-journald` 磁盘占用情况的重大担忧，特别是它在 ext4 和 btrfs 等文件系统上极高的写放大问题。由于该日志采用了复杂的、基于 mmap 的二进制格式以及频繁的哈希表更新，单条日志记录可能会导致数万字节的磁盘写入。批评者认为，该设计优先考虑自定义去重和索引，从根本上就是缺陷且低效的。许多用户反映，与在纯文本文件上使用 `grep` 或 `ripgrep` 等标准文本处理工具相比，`journalctl` 的速度要慢得多。虽然支持者认为日志提供了结构化查询功能，但反对者认为这些功能的价值往往无法抵消其性能损耗和复杂性。讨论强调了一个反复出现的主题：`systemd` 项目通常倾向于使用专有的内部解决方案，而非 SQLite 或专用的日志管理守护进程等成熟且经过实战检验的替代方案。许多高级用户建议禁用持久化日志存储（`Storage=volatile`）或完全将其替换为 `rsyslog`，以提高系统性能并减少 SSD 损耗。批评者的共识是，`journald` 试图解决的问题——即本地日志管理——实际上早已被更简单、更稳健的工具完美解决了。

原文

systemd version the issue has been seen with

257.9

Used distribution

Debian 13

Linux kernel version used

6.12.57+deb13-amd64

Component

systemd-journald

Expected behaviour you didn't see

Log writes should be within order of magnitude of syslog

Unexpected behaviour you saw

VM doing ~50 IOPS when writing 2 lines of log per second

Steps to reproduce the problem

this is exactly same issue #15292 that was closed without good reason

Step 1. Use journald in mode where it writes to hard drive. The FS is XFS

Step 2. have constant stream of log entries going on a 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"

Step 3. Observe the VM IO traffic.

I used VM as example because the complaint in #15292 was "iotop is not accurate" (I can believe that, it's before any OS write coaelscing) but this clearly shows traffic after every kernel mechanism was used. So no, it isn't "kernel making lotsa iops out of it", it's slow.

Journald just uses extremely inefficient format (also I've seen it corrupt on unclean reboot enough times to declare it's not even all that resilient) as files are also multiple times the size of what's actually written in them.