[tor-bugs] #24737 [Core Tor/Tor]: oft given MaxMemInQueues advice is wrong

[Tor Bug Tracker & Wiki]

#24737: oft given MaxMemInQueues advice is wrong
----------------------------+----------------------------------
 Reporter:  starlight       |          Owner:  (none)
     Type:  defect          |         Status:  new
 Priority:  Medium          |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor    |        Version:
 Severity:  Normal          |     Resolution:
 Keywords:  doc, tor-relay  |  Actual Points:
Parent ID:                  |         Points:
 Reviewer:                  |        Sponsor:
----------------------------+----------------------------------
Changes (by teor):

 * keywords:   => doc, tor-relay
 * milestone:   => Tor: unspecified


Comment:

 I'm not sure what you want us to do in response to this ticket.
 If you can write up a short wiki page with some advice, we could point to
 it rather than trying to guess the right setting.

 Replying to [ticket:24737 starlight]:
 > 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

 I don't think percentages are helpful - I think creating a table with free
 RAM to MaxMemInQueues values would be more helpful. (See below.)

 > 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/<tor-pid>/status:VmRSS

 To be more precise: MaxMemInQueues doesn't track destroy queues, nor does
 it track various other Tor data structures,
 So you have to set it at a level that allows space for a few hundred
 megabytes of Tor data, and then some destroy queues.

 At 1024 MB per instance, this means 512 MB or less.

 But with 10 GB per instance, it really is ok to allow 5-7 GB in queues.
 (I have a relay that allows the default 8 GB in queues, and it's fine.)

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

 Are you the operator?
 Have they tried 0.3.2.8-rc and reopened another ticket?

 > …
 >
 > 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.

 The tor daemon will assert and exit if malloc returns NULL.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24737#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online