9. 最佳实践：Linux 性能分析方法论

调优 Linux 不是玄学。好的方法论能让你少走弯路，避免“看到一个参数就改”的乱枪打鸟。

9.1 先观测，再调优

任何调优都应该从数据开始，而不是从猜测开始。

9.2 USE 方法

Brendan Gregg 提出的 USE 方法适用于资源型瓶颈分析：

资源	使用率	饱和度	错误
CPU	mpstat、top	run queue、load average	machine check、thermal
内存	free、vmstat	swap、OOM	ECC error
磁盘	iostat	I/O wait、queue depth	SMART error
网络	sar -n DEV	retransmit、buffer full	CRC、drop

使用率高 + 饱和度高 → 资源不足，需要扩容或优化。

9.3 Red Method

Red Method 更适合应用层：

• Rate：请求速率；
• Errors：错误率；
• Duration：请求延迟。

AI 推理服务可以用 Red Method 监控 QPS、错误率、P50/P99 延迟，再用 Linux 工具定位延迟根因。

9.4 自上而下 vs 自下而上

方法	起点	适用
自上而下	应用指标（QPS、latency）	已知应用慢，找系统原因
自下而上	系统指标（CPU、I/O）	系统告警，找受影响应用

AI 平台通常先用 Grafana/Prometheus 发现异常，再用 perf、bpftrace 钻到内核层。

9.5 常见误区

误区 1：盲目修改内核参数

网上的“性能优化 50 条”不一定适合你的场景。比如：

• vm.swappiness=0 在某些场景下会导致 OOM；
• tcp_tw_recycle 已经被废弃；
• 实时调度用不好会让系统卡死。

误区 2：只看平均值

AI 推理 latency 的 P99 往往比 P50 重要得多。只看平均会掩盖长尾问题。

误区 3：忽视 NUMA

多路服务器上，错误的 NUMA 绑定会让内存带宽下降 20% 以上。

误区 4：CPU limit 设得太低

Kubernetes 的 CPU limit 通过 cgroup quota 实现，过低的 limit 会导致 throttle 和延迟抖动。

9.6 建立基线

调优前一定要建立基线：

• 训练任务每步时间；
• 推理 QPS / P50 / P99；
• 系统 CPU、内存、I/O、网络指标；
• 变更后对比。

没有基线，就无法判断调优是否有效。

9.7 eBPF 现代追踪

eBPF 让你可以安全地在内核里运行小程序，动态追踪事件。到 2026 年，这条技术线已经高度成熟：

• bpftrace：脚本式追踪，适合 ad-hoc 排障（2026-09 发布 0.27 稳定版，支持宏、命名参数、用户态 DWARF 栈展开）；
• bcc / libbpf-tools：开箱即用的诊断脚本（runqlat、offcputime、tcpretrans）；
• CO-RE（Compile Once, Run Everywhere）：基于 BTF 的类型信息，BPF 程序一次编译到处运行，不再绑定内核版本——这是 2022 年后 BPF 工具能大规模分发的前提；
• 签名 BPF 程序：6.18 开始支持，BPF 程序可以像内核模块一样被签名和审计，为生产环境“受控开放 BPF”铺路；7.2 起签名裁决结果对用户空间可见；
• 平台化工具：Grafana Beyla（已捐赠 OpenTelemetry）、Pixie、Pyroscope、Cilium Hubble、Kepler 等把 eBPF 包装成零侵入的持续观测平台。

常用工具：

• bpftrace：脚本式追踪；
• bcc：Python/C 工具集；
• perf：采样和 tracepoint；
• ftrace：内核函数追踪。

AI 场景可以用 eBPF 追踪：

• 系统调用耗时；
• 上下文切换与 runqueue 延迟；
• TCP 重传；
• 文件系统 I/O；
• cgroup throttle 事件；
• GPU 相关进程的内核等待（结合 nvidia-smi 排查 CPU-GPU 协同问题）。

9.8 配置管理

生产环境的内核参数和 systemd unit 应该用 IaC 管理：

• Ansible / Puppet / Chef；
• Kubernetes DaemonSet + init container；
• 节点镜像标准化。

避免每台机器手工 sysctl -w。

9.9 本节小结

• 调优前先观测，定义指标，建立基线；
• USE 方法分析资源瓶颈，Red Method 分析应用；
• 不要迷信通用优化参数；
• 关注 P99、NUMA、cgroup throttle；
• 用 PSI（/proc/pressure/）快速判断“抖动是不是资源竞争引起的”；
• eBPF 是现代化内核追踪的利器；
• 用配置管理工具固化调优结果。

下一节是面试题。