Updates, insights, and community posts from 1st Amendment Encrypted Openness.
After testing allocators, config tweaks, and restarts across 100+ relays, we found that switching to mimalloc or jemalloc is the only fix that actually stops Tor guard memory from ballooning to 5+ GB. Read more
Our 90-relay experiment on Ubuntu 24.04 proves that swapping glibc for mimalloc (79% reduction) or jemalloc (71% reduction) keeps Tor guards under 2 GB without recompiling or losing Guard status. Read more
Disabling DirCache cuts memory by 94%, but it also removes your Guard flag—making it a diagnostic proof point rather than a viable solution for production Guard relays. Read more
Despite its promising name, MaxMemInQueues only limits circuit buffers—not the directory cache fragmentation that actually causes Tor relays to bloat to 5 GB. Read more
Scheduled restarts can reduce memory by up to 19%, but they disrupt circuits and still leave you at 4.5 GB—use them only as a stopgap while migrating to a better allocator. Read more
Limiting how long Tor keeps consensus diffs had zero impact on memory—all test groups ended at 5.6–5.8 GB, proving the fragmentation problem lies in glibc, not cache retention. Read more
A straightforward guide to the leading Tor relay dashboards—compare their bandwidth stats, update frequency, map views, and detailed features to monitor your nodes and network with ease. Read more
Supercharge your Tor relay deployments with turnkey BGP configs that take you from zero to announced in minutes. Read more
Running a 10 Gbps Tor relay at maximum capacity reveals lessons every operator should know before scaling up. Read more
A recent thread on the Tor-relays list raises a fundamental question for operators: is it better to deploy a single high-capacity server, or several smaller ones distributed across locations and providers? Read more