Systemdを試しています。特に、eMMCリポジトリを持つYocto Poky（Linux）ベースの組み込みデバイスでJournaldを使用しようとしていますが、書き込み統計が/ sys / block / mmcblk0 / statのように高すぎるため、フラッシュの摩耗が心配です。とブロックトレースが表示されます。
注：再起動後もログを保持したい場合は、Journald / journalctlが提供する構造化フィールドを使用しているため、追加フィールドを維持する方法がないと、syslog転送を含む揮発性ログは実現可能に見えません。つまり、できる優先順位の高いメッセージが成功する限り、一部の低優先順位メッセージは競合時に失われる可能性があります。
たとえば、8秒ごとにいくつかの短いDEBUGメッセージを記録するテストケースは、1.4 GB /日の速度でMMCに記録されます。ただし、メッセージ自体は5 MB /日にすぎません（ただし、指標として使用するとjournalctl -o export | wc125 MBを提供します）。 ）/日 - おそらくメタデータが原因です。
この例では、ほぼ300倍の書き込み乗算があり、これは非常に高いようです（10倍を期待しました）。乗算を減らすために何ができるかを知りたいです。要因？
blkparse output:
jbd2/mmcblk0p4- (180)
Reads Queued: 0, 0KiB Writes Queued: 33611, 134444KiB
Read Dispatches: 0, 0KiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 0, 0KiB
Read Merges: 0, 0KiB Write Merges: 17722, 70888KiB
IO unplugs: 7835 Timer unplugs: 91
Allocation wait: 0 Allocation wait: 0
Dispatch wait: 0 Dispatch wait: 0
Completion wait: 0 Completion wait: 0
journal-offline (248, ...)
Reads Queued: 0, 0KiB Writes Queued: 6277, 46528KiB
Read Dispatches: 0, 0KiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 0, 0KiB
Read Merges: 0, 0KiB Write Merges: 154, 3840KiB
IO unplugs: 563 Timer unplugs: 30
Allocation wait: 0 Allocation wait: 0
Dispatch wait: 0 Dispatch wait: 0
Completion wait: 0 Completion wait: 0
kworker/u2:0 (253, ...)
Reads Queued: 0, 0KiB Writes Queued: 32284, 288288KiB
Read Dispatches: 0, 0KiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 0, 0KiB
Read Merges: 0, 0KiB Write Merges: 1351, 32744KiB
IO unplugs: 2553 Timer unplugs: 710
Allocation wait: 0 Allocation wait: 0
Dispatch wait: 0 Dispatch wait: 0
Completion wait: 0 Completion wait: 0
kworker/u2:1 (414, ...)
Reads Queued: 0, 0KiB Writes Queued: 28428, 260332KiB
Read Dispatches: 0, 0KiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 0, 0KiB
Read Merges: 0, 0KiB Write Merges: 1256, 29428KiB
IO unplugs: 2290 Timer unplugs: 679
Allocation wait: 0 Allocation wait: 0
Dispatch wait: 0 Dispatch wait: 0
Completion wait: 0 Completion wait: 0
kworker/u2:2 (208, ...)
Reads Queued: 1, 4KiB Writes Queued: 22264, 200632KiB
Read Dispatches: 0, 0KiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 0, 0KiB
Read Merges: 0, 0KiB Write Merges: 918, 21048KiB
IO unplugs: 1782 Timer unplugs: 481
Allocation wait: 0 Allocation wait: 0
Dispatch wait: 0 Dispatch wait: 0
Completion wait: 0 Completion wait: 0
systemd-journal (206)
Reads Queued: 13, 52KiB Writes Queued: 190, 508KiB
Read Dispatches: 0, 0KiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 0, 0KiB
Read Merges: 4, 16KiB Write Merges: 0, 0KiB
IO unplugs: 128 Timer unplugs: 4
Allocation wait: 0 Allocation wait: 0
Dispatch wait: 0 Dispatch wait: 0
Completion wait: 0 Completion wait: 0
CPU0 (mmcblk0p4):
Reads Queued: 632, 61712KiB Writes Queued: 123054, 930732KiB
Read Dispatches: 8616, 61712KiB Write Dispatches: 101590, 930732KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 8616, 61712KiB Writes Completed: 109579, 930732KiB
Read Merges: 4, 16KiB Write Merges: 21401, 157948KiB
Read depth: 2 Write depth: 9
IO unplugs: 15952 Timer unplugs: 2012
私が試したこと：
- Journald.confでSyncIntervalSecを調整します - 全体に大きな影響を与えないようです。ただ時間だけです。
- ext4の代わりにF2FS - 実際には状況が悪化しますが、まだmount / mkfsパラメータを調整したことがありません（調整アイデアを歓迎）
- sysctl vm.dirty_writeback_centisecs=0 - これは、blktrace のほとんどの増幅がジャーナルオフライン実行間の kworker から出てくると見たためです。おそらくJournald mmap（）を使用しているのでしょうか？ 1日に約400MBなので大幅に改善されましたが、Journaldのドキュメントに記載されているように、CRITメッセージがまだすぐに同期されるかどうかはわかりません。
- https://github.com/systemd/systemd/pull/21183役に立ちそうだが安定化まではまだ行く道が遠い。
- fsレベル圧縮 - 結果が不明です。この方法が正しく評価されているかどうかはわかりませんか？