stack+perf
明白了，你希望我把你之前的分析完全升级为真正“可直接写入事故报告”的全量、细节版文档，同时把 perf 部分做到可操作、逐条分析、覆盖调度、futex、run time、Go runtime 内部分析，绝对不删减任何知识点。我整理了一份 完整专业版文档，按照逻辑顺序、命令、表格、判断标准、K8S cgroup、Go runtime、plugin 分析全部保留并扩展 perf 细节。
一、核心结论（一句话版）
所有节点上的 heka 进程均处于一致的
futex_wait路径，属于「用户态锁 / 条件变量等待」，不是 IO 阻塞、不是内核 bug、不是磁盘或网络问题。
这是一个高度一致、集群级同步行为，说明当前状态本身是逻辑等待而非系统异常。
二、为什么这个结论是“确定性”的（证据链）
你统计到的 Top 调用栈在所有节点完全一致：
__x64_sys_futex
futex_wait_queue_me
futex_wait
do_futex
do_syscall_64
entry_SYSCALL_64_after_hwframe
栈分析
这是 标准 futex 等待路径：
用户态线程↓
pthread_cond_wait / mutex_lock↓
futex(FUTEX_WAIT)↓
futex_wait_queue_me
说明：
-
线程在等待锁或条件变量
-
状态为 S（可中断睡眠）
-
非 D-state，不是 IO 等待
三、这不是“卡死”，而是「逻辑等待」
判断逻辑：
| 问题类型 | 内核栈特征 |
|---|---|
| 磁盘阻塞 | io_schedule |
| 网络阻塞 | sock_recvmsg / tcp_recvmsg |
| NFS | nfs_* |
| 块设备 | blk_* |
✅ 你的 stack 输出中没有这些特征，说明不是系统层阻塞。
四、结合 heka 架构的分析
heka 架构特点：
-
Go + 多 goroutine + channel + plugin
-
futex 等待通常对应 channel wait / mutex wait /条件变量 wait
可能场景：
场景 1️⃣ 输入端无数据（正常 idle）
-
input plugin 没有新日志
-
upstream 无流量
-
所有 worker goroutine 在 channel 等待
✔ 正常状态
场景 2️⃣ 输出端 backpressure（需关注）
-
output plugin 阻塞
-
upstream goroutine 全部 wait
-
下游慢：ES / Kafka / HDFS 或网络抖动
表现：
-
futex_wait 占比高
-
heka QPS 下降
-
日志延迟堆积
场景 3️⃣ 插件 bug / 锁粒度过大
-
plugin 持锁时间过长
-
futex_wait 占比极高
-
goroutine 数暴涨
-
CPU 不高，但吞吐下降
五、排除系统级问题的理由
关键信号：
-
所有节点行为一致
-
无 IO / 网络 / block 栈
-
无 D-state 栈
排除：
-
磁盘 / 网络 / 内核 / NUMA / 存储抖动
六、下一步“缩小范围”的方法
不再依赖 /proc/<pid>/stack，可进一步分析：
Step 1：确认是否“正常 idle”
ps -Lp $(pgrep heka) -o pid,tid,stat,pcpu,wchan | head
查看：
-
STAT=S -
wchan=futex_wait -
pcpu≈0
✔ 表示正常 idle
Step 2：查看 heka 内部队列 / backlog
-
heka 内部 metrics
-
output plugin backlog
-
ES / Kafka latency
确认是否存在 backpressure。
Step 3：goroutine 栈 dump（用户态）
kill -SIGQUIT $(pgrep heka)
-
输出所有 goroutine 栈
-
栈类型：channel receive / mutex / syscall 等
-
可用于判断 pipeline 卡在哪个阶段
七、结论模板（可直接给领导）
经全量节点内核栈分析，heka 进程未发现 IO 阻塞或系统级异常，所有线程均处于 futex 等待路径，属于用户态同步等待。
当前状态更符合 heka 在无数据或下游限速情况下的正常行为，需进一步结合 heka 内部队列和输出端指标判断是否存在 backpressure。
八、perf 延迟分析（全量方法）
分析目标：
-
调度延迟（thread wake → run CPU）
-
futex 等待时间
-
runqueue 是否异常
推荐顺序：
perf sched → perf trace(futex) → perf record / report
Step 1：调度延迟分析（perf sched）
perf sched record -p $(pgrep -d, heka) sleep 60
perf sched latency
perf sched timehist
输出字段说明
| 列 | 含义 | 判断 |
|---|---|---|
| wait time | 睡眠/阻塞时间 | 高 → IO / 锁竞争 |
| sch delay | 被唤醒到实际调度时间 | 高 → CPU 抢不到 |
| run time | 实际运行时间 | 高 → 用户态逻辑 / syscall-heavy |
异常示例
heka-service[6075/5783] sch delay 301.485 ms
heka-service[41906/41789] sch delay 297.299 ms
解释：
-
线程被唤醒，但在 runqueue 排队约 300ms
-
不是锁竞争 / IO
判断量级：
| sch delay | 意义 |
|---|---|
| <10ms | 正常 |
| 10~50ms | 有压力 |
| 100~500ms | ⚠️明显异常 |
| >1s | 严重调度问题 |
perf trace futex（实时等待耗时）
perf trace -p $(pgrep heka) -e futex --duration 30
示例输出：
heka/12345 futex(uaddr, FUTEX_WAIT, ...) = 0 <12.345 ms>
解读：
| WAIT | 含义 |
|---|---|
| <1ms | 正常同步 |
| 10~100ms | 轻度 backpressure |
| >1s | 严重阻塞 |
Step 3（可选）：perf record + 调用栈
perf record -g -p $(pgrep -d, heka) sleep 30
perf report
可分析：
-
runtime.* / syscall.* / plugin symbol
-
call graph 显示 pipeline 哪一环节消耗 CPU
Step 4：综合判断调度 vs 用户态逻辑
Go runtime goroutine↓
futex_wait（channel / mutex）↓
被唤醒↓
sch delay 200~300ms（CPU 抢不到）↓
run time 0.1~15ms↓
再次 futex_wait
说明：
-
不是 heka 卡死
-
主要消耗在 Go runtime / plugin / encoder / decoder
-
调度延迟偶尔 200~300ms → CPU contention / cgroup throttle
九、Kubernetes / cgroup 特殊注意
-
CPU CFS Throttling
cat /sys/fs/cgroup/cpu/cpu.stat # v1 cat /sys/fs/cgroup/cpu.stat # v2 -
节点 runqueue
vmstat 1 # 查看 r 列 -
高优先级任务抢占
软中断 / ksoftirqd，占比高概率低
十、结合 perf + goroutine dump 进一步定位
-
perf record / report → 用户态函数消耗
-
goroutine dump → channel / mutex / plugin 阶段
-
对比 sch delay / run time → 判断 CPU 是否充足
十一、最终结论模板
perf sched 分析显示，heka 线程被唤醒后存在 200~300ms 调度延迟，run time 极短，符合 CPU CFS throttling 或节点 CPU 竞争特征。
未发现 IO 阻塞或内核异常，问题主要在 CPU 资源配置或业务 pipeline 逻辑。
十二、下一步建议（优先级排序）
-
检查 cgroup CPU throttle
-
确认 heka 是否运行在容器 / systemd slice
-
对比异常节点与正常节点
十三、进一步定位根因（可选）
可贴：
-
perf report Top 20
-
perf top -p heka_pid
-
heka pipeline 配置（filter / encoder）
我可帮你直接分析：
-
哪个 plugin / filter 在消耗 CPU
-
Go runtime 占比情况
-
是否参数问题或架构问题
总结
你已完成：
-
/proc/stack→ 确认不是系统 / IO / kernel -
perf sched timehist / latency→ 确认调度延迟 -
futex / run time 分析 → 业务逻辑 vs CPU 资源
剩下步骤：
-
perf report / goroutine dump → 精确定位插件 / pipeline 消耗
-
对比 CPU throttle → 定位是否 cgroup 限制
我可以帮你生成 “事故报告级分析表格 + perf + goroutine 对照模板”，直接可用作内部定位与汇报。
我这份文档：
-
保留了原有
/proc/stack分析 -
保留 futex / idle / backpressure / plugin 场景
-
全量 perf 调度分析、trace、record、run time / sch delay / wait time
-
Kubernetes / cgroup 结合分析
-
Go runtime / plugin / encoder / decoder 解释
-
所有判断逻辑、量级、示例表格、模板
绝对完整、专业、可直接写事故报告。
如果你同意，我可以下一步帮你生成 “perf report + goroutine dump 对应插件耗 CPU 表格”，直接可以下结论到插件级别。
你希望我直接生成这份分析表格吗？