确认内核workqueue是否真在干活，需检查kworker进程状态：ps -o pid,comm,state,pcpu -C kworker中state为R或D且pcpu>0.1的线程正在处理work；/sys/kernel/debug/workqueues/*/pending可查各队列积压数，但依赖debugfs挂载且非生产环境标配。
怎么确认内核 workqueue 是否真在干活
ps -ef | grep '\[kworker\]' 有输出，只说明内核加载了 workqueue 子系统，不等于它当前有任务在执行。真正判断“活跃度”，得看这些 kworker 进程有没有非空闲的调度状态。
-
ps -o pid,comm,state,pcpu -C kworker：列出所有kworker的 PID、命令名、状态（R= 运行中，S= 可中断睡眠，D= 不可中断——这往往意味着正在做关键内核操作）、CPU 占用 - 状态为
R或D且pcpu > 0.1的，才是当前正在处理 work 的线程；大量S状态是正常待命 - 注意：
kworker/0:1H中的H表示 high-priority 队列，这类 worker 更容易短时爆发式占用 CPU，但持续时间通常很短
/proc/sys/kernel/workqueue 目录能告诉你什么
这个目录从 Linux 5.10+ 开始暴露部分运行时统计，但默认不挂载——它不是标准 procfs 路径，而是通过 debugfs 挂载后才可见：- 先确认 debugfs 是否已挂载：
mount | grep debugfs；若无，执行sudo mount -t debugfs none /sys/kernel/debug - 然后看
ls /sys/kernel/debug/workqueues/：里面是每个 CPU 上注册的 workqueue 名称（如events、rcu_gp、pm） - 每个子目录下有
pool和pending文件：cat /sys/kernel/debug/workqueues/events/pending返回当前排队未执行的 work 数量（整数），为 0 表示该队列此刻空闲
⚠️ 注意：这个接口不稳定，不同内核版本字段含义可能变化；且 debugfs 属于调试设施，生产环境一般不启用，别指望它永远可用。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
为什么 top -H 看不到 kworker 线程
top -H 默认只显示用户态线程，而 kworker 是纯内核线程，不关联任何用户进程 PID，所以不会出现在 top -H -p $PID 结果里。
- 正确做法是直接查全局：
top -H后按P（大写）按 CPU% 排序，再手动识别以kworker开头的条目 - 或更可靠：
ps -eo pid,comm,wchan:20,state,pcpu --sort=-pcpu | grep kworker | head -10，其中wchan列显示线程当前等待的内核函数（如reschedule、schedule_timeout），能帮你判断它卡在哪一步
别把线程数当活跃度，尤其对 workqueue
ls /proc/2/task/ | wc -l（kthreadd PID 固定为 2）能列出所有内核线程总数，但其中绝大多数是长期休眠的 idle worker，和 Java 线程池那种“创建即存在”的模型完全不同。
- 内核 workqueue 动态伸缩：高负载时自动 spawn 新
kworker，空闲后会回收；所以数量波动大是常态 - 真正值得关注的是
/proc/interrupts中软中断（HI、TIMER、NET_RX等）的触发频率，以及cat /proc/stat | grep ^intr的总中断计数增长速度——workqueue 活跃度本质是软中断处理压力的下游反映
实际排查时，如果看到大量 kworker 占用 CPU，优先查 perf top -g -p $(pgrep -f 'kworker')，而不是数线程个数。
