Tor client performance (was Re: URGENT: patch needed ASAP for authority bug)
Richard Johnson
rdump at river.com
Wed Apr 21 00:16:12 UTC 2010
At 10:50 -0400 on 2010-04-20, Andrew Lewman wrote:
> On 04/20/2010 09:56 AM, Olaf Selke wrote:
>> yep! Sorry to bother you again with this number-of-connection issue. Tor
>> on my network status machine is a non exit relay with a rather
>> restrictive bandwidth policy of "BandwidthRate 50 KB" and
>> "BandwidthBurst 100 KB". Even this tiny middleman relay holds 10000+ tcp
>> connections. Probably this number of connections will kill most routers
>> used in residential environment.
>
> A random thought, a number of people pick paths through tor network
> based on fastest relays by bandwidth served. They think this makes
> their tor faster. As blutmagie was #1 for so long, perhaps you're
> seeing the traffic from many clients specifically picking blutmagie.
I've seen resource exhaustion on a relay [1] which has been an intermittent
middleman (up roughly 75% of the time) for a couple years. Bandwidth has
always been set fairly low in torrc (RelayBandwidthBurst 921600,
RelayBandwidthRate 307200 or less) compared to the bandwidth available on
the LAN & WAN. (If I have to find another way to throttle connections than
have tor internally manage to keep a light footprint on the host and its
upstream, I might be able to find the time to do that, and thus keep it
going.)
If my problem is caused by the same change as appears to be affecting
others, it started for me sometime between Friday PM and Monday 01:30 -0600.
I saw the following types of messages logged (in the Message Log window set
to show notice and above) repeating about 10 times per minute:
Apr 20 11:59:01.630 [Warning] Error creating network socket: Too many
open files
After catching up on tor-relays, and reading this thread, I figured I'd
test whether it was directory mirroring run amok. I unchecked "Mirror the
Relay Directory" in Vidalia.app preferences. tor crashed immediately when
I clicked Save on the preferences change [2]. I then checked my torrc for
a change, but it had not been modified for 2 weeks. Looks like there was a
write failure that the code didn't detect and handle.
I quit and relaunched Vidalia.app. I confirmed "Mirror the Relay
Directory" was still unchecked in the Vidalia.app preferences window, but
didn't toggle it on and off. When I restarted tor within Vidalia, this was
logged as I would expect for the "DirPort 9030" still being in torrc:
Apr 20 12:07:54.198 [Notice] Opening Directory listener on 0.0.0.0:9030
However, netstat shows no listener actually on 9030. After I toggled
"Mirror the Relay Directory" on and off, with saves both times, the DirPort
9030 line was removed from torrc.
Additional problems uncovered in this process:
o torrc write failure caused tor crash [2] on [1].
o DirPort was not listening in practice despite its config line still
being in torrc after the write failure, and despite it being logged
as starting.
I've now run tor for 6 hours since, with no repeat of "Error creating
network socket: Too many open files" so far. It indeed looks like it is
directory mirror connections coming in at a high rate all of a sudden,
thereby running the account out of its allocation of file
descriptors/sockets.
Richard
-------
[1]
Mac OS X, currently running release tor 0.2.1.25 in Vidalia.app 0.2.7.
-------
[2] tor crash report
Process: tor [1740]
Path: /Users/.../Applications/Vidalia.app/Contents/MacOS/tor
Identifier: tor
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: Vidalia [1734]
Date/Time: 2010-04-20 12:01:10.314 -0600
OS Version: Mac OS X 10.5.8 (9L30)
Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000008
Crashed Thread: 0
Thread 0 Crashed:
0 libSystem.B.dylib 0x9268f1a0 strncmp + 144
1 tor 0x0001d3df write_configuration_file
+ 175
2 tor 0x00043eef
connection_control_process_inbuf + 3311
3 tor 0x000286fa connection_process_inbuf
+ 266
4 tor 0x0002c84a connection_handle_read +
2410
5 tor 0x0006be7f conn_read_callback + 47
6 tor 0x000d5ded event_base_loop + 1028
7 tor 0x000d5e80 event_loop + 34
8 tor 0x0006d7f7 do_main_loop + 375
9 tor 0x0006da8b tor_main + 91
10 tor 0x00001bd2 _start + 216
11 tor 0x00001af9 start + 41
Thread 1:
0 libSystem.B.dylib 0x926ceb96
recvfrom$NOCANCEL$UNIX2003 + 10
1 tor 0x00044a52 cpuworker_main + 114
2 tor 0x000c0203 tor_pthread_helper_fn + 67
3 libSystem.B.dylib 0x926b7155 _pthread_start + 321
4 libSystem.B.dylib 0x926b7012 thread_start + 34
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x00000050 ebx: 0x0001d340 ecx: 0x00000050 edx: 0x00000005
edi: 0x000e1550 esi: 0x00000000 ebp: 0xbffff508 esp: 0xbffff4e0
ss: 0x0000001f efl: 0x00010206 eip: 0x9268f1a0 cs: 0x00000017
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037
cr2: 0x00000008
Binary Images:
0x1000 - 0x10dff7 +tor ??? (???) <1dc603ffae74f475f64f7ba2ed1f5ce9>
/Users/.../Applications/Vidalia.app/Contents/MacOS/tor
0x8fe00000 - 0x8fe2db43 dyld 97.1 (???) <458eed38a009e5658a79579e7bc26603>
/usr/lib/dyld
0x91ca9000 - 0x91cb7ffd libz.1.dylib ??? (???)
<5ddd8539ae2ebfd8e7cc1c57525385c7> /usr/lib/libz.1.dylib
0x92685000 - 0x927ecff3 libSystem.B.dylib ??? (???)
<c8f52e158bf540cc000146ca8a705958> /usr/lib/libSystem.B.dylib
0x93786000 - 0x937aafeb libssl.0.9.7.dylib ??? (???)
<5b29af782be5894be8b336c9c73c18b6> /usr/lib/libssl.0.9.7.dylib
0x9529d000 - 0x9534fffb libcrypto.0.9.7.dylib ??? (???)
<d02f7e5b8a68813bb7a77f5edb34ff9d> /usr/lib/libcrypto.0.9.7.dylib
0x9678c000 - 0x96793fe9 libgcc_s.1.dylib ??? (???)
<f53c808e87d1184c0f9df63aef53ce0b> /usr/lib/libgcc_s.1.dylib
0x96cc4000 - 0x96cc8fff libmathCommon.A.dylib ??? (???)
/usr/lib/system/libmathCommon.A.dylib
0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib
More information about the tor-relays
mailing list