Also, when a Tor relay goes offline, the traffic is redistributed across the Tor network. It is unlikely you would receive the high speed traffic of a node just because it went offline, unless a few HIGHLY unlikely variables occur.
Also, all of the clients will be completely disconnected which were using the Tor server; it is impossible to "re-patch" the connections, given the anonymous nature of Tor. On Wed, Dec 3, 2014 at 4:07 PM, Austin Bentley <ab...@mst.edu> wrote: > Hey bud, > > Your adsl connection has a low advertised bandwidth, and doesn't make many > connections with regards to tor; thus, the CPU usage is correct. Look up > your server's fingerprint or nickname on Tor Globe to see how much of the > tor network travels through your server. > > CPU load is usually associated with a lot of bandwidth or a inefficiency > in the server. I've heard that a 100mbit tor server using full 12.5MB/s > up/down will saturate the core dedicated to the Tor process; this is > presumably why a lot of servers run multiple Tor instances on different > cores and IP addresses. However, in your case, it is likely > > The large amount of connections is generally caused by a few things: > 1. You've been running a very stable server for a long period of time and > have sufficient bandwidth to provide connectivity for a large number of > clients; additional flags, such as Guard, HSDir, V2Dir, and Exit will > likely result in more connections. This is not likely with your server, > given your advertised bandwidth is only 68.44kb/s. > 2. A single client is using your server for a lot of connections. > 3. An anomaly/attack in the Tor network (somewhat unlikely, I don't know > if any have been documented.) > 4. An attack against your server. This is very hard to do through the Tor > network; an attack against a Tor relay using Tor is an attack against all > Tor relays. HOWEVER, they could be attacking your port which you use to > host your tor server. > > > Just for reference, here's my tor stats: > Advertised B/W: ~4MB/s > Connections (555 inbound, 5 outbound, 93 exit, 1 socks, 5 circuit, 1 > control) > Tor is averaging 9%-13% CPU usage; 198MB memory. > > More info on my server: > > https://globe.torproject.org/#/relay/EF84089646304169F439A8F473742D74F027BA1B > > > > I hope this answered your question, if not, send a reply and hopefully > I'll reply sometime. > > On Wed, Dec 3, 2014 at 2:22 PM, webmaster <webmas...@defcon-cc.dyndns.org> > wrote: > >> >> Am 03.12.2014 um 19:04 schrieb Toralf Förster: >> > On 12/03/2014 06:17 PM, webmaster wrote: >> >> At first I thought: Fuck, someone intruded into my machine. >> >> But after some looking through Arm I found many (>100) INBOUND >> connections. >> > "many" ? >> > >> > I do have usually something like this : >> > Connections (782 inbound, 458 outbound, 245 exit, 1 control): >> > for and advertised bandwidth of 4 MBit, so >100 are quite normal. >> > >> > Probably you should raise the ulimit, I do have for da dedicated server >> (and Gentoo) : >> > >> > tfoerste@tor-relay ~ $ cat /etc/conf.d/tor >> > # >> > # Set the file limit >> > rc_ulimit="-n 30000" >> > >> >> I'm running the server through a relatively slow adsl connection >> (6,9 MBit/s down, 733 kBit/s up). Advertised Bandwidth: 68.44 kB/s. >> >> My ulimit is set to 1024 (os default). I will keep the ulimit setting at >> the default value because i see now reason for increasing it. >> >> Actually my server handles 28 inbound, 5 outbound and 14 circuits. The >> load is approx. 2%. >> >> From my point of view this strange behavior isn't common for my tor >> server because usually the cpu load of the tor process is below 10%. >> >> >> What happens to the tor network when a tor server with high bandwidth >> goes off-line? Maybe this could be a reason? >> >> >> -- >> -----BEGIN PGP PUBLIC KEY BLOCK----- >> Version: GnuPG v2.0.17 (MingW32) >> >> mQENBFHMmT8BCAC0smvU7Bq1ABxAhvBRn7d4ekkk95aCE4TTQo4wy1z/rGLhQfdt >> dhiD+Vy61vGrsdK3ei5sW6rBvX2m8+YmBi+8AAgSiZmS0JM3Zz3cmTi5oh0D/yM8 >> 4aDj7wQYfJyzSmYN8InAQ5eA77lwIdqG27kR9wga2szeJwCnWReta0R+7YFkpUW+ >> zUlf4SWcUx5SmBsaiELQpm+Qcn+fyopo12RX6YVmoNPBvN2nDXDnRhUCKGc+0xhD >> UrBpCHrApK6sTnMsD34ClCLTL2L1gckQ0AsQqY3PJlx3R8kIJxlmr6R3WnjPMIG0 >> lqrukB9PcOrHM1MZXK1gK6AtypHBN98lr8Z9ABEBAAG0KndlYm1hc3RlciA8d2Vi >> bWFzdGVyQGRlZmNvbi1jYy5keW5kbnMub3JnPokBPgQTAQIAKAUCUcyZPwIbIwUJ >> CWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQcN1vxvRQl+0SEwf+KXjf >> YtiSUSVS11uqeQ/8g46NwmNa91P3toZvEd7vhLSbjnL9bi/vApzNnUTGT3VP4/NA >> dg9SbR4qKlSr8T+YikRMV3tiuiVq8m7g00qM9y8MIomwJTounz8VdO/aJXFSOxAK >> Bb6ElREADspCzr2qSZCnozWUzbd+b8owbGeRRq3e33Aa5Nlm/xDRxGDWANbaIA8q >> Gkibvy3vWEwrxiwsakvHGaEZnPEtlNm3M1xcmFAuyl73qzUMkLN0u9E/2igo4EB5 >> EdMb5Ab5hfWdljxBqJr0tsvMfSK4VkzMCbKYkTqHZIRPQnhiSBE6Yo1Q6RCl/Hht >> bkvU4RA0J+NkXMZljrkBDQRRzJk/AQgA0HojJnK0uhEkAnbmszYsf477DV+LD02s >> ZEAlLGhJlf9qYaDiPMPwaZ3nK8/PYKzPpBWfHgRQP97rLHPIVJYl3BHDa/nWeZ2b >> e/HzYhpX0djbK9qe6W/CTfGbXmC/y+4dDGB8dvtTAW3JILm7xEdwiWtywozEVy7V >> lnMK4JQvlfOh+3XO6qv71FXyuRkObvkYzqvxUYHewtvvObcVxXHP0C0O6LB44iAW >> 2boZVVuiHdudnyNAezJajPMUT8SnI0bwL6+0TgnHL4cKNUEPQljIrrvi+9nCkq7V >> uBtnsYtyoo2reoxmCbX/Z1zZsxdUcKpeJHlc5AypyN8DUJ+APJ9NnwARAQABiQEl >> BBgBAgAPBQJRzJk/AhsMBQkJZgGAAAoJEHDdb8b0UJftOY0H/1TChmQrJC/qzefW >> PK7EqFlBg3TIEXdu8JHjF42ZOgzQRfp7E2wWzEx0Y45lNXMs6Yg15hWCEDaUDF6F >> 5WZKNrP8xIldyR9Aw7fyKqjZ9UuKovqofHsCiaSO7nWzGM6GF3nBDNI9NcFve/wN >> wggyjAbohOJrJGal3N0HlG3cakqjEmjBe1gQEMC0ZPlWstb/cqqr49TNPrRmQc4P >> SyGffh8Xqhw94m1LDBXFEaYe7AxjNk1sPAVfO1rOdLF6GOun/UwgbhDQX/Rb9C3t >> AhjSgyFEiR/gfrUZ7R6SY51qOUf1lN5ZN85C/x27XoZWYlsNaH3Ei6nG+yeswBMk >> ZRMbezQ= >> =Med3 >> -----END PGP PUBLIC KEY BLOCK----- >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> >
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
