Tại sao kworker tiêu thụ nhiều tài nguyên trên máy chủ Linux 3.0.0-12?

Thứ sáu tuần trước, tôi đã nâng cấp máy chủ Ubuntu của mình lên 11.10, hiện đang chạy với nhân máy chủ 3.0.0-12. Kể từ đó hiệu suất tổng thể đã giảm đáng kể. Trước khi nâng cấp, hệ thống tải khoảng 0,3, nhưng hiện tại nó ở mức 22-30 trên hệ thống CPU 8 nhân với 16GB RAM (miễn phí 10 GB, không sử dụng trao đổi).

Tôi sẽ đổ lỗi cho trình điều khiển hệ thống tệp BTRFS và mảng MD bên dưới, bởi vì [md1_ston1] và [btrfs-transacti] đã tiêu tốn rất nhiều tài nguyên. Nhưng tất cả [kworker / *: *] tiêu thụ nhiều hơn thế.

sar đã xuất ra một cái gì đó tương tự như thế này liên tục kể từ thứ Sáu:

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 

Và iostatxác nhận tỷ lệ ghi rất kém:

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          

Câu hỏi là: Làm thế nào tôi có thể theo dõi lý do tại sao các luồng kworker tiêu thụ nhiều tài nguyên (và cái nào)? Hoặc tốt hơn: Đây có phải là sự cố đã biết với kernel 3.0 không và tôi có thể điều chỉnh nó với các tham số kernel không?

Chỉnh sửa:

Tôi đã cập nhật Kernel lên phiên bản hoàn toàn mới 3.1 theo khuyến nghị của các nhà phát triển BTRFS. Nhưng thật không may, điều này đã không thay đổi bất cứ điều gì.

Tôi tìm thấy chủ đề này trên lkml mà trả lời câu hỏi của bạn một chút. (Có vẻ như ngay cả bản thân Linus cũng bối rối không biết làm thế nào để tìm ra nguồn gốc của những chủ đề đó.)

Về cơ bản, có hai cách để làm điều này:

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

Đối với điều này, bạn sẽ cần ftrace được biên dịch trong kernel của bạn và để kích hoạt nó với:

mount -t debugfs nodev /sys/kernel/debug

Thông tin thêm về các tiện ích theo dõi chức năng của Linux có sẵn trong tài liệu ftrace.txt .

Điều này sẽ xuất ra tất cả các chủ đề đang làm và rất hữu ích để theo dõi nhiều công việc nhỏ.

cat /proc/THE_OFFENDING_KWORKER/stack

Điều này sẽ xuất ra ngăn xếp của một chủ đề duy nhất làm rất nhiều công việc. Nó có thể cho phép bạn tìm hiểu nguyên nhân gây ra luồng cụ thể này để làm hỏng CPU (ví dụ). THE_OFFENDING_KWORKERlà pid của kworker trong danh sách quá trình.

Giải pháp là: Tôi không biết cách tìm ra nguyên nhân. Không ai nói với tôi cho đến nay.

Nhưng nói chuyện với các nhà phát triển BTRFS đã tiết lộ một lỗi trong trình điều khiển btrfs khi viết nhiều tệp nhỏ trong một khoảng thời gian rất ngắn. Đây là một vấn đề về hạt nhân từ 3.0 đến 3.1. Có lẽ nó được sửa trong 3.2.

Trong khi đó, tôi đã có một bản vá cho kernel hiện tại đã giải quyết vấn đề.

Tôi đã có một vấn đề tương tự; nhìn vào ngăn xếp chủ đề của 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

Tôi hình dung đó là các mô-đun usb. Trước đây tôi đã sử dụng một máy khác hoàn toàn rmmod'd tất cả các mô-đun usb và [uex] hci nhận ra rằng tôi đã tắt bàn phím (thậm chí không phải ctrl-shift-sysrq-U!), Vì vậy tôi đã kết thúc việc này:

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 

đã lừa

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

Vì vậy, nghi ngờ chính của tôi là tiện ích này: RTL8723B * WIFI + Module Bluetooth. Bây giờ tôi đang tự hỏi liệu mã quản lý năng lượng có nhận ra đó là cùng một thiết bị hay không nếu nó cố gắng tắt nguồn bộ chuyển đổi BT không sử dụng.

bối cảnh:

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

echo N >/sys/module/drm_kms_helper/parameters/poll (ở chế độ root)

Sự cố với card đồ họa Intel