Version 6.4 - File copies onto cache drive completely cripple Plex and maybe others

[Chad Kunsman]

Threads that appear to be people having the same or a similar issue can be found here:

 

https://lime-technology.com/forums/topic/59792-system-gets-unresponsive-when-a-docker-app-starts-a-file-transfer/

https://lime-technology.com/forums/topic/58017-when-copying-files-to-unraid-server-becomes-unresponsive-gui-smb-dockers-etc/

https://lime-technology.com/forums/topic/62376-unraid-635-high-load-50-when-copying-large-files-from-one-share-to-another/

 

I'm new to Unraid, having set up my current server less than two weeks ago. 

 

i7-4770

8GB RAM

5 platter drives -  1TB cache, 4TB parity, then 4TB, 2TB, 1TB data drives. All drives pre-cleared before assigning their role. No SMART errors.

 

appdata, system, domain, and iso shares are all on the 1TB cache drive and set to 'cache prefer'. I also have another share called 'speedy' that I put files I'm seeding on. 

All drives are XFS, and cache drive was BTRFS before but I reformatted as XFS.

 

I run dockers including: PlexMediaServer, Tautulli, Sonarr, Radarr, Jackett

 

I have a USB external drive (unassigned devices plugin), as well, 8TB.

 

When my cache drive was BTRFS, I would run an rsync from my USB external over to an array share that's set to 'cache yes'. Meaning that the files were technically hitting cache drive first. 

Whenever I had this rsync running, all my docker containers would take a huge dump. They were completely inaccessible. I couldn't stop them, kill them, exec a shell into them, no webUI was loading, nothing. Completely inaccessible. Even parts of the Unraid UI were not loading, such as the dashboard tab, the docker tab, and maybe one more but I don't remember. 

 

Cancel the rsync job, and everything is instantly fine again.

 

I tried assigning a 'nice' and and 'ionice' value to the rsync job, but it made no difference. 

 

After lots of forum hits of people experiencing similar issues, some people tended to agree that reformatting the cache drive to XFS would help a lot if not completely solve the problem. So I spent time moving stuff around in order to make that happen. 

 

So my new tests, with the cache drive as XFS, have definitely shown improvement. Non-Plex containers seem workable, if not a bit slow. I can stop docker containers, I can exec a shell into them, including PlexMediaServer, but one thing that hasn't changed is that Plex itself is crippled, still, while a copy is going on. 

 

From the short testing I've done, it seems as though an active stream, even if transcoded, won't be impacted if the copy job is started after the stream starts. But if the copy job is underway, you cannot navigate the Plex UI at all, such as browsing, or starting a stream. it just hangs nearly indefinitely. 

 

So if I had a big copy job running, no one could use my plex server until I finished the copy, or unless they already had a stream going. 

 

Anyone have any ideas on this? My best guess is that whatever I/O that Plex uses while navigating the UI or initiating a stream is trashed when there is a high level of disk activity going on already. But I don't know why this is. I know almost nothing about disk IO and prioritization, but I had always assumed that if multiple processes needed disk access, that it would generally share, to some degree, at least to not cause any more than a nominal slowdown. Noticeable, but not crippling. 

Are there any settings or options I could try to solve this? If there is nothing, I think I would have to somehow move my appdata share onto a different drive than the cache drive. 

 

 

[Chad Kunsman]

That's a sound idea, though not sure if relevant to this particular issue.

 

Edit: The comment I replied to was deleted.