存储排查不要只看磁盘利用率

性能证据链应同时覆盖应用层、进程层、操作系统层和硬件或虚拟化层。监控图表负责发现异常，系统工具负责定位资源，日志和追踪负责说明请求经过了哪些环节。

实验记录应保留采🔥集时间和压力参数。没有时间范围的指标很难与业务日🌅志对齐，没有压力参数的测试结果也很难复现。

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

先确认性能之巅1-4的编号范围

性能问题可以从延迟、吞吐量、错误率和资源💫饱和度四个角度描述。延迟反映单次请求耗时，吞吐量反映单位时间处理量，错误率反映请求质量，饱和度反📌映资源是否排队等待。

CPU 使用率升高时，应先😎查看 user、system、iowait、steal 和 idle 等🔮构成，再结合运行队列判断是否真的出现计算饱和。多核机器上，整体利用率不高并不代表没有瓶颈，单个核心被打满、线程无法并行或锁竞争都可能造成响应变慢。

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

看完视频后，用一台 Linux 虚拟机完成四个实验

查找性能之巅1-4时，最有效的学习方式不是从头到尾被动播放，而是先确认编号对应的内容，再按照“性能方法论—CPU与内存—存储与文件系统—网络与综合排障”的顺序观看。每看完一部分，都应在 Linu🎯x 实验环境中验证一个现象，否则很容易只记住工具名称，却不会判断真正的瓶颈。

容器环境还要检查容器限制、工作集增长和内存 cgroup 事件。宿主机仍有空闲内存，不代表容器没有达到上限；容器被 OOM Kill 时，应用日志、内核日志和限制配置需要一起核对。

文件系统、磁盘和网络问题都可能表现为“应用响应慢”，但三者的证据不同。磁盘问题通常体现为设备延迟和队列增长，文件系统问题可能体现为元数据操作或空间不足，网络问题则常见于丢包、重传、连接建立和带宽限制。

四个主题阶段应该怎样观看

系统性能排障顺序应由问题现象⭐决定，而不是由文✅件名决定。用户反馈接口变慢时，应先确认延迟、吞吐量、错误率和影响范围，再判断是否涉及 CPU、内存、磁盘、网络或应用代码。

CPU与内存分析的关键不是寻找最高占用进程，而是判断处理器时间究竟花在用户代码、内核代码、IO 等待、中断、调度还是虚拟化等待上。

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

视频标题只能帮助定位学习材料，不能代替故障分析。一个“CP💯U 使用率很高”的现象，可能来自真正的计算压力，也可能是频繁上下文切换、锁竞争、软中断或虚拟机窃取时间。