March 1, 20197 yr Every few days my system pegs CPU at 100% with the process "app" and becomes unresponsive. Background processes still run, but using the front end is difficult and at least one of my dockers (OpenDCT) shows as stopped. This only started a few weeks ago, while using 6.6.6, but the update to 6.7.0-rc5 didn't help. I have to reboot the server to recover. Can anyone spot anything causing the issue in the attached diagnostics? Thanks. unraidpvr-diagnostics-20190301-2230.zip
March 2, 20197 yr It's one of your docker containers. Can't tell which one though Incidentally, Mar 1 03:00:08 unRAIDpvr move: move: skip /mnt/disk1/system/docker/docker.img You'll get better performance if you stop then docker service (Settings - Docker), then run Mover from the main tab to get it onto the cache drive, after its finished re-enable docker Edited March 2, 20197 yr by Squid
March 2, 20197 yr Author 6 minutes ago, Squid said: It's one of your docker containers. Can't tell which one though Incidentally, Mar 1 03:00:08 unRAIDpvr move: move: skip /mnt/disk1/system/docker/docker.img You'll get better performance if you stop then docker service (Settings - Docker), then run Mover from the main tab to get it onto the cache drive, after its finished re-enable docker Thanks. I'm pretty sure I know which container (OpenDCT), just no idea why. It looks like the cache NVME drive (nvme0n1 nvme1n1) isn't keeping up with recordings - the docker shows the buffer filling up and not writing fast enough. The diagnostics don't show cache/nvme errors do they? I'm not sure what the mover line is telling me. I have mover set up to move recordings from cache to array, why would that affect docker.img?
March 2, 20197 yr 22 minutes ago, Rick Gillyon said: I'm not sure what the mover line is telling me. I have mover set up to move recordings from cache to array, why would that affect docker.img? Because the system share is set up to move from array to cache (prefer), and the docker image is sitting on disk 1. Mover can't move it while it's in use. You will get better performance with it on the cache drive by doing the steps above
March 2, 20197 yr Community Expert Might be just as easy to simply disable docker service, delete and recreate your docker image at the more reasonable size of 20G, and then reinstall your dockers using the Previous Apps feature on the Apps page. You probably setup docker before you added a cache drive and that is why it isn't on cache now like it should be. If you recreate it then it will be created on cache like it should be.
March 2, 20197 yr Author Okay, have sorted docker into cache. Would that cause recordings by a docker to write slowly to cache? If not, any hints why cache NVME drive (nvme0n1 nvme1n1) might be choking? Any related errors in the diagnostics? Thanks.
March 5, 20197 yr Author Monitoring memory, this seems to be a problem with recent versions of Plex eating up all available memory and grinding the system to a halt. Regressing Plex to an earlier more stable version seems to have fixed the problem (so far). Thanks for the help.
Archived
This topic is now archived and is closed to further replies.