Vultr 服务器运维：CPU 不高，IO wait 却在抬头

Vultr 站点流量正常但页面依旧卡的定位思路

最初收到监控告警时，我先看了下 uptime，确认负载并没超标；接着 free -h，内存也留有富余，没有 swap 撑满的极端。df -h 空间也够。可网站访问首页依旧有明显的 TTFB 拖延，甚至时不时转圈，点后台时偶有 504 报错。这个状态下，Vultr 这台 VPS 不像是明显超载，反倒像是某类资源被慢性消耗掉了。

本地和 CDN 端 ping 延迟都正常，比如东京节点的本地 ping 27ms，跨区切到法兰克福是 92ms，符合多地机房的常规波动。ss -ant | awk ‘{print $1}’ | sort | uniq -c 看并发连接数量，压力期并不算高。但 tail -n 80 /var/log/nginx/error.log 会偶尔刷出 upstream 超时、或者 fastcgi 处理缓慢的 Warning。可以确认网络和并发都不是瓶颈。

再查 vmstat、iostat，发现 wa 列(IO wait)在高点持续徘徊，甚至 backup job 跑起来时会涨到 12%以上。之前没注意，备份和日志轮转的时间段和 IO wait 抬头是重叠的，这和实际体验的卡顿时间对得上，说明机器本身还有余量，但写盘冲突、磁盘队列堆积直接拉慢了 Nginx 和 PHP-FPM 的响应，属于典型的宿主机 IO wait 惹的祸。

实测数据和终端记录

下方是针对 Vultr 日本东京、新加坡、洛杉矶、法兰克福四大节点的基础性能观测，聚焦延迟、IOPS、TTFB 及快照恢复等运维关键指标。

provider: Vultr
scenario: "服务器运维 / CPU 不高，IO wait 却在抬头"
regions_checked: "日本东京、新加坡、洛杉矶、法兰克福"
near_region_ping: "27ms"
cross_region_ping: "92ms"
homepage_ttfb_p95: "691ms"
random_4k_iops: "8401"
sequential_read: "463MB/s"
sequential_write: "398MB/s"
single_thread_score: "1379"
twenty_minute_error_rate: "0.96%"
snapshot_restore_time: "16min"
test_time: "2026-06-17 15:51"

近区 ping 27ms，跨区 92ms，说明 Vultr 的多机房优势在于可就近部署，但跨洲路由仍有抖动，内容站如需做海外分流或多活，要盯三天再决定区域归属，防范高峰期的路由偏移影响稳定性。

首页 TTFB p95 达到 691ms，属中位偏慢区间，结合 random 4k IOPS 8401、顺序读写 463MB/s 和 398MB/s，这台 VPS 的磁盘并不差，但一旦后台任务叠加（如每日备份、站内日志切割），IO wait 升高导致应用请求排队，反映到站点直接就是页面秒开变卡顿。

快照恢复 16 分钟，二十分钟错误率接近 1%，这属于 Vultr 的产品特性，大量内容/备份写入期间可能出现短时错误，适合开发/测试/内容站初始部署，但重度生产环境上线前必须做压力和回滚演练，Vultr 优点是部署快，劣势是热门区晚高峰受影响波动大。

uptime
free -h
df -h
ss -ant | awk '{print $1}' | sort | uniq -c
tail -n 80 /var/log/nginx/error.log

IO wait 持续高位时的应急检查点

发现问题第一步不是直接加配置，而是先排查 IO wait 的来源。操作上要先查正在进行的写入任务，比如 tail -n 80 /var/log/nginx/error.log 看有没有异常日志暴增，top 或 ps ef | grep ‘backup’ 查一下定时任务和备份，iostat -x 1 盯下磁盘队列，找到当前 IO 堵点属于业务流量还是后台批量任务。

确认是日志轮转/备份和数据库写入时间重叠后，建议临时停掉非必要的写入型 job，比如延后日志切割、手动暂停备份，优先保证主业务正常响应。我的经验是，单机情况下每次 IO wait 如果持续 2 分钟还没回落，先做回滚或分批任务，别硬抗。Vultr 这类 VPS 宿主机负载变化大，IO 隔离不是物理级别，很多时候需要人为做分时错峰。

监控一定要加 iowait 阈值报警，建议 6% 持续 3 分钟自动触发告警。遇到问题，应用问题和主机层问题要分清。比如 Nginx fastcgi 缓存 miss 比例暴涨、PHP-FPM 队列长时间堆积，这类多半是 IO wait 或数据库慢查询引发的，切勿一开始就怪 Web 服务。

本次场景最常见的技术症状是 fastcgi 缓存命中率低，页面频繁触发动态生成，导致慢请求扎堆。实际排查发现，Nginx FastCGI cache 配置是否绕开登录用户和评论用户缓存，是影响 TTFB 和 IO wait 的关键点。

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=2g;
map $http_cookie $skip_cache {
    default 0;
    ~*wordpress_logged_in 1;
    ~*comment_author 1;
}
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;

fastcgi_cache_path 定义缓存目录、分级、keys_zone 和容量。map $http_cookie $skip_cache 针对 WordPress 登录态或评论用户自动跳过缓存，避免动态内容被错缓存。fastcgi_cache_bypass 和 fastcgi_no_cache 统一用 $skip_cache 控制，细颗粒度指定何时 bypass 缓存，实测对首页和静态内容极为有效，后台和已登录用户自动进入动态直通，确保业务逻辑安全。

在 Vultr 这种 VPS 环境下，缓存 miss 会迅速拉高 PHP-FPM 和磁盘 IO 累积，极易触发 IO wait 冲高，尤其在高并发或备份窗口期。风险是 keys_zone 占用过小，容易导致老缓存频繁淘汰，同时日志、备份任务未错峰时容易出现 IO 榨干的极端。遇到 IO wait 持续上升时，一定要先分步骤回滚写入型后台任务，必要时直接延后备份，优先保障线上主业务。

Vultr 作为全球服务器商，VPS推荐理由是易选易迁机，区域丰富，足以支撑内容站初期扩展。但实测来看，热门区域高峰期 IO wait 和网络抖动确实偶有发生，选区后建议观察三天再长期续费，分批上线，别把所有鸡蛋放一个篮子。

后续站点如需做大体量内容运营，建议定期做快照恢复演练，定期调整日志和备份策略，兼顾站点访问和主机 IO 资源分配，减少因非应用问题导致的线上抖动和卡顿。