Random High CPU Usage and Memory Management Issues After Long Periods of Runtim

[Aesthermortis]

qBittorrent & operating system versions

Operating System: Windows 11 Pro 23H2 (10.0.22631) Number of torrents: 1090 (860 seeding)

qBittorrent version: v4.6.7 Qt: 6.4.3 Libtorrent: 2.0.11.0 Boost: 1.86.0 OpenSSL: 1.1.1w zlib: 1.3.1

What is the problem?

Description: qBittorrent frequently experiences significant CPU usage spikes after running for extended periods, occurring randomly without any clear trigger. These spikes can cause the CPU usage to stay between 90-100%, despite the program only performing regular download or upload tasks. This high CPU usage should typically only occur during more intensive operations, such as hash checks or torrent creation. Normally, with around 15 torrents downloading and some uploading, CPU usage doesn't exceed 40%.

Additionally, the program's memory management seems inefficient. Despite raising the memory usage limit to 1024 MB, the program consistently uses a low amount of RAM, resulting in slow responsiveness or temporary "Not Responding" states when navigating through the interface or restoring the window after minimizing. This issue becomes more noticeable as the number of torrents increases.

Expected Behavior: CPU usage should remain at a reasonable level based on program activity (around 40% or less during regular torrent operations such as downloading or uploading). Memory usage should be more aligned with the set limit to ensure the interface remains responsive. The program should only reach 90-100% CPU usage during more demanding tasks, like hash checks or torrent creation.

Actual Behavior: CPU usage spikes randomly to 90-100% and remains high for extended periods, even during simple download/upload activities. Memory usage remains low, resulting in lag or unresponsiveness in the interface. Program often becomes temporarily unresponsive when restoring the window or switching between menus.

Steps to reproduce

Run qBittorrent for an extended period (several hours or more). Download/upload multiple torrents (around 15 active downloads and some uploads). Monitor CPU usage for random spikes. Increase memory limit to 1024 MB in the settings. Interact with the interface or restore the window after minimizing.

Additional context

CPU usage doing nothing:

CPU usage when uploading:

Changing the memory process priority to normal makes the program use around 250Mb of ram making the interface run more fluid.

Log(s) & preferences file(s)

No response

[HanabishiRecca]

Try to intall the base version (the installer without qt6 lt20 suffix) and see if it reproduces.

[dezza]

I've had the same issue with 4.6.7 on linux, it bogged the system down completely and the WebUI was barely useable. I reduced IO threads to 4, no change.

[hardwareadictos]

Same issue here

[Aesthermortis]

At the moment version 5.0 does not seem to have this problem, the interface is more fluid and maintains considerably low CPU usage that does not even activate the fans. However, when performing the hash check after downloading a file of about 50Gb, the interface freezes for about 10 seconds.

[rwjack]

Yeah I noticed some odd memory leak on 5.0.

It was sitting at 1.6GB. Restarting the container just dropped it back to ~70MB. Will see if it happens again

[HanabishiRecca]

Will see if it happens again

If you use lt20 build, it will happen again. It's just how it works. Follow arvidn/libtorrent#6667. Also see recent #21300.

[rwjack]

If you use lt20 build

Unsure, I use the latest version of this: https://hub.docker.com/r/linuxserver/qbittorrent

[HanabishiRecca]

I use the latest version of this

Yes, it is LT20. Your best option for now is to set RAM limit for the container.

[Aesthermortis]

Will see if it happens again

If you use lt20 build, it will happen again. It's just how it works. Follow arvidn/libtorrent#6667. Also see recent #21300.

After 2 days of use, it hasn't exceeded 15%-25% CPU usage at any time, which only happens during hash checks. During normal use, there is a fluctuation of about 5%.

Yeah I noticed some odd memory leak on 5.0.

It was sitting at 1.6GB. Restarting the container just dropped it back to ~70MB. Will see if it happens again

In my case, version 5.0 consistently uses 700MB of RAM, which is beneficial as it makes the interface more responsive and improves data transfer performance.