dyno Posted April 3 Share Posted April 3 (edited) I've been having some pretty severe memory leak issues with all three qbittorrent docker containers recently (binhex, hotio and lscr.io). I transferred ~10,000 torrents (47TB total) and fast resume data from another linux-based (not Unraid) server to my Unraid server. The previous server that these torrents were running on was rock solid stable for a year and that server used 8GB RAM total (including the OS). No memory leaks with that Qbit instance (4.3.9 libtorrent v1).  The qbit instance is just seeding (no downloading). And no matter what I try, the qbit container eats up more and more RAM until it almost locks up the server. Even when I have zero active torrents, memory usage grows until the docker oom killer reaps it (and resets the qbit app within the container). For now, I've set a container memory limit of 64GB and that prevents the server itself from running out of RAM, otherwise Qbit will easily eat up all 192GB of RAM before I have to kill it.   Troubleshooting Steps I've Tried -- no success with any of them: Different containers (lscr.io, Binhex and Hotio) Different Qbit versions (4.3.9, 4.4.5, 4.6.0, 4.6.2, 4.6.3 and 4.6.4) Different Libtorrent versions (v1 and v2) New Server Hardware (new CPU, Ram, Mobo, HBA)  Server Specs: Supermicro H12SSL-NT EPYC 7B13 - 64 core at 2.20 Ghz 256GB DDR4-3200 ECC RDIMM Memory Allocation: 64GB to ZFS 64GB to troublesome Qbit container The remainder is unallocated  Strangely enough, I have two other active lscr qbit containers (details below) and those containers only uses around 1-4GB of RAM each (depending on activity). This is all on the same unraid server. I've also tried endless changes to qbit advanced config options, but nothing helps.  I'm not sure what the problem is, but I've never run across such memory leaks across so many different versions of qbit. The only constant factor for the memory leaks is this set of torrents and Unraid. Any suggestions would be greatly appreciated. Enclosed are my anonymized diagnostics.   Since these issues persist across every new container I create, I'm unsure if perhaps there's a rogue torrent causing the issue? I'm completely stumped at this point.  Qbit Instance 1: 1,000 torrents -- seed size 26TB -- no memory issues Qbit Instance 2: 10,000 torrents -- seed size 63TB -- no memory issues Qbit Instance 3: 10,000 torrents -- seed size 47TB -- terrible memory leaks (problem child)  Other Config Info (may not be relevant): Local File Storage for Qbit 16 HDD RAIDZ2 Pool Two VDEVs with 8 HDD each   galactica-diagnostics-20240402-1951.zip Edited April 3 by dyno edited for clarity Quote Link to comment
Unraidmule Posted April 5 Share Posted April 5 I am having the same issue which has not been resolved yet:  RAM leak issue  Did you find a solution? Quote Link to comment
dyno Posted April 5 Author Share Posted April 5 5 hours ago, Unraidmule said: I am having the same issue which has not been resolved yet:  RAM leak issue  Did you find a solution?  Not yet, unfortunately. I posted a thread in the lscr.io Discord server, but they instructed me to make a bug report to qBittorrent. Since this issue is occurring across containers from three different maintainers.   I'll probably make a bug report in GitHub today. Quote Link to comment
Unraidmule Posted April 5 Share Posted April 5 Are you using any other sort of application which is probing the qBit API? Also my issue only occurred if I stayed on the web UI Â I was also instructed the same as you - lscr.io said it wasn't their problem too. Quote Link to comment
dyno Posted April 5 Author Share Posted April 5 11 minutes ago, Unraidmule said: Are you using any other sort of application which is probing the qBit API? Also my issue only occurred if I stayed on the web UI  I was also instructed the same as you - lscr.io said it wasn't their problem too. I have WebUI tabs open for all the qbit containers, but that has no impact on server memory usage.   I have some manual scripts that poll the qBit API, but I only run them occasionally to locate unregistered .torrent files and clean them up. So that would not cause this either. Quote Link to comment
Unraidmule Posted April 5 Share Posted April 5 If you keep the tabs closed, does it fix your issue? Â For me, I was calling the API constantly for 3 instances (every 2-3s) while keeping the web UI open, which has a glitch to increase the RAM until server crashes. Quote Link to comment
dyno Posted April 5 Author Share Posted April 5 21 minutes ago, Unraidmule said: If you keep the tabs closed, does it fix your issue? Â For me, I was calling the API constantly for 3 instances (every 2-3s) while keeping the web UI open, which has a glitch to increase the RAM until server crashes. Â No, it has no impact on memory usage. Quote Link to comment
Unraidmule Posted April 6 Share Posted April 6 Ah OK, if you find a solution can you please post it here Quote Link to comment
dyno Posted April 6 Author Share Posted April 6 10 hours ago, Unraidmule said: Ah OK, if you find a solution can you please post it here Will do.   Unfortunately, this appears to be a bug in qBittorrent’s code.  For now, I’d recommend setting a memory limit for your qBit container(s) to prevent it from crashing the server.   Aside from that, you may want to try Transmission.  For myself, I can live with this for the moment since I have a lot of RAM.  That said, migrating to Transmission is painful and not really feasible for me. Quote Link to comment
Unraidmule Posted April 8 Share Posted April 8 I set a limit on the qBit containers, but they crash internally which is very bad — creates ghost peers and wiped out my upload stats that are not registered due to no announcement Quote Link to comment
dyno Posted May 10 Author Share Posted May 10 On 4/8/2024 at 3:24 AM, Unraidmule said: I set a limit on the qBit containers, but they crash internally which is very bad — creates ghost peers and wiped out my upload stats that are not registered due to no announcement So I figured out the cause of my issue.  The .torrents in my qbit instance had all been migrated from a Debian qbit instance, along with their .fastresume files.  This was done to avoid a recheck.   For some unclear reason, this was the cause of my memory leak issues.  So I created a new container, added all the .torrent files to it and then re-checked all of them.   Since then, I’ve had no issues with memory leaks.  I also made an issue in the qbit GitHub repo.  Regardless, this doesn’t seem to be an Unraid issue.  It’s definitely a qbit issue. Quote Link to comment
Unraidmule Posted May 27 Share Posted May 27 Thanks for the information, unfortunately I only use the linuxserver container and I think they didn't change the OS behind it? I think my issue is from having multiple web UIs open simultaneously, which causes the memory to leak. If I only leave one open, I never get the issue. Appreciate the reply though. Quote Link to comment
Solution dyno Posted May 27 Author Solution Share Posted May 27 11 hours ago, Unraidmule said: Thanks for the information, unfortunately I only use the linuxserver container and I think they didn't change the OS behind it? I think my issue is from having multiple web UIs open simultaneously, which causes the memory to leak. If I only leave one open, I never get the issue. Appreciate the reply though.  After some additional testing, it appears that the issue is indeed related to having multiple WebUI sessions open simultaneously. Check out my issue on Github.  Qbit Memory Leaks - GitHub Quote Link to comment
Unraidmule Posted May 28 Share Posted May 28 16 hours ago, dyno said:  After some additional testing, it appears that the issue is indeed related to having multiple WebUI sessions open simultaneously. Check out my issue on Github.  Qbit Memory Leaks - GitHub  Thanks for the link and explanation of your issue.  I read your latest post on the GH issue. This is the exact issue I have, you open 2+ qBit instances on the same browser it will leak and very quickly - usually on both the instances open - even when torrent is paused. I also tried to open one qBit instance on different PCs (same LAN) and somehow that was also causing leaks but I need to do more testing on that.  I really hope this gets resolved, I don't even think the issue is specific to Unraid OS.  Only solution at the moment is open one client at a time and remember to close the tab before viewing any other instance via the webUI. But if you make the mistake just close both quickly and let them settle down before viewing them via the webUI again. Quote Link to comment
dyno Posted May 30 Author Share Posted May 30 On 5/28/2024 at 7:14 AM, Unraidmule said:  Thanks for the link and explanation of your issue.  I read your latest post on the GH issue. This is the exact issue I have, you open 2+ qBit instances on the same browser it will leak and very quickly - usually on both the instances open - even when torrent is paused. I also tried to open one qBit instance on different PCs (same LAN) and somehow that was also causing leaks but I need to do more testing on that.  I really hope this gets resolved, I don't even think the issue is specific to Unraid OS.  Only solution at the moment is open one client at a time and remember to close the tab before viewing any other instance via the webUI. But if you make the mistake just close both quickly and let them settle down before viewing them via the webUI again. I'd suggest making a bug report on Github as well. The more reports they get, the more likely they will be to address the issue. Quote Link to comment
Unraidmule Posted May 31 Share Posted May 31 (edited) 18 hours ago, dyno said: I'd suggest making a bug report on Github as well. The more reports they get, the more likely they will be to address the issue.  I read your report, and yours was very extensive. TBH IDK how you figured out client side and server side leaks? Its more a power user issue which they might not deem important enough to address quickly - just how other applications don't cater to multiple instances too. Like cross-seed etc. Edited May 31 by Unraidmule Quote Link to comment
Boojah Posted August 7 Share Posted August 7 Hi, old thread, but stumbled upon it and thought i'd share my workaround to this problem.  I simply have a 'user script' (a plugin) like so: #!/bin/bash docker restart qbittorrent  Which is scheduled daily, which limits ram usage to a few hundred megs or something that I can deal with. I find that better than hard limiting memory. One could perhaps instead use a docker backup running at some interval to force a restart.  Thing is that none of the mentioned causes apply to me, it happens even after a restart while never opening a webui whatsoever. Or having old torrents that has been migrated, as all mine are added natively with the same container. (I could maybe, but unlikely, have had another container previously, but I am running liunuxserver currently.) Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.