On 4 Jan 2018, at 09:24, teor teor2345@gmail.com wrote:
there are about a million extra clients on the network since December. See this email for details:
https://lists.torproject.org/pipermail/tor-relays/2017-December/014002.html
If this is causing your relay issues, here are the things you can try:
RAM:
Set MaxMemInQueues to half your available RAM per tor instance. (It doesn't track all of Tor's memory usage.)
If your machine has one relay, if you have this much RAM, try this setting: 4 GB -> MaxMemInQueues 512 MB 8 GB -> MaxMemInQueues 2 GB 16 GB -> MaxMemInQueues 4 GB 32 GB -> MaxMemInQueues 8 GB
(If you have more than one relay on the machine, divide MaxMemInQueues by the number of relays. If you still have RAM issues, take down one relay.)
To decrease the risk of a Linux kernel oops, you might want to increase vm.min_free_kbytes. We recommend something like:
vm.min_free_kbytes=131072
(Check the existing value, and don't make it lower.) This gives the kernel extra RAM for large amounts of network traffic.
File descriptors / sockets:
Increase file descriptors for your tor user, or set ConnLimit to the number of file descriptors available to tor.
Sorry, this advice about file descriptors is wrong.
If Tor is running out of file descriptors, increase the file descriptors allocated to the user at the OS level.
If Tor is running out of CPU and has a lot of connections (over 10,0000), decrease the file descriptors allocated to the user.
You can do this on Debian Linux using a systemd drop-in: LimitNOFILE=10000
As a last resort, try setting:
DisableOOSCheck 1
But it's known to kill too many OR connections, so turn it off after the load passes.
T
-- Tim / teor
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------