Sonarr version (exact version): 2.0.0.4389 Mono version (if Sonarr is not running on Windows): OS: Windows 10 version 1607 ((Debug logs)): https://dl.dropboxusercontent.com/u/41179292/sonarr_logs.zip Description of issue: I’ve noticed over the last couple months that the nzbdrone.host process will eventually take most of the available cpu time. It never relents and I need to restart Sonarr or the machine. But it’s just a matter of time until it happens again.
My next thought is to reinstall Sonarr, but rather than set everything up again I’d like to understand what’s going on first so it doesn’t happen again.
At the very least we’d need to see ((trace logs)) from a time of high CPU usage. We’d also need to know what type of CPU is in the system (model number) since 40% of a 1.6 atom vs an i7 is a vast difference.
Sonarr should idle at close to 0, but will use more CPU cycles when processing items from RSS, searching or refreshing series.
The trace logs you supplied look like they are processing an RSS sync as well as communicating with the download client, which will jump up the CPU usage (up to ~34% on my 3.0 GHz dual-core), but then it should drop back down to 0% right after.
The logs I attached were during a time of high usage. My CPU is an Intel i7-3930K @3.20 GHz, 6 cores.
I understand there is going to be times of usage while processing things, but in the past I have seen the CPU pegged close to 100% for over a 24 hour period.
The only time I recall Sonarr using high CPU for a long period of time was due to a bug that was fixed shortly after v2 was released (years ago) and that was only under mono.\
It seems unlikely that Sonarr would be able to maintain high CPU usage in most situations since RSS Sync and disk scans are generally quick, but if it was rescanning files for media info (which happened with an update in the last couple months) that might pick up the usage for and could last a while if there were tons of episode files to scan through.
Yes, recently, as in the last two months. I always keep the app up to date.
I can tell you, it is the nzbdrone process. If you need more information I can provide it next time this happens. I’ve attached a CPU usage graph from this morning, the same time frame covered in the logs. The machine was powered off overnight (though I rarely do this). You can see the CPU immediately spike and after I restart Sonarr, fine for the rest of the day.
I did a restart of Sonarr at around 8:32 AM PST on 11/12/16 and the CPU usage dropped to near zero. Attaching logs as far back as I have them. Not quite sure what is going on here.
My only idea at the moment would be something with the .net framework, what versions do you have installed? The easiest way is probably with the powershell snippet:
So just because Nzbdrone isn’t writing to logs… it’s not hogging my CPU? Trying to help you out here. It is eating my CPU. I’m a software engineer, I can see what is chewing it up.
PSChildName Version Release
v2.0.50727 2.0.50727.4927
v3.0 3.0.30729.4926
Windows Communication Foundation 3.0.4506.4926
Windows Presentation Foundation 3.0.6920.4902
v3.5 3.5.30729.4926
Client 4.6.01586 394802
Full 4.6.01586 394802
Client 4.0.0.0
I meant anything Sonarr is doing is logged (API requests, tasks, etc), so Sonarr is doing nothing (except sitting there and waiting) at periods where the CPU usage is still high. The fact that the CPU usage is high no matter what is perplexing.
I have the same .net versions on my setup (Win 10 as well) and not seeing the same issue when running NzbDrone.Console.exe.
If you run NzbDrone.Console.exe do you see the same issue (instead of running as a service)? (to rule out the service being the culprit).
I’d be curiosu if you have the same issue without Kaspersky running as we’ve had issues with other AV’s cuasing issues with Sonarr, but not like this, but perhaps the next steps will give us more to go on.
I think to get some insight into what the process is doing is to grab some procdump files.
1 . Get ProcDump: https://technet.microsoft.com/en-ca/sysinternals/dd996900.aspx
2. Extract it and open a command prompt with the CWD where ProcDump was extracted
3. Get the process ID of Sonarr from Task Manager
3. Run ProcDump with the following command: procdump -c 50 -s 5 -n 3 12345 replacing 12345 with actual process ID
When Sonarr hits 50% CPU usage for more than 5 seconds it will write a process dump file, writing up to 3 total before exiting.
Once you have those files zip them up and PM me a link to grab them and I’ll take a look (and see if Taloth can do the same).
The process looks to be running normally this morning but I will keep an eye on it. Personally I am suspicious of qBittorrent 3.3.7. This version has been acting strange for me, sometimes not responding to the UI or web API after it has been running for some time, until I restart it. Maybe that is a red herring but something else on my list to try is a different BT client.
Maybe I’m dense, but I could not figure out how to send a PM. Anyway, I noticed NzbDrone has been taking up around 25% of my CPU this morning. In my experience, if I just leave it for a day or two this will climb even higher.
I noticed there is one item in the download queue that seems to be going nowhere, and some qBittorrent communication errors in the logs as I mentioned before. I will let you do the diagnosis but that is something that might be worth looking at. I am not sure if this is related or not.
Sorry, I took a quick look before and was having issues with the dump file I tried, but it looks like I forget to ask for a full dump file. Since the CPU usage is already high can you run procdump -ma 12345 (replacing 12345 with the actual PID of the Sonarr process).
Thanks, that helped immensely and @Taloth was able to dig in and find the underlying issue.
It looks like this is related to the proxy support built into Sonarr (over time the proxy listeners are created, but never disposed of properly), the issue goes beyond the code in Sonarr and will need to be fixed in the library we’re using.
In the mean time using something else to proxy the requests (maybe fiddler) would be advisable or possibly use a local proxy server so the IP address remains the same and new proxies aren’t created.
Cool, great news! I’d bet others who are using a proxy would see the same thing, but it’s not really obvious unless you are anal about your system performance like I am.
