journalctl --disk-usage私が何かをすると、300MBジャーナルファイルのサイズは大きいですが、実際のテキストを見るとjournalctl | wc -c、28MBまあ、journald には圧縮機能があり、タイムスタンプ、uid、メッセージ ハッシュなどのメタデータを考慮しても、ディスク領域の無駄遣いのように思えます。
ジャーナル ファイルが、内部の実際のテキストに比べてなぜこんなに大きいのか、誰か教えてもらえますか?
答え1
理由は 2 つあります。まず、@Mella が述べたように、現在のログとすべてのログには違いがあります。
次に、 に記載されているようにman journalctl、出力形式はいくつかあります。最もコンパクトで詳細度の低いもののサイズを測定していました。systemd ジャーナルの最大データを表示するには、次を使用します。
journactl --output=verbose
私の場合、コンパクト ジャーナル出力では 32 MB のデータが返されますが、 では 128 MB が返され--output=verbose、 では 152 MB が見つかりjournalctl --disk-usage、アクティブ ジャーナルとアーカイブ ジャーナルの両方がカバーされます。
心配な場合は、man journald.confディスク容量の使用量を制限する方法を確認してください。journald
答え2
- これらは一種のバグなので巨大です:
示されているように上流のしたがって、journald の開発者には知られていることですが、バイナリ ログ形式で使用されるものはそれほど優れたものではありません (まだ?)。
- 圧縮が効いていないせいか、サイズが大きいです
/etc/systemd/journald.confnamedにもオプションがありますがCompress=yes、システムによってはアクティブになっていない可能性があり、その場合は実質的に圧縮が行われません。
- アーカイブされたジャーナルの問題はここでは問題ではありません。
journaldが区別するのは原則的には正しいが、アクティブそしてアーカイブ済みジャーナルログによると、これは他の回答に対する誤解を招く返答であり、次のようにman journalctl明確に述べています。
出力は、ローテーションされているか現在書き込み中であるかに関係なく、また、システム自体に属しているかアクセス可能なユーザー ジャーナルであるかに関係なく、アクセス可能なすべてのジャーナル ファイルからインターリーブされます。
したがって、他の回答はここでは誤解を招くことになります。
- いくつかのファイル割り当て、断片化、破損防止対策のため、journalctl のディスク使用量は膨大になります (つまり、同等レベルの情報 (つまりフィールド) を持つプレーン テキスト ファイルよりも大きくなります)。
「ファイルの断片化/割り当ての問題」
私のボックスでは、journalctl --version == "systemd 239[...]"データを含むジャーナル ファイルは、8MiB の倍数のファイル サイズで存在します。その結果、私のシステム ジャーナル ファイルは、実際にはデータの一部 (1 つのケースでは 56kiB) しか保存されていない場合でも、8MiB の大きさになります。
「破損防止問題」 の開発者の一人である Poettering 氏によるjournaldと、systemdジャーナルが によって破損したと判断された場合journald、さらなる問題を防ぐために「修正」は行われず、そのまま残されるとのこと。(https://bugs.freedesktop.org/show_bug.cgi?id=64116#c3）
これはもちろん、圧縮されていない、ほぼ空のジャーナル バイナリ ログ ファイルが var ログ内に存在する可能性が高いことを意味し、実質的には正常なプレーンテキストの代替よりもはるかに大きくなります。
答え3
journalctlパラメータなし（出力を で測定しているwc -c）では、アクティブなジャーナルのジャーナル エントリのみが表示されます（何がターンオーバーを促すのかはすぐにはわかりません）。 は、journalctl --disk-usageアーカイブされたジャーナルとアクティブなジャーナルによって使用されているスペースを表示します。