Skip to content

Recommend a MaxMemInQueues value in the Tor man page

due to recent DOS attacks much incorrect advice has been tossed around on tor-relays regarding the application of MaxMemInQueues

many seem to believe that MaxMemInQueues should be set to 75-80% of available memory but this is painfully (in the sense of OOM crashes) incorrect

proper advice is to set MaxMemInQueues to 45% of physical memory available for the instance, assuming DisableAllSwap=1 is also in effect; 40% is a safer, more conservative value

one of my relays configured with MaxMemInQueues=1024MB recently emitted

We're low on memory.  Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.)
Removed 1063029792 bytes by killing 1 circuits; 21806 circuits remain alive. Also killed 0 non-linked directory connections.  

after which the tor daemon was observed to consume precisely 2GB per /proc//status:VmRSS

the aforementioned incorrect advice was followed in #22255 (moved) and the operator continues to experience OOM failures

another mitigation is to establish conservative linux memory management with the sysctl settings

vm.overcommit_memory = 2 vm.overcommit_ratio = X

where X is set such that /proc/memifo:CommitLimit is approximately 80% of physical memory (90% if 16GB or more is present)

The settings will prevent sparse-memory applications from running (e.g. ASAN instrumented code), but is appropriate for dedicated tor relays systems. Effectively disables OOM killer and should result in graceful memory exhaustion behavior, though I have not investigated tor daemon response in the face of malloc() fails returning null pointers.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information