perf热点找到热进程3
很好，这个 perf report 其实已经把关键信息暴露出来了，只是你现在卡在“不会读结构”。
我帮你直接把这一段翻译成结论 + 定位 vector/系统真实负载结构。
✔ 一、先读这一列（非常关键）
你看到的是：
Children / Self / Pid:Command / Command
✔ 这四列的真实含义
| 列 | 含义 |
|---|---|
| Self | 该函数本身消耗 CPU |
| Children | 调用链下游 CPU |
| Pid:Command | 进程 ID + 名字 |
| Command | 线程/进程名 |
✔ 二、你这个输出的核心结论（重点）
我直接帮你翻译：
✔ 1）swapper 占 12.6%
0:swapper → 12.63%
👉 这个非常关键：
❗ CPU 有 12% 在 idle / 调度 / 轻负载切换
✔ 2）haproxy + tokio runtime 是“分散型 CPU”
你这里：
haproxy ~0.4% * 多线程
tokio-runtime-w ~0.35~0.40% * 多线程
👉 结论：
✔ 没有单一热点进程
✔ 是“很多线程轻度占用 CPU”
✔ 三、最关键判断（你这个场景本质）
❗ 不是 CPU 被某个函数打爆
而是：
✔ 多进程 + 多线程 + runtime 驱动型负载
✔ 四、你的系统状态拆解
结合你之前 top：
-
vector 很重（你之前贴过）
-
现在 perf report 看到：
-
tokio-runtime-w
-
haproxy
-
swapper
-
✔ 结构是：
vector（重计算）↓
tokio runtime（调度层）↓
haproxy（网络层）↓
kernel/scheduler（swapper）
✔ 五、关键结论（重点来了）
✔ 1）没有单一 CPU 热点
如果是 encode / memcpy，你会看到：
vector::encode
memcpy
json::serialize
👉 但你这里：
❌ 没有任何函数占比突出
✔ 2）CPU 被“打散”
你看到的是：
| 现象 | 含义 |
|---|---|
| tokio-runtime-w 多个进程 | 线程池调度 |
| haproxy 多实例 | 网络负载分散 |
| 每个 <0.5% | 无单点热点 |
✔ 3）swapper 有 12%
👉 这个非常关键：
CPU 在“切换/调度”，不是在算
✔ 六、现在可以下结论（很重要）
✔ 你这个系统不是：
❌ encode bottleneck
❌ memcpy bottleneck
✔ 而是：
✔ 调度型负载 + 多 runtime 并行碎片化 CPU
✔ 七、为什么你感觉 load 77，但 perf 看起来“没热点”
这是经典现象：
| 指标 | 解释 |
|---|---|
| load 高 | runnable + 调度压力 |
| perf 没热点 | CPU被拆成很多小片 |
| tokio/haproxy | 任务碎片化 |
✔ 八、真正问题类型（核心）
你现在属于：
✔ “分布式 CPU 消耗型负载”
特征：
-
多进程
-
多线程 runtime（tokio）
-
单线程占比极低
-
swapper/调度占比上升
✔ 九、下一步应该怎么看（关键建议）
你现在不能再看：
❌ perf top
应该看：
✔ 1）调度压力（最关键）
perf sched record -- sleep 10
perf sched latency
👉 看线程是不是：
-
排队严重
-
context switch 过多
✔ 2）context switch
vmstat 1
看：
-
cs 是否爆炸
✔ 3）线程竞争
pidstat -w 1
✔ 十、一句话总结（非常关键）
你现在不是 CPU “算不过来”，
而是 CPU 在“被大量 tokio / haproxy / vector 任务切碎调度”。
✔ 如果你下一步要继续（建议）
你这个已经到高级诊断阶段了，可以继续：
👉 “帮你从 perf sched + context switch 判断 tokio runtime 是否线程池过度导致 CPU 77 load 的根因”