#24782: Set a lower default MaxMemInQueues value
---------------------------------+------------------------------------
Reporter: teor | Owner: ahf
Type: defect | Status: assigned
Priority: Medium | Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-relay, tor-ddos | Actual Points:
Parent ID: | Points: 0.5
Reviewer: | Sponsor:
---------------------------------+------------------------------------
Comment (by dgoulet):
Replying to [comment:6 teor]:
> Replying to [comment:5 dgoulet]:
> > We could also explore the possibility for that value to be a moving
target at runtime. It is a bit more dicy and complicated but because Tor
at startup looks at the "Total memory" instead of the "Available memory"
to estimate that value, things can go badly quickly if 4/16 GB of RAM are
available which will make Tor use 12GB as a limit... and even with a
fairly good amount of swap, this is likely to be killed by the OOM of the
OS at some point.
> >
> > On the flip side, a fast relay stuck with an estimation of 1GB or 2GB
of RAM that Tor can use at startup won't be "fast" for much long before
the OOM kicks in and start killing old circuits.
>
> This is not what I have observed. I have some fast Guards. Under normal
load they don't ever use much more than 1 - 2 GB total RAM.
Oh that was in the context of the ongoing "DDoS" on the network. I also
usually never go above 1.2GB for a ~12MB/s relay but right now I'm at ~3GB
so an estimation at 1GB of RAM would just decrease my relay capabilities.
> If the fastest relay can do 1 Gbps, then that's 125 MB per second. 12 GB
of RAM is 100 seconds of traffic. Is it really useful to buffer 100
seconds of traffic? (Or, under the current load, tens of thousands of
useless circuits?)
>
> So I'm not sure if using more RAM for queues actually helps. In my
experience, it just increases the number of active connections and CPU
usage. I don't know how to measure if this benefits or hurts clients. (I
guess I could tweak my guard and test running a client through it?)
I think this could come down to lots of traffic being queued because the
next hops are overloaded so if you relay is very big, Tor is happy to keep
it while waiting to relay the cells to the much slower next hop. However,
I'm seriously uncertain about this and if it is even really what is
happening... Need more investigation on my part.
[snip]
Yeah the rest of your response is good knowledge and I'm honestly also
uncertain of what to do for now either.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24782#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
