【PHP问题定位】php-fpm的idle掉底分析

zhangfaliang 发布于2019-07-01 10:31 / 1759人阅读

摘要：周三晚加上了对阿波罗超时的监控，周四观察上线期间阿波罗超时指标的变化，时间也吻合。月日下午又报了一次警与此同时的阿波罗超时监控这里同时列出机器指标的目的是为了说明，尽管没有报警，但机器的指标变化和是统一的。

顺风车运营研发团队熊浩含

问题现象

线上报警群里时而有php-fpm-idle的零星报警，持续时间很短（几秒甚至一秒），见下图

问题分析

发生故障时，我们可以通过观察相关指标在故障时间的前后异常变化，找出故障原因。常用的指标如下：

cpu_idle

php-fpm-idle

nginx.status.flow

opcachereset

指标截图如下：

io.read

nginx.status

opcachereset

在故障发生时（php-fpm-idle掉底），除了nginx的499明显增多，io增大外，其余性能指标并无明显变化。值得注意的是，故障时间与opcachereset时间高度重合，opcachereset是上线时的操作，会清除服务器上的phpopcache。故有两种可能：

故障单纯是清除opcache导致的，php需要重新解析php文件，耗时增加，php-fpm-idle下降;

上线时进行的某些操作，影响了某些url请求的效率，导致超时(nginx出现大量499)，也引起了php-fpm-idle下降;

nginx_499:部分请求长时间占用了php-fpm进程（死循环或者超时），导致了新请求的排队，php-fpm-idle下降。

cpu-idle:cpu-idle和php-fpm-idle其实并没有直接关系，但会相互影响。当请求增多，php-fpm启动了更多的进程处理请求，自然也会增加cpu的消耗，cpu_idle降低;而当cpu_idle降低时（cpu更忙），php处理请求比平时要花费更多的时间，导致请求堆积，php-fpm-idle下降。

io:磁盘io会直接影响fpm进程读写文件，io过高，导致读写文件慢；同时过高的io也会影响cpu-idle，进而间接影响php-fpm。

日志采集系统对采集的性能指标数据有聚合操作。例如指标A10s采集一次，当天可以按10s的粒度查看数据。但对于历史数据，例如7天前，数据粒度不再是10s,而变成了15分钟，odin对数据做了聚合。这意味着一些”尖峰数据“随着时间推移，其尖峰不再，曲线会变得平滑。

问题定位

查看报警机器的nginx的access.log

取前几处请求的traceid，在业务日志中查看，发现大量的apollo（一个内部服务）请求超时，proc_time时间过长

在看nginx日志的时候发现，499的log中，request_time是以客户端断开连接的时间计算的。例如api的请求超时时间是0.08s，超时后请求方主动断开，此时nginx即打印了499的log（比0.08s稍长）。但实际上php-fpm的处理仍在继续，过了更长的时间后，在trace日志中打印了真正的执行时间（proc_time）。

查到这里，我的猜想是：因为上线操作触发了阿波罗(一个内部服务)的某种异常，导致阿波罗链接在这一瞬间全部超时，引起nginx的大量499，也引起了php-fpm-idle的掉底。

验证这个猜想需要解决以下两个问题：

(一) 上线和阿波罗超时是否有必然的联系？需要多找几个例子验证

(二）既然只要上线就会触发这个问题，为啥不是每台机器都报警，而只有零星的报警？

先看问题（一），结果是振奋人心的，找了几台机器验证，上线时间和业务日志中大量出现”call apollo too long“的时间重合。周三晚加上了对阿波罗超时的监控，周四观察上线期间阿波罗超时指标的变化，时间也吻合。

8月9日下午15：22又报了一次警

与此同时的阿波罗超时监控:

*.16.gz01

.17.gz01

这里同时列出17.gz01机器指标的目的是为了说明，尽管17.gz01没有报警，但17机器的指标变化和16是统一的。

再看问题（二）：我的猜想是，由于故障时间很短（看机器日志只有100ms左右）,而odin最短10s采集一次指标，大部分机器php-fpm-idle掉底的数据并没有被采集到。

结论

上线过程中清除了php的opcache，导致下一时刻的请求到来时，代码中的阿波罗会读取本地配置文件，io增加，而php需要重新解析文件，io进一步增大，耗时增加，导致php-fpm-idle有一瞬间的掉底。

云服务器服务器托管定位问题分析问题的工具 php-fpm 分析问题的具体方法

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/29252.html

【PHP问题定位】2018-07-02 fpm掉底分析

摘要：顺风车运营研发团队黄桃问题现象某机器这段时间出现掉地的报警如图原因分析查看当时的监控，等今天出现两次突降，一次是点左右，一次是左右，查看整周也经常出现突降，如图在分时突然升高也在时出现大量写当时短暂出现降低，之后出现徒顺风车运营研发团队黄桃问题现象某机器这段时间出现cpu-idle掉地的报警如图： showImg(https://segmentfault.com/img/bVb...

Code4App 2019-07-01 10:15 评论0 收藏0
php-fpm进程数管理

摘要：是实现的进程管理器用于替换的大部分附加功能，适用于高负载网站。能够创建的最大子进程数量，它在使用多个配置的进程池的时候，控制全局的子进程数量。同时根据进程池的数量来看一个进程管理器的子进程数量限制。 PHP-FPM 先来了解一些名词概念： CGI是Common Gateway Interface（通用网管协议），用于让交互程序和Web服务器通信的协议。它负责处理URL的请求，启动一个进...

hlcfan 2019-07-01 10:18 评论0 收藏0
PHP-FPM 调优：使用 ‘pm static’ 来最大化你的服务器负载能力

摘要：进程管理器和的相似之处现在，我们要说些偏离主题，但我觉得和调优有关的事情。但是，一旦你有可用的闲置内存，那么把设置成的最大值将减少许多进程管理器所带来的开销。 showImg(https://segmentfault.com/img/remote/1460000016435381);让我们来迅速了解一下怎样设置 PHP-FPM，以便达到高吞吐，低延迟以及稳定的使用 CPU 和内存的完美...

CNZPH 2019-07-01 12:31 评论0 收藏0
PHP超时处理全面总结

摘要：的毫秒级超时也有问题。。中超时实现一初级最简单的超时实现秒级超时思路很简单链接一个后端，然后设置为非阻塞模式，如果没有连接上就一直循环，判断当前时间和超时时间之间的差异。实际处理这个调用的部件在完成后，通过状态通知和回调来通知调用者。概述在PHP开发中工作里非常多使用到超时处理到超时的场合，我说几个场景：异步获取数据如果某个后端数据源获取不成功则跳过，不影响整个页面展现为了保...

I_Am 2019-06-27 10:27 评论0 收藏0
PHP-FPM设置max_chindren、max_requests

摘要：首先，我们关注下的运行方式模式始终保持一个固定数量的子进程，这个数由定义，这种方式很不灵活，也通常不是默认的。指的是每个子进程在处理了多少个请求数量之后就重启。首先，我们关注下 PHP-FPM 的运行方式：pm = static模式：始终保持一个固定数量的子进程，这个数由pm.max_children定义，这种方式很不灵活，也通常不是默认的。优点是不用动态的判断负载情况，提升性能；...

hedge_hog 2019-07-01 10:27 评论0 收藏0