[tor-relays] relay configuration not allowing optimal performance

Richie richie at zuviel.org
Sun Feb 26 08:15:29 UTC 2023


Hi there,

i also use enkidus DDoS-Migitationscripts and had some constant 
"overloaded" messages (along with a drop in consensus weight). Just 
reinstalling the scripts fixed the issue for me (i guess its just me 
messing up some cron stuff, nevertheless, maybe i'm not the only one).

Regarding your HW/Bandwith...

Am 25.02.23 um 14:44 schrieb Relayer via tor-relays:
> I'm running a tor relay on some older hardware that I didn't want to 
> discard when I could still put it so good use.
> 
> Some details of the box are:
> -- CPU: Intel(R) Core(TM)2 Duo CPU     P8600  @ 2.40GHz
> -- RAM: 4GB
> -- ARCH: x86_64
> -- HDD: 250GB
> -- OS: Ubuntu 22.04.1
> 

..i had quite the same processor on my previous relay. It actually 
should be able to relay some more data. If the ddos script 
reinstallation doesn't help: killing off the desktop enviroment (if not 
deactivated by default) clears up some resources.

> I originally configured a single Tor instance IPv4 to run as a relay 
> only (not as an exit, nor hosting a hidden service). I am also using the 
> iptables rules from https://github.com/Enkidu-6/tor-ddos 
> <https://github.com/Enkidu-6/tor-ddos> to minimize DDOS overhead (please 
> advise if there are alternatives or additions to this).
> 
> My original config seemed ok until I started seeing my CPU and RAM 
> maxing out consistently so I throttled back with the following in my torrc:
> 
> RelayBandwidthRate 100 KB # Throttle traffic to 100KB/s (800Kbps)
> RelayBandwidthBurst 200 KB # But allow bursts up to 200KB/s (1600Kbps)
> MaxAdvertisedBandwidth 1 MB
> 
> My RAM usage now is only about 50% or marginally less of my total available.

I think i had only 2GB on a quite similar machine and it made about 
400-600 kB. CPU/Ram on 70-80% is normal as far as i can tell. Nyx also 
grabs some processor load, though (here about 10-30%). If not needed 
permanently, i'd recommend turning it off apart from checking actual 
load/connections.

Your Box is a dual core. 100% CPU should not be a problem. I played 
around with the NumCPU-Flag in torrc back then, but 
https://forum.torproject.net/t/numcpus-best-practice-on-multi-core-multi-relay-servers/3802/10 
says one shouldn't (and i didn't get anything out of it).

> Here's how the metrics look lately:
> https://metrics.torproject.org/rs.html#details/38939B45237BA84941C74836349C152473F84C56 <https://metrics.torproject.org/rs.html#details/38939B45237BA84941C74836349C152473F84C56>
> 
> As you can see, the throughput rated dropped in half (that's when the 
> graph drops on 2023-02-09). However, the volume continued to decline.
> 
> Additionally, I'm unclear why my Middle Probability and Consensus Weight 
> have both dropped to near 0%. Are those, in fact, where I want them?

At least for me, Consensus weight is a bit difficult to interpret. It 
does not only measure your throughput, but its relation to the whole Tor 
network. If the network grows, your consensus weight drops. Here, it 
looks quite correlated to the 25-30k your Relay puts through.

> 
> I'm monitoring with nyx and see I get some traffic through with no 
> apparent errors or warnings. I am NOT seeing the CPU spikes any longer 
> but I don't think I'm giving the most with my hardware.
> 
> Questions:
> 1.) Is my tor service now misconfigured and not utilizing my hardware as 
> best it could?

As long as you don't get "overloaded" notices, i guess you'd be safe 
with, well, 400kB rate, 600kB Burst. More than 100 should definitely be 
possible.

> 2.) Should my Consensus Weight and/or Middle Probability be higher?

right now, no :) When actual throughput rises, then it should grow, too.

> 3.) Should I consider running two tor instances?

I don't see any advantages. Problem is definitely not a "its only one 
instance!". Apart from more work/configuration/overhead without 
advantage, ddos exposure maybe doubles.

greetz
Richie

> 
> Nyx log snippet:
> 07:59:32 [NOTICE] Heartbeat: DoS mitigation since startup: 7 circuits 
> killed with too many cells, 591 circuits rejected, 2 marked addresses, 0 
> marked addresses for max queue, 0 same address concurrent
> │ connections rejected, 0 connections rejected, 0 single hop clients 
> refused, 19166 INTRODUCE2 rejected.[1 duplicate hidden]
> │ 07:59:32 [NOTICE] Since startup we initiated 0 and received 0 v1 
> connections; initiated 0 and received 0 v2 connections; initiated 0 and 
> received 0 v3 connections; initiated 0 and received 57982 v4
> │ connections; initiated 116266 and received 356623 v5 connections.
> │ 07:59:32 [NOTICE] Circuit handshake stats since last time: 3/3 TAP, 
> 44849/44849 NTor.[1 duplicate hidden]
> │ 07:59:32 [NOTICE] While not bootstrapping, fetched this many bytes: 
> 194128391 (server descriptor fetch); 7140 (server descriptor upload); 
> 17539422 (consensus network-status fetch); 1794 (authority cert
> │ fetch); 2111765 (microdescriptor fetch)
> │ 07:59:32 [NOTICE] Heartbeat: Tor's uptime is 10 days 23:58 hours, with 
> 179 circuits open. I've sent 34.83 GB and received 35.63 GB. I've 
> received 444762 connections on IPv4 and 0 on IPv6. I've made
> │ 254336 connections with IPv4 and 0 with IPv6.[1 duplicate hidden]
> │ 01:59:32 [NOTICE] Since startup we initiated 0 and received 0 v1 
> connections; initiated 0 and received 0 v2 connections; initiated 0 and 
> received 0 v3 connections; initiated 0 and received 56651 v4
> │ connections; initiated 114326 and received 347071 v5 connections.
> │ 01:59:32 [NOTICE] While not bootstrapping, fetched this many bytes: 
> 189431170 (server descriptor fetch); 7140 (server descriptor upload); 
> 17131743 (consensus network-status fetch); 1794 (authority cert
> │ fetch); 2068377 (microdescriptor fetch)
> 
> Thanks.
> 
> Relayer1974
> 
> 
> 
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



More information about the tor-relays mailing list