シングルログラインは、systemd-journaldのディスク書き込みでext4が49KB以上、btrfsが110KB以上です

元記事: 2026年8月14日原文(github.com)

概要

systemd-journald が予想以上の ディスクI/O を発生させている問題
Debian 13環境、 カーネル6.12.57、XFSファイルシステムでの再現
2行/秒 のログ書き込みで ~50 IOPS 発生
syslogに比べて 非効率な書き込みパターン とファイルサイズの肥大化
以前報告された #15292 Issue の再発

systemd-journaldによる過剰なディスクI/O問題

systemd-journald は、ログをディスクに書き込む際に 異常に高いIOPS を発生させる現象
Debian 13、カーネルバージョン 6.12.57+deb13-amd64、XFSファイルシステム上で確認
syslog と比較して、同等のログ量でも IO負荷が桁違い に高い
2行/秒 のログ書き込みで ~50 IOPS を消費
VM上での観測例： iotop などのツールを用いても高IOPSを確認可能
journaldのファイル形式 が非効率で、実際のログサイズよりも ファイルサイズが数倍大きくなる 傾向
クラッシュや不正シャットダウン時 にファイルが破損しやすいという報告もあり、 堅牢性にも疑問
以前のIssue (#15292) と同様の内容で、根本的な解決がされていない状況

再現手順

journald を ディスク書き込みモード で稼働させる
XFSファイルシステム を使用する
VM上で 一定間隔（例：2秒ごと） にログエントリを出力し続ける
VMのIOトラフィックを監視 し、journaldによる高いIOPSを確認
syslog に切り替えた場合と比較すると、journaldの 非効率性 が明らか

根本的な課題と考察

journaldのログフォーマット が、頻繁なメタデータ更新や小さな書き込みを多発させる設計
バッファリングや書き込み合成 が不十分で、物理I/Oの発生頻度が高い
ログファイルの肥大化 および 破損リスク の増加
syslog などの従来方式に比べて、 パフォーマンス・堅牢性ともに劣る 場合がある

推奨対応策

journald.conf の各種パラメータ（ Storage=, SyncIntervalSec= 等）を調整し、I/O頻度を抑制
バッファリングの強化 や 書き込み合成の有効化 を検討
ログバックエンドをsyslogに切り替える ことで、I/O負荷の低減
journaldの設計改善要望 をsystemdコミュニティへ再度提起
定期的なバックアップと検証 による、 ログ破損リスク への備え

まとめ

systemd-journald は現状、 高頻度なディスクI/O や ログファイル肥大 などの問題を抱える
運用環境に応じてsyslogへの切り替え や journald設定の最適化 が推奨
systemdコミュニティ へのフィードバックと、 今後の改善動向の注視 が必要

提供: ハクソク · 要約更新: 2026年8月14日

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

https://github.com/systemd/systemd/issues/40262#issuecomment...

└

コメントありがとう。興味本位で、その設定はどうやって思いついたの？私にとっては、そのテストスイートのほとんどが異質に感じるんだけど。

最近、journaldのディスク使用量を調べてみたら、びっくりしたよ。次のステップとして、心の平和を得るために https://www.devuan.org/os/init-freedom を試してみるつもり。Debianシステムの次のディストロとして使う予定で、別のボックスでのVoid Linux（runit）の長い経験は素晴らしかったからね。

└

多くのアプリが、開発者が問題だと思っていなくてもディスクを叩きまくってるんだよね。journaldだけじゃなくて、残念ながら。普通のLinuxデスクトップをディスクのアクセスを少なくするために、これが3回目の挑戦なんだ。これはbtrfsやCOW FSにとって大きな問題で、小さくて頻繁な書き込みに対して大きな書き込み増幅があるから（2年間でアイドル状態のデスクトップSSDに38.7TB書き込まれた）。興味があれば、今回の発見をまとめてみたよ：

workrave: 60秒ごとにステータス同期 https://github.com/rcaelers/workrave/pull/717
kde klipper: 永続ストレージが無効でも、コピーするたびにディスクに保存される https://bugs.kde.org/show_bug.cgi?id=501030
kde plasmashell: 通知ポップアップが消えるたびにqtシェーダーキャッシュを保存する https://bugs.kde.org/show_bug.cgi?id=523805
bitwarden firefox拡張: デスクトップアプリに10秒ごとに接続を試み、失敗ごとにブラウザのWebStorageに約14KB書き込む https://github.com/bitwarden/clients/issues/22192
firefox datareporting/glean: とてもおしゃべりな .mozilla/firefox/xxx/datareporting/glean/db/data.safe
ipfs: 受信したDHTアナウンスを全てディスクに書き込む、3時間で20GB https://discuss.ipfs.tech/t/constant-writes-to-datastore-log/20316
mailcow: redisが5分ごとにデータを保存する https://github.com/mailcow/mailcow-dockerized/pull/7405

└

systemd-journaldのログファイルフォーマットは、今まで扱った中で最も狂ったものの一つだし、ユーザーインターフェースも最悪だよ。バイナリログやデータベースのログに反対してるわけじゃないけど、systemdに関しては良いアイデアがひどく実装されてるのを何度も見てきた。

└

デヴアンはほぼ初日から使ってるけど、めっちゃおすすめだよ。最近のFreeBSDも悪くないしね。

└

QubesのDomain-0がOpenRC付きのカスタマイズされたGentooだったらよかったのに。Fedoraをsystemdのベースにするのは最悪の選択だった。ポッタリングがユーザーランドに与えた影響なんて、誰も許可すべきじゃなかった。systemdはほぼ取り返しのつかないミスだよ。

おお、mmapped書き込みか。昔、一度そのミスをしたことがあるよ。:) そのGHの問題にコメントを投稿したこともある。

└

もっと詳しく教えて？いい話がありそうだね。

journaldは、個人的にはsystemdエコシステムの中で最悪の部分だと思う。ログを保存せずにルーターとしてだけ使った方がいいよ。使ってるインデックスシステムは遅くて、チャッティなサブシステムに対する制御もないから、特定の識別子のログを切り詰めることもできない。インデックスが役立ってるとはいえ、agやrgのようなモダンなgrepの方がパフォーマンスがいいよ。構造は大事だけど、journald以外の場所にある方がいいね。

└

最近、過剰な書き込みのせいでログを減らすためにかなりの努力をしたんだ。すべてがそれぞれのログを持っていて、どのファイルが増えているかを見るだけで済んでた頃の方がずっと楽だったよ。

└

既存のデータベースファイル形式を使ってくれた方がずっと良かったな。Sqlite3は堅牢で、ほとんどのLinuxディストリビューションのデフォルトインストールにすでに含まれてるし。SQLでシステムログをクエリできたらクールだし、sd_journal APIの変な quirksを使うよりも速いと思う。

Hacker Newsで議論の続きを見る