Vendredi dernier, j'ai mis à niveau mon serveur Ubuntu vers 11.10, qui fonctionne maintenant avec un noyau 3.0.0-12-server. Depuis lors, les performances globales ont chuté de façon spectaculaire. Avant la mise à niveau, la charge du système était d'environ 0,3, mais elle est actuellement de 22 à 30 sur un système à 8 cœurs avec 16 Go de RAM (10 Go gratuits, aucun échange utilisé).
J'allais blâmer le pilote du système de fichiers BTRFS et le tableau MD sous-jacent, car [md1_raid1] et [btrfs-transacti] consommaient beaucoup de ressources. Mais tous les [kworker / *: *] consomment beaucoup plus.
sar a produit quelque chose de similaire constamment depuis vendredi:
11:25:01 CPU %user %nice %system %iowait %steal %idle
11:35:01 all 1,55 0,00 70,98 8,99 0,00 18,48
11:45:01 all 1,51 0,00 68,29 10,67 0,00 19,53
11:55:01 all 1,40 0,00 65,52 13,53 0,00 19,55
12:05:01 all 0,95 0,00 66,23 10,73 0,00 22,10
Et iostatconfirme un taux d'écriture très faible:
sda 129,26 3059,12 614,31 258226022 51855269
sdb 98,78 24,28 3495,05 2049471 295023077
md1 191,96 202,63 611,95 17104003 51656068
md0 0,01 0,02 0,00 1980 109
La question est: comment savoir pourquoi les threads kworker consomment autant de ressources (et laquelle)? Ou mieux: est-ce un problème connu avec le noyau 3.0, et puis-je le modifier avec les paramètres du noyau?
Éditer:
J'ai mis à jour le noyau vers la toute nouvelle version 3.1 comme recommandé par les développeurs BTRFS. Mais malheureusement, cela n'a rien changé.
la source
pcie_ports=compatoupcie_ports=native. (Essayez d'abord «natif». Il est moins susceptible de résoudre le problème mais moins susceptible de causer d'autres problèmes.)Réponses:
J'ai trouvé ce fil sur lkml qui répond un peu à votre question. (Il semble que même Linus lui-même était perplexe quant à la façon de découvrir l'origine de ces fils.)
Fondamentalement, il existe deux façons de procéder:
Pour cela, vous aurez besoin de ftrace pour être compilé dans votre noyau, et pour l'activer avec:
Plus d'informations sur les fonctionnalités de traceur de fonctions de Linux sont disponibles dans la documentation ftrace.txt .
Cela affichera ce que les threads font tous et est utile pour tracer plusieurs petits travaux.
Cela produira la pile d'un seul thread effectuant beaucoup de travail. Il peut vous permettre de découvrir ce qui a causé ce thread spécifique à monopoliser le processeur (par exemple).
THE_OFFENDING_KWORKERest le pid du kworker dans la liste des processus.la source
-Eoption sleepd, et l'utilisation du processeur a disparu!La solution est: je ne sais pas trouver la cause. Personne ne m'a dit jusqu'à présent.
Mais parler avec les développeurs BTRFS a révélé un bogue dans les pilotes btrfs lors de l'écriture de nombreux petits fichiers en très peu de temps. Il s'agit d'un problème sur les noyaux de 3.0 à 3.1. Peut-être que cela est corrigé dans 3.2.
En attendant, j'ai obtenu un correctif pour le noyau actuel qui a résolu le problème.
la source
J'ai eu un problème similaire; en regardant la pile de threads de kworker:
J'ai pensé que ce sont les modules USB. J'avais auparavant sur une autre machine allègrement rmmodé tous les modules usb et [uex] hci ont réalisé que j'avais éteint le clavier (pas même ctrl-shift-sysrq-U!), Donc j'ai fini par faire ceci:
a fait l'affaire:
Donc, mon principal suspect est ce gadget: RTL8723B * Module WIFI + Bluetooth. Je me demande maintenant si le code de gestion de l'alimentation se rend compte que c'est le même appareil s'il essaie par exemple de mettre hors tension un adaptateur BT inutilisé.
le contexte:
la source
echo N >/sys/module/drm_kms_helper/parameters/poll(en mode root)Problème avec la carte graphique Intel
la source