It either says too many open files or freezes (when the torrent has too many seeds)
The global peer limit is set to 38527 and per torrent peer limit is 500
max openfiles in debian is set to 500000
Code: Select all
sysctl -n fs.nr_open: 1048576 fs.file-max = 9913074 ulimit -a: ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 257803 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 500000 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 257803 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
So I dont see why transmission should be freezing with just 1 torrent of archlinux iso file that tries to create 800 peer connections (that too is weird because per torrent max peers is 500)
Transmission is the latest stable for debian jessie (2.84)
DHT and UTP are enabled (disabling them does no good either, it ends up crashing later)
transmission-daemon is running as root. (no gui, its a server)
This is the torrent file: https://www.archlinux.org/releng/releas ... 1/torrent/
Even if the torrent client is freshly started, when I add this torrent file, the webgui freezes, then I have to restart transmission daemon
lsof shows about 865 open descriptors AFTER starting this torrent.
Before starting it, it shows 23 to 26
The other issue, after starting 50 to 60 low peer torrents, new torrents start giving "cannot save resume file too many open files". Seriously? Its running on a dedicated server and it cant even handle 60 torrents?
I dont want to look for alternative clients because I have the whole system setup with transmission's rpc, ill need to hire a developer again to write new code for some other client's api.
Is this behaviour normal of there is something wrong with my servers? all 3 of my servers are have the same issue.