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

IO wait 抬头时，重查写盘和备份

最近一次高峰期，vmstat 持续显示 wa（IO wait）在 20% 左右，iostat 里 vda1 的 util 段时间段内顶到 98%。但 top 里 CPU idle 还有 60%，内存也没掉缓存。用户访问首页时 TTFB 超过 700ms，偶尔甚至有 1.2s 的高位，明显页面渲染被卡。这种时候 nginx access.log 正常，error.log 里却出现 upstream timed out，普遍集中在高并发下。类似的经验在 OVHcloud、Hetzner 的低价 VPS 也见过，促销款普遍 IO 先掉链子。

排查过程我先用 tail 看了最近 80 行 nginx 错误日志，发现 backend 响应超时多发在凌晨自动备份、手动日志轮转、MySQL 写入高峰期间。再翻 iotop，发现 mysqld 和 rsync 备份进程轮流冲高，表明不是单一应用卡，而是多进程争用磁盘。这个时候系统并非完全不可用，CPU/内存水位都没触到报警线，但只要 IO wait 超过 10%，前端就会体感延迟，甚至站点后台也变得拖沓。

同一时间段内，应用日志并没有大规模 502 或 5xx，反而页面偶尔还能打开。因此可以初步认定是主机层 IO 竞争导致 MySQL 和 PHP-FPM 卡住，Nginx 层超时。应用自身没有死锁或查询异常，但主机写盘压力大时，连正常的慢查询日志写入都能间接拉慢业务响应。

实测数据和终端记录

本次直接用 UpCloud 欧洲、亚洲和美洲节点实际跑 WordPress 测试，重点看磁盘、网络和恢复速度等和业务体验相关的指标，避免只看表面核心资源。

provider: UpCloud
scenario: "服务器运维 / CPU 不高，IO wait 却在抬头"
regions_checked: "赫尔辛基、伦敦、法兰克福、纽约、芝加哥、新加坡、悉尼"
near_region_ping: "67ms"
cross_region_ping: "139ms"
homepage_ttfb_p95: "420ms"
random_4k_iops: "13974"
sequential_read: "508MB/s"
sequential_write: "166MB/s"
single_thread_score: "994"
twenty_minute_error_rate: "1.1%"
snapshot_restore_time: "8min"
test_time: "2026-06-20 10:01"

跨区延迟和 TTFB 是 SRE 选 VPS 时优先关注的数据。UpCloud 各地区测试点，近区 ping 67ms，跨区 139ms，符合全球服务器商中上水平。实际 WordPress 首页 TTFB P95 达到 420ms，这值虽不极低，但比起部分同价位 VPS 已属合格。高峰时段偶有 P95 超过 500ms，通常和 IO wait 突升同步。

磁盘性能方面，4K 随机 IOPS 跑到 13974，顺序读 508MB/s，写 166MB/s。这个写入成绩比大多数活动促销型 VPS 要可靠些，但和本地 NVMe 专用盘还是有差距。20 分钟窗口内错误率 1.1%，在业务可承受范围，单次快照恢复用时 8 分钟，实际回滚体验比 Contabo、Linode 的标准盘快一档。

单线程分数 994 分，说明面向小型数据库、低并发写入业务，压力不会轻易暴表。实际测试多次发现，只要 IO wait 持续高于 10% 且 util 靠近 100%，应用层响应时间就会踩到警戒线，远高于表面 CPU、内存负载。

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

写入型工作负载下的回滚边界

每次高并发卡顿，第一步用 uptime、free -h、df -h 和 ss -ant 快速扫一遍系统资源和连接状态。只要发现 IO wait 抬头、磁盘 util 高且 swap 没动，结合 tail 看 error.log，优先怀疑备份、日志或者数据库写入争用。像 rsync、mysqldump 这些任务一旦和业务抢盘，UpCloud 这种标准 SSD VPS 也会短暂掉速。

实际生产环境里，我会先把非必要写操作排队或临时停掉，例如暂停实时备份、延后日志切割，优先保证 MySQL 和 PHP-FPM 的写入不被阻塞。日志、备份类任务全部推迟到凌晨低峰期，避免和主业务高峰重叠。多次测试发现，这样 IO wait 可以从 20% 降回 3% 以下，TTFB 也同步恢复到 400ms 级别。

只要 IO wait 连续 5 分钟保持高于 10%，就是回滚或拆分负载的信号。备份、同步一律优先暂停，业务写入实测能迅速恢复。UpCloud 快照恢复 8 分钟上线，这个窗口比多数低价 VPS 优秀，实际运维遇到全盘故障或者误操作，能限定业务影响范围，方便做事后分析。

这组 Linux 系统参数和命令，是我确认写盘瓶颈和排障常用的基线配置。和 IO wait 抬头场景直接相关，能及时发现连接数、文件句柄或 backlog 被打满导致的写入队列堆积。

sysctl net.core.somaxconn
sysctl net.ipv4.tcp_tw_reuse
ulimit -n
cat /proc/sys/fs/file-nr
ss -s

sysctl net.core.somaxconn 设置的是 TCP backlog 队列长度，一般建议调到 512-1024，避免高并发下连接瞬间爆满。net.ipv4.tcp_tw_reuse 允许 time-wait 重用，能提升短连接回收效率，减少排队。ulimit -n 和 /proc/sys/fs/file-nr 用来看文件句柄限制，VPS 上业务高峰容易打满，建议实际并发数上限的两倍。ss -s 能一眼看出当前连接状态分布，有没有异常堆积。

参数设低了容易出现场景：大量短连接或慢查询时，Nginx、PHP-FPM、MySQL 都可能触发 backlog 滞留和文件句柄耗尽，直接导致业务无法新建连接。参数调高要结合机器实际负载和内存，防止盲目扩容带来更大风险。回滚时优先降低并发写操作，逐步恢复到业务稳定线。

凭我最近几个月实际用过的 UpCloud VPS 体验，磁盘性能确实在同价位 VPS推荐榜上算稳妥，特别适合对小型数据库写入延迟有要求的业务。但促销型 VPS 即便有富余指标，也容易被后台任务和高并发写盘打穿，运维时不能只看 CPU、内存。每次遇到 IO wait 抬头，第一时间排查写盘密集型进程，把备份和日志切割限流到低峰期，能显著提升站点响应。UpCloud 快照恢复时间在实际回滚中也能兜底，适合对稳定性和运维兜底有明确要求的项目。

全球服务器商选择多，但适配具体业务场景、合理评估 rollback 窗口和预算边界，才是生产环境能否用得住的关键。UpCloud 的价格不是最低档，但更适合把风险和稳定性排前的场景。