Hello,
We ran experiments over 10 days on ~100 Tor guard relays (Tor 0.4.8.x) on Ubuntu 24.04 to determine which memory optimizations materially affect long-term, steady-state RSS under sustained load.
Results: allocator choice dominates steady-state RSS outcomes. Using mimalloc 2.x and jemalloc 5.x produced large, sustained reductions in resident memory, on the order of 70–80 percent, compared to the default glibc malloc; tcmalloc showed a smaller but measurable improvement. By contrast, the two commonly cited configuration parameters, MaxMemInQueues and MaxConsensusAgeForDiffs, showed little to no impact on steady-state RSS when adjusted in isolation.
Operationally, these reductions allow higher relay density per host, with guard relay memory footprints decreasing from roughly 5–6 GB to approximately 1–2 GB per relay under sustained load.
Attached are the summary chart and table. Full methodology, comparisons, and data are here, with links to scripts on GitHub to reproduce:
https://www.1aeo.com/blog/tor-memory-optizations-what-actually-works.html
Tor at 1AEO
Approach Result Viable?
mimalloc 2.1.2 1.16 GB (80% reduction) Yes
jemalloc 5.3.0 1.59 GB (72% reduction) Yes
tcmalloc 2.15 3.79 GB (33% reduction) Partial
mimalloc 3.0.1 4.39 GB (23% reduction) Partial
DirCache 0 0.29 GB (94% reduction) No (loses Guard)
MaxMemInQueues ~5.0 GB (no change) No
MaxConsensusAgeForDiffs ~5.7 GB (no change) No
Periodic restarts 5.0–5.3 GB (minimal) Workaround only
glibc 2.39 (control) 5.68 GB Baseline
Attachment:
image.png
Description: PNG image
Attachment:
image.png
Description: PNG image
Attachment:
publickey - tor@1aeo.com - 0x9288289B.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx
