qBittorrent
qBittorrent copied to clipboard
qbittorrent
Memory leak
qBittorrent & operating system versions
qBittorrent: 5.0.0 x64 Operating system: Gentoo Qt: 6.7.2 libtorrent-rasterbar: 2.0.10
What is the problem?
qBittorrent leaks memory on my system when downloading torrents. I first noticed the leak on 4.6.6 and decided to upgrade and see if the issue is fixed in the up-to-date version. qBittorrent started with ~200 MiB of RAM but at the time of writing this it has consumed 3.5 GiB. When I pause torrents, all the leaked memory is released.
Steps to reproduce
- Start downloading any torrent, preferably a huge one (20 GiB or more)
- Observe qBittorent consuming more and more memory over time
Additional context
No response
Log(s) & preferences file(s)
https://gist.github.com/moonlitpath/41c7a72752ca980d02c3a6d395cd50f4
Sorry if it's a duplicate. I found several similar reports but IDK if I'm facing the same issue.
If you are interested in testing, try this patch #21300. (I think I don't need to explain how to patch&build stuff for a Gentoo user.)
Then you go into advanced settings tab and set Disk IO type to Simple pread/pwrite.
Also there is a libtorrent patch https://github.com/arvidn/libtorrent/issues/6667#issuecomment-2395527126, it improves performance a lot for this new mode.
I'm not entirely sure, if it's only related to the issue above. I also updated to 5.0.0 yesterday, and noticed several freezes on my systems. I managed to figure out the reason, they run out of memory. Apparently qbittorent starts to use more than 40gb after a while... I reinstalled a previous 4.6.4 package and it works normally again. I was able to replicate this on two of my arch servers. The libtorrent stayed the same (2.0.10). Not sure that it matters but I'm also using the nox version, as I have no desktop manager on these systems. I also use the API quite heavily, with thousands of active torrents. My normal memory usage for qbt is around 5 gb, which has been stable for a while. I also tried disabling the os read write cache in qbt, but that didn't seem to change anything regarding the oom.
I reinstalled a previous 4.6.4 package and it works normally again. I was able to replicate this on two of my arch servers. The libtorrent stayed the same (2.0.10).
Looks more like #21502. In that case, wiping the qBittorrent settings and starting with a clean profile seems to help.
I could give it a try, but that would probably take a couple days, rechecking 6k+ torrents with several 10s of TBs of data takes a long time. Do you think it is caused by the fastresume files perhaps? Or you mean only deleting the config files?
No, don't wipe the resume data. Only delete the client settings (~/.config/qBittorrent/qBittorrent.conf).
All your tasks will remain intact.
I moved to a third server to test, as this one has a bit more free ram. Here qbt was restarting constantly because of the memory issue, which took me some time to realize, as i was only watching it from top... Anyways I was able to update this one as well and get the oom reproduced. Then I deleted the entire ~/.config/qBittorrent directory as you recommended. It got recreated on restart. Set up port, password, default directory and global speed limits only. Still got the same result. Memory usage slowly creeping up on 5.0.0 to around 40gb max, where this system just silently decides to kill it, then systemd restarts it. I'll try to stop the service that does the API calls next, and leave the web ui alone as well. Maybe that's the problem. I also did a negative test on this machine as well, the older version is fine here too, stops around 14gb and stable.
It got more interesting over night. I left the server to do it's thing, but apparently with the default config it didn't quite hit the memory limit that it did before, so it didn't got killed, and eventually pushed the memory usage back down to <10gb and is now stable. I put the old config file back, and it didn't seem to mind it with that either now. Is it possible that there is a migration process that needs to complete that uses a lot of memory and if we have our config very lax, with a bunch of connections and active torrents allowed, then it just can't handle it?
No. The cause is still unknown. Libtorrent 2.x is intended to use as much RAM as possible for a cache though. It's easily reproducible if you force re-check on a torrent with few large files (totally larger than your RAM). So it's unclear what you are seeing.
Try to use libtorrent 1.x build to factor that out. Alternatively, set Disk IO type to POSIX-compliant (don't forget to restart the client) and see if that still reproduces.
The problem disappeared after a while on two of my systems. Only remained on one. That I kept on the older version, but after a while when I did updates it disappeared there as well. I'm not sure if it was directly related to qBt, it is possible that it was an interaction between the libs that it uses that caused this. As far as I can tell, currently nothing seems to leak. Higher memory usage? Sure, but it's stable.
I'm still having memory leak even after switch to simple pread/pwrite. Any ideas? I'm running 5.0.4 on a proxmox LXC
Any ideas?
No, we don't have extrasensory abilities. Create a new issue following the template, with detailed info about the system, attach logs etc. Then we'll see.
Try to do a full system update, delete the config folders. Also, check if it's really a memory leak, the new version likes to allocate a bunch of memory, but if it stays stable it's not leaking.
I've done system update, haven't try delete the config folder thou. I think it's probaly a leak since the memory just filled up steadily overtime and the system crashed when it's full (I give the LXC 4GB of RAM). Sorry I don't know much about coding so I won't be able to provide much info. Just want to check the sittuation of the issue.
