栈是云原生站型数据中级PaaS。我们在github和gitee上有一个有趣的开源项目:FlinkX，这是一个基于FlinkX的统一数据同步工具，既可以采集静态数据，也可以采集实时变化的数据。这是一个全球性的，异构和批处理流集成的数据同步引擎。如果你喜欢，请给我们一颗星星！明星！明星！
Github开源项目:
https://github.com/dtstack/flinkx
Gitee开源项目:
https://gitee.com/dtstack _开发_ 0/Flinkx
一个下午，大家都在忙自己的事情。突然，所有队员同时收到短信提醒，以为公司发奖金了。他们非常高兴。乍一看，“一个客户端服务器的cpu利用率是100%。请及时处理！”原来是报警信息。同时看到钉钉群里发出了很多报警信息...
二、故障回顾提示“cpu利用率达到98%”。打开阿里云控制台。通过云监控，发现下午15:06-16:46左右，云上部分四台集群服务器的CPU利用率波动较大(先降后升)，负载过高。当网络流量达到一定峰值时，呈现下降趋势，TCP连接数先呈现下降趋势，后呈现上升状态。现象如下:
CPU利用率先降后升:利用率接近100%。
平均系统负载先升后降:负载超过40。
网络流入:网络带宽流入流出先降后升。
TCP连接:首先向上，然后向下。
三、问题排查过程1) nginx日志故障排除
查看nginx 15:06-16:46的日志，发现请求订单接口响应时间长于30s。如下图:
2)检查fpm-php日志
查看fpm-php日志，在15:06-16:46期间，大量fpm-php子进程重启，如下图所示:
同时，在nginx错误日志中发现了更多的502，504状态代码，如下图所示:
Ngx502状态代码:
Ngx504状态代码:
3)问题定位分析
A.从fpm-php的相应日志中发现大量的fpm-php子进程被重启，因为每个子进程接受的请求数达到了设定值。
B.在重启大量fpm-php子进程的过程中，如果有大量请求进来，它们无法响应，因此Nginx会收到大量的502和504错误。
C.同时，当大量fpm-php重启时，会消耗大量CPU负载，php不接受业务请求和转发数据，服务器流量骤降。
4)处理结论
经过以上分析，最终的定位确认是fpm-php子进程数量太低，每个子进程接受的请求max_requests数量太少。应付不了每天的交通高峰。
四、优化建议根据服务器的CPU/内存配置，适当增加max_requests的子节点数和请求数。如下图，设置一个比较大的值。
五、优化效果1)增加fpm-php子进程的数量和每个子进程接收的请求可以减少php子进程的重启频率；
2)可以缓解业务高峰时段对服务造成的压力，减少业务影响。
六、写在最后袋鼠云基于互联网的在线方式，为客户提供网络及资源规划、应用架构规划、性能优化、监控报警、系统健康检查、业务推广护航、云上安全运行等全方位的专业运维服务，保障客户业务系统在云上的稳定运行。
