4. 性能瓶颈分析：上下文切换开销、锁竞争、内存拷贝、中断风暴
性能调优这件事，说白了就是找短板。协议栈跑不快，往往不是CPU不够强，而是资源都耗在了看不见的地方。我这些年排查过不少性能问题，十有八九都绕不开这四个坑：上下文切换、锁竞争、内存拷贝、中断风暴。今天咱们就把它们一个个拆开看。
4.1 上下文切换开销
上下文切换，就是CPU从干一件事切换到干另一件事。每次切换都要保存寄存器、刷新TLB、重新加载上下文。你想想看，一次切换大概几微秒，看起来不多，但要是每秒切换几万次呢？
我在项目中遇到过一台机器，CPU利用率只有30%，但吞吐死活上不去。一查/proc/stat，每秒上下文切换高达15万次。说白了，CPU都在忙着“换衣服”，根本没时间干活。
4.1.1 上下文切换的代价
| 切换类型 | 典型开销 | 主要影响 |
|---|---|---|
| 系统调用（用户态↔内核态） | ~0.5-2 µs | 频繁系统调用累积延迟 |
| 线程切换（同一进程） | ~1-5 µs | TLB失效，缓存污染 |
| 进程切换（不同进程） | ~3-10 µs | 地址空间切换，缓存完全失效 |
4.1.2 如何定位上下文切换问题
我习惯用 perf sched 和 vmstat 来抓现场。具体步骤很简单：
- 看全局指标：
vmstat 1观察cs（context switch）列，如果持续超过5万次/秒，就要警惕了。 - 抓热点线程：
perf sched record -- sleep 10采集调度事件，然后用perf sched map看哪个线程频繁被切换。 - 分析原因： 是锁竞争导致的？还是线程数太多？还是中断太频繁？
4.2 锁竞争
锁这个东西，用好了是保护，用不好就是性能杀手。多核环境下，锁竞争会导致线程排队等待，CPU空转。更可怕的是，锁竞争还会引发上下文切换——线程拿不到锁，被挂起，换另一个线程上来，来回折腾。
我曾经调试过一个网关项目，16核CPU，吞吐只有预期的30%。用 perf top 一看，热点函数里有个 spin_lock 占了40%的CPU时间。嗯，这就是典型的锁竞争。
4.2.1 常见锁竞争场景
- 全局锁： 比如一个全局的socket哈希表，所有线程都去抢这把锁。
- 共享数据结构： 多个线程同时操作同一个队列、链表或计数器。
- 内核协议栈锁： 比如inet socket锁、路由表锁，在高并发下很容易成为瓶颈。
4.2.2 锁竞争排查方法
我常用的三板斧：
- perf lock：
perf lock record -- sleep 5然后perf lock report，直接告诉你哪把锁争抢最激烈。 - 火焰图： 用
perf record -g生成火焰图，看哪些函数调用链上锁等待占比高。 - 代码审查： 检查锁的粒度是否过大，能不能用读写锁、RCU或者无锁数据结构替代。
4.3 内存拷贝
内存拷贝是协议栈里最容易被忽视的性能杀手。一个数据包从网卡到应用，可能要经历好几次拷贝：DMA到内核缓冲区、协议处理时拷贝、从内核拷贝到用户态、应用内部再拷贝。每次拷贝都占用内存带宽和CPU缓存。
我记得有一次优化一个视频流服务，发现CPU的L2缓存缺失率特别高。一查，原来是每次收包都做了两次不必要的memcpy。去掉之后，吞吐直接翻倍。
4.3.1 协议栈中的拷贝路径
| 阶段 | 拷贝类型 | 优化方向 |
|---|---|---|
| 网卡→内核 | DMA（硬件拷贝） | 启用TSO/GRO减少DMA次数 |
| 内核协议处理 | skb数据拷贝 | 使用零拷贝技术（如sendfile） |
| 内核→用户态 | read/write系统调用拷贝 | mmap、io_uring、DPDK |
| 应用内部 | 业务逻辑拷贝 | 使用零拷贝API，避免不必要的拼接 |
4.3.2 如何发现内存拷贝问题
我一般用 perf stat -e cache-misses 看缓存缺失率，如果超过10%，就要怀疑是不是拷贝太多了。更直接的办法是用 strace -c 统计系统调用次数，如果 read/write 调用次数和包数量差不多，说明没有做批处理，每次都在拷贝。
sendfile 或 splice 替代 read + write。这两个系统调用可以在内核态直接完成数据搬运，省掉一次用户态拷贝。
4.4 中断风暴
中断是网卡通知CPU“有数据来了”的方式。但如果中断来得太频繁，CPU就会一直被中断打断，没法专心处理业务。这就是中断风暴。
我遇到过最夸张的一次，一个千兆网卡跑满速，每秒产生超过10万次中断。CPU的 softirq 占用率高达80%，业务处理几乎停滞。嗯，这就是典型的中断风暴。
4.4.1 中断风暴的成因
- 单队列网卡： 所有中断都打到同一个CPU上，导致该CPU过载。
- 中断合并关闭： 每个包都触发一次中断，没有做合并。
- NAPI配置不当： 轮询权重太低，导致频繁在中断和轮询之间切换。
4.4.2 中断风暴的解决方案
- 启用RSS（Receive Side Scaling）： 把中断分散到多个CPU上，避免单核过载。
- 调整中断合并参数： 通过ethtool设置
rx-usecs和rx-frames，让网卡攒一批包再发中断。 - 使用NAPI轮询： 高吞吐场景下，轮询比中断更高效。调整
net.core.netdev_budget和net.core.netdev_budget_usecs。 - 绑定中断到特定CPU： 用
irqbalance或手动设置/proc/irq/亲和性。
4.5 四大瓶颈的关系与排查思路
这四个瓶颈不是孤立的，它们经常互相影响。比如锁竞争导致上下文切换，上下文切换又导致缓存污染，缓存污染又让内存拷贝更慢。所以排查的时候，不能只看一个指标。
我个人的排查顺序是这样的：
- 先看CPU利用率分布： 用
top或htop看si（软中断）和us（用户态）占比。如果si超过20%，优先排查中断风暴。 - 再看上下文切换：
vmstat 1看cs列，如果过高，用perf sched定位原因。 - 然后看锁竞争：
perf lock或火焰图，找到热点锁。 - 最后看内存拷贝： 用
perf stat和strace确认拷贝次数和缓存缺失率。