V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
skvi
V2EX  ›  PHP

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

  •  
  •   skvi · 2023-08-31 10:57:32 +08:00 · 1777 次点击
    这是一个创建于 458 天前的主题,其中的信息可能已经有所发展或是发生改变。

    兄弟的公司所 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. diskpgredisnginx都挺正常,因为每次都是重启fpm能解决,应该排除了。
      3. 内存:free -h显示 avaliable 还有1/3以上。
      4. CPU:top显示平均负载在8-10之间,cpu 占用高的都是fpm进程。

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

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

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

    17 条回复    2023-09-12 14:17:02 +08:00
    Dcynsd
        1
    Dcynsd  
       2023-08-31 11:05:13 +08:00
    开启 php-fpm 慢日志看看
    dusu
        2
    dusu  
       2023-08-31 11:07:42 +08:00 via iPhone
    碰巧最近 7.4 我们线上也出现了
    原因目前确定在 apcu 上限内存满了导致的问题
    暂时还没有深究
    但能通过出问题 reload fpm 来临时解决
    ygtq
        3
    ygtq  
       2023-08-31 11:08:46 +08:00
    这也太难猜了吧,要不你装个类似 Tideways 的监控一下?
    kokutou
        4
    kokutou  
       2023-08-31 11:11:57 +08:00 via Android
    先升级 php8 看看
    kphcdr
        5
    kphcdr  
       2023-08-31 11:24:08 +08:00
    1. 慢日志
    2. xhprof
    3. 排除一下 mysql 和 redis 等服务问题
    aaronnum7
        6
    aaronnum7  
       2023-08-31 11:25:57 +08:00
    用 strace -p 命令看下 FPM 进程执行阻塞时的系统调用呢
    BeforeTooLate
        7
    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
        8
    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
        9
    php0yyds  
       2023-08-31 11:32:00 +08:00
    楼上说的好像有道理,fpm 进程太少了 8
    skvi
        10
    skvi  
    OP
       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
        11
    julyclyde  
       2023-08-31 13:08:23 +08:00
    php 不是有 max requests 么,可以自动重启的呀
    kkk9
        12
    kkk9  
       2023-08-31 13:48:15 +08:00
    先考虑 sql 慢查询,再考虑 php 的问题
    ygtq
        13
    ygtq  
       2023-08-31 14:00:04 +08:00
    @skvi prometheus 看不到进程内的呢,除非你自己暴露指标出来,你应该要想办法监控 php 进程内的
    8355
        14
    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
        15
    skvi  
    OP
       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
        16
    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
        17
    putyy  
       2023-09-12 14:17:02 +08:00
    1. opencache 开了吗?
    2. dynamic 也没问题,但是 start_servers 、max_children 这些明显太小,可以参考网上的参数调整大一些
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2684 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 07:27 · PVG 15:27 · LAX 23:27 · JFK 02:27
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.