インフラ・DevOps
systemd-journaldのディスク書き込みが1行あたり49KB以上(ext4)/ 110KB以上(btrfs)になる問題
Single log line is 49KB+ (ext4) / 110KB+ (btrfs) of systemd-journald disk writes (github.com)
要約
systemd-journaldがログをディスクに書き込む際に、特にext4やbtrfsファイルシステムにおいて、1行のログに対して49KBから110KB以上ものディスク書き込みが発生するという問題が報告されています。これは、syslogと比較して桁違いに大きく、VM環境で毎秒2行のログ書き込みで約50 IOPSを発生させるほどの過剰なI/Oを引き起こしています。報告者は、journaldの非効率的なフォーマットと、クリーンでない再起動時の破損の可能性を指摘しています。
全文翻訳
おっと!読み込み中にエラーが発生しました。このページを再読み込みしてください。
systemd / systemd Public
おっと!読み込み中にエラーが発生しました。このページを再読み込みしてください。
通知
通知設定を変更するにはサインインする必要があります
フォーク 4.6k スター 16.6k
systemd-journaldによる過剰なI/O #40262
新しいイシューコピーリンク
新しいイシューコピーリンク
オープン
オープン
Excessive IO caused by systemd-journald #40262
コピーリンク
ラベル
バグ 🐛 プログラミングエラー、優先的に修正が必要 プログラミングエラー、優先的に修正が必要
ジャーナル
説明
XANi
2026年1月3日にオープン
イシュー本文
問題が発生しているsystemdのバージョン
257.9
使用しているディストリビューション
Debian 13
使用しているLinuxカーネルのバージョン
6.12.57+deb13-amd64
コンポーネント
systemd-journald
期待される動作
ログの書き込みは、syslogのオーダーマグニチュードの範囲内であるべきです。
実際に見られた動作
VMが1秒あたり2行のログを書き込む際に、約50 IOPSを発生させている。
問題の再現手順
これは#15292と全く同じ問題ですが、理由なくクローズされました。
ステップ1. journaldをハードドライブに書き込むモードで使用します。ファイルシステムはXFSです。
ステップ2. 継続的なログエントリのストリームが発生するようにします。
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"
ステップ3. VMのI/Oトラフィックを観察します。VMを例として使用したのは、#15292の苦情が「iotopは正確ではない」(OSの書き込みキャッシュが有効になる前のことなので、信じられます)でしたが、これはすべてのカーネルメカニズムが使用された後のトラフィックを明確に示しています。つまり、カーネルが多くのIOPを生成しているのではなく、遅いのです。Journaldは非常に非効率的なフォーマットを使用しています(また、クリーンでない再起動時に十分な回数破損するのを見てきたので、それほど回復力があるわけではないと宣言できます)。ファイルは実際に書き込まれた内容の数倍のサイズになっています。
リアクションは現在利用できません
メタデータ
メタデータ
担当者なし
ラベル
バグ 🐛 プログラミングエラー、優先的に修正が必要 プログラミングエラー、優先的に修正が必要
ジャーナル
タイプ
タイプなし
プロジェクト
プロジェクトなし
マイルストーン
マイルストーンなし
関係
まだなし
開発
ブランチまたはプルリクエストなし
イシューアクション
GitHub Copilotアプリで開く