用证据链代替单指标判断

性能分析方法论的重点是把“系统很慢”转换成可以验证的假设。一次完整排查至少要记录发生时间、受影响的接口🎵或进程、正常基线、异常指标和已经排除的方向。

内存问题需要区分可用内存下降、页缓存增长、匿名内存过大、频繁回收和交换分区活动。free 适合查看总体状态，vmstat 可以观察换页、运行队列和阻塞情况，/proc/meminfo 能提供更细的内存分类。

按基础选择观看与练习重点

磁盘利用率接近百分之百并不自动等于吞吐达到上限，关键还要看读💫写延迟、💎请求大小、队列深度和读写比例。iostat 适合查看设备层指标，pidstat -d 可以追踪进程的读写活动，df 和 du 用于区分文件系统容量与目录占用。

客户端超时不一定表示服务端 CP💎U 忙。连接数耗尽、连接池配置过小、NAT ⚡端口不足、丢包重传、下游服务变慢和负载均衡排队，都可能把延迟传递给上层接口。

性能学习中的常见误区，通常来自把工具输出直接当成结论。下面五种情况会让排障方向迅速偏离。

CPU 排查看利用率构成

数据库或日志服务出现写入变慢时，应继续检🎆查同步写、文件系统挂载参数⭐、磁盘阵列缓存和后台任务。清理文件、调整缓存或更换调度器都属于有风险的动作，必须先保存基线并确认回滚方式。

不要把视频编号当成排障顺序

例如接口延迟上升时，先确认应用请求量是否变化，再观察进程 CPU、运行队列、内存回收、磁盘等待和网络重传。多个时间点能够同时对齐，结论才比单次截图更可靠。

网络延迟应拆📚分为 DNS、连接建立、TLS、服务端处理、数据传输和客户端读取等阶段。ss 可以观察连接状态和队列，sa🎆r 或 ip 可以查看网卡流量与错误，tcpdump 适合在需要确认握手、重传和窗口变化时取证。

不同基础的学习者不需要以相同速度完成全部内容，重点应根据当前排障职责调整。只做应用开发的人，应先掌握延迟分解和进程资源；负责主机运维的人，应增加内核、IO 和网络观测；负责平台稳定性的人，还需要练习跨主机、容器和下游服务的关联分析。