Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Excess memory usage #11348

Closed
ned-martin opened this issue Oct 9, 2019 · 5 comments
Closed

Excess memory usage #11348

ned-martin opened this issue Oct 9, 2019 · 5 comments

Comments

@ned-martin
Copy link

ned-martin commented Oct 9, 2019

qBittorrent version and Operating System

v4.1.8 x64 / Windows 8.1

What is the problem

Excessive memory usage over time.

The memory usage climbs over time, and appears to never go down. There does not seem to be an upper limit. My system has 32GB RAM and no disk-based swap, so I start receiving memory errors when the process gets to around 28GB RAM usage. This appears to occur without any actions - i.e. not moving torrents etc., just running qBittorent with many torrents and many trackers.

My disk cache is set to 64MiB / 60s expiry.

What is the expected behavior

Memory usage should remain reasonable, and should go up and down, as per previous versions.

Steps to reproduce

Run qBittorent for several days with many torrents and many trackers. Note that memory usage only increases, never decreases.

@Balls0fSteel
Copy link

You may have:

  • A bad device driver.
  • A HDD/raid array failing.

See this for help/guidance: https://woshub.com/huge-memory-usage-non-paged-pool-windows/

I realize you are talking about ram usage, but the ram usage is ALSO maxed when this happens.

@ned-martin
Copy link
Author

ned-martin commented Oct 9, 2019

You may have:

* A bad device driver.

* A HDD/raid array failing.

See this for help/guidance: https://woshub.com/huge-memory-usage-non-paged-pool-windows/

I realize you are talking about ram usage, but the ram usage is ALSO maxed when this happens.

It's possible I have a bad device driver, but I suspect it's very unlikely - the machine is virtualised so is using standard virtual hardware drivers. The "HDD" is network-attached storage (via 10 GigE), if that makes any difference, but once again I suspect it does not. I'm unsure how to verify either of these points. This excess memory usage was not a problem in any previous version I have used.

I have not noticed any excessive use of the non-paged pool. RAM seems to be fairly straight-forwardly used by the single qbittorent.exe process. It slowly climbs by something like a few gigabytes a day, which might not seem like much but it means that I have to monitor and restart qBittorent (which as many other bug reports here have pointed out, takes a really long time before the process actually quits and causes other issues and risks data loss etc.) every so often as its memory usage hits insane amounts.

@Balls0fSteel
Copy link

Now this, is way more interesting. The virtual bit was never mentioned, while it is the most important of this all.

  • What hypervisor?
  • What driver for the storage?
  • It's possible that it's a new issue, but if you have special hardware, it's always good to share as much as detail about it, as you just can.

You could try the new 4.2 alpha version? It should fix a few bugs...

@Ohelig
Copy link

Ohelig commented Oct 24, 2019

I've had this problem too since upgrading to 4.1.8. Running Windows 10 x64 version 1903. I've got about 15k torrents and over ~48 hours qbittorrent creeps up to consume as much of my 64GB of memory as it can.

https://i.imgur.com/9cFZvP8.png

When I killed the process, my overall memory usage dropped from 95% to 14%,, so it was really using 52gb. I can post whatever specs you need or just try upgrading to 4.2 alpha

@Balls0fSteel
Copy link

I'll close this as there was no reply from OP.

@qbittorrent qbittorrent locked and limited conversation to collaborators Feb 28, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants