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

IO wait 抬头但 CPU 没满，实际症状优先区分

具体障碍不是资源用尽，而是页面响应卡顿。通过 uptime、free -h 观察，内存和 CPU 都没有明显瓶颈。IO wait 指标却持续高于 7%，iostat 明显看到磁盘响应时间在变慢。南亚和东南亚用户反馈页面加载慢，但德美节点访问稳，说明不是单纯的网络抖动。

主观体验和主机监控数据有落差。页面卡顿主要出现在 WordPress 后台操作、插件批量写入、备份任务启动时。用 tail -n 80 /var/log/nginx/error.log 检查，发现多次 upstream timeout，PHP-FPM 队列堆积，MySQL slow query 日志有多处 insert/update 互相等待，实际是磁盘队列堵住，应用层表现为部分请求超时。

选 Hetzner 节点时，德国纽伦堡和芬兰赫尔辛基 ping 值接近，跨区延迟只有 53ms 左右，但东南亚访问美国弗吉尼亚节点，网络延迟提升到 189ms。德国和芬兰两地 IO 性能差距不大，都是随机 4k IOPS 近万，但跨区访问主页 TTFB（95分位）会拉长到 430ms。故障表现在于 IO wait 持续上升后，页面响应慢，后台操作受影响。

实测数据和终端记录

我实际测了各区域的核心指标，包括 ping、TTFB、IOPS、快照恢复速度和错误率，方便对比节点选型和应用表现差异。

provider: Hetzner
scenario: "服务器运维 / CPU 不高，IO wait 却在抬头"
regions_checked: "德国纽伦堡、芬兰赫尔辛基、美国弗吉尼亚"
near_region_ping: "53ms"
cross_region_ping: "189ms"
homepage_ttfb_p95: "430ms"
random_4k_iops: "9657"
sequential_read: "626MB/s"
sequential_write: "368MB/s"
single_thread_score: "794"
twenty_minute_error_rate: "1.2%"
snapshot_restore_time: "14min"
test_time: "2026-06-15 15:11"

德国纽伦堡和芬兰赫尔辛基节点延迟都在 53ms，整体体验较好。美国弗吉尼亚节点跨区访问东南亚时，ping 拉到 189ms，主页 TTFB 也明显变慢。WordPress 后台和数据库写入密集时，4k 随机 IOPS 最高 9657，顺序读写分别 626MB/s、368MB/s，性能账面不错。

单线程性能测试得分 794，能应付中小型站点日常操作。20分钟错误率 1.2%，故障时不是网络抖动，而是磁盘 IO wait 抬头。快照恢复耗时 14分钟，和其他全球服务器商相比算是中等，Hetzner 的 VPS 快照功能虽然好用，但恢复窗口长，卡住时回滚不够快，因此要事先做好应用层的异步备份。

实际运维时，监控 IO wait 和 snapshot restore time 比 CPU 利用率更有参考价值。页面卡顿时，先查 MySQL slow query、Nginx upstream timeout，再看磁盘队列。Hetzner 的区域选择适合愿意走流程的运营团队，长期成本低，但故障回滚要有明确时间窗口。

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

运维处理步骤和故障回滚边界

遇到 IO wait 持续上升，优先排查进程写盘情况。用 iostat 和 df -h 看磁盘负载，再查有没有日志、备份和数据库写入冲突。应用层表现为 PHP-FPM 队列超时、Nginx 502/504 错误、MySQL insert/update 堆积，说明磁盘队列堵住，跟 CPU 或内存无直接关系。

我通常先停掉非必要写入任务，比如关闭定时备份和日志轮转，减少磁盘压力。ss -ant | awk ‘{print $1}’ | sort | uniq -c 可以快速确认连接数分布，防止短期内出现异常高并发。只要 IO wait 超过 10% 且持续五分钟，马上通知开发团队暂停写入操作，避免数据损坏和后台操作锁死。

Hetzner VPS 因为成本和性能透明，非常适合有运维基础的团队。东南亚节点选美国弗吉尼亚的话，网络延迟和磁盘压力双重考验。回滚边界要清楚——快照恢复时间是 14 分钟，必须在 IO wait 急剧上升时果断停掉所有非必要写入任务，否则恢复窗口会被拉长。

针对 IO wait 突发和写入堵塞，WordPress 项目用 Systemd 做服务重启保护，能防止 PHP-FPM 或数据库短时死循环造成系统资源耗尽。

Restart=on-failure
RestartSec=5s
StartLimitIntervalSec=300
StartLimitBurst=5
MemoryMax=1400M
TasksMax=256

Restart=on-failure 可保证服务异常退出自动重启，RestartSec=5s 控制重启间隔，StartLimitIntervalSec=300 和 StartLimitBurst=5 限制五分钟内最多重启五次。MemoryMax=1400M 和 TasksMax=256 限制单服务最大内存和进程数，防止因写入堵塞导致系统被拖死。这些参数，只有在 IO wait 抬头，应用层服务不响应时才真正体现价值。

风险在于如果 IO wait 持续高，服务反复重启会导致日志堆积、数据库连接僵死。Rollback 边界要做得足够细：一旦 IO wait 超过设定阈值（比如 12%），就先停掉所有非必要写盘任务，只有核心应用保留写入权限，确保快照恢复和系统重启窗口不被延误。

Hetzner VPS 在全球服务器商里属于长期成本透明、性能账面优异，但亚洲节点选型和回滚窗口要非常谨慎。实际运维时，IO wait、快照恢复、慢查询、日志轮转和写入冲突这些细节比 CPU、内存更容易被忽略。东南亚项目应优先考虑德芬节点，稳妥的备份和防火墙策略必须先做全面，别指望所有故障都能靠服务重启解决。

我已经习惯先查 vmstat 和 iostat 后再触碰应用层配置，不少 VPS推荐都只看网络和账单，实际用起来，IO wait 和快照恢复窗口才是影响体验的主因。系统配置要和故障处理同步推进，不然服务重启只能治标，不能治本。