Qbittorrent Memory Leaks

[dyno]

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

[Unraidmule]

I am having the same issue which has not been resolved yet:

 

RAM leak issue

 

Did you find a solution?

[dyno]

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.

[Unraidmule]

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.

[dyno]

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.

[Unraidmule]

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.

[dyno]

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.

[Unraidmule]

Ah OK, if you find a solution can you please post it here

[dyno]

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.

[Unraidmule]

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

[dyno]

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.

[Unraidmule]

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.

[dyno]

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

[Unraidmule]

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.

[dyno]

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.

[Unraidmule]

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

[Boojah]

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.)