网站卡顿怎么排查？PHP高并发优化技巧

PHP-FPM卡顿主因是子进程耗尽而非代码问题，需检查active processes是否达max_children、验证OPcache是否生效、排查N+1查询及Xdebug隐性加载。

看一眼就知道是不是PHP-FPM卡住了

很多“网站卡顿”其实根本不是代码问题，而是 PHP-FPM 子进程全在排队等处理——你刷新页面要等 3 秒以上，top 里却看不到 PHP 进程占 CPU，反而 nginx 的 worker 进程大量处于 sleeping 状态，这就是典型 FPM 响应不过来。

• 立刻执行：sudo systemctl status php-fpm 或 ps aux | grep 'php-fpm:'，看活跃子进程数是否接近 pm.max_children
• 查请求堆积：curl -s http://127.0.0.1/status?full | grep 'processes$'（需开启 pm.status_path）
• 如果 active processes 长期等于 max children，且 slow requests 持续增长，说明 FPM 池已满，必须调参或查慢脚本

别急着加机器——90% 的情况是某个接口死循环、没设超时的 cURL、或数据库锁表，导致一个请求卡住整个 worker。

用 opcache_get_status() 两秒确认字节码缓存是否真在干活

很多人以为开了 opcache.enable=1 就万事大吉，但实际中常因配置错位或缓存击穿导致 OPcache 形同虚设。最直接的验证方式不是看 phpinfo，而是调用函数实时查状态。

• 写个临时脚本：

• 关键看 num_cached_scripts：新部署后首次访问应快速上升；若长期为 0 或只缓存个位数文件，检查 opcache.restrict_api 是否误配，或 opcache.validate_timestamps=0 在开发环境没关（导致改完代码不生效还误以为缓存失效）
• 注意 opcache.max_accelerated_files：设太小（如默认 2000）会导致频繁淘汰，尤其 Composer 自动加载文件多的项目，建议至少设为 20000

数据库 N+1 查询，slow_query_log 可能根本抓不到

MySQL 慢日志只记录单条 SQL 超时，但 N+1 是 100 个 20ms 的查询连发——总耗时 2 秒，每个都躲过 long_query_time=1，结果页面卡死，日志却干干净净。

• 真正有效的办法：在 PHP 层埋点统计查询次数。Laravel 用户可开 DB::enableQueryLog()；原生 PDO 可封装 query() 方法，在全局记录 $this->queryCount++
• 上线前必做：在关键页面末尾加一行：
  ，肉眼一扫就知道有没有异常（比如首页打出 127 次查询）
• 修复时不光加索引——更关键的是把循环内 SELECT * FROM posts WHERE user_id = ? 改成一次 SELECT * FROM posts WHERE user_id IN (1,2,3...)，再用 PHP 关联组装

别让 Xdebug 在生产环境偷偷吃掉 300% 的响应时间

很多团队说“我们没开 Xdebug”，但检查 php --ini 会发现 xdebug.so 仍被加载，只是 xdebug.mode 设成了 off——这依然会让每次请求多花 50~200ms 初始化调试器上下文。

• 终极判断命令：php -m | grep xdebug，只要输出非空，Xdebug 就在加载；要彻底禁用，必须注释掉 zend_extension=xdebug.so 这行
• 开发机也别无脑开全功能：把 xdebug.mode=debug,develop 改成 xdebug.mode=debug，并确保 xdebug.start_with_request=trigger，否则每次请求都在扫描断点
• 一个容易被忽略的坑：xdebug.log 如果指向磁盘文件（尤其 NFS 或低速盘），高并发下 I/O 会直接拖垮整个 PHP-FPM 池

性能排查最怕“以为修好了”，实际上只是把症状压下去了。比如调大 pm.max_children 暂时缓解排队，但那个卡住的慢查询还在——下次流量高峰它会立刻回来。真正的快，是让每个请求从进来到返回，路径清晰、无盲区、可度量。