Hello Aleff,
That is up to you. I strongly suspect that the hardware is the bottleneck, but detailed specifications are required in order to determine a conclusion. Tor is currently bounded by single-thread CPU performance, with a minimum recommendation of 1 GB of RAM for non-exit relays faster than 40 Mbit/s. If your hardware does not meet these RAM requirements, upgrade it, then adjust the relay bandwidth rate limit as necessary.
Frank
Mar 27, 2024, 7:00 AM by tor-relays@lists.torproject.org:
I want to thank you for all the support replies you sent in response to my previous communication. I have carefully read through all your insights and appreciate your efforts in trying to find a solution to the issue.
After thorough consideration of the matter, I have concluded that the problem may not be due to configuration errors in the automatic updates, as initially speculated. Rather, it seems that the issue could be hardware-related, with my VPS computer potentially unable to handle a certain amount of traffic.
It's worth noting that there are no bandwidth issues, and the connection speed is high. However, I have set a RelayBandwidthRate limit of 250 Mbits. Interestingly, despite this configuration, the Tor Metrics site detects a speed of approximately 10/13 MBytes, equivalent to about 90/110 Mbits. This led me to speculate that the machine might experience an overload of operations or connections, causing it to crash temporarily. As a result, at the time of restart, Tor Statistics records the maximum speed reached up to that point (without ever reaching the set limit). Subsequently, following this theory, the Tor service restarts automatically without causing any anomalies in the service.
To address this situation, I have decided to reduce the RelayBandwidthRate limit from 250 Mbits to 100 Mbits, which falls within the minimum limits proposed by torproject. If this is the case, however, it is also true that it would be best to impose an upper limit of 80% when considering the bandwidth magnitude involving the crash event as the maximum point. I honestly don't know how I would be able to verify this and acquire this kind of data, probably doing trial and error is the way. Perhaps the ideal would be to lower the maximum bandwidth further to verify for sure that this is what it is?
Currently, I am closely monitoring the situation to assess whether this modification has a positive impact on the issue.
I will keep you updated on any progress, and I thank you once again for your support and understanding.
Best regards,
Aleff.
Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support:
- Free Software Foundation! (my.fsf.org/join?referrer=6202114)
- Electronic Frontier Foundation! (eff.org)
- Tor-Project (torproject.org)
- Signal (signal.org)
martedì 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays tor-relays@lists.torproject.org ha scritto:
Hi Alessandro,
It's good to hear from you. I have a relay in a somewhat similar situation[1], although I've only just clocked it. If you're using Debian or one of its derivatives, then you can configure the unattended-upgrades package to perform a restart at a specific time if required. This means that your relay won't restart every time an upgrade is required, but will keep itself up to date. I think configuring a time for a daily restart (if upgrade required) would be a fairly good balance between stability and reliability.
See what other people say or from your own experience, as Tor circuits are generally quite resilient and as long as you aren't a guard node I believe connections won't die because your relay is restarting.
I would also note that Tor recommends [2] an uptime or 24/7 is nice, but not required and that restarts to the daemon or node are fine. Because of this, it might not be worth worrying too much about this issue.
I hope you find some of this useful, Seth
[1] https://metrics.torproject.org/rs.html#details/5FEB80D4DCC63180CB4D87C122217... [2] https://community.torproject.org/relay/relays-requirements/ -------- Original Message -------- On 26/03/2024 08:54, Alessandro Greco via tor-relays tor-relays@lists.torproject.org wrote:
Dear Tor-Relays Mailing List Members,
I hope this email finds you well. I'm reaching out to share some observations and pose some questions regarding the management of relay node updates, particularly concerning their impact on stability and security of the service provided.
Recently, I've noticed an interesting pattern with my relay node (ID: 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed TorProject's recommendations [2] and configured automatic updates, which has led to frequent restarts of the node to keep the Tor software up-to-date. While this practice ensures high security by keeping the software updated, it seems to compromise the stability of the node itself. The Uptime value of my node has remained at a maximum of a few hours.
This situation has prompted me to reflect on what might be the best strategy to adopt. On one hand, frequent updates ensure optimal security, while on the other hand, continuous restarts may affect the user experience for those relying on the node's stability for their Tor activities.
As such, I'd like to pose some questions to the community to gather feedback and assess best practices:
- In your opinion, is it preferable to maintain automatic updates to ensure maximum security, even if frequent restarts may compromise the node's stability?
- Or would it be more sensible to adjust the update frequency, perhaps performing them once or twice a week, to ensure greater stability of the node without excessively compromising security?
- Have you had similar experiences with your relay nodes? How have you addressed this challenge and what were the outcomes?
Thank you in advance for your time and cooperation.
Best regards, Aleff.
[1] https://metrics.torproject.org/rs.html#details/47B72187844C00AA5D524415E52E3... [2] https://community.torproject.org/relay/setup/guard/debian-ubuntu/updates/
Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support:
- Free Software Foundation! (my.fsf.org/join?referrer=6202114)
- Electronic Frontier Foundation! (eff.org)
- Tor-Project (torproject.org)
- Signal (signal.org)_______________________________________________
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