凌晨促销流量涌入VPS后，接口响应时间从20ms升至数百毫秒，监控里的CPU使用率却只有40%。运维人员容易立即扩容CPU，但真正等待的可能是磁盘请求：进程已经进入不可中断睡眠，队列持续堆积，业务线程无法推进。更棘手的是，偶发慢请求与持续性I/O饱和看起来十分相似；若仅凭一分钟平均值判断，既可能误加CPU，也可能靠重启暂时掩盖脏页回写压力。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：浪浪云（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一、三类拥塞信号并不是同一回事
首先区分CPU计算压力、CPU等待与磁盘饱和。计算压力通常伴随用户态占用升高、运行队列变长和上下文切换增加；CPU等待则表现为iowait升高，但iowait本身不能证明磁盘已饱和，它还可能受到虚拟化宿主机调度、存储网络拥塞或设备超时影响。此时应观察进程的进程阻塞状态：大量任务处于D状态，说明它们正在等待内核I/O，而不是等待CPU执行。
磁盘持续饱和有三个更稳定的信号：请求平均等待时间持续上升，块设备队列深度长期大于1，以及读写延迟与吞吐同时恶化。块设备队列深度高，说明多个请求尚未完成便有后续请求进入；平均等待时间增加，则反映服务响应已经受到排队影响。脏页回写压力还有明显前兆：系统脏页比例上升、writeback进程频繁刷新，但设备利用率未必立刻达到100%。此时业务写入看似成功，延迟尖刺却可能由内核集中回写造成。
短时抖动则不同。它通常只持续数秒，块设备队列深度和平均请求等待时间同步冲高，随后迅速回落；常见原因是日志刷盘、备份任务、虚拟化邻居突发负载或存储网络重传。若只查看五分钟平均值，这些尖峰会被稀释。因此应保留原始采样，至少同时记录p95、p99延迟、队列深度、吞吐和设备等待时间，避免用单个平均值给瓶颈下结论。
二、用延迟分解和队列指标锁定瓶颈
判断时先建立端到端链路：应用收到请求后，分别记录进入系统、调度到线程、发起文件I/O、I/O完成及返回响应的耗时。只有I/O完成段明显变长，才能把问题收敛到存储路径。CPU运行队列持续拥挤且用户态时间高，才偏向计算不足；D状态任务多、存储延迟升高而CPU仍有空闲，则应优先处理磁盘。还要加入宿主机视角，因为VPS内部看到的是虚拟块设备，底层共享介质争用可能表现为设备延迟增加，却不一定表现为本机磁盘利用率百分之百。
随后做存储延迟采样，按十秒或三十秒粒度关联四项指标：平均请求等待时间、块设备队列深度、读写吞吐和进程D状态数量。若队列深度长期偏高、等待时间连续多个窗口上升，可判定为持续饱和；尖峰零散且很快回落，多为短时抖动；若脏页数量与writeback活动同时升高，则属于回写压力。不要把设备利用率单独作为依据：现代设备可能用更低利用率完成更高吞吐，SSD也存在并发深度限制。
处理顺序应与证据匹配。持续饱和且CPU有余量时，先限制并发I/O、合并小文件或启用异步写入，再评估更换更大吞吐或更低延迟的存储；脏页回写压力明显时，可调整脏页比例和回写节奏，但不能把阈值当成万能解法；短时抖动若来自日志或备份，应错峰执行并设置限速。ServLlama可用于集中查看进程状态、队列与延迟采样，帮助确认高延迟究竟集中在哪个业务进程。若队列长期不降、采样已确认底层存储劣化且调参无效，再迁移到独立或高性能存储，避免继续用CPU扩容掩盖问题。
把 I/O 等待拆成队列与真实服务时间
在排除 CPU、网络瓶颈后，用 iostat -xz 1 同时观察平均请求等待时间（r_await、w_await）、吞吐和请求队列。等待时间包含排队与服务耗时，不能单凭它断定磁盘已满；队列持续堆积且延迟同步上升，才像本地设备拥塞。队列较低而延迟偶发升高，应转查虚拟机宿主、云盘后端或介质错误。
块设备队列深度要结合 /sys/block/sda/queue/nr_requests、/proc/diskstats 和 cgroup 的 io.stat 判断。前者是设备允许排队的上限，并非实时队列；diskstats 是累计值，必须通过相邻采样求差。容器限流也可能表现为等待升高，因此还要按设备和进程组分别统计。
存储延迟采样应记录时间、读写方向、队列深度和延迟分位数。线上不要直接进行高并发压测，可改用影响较小的 fio，选择有代表性的块大小，并对比 direct=1 与缓存路径。云环境还要区分存储网络、宿主机争用和配额限流。
从阻塞进程回溯真正的写入源
用 ps -eo state,pid,ppid,comm 找出处于 D 状态的任务，再查看 /proc/<pid>/stack 或 wchan。这种进程阻塞状态只表示任务正在等待 I/O 或内核锁，并不等于该进程就是根因；还要结合父子关系、打开的文件和调用栈，判断压力来自日志、数据库刷盘、备份还是 swap。
如果写入量很大而设备利用率不高，应检查 /proc/meminfo 中的 Dirty、Writeback 以及 vm.dirty_* 参数。Dirty 表示待回写页，Writeback 表示正在写回的页；二者持续增长，才说明存在脏页回写压力或回写受阻。将它们与写回线程、设备等待时间对应起来，才能分清是应用提交过快，还是底层设备写不动。
常见误区是把 iowait 当成磁盘延迟、把 %util=100% 当成吞吐饱和，以及在高峰期运行 fio。这些指标只能提示症状，不能替代因果验证。最后按清单执行：采集 iostat -xz 1、vmstat 1、pidstat -d 1 和 /proc/pressure/io；定位 D 状态进程、其打开文件与 cgroup；核对 Dirty/Writeback、队列深度和等待时间；检查日志轮转、数据库 checkpoint、备份、swap 与云盘限流；仅在低峰进行可回收的短时采样。队列深、等待涨、回写堆积同时出现，才可确认 I/O 拥塞；若仅出现单次高延迟，则优先追查后端抖动或错误重试。
喜欢 
顶
难过
囧
围观
无聊
