本系列基于 Brendan Gregg《性能之巅：洞悉系统、企业与云计算》整理，结合笔者多年一线性能调优经验，以"故事场景+原理分析+实战命令"的三段式结构，将这本系统性能领域的经典著作拆解为可实践、可复用的技术手册。
第0章 写在前面：当系统变慢时，你在想什么？
一个真实的故障早晨
凌晨3点47分，运维工程师小林被电话惊醒。
"支付接口响应时间飙到15秒了！"监控系统的告警语音冰冷而急促。
小林打开笔记本，SSH登上服务器，手指在键盘上飞舞：
topCPU使用率60%，不高。再看内存，还有40%空闲。磁盘？iostat一看，I/O也不饱和。
"奇怪，资源都不高，为什么慢？"
他打开应用日志，满屏的timeout和connection refused。再查数据库，连接池满了。继续深挖——连接池满是因为某些查询执行了30秒。那些查询之所以慢，是因为表被锁了。表被锁是因为一个定时任务在做全表扫描……
两个小时后，问题定位了。代价是：12笔支付失败，用户投诉3起，小林被总监叫去喝茶。
这不是技术问题，这是方法论的问题。
性能问题的本质
性能分析最吊诡的地方在于：资源不高≠没有瓶颈，瓶颈消除≠问题消失。
graph TD
A[系统变慢] --> B{第一反应}
B -->|新手| C[重启试试]
B -->|熟手| D[看top]
B -->|专家| E[定义问题]
C --> F[可能好了
但不知道原因]
D --> G[CPU不高
然后呢？]
E --> H[响应时间?吞吐量?错误率?]
H --> I[建立假设]
I --> J[验证假设]
J --> K[定位根因]
style E fill:#e8f5e9
style K fill:#e1f5fe本书作者 Brendan Gregg 用一句话点破了本质：
"性能分析不是找到热点函数加以改写，而是通过对系统的总体把握与观测，精确定位软硬件性能瓶颈，设法化解并突破。"
本书面向谁？
mindmap root((性能之巅
读者群)) 运维工程师 系统调优 故障排查 容量规划 后端开发 代码优化 系统调用 内存管理 架构师 系统设计 性能建模 选型决策 技术管理者 团队赋能 建立规范 面试评估
如果你是：
- 遇到过"CPU不高但系统慢"的诡异现象
- 想知道火焰图怎么看、怎么生成
- 想掌握一套可复用的性能排查方法论
- 想了解BPF/eBPF这个当红炸子鸡
那么这本书，以及这个系列，就是为你准备的。
本书结构
本系列将原书16章重组为13章，每章围绕一个核心主题：
| 章节 | 主题 | 核心收获 |
|---|---|---|
| 第1章 | 绪论与方法论 | USE、RED方法，火焰图原理 |
| 第2章 | 操作系统基础 | 内核、中断、调度、虚拟内存 |
| 第3章 | CPU性能分析 | perf、火焰图、调度延迟 |
| 第4章 | 内存性能分析 | 页缓存、SWAP、内存泄漏 |
| 第5章 | 文件系统与磁盘 | ext4/XFS/ZFS、I/O栈、调度器 |
| 第6章 | 网络性能分析 | TCP/IP栈、拥塞控制、工具链 |
| 第7章 | 应用程序性能 | 编译优化、锁竞争、语言特性 |
| 第8章 | 云计算与虚拟化 | 容器、cgroup、云实例选型 |
| 第9章 | 基准测试 | 测试原则、陷阱、工具 |
| 第10章 | BPF动态追踪 | BCC、bpftrace、实战 |
| 第11章 | 综合实战 | Netflix案例、完整排查链路 |
| 附录 | 速查手册 | 工具命令、参数速查 |
如何使用本系列
第一遍通读：建立全局认知，理解性能分析的体系化思维。
第二遍精读：跟着命令敲，在自己的测试环境复现实验。
第三遍查阅：遇到问题先翻对应章节，用书中的方法论指导排查。
现在，让我们正式开始性能之巅的探索之旅。
"Don’t guess. Measure." —— 性能分析的第一原则，也是最后一原则。