A fresh ZimaOS install sitting near 30% CPU for many hours should not automatically be dismissed as “normal,” especially when the process list points to kworker. The useful next step is to identify which kernel worker is active and what device or interrupt is keeping it busy.
In this thread, AI Search was ruled out and the user still saw the behavior after roughly ten hours. The low temperature and power draw were reassuring, but they did not prove why the kernel workers were active.
What the Thread Actually Showed
The original system used an i3-6100T with two cores and four threads. A community reply first suggested post-install activity and Web UI polling, but the user later confirmed the load persisted for about ten hours and AI Search was disabled.
Another reply described kworker as kernel work related to drivers, interrupts, power management, disks and networking. That description is broadly correct, but the conclusion that 25–30% is always harmless on a two-core CPU was not proven by the thread.
Identify the Busy Worker Before Changing Settings
Start with the process list while the dashboard shows the spike. If one kworker thread repeatedly rises at the same time, record its name, CPU percentage and the exact timestamp. Then check whether the activity changes when you disconnect optional USB devices, idle disks, extra NICs or other hardware one at a time.
The same principle appears in the NAS bottleneck checklist: correlate the symptom with the resource and process that changes at the same moment instead of upgrading hardware based on one graph.
Rule Out Background Work and Recent Bugs
Fresh installs can perform discovery, indexing and service initialization, so a short spike after boot is not automatically a fault. But persistence for many hours changes the diagnosis. Close the Web UI, stop nonessential apps, confirm AI Search state and reboot once to see whether the same worker returns.
Also compare behavior after updating to the current release. The ZimaOS 1.7.1 notes include stability and memory fixes, although they do not specifically claim to fix this February 2026 kworker report.
When to Escalate
Escalate when one worker stays busy after a clean reboot, temperatures or wattage climb, the system becomes slow, or the load changes predictably with one device. Capture the ZimaOS version, hardware model, top output and the exact worker name.
For a general method of separating CPU pressure from storage or network pressure, the resource bottleneck method uses the same evidence-first approach.
Bottom Line
The thread did not prove that 30% idle CPU is normal for every low-core ZimaOS system. Low temperature and power are good signs, but persistent kworker usage still deserves process-level and device-level isolation before it is accepted as harmless.
