一次WordPress站点504错误的排查与优化实录

由永夜 · 2026/06/02

浏览量： 6

背景

我的站点 www.shuijingwanwq.com 是一个基于 WordPress 的内容站，网页数量约 2 万篇，日均访问量逐步上升。服务器采用阿里云 ECS（1核2GB），Web环境使用 OneinStack（Nginx + PHP-FPM + Redis + 阿里云 RDS MySQL）。网站一直运行平稳，直到某天晚上突然出现大面积 504 Gateway Time-out，后台尤其缓慢，几乎无法操作。其实前段时间也遇见过同样的问题，也做了初步的优化：我的个人博客，今天突然响应 504 的排查解决流程

问题现象

前端页面间歇性打不开，刷新偶有 504 错误；
后台 /wp-admin/admin.php 加载极慢，时常超时；
阿里云控制台显示 ECS CPU 使用率持续 100%；
RDS 错误日志中出现大量 Aborted connection 和 Got an error reading communication packets。

排查过程

1. 服务器基础状态检查

登录服务器，执行 top 发现负载高达 7.09（1核机器），%us 超过 80%，多个 php-fpm 进程占用 CPU 在 13%~20% 之间，redis-server 也占用 13% 左右，而 %id 为 0。内存剩余约 150MB，Swap 使用极少。iostat 显示磁盘 %util 很低，排除磁盘 I/O 瓶颈。如图1

2. PHP-FPM 配置分析

查看 /usr/local/php/etc/php-fpm.conf，发现几个严重问题：

慢日志被重复定义且最后被覆盖为 0：request_slowlog_timeout 出现了两次，第一次 3s，后面又设为 0，导致慢日志从未生效。


;;;;;;;;;;;;;;;;;;;;;
; FPM Configuration ;
;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;
; Global Options ;
;;;;;;;;;;;;;;;;;;

[global]
pid = run/php-fpm.pid
error_log = log/php-fpm.log
log_level = warning

emergency_restart_threshold = 30
emergency_restart_interval = 60s
process_control_timeout = 5s
daemonize = yes

;;;;;;;;;;;;;;;;;;;;
; Pool Definitions ;
;;;;;;;;;;;;;;;;;;;;

[www]
listen = /dev/shm/php-cgi.sock
listen.backlog = -1
listen.allowed_clients = 127.0.0.1
listen.owner = www
listen.group = www
listen.mode = 0666
user = www
group = www

pm = ondemand
pm.max_children = 5
request_slowlog_timeout = 3s
slowlog = /usr/local/php/var/log/slow.log
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 500
pm.process_idle_timeout = 10s
request_terminate_timeout = 120
request_slowlog_timeout = 0

pm.status_path = /php-fpm_status
slowlog = var/log/slow.log
rlimit_files = 51200
rlimit_core = 0

catch_workers_output = yes
;env[HOSTNAME] = iZ23wv7v5ggZ
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp

超时设置不协调：PHP-FPM 的 request_terminate_timeout = 120s，而 Nginx 未设置 fastcgi_read_timeout（默认 60s），导致 PHP 执行超过 60 秒时 Nginx 先返回 504，但 PHP-FPM 仍在执行，浪费资源。

3. Nginx 配置缺失

站点配置文件 /usr/local/nginx/conf/vhost/www.shuijingwanwq.com.conf 中的 PHP 处理部分缺少 fastcgi_read_timeout，默认 60 秒超时。

4. RDS 错误日志分析

RDS 控制台错误日志出现大量：

Aborted connection ... (Got an error reading communication packets)
Got packets out of order

这表明 PHP 与 MySQL 之间的连接被异常中断，通常是因为 PHP 执行时间过长，超过了 MySQL 的 wait_timeout 或 PHP 进程提前终止。如图3

5. 慢日志为空

无论是 PHP 慢日志（/usr/local/php/var/log/slow.log）还是 RDS 慢查询日志（控制台慢日志明细），均无数据。原因是 PHP 慢日志被关闭，RDS 的 long_query_time 默认 10 秒，当前查询可能耗时 2~5 秒但未被记录。

解决方案

1. 修正 PHP-FPM 配置

采用 ondemand 模式，适合 1 核小内存机器，空闲时释放进程。最终配置如下：如图4

;;;;;;;;;;;;;;;;;;;;;
; FPM Configuration ;
;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;
; Global Options ;
;;;;;;;;;;;;;;;;;;

[global]
pid = run/php-fpm.pid
error_log = log/php-fpm.log
log_level = warning

emergency_restart_threshold = 30
emergency_restart_interval = 60s
process_control_timeout = 5s
daemonize = yes

;;;;;;;;;;;;;;;;;;;;
; Pool Definitions ;
;;;;;;;;;;;;;;;;;;;;

[www]
listen = /dev/shm/php-cgi.sock
listen.backlog = -1
listen.allowed_clients = 127.0.0.1
listen.owner = www
listen.group = www
listen.mode = 0666
user = www
group = www

pm = ondemand
pm.max_children = 5
pm.process_idle_timeout = 10s
pm.max_requests = 500

request_terminate_timeout = 120s
request_slowlog_timeout = 3s
slowlog = /usr/local/php/var/log/slow.log

catch_workers_output = yes
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp

删除了与 ondemand 冲突的 pm.start_servers、pm.min/max_spare_servers。
确保慢日志唯一且生效。

2. Nginx 增加超时

在 PHP 处理 location 中添加：

fastcgi_read_timeout 150s;

使 Nginx 超时时间略大于 PHP-FPM 的 120 秒，避免 Nginx 提前中断。如图5

3. 调整 RDS 慢查询阈值

登录 RDS 控制台 → 参数设置 → 将 long_query_time 从 100 改为 1 秒，以便捕获更多慢 SQL。如图7

4. 重启服务

systemctl restart php-fpm
systemctl restart nginx

结果

调整后网站访问恢复正常，CPU 使用率回落至正常水平，后台响应明显提升。RDS 错误日志中的连接中断大幅减少。尽管 RDS 慢日志仍未发现特别慢的 SQL，但整体瓶颈已基本解除。

后续优化建议

尽管当前已经恢复，但考虑到数据量已达 2 万篇且流量持续增长，1 核 2GB 的配置仍显吃力。以下是后续可采取的优化措施：

✅ 1. 硬件升级（根本性解决）

升级 ECS 配置：至少 2 核 4GB，推荐 4 核 8GB。升级后可将 PHP-FPM 模式改为 dynamic，pm.max_children 调整至 10~15，并发处理能力大幅提升。
RDS 规格提升：如果慢查询增多或连接数经常打满，可考虑升级 RDS 内存或开启只读实例。

✅ 2. 使用 CDN 加速静态资源

阿里云 CDN + OSS 组合：

将站点图片、CSS、JS 等静态文件上传至 OSS，并开启 CDN 加速。
配置 WordPress 插件（如 AliOSS）自动同步媒体库。
效果：减轻 ECS 带宽压力，加快全国各地访问速度。

✅ 3. 页面缓存深度优化

已安装 W3 Total Cache，建议检查：

页面缓存 使用磁盘增强或 Redis。
对象缓存 确认使用 Redis 驱动。
数据库缓存 同样使用 Redis，避免磁盘 I/O。
开启 Opcode 缓存（如 Zend OPcache）。

✅ 4. 数据库专项优化

定期执行 OPTIMIZE TABLE 优化 wp_posts、wp_postmeta 等大表。
为常用查询字段添加索引，例如 post_date、meta_key。
使用 Index WP MySQL For Speed 插件自动分析并添加缺失索引。

✅ 5. 监控与告警

安装阿里云云监控，对 CPU、内存、RDS 连接数设置阈值告警。
编写每天定时脚本，检查 PHP 慢日志和 RDS 慢日志，若发现新慢请求则发送邮件。

✅ 6. 定期清理与维护

清理过期草稿、回收站文章、无用的 postmeta 数据。
禁用或删除不常用的插件，减少后台加载项。
配置 WP-Cron 改用系统 crontab 触发，避免每次访问都检查任务队列。

总结

这次 504 故障的根本原因是 服务器配置与业务规模不匹配，加上 PHP-FPM 参数设置错误，导致 CPU 耗尽、连接中断。通过修正配置、增加超时、开启慢日志，问题得以解决。长期来看，升级硬件和引入 CDN 是必经之路。

希望这篇记录能为遇到类似问题的朋友提供参考。如果你也有 WordPress 高负载优化经验，欢迎交流！

一次WordPress站点504错误的排查与优化实录

您可能还喜欢...

发表回复取消回复

一次WordPress站点504错误的排查与优化实录

WordPress 性能优化手记

解决 WordPress + Polylang 批量处理标签时遇到的 Redis OOM 错误

一次WordPress站点504错误的排查与优化实录

背景

问题现象

排查过程

1. 服务器基础状态检查

2. PHP-FPM 配置分析

3. Nginx 配置缺失

4. RDS 错误日志分析

5. 慢日志为空

解决方案

1. 修正 PHP-FPM 配置

2. Nginx 增加超时

3. 调整 RDS 慢查询阈值

4. 重启服务

结果

后续优化建议

✅ 1. 硬件升级（根本性解决）

✅ 2. 使用 CDN 加速静态资源

✅ 3. 页面缓存深度优化

✅ 4. 数据库专项优化

✅ 5. 监控与告警

✅ 6. 定期清理与维护

总结

您可能还喜欢...

在 Yii 2 框架中实现接口的向后兼容的流程

在 Yii 2.0 中，一张关联表中的一个字段分别被两张表同时关联的实现

发表回复 取消回复

发表回复取消回复