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

2023-08-31 10:57:32 +08:00
 skvi

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

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

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

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

1768 次点击
所在节点    PHP
17 条回复
Dcynsd
2023-08-31 11:05:13 +08:00
开启 php-fpm 慢日志看看
dusu
2023-08-31 11:07:42 +08:00
碰巧最近 7.4 我们线上也出现了
原因目前确定在 apcu 上限内存满了导致的问题
暂时还没有深究
但能通过出问题 reload fpm 来临时解决
ygtq
2023-08-31 11:08:46 +08:00
这也太难猜了吧,要不你装个类似 Tideways 的监控一下?
kokutou
2023-08-31 11:11:57 +08:00
先升级 php8 看看
kphcdr
2023-08-31 11:24:08 +08:00
1. 慢日志
2. xhprof
3. 排除一下 mysql 和 redis 等服务问题
aaronnum7
2023-08-31 11:25:57 +08:00
用 strace -p 命令看下 FPM 进程执行阻塞时的系统调用呢
BeforeTooLate
2023-08-31 11:29:34 +08:00
pm.max_children = 12
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
你这么好的配置为啥这里设置才这么点?
BeforeTooLate
2023-08-31 11:31:48 +08:00
机器配置还不如你,我都设置静态了。
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
2023-08-31 11:32:00 +08:00
楼上说的好像有道理,fpm 进程太少了 8
skvi
2023-08-31 12:19:51 +08:00
@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
2023-08-31 13:08:23 +08:00
php 不是有 max requests 么,可以自动重启的呀
kkk9
2023-08-31 13:48:15 +08:00
先考虑 sql 慢查询,再考虑 php 的问题
ygtq
2023-08-31 14:00:04 +08:00
@skvi prometheus 看不到进程内的呢,除非你自己暴露指标出来,你应该要想办法监控 php 进程内的
8355
2023-08-31 14:25:11 +08:00
按照你这个配置就是这种情况,并发量高了就会是 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
2023-08-31 16:50:06 +08:00
@julyclyde #11 嗯,好像是超过阈值的应该是会销毁当前进程,起一个新的


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


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



@8355 #14 切换成这个配置前是 static/max 200/start 100, 后面我在找样本配置看看~~
devopsdogdog
2023-09-01 21:25:07 +08:00
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
2023-09-12 14:17:02 +08:00
1. opencache 开了吗?
2. dynamic 也没问题,但是 start_servers 、max_children 这些明显太小,可以参考网上的参数调整大一些

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/969689

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX