
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thank you to all who responded to my question!<div class=""><br class=""></div><div class="">The memory issue seems to be fixed now, and I would like to share what worked (and what didn’t).</div><div class=""><br class=""></div><div class="">I first tried setting MaxMemInQueues to 512, then 384, while still running Tor 0.2.5.16. This didn’t help.</div><div class=""><br class=""></div><div class="">Adding the option DisableOOSCheck 0 caused an error that prevented Tor from starting.</div><div class=""><br class=""></div><div class="">I then upgraded Tor to 0.3.2.9. With this version, setting MaxMemInQeues to 384 seems to have fixed the problem, with no other changes to /etc/tor/torrc.</div><div class=""><br class=""></div><div class="">Tor has been running for 29 hours with memory usage hovering around 85%, while average throughput is close to 10 megabytes per second.</div><div class=""><br class=""></div><div class="">For any who are interested, additional details about the relay in question are available here:</div><div class=""><br class=""></div><div class=""><a href="https://atlas.torproject.org/#details/0964EEEF3AEF8442F510F8A61370657BC6E0E098" class="">https://atlas.torproject.org/#details/0964EEEF3AEF8442F510F8A61370657BC6E0E098</a></div><div class=""><br class=""></div><div class="">George W. Maschke</div><div class=""><a href="https://georgemaschke.net" class="">https://georgemaschke.net</a></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 31, 2018, at 4:02 AM, teor <<a href="mailto:teor2345@gmail.com" class="">teor2345@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><br class=""><br class=""><div class="">On 31 Jan 2018, at 10:45, r1610091651 <<a href="mailto:r1610091651@telenet.be" class="">r1610091651@telenet.be</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, 28 Jan 2018 at 11:06 teor <<a href="mailto:teor2345@gmail.com" class="">teor2345@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><br class=""><div class=""><br class=""></div></div><div dir="auto" class=""><div class="">Try to make sure MaxMemInQueues allows 10-20s of traffic.</div><div class=""><br class=""></div><div class=""><br class=""></div></div></blockquote><div class="">Hi teor</div><div class=""><br class=""></div><div class="">That advice is quite sensible in my opinion and should be incorporated into tor mainline. With the recent load spikes, I've always wanders why is there a need for that may MB or even GB of queue memory. If it can't be retransmitted in few seconds, it will be retransmitted by source and will increase the queues further...</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Tor doesn't work like TCP.</div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Clients do give up and retry after about 10-20s.</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class="">But if a circuit is broken by discarding cells, then the entire circuit needs</div><div class="">to be rebuilt, and the request sent again. And the client will probably</div><div class="">choose another path, that isn't as congested.</div><div class=""><br class=""></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">A large MaxMemInQueues keeps circuits from breaking during traffic</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">spikes.</span></div><div class=""><br class=""></div><div class="">But you're right, if the whole network is overloaded, it leads to a lot of large</div><div class="">buffers that don't do much.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">The current setting for maxmeminqueue is 256MB and will correct itself if lowered. I would suggest to make that value rate dependent, either configured or measured.</div><div class=""><br class=""></div><div class=""> To your knowledge, was there any thought put into such a dynamic config, instead of fixed percentage of free memory, independent of the actual throughput?</div></div></div></div></blockquote><div class=""><br class=""></div>There's a ticket to make it lower:<div class=""><a href="https://trac.torproject.org/projects/tor/ticket/24782" class="">https://trac.torproject.org/projects/tor/ticket/24782</a></div><div class=""><br class=""></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">One problem with dynamic limits is that they don't handle traffic spikes well.</span></div><div class="">So we don't want to make it too low, because if your relay has the RAM,</div><div class="">it should use it.</div><div class=""><br class=""></div><div class="">T</div><div class=""><br class=""></div></div>_______________________________________________<br class="">tor-relays mailing list<br class=""><a href="mailto:tor-relays@lists.torproject.org" class="">tor-relays@lists.torproject.org</a><br class="">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays<br class=""></div></blockquote></div><br class=""></div></body></html>