phpMyAdmin并发瓶颈在PHP-FPM进程数,而非Nginx连接数;需调高pm.max_children并配套优化fastcgi_read_timeout、系统文件描述符限制及重启顺序。
直接改 nginx.conf 不能让 phpmyadmin 多并发——它本质是单进程 php 脚本,瓶颈在 php-fpm,nginx 只负责转发。真正起效的调整必须落在 php-fpm 配置和 nginx 与它的协作参数上。
phpMyAdmin 是纯 PHP 实现的 Web 管理界面,所有请求最终都落到 php-fpm 进程处理。即使 Nginx 能扛 10 万连接,若 pm.max_children 设为 5,最多只允许 5 个用户同时执行 SQL 查询或导入导出操作——其余请求会排队或返回 504。
504 Gateway Time-out 或浏览器卡在“正在等待响应”这个值决定了同一时刻能并行处理多少个 PHP 请求。设得太低,用户一多就排队;设太高,又可能耗尽内存。需按服务器实际内存和 phpMyAdmin 平均内存占用估算:
ps aux | grep php-fpm | grep -v grep | awk '{sum+=$6} END {print sum/1024 " MB"}' 查单个 php-fpm 进程平均内存(通常 30–80MB)2048 / 50 ≈ 40
/etc/php/*/fpm/pool.d/www.conf 中修改:pm.max_children = 40
pm.start_servers = 10、pm.min_spare_servers = 5、pm.max_spare_servers = 20
Nginx 本身不处理 PHP,但若转发配置不当,会放大 PHP-FPM 的压力或引入额外超时:
fastcgi_read_timeout 必须大于 phpMyAdmin 最长操作预期(如导入 500MB SQL 可能需 300s)→ 建议设为 600
fastcgi_send_timeout 和 fastcgi_connect_timeout 保持默认或略增(60),避免短连接中断fastcgi_buffer_size 和 fastcgi_buffers 足够大,否则大结果集(如 SELECT * FROM huge_table)会触发 upstream sent too big header 错误 → 推荐:fastcgi_buffer_size 128k;fastcgi_buffers 4 256k
fastcgi_cache:phpMyAdmin 是动态管理界面,缓存会导致 CSRF token 失效、状态错乱哪怕 PHP-FPM 和 Nginx 都配好了,Linux 默认限制仍会掐断高并发:
立即学习“PHP免费学习笔记(深入)”;
worker_rlimit_nofile 在 nginx.conf 全局块中必须 ≥ worker_processes × worker_connections(例如 8 × 10240 = 81920)/etc/security/limits.conf 中要放开 www-data(或运行 php-fpm 的用户)的文件描述符:www-data soft nofile 100000、www-data hard nofile 100000
sysctl -w fs.file-max=2000000 并写入 /etc/sysctl.conf,否则内核层面会拒绝分配句柄sudo systemctl restart php-fpm,再 sudo systemctl restart nginx,否则新 Nginx 可能连不上旧 FPM socket最常出问题的地方不是参数没改,而是改了之后没重启对应服务,或者系统级 ulimit 没同步生效——检查 sudo ss -s | grep "tcp:" 和 sudo cat /proc/$(pgrep php-fpm)/limits | grep "Max open files" 才算真正落地。