Perché kworker sta consumando così tante risorse sul server Linux 3.0.0-12?

19

Venerdì scorso ho aggiornato il mio server Ubuntu a 11.10, che ora funziona con un kernel 3.0.0-12-server. Da allora le prestazioni complessive sono diminuite drasticamente. Prima dell'aggiornamento il carico di sistema era di circa 0,3, ma attualmente è a 22-30 su un sistema CPU a 8 core con 16 GB di RAM (10 GB gratuiti, nessuno scambio utilizzato).

Stavo incolpando il driver del file system BTRFS e l'array MD sottostante, perché [md1_raid1] e [btrfs-transacti] hanno consumato molte risorse. Ma tutti i [kworker / *: *] consumano molto di più.

sar ha emesso qualcosa di simile a questo costantemente da venerdì:

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 iostatconferma un tasso di scrittura molto scarso:

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 domanda è: come posso rintracciare perché i thread di kworker consumano così tante risorse (e quale)? O meglio: si tratta di un problema noto con il kernel 3.0 e posso modificarlo con i parametri del kernel?

Modificare:

Ho aggiornato il kernel alla nuovissima versione 3.1 come raccomandato dagli sviluppatori BTRFS. Ma sfortunatamente questo non ha cambiato nulla.

— mailq
fonte

Vedi askubuntu.com/questions/33640/… . Vorrei aggiungere ai suoi suggerimenti la rimozione dei moduli del kernel uno alla volta per vedere se si tratta di uno specifico.

— Shawn J. Goff,

@ ShawnJ.Goff Questa è solo una soluzione alternativa fornita da tentativi ed errori. Ma voglio sapere come posso identificare il colpevole con alcuni strumenti (di debug). Questo dovrebbe quindi portarmi a un modulo del kernel in questione.

— mailq,

Prova ad avviare con pcie_ports=compato pcie_ports=native. (Prova prima "nativo". È meno probabile che risolva il problema ma meno probabilità di causare altri problemi.)

— David Schwartz,

@DavidSchwartz Non è cambiato. Questa sarebbe anche solo una soluzione per evitare il problema. Ma devo identificare personalmente il problema per poi elaborare una soluzione. Come posso identificare la causa?

— mailq

18

Ho trovato questa discussione su lkml che risponde un po 'alla tua domanda. (Sembra che anche lo stesso Linus fosse perplesso su come scoprire l'origine di quei fili.)

Fondamentalmente, ci sono due modi per farlo:

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

Per questo avrai bisogno di compilare ftrace nel tuo kernel e abilitarlo con:

mount -t debugfs nodev /sys/kernel/debug

Maggiori informazioni sulle funzionalità del tracciante funzioni di Linux sono disponibili nella documentazione di ftrace.txt .

Ciò genererà ciò che tutti i thread stanno facendo ed è utile per tracciare più piccoli lavori.

cat /proc/THE_OFFENDING_KWORKER/stack

Questo produrrà lo stack di un singolo thread facendo molto lavoro. Potrebbe consentirti di scoprire che cosa ha causato questo specifico thread ad arrestare la CPU (ad esempio). THE_OFFENDING_KWORKERè il pid del kworker nell'elenco dei processi.

— anarcat
fonte

Grazie. Ho dovuto ripetere più volte il file dello stack fino a quando non ha avuto il tempo necessario per fornire alcune informazioni. Nel mio caso, ho trovato "acpi_ds_create_operands" e "input_polled_device_work". Un'ipotesi fortunata mi ha fatto provare l' -Eopzione sleepd e l'utilizzo della CPU è scomparso!

— joeytwiddle,

5

La soluzione è: non so come trovare la causa. Nessuno me l'ha detto finora.

Ma parlare con gli sviluppatori BTRFS ha rivelato un errore nei driver btrfs quando scrivevano molti file di piccole dimensioni in un periodo di tempo molto breve. Questo è un problema sui kernel dalla 3.0 alla 3.1. Forse si risolve in 3.2.

Nel frattempo ho ottenuto una patch per l'attuale kernel che ha risolto il problema.

— mailq
fonte

2

Ho avuto un problema simile; guardando lo stack di thread del 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

Ho pensato che fossero i moduli USB. In precedenza avevo su un'altra macchina rmmodamente benedetto tutti i moduli USB e [uex] hci sono stati resi conto che avevo spento la tastiera (nemmeno ctrl-shift-sysrq-U!), Quindi ho finito per farlo:

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

ha fatto il trucco:

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

Quindi il mio principale sospettato è questo gadget: RTL8723B * Modulo WIFI + Bluetooth. Mi chiedo ora se il codice di gestione dell'alimentazione si rende conto che è lo stesso dispositivo se tenta ad esempio di spegnere un adattatore BT inutilizzato.

contesto:

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

— jmullee
fonte

-2

echo N >/sys/module/drm_kms_helper/parameters/poll (in modalità root)

Problema con la scheda grafica Intel

— Raqui
fonte

5

Come fai a sapere che questa è la causa?

— vonbrand