Hi,
I am experiencing trouble with a new VPS relay.
https://atlas.torproject.org/#details/41F07731207742860D43AC426FBAE2F3947BD1...
It spontaneously acquired an advertised bandwidth of 2.67MB/s but then started to sputter.
Failing because we have 1314 connections already ...
Specifically, looking at
/proc/user_beancounters
numtcpsock is the culprit, which is limited to 1360 (some other processes are using the remaining sockets). This artificial limit causes new connections to fail even though send/receive buffers or CPU usage are well below critical.
The value can't be changed from inside the OpenVZ container. That's a pity because traffic appears to be unmetered and a lot of potential is wasted this way.
I understand that there is currently no way to limit this inside the Tor process because every relay needs to be ready to connect to every other relay at any time.
So I tried to get its consensus weight down. Gradually lowering the MaxAdvertisedBandwidth to 300k caused it to briefly acquire the "Stable" flag and run into trouble again.
That's no better than a home connection. Worse, in fact, because the problem persists.
I'm curious, is this a common experience?
Asking customer service would mean explicitly drawing attention to the fact that I'm trying to use the cheap plan to run Tor nodes. That's completely against my instincts. On the other hand they *did* offer a free-form box in the registration form.
Has anyone tried and if so, to any avail?
Is there a workaround I'm missing? iptables can be configured freely, but I don't see how that would help.
At this point I'll probably call it a day, try elsewhere and set this one up as a bridge instead.
Frankly I was a bit surprised that technical snags like this aren't generally mentioned in relay setup guides or FAQs. For all I know, it may be common knowledge among expert sysadmins that OpenVZ should be shunned or whatever, but to someone with little prior experience as a user of commercial hosting, some of these limitations come as a surprise.
In a bout of post factum searching, I only found this discussion
https://serverfault.com/questions/698845/debian-limit-number-of-tcp-sockets-...
IMHO this kind of knowledge should be spread more "pro-actively", which is why I'm posting this on a public list.
Peace, Erik