Por que o kworker consome tantos recursos no Linux 3.0.0-12-server?


19

Na última sexta-feira, atualizei meu servidor Ubuntu para 11.10, que agora roda com um kernel 3.0.0-12. Desde então, o desempenho geral caiu drasticamente. Antes da atualização, a carga do sistema era de cerca de 0,3, mas atualmente é de 22 a 30 em um sistema de CPU de 8 núcleos com 16 GB de RAM (10 GB gratuitos, sem troca usada).

Eu culparia o driver do sistema de arquivos BTRFS e a matriz MD subjacente, porque [md1_raid1] e [btrfs-transacti] consumiram muitos recursos. Mas todo o [kworker / *: *] consome muito mais.

sar produziu algo semelhante a isso constantemente desde sexta-feira:

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 

E iostatconfirma uma taxa de gravação muito ruim:

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          

A pergunta é: como rastrear por que os threads do kworker consomem tantos recursos (e qual)? Ou melhor: esse é um problema conhecido do kernel 3.0 e posso ajustá-lo com os parâmetros do kernel?

Editar:

Atualizei o Kernel para a nova versão 3.1, conforme recomendado pelos desenvolvedores do BTRFS. Mas, infelizmente, isso não mudou nada.


Veja askubuntu.com/questions/33640/… . Eu acrescentaria às suas sugestões removendo os módulos do kernel, um de cada vez, para ver se é um específico.
Shawn J. Goff

@ ShawnJ.Goff Esta é apenas uma solução alternativa fornecida por tentativa e erro. Mas quero saber como posso identificar o culpado com algumas ferramentas (de depuração). Isso deve me levar a um módulo do kernel em questão.
mailq

Tente inicializar com pcie_ports=compatou pcie_ports=native. (Tente 'nativo' primeiro É menos provável para corrigir o problema, mas menos provável de causar outros problemas..)
David Schwartz

@DavidSchwartz Não mudou. Isso também seria apenas uma solução para evitar o problema. Mas preciso identificar o problema para elaborar uma solução. Como posso identificar a causa?
mailq

Respostas:


18

Encontrei este tópico no lkml que responde um pouco à sua pergunta. (Parece que até o próprio Linus ficou intrigado sobre como descobrir a origem desses tópicos.)

Basicamente, existem duas maneiras de fazer isso:

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

Para isso, você precisará que o ftrace seja compilado no seu kernel e habilite-o com:

mount -t debugfs nodev /sys/kernel/debug

Mais informações sobre os recursos de rastreador de funções do Linux estão disponíveis na documentação ftrace.txt .

Isso produzirá o que todos os threads estão fazendo e é útil para rastrear vários trabalhos pequenos.

cat /proc/THE_OFFENDING_KWORKER/stack

Isso produzirá a pilha de um único thread fazendo muito trabalho. Pode permitir que você descubra o que causou esse encadeamento específico para monopolizar a CPU (por exemplo). THE_OFFENDING_KWORKERé o pid do kworker na lista de processos.


Obrigado. Eu tive que repetidamente localizar o arquivo de pilha até que ele ficasse tempo suficiente para fornecer algumas informações. No meu caso, encontrei "acpi_ds_create_operands" e "input_polled_device_work". Um palpite de sorte me fez tentar a -Eopção de dormir, e o uso da CPU desapareceu!
joeytwiddle

5

A solução é: não sei como encontrar a causa. Ninguém me disse até agora.

Mas conversar com os desenvolvedores do BTRFS revelou um erro nos drivers btrfs ao gravar muitos arquivos pequenos em um período muito curto. Este é um problema nos kernels de 3.0 até 3.1. Talvez isso seja corrigido no 3.2.

Enquanto isso, recebi um patch para o kernel atual que resolveu o problema.


2

Eu tive uma questão semelhante; olhando para a pilha de threads do 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

Eu achei que eram os módulos usb. Eu tinha anteriormente em outra máquina alegremente rmmod'd todos os módulos usb e [uex] hci percebem que havia desligado o teclado (nem mesmo ctrl-shift-sysrq-U!), Então acabei fazendo o seguinte:

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 

fez o truque:

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

Então, meu principal suspeito é este dispositivo: RTL8723B * WIFI + Módulo Bluetooth. Gostaria de saber agora se o código de gerenciamento de energia percebe que é o mesmo dispositivo se tentar, por exemplo, desligar um adaptador BT não utilizado.

contexto:

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 (no modo raiz)

Problema com a placa gráfica Intel


5
Como você sabe que essa é a causa?
vonbrand
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.