Systemd Journald(임베디드 장치)의 플래시 마모 감소

2024-6-9 • tag-icon

Systemd를 실험하고 있습니다. 특히 eMMC 저장소가 있는 Yocto Poky(Linux) 기반 임베디드 장치에서 Journald를 사용하려고 시도하고 있지만 쓰기 통계가 /sys/block/mmcblk0 /stat와 같이 너무 높기 때문에 플래시 마모가 걱정됩니다. 및 블록 추적이 표시됩니다.

참고: 재부팅 후에도 로그가 유지되기를 원하며, Journald/journalctl에서 제공하는 구조화된 필드를 사용하고 있으므로 추가 필드를 유지하는 방법이 없으면 syslog 전달이 포함된 휘발성 로그는 실현 가능해 보이지 않습니다. 즉, 나는할 수 있는우선순위가 높은 메시지가 성공하는 한 일부 낮은 우선순위 메시지는 충돌 시 손실될 수 있습니다.

예를 들어, 8초마다 몇 개의 짧은 DEBUG 메시지를 기록하는 테스트 사례는 1.4GB/일의 속도로 MMC에 기록합니다. 그러나 메시지 자체는 5MB/일에 불과합니다(그러나 측정항목으로 사용하면 journalctl -o export | wc125MB를 제공합니다). ) / 일 - 아마도 메타데이터로 인해 발생함).

이 예에서는 거의 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() 사용 때문일까요? 하루에 약 400MB이므로 크게 개선되었지만 Journald 문서에 명시된 것처럼 CRIT 메시지가 여전히 즉시 동기화되는지 확실하지 않습니다.
https://github.com/systemd/systemd/pull/21183도움이 될 것 같지만 안정화까지는 아직 갈 길이 멀다.
fs 수준 압축 - 결과가 불분명합니다. 이 방법이 올바르게 평가하는지 확실하지 않습니까?

관련 정보