Musl builds use mallocng. mimalloc fixes the mallocng speed but triples peak memory
The musl targets have no entry in platform-settings.toml, so they build without an
allocator override and run on musl's mallocng, which serializes allocations on a global
lock and is slow for parallel work like backup. The original Docker image (#969) used a
glibc base partly for this reason. #1297 moved it to musl on scratch and lost that.
I tried the obvious fix, adding mimalloc to additional-features for the musl targets,
and measured it on aarch64-unknown-linux-musl (rust:alpine, release profile, 801 files
/ 227 MB). It is faster, but the memory cost looks too high to turn on by default.
Speed: backup 0.79s -> 0.52s, incremental re-backup 268ms -> 239ms, check --read-data
252ms -> 218ms.
Memory: peak RSS 137 MB -> ~450 MB. Under a container limit, same dataset, three runs each:
| Limit |
mallocng |
mimalloc |
mimalloc + MIMALLOC_PURGE_DELAY=0 |
| 512 MB |
OK, 137 MB |
OK, 435-465 MB |
OK, 276-308 MB |
| 384 MB |
OK 3/3 |
OOM-killed (SIGKILL) 3/3 |
OK 3/3, 270-311 MB |
A separate round at 512 MB killed it once at 501 MB peak while the other runs passed, so
that limit sits right on the edge.
Nothing breaks functionally. cargo test --all-targets --features release --features mimalloc --workspace passes, and init / backup / check --read-data / restore plus a
recursive diff against the source are identical with and without mimalloc. The binary
grows by 202 KiB. CI would not have shown any of this either way: ci.yml only builds
with --features release, and platform-settings.toml is read solely by the release
workflows.
MIMALLOC_PURGE_DELAY=0 brings the peak down to ~280 MB at no measurable speed cost, but
it would have to be applied in-process via mi_option_set rather than left to users.
Since rustic often runs on NAS boxes and memory-capped containers, I would rather not
enable this by default without a decision: is a ~1.5x backup speedup worth ~2x RSS with
the purge tuning, or should musl stay on mallocng and the image move back to glibc?
If this is something desired I can open a PR with my local changes.
Musl builds use mallocng. mimalloc fixes the mallocng speed but triples peak memory
The musl targets have no entry in
platform-settings.toml, so they build without anallocator override and run on musl's mallocng, which serializes allocations on a global
lock and is slow for parallel work like
backup. The original Docker image (#969) used aglibc base partly for this reason. #1297 moved it to musl on scratch and lost that.
I tried the obvious fix, adding
mimalloctoadditional-featuresfor the musl targets,and measured it on
aarch64-unknown-linux-musl(rust:alpine, release profile, 801 files/ 227 MB). It is faster, but the memory cost looks too high to turn on by default.
Speed: backup 0.79s -> 0.52s, incremental re-backup 268ms -> 239ms,
check --read-data252ms -> 218ms.
Memory: peak RSS 137 MB -> ~450 MB. Under a container limit, same dataset, three runs each:
MIMALLOC_PURGE_DELAY=0A separate round at 512 MB killed it once at 501 MB peak while the other runs passed, so
that limit sits right on the edge.
Nothing breaks functionally.
cargo test --all-targets --features release --features mimalloc --workspacepasses, and init / backup /check --read-data/ restore plus arecursive diff against the source are identical with and without mimalloc. The binary
grows by 202 KiB. CI would not have shown any of this either way:
ci.ymlonly buildswith
--features release, andplatform-settings.tomlis read solely by the releaseworkflows.
MIMALLOC_PURGE_DELAY=0brings the peak down to ~280 MB at no measurable speed cost, butit would have to be applied in-process via
mi_option_setrather than left to users.Since rustic often runs on NAS boxes and memory-capped containers, I would rather not
enable this by default without a decision: is a ~1.5x backup speedup worth ~2x RSS with
the purge tuning, or should musl stay on mallocng and the image move back to glibc?
If this is something desired I can open a PR with my local changes.