March 28, 20215 yr Hello everybody, several days ago i migrated from proxmox to unRAID. Sadly i discovered a problem since day one with unRAID on the system. I dont know why, but on of my CPU Cores is pinned at 100%. Directly after a new start and typing in htop its CORE 2 at 100% and after 3 secs it switches to CORE 4. Any idea what causes this problem? Edited March 28, 20215 yr by C0bra_2056
March 28, 20215 yr Community Expert Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.
March 28, 20215 yr Community Expert Why are you running Mover every 5 minutes? Mover is intended for idle time. Since your cache is so small probably better to not cache any user share writes and just use it for fast storage for dockers / VMs. Your system share has some files on the array. You want appdata, domains, system shares all on cache so dockers / VMs won't be impacted by slower parity, and so they won't keep array disks spunup since they will always have files open.
March 28, 20215 yr Author Every 5 minutes? Mh, i was pretty new to the system and tried to learn. Wasted the whole day to get into the system. ATM i set it to an daily base for mover, before it was an hour. Dont know where the 5 minutes come from. An hour ago i already removed the cache option of my "StorageArray", the cache is now exlusive for the "DockerArray". But thx for the explanation, took a while to understand the cache logic in unRAID. Got any idea about the cpu core usage? I completely forgot to attach an screenshot, but i dont think it helps a lot if the diagnostics got already posted: EDIT: well the screenshot is kinda useless, the top part of htop is cut. But it shows that the cpu core is maxed out at 100%. Edited March 28, 20215 yr by C0bra_2056
April 1, 20215 yr Author I tried to search in the forum if somebody else got the same problem. Every other thread where i found the same problem was source of the problem the gui mode. Which was some kind of a bug that i reboots into the gui mode. So i plugged in my monitor and there was only a terminal session. Too bad. Back to zero.
April 1, 20215 yr Your diagnostics tell a process is taken all cpu resources, but I can't tell what it is. Your are loading a lot of plugins, start your system in safe mode and see if the same thing occurs.
April 1, 20215 yr Author Finally i got time today to restart the system. Alright, hooked up a monitor and restartet into safe mode (no GUI, no plugins). And the 100% cpu usage was gone (Diagnostic attached). After a another restart into normal mode (no GUI), there was again a core locked at 100% (Diagnostic attached aswell). Interesting fact was, after i set up unRAID at the beginning without installing any plugin, there was already this issue. Down below is a picture of htop showing the top cpu processes in normal mode with 100% cpu core usage, aswell a picture of all installed plugins. The Plugin Nerd Tool was only nessecery for the gpu dashboard installation. Unbalance is deactivated. normalmode-albert-diagnostics-20210401-1749.zip safemode-albert-diagnostics-20210401-1744.zip Edited April 1, 20215 yr by C0bra_2056
April 3, 20215 yr Author So now i deinstalled all plugins and did a new restart, well without changes. After that i installed back all plugins. What happens with unraid if you boot up in safe mode, besides disabling plugins and the possibility to start the array? albert-diagnostics-20210403-2203.zip
April 4, 20215 yr Author I got an idea today, and searched a bit in the "Setup" menu from htop. And removed the "x" from "Hide kernel threads. Now its possible to see which process is taking up the cpu usage. The command "kworker/3:2+pm" is taking round about 83-85% cpu usage. But i dont know what this process is good for. Anybody an idea?
May 12, 20215 yr Author Again i tried to find the problem, without success. Even disabled Docker and VM, removed all Plugins and stopped the Array. And the process and cpu usage was still there. Only restarting in safe mode gets rid of this problem.
Archived
This topic is now archived and is closed to further replies.