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