为什么 kworker 在 Linux 3.0.0-12-server 上消耗这么多资源?

mai*_*ilq 21 performance cpu kernel load

上周五,我将我的 Ubuntu 服务器升级到 11.10,它现在使用 3.0.0-12-server 内核运行。从那以后,整体性能急剧下降。升级前系统负载约为 0.3,但目前在具有 16GB RAM(10GB 空闲,未使用交换)的 8 核 CPU 系统上为 22-30。

我要责怪 BTRFS 文件系统驱动程序和底层 MD 阵列,因为 [md1_raid1] 和 [btrfs-transacti] 消耗了大量资源。但是所有的 [kworker/*:*] 消耗更多。

sar 自周五以来,一直在输出类似的东西:

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 
Run Code Online (Sandbox Code Playgroud)

并iostat确认写入率非常低:

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          
Run Code Online (Sandbox Code Playgroud)

问题是:我如何才能追踪为什么 kworker 线程消耗这么多资源(以及哪个)?或者更好:这是 3.0 内核的已知问题,我可以使用内核参数对其进行调整吗?

编辑:

我按照 BTRFS 开发人员的建议将内核更新为全新的 3.1 版。但不幸的是,这并没有改变任何事情。

ana*_*cat 19

我在 lkml 上找到了这个线程,可以稍微回答你的问题。(似乎连 Linus 本人都对如何找出这些线程的起源感到困惑。)

基本上,有两种方法可以做到这一点:

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

为此,您需要在内核中编译ftrace,并使用以下命令启用它:

mount -t debugfs nodev /sys/kernel/debug
Run Code Online (Sandbox Code Playgroud)

ftrace.txt 文档中提供了有关 Linux 的函数跟踪器工具的更多信息。

这将输出线程都在做什么,并且对于跟踪多个小作业很有用。

cat /proc/THE_OFFENDING_KWORKER/stack
Run Code Online (Sandbox Code Playgroud)

这将输出做大量工作的单个线程的堆栈。它可以让您找出导致此特定线程占用 CPU 的原因(例如)。THE_OFFENDING_KWORKER是进程列表中 kworker 的 pid。


mai*_*ilq 5

解决办法是:不知道怎么找原因。至今没人告诉我。

但是与 BTRFS 开发人员交谈时发现 btrfs 驱动程序在很短的时间内编写许多小文件时存在一个错误。这是 3.0 到 3.1 内核的问题。也许它会在 3.2 中得到修复。

与此同时,我为当前内核获得了一个补丁,解决了这个问题。