Hi,

Since some months now, I noticed that any process can use all available CPUs. For example updating my docker containers has become complicated and often fails to remove the container before starting it with the new image. Also my immich docker (installed via CA) was using all the CPU when files are synced to it (for transcoding and other ML activities), rendering my server unavailable/inaccessible until the CPUs are freed. Now I moved my immich installation to docker compose with a dedicated container for ML, so that I can control the resources it is allowed to use.

But the issue with docker updates is still there. I see this:

And UI does not refresh anymore. I can't ssh into the box. Nothing responds.

Please advise on few fronts:
1) How can I make sure that my unraid server OS always has 2 CPU cores reserved for itself (and nothing can steal those).

2) How can I get the docker updates working seamlessly? They often fail, leave the orphan containers, case my docker container disappear from the list (leaving me with the only option to reinstall those from previous apps) etc.

nedio-server-diagnostics-20261104-1421.zip

Thanks for the diagnostics. They were taken after the event, when the server was already idle, so they can't show what was saturated at the time. They do show the pattern, though: each time containers were updated, the Docker runtime logged timeouts ("context deadline exceeded", "evicting /tasks/exit from queue"). At the same time, the WebGUI requests that query Docker piled up and timed out. That is why updates sometimes fail halfway and leave a container removed or orphaned. Docker didn't get a response in time while it recreated the container.

1) Keeping cores free for Unraid

There is no setting that reserves cores for the OS itself. You get the same result by keeping everything else away from those cores. Don't use CPU Isolation for this. It does the opposite: it removes the isolated cores from Unraid's own use.

- Your VMs are already pinned away from cores 0-3, which is good.

- For containers, limit the heavy ones, for example:

- in the template's Extra Parameters: --cpuset-cpus=2-19 (keeps CPU 0 and 1, the first core and its HT thread, free), and/or --cpus=8 (caps the total CPU time the container can use)

- or set the per-container pinning in Settings > CPU Pinning

- in your compose stacks: cpuset: "2-19" or cpus: "8" per service, especially the Immich ML and server containers

2) Docker updates

Your docker.img, appdata and the Immich data are all on cache-a. That pool is a ZFS mirror of two Crucial BX500 SSDs. These are DRAM-less SATA SSDs, and their write speed drops a lot under sustained writes. Pulling and extracting images writes a lot of data, and when the pool can't keep up, everything waiting on it stalls, Docker included. This shows as high "CPU" usage in the dashboard. I can't confirm this yet, so next time it happens, if you can, open the local console or an SSH session started beforehand and run:

top -b -n1 | head -30 > /boot/top.txt

cat /proc/pressure/cpu /proc/pressure/io /proc/pressure/memory > /boot/pressure.txt

Then post those two files plus new diagnostics once the server responds again. If the wa value in top and the io pressure are high, the disk is the bottleneck. If us/sy and cpu pressure are high, the CPU is.

Meanwhile:

- update containers one at a time instead of using Update All

- avoid updating while Immich is processing new uploads

- if I/O is confirmed, the best fix is to move docker.img and appdata to faster storage, for example a pool on an NVMe device, or at least separate them from the Immich library

If a container disappears from the list after a failed update, reinstall it from Apps > Previous Apps. This uses your saved template, so the settings and appdata are kept.

One more thing: your diagnostics include your go file, and it contains a commented-out line with an archive password and a repository path. Diagnostics posted on the forum are public, so I recommend that you change that password and remove the line from the go file.