[tor-relays] We're trying out guard-n-primary-guards-to-use=2
Roger Dingledine
arma at torproject.org
Wed Jul 6 19:19:48 UTC 2022
On Mon, Jun 27, 2022 at 10:58:42PM -0400, Roger Dingledine wrote:
> So: I am giving you all here some early warning, in case you see anything
> odd on the network when we make this change. Let us know if you do. :)
So far so good. Performance looks like it improved.
The "intro2 cell" overload also stopped over the weekend (yay):
https://metrics.torproject.org/hidserv-rend-relayed-cells.html
But it was replaced with a new overload (boo), from way too many Tor
clients running at a few cloud providers. The main result for relay
operators is greatly increased file descriptor use, with a few IP
addresses or /24's generating the majority of the new connections.
If your relay is bumping up against its file descriptor limits,
or otherwise suffering (e.g. more memory usage than desired), one
reasonable option for you might be to set some iptables-level connection
limiting. More details in this ticket:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40636#note_2818529
Some of the dir auths are suffering from this connection overload too --
longclaw and bastet in particular but I think all of us are feeling it.
As I mention in that ticket, ultimately it seems to me that we'll need
to come up with a guide of recommended iptables rules for big relay
operators to run alongside their Tor. It wouldn't be mandatory (Tor has
some adequate-ish defenses here at the application layer) but it seems
clear that it would do the job better at scale.
--Roger
More information about the tor-relays
mailing list