最近一段时间，我的 WordPress 服务器再次频繁出现 CPU 使用率过高告警。
这台服务器同时承载中文站、英文站和 WordPress 后台域名，前端还分别接入了 EdgeOne 与 Cloudflare。WordPress 使用 W3 Total Cache 作为页面缓存，通过 Redis 保存对象缓存。
此前我已经围绕 CDN、W3TC 页面预缓存、Redis 对象缓存和 Nginx 规则进行过多轮排查与优化。但这次再次出现持续 CPU 告警后，我开始重新考虑一个问题：
继续投入大量时间优化缓存与 CDN 规则，是否还比直接升级服务器硬件更划算？
经过云监控、EdgeOne 离线日志和 W3TC 预缓存范围的实际分析后，我最终决定将阿里云 ECS 从 1 核 2 GiB 升级为 2 核 4 GiB。
本文记录这次从再次告警、分析请求，到最终完成硬件升级和验证的完整过程。
一、服务器再次频繁出现 CPU 告警
在阿里云云监控的报警历史中，可以看到多次 CPU 告警。
2026 年 8 月 3 日晚间，服务器曾两次达到 100%：
2026-08-03 20:48:01 CPU 100%
2026-08-03 20:51:01 恢复到 66.59%
2026-08-03 21:02:01 CPU 100%
2026-08-03 21:04:01 恢复到 63.78%
2026 年 8 月 4 日凌晨又出现了一轮持续时间更长的告警：
2026-08-04 02:20:01 告警发生，CPU 78.38%
2026-08-04 02:21:01 仍超过阈值，CPU 79.43%
2026-08-04 02:43:01 恢复正常，CPU 68.23%
这次 CPU 高负载持续了大约 23 分钟，因此更适合作为重点分析样本。
我随后将监控时间缩小到 2026 年 8 月 4 日 02:10～02:50。
从操作系统监控曲线可以看到，在 02:10 到 02:42 之间，CPU 长时间处于 75%～100% 区间，并且频繁触及 100%。
同一时间，内存使用率长期保持在 60% 左右。内存本身没有立即耗尽，但对于一台只有 2 GiB 内存的服务器来说，剩余空间已经不算宽裕。
二、最初怀疑 W3TC 没有预缓存归档分页
此前，我已经为 W3 Total Cache 制作了一份中文站与英文站联合使用的预缓存 Sitemap。
这份文件会读取：
https://www.shuijingwanwq.com/sitemap_index.xml
https://en.shuijingwanwq.com/sitemap_index.xml
然后递归收集两个站点的文章、页面、分类和标签 URL，并让 W3TC 分批预热。
这次告警后，我开始怀疑：
当前预缓存是否只覆盖了分类页、标签页和日期归档的第一页，而没有覆盖
/page/2/这样的后续分页？
实际检查结果是：
总 URL 数量：6338
包含 /page/N/ 的 URL 数量：0
这证明当前联合 Sitemap 中确实没有以下页面：
/page/2/
/page/3/
/category/example/page/2/
/tag/example/page/2/
/2026/08/page/2/
原因也比较明确：生成脚本只是递归读取 Yoast Sitemap 中已经存在的 URL，并不会自行计算每个归档页有多少分页，再额外生成 /page/N/。
这些分页仍然可以被 W3TC 正常缓存，但必须先由访客或爬虫访问一次：
- 请求首次到达源站；
- WordPress、PHP 和数据库动态生成页面；
- W3TC 将生成结果保存为 Page Cache；
- 后续相同请求才能直接命中页面缓存。
如果大量爬虫集中访问此前没有生成缓存的分页页面，就会增加 PHP 和数据库负载。
不过，仅凭这一点还不能认定分页未预缓存就是本次 CPU 告警的根本原因。
三、将阿里云告警时间与 EdgeOne 日志对齐
确定告警窗口后，我在 EdgeOne 下载了相同时间段的离线日志。
阿里云云监控使用北京时间，告警发生在：
2026-08-04 02:10～02:43
EdgeOne 离线日志文件名中的时间使用 UTC，因此需要下载：
2026-08-03 18:00～18:59 UTC
对应的北京时间正是：
2026-08-04 02:00～02:59 UTC+8
EdgeOne 分别生成了中国大陆可用区，以及全球可用区（不含中国大陆）的日志文件。
对两份日志进行合并分析后，发现了两类比较明显的自动化抓取行为。
四、一个固定客户端持续抓取了 1320 个 HTML 页面
在 02:10:04～02:42:26 之间，有一个固定客户端 IP 持续访问网站。
它的请求特征如下：
| 指标 | 结果 |
|---|---|
| HTML 请求数 | 1320 |
| 不同路径数 | 1316 |
| EdgeOne MISS | 1044 |
| 静态资源请求 | 0 |
| 单秒最高请求数 | 16 |
| 开始时间 | 02:10:04 |
| 结束时间 | 02:42:26 |
这个时间范围与阿里云 CPU 高负载曲线几乎完全重合。
该客户端使用了一个看起来很普通的 Chrome User-Agent：
Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36
Chrome/90.0.4430.93 Safari/537.36
但它的行为显然不是普通浏览器访问：
- 连续访问 1316 个不同的 HTML 路径；
- 完全没有请求 CSS、JavaScript、字体和图片；
- 同一秒内并发请求多个页面；
- 快速遍历文章、分类、标签和分页；
- 抓取结束后不久，服务器 CPU 恢复正常。
其访问页面构成如下：
| 页面类型 | 请求数 |
|---|---|
| 文章详情页 | 724 |
| 标签首页 | 242 |
| 标签分页 | 156 |
| 分类首页 | 78 |
| 分类分页 | 55 |
| 其他页面 | 48 |
| 首页分页 | 10 |
| 首页或搜索 | 4 |
| 日期分页 | 3 |
其中分页请求合计为 224 次，约占该客户端全部请求的 17%。
这说明分页没有被预缓存确实会增加部分负载，但即使把所有 /page/N/ 加入预缓存，这个客户端仍然会继续请求数百篇文章、标签页和分类页。
在整个 02:10～02:43 告警窗口中，这一个客户端：
- 占全部请求约 23.5%；
- 占全部 EdgeOne MISS 约 46%；
- 占 EdgeOne 记录的内部处理耗时约 47.1%。
因此，它是本轮 CPU 告警中最主要的外部请求来源。
五、同时还存在分布式异常路径扫描
日志中还有另一组统一使用 Nexus 5 移动端 User-Agent 的请求：
Mozilla/5.0 (Linux; Android 6.0; Nexus 5 ...)
Chrome/65.0.3325.181 Mobile Safari/537.36
这组请求在同一告警窗口中的特征如下：
| 指标 | 结果 |
|---|---|
| 请求数 | 260 |
| 客户端 IP 数 | 134 |
| 不同 URL 数 | 256 |
| EdgeOne MISS | 260 |
| Referer | 全部为空 |
部分请求还会构造非常长、非常异常的路径，例如将多个分类和历史路径不断拼接：
/category/web-devel/web-framework/yii/page/14/
http-basics/http/https-tool/httpserver/http-status/...
这类地址不是正常的 WordPress 导航结果，更像是分布式扫描程序在组合和遍历 URL。
部分 MISS 请求的响应时间已经达到 20～30 秒。在主抓取客户端请求暂时减少时，这类分布式请求仍然可能继续消耗 PHP-FPM 和 CPU。
日志中还存在大量搜狗爬虫请求，但它们大部分已经被 EdgeOne 命中缓存：
搜狗请求总数：1686
HIT：1586
MISS：74
Dynamic：26
因此，搜狗爬虫虽然请求量较高，但不是这次源站 CPU 持续高负载的主要来源。
六、为什么没有继续全面增加 CDN 防护规则
完成日志分析后，我又检查了 EdgeOne 当前的安全防护配置。
当前已经开启：
自适应频控
规则等级：自适应－宽松
处置方式：JavaScript 挑战
但当前套餐中：
- 智能客户端过滤需要更高版本；
- 慢速攻击防护需要企业版；
- 精准速率限制只有 1 条配额；
- 高级 Bot 管理同样需要升级服务。
我当然可以继续围绕 User-Agent、单 IP 请求频率、HTML 页面范围和 JavaScript 挑战设计规则。
但这里存在几个现实问题：
第一，主要抓取客户端的峰值只有每秒十几次，并不是传统意义上的大流量攻击。规则设置过宽无法命中，设置过严又可能误伤正常用户和搜索引擎。
第二，还有大量来自不同 IP 的分布式请求，仅限制一个 IP 无法彻底解决。
第三，将所有分类、标签和日期归档分页加入 W3TC 预缓存，可能让联合 Sitemap 从几千个 URL 快速扩大到数万甚至更多。这样不但未必解决抓取问题，还可能让 W3TC 自己长期制造预热负载。
第四，当前服务器本身只有 1 核 CPU。即使缓存和 CDN 配置继续优化，只要出现一批没有命中缓存的动态请求，PHP-FPM 仍然很容易把唯一一个 CPU 核心占满。
继续优化当然还有价值，但在这个阶段，投入产出比已经开始下降。
七、服务器本身已经缺少资源余量
升级前，这台 ECS 的配置为：
实例规格：ecs.n1.small
CPU：1 vCPU
内存：2 GiB
公网带宽：2 Mbps
在阿里云控制台中，日常内存使用率已经长期接近 60%，CPU 又频繁触发 70%、95% 甚至 100% 告警。
除此之外，我还计划在这台服务器上部署 Go Tour 多语言程序站点。
虽然 Go Tour 生产环境不会在服务器本机执行用户提交的 Go 示例代码，但它仍然需要：
- 独立的 Go Web 进程；
- Nginx 反向代理；
- 日志和监控；
- 部署和更新时的临时资源；
- 与现有 WordPress 服务共享 CPU 和内存。
在这种情况下，继续让 WordPress、Nginx、PHP-FPM、Redis、W3TC 和未来的 Go 服务全部挤在 1 核 2 GiB 上，风险已经比较明显。
因此，我决定先升级硬件，为现有网站和后续程序站点增加基础余量。
八、预算有限，最终选择 2 核 4 GiB
阿里云升配页面提供了多个可选规格，例如：
| 规格 | 配置 | 参考价格 |
|---|---|---|
| ecs.n1.medium | 2 核 4 GiB | 188 元/月 |
| ecs.n2.medium | 2 核 8 GiB | 294 元/月 |
| ecs.sn1.medium | 2 核 4 GiB | 259 元/月 |
| ecs.sn2.medium | 2 核 8 GiB | 286 元/月 |
计算型和更新规格族在 CPU 稳定性方面更有优势，但我当时的预算比较有限。
综合当前负载和成本后，我最终选择：
ecs.n1.medium
2 vCPU
4 GiB
公网带宽继续保持 2 Mbps
它仍然属于共享计算型，不是理想的长期高性能方案，但与原来的 1 核 2 GiB 相比：
- CPU 核心数翻倍；
- 内存容量翻倍；
- PHP-FPM 不再与所有服务争抢唯一一个 CPU 核心；
- Redis 和系统文件缓存拥有更多内存余量；
- 可以先为 Go Tour 提供基本运行空间。
实例当时的到期时间是 2026 年 12 月 4 日。
控制台显示的 188 元/月 是规格参考价格，实际升配只需要支付剩余服务期的新旧配置差价。
本次实际补差价为：
441.03 元
九、升配前先创建系统盘快照
虽然阿里云 ECS 变更实例规格通常不会修改系统盘和数据盘内容，但生产环境操作仍然应该保留回滚手段。
在确认订单前，我先为系统盘创建了一份快照。
这份快照主要用于应对以下情况：
- 实例重启后系统无法正常启动；
- Nginx、PHP-FPM 或 Redis 启动失败；
- 文件系统或配置出现异常；
- 必须恢复到升配前状态。
完成快照后，我回到升级配置页面，选择：
变配生效之后，立即重启实例
支付并提交订单后，ECS 自动重启。中文站、英文站和后台域名在重启期间短暂不可访问。
几分钟后，阿里云控制台重新显示实例处于“运行中”状态。
十、验证 CPU、内存和基础服务
服务器恢复后，我首先执行只读检查：
date
uptime
nproc
free -h
ps -ef | grep '[n]ginx'
ps -ef | grep '[p]hp-fpm'
ps -ef | grep '[r]edis-server'
ss -lntp | grep -E ':(80|443|6379)\b'
实际结果如下：
CPU 核数：2
内存总量：3.6 GiB
已使用：327 MiB
可用：3.0 GiB
Swap：2.0 GiB
已使用：0
控制台购买的是 4 GiB 内存，而 Linux 中显示约 3.6 GiB，属于虚拟化和系统预留后的正常结果。
Nginx、PHP-FPM 和 Redis 均已正常启动：
Nginx：1 个 master、2 个 worker
PHP-FPM：正常运行
Redis：127.0.0.1:6379 正常监听
从 Nginx worker 数量也可以直接看到，新系统已经识别到两个 CPU 核心。
十一、验证中文站、英文站和后台域名
随后分别检查源站和公网访问。
源站请求结果：
www.shuijingwanwq.com HTTP 200
en.shuijingwanwq.com HTTP 200
admin.shuijingwanwq.com HTTP 200
公网请求同样全部返回 200：
https://www.shuijingwanwq.com/ HTTP 200
https://en.shuijingwanwq.com/ HTTP 200
https://admin.shuijingwanwq.com/ HTTP 200
中文首页第一次源站访问耗时约 14.45 秒，而英文首页和后台首页只需要约 0.02 秒。
刚开始看到这个结果时，我一度怀疑中文首页仍然存在性能问题。
不过，服务器刚刚重启，W3TC 页面缓存尚未完成首次生成，因此还需要区分：
- 持续性慢响应；
- 重启后的第一次冷缓存生成。
十二、中文首页只是第一次冷缓存生成较慢
我随后连续请求了 5 次中文首页：
第 1 次：TTFB 0.014612 秒，总耗时 0.015976 秒
第 2 次：TTFB 0.020882 秒，总耗时 0.022608 秒
第 3 次：TTFB 0.015257 秒，总耗时 0.016543 秒
第 4 次：TTFB 0.022701 秒，总耗时 0.023968 秒
第 5 次：TTFB 0.017219 秒，总耗时 0.018834 秒
后续 5 次请求均稳定在约 0.02 秒。
页面末尾也出现了 W3 Total Cache 标记：
使用对象缓存 Redis
使用页面缓存 Disk: Enhanced
Served from: www.shuijingwanwq.com
同时，W3TC 已经重新生成中文首页缓存文件：
_index_slash_ssl.html
_index_slash_ssl.html_gzip
因此可以确认：
中文首页第一次约 14 秒的响应，只是服务器重启后的冷缓存生成，并不是升级后的持续性能异常。
缓存生成完成后，源站首页响应已经恢复到约 20 毫秒。
十三、升级后的实际结果
本次升级最终完成了以下变化：
| 项目 | 升级前 | 升级后 |
|---|---|---|
| CPU | 1 核 | 2 核 |
| 内存 | 2 GiB | 4 GiB |
| Linux 实际可见内存 | 约 1.8 GiB | 约 3.6 GiB |
| 公网带宽 | 2 Mbps | 2 Mbps |
| 实际补差价 | — | 441.03 元 |
| Nginx worker | 1 | 2 |
| 中文站 | 正常 | 正常 |
| 英文站 | 正常 | 正常 |
| 后台域名 | 正常 | 正常 |
| Redis Object Cache | 正常 | 正常 |
| W3TC Page Cache | 正常 | 正常 |
升级完成后，没有立即调整：
- W3TC 预缓存范围；
- EdgeOne 精准速率限制；
- Nginx 限速规则；
- PHP-FPM 参数；
- Redis 最大内存；
- CDN 缓存策略。
这样可以避免硬件升级与软件配置修改同时发生，导致后续无法判断究竟是哪一项变化产生了效果。
十四、硬件升级不等于抓取问题已经消失
这次升级解决的是服务器资源余量不足的问题，并不意味着自动化抓取已经消失。
如果以后再次出现：
- 大量 EdgeOne MISS；
- 集中访问文章、分类和标签页；
- 分布式异常路径扫描；
- 单个客户端持续遍历大量 HTML 页面；
源站仍然可能产生明显负载。
CDN 防护、缓存策略和源站限速依然有价值。
但在服务器已经长期运行于 1 核 2 GiB、CPU 又频繁达到 100% 的情况下，仅靠继续叠加缓存和规则来压榨单核资源，已经不是最合适的方案。
这次升级的真正意义是：
先让服务器拥有基本的并发和内存余量，再继续判断哪些缓存、防护和软件优化真正值得投入。
十五、下一步：开始评估软件栈升级
硬件升级完成后，我又对服务器软件栈进行了盘点。
当前主要版本包括：
Alibaba Cloud Linux 3
Nginx 1.24.0
PHP 8.1.19
Redis 7.0.11
WordPress 7.0.2
PHP-FPM 当前使用：
pm = ondemand
pm.max_children = 7
OPcache 当前分配：
opcache.memory_consumption = 128M
opcache.max_accelerated_files = 100000
硬件资源增加以后，下一阶段将重点评估：
- PHP 是否应该升级；
- 如何在不破坏现有 WordPress、多语言和缓存环境的情况下验证新 PHP；
- 是否需要调整 PHP-FPM；
- OPcache 是否需要增加内存；
- Nginx 和 OpenSSL 是否应该升级；
- Redis 是否还有必要调整；
- 如何为后续 Go Tour 程序站点预留资源。
这一部分涉及的软件兼容性和回滚风险明显高于单纯硬件升配，因此会放到下一篇文章中单独记录。
总结
这次 CPU 告警最初让我怀疑 W3TC 没有预缓存 /page/2/ 等归档分页。
检查后确认，联合 Sitemap 中的 6338 个 URL 确实没有任何 /page/N/，但 EdgeOne 日志进一步显示，真正导致告警的主要因素是：
- 单一客户端持续抓取 1320 个 HTML 页面；
- 其中 1044 次为 EdgeOne MISS；
- 同时存在来自 134 个 IP 的分布式异常路径扫描；
- 请求时间与 CPU 高负载窗口高度重合。
分页未预缓存只是放大因素，而不是唯一原因。
在评估继续配置 CDN、扩大 W3TC 预缓存和增加源站规则的投入后，我最终决定先解决最基础的硬件余量问题。
本次将阿里云 ECS 从：
1 核 2 GiB
升级为：
2 核 4 GiB
实际补差价为 441.03 元。
升级完成后：
- 系统正确识别两个 CPU 核心；
- 可用内存增加到约 3 GiB；
- Nginx、PHP-FPM 和 Redis 正常；
- 中文站、英文站和后台域名全部恢复；
- W3TC 冷缓存生成完成后，中文首页源站响应稳定在约 0.02 秒。
硬件升级并没有取代缓存和防护，但它为现有 WordPress 站点和后续 Go Tour 程序站点提供了更合理的基础资源，也让我不必再依赖不断增加复杂规则来维持一台单核服务器。
WordPress 网站维护、性能优化与博客运营咨询
本站已持续运营超过 10 年，累计发布 1000+ 篇原创技术文章，长期实践 WordPress 网站建设、CDN / Cloudflare 配置、缓存优化、Google SEO、广告变现和多语言网站运营。
如果你的 WordPress 网站遇到访问慢、缓存异常、插件冲突、广告不显示、SEO 基础结构混乱、CDN 配置不确定等问题，可以联系我做一次远程技术排查。
适合以下用户：
✅ 个人博客站长
✅ WordPress 网站运营者
✅ 独立开发者与内容创作者
✅ SaaS 产品官网运营团队
✅ 希望优化网站速度与稳定性的站点
服务内容：
✅ WordPress 速度优化
✅ Cloudflare / CDN / 缓存配置排查
✅ 插件冲突与页面异常排查
✅ AdSense 广告显示问题排查
✅ SEO 基础结构检查
✅ 博客运营与商业化咨询
如需了解方案或交流相关问题，请直接联系我，并注明：WordPress 维护咨询。
联系方式：
Telegram：@shuijingwan
微信：13980074657
邮箱：shuijingwanwq@gmail.com
发表回复