Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
qBittorrent frequently maxes out one CPU logical processor after OS sleep and resume #11039
qBittorrent version and Operating System
What is the problem
Approximately once every two or three times that the PC goes to sleep, upon resume, qBittorrent maxes out one of the CPU cores. This high CPU usage continues until qBittorrent is closed and restarted (i.e. it's not a transient issue that only occurs for a short period of time after the OS resume).
What is the expected behavior
qBittorrent CPU usage remains constant after sleep and resume (excepting any resume-specific tasks).
Steps to reproduce
Extra info(if any)
This appears to be the same bug as #7104 ("High CPU usage after sleep"). That bug was closed with the comment "If this still happens for you, please open a new ticket and include as many details as possible." I'm happy to provide more detail and/or run tests on my machine, but I'm not sure what would be useful, so instead of preemptively spamming a bunch of information, I'll instead do my best to respond to any/all questions asked here.
Once qBittorrent is in this state, the high CPU usage persists until the app is restarted.
This problem has reproduced for me for months (and, judging by #7104, may have existed for years).
Most recent three log files attached. (qbittorrent.log.bak24 and qbittorrent.log.bak23 were renamed to qbittorrent.log.bak24.log and qbittorrent.log.bak24.log, respectively, so that GitHub would accept them as attachments.)
Maybe I will say the obvious but the project really need to fix thoses performances issues.
I checked the GitHub issues of the project just because my computer almost crashed thanks to qBittorrent. My Manjaro has just boot and after 10-15mn on the web all my PC was over-slow. My CPU and my HDD were at their rupture point. And just, after removing 3 "old" torrents that were seeding, all came back to normal.
This kind of bug is an hardware killer for God sake ! I uninstall softwares for less than that !
You have 22 opened performance issue and some are more than 5 years old ... You need to clean thoses issues and prioritize them over featuring or refactoring. I use qBittorrent since many years but I didn't see a lot of bugfix or performance improvement over the years. It's really sad to see that much work (commits and PR) and so few results
You are more than welcome to contribute to the project yourself. qBittorrent is fully maintained by volunteers. The way things get done is people having the time and motivation to work on them.
Rather unsatisfying update...
I went to my PC to do this using Process Monitor (a Windows equivalent to strace). Usually, when I unlock my PC, if qBittorrent had been running in the meantime, it would show 13% CPU usage as described above (13% system CPU usage = 100% usage of one CPU core), but this time CPU usage was low/normal. I suspended and resumed the PC seven times, but each time CPU usage remained below 2% at all times.
This suggests one of three things to be the case:
The next time I notice high qBittorrent CPU usage I'll attach Process Monitor and see what it's up to, although I recognize that's not as good as catching it in the transition from normal to high CPU usage.
Ok, got it to reproduce by starting a new download and then suspending and resuming while that download was underway. I started Process Monitor before suspending (when CPU usage was normal) and stopped it after resuming (when CPU usage was spiked).
I've attached Process Monitor logs in all three available formats. The dialog to save as XML had options for saving stack data as well -- I don't know if that means the XML file has information the other two don't, or if the other two file formats include stack data by default.
Take a look and let me know if that helps at all.
OnceIWasCool, since you've run Process Explorer...have you also tried TCP View to see if the listening ports qBitTorrent randomly opens at start are closed after OS sleep and resume?
I know forcing them closed using TCP View causes 100% CPU usage on 1 core, but that might "naturally" occur after OS sleep and resume as well.