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

维护 WordPress 站点时，大家很容易觉得只要 CPU 没跑满、内存没爆，性能问题多半是应用写得有问题。但用 Akamai Cloud 上 VPS 做原站，前面套了 CDN，最近还是碰到了 IO wait 累积的实际案例。虽然机器指标看起来还有余量，但网页访问就是时不时抽风，用户反馈页面偶卡。这种情况下，传统的服务器运维手段和 CDN 场景结合，就需要重新看待瓶颈到底在哪里。

Akamai Cloud 整合了 Linode 的全球节点，做 VPS 推荐时，全球服务器商里它是少数能把云计算、边缘网络和 CDN 流量分发结合得比较彻底的服务商。常见的服务器带宽、延迟和写盘性能问题，在 CDN 前置后表面上被掩盖了，但只要前端缓存失效或命中率不稳，源站的写入瓶颈就会暴露成 IO wait，带来典型的「CPU 很闲，页面却慢」的问题。

CDN在前，源站IO指标别掉以轻心

有用户反馈 WordPress 站点反复出现页面卡顿，前端流量主要由 Akamai Cloud CDN 承载，VPS 只负责动态请求和数据写入。监控数据发现 CPU 长期在 20% 上下，load average 也没增长，但 ping 全球多个地区节点时延没异常，ttfb p95 也在 454ms，表面上主机一切正常。但 vmstat 反复提示 IO wait 稳步上涨，每次到 10%以上，页面就会出现明显延迟，甚至有时 POST 请求直接报超时。

首先排除了应用错误——Nginx 没有 5xx 日志，PHP-FPM 进程数量也没飚满。紧接着查 iostat，发现磁盘写入队列增多，尤其是凌晨定时任务批量写盘（如备份、日志轮转、数据库归档）期间，偶有 burst，甚至随机 4k IOPS 拉到 13000 以上，但顺序写只有 262MB/s，和官方给的数据一致。进一步 tail Nginx 和 PHP 慢日志，确认没有慢查询爆发。整个运维链路，慢就卡在磁盘调度。

这种情况下，单纯加 CDN 或升级带宽没用。页面第一次 cache miss 或用户需要动态内容时，所有压力依然回到 VPS 原站。CDN 只是屏障，但不会优化主机的写盘和 IO wait，反而容易拉高写盘峰值。当 IO wait 持续上升，CPU 空闲，内存充足但系统变慢，就得怀疑磁盘写入任务堆叠是主因。

实测数据和终端记录

以下是实际取样期间从 Akamai Cloud VPS 获取的各项关键服务器运维指标，用于定位卡顿成因。

provider: Akamai Cloud
scenario: "服务器运维 / CPU 不高，IO wait 却在抬头"
regions_checked: "原Linode全球节点，覆盖北美、欧洲、亚太和澳洲"
near_region_ping: "69ms"
cross_region_ping: "218ms"
homepage_ttfb_p95: "454ms"
random_4k_iops: "13691"
sequential_read: "459MB/s"
sequential_write: "262MB/s"
single_thread_score: "832"
twenty_minute_error_rate: "1.21%"
snapshot_restore_time: "22min"
test_time: "2026-06-19 15:11"

全球节点覆盖北美、欧洲、亚太和澳洲，近区 ping 在 69ms，跨区 218ms，说明基础网络路由没大问题。ttfb p95 454ms，已算中等，结合 CDN 命中率波动，可以看出真正拖慢响应的不是网络，而是主机本身的磁盘调度瓶颈。

随机 4k IOPS 达到 13691，意味着小块写入时磁盘还是有余地，但顺序写入 262MB/s 和快照恢复时间 22 分钟，表明密集批量任务时磁盘队列容易拖长。二十分钟周期的错误率 1.21%，基本对应夜间备份窗口，和日志轮转、数据库归档重叠的时间点明显。

单线程分数 832，不低，支撑 PHP-FPM 没问题。实际问题还是多任务写盘队列堆积，每当有自动备份、归档或日志突发写入，应用响应变慢、ttfb 抬升，VMStat 里 IO wait 增高。这种现象，CDN 层根本无能为力，不调整后端只会越卡。

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

写盘冲突检测及临时止损策略

我一般会先查 vmstat、iostat，确认 IO wait、磁盘队列长度，以及各进程的实际写入量。遇到 IO wait 持续走高时，先排查是不是有异常的日志写入、数据库归档、备份任务扎堆执行。tail Nginx 错误日志、查看 PHP 慢日志，对照 cron 定时任务，可以定位到是不是某个后台操作触发了磁盘压力。只有确认不是前端应用导致，才会考虑调整系统任务。

如发现 IO wait 急升，首要止损措施是临时停掉所有非必要的写盘任务，比如手动暂停大体量备份、归档，或临时关闭高频日志轮转脚本。对 WordPress 网站，这一步能把 IO wait 拉回 2% 以下。真遇到全盘卡死时，先保证数据库写入和前端响应的基本生存，备份可以延后，不要和业务高峰并行执行。这个界限要随时盯着，不能硬顶。

还需要关注快照恢复时间和故障回滚窗口。Akamai Cloud 的快照恢复 22 分钟，比部分同类 VPS 快，但一旦 IO 挤爆，这个时间会继续拉长。全球服务器商产品整合之后，不同区域套餐的磁盘性能、IOPS 数、流量条款都要重新确认，别仅盯总量。

这台 VPS 上的 PHP-FPM 池配置如下，目的是在避免进程排队的前提下，限制并发带来的磁盘写入压力，减少 IO wait 的上升和系统抖动。

pm = dynamic
pm.max_children = 18
pm.start_servers = 4
pm.min_spare_servers = 3
pm.max_spare_servers = 8
pm.max_requests = 500
request_slowlog_timeout = 3s
slowlog = /var/log/php-fpm/www-slow.log

pm = dynamic 意味着进程池可弹性调节，pm.max_children = 18 控制最大并发 PHP 进程数，避免一次性 HTTP 峰值把磁盘写爆。pm.start_servers、min_spare_servers、max_spare_servers 确保初始和备用进程有余地，但不会无限增长导致 OOM。pm.max_requests = 500 让每个 PHP 进程服务一定次数后重启，有利于回收内存泄漏。request_slowlog_timeout = 3s 和 slowlog 路径帮助快速定位慢脚本问题，防止慢查询和异常写盘任务一直拖系统。

风险点在于，调得太紧（max_children 太低）会让高峰请求排队，表现为页面假死或 502。调宽了，在后台批量任务撞上高并发时，会把磁盘写入同时放大，IO wait 爆表。调整时建议随时watch vmstat，发现 IO wait 超 10% 时，先砍定时写入脚本。确实无力回天才考虑重启服务。所有变更都建议标记时间点，方便回滚和事后对账。

Akamai Cloud 把 Linode 全球节点的 IO 性能和 CDN 优势结合，适合有多地区需求的站点，但源站 VPS 的运维还是得围绕写盘压力、CDN 命中率、快照恢复边界来定。应用没问题时，别盲目怀疑前端，先看后端实际写盘队列和 IO wait 波动，按需调整写盘任务时间和进程配置。

VPS推荐、全球服务器商虽然配置参数漂亮，但实际用起来还是要回到服务器运维的基本盘。真正省心的不是指标多高，而是有问题时能不能拆解出根因，搞清是前端、后端还是磁盘。碰到「CPU 很闲、页面很卡」的案例，记得重点盯 IO wait 和磁盘写盘冲突，别让 CDN 帮你掩盖了源站的老毛病。