open file limit 1024

[emptyset]

After upgrading to 2.31, I had a variety of major problems including crashes, 100% cpu hangs, very bad seeding performance, and files getting lost when moved. In order for it to run at all, I had to reduce the peer limit, file limit and/or cache size.

Before downgrading to 2.22, I noticed what I think is the cause of all of it, as I have seen similar issues on various clients in the past. Many 'open file limit' errors in the log.

The open file limit, as found in /proc/[pid]/limits, for 2.31 daemons only, is '1024', rather than the higher limit of the system/invoking shell.

[emptyset]

This is on Ubuntu 11.04 AMD64 transmission-ppa build.

[Username]

very bad seeding performance,

Try to disable uTP support. It's current implementation is very bad - experiments shown that disabling it improves speed very well. In my config, uTP never able to exceed ~50kbytes/sec per peer while TCP can easily exceed 400kbytes/sec.

[x190]

FWIW, Mac Client initializes at 1024 but can increase that number, notably when DHT is initialized. Intel Mac 10.6.7

2011-06-08 10:10:38 -0600 fdlimit.c:797 [Debug] Transmission: setrlimit( RLIMIT_NOFILE, 1024 )

2011-06-08 23:09:17 -0600 tr-dht.c:330 [Debug] DHT: DHT initialized
2011-06-08 23:09:19 -0600 fdlimit.c:797 [Debug] Transmission: setrlimit( RLIMIT_NOFILE, 3328 )

2011-06-09 02:30:16 -0600 tr-dht.c:276 [Debug] DHT: Initializing DHT
2011-06-09 02:30:19 -0600 fdlimit.c:797 [Debug] Transmission: setrlimit( RLIMIT_NOFILE, 7936 )

[jordan]

It's intentional that the open file limit is bounded by FD_SETSIZE. This is necessary to prevent memory corruption errors in libcurl, see #4164 for more information.

Actually I'm wondering if the open-file-limit configuration setting is worth keeping around anymore. Perhaps libtransmission should automatically set it to the maximum allowed by FD_SETSIZE.