ログ1行が49KBの書き込みに膨らむ journaldへの再報告

3行まとめ

• 「ログ1行でディスクに数万バイト書かれる」と systemd に報告された
• 1秒に2行のログで、仮想マシンが約50 IOPSIOPS1秒あたりのディスク入出力の回数。ディスクの忙しさを測る単位です。 を出したという計測
• 原因の切り分けは未決着。過去の同じ報告は一度閉じられている

何が起きたか

systemd の課題管理に、ログ書き込みが重すぎるという報告が上がりました。タイトルがそのまま主張です。1行のログが ext4 で49KB以上、btrfs で110KB以上のディスク書き込みになる。

環境は Debian 13、systemd 257.9、Linux カーネル 6.12.57+deb13-amd64。報告者は haproxy のアクセスログを例に挙げています。流れる量は1秒あたり2行ほど。

それでも仮想マシンのIOトラフィックは約50 IOPS に達したと書かれています。再現手順でのファイルシステムは XFS でした。期待されていたのは、syslogsyslog従来からあるログの仕組み。報告者はこれと同じ桁の書き込み量を期待していました。 と同じ桁に収まることです。

なぜ難しい・何がすごいか

小さな書き込みほど、ディスクに届く量は割に合わなくなります。これを書き込み増幅書き込み増幅要求した量より多くのデータが実際にディスクへ書かれること。層をまたぐたびに膨らみます。と呼びます。アプリが100バイト書いたつもりでも、途中で膨らむ。

層は一つではありません。ログを受け取る仕組み、ファイルシステム、ブロック層、そしてSSDの内部。どの層も、自分に都合のいい単位へデータを詰め直します。

4KB単位で扱う層に100バイトを渡せば、その時点で40倍。この比率は書き込みが小さいほど悪化します。今回どの層がどれだけ効いているかは、まだ確定していません。

たとえ話

ハガキ1枚を宅配便で送る場面を思い浮かべてください。段ボール、緩衝材、送り状。中身より梱包のほうが重くなります。

ログ1行にも、時刻やプロセス名といった情報がくっつき、保存形式の枠組みが乗ります。中身が短いほど梱包の比率は上がる。1行あたりのコストは、文字数だけでは決まりません。

用語ミニ辞典

• 書き込み増幅: 要求した量より多くのデータが実際にディスクへ書かれること。層をまたぐたびに膨らみます。
• systemd-journald: systemd がログを集めて保存する部分。今回の報告の対象です。
• IOPS: 1秒あたりのディスク入出力の回数。ディスクの忙しさを測る単位です。
• syslog: 従来からあるログの仕組み。報告者はこれと同じ桁の書き込み量を期待していました。
• ext4 / btrfs / XFS: Linux で使われるファイルシステム。報告にはこの3つが登場します。

技術者向けの深掘り

争点は「誰が増幅させているのか」です。報告者によれば、同じ内容は過去に #15292 として上がり、十分な理由なくクローズされました。そのときの反論は、iotop の数値が正確でないというものでした。

今回はその論点を避け、仮想マシンの外から見たIOトラフィックで計測しています。カーネル側の書き込み結合を通ったあとの数字だ、という主張です。

報告者は journald の保存形式そのものを非効率だと見ています。

Journald just uses extremely inefficient format

と述べ、ジャーナルファイルが実際の記録量の何倍にも膨らむと指摘しています。不正な再起動での破損にも触れていますが、こちらは自身の経験としての言及です。systemd 側の結論は、この報告の中では出ていません。

これは自分に関係ある？

サーバーを運用しているなら、ログの行数とディスクIOが釣り合っているかを見る材料になります。ただし今回は1つの環境での計測です。一般化はまだできません。

アプリを書く側にも効きます。ログ1行のコストは文字数より回数で決まる、という感覚を持てるかどうか。

ログを直接触らない人にも、話の形は身近です。小さな操作が裏で何倍にも膨らむ構造は、ソフトウェアのあちこちにあります。