UnRaid Freezing/Unresponsive

[syrys]

So, since couple of weeks ago, i have been having a strange problem. Im not really sure why, whats causing it or even how to diagnose it.

 

My Setup:

Unraid 6.2.4

Parity: 1x 8tb

Data: 1x 6tb, 3x 8tb, 1x 4tb.

* most of the array drives are pretty full (95+%) and bulk of the free space is on the latest added 8tb drive (5.5tb/34tb Free).

Cache: 2x 480GB SSD

Unassigned Devices: 2x 4tb

I have several dockers including sonarr/couchpotato to automate media, deluge/sabnzbd for downloading and plex for media delivery.

 

Issue:

Every few days, i notice that my unraid instance freezes for few minutes. The machine is still running etc, but im unable to load the unraid Web UI (when i refresh, my browser keeps loading and saying something like "waiting for socket"). Same issue happens with every docker (so, the docker's Web UI becomes unresponsive the exact same way). When i say this happens every few days, i should specify that i only NOTICE it every few days (because its only obvious if it happens while im watching media on plex), i have no idea how often this actually happens.

 

Only way to solve the problem i have found so far is to just wait. It stays unresponsive for roughly 10 minutes, and comes right back up as if nothing was ever wrong. Last time it happened (last night), i quickly checked the logs (the logs button on top right of the Web UI) as soon as it became responsive, but there were no entries in the logs for the last hour or two according to the timestamps (it was only unresponsive for about 10 minutes).

 

Does anyone know what or why this could be? Could this be due to an issue with a drive? A docker? Something else? Heat?

 

Any help greatly appreciated.

 

Cheers

[McCloud]

I have this exact same issue, and from what I've gathered, I've seen it happen exactly when Sonarr or CouchPotato finished a download/extraction and is moving the file and lasts for however long it takes to move it.  Still trying to figure out why this happens though.  

Edited March 14, 2017 by McCloud

[syrys]

1 hour ago, McCloud said:

I have this exact same issue, and from what I've gathered, I've seen it happen exactly when Sonarr or CouchPotato finished a download/extraction and is moving the file and lasts for however long it takes to move it.  Still trying to figure out why this happens though.  

please let me know if you ever figure out what it is or how to solve it. i still have the issue, it was happening like 5 minutes ago  grr

 

One thing i noticed was that most of the time when this was happening, i noticed that the mover is running. Although, i cant be certain of that, as the UI is frozen obviously. So maybe you are on the right track, maybe it has something to do with sonarr/cp extracting and trying to copy big media files into the cache, or maybe the mover using up all the hdd bandwidth of the cache/array.

 

This is really frustrating, i dont know what to do anymore =/

[McCloud]

After messing with it.  I disabled caching on my Movie and TV shares, and moved the nzbget download folder (which was on my cache drive) to the main array without caching as well.  Seems to be working for about 12 hours with no intermittent hangups.  You'll have to update CP and Sonarr docker mappgings to check the right folders for processing.

 

I also toyed with docker CPU pinning and assigned dedicated cores to nzbget, sonarr, plex, and CP, but that didn't seem to make any difference that I could see.

Edited March 15, 2017 by McCloud

[syrys]

1 hour ago, McCloud said:

After messing with it.  I disabled caching on my Movie and TV shares, and moved the nzbget download folder (which was on my cache drive) to the main array without caching as well.  Seems to be working for about 12 hours with no intermittent hangups.  You'll have to update CP and Sonarr docker mappgings to check the right folders for processing.

 

I also toyed with docker CPU pinning and assigned dedicated cores to nzbget, sonarr, plex, and CP, but that didn't seem to make any difference that I could see.

 

yup, i would assume it the disabling of caching that is the true solution here. but thats not really a solution really. my downloads are all going to a separate unassigned drive (not part of the array), and i still have the issue, so its not related to that part of your solution (although my plex/sonarr/cp dockers are installed in the cache). So, what im suspecting is the mover, when the mover is running, the drives/array bandwidths gets saturated, causing everything to freeze. by disabling caching, mover will trigger less frequently or rather will complete quickly, thus not noticing any issues.

 

Although limiting mover or disabling caching will solve the symptoms, it doesnt actually address the actual issue. maybe the mover needs to be run in sort of low priority mode, or limit the movers moving speeds, if thats even possible.

 

Can a lime tech developer/admin address this issue please? Or atleast look into if what we are saying is correct?

 

Cheers.

[syrys]

alright, i can confirm the issue. when i simply click "move now" on the bottom of the main page of the unraid UI (when there are some media on the cache drive to move), my dockers  (plex, cp, sonarr) instantly become unresponsive or atleast insanely laggy/slow. 

[lixe]

I have exactly the problem, I explained it here: 

 

but I don't think it has anything to do with the mover. The mover only runs Monday morning on my system. I guess that all the copying is using the whole data bandwidth and it even doesn't make any difference whether the shares are using cache and so on. While only downloading everything is fine because the speed is limited and it is only writing. After that comes reading and writing only limited by disk bandwidth and it seems as it uses all it can get. So limiting it would be perfect, but I don't know how? The only alternative seems to pause post process in nzbget most of the time, so it happens for example over night, when most likely no ist uses the system.

[Frank1940]

If you have access to a console (either through a monitor and keyboard, or a SSH or telnet session), you could run   htop    on the command line ans see what processes are running and consuming most of your CPU at the time when the slowdown occurs.  This should provide some useful clues as to what is happening...

 

EDIT:  Try this ahead of time so you get a feel for what you are looking at and what is the behavior under normal conditions.

Edited April 21, 2017 by Frank1940