Pourquoi kworker consomme-t-il autant de ressources sur Linux 3.0.0-12-server?


19

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é.


Voir askubuntu.com/questions/33640/… . J'ajouterais à ses suggestions la suppression des modules du noyau un à la fois pour voir s'il s'agit d'un module spécifique.
Shawn J.Goff

@ ShawnJ.Goff Il s'agit simplement d'une solution de contournement fournie par essais et erreurs. Mais je veux savoir comment identifier le coupable avec certains outils (de débogage). Cela devrait alors me conduire à un module du noyau en question.
mailq

Essayez de démarrer avec pcie_ports=compatou pcie_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.)
David Schwartz

@DavidSchwartz N'a pas changé. Ce serait également juste une solution pour éviter le problème. Mais je dois identifier le problème moi-même pour ensuite élaborer une solution. Comment puis-je identifier la cause?
mailq

Réponses:


18

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:

$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
(wait a few secs)

Pour cela, vous aurez besoin de ftrace pour être compilé dans votre noyau, et pour l'activer avec:

mount -t debugfs nodev /sys/kernel/debug

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.

cat /proc/THE_OFFENDING_KWORKER/stack

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.


Merci. J'ai dû répéter le fichier de pile à plusieurs reprises jusqu'à ce qu'il soit assez long pour fournir des informations. Dans mon cas, j'ai trouvé "acpi_ds_create_operands" et "input_polled_device_work". Une supposition chanceuse m'a fait essayer l' -Eoption sleepd, et l'utilisation du processeur a disparu!
joeytwiddle

5

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.


2

J'ai eu un problème similaire; en regardant la pile de threads de kworker:

while true ; do clear ; grep -n ^ /proc/24910/stack | sort -rn | cut -d: -f 2- ; sleep 1 ; done

[<ffffffffffffffff>] 0xffffffffffffffff
[<ffffffff810908f0>] kthread+0x0/0xe0
[<ffffffff81576432>] ret_from_fork+0x42/0x70
[<ffffffff810908f0>] kthread+0x0/0xe0
[<ffffffff810909b1>] kthread+0xc1/0xe0
[<ffffffff8108b520>] worker_thread+0x0/0x550
[<ffffffff8108b573>] worker_thread+0x53/0x550
[<ffffffff8108aa4b>] process_one_work+0x14b/0x420
[<ffffffff81405a3d>] rpm_idle+0x1ad/0x220
[<ffffffff8140509d>] __rpm_callback+0x2d/0xb0
[<ffffffffa01aef16>] usb_runtime_idle+0x26/0x30 [usbcore]
[<ffffffffa01aeef0>] usb_runtime_idle+0x0/0x30 [usbcore]
[<ffffffff8140686c>] __pm_runtime_suspend+0x5c/0x90
[<ffffffff81405b19>] __pm_runtime_idle+0x69/0x90
[<ffffffff81405295>] rpm_suspend+0x105/0x620
[<ffffffff8140513f>] rpm_callback+0x1f/0x70
[<ffffffff8140509d>] __rpm_callback+0x2d/0xb0
[<ffffffffa01aee50>] usb_runtime_suspend+0x0/0x80 [usbcore]
[<ffffffffa01aee7e>] usb_runtime_suspend+0x2e/0x80 [usbcore]
[<ffffffffa01adc4f>] usb_suspend_both+0xef/0x1f0 [usbcore]
[<ffffffffa01adb06>] usb_resume_interface.isra.6+0xa6/0x100 [usbcore]
[<ffffffffa01a0c63>] hub_resume+0x23/0x60 [usbcore]
[<ffffffffa01a0636>] hub_activate+0xc6/0x5c0 [usbcore]
[<ffffffffa01a9d3f>] usb_kill_urb+0x3f/0xa0 [usbcore]
[<ffffffffa019d249>] hub_port_status+0xd9/0x120 [usbcore]
[<ffffffff81088a4f>] __queue_work+0x12f/0x340
[<ffffffff810888b6>] insert_work+0x46/0xb0
[<ffffffffa01aa6d4>] usb_control_msg+0xc4/0x110 [usbcore]
[<ffffffffa01aa55a>] usb_start_wait_urb+0x9a/0x150 [usbcore]
[<ffffffff810a36f7>] update_curr+0xd7/0x120

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:

MODS="uvcvideo ohci_hcd ehci_hcd xhci_hcd ohci_pci ehci_pci xhci_pci usbcore"
( echo $MODS $MODS | xargs -n 1 rmmod -v ; sleep 3 ; echo $MODS | xargs -n 1 modprobe -v ; )

root@hp:~# ( echo $MODS $MODS | xargs -n 1 rmmod -v ; sleep 3 ; echo $MODS | xargs -n 1 modprobe -v ; )
rmmod: ERROR: Module ohci_hcd is in use by: ohci_pci
rmmod: ERROR: Module ehci_hcd is in use by: ehci_pci
rmmod: ERROR: Module xhci_hcd is in use by: xhci_pci
rmmod: ERROR: Module uvcvideo is not currently loaded
rmmod: ERROR: Module ohci_pci is not currently loaded
rmmod: ERROR: Module ehci_pci is not currently loaded
rmmod: ERROR: Module xhci_pci is not currently loaded
insmod /lib/modules/4.1.0-2-amd64/kernel/drivers/media/usb/uvc/uvcvideo.ko 
insmod /lib/modules/4.1.0-2-amd64/kernel/drivers/usb/host/ehci-hcd.ko 
insmod /lib/modules/4.1.0-2-amd64/kernel/drivers/usb/host/ohci-hcd.ko 
insmod /lib/modules/4.1.0-2-amd64/kernel/drivers/usb/host/xhci-hcd.ko 
insmod /lib/modules/4.1.0-2-amd64/kernel/drivers/usb/host/ehci-pci.ko 
insmod /lib/modules/4.1.0-2-amd64/kernel/drivers/usb/host/ohci-pci.ko 
insmod /lib/modules/4.1.0-2-amd64/kernel/drivers/usb/host/xhci-pci.ko 

a fait l'affaire:

grep -n ^ /proc/24910/stack | sort -rn | cut -d: -f 2-
[<ffffffffffffffff>] 0xffffffffffffffff
[<ffffffff810908f0>] kthread+0x0/0xe0
[<ffffffff81576432>] ret_from_fork+0x42/0x70
[<ffffffff810908f0>] kthread+0x0/0xe0
[<ffffffff810909b1>] kthread+0xc1/0xe0
[<ffffffff8108b520>] worker_thread+0x0/0x550
[<ffffffff8108b5ec>] worker_thread+0xcc/0x550

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:

root@hp:~# lsusb
    Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 002 Device 002: ID 0c45:651b Microdia 
    Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 003 Device 002: ID 0bda:b001 Realtek Semiconductor Corp. 
    Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 007 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@hp:~# lsmod | grep usb
    btusb                  45056  0
    btbcm                  16384  1 btusb
    btintel                16384  1 btusb
    bluetooth             438272  5 bnep,btbcm,btusb,btintel
    usbcore               200704  8 btusb,uvcvideo,ohci_hcd,ohci_pci,ehci_hcd,ehci_pci,xhci_hcd,xhci_pci
    usb_common             16384  1 usbcore

root@hp:~# lsb_release -a
    No LSB modules are available.
    Distributor ID:    Debian
    Description:    Debian GNU/Linux stable-updates (sid)
    Release:    stable-updates
    Codename:    sid

root@hp:~# uname -a
    Linux hp 4.1.0-2-amd64 #1 SMP Debian 4.1.6-1 (2015-08-23) x86_64 GNU/Linux

root@hp:~# dmesg | tail -n 20
    [97865.088740] usb 2-4: SerialNumber: HP Webcam
    [97865.091557] uvcvideo: Found UVC 1.00 device HP Webcam (0c45:651b)
    [97865.105948] input: HP Webcam as /devices/pci0000:00/0000:00:13.2/usb2/2-4/2-4:1.0/input/input17
    [97865.189817] usb 3-3: new full-speed USB device number 2 using ohci-pci
    [97865.350981] usb 3-3: No LPM exit latency info found, disabling LPM.
    [97865.368958] usb 3-3: New USB device found, idVendor=0bda, idProduct=b001
    [97865.368969] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [97865.368976] usb 3-3: Product: Bluetooth Radio 
    [97865.368981] usb 3-3: Manufacturer: Realtek 
    [97865.368985] usb 3-3: SerialNumber: 00e04c000001
    [97865.375859] Bluetooth: hci0: rtl: examining hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723
    [97865.375867] Bluetooth: hci0: rtl: loading rtl_bt/rtl8723b_fw.bin
    [97865.375896] usb 3-3: firmware: failed to load rtl_bt/rtl8723b_fw.bin (-2)
    [97865.375902] usb 3-3: Direct firmware load for rtl_bt/rtl8723b_fw.bin failed with error -2
    [97865.375907] Bluetooth: hci0: Failed to load rtl_bt/rtl8723b_fw.bin
    [97865.397812] Bluetooth: hci0: rtl: examining hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723
    [97865.397821] Bluetooth: hci0: rtl: loading rtl_bt/rtl8723b_fw.bin
    [97865.397850] usb 3-3: firmware: failed to load rtl_bt/rtl8723b_fw.bin (-2)
    [97865.397856] usb 3-3: Direct firmware load for rtl_bt/rtl8723b_fw.bin failed with error -2
    [97865.397861] Bluetooth: hci0: Failed to load rtl_bt/rtl8723b_fw.bin

-2

echo N >/sys/module/drm_kms_helper/parameters/poll (en mode root)

Problème avec la carte graphique Intel


5
Comment savez-vous que c'est la cause?
vonbrand
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.