en
Tor Relay Memory Optimization for Small VPS
Tor relay memory usage grows with the number of active circuits and the amount of data buffered in queues. On small VPS plans with limited RAM (1-2GB), unoptimized Tor relays can consume excessive memory, leading to OOM (out of memory) kills that terminate the relay process and disrupt users' circuits. Understanding Tor's memory usage patterns and configuring appropriate limits allows relay operators to run stable relays on resource-constrained VPS plans without sacrificing too much relay utility. This guide covers Tor's memory configuration directives and OS-level memory management techniques for efficient relay operation.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
Understanding Tor's Memory Usage
Tor's primary memory consumers: (1) circuit cells in queue: each active circuit buffers cells (512-byte units) waiting for transport. High-bandwidth relays with many active circuits accumulate significant cell buffers. (2) Descriptor cache: Tor caches relay descriptors and consensus data. The full consensus document is several megabytes, and individual relay descriptors add more. On a relay: the descriptor cache is smaller than on a client (relays cache their own and nearby relays' descriptors), but still consumes tens of MB. (3) Hidden service descriptors (for HSDir relays): relays with the HSDir flag store v3 hidden service descriptors - each is a few KB, but many accumulate. (4) Connection metadata: each open connection (other relays, clients) has associated metadata. High-connection-count relays consume memory proportional to their connection count.
MaxMemInQueues Configuration
The most important Tor memory configuration directive: MaxMemInQueues 256 MB (example value). This limits the total memory Tor uses for cell queues across all circuits. When Tor's cell queue memory exceeds this limit, it drops circuits with the largest queues first - a controlled degradation rather than uncontrolled memory growth. Recommended values: for a 1GB RAM VPS: MaxMemInQueues 256 MB (leaving ~750 MB for OS, descriptor cache, and other Tor components). For a 2GB RAM VPS: MaxMemInQueues 512 MB. For a 512MB RAM VPS (very small): MaxMemInQueues 128 MB (relay will have limited capacity but can run stably). Set this value in /etc/tor/torrc and restart Tor. Monitor actual Tor memory usage with ps aux | grep tor to confirm RSS memory stays below the MaxMemInQueues value plus expected overhead.
Limiting Active Circuits and Connections
Additional parameters that limit memory-intensive circuit accumulation: NumEntryGuards 1 (client-side - reduces guard node connections, not applicable for pure relays). ConnLimit 1000 limits the maximum number of simultaneous connections Tor will accept. Reducing ConnLimit reduces memory for connection metadata but also limits relay capacity. MaxCircuitDirtiness 600 (seconds, default 10 minutes) reduces the lifetime of circuits in reuse - shorter lifetimes mean circuits are cleaned up sooner, freeing their cell queue memory. CircuitBuildTimeout 60 reduces the timeout for circuit construction - abandoned circuit-in-progress states are cleaned up sooner. These parameters collectively reduce the maximum number of active circuits at any time, reducing peak memory usage.
OS-Level Memory Management
Beyond Tor configuration, OS settings affect memory stability: (1) swap space: configure a swap file or partition (2-4x RAM) to prevent OOM kills when Tor's memory usage briefly spikes. Create swap: fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile. Add to /etc/fstab for persistence. Swap is slower than RAM but prevents OOM kills. (2) vm.swappiness: set vm.swappiness = 10 in /etc/sysctl.conf to reduce aggressive swapping under normal conditions (only swap when RAM is nearly full). (3) OOM score adjustment: set Tor's OOM score lower to make the OOM killer less likely to kill Tor versus other processes: echo -100 > /proc/$(pidof tor)/oom_score_adj. (4) Memory monitoring: configure a cron job that alerts when free memory drops below a threshold: available=$(awk '/MemAvailable/{print $2}' /proc/meminfo); if [ $available -lt 102400 ]; then mail -s 'Low memory alert' admin@example.com < /dev/null; fi.
Monitoring and Tuning After Configuration
After applying memory optimizations: monitor Tor's actual memory consumption with ps aux | grep tor (check RSS column) and by checking Tor's self-reported memory via the control port: echo -e 'AUTHENTICATE \"\"\nGETINFO status/version-current\nQUIT' | nc 127.0.0.1 9051. Watch for Tor log entries indicating memory-induced circuit drops: log messages containing 'killing circuits' or 'circuit dropped due to memory pressure' indicate the MaxMemInQueues limit is being hit. If circuit drops are frequent: increase MaxMemInQueues (if RAM allows) or reduce BandwidthRate to reduce the number of active circuits. The relay's consensus weight (visible on Tor Metrics) reflects actual bandwidth contribution - a memory-constrained relay may have lower consensus weight than its configured BandwidthRate suggests.
Related Services
Why Anubiz Host
100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.