身为站长, 最畏惧的并非网站没人浏览, 而是出现“有人前来就崩溃”的状况。一旦并发量提高, 服务器径直报出504 Gateway Timeout错误, 然而单人进行测试时却觉得顺滑冰爽这般奇特问题 , 很可能是架构层面的资源竞争所引发的。今日我们不讲玄学虚夸之词, 唯独讲述具体的排查途径以及能够重复使用的修复代码。

一、问题根源：谁在排队？

504超时的实质是, 上游服务器（Nginx/Apache）等待后端处理出现超时情况。在并发的时候出现了问题, 这表明请求在里面排队, 并且超过了默认的超时时间（一般是60秒）。

三个最常见瓶颈：

PHP - FPM进程数量处于不足的状态, 当请求来临的时候, 这些进程被整体占满无空闲, 后续到来的请求只能依次排队去等待。

数据库连接池被充满, 众多查询一同涌入, 连接池出现溢出状况, 查询陷入等待且超时。

外部的API或者Redis出现阻塞问题, 存在某个慢查询, 或者被人锁住了, 导致后续的请求全部都被卡住了。

二、三步排查法（附命令）

1. 检查PHP-FPM进程状态

# 查看当前活动进程数
ps aux | grep php-fpm | wc -l
# 查看进程空闲状态
pmap -x $(pidof php-fpm) | head -20

要是活跃进程的数量, 接近于 pm.max_children 所设定的数值, 那就表明进程池已经满了。

修复的方案是, 加以调整, 针对 /etc/php//fpm/pool.d/www.conf进行这样的操作。

pm = dynamic
pm.max_children = 50          # 根据内存调整，1G内存建议30-50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500         # 防止内存泄漏

重设之后再度启动PHP-FPM: 运用systemctl重启php-fpm。改成逗号, 把“, ”换成“: ”使句末有标点符合要求。

2. 检查数据库连接数

SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Threads_connected';

要是 Threads_connected 朝着 max_connections 趋近, 马上进行扩容举措, 或者把连接池的上限予以增添哦。

修复方案：在 my.cnf 中调整

max_connections = 200
wait_timeout = 300
interactive_timeout = 300

3. 检查是否有慢查询阻塞

SHOW FULL PROCESSLIST;

着重去关注, 处于Waiting for table lock状态, 且Time值大的情况, 也要关注处于Sending data状态, 且Time值大的情形。

对于高频查询字段, 采取的修复方案是: 添加索引, 或者运用 EXPLAIN 来分析查询计划。

三、临时应急：调高Nginx超时

如果问题出在网络抖动或后端偶发慢响应，可以临时放宽超时。

location ~ \.php$ {
    fastcgi_read_timeout 120s;
    proxy_read_timeout 120s;
}

但注意，这只是“止痛药”，不是“药方”。

不是“访问的人数众多”造成并发 504 的根源, 而是“资源竞争致使排队超时”才是并发 504 的根源, 将并发 504 的根源一句话总结出来就是如此。优先对 PHP - FPM 进程数以及数据库连接池展开检查 , 90%的疑难问题都能够在这个地方被解决。

如果你想直接测试这些配置的效果，可以到 否玩代码编辑 网站模拟并发请求：https://www.fouwan.com