I am running Unraid 7.0.1 and my server has suddenly because sluggish with very high IOwaits.  I didn't realize my docker /appdata and /docker folders were not on my SSD-cache, so I moved them over.

 

Now it seems like there are dozens of "du -sb" processes running, and I see the system load get higher and higher, to the point where I have to reboot the system daily just to get to the Web-UI.  Here are my diagnostics a few minutes after my last reboot (while the system was still responsive).

 

I am reasonable confident is it not docker, because I shutdown my dockers containers one-by-one before the last reboot and the system did not become more responsive.  Loads are slowly creeping upwards .

 

 16:22:19 up 41 min,  1 user,  load average: 52.45, 47.13, 34.34

server03-diagnostics-20250519-1606.zip

Can you open a terminal and post the output of

ps -auxf

Make sure that you already are seeing the "du" processes running

Unfortunately, the Unraid server crashed (likely due to high load) before I could create the output file.  Here is the output about 40 minutes after a forced reset-button style reboot.

 

I realize it's not the same, however, part of me also suspects this may not be caused by the "du" program after all, but maybe by one of the docker containers that's running away.  I've been battling this problem with a few months now, but in the past, I could go about a month without having to reboot.

 

ps.output.txt server03-diagnostics-20250519-2328.zip

So the problem turned out to be within the Immich container.

Somehow, the number of background thumbnail generation processes was set to a super-high number (30) and this was causing my system to slow down. It was hard to pin down that Immich and specifically the background-thumbnail-generator as the problem.

I think there needed to be very specifically conditions to take place (like a user uploading a large batch of photos that needed thumbnail generation) in order for the problem to be triggered.

Ultimately, logging in as tImmich's Administrator user and resetting the number of background jobs to defaults values has addressed this high CPU problem for me.