Disk and UI performance slows to a crawl when downloading with SABnzbd

[pspfreak]

Hi all,

 

I've ran into this issue with my unRAID installation where if I start a download with SABnzbd, say more than 10GB in size, I end up getting either a slow to respond UI or a completely unresponsive GUI (both the unraid GUI and SABnzbd.) The first 10GB or so download with no issue, at full line speed, but then after that, things turn into pretty much a complete dumpster fire. SABnzbd even goes as far as to lose connection. 

 

In the dashboard my, usage looks something like this: 

here is htop:

 

As you can see, I am currently doing transcoding with tdarr, but whether this is running or not does not change the outcome. 

 

As for hardware, currently I'm running a Core i5-4590, 28GB of RAM, a LSI HBA with 6 WD6001F9YZ's (2 Parity), a WD Blue SA510 (500GB Blue SSD) as my cache drive for downloading and docker appdata/docker image, and a Samsung 860 Evo 500GB as a unassigned device, here is my VM disk images. 

 

I've tried tweaking things, I originally started with just downloading direct to HDD, went to an older smaller SSD as a cache, and now this SSD, and its always the same story. I can't imagine I'm bottlenecked by the SSD here, even if I was I wouldn't expect a full stop on network traffic? 

 

I have ordered an i5-12400 as an upgrade due to some unrelated reasons, however this issue was persistent across this current hardware and an older Dell R710. Hopefully I've provided some useful information so I can get this resolved.

 

Edit: I forgot to mention, I am writing directly to the cache drive, no array logic here. 

Edited October 27, 2022 by pspfreak

[Squid]

Can you post the relevant xml from /config/plugins/dockerMan/templates-user and also a screenshot of the shares tab when you hit compute all

[pspfreak]

1 hour ago, Squid said:

Can you post the relevant xml from /config/plugins/dockerMan/templates-user and also a screenshot of the shares tab when you hit compute all

Here you are, i must note that whether its downloading or completing processing (unpacking, repair, etc) the entire system remains like I mentioned. Hopefully that is the XML you were talking about. I'm currently waiting on "Compute All", It's already been around 10 minutes. Is this a long process when you have a decent amount of files? 

 

Edit: I think the process just hung itself, I refreshed and got the info.

 

my-binhex-sabnzbd.xml

Edited October 28, 2022 by pspfreak

[pspfreak]

I wanted to mention I upgraded hardware today to the i5-12400 and this issue still occurs. 

[pspfreak]

Turns out it happened to be my cache SSD causing the issues, I tested copying to a share while this happens and I would see the same thing. Problem solved. 

[Gruffydd]

On 10/29/2022 at 5:17 PM, pspfreak said:

Turns out it happened to be my cache SSD causing the issues, I tested copying to a share while this happens and I would see the same thing. Problem solved. 

What did you do to resolve your issue? I am having the same thing.

[craig2583]

On 10/29/2022 at 6:17 PM, pspfreak said:

Turns out it happened to be my cache SSD causing the issues, I tested copying to a share while this happens and I would see the same thing. Problem solved. 

I would also be curious to find out how this was fixed.  I am having the same issue.  I am writing to an SSD cache pool.  Sounds like OP just changed out their SSD but I wonder why that would be the case for multiple people then.

[seefilms]

Hey, pspfreak... can you answer Gruffydd's question?

[user2579]

@pspfreak what did you end up doing?

[louiseuk]

Hello everyone - I'm having the same issue! Did anyone ever hear back from @pspfreak, or did any of you manage to fix this?

[woven-pertinence4412]

Not that this is the solution to others having the same issue but I came to say that I too was experiencing something similar, sabnzb would download then once post processing would start Unraid would become unresponsive and the system would be taxed 100%. Once I changed how my post processing was done the system behaved totally fine. More specifically, I figured out that most processing was done on my SSD drive but once the media was moved to the array and Plex then started its file scanning processes (Intro detection, credit detection, etc). The Plex scanning completely hosed the system when performing these actions to media on the array. So I changed it so that the media stays on cache for 24hrs then gets moved to the array and this completely solved my issue. Hope this is insightful to others as I was thoroughly frustrated by this for days.

[pspfreak]

 

On 7/30/2023 at 4:03 PM, louiseuk said:

Hello everyone - I'm having the same issue! Did anyone ever hear back from @pspfreak, or did any of you manage to fix this?

 

On 6/17/2023 at 4:32 PM, user2579 said:

@pspfreak what did you end up doing?

 

On 2/10/2023 at 10:41 AM, seefilms said:

Hey, pspfreak... can you answer Gruffydd's question?

 

On 1/28/2023 at 5:47 PM, craig2583 said:

I would also be curious to find out how this was fixed.  I am having the same issue.  I am writing to an SSD cache pool.  Sounds like OP just changed out their SSD but I wonder why that would be the case for multiple people then.

 

On 12/30/2022 at 11:20 PM, Gruffydd said:

What did you do to resolve your issue? I am having the same thing.

 

Sorry all, I don't go on here much as obvious by my lack of response. It turned out the SSD i was using a cache was dramless and seemingly unrelated failed after. I now use a decent quality Samsung NVME drive and have no issues with saturating line speed (1gig) and unpacking at the same time. 

 

My suggestion is to use a fairly recent and high quality SSD, ensure it has a dram cache or high performance nand. 

[user2579]

On 1/3/2024 at 8:39 PM, pspfreak said:

@pspfreak I came to the same solution as well.  Be leery about the high capacity NVMEs as they may not have DRAM.  Additionally, for mover congestion, if you're say... really downloading a massive queue to rebuild a library, if you have parity on, the transfer speeds from mover are going to be much slower than without parity- use that info at your own risk.