成为Linux性能专家需构建系统级认知框架，涵盖硬件资源、内核机制与应用建模；通过问题驱动的纵深阅读、原理反推、分层可观测性及真实场景攻坚，夯实内核与硬件协同基础。
想成为 Linux 性能专家，不能只靠零散的命令和经验堆砌。核心是建立系统级认知框架——从硬件资源（CPU、内存、磁盘、网络）到底层内核机制（调度、内存管理、I/O 栈、中断、cgroup），再到应用行为建模与可观测性闭环。进阶路径的关键，在于“问题驱动下的纵深阅读”和“工具链背后的原理反推”。
夯实内核与硬件协同基础
跳过原理直接调优，容易陷入“改参数—看指标—再改”的低效循环。必须理解性能现象背后的执行路径：
- 用 perf record -e cycles,instructions,cache-misses 采集一段高延迟请求，再通过 perf script 结合源码或符号表，定位是否卡在 TLB miss、分支预测失败或锁竞争
- 读 《Linux Performance》（Brendan Gregg）第 3–5 章 + 《Understanding the Linux Kernel》（ULK）对应章节，重点画出 page fault 处理流程图、CFS 调度器中 vruntime 更新与红黑树插入逻辑
- 在虚拟机中故意关闭 KVM 的 speculative store bypass mitigation，用 sysbench cpu 对比性能变化，再查 /sys/devices/system/cpu/vulnerabilities/ 验证缓解状态，理解微架构漏洞如何真实影响吞吐
构建分层可观测性工作流
不是工具越多越好，而是让每个工具回答明确的问题：
- 第一层（宏观瓶颈）：用 mpstat -P ALL 1 看 CPU 各核 busy/idle 分布，结合 pidstat -u -t 1 观察线程级调度延迟，识别是否为调度抖动或 NUMA 不均衡
- 第二层（资源争用）：用 slabtop 查 slab 内存碎片，配合 /proc/buddyinfo 判断是否因大页分配失败频繁触发 direct reclaim；用 biotop（bpftrace 版）看进程 I/O size 与 latency 分布，区分随机小 IO 还是顺序大块写瓶颈
- 第三层（应用语义）：用 bpftrace -e 'uprobe:/path/to/app:func_name { printf("called by %s\n", comm); }' 注入轻量探针，验证业务逻辑中是否存在意外的同步阻塞路径
深入容器与云原生场景调优
现代生产环境几乎离不开 cgroup v2 + systemd + 容器运行时组合，性能问题常跨多层抽象：
- 用 systemd-analyze plot > boot.svg 分析启动阶段各 service/cgroup 初始化耗时，识别 init 容器中 systemd 服务依赖导致的冷启动延迟
- 在 Kubernetes 中部署 stress-ng --vm 2 --vm-bytes 1G --timeout 60s，同时监控 cgroup v2 memory.current / memory.stat 和 /sys/fs/cgroup/kubepods.slice/memory.events，观察 oom_kill 与 high threshold 触发的先后关系
- 对比 runc 与 gVisor 运行相同 Java 应用时的 perf sched latency 输出，理解不同运行时对系统调用拦截带来的调度延迟差异
参与真实复杂问题攻坚
脱离生产压力的练习难以建立直觉。建议主动接触以下类型问题：
- 数据库慢查询伴随 pg_stat_activity.wait_event_type = 'Lock'，但 pg_locks 显示无长持锁 —— 往下查 /proc/PID/stack 是否卡在 futex_wait_queue_me，再确认是否因 glibc 版本导致 pthread_mutex 在 contended 场景退化为休眠锁
- HTTP 接口 P99 延迟突增 200ms，tcpdump 显示重传集中在特定端口段 —— 结合 ss -i 查 sk->sk_pacing_rate 是否被 cgroup net_prio 或 fq 混合限速策略压制
- CI 构建任务在某台宿主机上 consistently timeout，dmesg -T | grep -i "out of memory" 无记录，但 cat /sys/fs/cgroup/memory.events 显示频繁 oom_kill —— 实际是 memory.low 设置过低，触发内核积极 reclaim 导致文件缓存剧烈抖动，影响编译中间文件读取
不复杂但容易忽略：每次解决一个问题后，把复现步骤、关键指标截图、内核日志片段、最终 root cause 和修复动作整理成一页 Markdown，半年积累 20+ 个这样的案例，就自然形成了你自己的性能决策树。
