當我做 a 時，journalctl --disk-usage它會說一些關於300MB日誌檔案的大小，但當我查看實際文字時，journalctl | wc -c它是關於28MB。好吧，journald 具有壓縮功能，甚至考慮到時間戳、uid、訊息哈希等元數據，在我看來，這似乎是對磁碟空間的荒謬浪費。
有人可以告訴我為什麼日誌檔案與裡面的實際文字相比如此之大？
答案1
有兩個原因。首先，如 @Mella 所提到的，目前日誌與所有日誌之間存在差異。
其次，如 所述man journalctl，有多種輸出格式。您正在測量最緊湊/最不詳細的尺寸。若要查看 systemd 日誌中的最大數據，請使用：
journactl --output=verbose
在我的例子中，緊湊日誌輸出返回 32 Megs 數據，而 128 MB 返回--output=verbose，152M 找到journalctl --disk-usage，涵蓋活動日誌和歸檔日誌。
如果您擔心的話，請參閱 參考資料man journald.conf以了解如何限制磁碟空間的使用量。journald
答案2
- 它們很大，因為它是一個錯誤：
如圖所示上游因此，journald 的開發人員知道，二進位日誌格式中使用的 根本不是很好（還？）。
- 它們很大，因為壓縮可能沒有激活
/etc/systemd/journald.confname中還有一個選項Compress=yes，該選項可能在您的系統上未激活，因此實際上沒有壓縮。
- 存檔期刊的問題在這裡並不重要。
雖然原則上，journald 區分積極的和已歸檔在日記日誌中，這是對其他答案的誤導性答复，其中man journalctl明確指出：
所有可存取的日誌檔案的輸出都是交錯的，無論它們是輪換的還是目前正在寫入的，也無論它們是屬於系統本身還是可存取的使用者日誌。
因此，其他答案在這裡具有誤導性。
- 由於某些檔案分配、碎片、反腐敗措施，journalctl 的磁碟使用量龐大（即大於具有可比較資訊等級的純文字檔案 - 即欄位）。
“文件碎片/分配問題”
在我的盒子上，journalctl --version == "systemd 239[...]"包含資料的日誌檔案的檔案大小是 8MiB 的倍數。因此，在我的系統日誌檔案中，即使實際上只儲存了一小部分（例如 56kiB）數據，該檔案也會有 8MiB 大。
“反腐敗問題” 根據 Poettering 的開發者之一的journald說法systemd，如果期刊被認為已被 腐敗journald，它不會被“修復”，而是保持原樣，以防止進一步的問題出現。 （看https://bugs.freedesktop.org/show_bug.cgi?id=64116#c3）
這當然意味著未壓縮的、幾乎空的日誌二進位日誌檔案很可能位於您的 var 日誌中，使其實際上比正常的明文替代方案大得多。
答案3
journalctl沒有參數（您正在測量其輸出wc -c）僅顯示活動日記帳中的日記帳分錄（我不確定是什麼導致了營業額）。journalctl --disk-usage顯示已歸檔日誌和活動日誌所使用的空間。