Indeed qBittorrent behaves badly:
- I added a single torrent, the Debian DVD image: https://cdimage.debian.org/debian-cd/current/amd64/bt-dvd/debian-13.6.0-amd64-DVD-1.iso.torrent
- It connects to peers quickly and maxes out my bandwidth, so all good in this regards.
- No upload done, surely also because I do not forward the port, and qBittorrent seems to actively connect to peers for seeding only if the download is done (happened just now, indeed now upload starts), or in case of low download activity.
- We apply
Downloads\DiskWriteCacheSize=<10% of physical RAM size>, but I do not see this in the web UI settings, maybe this setting is obsolete. Also, I do not see a reason to use such a potentially still huge write cache. We should probably remove it. But that alone would still not be a huge issue.
- But I do see this:
- Despite that, qBittorrent seems to download the entire download of a torrent into memory. It raised continuously during the download. The size of the DVD is slightly lower than the RAM size of the test VM, so it finished before I could see whether it runs into OOM or not. After it finished, RAM usage dropped to expected ranges instantly. So it really was that download that got cached somehow, being written to disk after finish. That is nonsense.
- Furthermore, even long before memory went significantly full, CPU usage was 400% (on 4 cores) by times, and
htop in the SSH session stalled by times, as well as the web UI. Like when I tried to open “Options”, it loaded endlessly, progress stats did not update, and I needed to reload the whole website to restore things.
I cannot find a documentation with a list of all config file settings 
. Saving settings in the web UI seems to add valid ones, but not remove invalid ones. Here are some in the source code, but it does not contain all of them: qBittorrent/src/base/preferences.cpp at 0c6756f703b28d44a1c35bd18be95cada83d5cf5 · qbittorrent/qBittorrent · GitHub
E.g. Session\DiskCacheSize was added, copying the value from our Downloads\DiskWriteCacheSize. But that setting does not appear in prior file.
Ah, here is the list of changed (and auto-migrated) settings: qBittorrent/src/app/upgrade.cpp at 0c6756f703b28d44a1c35bd18be95cada83d5cf5 · qbittorrent/qBittorrent · GitHub
Indeed the old settings just remain in the config file, too. There is actually an “auto” value which we should use instead: Change some settings defaults for better behaviour out of the box · qbittorrent/qBittorrent@30502de · GitHub
I’ll retest with that, but a disk cache of 391 MiB does not explain the >3 GiB memory usage, which looks like there was no limit at all.
So the settings which can be changed via GUI are in qBittorrent/src/base/preferences.cpp at 0c6756f703b28d44a1c35bd18be95cada83d5cf5 · qbittorrent/qBittorrent · GitHub, but other settings which can be changed in the config file only, are distributed among other files in qBittorrent/src at master · qbittorrent/qBittorrent · GitHub, which can be roughly derived from the settings name and section.
EDIT: Retesting with a larger Ubuntu image that could exceed the VMs RAM. With DiskCacheSize=-1 (auto), it still downloads into RAM without limit so far. But at the same time, the true data seems to be written to disk as well. The file is pre-allcocated with full 6.1 GiB size, but sparse. But the true data is written as well, as can be monitored:
2026-07-30 17:37:55 root@VM-Trixie:/mnt/dietpi_userdata/downloads# du -sm ubuntu-26.04-desktop-amd64.iso
997 ubuntu-26.04-desktop-amd64.iso
2026-07-30 17:37:59 root@VM-Trixie:/mnt/dietpi_userdata/downloads# du -sm ubuntu-26.04-desktop-amd64.iso
1002 ubuntu-26.04-desktop-amd64.iso
2026-07-30 17:38:00 root@VM-Trixie:/mnt/dietpi_userdata/downloads# du -sm ubuntu-26.04-desktop-amd64.iso
1005 ubuntu-26.04-desktop-amd64.iso
2026-07-30 17:38:01 root@VM-Trixie:/mnt/dietpi_userdata/downloads# du -sm ubuntu-26.04-desktop-amd64.iso
1009 ubuntu-26.04-desktop-amd64.iso
2026-07-30 17:38:02 root@VM-Trixie:/mnt/dietpi_userdata/downloads# l ubuntu-26.04-desktop-amd64.iso
-rw-rw-r-- 1 qbittorrent dietpi 6.1G Jul 30 17:38 ubuntu-26.04-desktop-amd64.iso
So I have no idea why it is kept in memory as well.
EDIT2: Ah, here is a related bug report at Debian: https://bugs.debian.org/1111237
No answer. We need to test this on Bookworm and Forky, and with empty/default config, to pin-point it to a certain version and/or setting. The bug report indicates it appeared in Trixie, resp. between qBittorrent v4.5.2 and v5.1.0.
Nasty is that there is no source repo link in the package, and the source does not seem to be at Salsa (Debian’s GitLab instance). It was, but all related repos are out of date, hence it is now hosted elsewhere: https://salsa.debian.org/search?search=qbittorrent
Ohh wait a second: This is a misinterpretation, though also weirdly implemented:
However, this means it shouldn’t ever run OOM. The bug report is about a qBittorrent instance running in a container. Those have their own memory/resource limit enforcement via cgroups on the host. And I can imagine, that with the filesystem cache usage attached to the process that way, the memory cgroup limits might misinterpret this. Or the container engine might occupy it at the host as if it was not just the filesystem cache.
@GregoryWest501
Can you confirm, that while memory usage of the qbittorrent-nox process in htop looks high, free -h shows most of this below buff/cache, with enough left below available? And does it max out CPU usage as well when maxing out your download bandwidth? In my case, with the Ubuntu torrent download, I couldn’t max out my bandwidth, and CPU usage dropped to half as well, compared to the max/max Debian torrent download. So if whichever part of the download/store chain causes too high CPU usage in case of high transfer rates, a solution would be to limit those via GUI, and/or reduce the priority of the process in dietpi-services, so SSH and other things may remain more responsive.
