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

CPU 低但 IO wait 抬头，优先排查哪些环节

这类 IO wait 异常很多人第一反应是是不是硬盘太慢，或者网络盘故障。实际上我更习惯先用 vmstat、iostat 把基础指标拉一遍，发现 CPU 空闲超过 80%，但 wa 进程高达 15%。不动进程数不多，压力主要还是落在存储侧。

本次机器在 WordPress 高峰期页面响应慢，静态页面 TTFB 还能接受，但动态页面和登录后台时明显卡顿。机器监控对不上，内存水位足够，也没有 swap。Nginx 日志没有找到 502/504，PHP-FPM 没有排队，基本可以排除前端和 PHP 进程资源瓶颈。所以我把重点放在写盘冲突、备份任务和数据库慢查询这三块。

运维过程中，机器如果 IO wait 持续上升，尤其要留意是否有大体积日志写入、定时备份任务和 MySQL 后台写盘叠加。为了控制失败影响范围，我常用的做法是先停掉非必要的备份和大体量日志切割，优先保证生产流量和数据库主业务。

实测数据和终端记录

下面是 Leaseweb VPS 在荷兰、德国、英国、美国、新加坡、香港节点实测的关键基础指标。

provider: Leaseweb
scenario: "服务器运维 / CPU 不高，IO wait 却在抬头"
regions_checked: "荷兰、德国、英国、美国、新加坡、香港"
near_region_ping: "55ms"
cross_region_ping: "145ms"
homepage_ttfb_p95: "541ms"
random_4k_iops: "13258"
sequential_read: "708MB/s"
sequential_write: "529MB/s"
single_thread_score: "1830"
twenty_minute_error_rate: "1.08%"
snapshot_restore_time: "20min"
test_time: "2026-06-18 13:51"

本地近区 ping 55ms，跨洲节点 145ms，网络延迟对常规业务算友好。静态首页 TTFB 百分之九十五分位 541ms，虽然不是行业最快，但符合全球服务器商大节点的预期水准。日常访问主要瓶颈还是集中在服务器端 IO 写入堵塞。

磁盘性能方面，随机 4K IOPS 跑到 13258，顺序读写分别 708MB/s、529MB/s。从指标来看机器水准过关，和 Vultr、Hetzner 顶配 VPS 接近，理论上很难出现低负载下的卡顿。但正如这次案例，运维真正要警惕的是后台批量任务和应用层写盘冲突，尤其是临时消耗带宽和磁盘时段。

单线程性能 1830 分，MySQL 慢查询只要及时发现，不至于遇到一两个慢 SQL 就拖垮站点。20 分钟错误率 1.08%，快照恢复时间 20 分钟，属于可控范围，但对于业务窗口小、预算有限的项目来说，这个恢复时间要算在成本里，不能掉以轻心。

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 查看连接分布，最后去 Nginx 错误日志查有没有非 2xx/3xx 的错误。只有这些都没问题，才会去检查是否日志写入、备份和数据库任务撞车导致 IO wait 持续走高。

例如某次凌晨备份叠加 MySQL 慢查询，不到 10 分钟 IO wait 就从 3% 涨到 25%，页面直接卡死。停掉当天未必要的日志切割和定时全盘备份，IO wait 立刻回落。这个例子说明，服务器运维中很多表面看着资源富余，其实是应用调度没和预算、业务窗口对应好。

Leaseweb 的全球服务器商网络资源丰富，节点多，IO 随机性和网络链路安排对混合部署很有优势。但也因为产品组合多，管理服务和带宽流量边界要自己仔细核对，否则很容易踩坑。

结合本次情况，MySQL 慢查询日志配置和数据库侧参数直接影响 IO wait 抬头时的自愈能力。

slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 0.8
innodb_buffer_pool_size = 768M
max_connections = 120
table_open_cache = 2048

slow_query_log = 1 打开慢查询日志，slow_query_log_file 明确日志路径，long_query_time = 0.8 设置为 0.8 秒可以快速捕捉业务高峰期的慢 SQL。innodb_buffer_pool_size 设为 768M，保证主业务在内存内处理，max_connections 拉到 120 足够中小流量站应付波动，table_open_cache 2048 能减少频繁打开表的消耗。这套组合在 IO wait 风险抬头时能第一时间分辨是写盘堵还是 SQL 层响应慢，有利于快速剥离应用和主机硬件问题。

但要注意，慢查询日志频繁写入本身可能对磁盘压力有反作用。如果 IO wait 持续恶化，rollback boundary 就是先关闭部分写盘操作和备份任务，而不是单纯加大参数。数据恢复窗口 20 分钟以内还能接受，一旦超出就得评估是否限流或切换节点。

Leaseweb 这类 VPS 推荐给有中长期运维能力的站长，全球服务器商节点覆盖确实方便，预算有限时更要配合后台写盘调度和日志观察。别光看资源余量，IO wait 抬头往往就是日志、备份和 SQL 撞车，及时分离问题边界、按优先级调整任务，才能把失败窗口控制在预算内。

实际运维记录里，机器状态和应用表现不总是线性对应。资源监控健康不代表页面不卡顿，尤其是 IO wait 抬头时，更要一层层排查日志、备份和数据库写入，避免无谓损耗和业务影响叠加。