[tor-relays] Tor relay - hardware upgrade and "Observed bandwidth" not changed
Hello, I recently upgraded the hardware of my Tor relay and the "Advertised Bandwith" did not change. https://metrics.torproject.org/rs.html#search/pelote :9001 > Bandwidth rate: 1024 MiB/s > Bandwidth burst: 1024 MiB/s > Observed bandwidth: 5.46 MiB/s :9101 > Bandwidth rate: 1024 MiB/s > Bandwidth burst: 1024 MiB/s > Observed bandwidth: 4.62 MiB/s My Internet provider allow: - 1 Gbit/s download - 600 Mbit/s upload The relay new hardware is "NUC8i5BEK" - Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz - 8GB DDR4 SDRAM PC4-19200 - Samsung SSD 950 PRO 256GB nvme System: - OpenBSD 6.7 - tor-0.4.2.7 Relay configuration is done with https://github.com/nusenu/ansible-relayor No IPv6 (yet). Do I have to wait for something like "The lifecycle of a new relay" ? https://blog.torproject.org/lifecycle-new-relay Regards, Lilyus publickey - lilyus@pm.me - 0xE4C91EA6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor relay occasionally maxing out CPU usage
Another thing, from the change-log: - Update the message logged on relays when DirCache is disabled. Since 0.3.3.5-rc, authorities require DirCache (V2Dir) for the Guard flag. Fixes bug 24312; bugfix on 0.3.3.5-rc. If I understand this correctly, my relay would no longer be a Guard if I choose to disable DirCache in order to prevent Tor from hogging my CPU? From the code that I have seen, simply not setting the directory port does not stop the relay from caching / compressing diffs. Or has this been changed more recently? Not being a guard would honestly suck, and being a guard but with limited bandwidth due to Tor hogging the CPU also sucks. Any ideas on what to do? 2020-05-19 13:43 GMT, William Kane : > Dear Alexander, > > I have added 'Log [dirserv]info notice stdout' to my configuration and > will be monitoring the system closely. > > Tor was also upgraded to version 0.4.3.5, and the linux kernel was > upgraded to version 5.6.13 but I do not think this will change > anything. > > Expect a follow-up within the next 12 hours. > > William > > 2020-05-18 1:40 GMT, Alexander Færøy : >> Hello, >> >> On 2020/05/17 18:20, William Kane wrote: >>> Occasionally, the CPU usage hit's 100%, and the maximum throughput >>> drops down to around 16 Mbps from it's usual 80 Mbps. This happens >>> randomly and not a fixed intervals which makes it pretty hard to >>> profile. >> >> One of the subsystem's that I can think of that could potentially lead >> to the problem that you are describing is our "consensus diff" >> subsystem. The consensus diff subsystem is responsible for turning >> consensus documents into these patch(1)-like diffs that clients can >> fetch without the need to transfer the whole consensus for each minor >> change. >> >> The subsystem also takes care of compression, which includes LZMA, which >> is a beast when it comes to burning CPU cycles. >> >>> No abnormal entries in the log files. >> >> I suspect you're logging at `notice` log-level, which is the reasonable >> thing to do. We need to log at slightly higher granularity to discover >> the problem here. >> >> Could I get you to add `Log [dirserv]info notice syslog` to your >> `torrc`? This line makes Tor log everything at notice log-level (the >> default), to the system logger, except for the directory server >> subsystem, which will be logged at `info` log-level instead. The code >> responsible for generating consensus diffs uses the `dirserv` for >> logging purposes. >> >> If the CPU spike happens right after a log message that says something >> in the line of "The most recent XXX consensus is valid-after XXX. We >> have diffs to this consensus for XXX/XXX older XXX consensuses. >> Generating diffs for the other XXX." then I think we have our winner. >> >> Please remember to remove the `info` log-level when the experiment is >> over :-) >> >> I'm curious what you figure out here. Let me know if you need any help. >> >> All the best, >> Alex. >> >> -- >> Alexander Færøy >> ___ >> 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
Re: [tor-relays] Tor relay occasionally maxing out CPU usage
Okay, so your suspicion was just confirmed: consdiffmgr_rescan_flavor_(): The most recent ns consensus is valid-after 2020-05-19T15:00:00. We have diffs to this consensus for 0/25 older ns consensuses. Generating diffs for the other 25. Right after, diffs were compressed with zstd and lzma, causing the CPU usage to spike. Disabling DirCache still gives me the following warning on Tor 0.4.3.5: May 19 17:56:42.909 [warn] DirCache is disabled and we are configured as a relay. We will not become a Guard. So, unless I sacrifice the Guard flag, there doesn't seem to be a way to fix this problem in an easy way. Please correct me if I'm wrong. 2020-05-19 15:07 GMT, William Kane : > Another thing, from the change-log: > > - Update the message logged on relays when DirCache is disabled. > Since 0.3.3.5-rc, authorities require DirCache (V2Dir) for the > Guard flag. Fixes bug 24312; bugfix on 0.3.3.5-rc. > > If I understand this correctly, my relay would no longer be a Guard if > I choose to disable DirCache in order to prevent Tor from hogging my > CPU? > > From the code that I have seen, simply not setting the directory port > does not stop the relay from caching / compressing diffs. > > Or has this been changed more recently? > > Not being a guard would honestly suck, and being a guard but with > limited bandwidth due to Tor hogging the CPU also sucks. > > Any ideas on what to do? > > 2020-05-19 13:43 GMT, William Kane : >> Dear Alexander, >> >> I have added 'Log [dirserv]info notice stdout' to my configuration and >> will be monitoring the system closely. >> >> Tor was also upgraded to version 0.4.3.5, and the linux kernel was >> upgraded to version 5.6.13 but I do not think this will change >> anything. >> >> Expect a follow-up within the next 12 hours. >> >> William >> >> 2020-05-18 1:40 GMT, Alexander Færøy : >>> Hello, >>> >>> On 2020/05/17 18:20, William Kane wrote: Occasionally, the CPU usage hit's 100%, and the maximum throughput drops down to around 16 Mbps from it's usual 80 Mbps. This happens randomly and not a fixed intervals which makes it pretty hard to profile. >>> >>> One of the subsystem's that I can think of that could potentially lead >>> to the problem that you are describing is our "consensus diff" >>> subsystem. The consensus diff subsystem is responsible for turning >>> consensus documents into these patch(1)-like diffs that clients can >>> fetch without the need to transfer the whole consensus for each minor >>> change. >>> >>> The subsystem also takes care of compression, which includes LZMA, which >>> is a beast when it comes to burning CPU cycles. >>> No abnormal entries in the log files. >>> >>> I suspect you're logging at `notice` log-level, which is the reasonable >>> thing to do. We need to log at slightly higher granularity to discover >>> the problem here. >>> >>> Could I get you to add `Log [dirserv]info notice syslog` to your >>> `torrc`? This line makes Tor log everything at notice log-level (the >>> default), to the system logger, except for the directory server >>> subsystem, which will be logged at `info` log-level instead. The code >>> responsible for generating consensus diffs uses the `dirserv` for >>> logging purposes. >>> >>> If the CPU spike happens right after a log message that says something >>> in the line of "The most recent XXX consensus is valid-after XXX. We >>> have diffs to this consensus for XXX/XXX older XXX consensuses. >>> Generating diffs for the other XXX." then I think we have our winner. >>> >>> Please remember to remove the `info` log-level when the experiment is >>> over :-) >>> >>> I'm curious what you figure out here. Let me know if you need any help. >>> >>> All the best, >>> Alex. >>> >>> -- >>> Alexander Færøy >>> ___ >>> 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
Re: [tor-relays] Tor relay occasionally maxing out CPU usage
Dear Alexander, I have added 'Log [dirserv]info notice stdout' to my configuration and will be monitoring the system closely. Tor was also upgraded to version 0.4.3.5, and the linux kernel was upgraded to version 5.6.13 but I do not think this will change anything. Expect a follow-up within the next 12 hours. William 2020-05-18 1:40 GMT, Alexander Færøy : > Hello, > > On 2020/05/17 18:20, William Kane wrote: >> Occasionally, the CPU usage hit's 100%, and the maximum throughput >> drops down to around 16 Mbps from it's usual 80 Mbps. This happens >> randomly and not a fixed intervals which makes it pretty hard to >> profile. > > One of the subsystem's that I can think of that could potentially lead > to the problem that you are describing is our "consensus diff" > subsystem. The consensus diff subsystem is responsible for turning > consensus documents into these patch(1)-like diffs that clients can > fetch without the need to transfer the whole consensus for each minor > change. > > The subsystem also takes care of compression, which includes LZMA, which > is a beast when it comes to burning CPU cycles. > >> No abnormal entries in the log files. > > I suspect you're logging at `notice` log-level, which is the reasonable > thing to do. We need to log at slightly higher granularity to discover > the problem here. > > Could I get you to add `Log [dirserv]info notice syslog` to your > `torrc`? This line makes Tor log everything at notice log-level (the > default), to the system logger, except for the directory server > subsystem, which will be logged at `info` log-level instead. The code > responsible for generating consensus diffs uses the `dirserv` for > logging purposes. > > If the CPU spike happens right after a log message that says something > in the line of "The most recent XXX consensus is valid-after XXX. We > have diffs to this consensus for XXX/XXX older XXX consensuses. > Generating diffs for the other XXX." then I think we have our winner. > > Please remember to remove the `info` log-level when the experiment is > over :-) > > I'm curious what you figure out here. Let me know if you need any help. > > All the best, > Alex. > > -- > Alexander Færøy > ___ > 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
[tor-relays] warn message in notices .log after reinstallation of the relay (and restore of torrc and "keys" folder)
Hi, I had issues with my bridge who is running on a Raspberry pi 3+ so i've decided to completely reinstall it. First i saved my torrc file and my "keys" folder from /var/lib/tor. First thing i did after a clean install of the server was to copy and paste my torrc file in /etc/tor/ and the files "ed25519_master_id_secret_key" and "secret_id_key" in the keys directory. Anyway after starting Tor i had the following messages in notices.log: [warn] http status 400 '"looks like your keypair has changed?...etc...etc... i decided to completely replace the content of the keys folder by my backup but i still have the same message. When i go to Tor relay search i see my bridge with two different identities and both are offline ( one of the hashed fingerprints is the right one). Anyway if i run "nyx" i can see that Tor is working, reachable from the outside and some circuits are built. I suspect i make a mistake with the "keys" but i'm a little bit lost. Can you guys help me please ? Sent with [ProtonMail](https://protonmail.com) Secure Email.___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
