凌晨备份启动后，VPS 上的 IOPS 从 800 跌到 200，网站请求接连超时，数据库写入也从毫秒级拖到数秒，面板里的磁盘跑分却仍然很高。问题往往不是磁盘“不够快”，而是测试命中缓存、负载偏离业务，或把顺序吞吐、随机 IOPS 与延迟混成一项。参数一旦脱离真实业务，再高的分数也可能误导扩容判断。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：onidel（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一、fio 参数要还原真实负载
fio测试参数设计要从负载出发。网站偏顺序读，数据库关注 4K 随机读写与同步落盘，备份是长时间顺序写，不能共用同一组 bs、iodepth 和读写比例。固定目录、大小、时长后逐项变更，顺序 1M 与随机 4K 分开测。
缓存控制决定可信度。buffered 测试可能命中页缓存，更像在测内存；direct=1 可绕过缓存，但仍要明确写入是否等待 fsync。目录、文件系统、预分配方式和测试时间应固定并记录，否则多轮结果无法比较，磁盘性能结果复现就失去意义。
还要理解IOPS、吞吐与延迟：1M 顺序读的 MB/s 不能替代 4K 随机读的 IOPS；提高 iodepth 可能增加吞吐，却恶化 p95、p99 延迟。数据库优先看小块随机负载，共享型 VPS 的单次峰值也不能代表全天稳定。
二、按网站、数据库与备份判断余量
先选接近生产的负载，再设门槛。网站看缓存未命中后的随机读和短时峰值；数据库看 4K 随机读写混合及 fsync 场景，核对并发所需 IOPS 与尾延迟；备份看持续顺序写，并避开数据库高峰。
不要套用统一“优秀线”，可把实测值当作上限，将日常可用余量控制在 70%～80%，为突发流量、队列抖动和虚拟化损耗留出空间。若网站正常而数据库随机写变慢，应先查混合负载与落盘延迟；若所有测试都慢，再查虚拟磁盘和宿主机争用。
最终至少重复三轮，保存参数和原始 JSON，并同步观察 CPU、Swap 与磁盘利用率，避免把主机侧瓶颈误判成磁盘问题。日常巡检可用 ServLlama 汇总指标，把 fio 基线与线上趋势对齐；工具负责呈现变化，结论仍要回到缓存边界与业务负载。
结果解读：别把吞吐、IOPS 与延迟混为一谈
顺序与随机读写回答的问题不同。大块连续读写测带宽上限，小块随机读写更接近数据库和文件系统负载。前者吞吐通常更高，但单次 I/O 更大，不能据此说它“更快”。比较时应固定块大小，如顺序 1 MiB、随机 4 KiB，并保持读写方向、比例和并发模型一致。
IOPS、吞吐和延迟不能混为一谈。IOPS 是每秒操作数，吞吐是每秒数据量，延迟反映请求等待时间；三者受块大小和队列深度影响。队列从 1 提到 32，吞吐可能上升，延迟也可能因排队变差。因此还要同时看平均延迟、p95/p99 延迟和 CPU 利用率。
结果还要结合错误数与抖动判断。少量高延迟尖峰即使伴随高 IOPS，业务体验仍可能不稳定；共享宿主机的邻居负载、虚拟化调度和突发回收也会制造波动。不要凭一次短测下定论，至少重复三轮并保存原始 JSON，同时排除备份、编译和业务流量。
缓存控制与性能复现：让测试结果可信
缓存与落盘控制决定测到哪一层。普通缓冲 I/O 可能先写入页缓存，测试结束看似很快，数据却未必持久化。验证磁盘通常采用 direct=1 绕过页缓存，并用 fsync 检查提交路径；direct 与非 direct 应分开比较。
不要随意执行全局 drop_caches：它可能影响同宿主机其他租户，也可能清掉无关数据。更安全的做法是在专用 VPS、空闲时段和固定区域测试，并预留足够空间。使用 SSD 时，还应确认 TRIM/discard 与云盘回收策略不会在测试中回收块。
复现磁盘性能需固定 fio 版本、文件系统、挂载参数、队列深度和时长，并记录 CPU、内存及预热过程。先短预热，再做稳态测试；复测沿用同一命令。若结果漂移，先排查共享宿主机性能、存储限速和后台任务，再判断磁盘是否变化。
最终检查清单：①无业务流量且空间充足；②分别设计 1 MiB 顺序与 4 KiB 随机测试，固定读写比例、队列深度及时长；③记录 IOPS、带宽、平均与 p95/p99 延迟、错误数和 CPU 占用；④验证持久化时启用 direct 与 fsync，缓存场景另测；⑤每项重复三轮，保存 fio JSON、命令和系统信息；⑥按业务目标解读，不把峰值当典型值，也不横比不同参数的数据。
喜欢 
顶
难过
囧
围观
无聊
