共计 1290 个字符，预计需要花费 4 分钟才能阅读完成。
本文整顿自：袋鼠云技术荟 | 某客户生产服务器 CPU 负载异样解决
数栈是云原生—站式数据中台 PaaS，咱们在 github 和 gitee 上有一个乏味的开源我的项目：FlinkX，FlinkX 是一个基于 Flink 的批流对立的数据同步工具，既能够采集动态的数据，也能够采集实时变动的数据，是全域、异构、批流一体的数据同步引擎。大家喜爱的话请给咱们点个 star！star！star！
github 开源我的项目：https://github.com/DTStack/fl…
gitee 开源我的项目：https://gitee.com/dtstack_dev…
一、问题背景
一天下午，大家都在忙着各自的事件，忽然小组人员都同时收到了短信揭示，认为是公司发奖金了，很是开心，咋一看“某某客户服务器 cpu 使用率 100%，请及时处理！”原来是告警短信，同时看到钉钉群里收回了大量的告警信息……
二、故障回顾
告警提醒”CPU 使用率达到 98%”，关上阿里云控制台，通过云监控发现在下午 15:06-16:46 左右，云上机器某四台集群服务器 cpu 使用率稳定较大（先降后升），负载过高，网络流量达到肯定峰值就呈现降落趋势，TCP 连接数先是呈现降落趋势，前面呈现回升状态。景象如下图：
CPU 先降后升使用率状况：使用率靠近 100%
零碎均匀负载先升后降状况：load 超过 40
网络流入流量：网络带宽流入流出先降后升
TCP 连接数状况：先升后降
三、问题排查过程
1) nginx 日志排查
查看 nginx15:06-16:46 时间段的日志发现申请订单接口响应工夫较长，超过 30s。如下图：
2) 查看 fpm-php 日志
查看 fpm-php 日志，在 15:06-16:46 这个时间段中，fpm-php 子过程呈现大量重启，如下图：
同时，nginx 谬误日志中发现较多的 502,504 状态码，如下图：
Nginx 502 状态码：
Nginx 504 状态码：
3) 问题定位剖析
a. 从 fpm-php 对应的日志里发现大量的 fpm-php 子过程重启, 起因是每个子过程承受的申请数达到设定值。
b. 在大量的 fpm-php 子过程重启过程中，如果有大量申请进来是无奈响应的，所以 Nginx 收到大量的 502、504 报错。
c. 同时在大量的 fpm-php 重启时会耗费大量的 CPU load，PHP 不承受业务申请、不转发数据，服务器流量直线降落。
4) 解决论断
通过上述剖析，最终定位确认是 fpm-php 子过程数配置太低，同时每个子过程承受的申请数 max_requests 设置太小。无奈应答每天的流量顶峰。
四、优化倡议
依据服务器的 CPU/ 内存配置，适当减少 children 的数量和 max_requests 的申请数。如下图，设置一个比拟大的值。
五、优化成果
1）减少 fpm-php 子过程数以及每个子过程接管的申请能缩小 php 子过程大量重启频次；
2）可缓解业务高峰期对服务造成的压力，升高业务影响。
六、写在最初
基于互联网在线化形式，袋鼠云为客户提供云上网络和资源布局、利用架构布局、性能优化、监控告警、零碎健康检查、业务大促护航、云上平安经营等全方位的业余运维服务，保障客户业务零碎在云上稳固运行。
