web-dev-qa-db-fra.com

Pourquoi l'utilisation du processeur Kworker est-elle si élevée?

J'ai récemment installé Ubuntu 12.04 sur mon ordinateur portable Samsung aux côtés de Windows 7. À chaque fois que j'utilise Ubuntu (même s'il est inactif), kworker utilise près de 90% d'un des 8 cœurs. Même si cela n'affecte pas vraiment mon utilisation, cela me perturbe et j'ai peur que cela nuise à mon processeur. J'ai même essayé d'installer une autre distribution Linux (Linux Mint) et kworker a causé le même problème. Donc je ne sais pas quoi faire. J'apprécierais vraiment votre aide.

enter image description here

12.04performancecpu
37
Yusuf

Au lieu de cela, je pense que cette utilisation du processeur n'est pas normale et est liée au bogue bien connu de kworker: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/88779

La solution pour moi et pour beaucoup d’autres était tout d’abord de trouver le "gpe" à l’origine du problème avec:

grep . -r /sys/firmware/acpi/interrupts/

et vérifiez une valeur élevée (le mien était gpe13 - avec une valeur de 200K - vous devez donc le modifier en conséquence, si différent). Après ça:

~ cp /sys/firmware/acpi/interrupts/gpe13 /pathtobackup
~ crontab -e

Ajoutez cette ligne pour qu’elle soit exécutée à chaque démarrage/redémarrage:

@reboot echo "disable" > /sys/firmware/acpi/interrupts/gpe13

Sauvegarder/quitter. Ensuite, pour que cela fonctionne aussi après le réveil de suspendre:

~ touch /etc/pm/sleep.d/30_disable_gpe13
~ chmod +x /etc/pm/sleep.d/30_disable_gpe13
~ vim /etc/pm/sleep.d/30_disable_gpe13

Ajouter ce truc:

#!/bin/bash
case "$1" in
    thaw|resume)
        echo disable > /sys/firmware/acpi/interrupts/gpe13 2>/dev/null
        ;;
    *)
        ;;
esac
exit $?

Sauvegarder/quitter, c'est fait.

Testé et travaillant sur:

Ubuntu 12.10 on Samsung Chronos 7 series - Model no. NP700Z7C --
Ubuntu 16.04.2 on Clevo - Model no. P650RS --
60
Mauro Mascia

L'utilisation du processeur semble être normale, il n'y a qu'un seul processeur (CPU1) qui a une utilisation élevée. En tout, il y a au total 3 processus qui sont dans l'état en cours d'exécution, deux d'entre eux étant kworker et gnome-system-mo (les 2 premiers processus dans la brève commande supérieure que vous avez ajoutée).

"kworker" est un processus fictif pour les threads de travail du noyau, qui effectuent la majeure partie du traitement réel du noyau, en particulier dans les cas d'interruptions, de minuteries, d'E/S, etc. Ils correspondent généralement à la grande majorité des tâches allouées " système "le temps nécessaire pour exécuter les processus. Ce n'est pas quelque chose qui peut être retiré en toute sécurité du système de quelque manière que ce soit, et n'a absolument aucun lien avec nepomuk ou KDE (sauf que ces programmes peuvent faire des appels système, ce qui peut obliger le noyau à faire quelque chose)

Pour plus d'informations sur kworker, veuillez consulter le lien suivant: - Qu'est-ce que KWorker et son importance

3
Ankit

J'ai installé Linux Mint 17 hier et j'ai remarqué ce soir que Kworker consommait 100% de l'un des 4 processeurs. J'ai exécuté le contrôle ci-dessus, mais je n'ai rien trouvé d'autre que 0 pour les interruptions.

Lors de l’examen des services que j’exécutais normalement, j’ai remarqué que l’arrêt du serveur nfs avait lâché le thread kworker sur zilch. Un redémarrage du serveur nfs n'a pas résolu le problème.

J'ai trouvé ce rapport de bogue ( https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1322407 ), ce qui indique qu'un problème de serveur NFS similaire a été résolu dans le noyau 3.13. 0-32,57. La dernière mise à jour de Mint 17 semble utiliser le noyau 3.13.0-24-generic. Je n'ai donc pas le correctif dans le noyau que je suis en train d'exécuter. Je ne sais pas si cela aidera quelqu'un d'autre, mais je suis systématiquement allé sur chaque machine cliente nfs et ai fait un 'umount -a -t nfs' et ai attendu de voir s'il avait un effet. J'ai trouvé le client qui semblait être à l'origine du problème, car le Kworker est tombé à néant après mon démontage. J'ai remonté les partages nfs sur le client 'mount -a -t nfs' et le problème n'est pas revenu.

0
Jack