Response of Qwen3.6-35B-A3B-UD-IQ4_XS.gguf (visual formating converted to bbcode on google A.I),
Let's clear up a few misconceptions first, then tackle the real bottlenecks and how to fix them.
1. `top` output: `SIZE=531M, RES=333M`
- `SIZE` = Virtual memory (includes shared libraries, memory-mapped files, swap, etc.). Not physical RAM.
- `RES` = Resident Set Size = actual physical RAM qBittorrent is using right now. 333M is normal for ~500MB limit + metadata overhead.
- qBittorrent is NOT using 4GB. The 4GB system-wide usage is ZFS ARC, kernel caches, other processes, and swap-backed pages.
2. Why qBittorrent's "Memory Limit" Doesn't Cap Total RAM
The memory limit in qBittorrent
only controls internal caches (piece cache, DNS cache, some connection buffers). It does
not cap:
- Torrent metadata (2200 torrents × peer lists, trackers, file trees, resume data)
- OS page cache / ZFS ARC
- Socket buffers, thread stacks, or shared libraries
With 2200 torrents, even with caching disabled, qBittorrent will hold significant in-memory state. This is expected, not a bug.
3. Why Swap is at 3.5GB/4GB
This is your real problem. Swap thrashing on FreeBSD + ZFS + 8GB RAM usually comes from:
- ZFS ARC spilling to swap despite `vfs.zfs.arc_max=536870912`. ZFS may still use swap for metadata, intent logs, or if `vm.swappiness` is too high.
- USB drives in a ZFS stripe: USB 3.0/2.0 can cause high I/O latency. Processes waiting on disk get paged out, inflating swap.
- qBittorrent connection/peer bloat: 2200 torrents × active peers × DNS/resolution threads can exhaust RAM, forcing the kernel to swap.
4. `mmap` vs `pwrite/pread` for Seeding
- `mmap`: Lets the OS page cache files. Efficient for seeding, but unpredictable memory usage. The kernel may keep pages in RAM longer than qBittorrent wants, causing OOM/swap pressure.
- `pwrite/pread` (Simple Read/Write): qBittorrent controls reads/writes directly. Better for memory-constrained systems because it bypasses aggressive OS caching and respects your cache limits.
- The default change in qBittorrent was indeed due to `mmap` causing OOM crashes on Linux with large torrents. FreeBSD's VFS handles `mmap` slightly differently, but the principle holds: stick with `pwrite/pread` if you're memory-bound.
5. Bug or Configuration?
Configuration + workload mismatch. qBittorrent is behaving as designed. The swap pressure comes from:
- ZFS + OS caching competing with qBittorrent
- 2200 torrents holding metadata in RAM
- USB-backed ZFS causing I/O stalls → processes waiting → swap usage
- `vm.swappiness` likely too high for a seedbox
Actionable Fixes
qBittorrent Settings
Code:
Disk cache: Off (or 64MB max)
I/O type: Simple read/write (pwrite/pread)
File pool size: 1
Memory limit: 256-512MB (you're good)
Connections: Global ≤ 200, Per torrent ≤ 50
Enable: "Close torrent when removed from list"
Disable: "Append .part extension" (if not already)
FreeBSD/ZFS Tuning
Add to `/etc/sysctl.conf`:
Code:
vfs.zfs.arc_max=536870912 # 512MB (you have this)
vfs.zfs.l2arc_noprefetch=0 # Helps if you ever add L2ARC ie Skip caching prefetched buffers (LEGACY)
kern.maxfiles=200000 # Prevents socket/descriptor limits
Check ZFS swap pressure:
Code:
swapinfo -h
arcstat -i 2 # Look at "c" (cache size) and "s" (spilled)
zpool iostat 1 # Check if USB drives are bottlenecking
qBittorrent Session Management
- Don't keep 2200 torrents loaded if you're not actively managing them. Use RSS feeds or auto-management rules to pause/remove inactive ones.
- Enable `Preferences > Advanced > "Use subcategories for torrent categories"` to auto-pause/remove based on age/size.
- Consider `--session-dir` on a RAM disk if resume data is causing bloat.
Alternative if qBittorrent Still Swaps
- Transmission has lower per-torrent memory footprint.
Quick Diagnostic Commands
Code:
top -o res -s 2 | head -20 # Sort by memory, 2 iterations
vmstat 2 5 # Check si/so (swap in/out)
swapinfo -h # Swap usage breakdown
zpool status # USB drive health/errors
Bottom Line
- qBittorrent is using ~333MB RES. The 4GB system usage is ZFS + OS + swap.
- Swap at 3.5GB means your system is under memory pressure, likely from ZFS + USB I/O latency + 2200 torrents.
- `pwrite/pread` is correct for your use case. `mmap` would likely make swap worse.
- This is not a bug, but a resource allocation mismatch. Monitor ZFS spill, limit active torrents, and consider offloading inactive ones.
If you share `swapinfo -h`, `arcstat -i 2`, and `zpool iostat 1`, I can pinpoint whether ZFS or qBittorrent is driving the swap.
