Warum verbraucht kworker so viele Ressourcen auf Linux 3.0.0-12-Servern?

19

Letzten Freitag habe ich meinen Ubuntu-Server auf 11.10 aktualisiert, der jetzt mit einem 3.0.0-12-Server-Kernel läuft. Seitdem ist die Gesamtleistung dramatisch gesunken. Vor dem Upgrade betrug die Systemlast ca. 0,3, auf einem 8-Kern-CPU-System mit 16 GB RAM (10 GB frei, kein Swap verwendet) liegt sie derzeit bei 22-30.

Ich wollte den BTRFS-Dateisystemtreiber und das darunterliegende MD-Array beschuldigen, da [md1_raid1] und [btrfs-transacti] eine Menge Ressourcen verbraucht haben. Aber alle [kworker / *: *] verbrauchen viel mehr.

sar hat seit Freitag ständig etwas Ähnliches ausgegeben:

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

Und iostatbestätigt eine sehr schlechte Schreibrate:

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

Die Frage ist: Wie kann ich herausfinden, warum die kworker-Threads so viele Ressourcen verbrauchen (und welche)? Oder besser: Ist dies ein bekanntes Problem mit dem 3.0-Kernel und kann ich es mit Kernel-Parametern optimieren?

Bearbeiten:

Ich habe den Kernel auf die brandneue Version 3.1 aktualisiert, wie von den BTRFS-Entwicklern empfohlen. Daran hat sich leider nichts geändert.

kernel  performance  cpu  load 
— mailq
quelle
Siehe askubuntu.com/questions/33640/… . Ich würde zu seinen Vorschlägen hinzufügen, Kernelmodule einzeln zu entfernen, um festzustellen, ob es sich um ein bestimmtes handelt.
— Shawn J. Goff
@ ShawnJ.Goff Dies ist nur eine Problemumgehung, die durch Ausprobieren bereitgestellt wird. Aber ich möchte wissen, wie ich den Täter mit einigen (Debug-) Tools identifizieren kann. Dies sollte mich dann zu einem fraglichen Kernelmodul führen.
— mailq
Versuchen Sie, mit pcie_ports=compatoder zu booten pcie_ports=native. (Versuchen Sie zuerst "native". Es ist weniger wahrscheinlich, das Problem zu beheben, aber weniger wahrscheinlich, andere Probleme zu verursachen.)
— David Schwartz
@DavidSchwartz Hat sich nicht geändert. Dies wäre auch nur eine Lösung, um das Problem zu vermeiden. Aber ich muss das Problem selbst identifizieren, um dann eine Lösung zu finden. Wie kann ich die Ursache identifizieren?
— mailq

Antworten:

18

Ich habe diesen Thread auf lkml gefunden , der Ihre Frage ein wenig beantwortet. (Es scheint, als wäre sogar Linus selbst verwirrt, wie er den Ursprung dieser Fäden herausfinden könnte.)

Grundsätzlich gibt es zwei Möglichkeiten:

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

Dafür benötigen Sie ftrace , um in Ihrem Kernel kompiliert zu werden und um es zu aktivieren mit:

mount -t debugfs nodev /sys/kernel/debug

Weitere Informationen zu den Funktionen des Function Tracers von Linux finden Sie in der Dokumentation zu ftrace.txt .

Dies gibt aus, was alle Threads tun, und ist nützlich, um mehrere kleine Jobs zu verfolgen.

cat /proc/THE_OFFENDING_KWORKER/stack

Dadurch wird der Stapel eines einzelnen Threads ausgegeben, der viel Arbeit leistet. Hier können Sie möglicherweise herausfinden, warum dieser bestimmte Thread (zum Beispiel) die CPU blockiert hat. THE_OFFENDING_KWORKERist die pid des kworkers in der prozessliste.

— Anarkatze
quelle
Vielen Dank. Ich musste die Stapeldatei wiederholt durchsuchen, bis sie lang genug wurde, um einige Informationen bereitzustellen. In meinem Fall habe ich "acpi_ds_create_operands" und "input_polled_device_work" gefunden. Ich hatte das Glück, die -EOption zum Schlafen zu nutzen, und die CPU-Auslastung verschwand!
— Joeytwiddle
5

Die Lösung lautet: Ich weiß nicht, wie ich die Ursache finden soll. Bisher hat mir noch niemand davon erzählt.

Im Gespräch mit den BTRFS-Entwicklern wurde jedoch ein Fehler in den btrfs-Treibern entdeckt, als viele kleine Dateien in sehr kurzer Zeit geschrieben wurden. Dies ist ein Problem bei Kerneln von 3.0 bis 3.1. Vielleicht wird es in 3.2 behoben.

In der Zwischenzeit habe ich einen Patch für den aktuellen Kernel bekommen, der das Problem behoben hat.

— mailq
quelle
2

Ich hatte ein ähnliches Problem. Blick auf den Thread-Stack des Arbeiters:

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

Ich dachte, es sind die USB-Module. Ich hatte zuvor auf einem anderen Rechner mühelos alle USB- und [uex] HCI-Module modifiziert, als mir klar wurde, dass ich die Tastatur ausgeschaltet hatte (nicht einmal Strg-Umschalt-Sysrq-U!), Also endete ich damit:

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

hat den Trick gemacht:

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

Mein Hauptverdächtiger ist also dieses Gerät: RTL8723B * WIFI + Bluetooth-Modul. Ich frage mich jetzt, ob der Energieverwaltungscode erkennt, dass es sich um dasselbe Gerät handelt, wenn z. B. versucht wird, einen nicht verwendeten BT-Adapter herunterzufahren.

Kontext:

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
quelle
-2

echo N >/sys/module/drm_kms_helper/parameters/poll (im root-Modus)

Problem mit der Intel-Grafikkarte

— RaqUi
quelle
5
Woher weißt du, dass das die Ursache ist?
— Vonbrand
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.