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 [email protected]: > 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 > <[email protected]> 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/5FEB80D4DCC63180CB4D87C1222177BB099E55AE >> [2] https://community.torproject.org/relay/relays-requirements/ >> -------- Original Message -------- >> On 26/03/2024 08:54, Alessandro Greco via tor-relays >> [email protected] 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: >> > >> >> > 1. In your opinion, is it preferable to maintain automatic updates to >> > ensure maximum security, even if frequent restarts may compromise the >> > node's stability? >> > 2. 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? >> > 3. 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/47B72187844C00AA5D524415E52E3BE81E63056B >> > [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 >> > [email protected] >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> >> >> _______________________________________________ >> tor-relays mailing list >> [email protected] >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> _______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
