Hi, I'm running a Tor relay on a low cost dedicated server.
The tor relay is named kingqueen and it's running on an Intel Atom N2700 dual core hyperthreaded CPU with 2gb of memory, in a data centre with a symmetric 100mbps connection.
I have found as time goes on and usage of my relay increases (about 3 weeks now) that the Tor process is increasingly using more of the CPU. TOP shows Tor using over 100% of CPU and the load average is 2 or more.
I use the dedi for other, less intensive things (OpenVPN, seedbox, also Owncloud though this falls over). I know that this is sub-optimal and ideally the dedi should be for the relay alone.
I was wondering if the CPU usage is standard. I guess it could be, given it has decryption work to be done? Is it high? Is there anything I can do to lower it, other than rate limiting, which I don't want to do?
Thank you
Hi,
In effect this CPU usage is quite normal : a Tor Relay use a lot of CPU, proportionally with amount of data passing trough the relay. With an Intel Atom D510 I was above 40 Mbps, while CPU was giving everything.
The problem with Tor is the "single-thread working" for encryption/relaying, so if you have a second CPU core available, may be you can open a second Tor instance in order to use the second core capacity.
In fact, when your Tor daemon reaches 100% of 1 core usage, you can see what is the current bandwith and set it into your torrc file as maximum. When a Tor instance exceeds 100% it's a little bit like a "congestion" into your Tor process, so it's better for 100% value to be a limit per Tor process. Your relay may average a little bit under the limit bandwidth of your torrc file, but this give better performance for Tor circuits established through your relay so it's not a bad ;)
An interesting webpage here, full of usefull informations that doesn't appear on the official tutorial : https://www.torservers.net/wiki/setup/server
Even if what you've done is more simple, or a little bit different, this tutorial will make you aware of a lot of interesting details and possibilities.
Good luck ! Julien ROBIN
----- Mail original ----- De: "kingqueen" kingqueen@btnf.tw À: tor-relays@lists.torproject.org Envoyé: Lundi 7 Juillet 2014 22:31:02 Objet: [tor-relays] CPU usage
Hi, I'm running a Tor relay on a low cost dedicated server.
The tor relay is named kingqueen and it's running on an Intel Atom N2700 dual core hyperthreaded CPU with 2gb of memory, in a data centre with a symmetric 100mbps connection.
I have found as time goes on and usage of my relay increases (about 3 weeks now) that the Tor process is increasingly using more of the CPU. TOP shows Tor using over 100% of CPU and the load average is 2 or more.
I use the dedi for other, less intensive things (OpenVPN, seedbox, also Owncloud though this falls over). I know that this is sub-optimal and ideally the dedi should be for the relay alone.
I was wondering if the CPU usage is standard. I guess it could be, given it has decryption work to be done? Is it high? Is there anything I can do to lower it, other than rate limiting, which I don't want to do?
Thank you _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Julien,
That is very useful and well explained. Thank you.
Robert
The problem with Tor is the "single-thread working" for encryption/relaying, so if you have a second CPU core available, may be you can open a second Tor instance in order to use the second core capacity.
In fact, when your Tor daemon reaches 100% of 1 core usage, you can see what is the current bandwith and set it into your torrc file as maximum. When a Tor instance exceeds 100% it's a little bit like a "congestion" into your Tor process, so it's better for 100% value to be a limit per Tor process.
On Mon, 07 Jul 2014 21:31:02 +0100 kingqueen kingqueen@btnf.tw wrote:
Hi, I'm running a Tor relay on a low cost dedicated server.
The tor relay is named kingqueen and it's running on an Intel Atom N2700 dual core hyperthreaded CPU with 2gb of memory, in a data centre with a symmetric 100mbps connection.
I have found as time goes on and usage of my relay increases (about 3 weeks now) that the Tor process is increasingly using more of the CPU. TOP shows Tor using over 100% of CPU and the load average is 2 or more.
I use the dedi for other, less intensive things (OpenVPN, seedbox, also Owncloud though this falls over). I know that this is sub-optimal and ideally the dedi should be for the relay alone.
I was wondering if the CPU usage is standard. I guess it could be, given it has decryption work to be done? Is it high? Is there anything I can do to lower it, other than rate limiting, which I don't want to do?
Hello,
Yes this is normal.
Set "NumCPUs 2" in your torrc to make it try utilizing the second core too (this won't help much, but at least somewhat).
Also you should renice tor to e.g. +10 so that it doesn't interfere with your non-Tor tasks. In Debian-based distros this should be configurable via "/etc/default/tor" config file, by setting NICE="--nicelevel 10" there.
On 7 July 2014, 04:49 UTC, Roman Mamedov wrote:
On Mon, 07 Jul 2014 21:31:02 +0100 kingqueen kingqueen@btnf.tw wrote:
Hi, I'm running a Tor relay on a low cost dedicated server.
The tor relay is named kingqueen and it's running on an Intel Atom
N2700 dual core hyperthreaded CPU with 2gb of memory, in a data centre with a symmetric 100mbps connection.
I have found as time goes on and usage of my relay increases (about 3
weeks now) that the Tor process is increasingly using more of the CPU. TOP shows Tor using over 100% of CPU and the load average is 2 or more.
I use the dedi for other, less intensive things (OpenVPN, seedbox,
also Owncloud though this falls over). I know that this is sub-optimal and ideally the dedi should be for the relay alone.
I was wondering if the CPU usage is standard. I guess it could be,
given it has decryption work to be done? Is it high? Is there anything I can do to lower it, other than rate limiting, which I don't want to do?
Hello,
Yes this is normal.
Set "NumCPUs 2" in your torrc to make it try utilizing the second core too (this won't help much, but at least somewhat).
With hyperthreading, I think 4 would be optimal? Also, I'm not a regular user of Linux, but doesn't top report load averages as a sum of all CPUs/cores/virtual cores... e.g., in this case, if the described CPU were at capacity, top would report 4.00?
If nothing else, this could be nicer to other running applications, but if tor was assuming one CPU/core previously, would actually increase the amount of CPU available to tor.
Peace, Asa
Also you should renice tor to e.g. +10 so that it doesn't interfere with your non-Tor tasks. In Debian-based distros this should be configurable via "/etc/default/tor" config file, by setting NICE="--nicelevel 10" there.
-- With respect, Roman
On Mon, 7 Jul 2014 23:30:22 -0700 "Asa Rossoff" asa@lovetour.info wrote:
With hyperthreading, I think 4 would be optimal?
Yes, 4 can be set, but I remember reading somewhere that Tor doesn't scale well beyond NumCPUs 2 (and poorly even to 2).
One way to increase utilization further would be to run a second instance of Tor. However as this server is also used for other tasks, this could begin starving them of CPU time via the hyperthreading concurrency even while Tor nominally runs at lower nice levels.
Roman Mamedov rm@romanrm.net wrote:
On Mon, 7 Jul 2014 23:30:22 -0700 "Asa Rossoff" asa@lovetour.info wrote:
With hyperthreading, I think 4 would be optimal?
Yes, 4 can be set, but I remember reading somewhere that Tor doesn't scale well beyond NumCPUs 2 (and poorly even to 2).
See my previous note in this thread. Note that NumCPUs specifies the number of [logical] CPUs available for simultaneous onionskin decryption threads to make use of. Those worker threads are not used for any other work, AFAIK.
One way to increase utilization further would be to run a second instance of Tor. However as this server is also used for other tasks, this could begin starving them of CPU time via the hyperthreading concurrency even while Tor nominally runs at lower nice levels.
It seems to me that an Atom is a tad underpowered for that sort of scheduling. One instance is enough. If the OP wishes to make better use of his network throughput capacity with tor, then he needs to get a more powerful machine to do it. Another matter to consider is that very high-throughput relays need to run on operating systems that support superpages (a.k.a. hugepages in LINUX) to reduce the large percentage of time wasted in processor stalls due to TLB thrashing. Microsoft only supports that when set up manually, IIRC. LINUX used to be likewise, but I seem to recall reading somewhere that its developers eventually wised up and made them automatic, like in FreeBSD. I have no idea whether NetBSD or OpenBSD supports superpages at all.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *or* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
Thank you to all for the useful information; especially to Roman, Julien and Scott.
I want to make optimal use of my existing dedi rather than hiring a more powerful one, so I've set NumCPUs to 2, renice to 10 and will reboot (as the latter is an init script I guess reboot is necessary.) I will then wait a couple of weeks to see what the maximum average bandwidth usage is at 200% CPU (for two cores) and will set the bandwidth limit to just below that.
Hopefully this will improve both my Tor relay's performance and allow me to continue to use the dedi for other purposes.
Thank you all once again.
kingqueen
--- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
...renice to 10...
This is good for the Tor process itself, but disadvantages other processes. If your server is doing name resolution (as an exit node) the resolver may be impacted, which in turn will hamper handling of exit traffic.
If you're running as a middle node then Never Mind.
On Tuesday, July 8, 2014 8:39am, "kingqueen" kingqueen@btnf.tw said:
Thank you to all for the useful information; especially to Roman, Julien and Scott.
I want to make optimal use of my existing dedi rather than hiring a more powerful one, so I've set NumCPUs to 2, renice to 10 and will reboot (as the latter is an init script I guess reboot is necessary.) I will then wait a couple of weeks to see what the maximum average bandwidth usage is at 200% CPU (for two cores) and will set the bandwidth limit to just below that.
Hopefully this will improve both my Tor relay's performance and allow me to continue to use the dedi for other purposes.
Thank you all once again.
kingqueen
This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tue, 8 Jul 2014 09:44:57 -0400 (EDT) "Steve Snyder" swsnyder@snydernet.net wrote:
...renice to 10...
This is good for the Tor process itself, but disadvantages other processes. If your server is doing name resolution (as an exit node) the resolver may be impacted, which in turn will hamper handling of exit traffic.
Renicing to a positive value decreases the priority of a process, not increases it. Tor at +10 will not affect any other processes, except maybe "completely idle" priority ones, which get +20.
Hello Steve,
...renice to 10...
This is good for the Tor process itself, but disadvantages other processes. If your server is doing name resolution (as an exit node) the resolver may be impacted, which in turn will hamper handling of exit traffic.
If you're running as a middle node then Never Mind.
Thank you. I'm a guard node actually (well, my dedi is) so all's well.
Cheers
--- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
"Asa Rossoff" asa@lovetour.info wrote:
On 7 July 2014, 04:49 UTC, Roman Mamedov wrote:
On Mon, 07 Jul 2014 21:31:02 +0100 kingqueen kingqueen@btnf.tw wrote:
[stuff deleted --SB]
Set "NumCPUs 2" in your torrc to make it try utilizing the second core too (this won't help much, but at least somewhat).
With hyperthreading, I think 4 would be optimal?
Probably, yes.
Also, I'm not a regular user of Linux, but doesn't top report load averages as a sum of all CPUs/cores/virtual cores... e.g., in this case, if the described CPU were at capacity, top would report 4.00?
No. top reports the average number of processes in the system in the ready-to-run state (more or less equivalent to the "dispatchable" state). This state include not only those currently dispatched, but also those that could be dispatched were enough otherwise idle [logical] CPUs available.
If nothing else, this could be nicer to other running applications, but if tor was assuming one CPU/core previously, would actually increase the amount of CPU available to tor.
On a high throughput node, it should make some difference, although the degree of difference depends upon the number of onion skins to be decrypted per unit of time. As has been stated here on multitudinous occasions, the real hangup on spreading the workload of tor across extra CPUs is that openssl is not a multithreaded library.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *or* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
tor-relays@lists.torproject.org
-
Asa Rossoff -
I -
Julien ROBIN -
kingqueen -
Roman Mamedov -
Scott Bennett -
Steve Snyder