![]() Because Python is effectively single-threaded and when doing a disk scan with a large queue, the resulting execution time causes SABnzbd to appear unresponsive. Post-download processing can also cause SABnzbd to become unresponsive until it gets to the unrar stage which occurs outside Python, but this is less frequent even with remote disk. The disk scans can easily be seen during a queue repair, but happen at other times as well. ![]() What I've determined at this point is the unresponsiveness in SABnzbd is due to the disk scans it is doing quite often. If you'd like, I can upload Sorry for the delay in my response. I will continue to monitor and try to collect - I think only the second time since I installed it, but the log file decided to rollover last night/this morning. I have not yet been able to correlate specifically when it happens or if there is a pattern, though. everything that happens after the download finishes and "complete"), the speed drops tremendously and the UI becomes unresponsive at times and for a while. One thing that is happening, and as said, during verify/repair/unpack (i.e. Usually the 30s refresh will show me when the UI is being unresponsive. One is to clear the warnings from the error list and the second is to have a 30-second auto-refresh on the Settings > Servers tab (I like to monitor download bandwidth on the different providers while I'm figuring out which ones I'm going to keep). There are two things that I have not done just to see if they were a contributing factor, however. It was downloading individual episodes, although it did a full season overnight which took a long time (~5 hours) to unpack. :-) It's been running fine since the last queue repair. So, this has been unexpected, welcomed, and useless to troubleshooting. What I believe to be the orchestrator thread:Ĭommon thread stack between all worker threads: Even with debug logging enabled, there is nothing being logged so I can't tell what's going on. It makes no sense to constantly rescan the same information repeatedly for over an hour. Hopefully this can be used by someone to identify what the problem is. I'm attaching the stack dumps of each thread as well as a common-thread file which shows a common base stack between all the "worker" (rescanning) threads. If I had to guess, what is currently thread ID 1008 seems to be their "leader" or at least that's the thread that appears active for a couple milliseconds in between each one of these "worker" threads doing the Temporary folder rescan. Instead, multiple threads, one-at-a-time and almost cyclical, are popping up to the top of the CPU usage list and Process Monitor is showing that each thread is rescanning the Temporary folder (over and over and over). SABnzbd.exe is not running at any "high" CPU as noted before in the thread above. Watching this more, the thread I mentioned above actually isn't doing any work right now, but the UI is completely unresponsive and all downloading has stopped. PYTHON27.DLL!PyEval_CallObjectWithKeywords+0x141 Ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 This thread appears to be the bottleneck and would need to be split up into multiple threads. The behavior I'm seeing is that although I have 4 cores on the machine, this thread can only consume the equivalent of 100% of a single core (obviously because it is a single thread). From Process Explorer, I can't tell what it is, but I'm posting the stack below. It appears that one of the threads under SABnzbd is limiting performance and causing "an" issue, if not "the" issue. Ok, so I've been digging into this for a while.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |