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.