Hello,

I really need some help here. I recently started cross-seeding with Qui around 1,000 torrents, and now am up to 1,500 including the cross seeded torrents, and qbitorrent is freezing every couple of minutes and coming back after 10 seconds or so requiring a webpage reload. It's causing chaos for the trackers, and obviously nothing can finish downloading let alone upload. I think it's an IO wait issue, but below are the full details (yes I've been using chatgpt to help, but to no avail):

Storage layout:

• 5× HDD array (individual disks mounted as /mnt/disk1–/mnt/disk5) WD Pro NAS drives capable for 280MB/s

• SSD pool where torrent files are moved to before mover moves them to the array.

• NVMe pool for Docker

Torrent client: qBittorrent from the community store
VPN: Gluetun container (qB runs behind it)
Public torrents paused; private seeding active
Typical upload low, sometimes zero when issue occurs.

qBittorrent WebUI becomes unresponsive.

• Container remains running

• No crash logs, in fact nothing in logs after startup language.

• After reload, forced-seeded torrents revert to “Seeding”

• Trackers sometimes show “skipping announce (unreachable)”

• docker exec into container sometimes hangs

The concern is whether qB is crashing or something else is stalling it.

Confirmed: no memory exhaustion or CPU limitation.

docker exec -it qbittorrent sh -lc '

pid=$(pidof qbittorrent-nox);

echo "PID=$pid";

awk "/open files/ {print}" /proc/$pid/limits;

echo -n "FD in use: ";

ls /proc/$pid/fd | wc -l

'

Output:
Max open files: 40960

FD in use: 298

Container not in D state when hung.

iostat -x sample output:
Device r/s rkB/s w/s wkB/s r_await w_await aqu-sz %util

sdc 357 64372 139 58500 50ms 13ms 20.02 100%

sdg 232 57772 143 58500 7ms 4ms 2.32 55%

NVME pool largely idle.

lsof -l 2>/dev/null | grep "/mnt/disk4/" | head -80

Results in: Multiple large MKV files open

1. b3sum reading 52GB remux file

2. rsync writing multi-GB file

3. shfs readers on Plex media files

All network tests to tracker url's worked fine and returned 200 including pinging the announce URL with my passkey.

Given:

• ~1300 torrents loaded

• HDD array (non-striped)

• Heavy background hashing and rsync activity

• qB behind VPN container

• Intermittent WebUI stalls without crash

Is this expected behavior under HDD saturation, or should qB remain responsive even when backend disk I/O is blocked? It feels like I need to move my entire array onto SSD's but this just seems ridiculous. Is there anyway to setup this up avoiding the FUSE layer and user space?

Thank you,
---------------
Edit: adding some data that was output at the exact moment it's frozen.

root@Citadel:~# PID=$(pidof qbittorrent-nox)

cat /proc/$PID/stack

[<0>] do_sys_poll+0x3af/0x4a0

[<0>] __do_sys_ppoll+0x8b/0xd0

[<0>] do_syscall_64+0x68/0xe0

[<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e

root@Citadel:~# ps -o pid,comm,state,wchan:30 -p $(pidof qbittorrent-nox)

PID COMMAND S WCHAN

3970704 qbittorrent-nox S do_sys_poll

root@Citadel:~# iostat -x 1 3

Linux 6.12.54-Unraid (Citadel) 02/19/2026 x8664_ (16 CPU)

citadel-diagnostics-20260218-1255.zip

Edited February 19Feb 19 by whisp
Adding diagnostics file.

You are likely to get better informed feedback if you attach your system’s diagnostics (with everything in the one zip file) to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

Fair enough, here you are.

citadel-diagnostics-20260218-1255.zip

Looks like you have poorly configured checks that keep restarting the qbit and gluetun containers way too often probably for no good reason.

Seems the 870 EVO SSD sometimes drops and has to be reset.

Your system share has data on disk1 which FCP warns you about, If that's the Docker image/FS that'll slow things down.

Edited February 18Feb 18 by Kilrah

All of this was working despite gluetun restarts and FCP warnings. Gluetun has never worked without restarting itself at least once every 24 hours due to it's overzealous healthchecks, And I have scripts to restart qbitorrent and gluetun if necessary to keep things going while I'm away. Qbitorrent worked fine with gluetuns flakiness, it was only once I have this many torrents that it started freezing.

Is the SSD dropping recent or has that been going on for awhile?

29 minutes ago, whisp said:

Is the SSD dropping recent or has that been going on for awhile?

Current log shows one occurrence since last boot, all we can see.

29 minutes ago, whisp said:

I have scripts to restart qbitorrent and gluetun if necessary

Seeing the log it seems to be running every 5 minutes if upload is below some threshold. That's way too frequent, restarting either they'll have to check everything when starting which will take a while and increasingly more with more torrents, then it takes a while to find peers and upload to actually ramp up. Might want to check every few hours, not 5 mins.

And that's assuming you actually have stuff people want and download from you, if not you might be restarting the container and redoing the whole checking thing simply because there's not enough people who want your stuff for upload to be above the threshold you set.

End of the log shows stuff being restarted every 5 mins because of some part of that.

Edited February 18Feb 18 by Kilrah

Got it, that's good feedback. I can revise the script to have a larger cooldown to account for that. Still need to figure out why QBT is doing this and why recently though -_-