The arr stack wasn't crashing, qBittorrent was thrashing

I caught a "Sonarr's down again" frustration from a household user. The actual problem wasn't Sonarr at all — Sonarr was fine. It just had a download client that was lying about being responsive.

What was happening

Sonarr's health page rotated through "Download clients are unavailable" warnings every few minutes, then clearing, then warning again. Imports were intermittent. The Sonarr UI worked normally between warnings; the warnings themselves didn't tie to any obvious load or pattern.

Sonarr's logs:

WARN  DownloadedEpisodesImportService  Failed to connect to qBittorrent: 
The operation has timed out

But qBittorrent's WebUI was returning HTTP 200 when I curled it manually. So Sonarr was wrong about it being down — or qBittorrent was responding to some requests and not others.

What I found

Three things needed to be true at the same time. First, qBittorrent's container was running with default memory limits (4 GB RAM, 1 GB swap). Second, the movies instance had been accumulating a long tail of stalled torrents over weeks. Third, qbittorrent-nox's virtual memory map had grown to ~16 TB — about 48x the box's physical RAM — because of how it tracks metadata for thousands of torrents.

$ free -h
              total        used        free      shared  buff/cache   available
Mem:          3.8Gi       3.7Gi        78Mi        12Mi        88Mi         55Mi
Swap:         1.0Gi       1.0Gi          0Bi

Swap completely full. RAM completely full. The process was alive and the TCP listener was accepting connections, but every actual operation was waiting on paging. From Sonarr's perspective, some requests returned and some timed out. That intermittent behavior is the signature of a thrashing process.

The fix

Bump the container resources. On Proxmox you can do this without a restart:

pct set 111 -memory 16384 -swap 4096
systemctl restart qbittorrent

Then for the arr containers themselves (which were also running underpowered), the same treatment with much more generous numbers since the host has 251 GB of RAM. The arr apps benefit from cache more than from cores.

The general recipe for "arr app is crashing" when it's really the download client:

1. arr health check: curl -H "X-Api-Key: $KEY" http://arr:port/api/v3/health
2. If "Download clients unavailable", curl the download client directly from
   the arr container's network. If TCP connects but HTTP hangs or is slow,
   the download client is the problem, not the arr app.
3. SSH to the download client, run `free -h`. If swap is full, you've found it.
4. Bump memory live with `pct set`. Restart the download client (NOT the arr).
5. Re-trigger arr health: POST /api/v3/command {"name":"CheckHealth"}.

What I'd do differently

Two things. First, my dashboards now graph free memory and swap on every torrent-client container, with an alert at 80% used. That's the leading indicator; "arr says download client is down" is the lagging one. Second, the systemd unit name for qBittorrent on these containers is qbittorrent.service, not qbittorrent-nox like a lot of guides say. Always check the unit name before scripting restarts — assuming the wrong name has burned me more than once.