请教：关于 PHP -fpm 进程疑似陷入 stuck 的排查

[skvi]

兄弟的公司所 to B 业务
后端大概就是 pg + nignx + php-fpm
偶然会遇到这么个问题很好奇，所以来请教 v 站的大佬们，希望各位大佬不吝赐教！

• fpm 配置

  贴上编译信息 + 运行配置, php.ini是默认配置就不贴了

  # 版本
  PHP 7.4.20 (cli) (built: Nov 29 2021 15:48:06) ( NTS )
  Copyright (c) The PHP Group
  Zend Engine v3.4.0, Copyright (c) Zend Technologies
  

  # 编译信息
  ./configure  --prefix=/usr/local/php7 --exec-prefix=/usr/local/php7 --bindir=/usr/local/php7/bin --sbindir=/usr/local/php7/sbin --includedir=/usr/local/php7/include --libdir=/usr/local/php7/lib/php --mandir=/usr/local/php7/php/man --with-mhash --with-openssl --with-mysqli=shared,mysqlnd --with-pdo-mysql=shared,mysqlnd --enable-gd --with-iconv --with-zlib --with-zip --enable-inline-optimization --disable-debug --disable-rpath --enable-shared --enable-xml --enable-bcmath --enable-shmop --enable-sysvsem --enable-mbregex --enable-mbstring --enable-ftp --enable-pcntl --enable-sockets --with-xmlrpc --enable-soap --without-pear --with-gettext --enable-session --with-curl --with-jpeg --with-freetype --enable-opcache --enable-fpm --with-fpm-user=nginx --with-fpm-group=nginx --without-gdbm --disable-fileinfo PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/
  

  # 配置
    [www]
  user = nginx
  group = nginx
  listen = 127.0.0.1:9000
  pm = dynamic
  pm.max_children = 12
  pm.start_servers = 2
  pm.min_spare_servers = 1
  pm.max_spare_servers = 3
  pm.max_requests = 300
  

• 现象

  这个部分目前我没法定位到问题，目前没有办法复现，使用一段时间后有概率出现，重启fpm可解决
  贴一个案例的现象，因为无法复现，无法贴上排查的屏显
  服务器 10C16G, 主频 3.7GHz

  1. 用户反映每次刷新页面等待的时间是往常的2 倍以上。(证实描述不虚)。
  2. disk、pg、redis、nginx都挺正常，因为每次都是重启fpm能解决，应该排除了。
  3. 内存：free -h显示 avaliable 还有1/3以上。
  4. CPU：top显示平均负载在8-10之间，cpu 占用高的都是fpm进程。

重点就是 cpu 平均负载满了，感觉像是某个进程陷入了死锁，一直在占用 cpu 时间，现在想了解的是：

1. 出现这种情况应该结合什么技能排查(能有具体案例就最好了)？
2. 是否需要后端代码层面植入什么print stack机制？

最后感谢各位路过，赐教的 V 站大佬们！

[Dcynsd]

开启 php-fpm 慢日志看看

[dusu]

碰巧最近 7.4 我们线上也出现了
原因目前确定在 apcu 上限内存满了导致的问题
暂时还没有深究
但能通过出问题 reload fpm 来临时解决

[ygtq]

这也太难猜了吧，要不你装个类似 Tideways 的监控一下？

[kokutou]

先升级 php8 看看

[kphcdr]

1. 慢日志
2. xhprof
3. 排除一下 mysql 和 redis 等服务问题

[aaronnum7]

用 strace -p 命令看下 FPM 进程执行阻塞时的系统调用呢

[BeforeTooLate]

pm.max_children = 12
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
你这么好的配置为啥这里设置才这么点？

[BeforeTooLate]

机器配置还不如你，我都设置静态了。
pm = static
pm.max_requests = 102400
pm.max_children = 200
pm.start_servers = 100
pm.min_spare_servers = 10
pm.max_spare_servers = 250
request_terminate_timeout = 600
request_slowlog_timeout = 10s
slowlog = php-fpm.log.slow

[php0yyds]

楼上说的好像有道理，fpm 进程太少了 8

[skvi]

@Dcynsd #1 我准备给他们开一下慢日志看看，trace 深度建议一般多少呢老哥


@dusu #2 我这边也是 reload 就好，我去了解下你这个问题哈


@ygtq #3 说的是，之前试过装了个`php_fpm_exporter`, prometheus+grafana, 感觉看不到什么东西，我再了解下监控


@kokutou #4 目前升不了呢


@kphcdr #5 mysql 其实没用，pg 和 redis 目前看都是没什么异常，可能我看的不够仔细


@aaronnum7 #6 OKK, 下次出现我试试看


@BeforeTooLate #7 之前开过静态 200 ，也是一样，看起来 stuck 的进程没有保持在 cpu 进程数量附近，所以先改成动态了，加上其实并发并没有那么可怕，我研究下你 #7 的配置参数下次尝试一下


@php0yyds #8 嗯嗯，目前感觉不是大量并发导致的，所以现改小了


多谢各位老哥的建议

[julyclyde]

php 不是有 max requests 么，可以自动重启的呀

[kkk9]

先考虑 sql 慢查询，再考虑 php 的问题

[ygtq]

@skvi prometheus 看不到进程内的呢，除非你自己暴露指标出来，你应该要想办法监控 php 进程内的

[8355]

按照你这个配置就是这种情况，并发量高了就会是 cpu 打满持续夯死。
pm = dynamic
pm.max_children = 12
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 300


按照 8 楼的配置先改一版 之后再慢慢晚上加就行。
pm.max_children = 200
pm.start_servers = 100
我估计 16g 内存我觉得加到 500 以上是没问题的

[skvi]

@julyclyde #11 嗯，好像是超过阈值的应该是会销毁当前进程，起一个新的


@kkk9 #12 嗯嗯，数据库用的 pg ，装了 contrib 扩展，记录了 pg_stat_statement, 确实找到了很多意想不到的慢查询，但是记录的时间和开始卡的时间不太对的上


@ygtq #12 老哥有什么关键字吗？我去学习一下



@8355 #14 切换成这个配置前是 static/max 200/start 100, 后面我在找样本配置看看~~

[devopsdogdog]

1. 进程确实太少了，16g,按我的经验是 200 个左右，是否这块问题，可以通过 php-fpm 日志确认，如果有相关 提示
2.避免内存溢出等问题 pm.max_requests 确实要设置 不宜过大过小
3. php-fpm 我是建议以 socket 方式进行交互， 假设没有网络方面的调优，端口占用也会出现类似问题
4. nginx 和 php-fpm 均开启日志，检查是卡 nginx 还是 php-fpm 上，upstream 的时间占用
5.关闭缓存或者一些奇怪的扩展。
6.检查对应时段是否有被 扫描漏洞，导致负载流量增大。
7. 楼上说的 apm 手段 和 strace 都对
8. 以前遇过的奇怪问题导致 ssl oscp 被墙
9. 确保 数据库 redis 等 网络延迟，一般内网没啥问题
10. 某些奇怪的 安全控件也可能导致 比如 OpenRASP 等等
以上均个人经验 仅供参考

[putyy]

1. opencache 开了吗?
2. dynamic 也没问题，但是 start_servers 、max_children 这些明显太小，可以参考网上的参数调整大一些