Hello Aleff, It should be okay as-is, but I would temporarily upgrade the hardware to determine if it is the root cause.
Frank Apr 2, 2024, 10:34 AM by tor-relays@lists.torproject.org: > My computer has: > - 1 vCore CPU > - 1 GB RAM > - Maximum bandwidth: 1 GB/s > > So if I understand correctly, the problem should not be at the hardware > level, right? > > > Il mar, apr 2, 2024 alle 12:14, Frank Lý via tor-relays <> > tor-relays@lists.torproject.org <mailto:Il mar, apr 2, 2024 alle 12:14, Frank > Lý via tor-relays <<a href=>> > ha scritto: > >> 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/5FEB80D4DCC63180CB4D87C1222177BB099E55AE >> >> [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: >> >> > >> >> >> >> > 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 >> >> > 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 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
