Linux kworker 是内核工作线程，负责执行延迟任务或异步处理，正常情况下几乎不消耗 CPU，若占用过高则大概率指向硬件中断或驱动异常，必须从软中断和硬件层面排查。
linux kworker 是什么？它和普通进程有何不同
kworker 是 Linux 内核为 workqueue 机制创建的内核线程，专门用于处理那些不需要立即执行、可以稍后完成的任务，比如磁盘 I/O 完成后的回调、网络协议栈的延迟处理、设备驱动中的定时工作等，都会交给 kworker 来跑，你可以把它想象成内核内部的“打杂工”，哪里需要耗时但非紧急的活，就派它去。
kworker 与普通用户进程的本质区别
- 运行空间：普通进程运行在用户态，有独立的地址空间；kworker 运行在内核态，共享内核地址空间，没有独立的用户态上下文。
- 可管理性：普通进程可以用
kill、renice控制；kworker 是内核线程，无法被用户层杀掉，也不能轻易调整优先级。 - 数量与命名：kworker 按 CPU 编号命名，
kworker/0:0表示绑定在 CPU0 上的第 0 号工作线程，系统启动后会自动创建工作线程池，数量随 CPU 核数和负载动态调整。 - 调度方式：kworker 本身是被内核调度器管理的，但它内部的任务通过 workqueue 调度，当 workqueue 为空时，kworker 会休眠，不占用 CPU。
实际场景：什么时候会看到 kworker 活跃？
在运维过程中,你可能会在 top 或 htop 里看到多个 kworker 进程，大多数情况下它们处于 S 状态（睡眠），偶尔转为 R 状态（运行）并只占用极少量 CPU，如果某个 kworker 持续占用超过 10% 甚至更高，说明它正在反复执行某个耗时任务，这通常是出问题的信号。
kworker 占用 CPU 高怎么办？从排查到解决
当服务器响应变慢,执行 top 发现某个 kworker 进程 CPU 占用率飙高，很多运维人员会感到困惑一个“内核线程”怎么会这么吃资源？
kworker 高占用几乎从不是它自身的问题，而是驱动、硬件中断或内核模块触发了异常频发的回调。
第一步：定位具体是哪个 kworker 在忙
使用 top 命令，按 1 查看每个 CPU 的负载，然后按 c 显示完整命令行，记下占用最高的 kworker 名称，kworker/1:2+events，后面的 +events 表示它属于 events workqueue，不同 workqueue 类型对应的任务范围不同，events 是最通用的，events_power_efficient 注重节能，events_freezable 可随系统休眠冻结。
第二步：查看软中断和硬中断分布
kworker 的负载通常与中断处理相关，运行以下命令检查软中断统计：
cat /proc/softirqs
关注 NET_RX、NET_TX、BLOCK、IRQ_POLL 等字段，如果某个 CPU 上的软中断计数远高于其他 CPU，说明该核心承担了大量中断处理，而 kworker 正是被这些软中断触发的任务唤醒的。
硬中断也可以通过 cat /proc/interrupts 查看，多数情况下，网络设备（尤其是多队列网卡）和 NVMe 固态硬盘是导致中断不均衡的常见原因。
第三步：检查驱动与硬件
- 网卡驱动：使用
ethtool -S eth0查看丢包或错误计数，运行ethtool -l eth0检查是否开启了多队列（RSS），如果所有中断都挤在同一个 CPU 上，尝试调整网卡中断亲和性：echo 1 > /proc/irq/43/smp_affinity（数字 43 替换为实际中断号）。 - NVMe 硬盘：查看
nvme list和dmesg | grep nvme，如果出现大量nvme相关的错误或重试，kworker 会被反复唤醒处理 I/O 重试，更新固件或调整 I/O 调度器（如echo none > /sys/block/nvme0n1/queue/scheduler
）有时能缓解。
- USB 设备：外接 USB 设备（如 U 盘、读卡器）的异常插拔或驱动 bug 会导致 kworker 反复尝试复位，断开所有 USB 设备看 CPU 是否下降，即可定位。
第四步：使用 ftrace 或 perf 追踪具体任务
如果以上方法无法定位,可以使用内核的追踪工具抓取 kworker 执行的函数：
perf top -p <kworker_pid>
或者用 trace-cmd 记录 workqueue:workqueue_execute_start 事件，业内专家指出，在复杂场景下，通过 perf script 分析堆栈，能直接看到是哪个驱动模块的回调函数占用了大量时间。
常见解决方案汇总
- 更新内核和驱动：多数厂商会在新版本中修复已知的 workqueue 死循环问题。
- 调整中断亲和性：将高负载中断分散到多个 CPU，避免单核 kworker 过载。
- 禁用不必要的硬件：如板载声卡、读卡器等，在 BIOS 中关闭或通过内核模块黑名单禁用。
- 使用
irqbalance服务：自动平衡中断分配，但注意它可能无法 fine-tune，需要配合手动调整。
kworker 与内核线程到底有什么区别？对比分析
很多人把 kworker、ksoftirqd、kthreadd 混为一谈，其实它们分工明确：
| 线程类型 | 职责 | 触发方式 | 对 CPU 的影响 |
|---|---|---|---|
| kworker | 执行 workqueue 任务 | 其他内核模块提交 work | 正常时极低，异常时持续高占用 |
| ksoftirqd | 处理软中断 | 硬中断后半部 | 网络/存储负载高时占用升高 |
| kthreadd | 创建和管理内核线程 | 系统调用或内核启动 | 几乎不占 CPU |
| migration | 进程迁移 | 负载均衡 | 仅在 CPU 热插拔时短暂出现 |
行业共识认为：kworker 负责的是“软中断之后”的延迟工作，而 ksoftirqd 直接处理软中断本身。ksoftirqd 占用高，说明网络或存储中断已经密集到无法在中断上下文处理完，必须唤醒专属线程；kworker 占用高，说明 workqueue 里堆积了太多回调，通常是驱动或硬件异常。
linux kworker 常见问题解答
kworker 可以关闭或禁止吗？
不可以。 kworker 是内核运行的必要组件，强行关闭会导致系统无法处理延迟任务，引发驱动超时、I/O 挂起甚至内核崩溃，如果你在某个特定场景下认为 kworker 是问题根源，正确的做法是定位哪个模块反复提交 work，然后禁用或更新该模块，而非直接杀掉 kworker 进程。
kworker 占用 CPU 高是否一定是硬件故障？
不一定是，但硬件故障是首要排查方向。 据统计，相当一部分 kworker 高占用案例最终指向网卡或硬盘驱动兼容性问题，其次是内核 bug，少数情况下，文件系统层（如 btrfs 的清理任务）也会导致 kworker 频繁运行，建议先更新驱动和内核，如果问题依旧，再考虑硬件替换。
如何查看 kworker 背后到底是哪个驱动在搞鬼？
通过 /proc/ 系统无法直接反查，但可以用 perf 或 trace-cmd 抓取函数调用，最简单的方法是：查看 cat /proc/sched_debug | grep kworker 并结合 echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event 开启追踪，然后观察 cat /sys/kernel/debug/tracing/trace_pipe 输出，其中会记录提交 work 的内核函数名称，从而定位到对应的驱动模块。
排查 kworker 问题时，优先关注硬件中断的均衡性，因为这是最容易被验证的步骤，理解 kworker 的运行机制，能帮你快速区分“内核正常工作”与“异常报警”，从而避免在无关的进程上浪费精力。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/linux-kworker%e5%8d%a0%e7%94%a8%e9%ab%98%e6%80%8e%e4%b9%88%e5%8a%9e-%e6%98%af%e4%bb%80%e4%b9%88%e5%8e%9f%e5%9b%a0/
