Une nouvelle installation de ZimaOS qui reste à près de 30 % d’utilisation du processeur pendant plusieurs heures ne devrait pas automatiquement être considérée comme « normale », en particulier lorsque la liste des processus indique kworker. L’étape utile suivante consiste à identifier le thread de travail du noyau actif et le périphérique ou l’interruption qui le maintient occupé.
Dans cette discussion, AI Search a été écarté et l’utilisateur observait toujours le comportement après environ dix heures. La faible température et la faible consommation électrique étaient rassurantes, mais ne permettaient pas de déterminer pourquoi les threads de travail du noyau étaient actifs.
Ce que la discussion a réellement montré
Le système d’origine utilisait un i3-6100T doté de deux cœurs et de quatre threads. Une réponse de la communauté a d’abord évoqué des tâches post-installation et l’interrogation de l’interface Web, mais l’utilisateur a ensuite confirmé que la charge persistait depuis environ dix heures et qu’AI Search était désactivé.
Une autre réponse décrivait kworker comme le travail du noyau lié aux pilotes, aux interruptions, à la gestion de l’alimentation, aux disques et au réseau. Cette description est globalement correcte, mais la conclusion selon laquelle une utilisation de 25 à 30 % est toujours inoffensive sur un processeur à deux cœurs n’a pas été démontrée par la discussion.
Identifiez le thread actif avant de modifier les réglages
Commencez par consulter la liste des processus lorsque le tableau de bord affiche le pic. Si un thread kworker augmente régulièrement au même moment, notez son nom, son pourcentage d’utilisation du processeur et l’horodatage exact. Vérifiez ensuite si l’activité change lorsque vous déconnectez tour à tour les périphériques USB facultatifs, mettez les disques au repos, débranchez les cartes réseau supplémentaires ou retirez d’autres composants matériels.
Le même principe apparaît dans la liste de contrôle des goulots d’étranglement d’un NAS : corrélez le symptôme avec la ressource et le processus qui changent au même moment, au lieu de mettre à niveau le matériel sur la base d’un seul graphique.
Écartez les tâches en arrière-plan et les bugs récents
Les nouvelles installations peuvent effectuer la découverte, l’indexation et l’initialisation des services : un bref pic après le démarrage n’est donc pas automatiquement un problème. En revanche, une persistance durant plusieurs heures modifie le diagnostic. Fermez l’interface Web, arrêtez les applications non essentielles, vérifiez l’état d’AI Search et redémarrez une fois pour voir si le même thread réapparaît.
Comparez également le comportement après la mise à jour vers la version actuelle. Les notes de ZimaOS 1.7.1 mentionnent des correctifs de stabilité et de mémoire, sans toutefois prétendre corriger spécifiquement ce signalement de kworker datant de février 2026.
Quand faire remonter le problème
Faites remonter le problème lorsqu’un thread reste actif après un redémarrage propre, que la température ou la puissance augmentent, que le système ralentit ou que la charge varie de manière prévisible avec un périphérique donné. Indiquez la version de ZimaOS, le modèle matériel, la sortie de top et le nom exact du thread.
Pour une méthode générale permettant de distinguer la pression exercée sur le processeur de celle exercée sur le stockage ou le réseau, la méthode d’identification des goulots d’étranglement des ressources applique la même approche fondée sur les faits.
En résumé
La discussion n’a pas démontré qu’une utilisation de 30 % du processeur au repos est normale sur tous les systèmes ZimaOS équipés d’un processeur comportant peu de cœurs. Une faible température et une faible consommation sont de bons signes, mais une utilisation persistante de kworker mérite tout de même une isolation au niveau des processus et des périphériques avant d’être considérée comme inoffensive.
