本文整理自：袋鼠云技術薈 | 某客戶生產服務器CPU負載異常處理

數(shù)棧是云原生—站式數(shù)據(jù)中臺PaaS，我們在github和gitee上有一個有趣的開源項目：FlinkX，F(xiàn)linkX是一個基于Flink的批流統(tǒng)一的數(shù)據(jù)同步工具，既可以采集靜態(tài)的數(shù)據(jù)，也可以采集實時變化的數(shù)據(jù)，是全域、異構、批流一體的數(shù)據(jù)同步引擎。大家喜歡的話請給我們點個star！star！star！

github開源項目：https://github.com/DTStack/flinkx

gitee開源項目：https://gitee.com/dtstack_dev_0/flinkx

一、問題背景

一天下午，大家都在忙著各自的事情，突然小組人員都同時收到了短信提醒，以為是公司發(fā)獎金了，很是開心，咋一看“某某客戶服務器cpu使用率100%，請及時處理！”原來是告警短信，同時看到釘釘群里發(fā)出了大量的告警信息……

二、故障回顧

告警提示”CPU使用率到達98%” ，打開阿里云控制臺，通過云監(jiān)控發(fā)現(xiàn)在下午15:06-16:46左右，云上機器某四臺集群服務器cpu使用率波動較大（先降后升），負載過高，網(wǎng)絡流量達到一定峰值就出現(xiàn)下降趨勢，TCP連接數(shù)先是出現(xiàn)下降趨勢，后面出現(xiàn)上升狀態(tài)。現(xiàn)象如下圖：

CPU先降后升使用率情況：使用率接近100%

系統(tǒng)平均負載先升后降情況：load超過40

網(wǎng)絡流入流量：網(wǎng)絡帶寬流入流出先降后升

TCP 連接數(shù)情況：先升后降

三、問題排查過程

1) nginx 日志排查

查看nginx15:06-16:46時間段的日志發(fā)現(xiàn)請求訂單接口響應時間較長，超過30s。如下圖：

2) 查看fpm-php日志

查看fpm-php日志，在15:06-16:46這個時間段中，fpm-php子進程出現(xiàn)大量重啟，如下圖：

同時，nginx錯誤日志中發(fā)現(xiàn)較多的502,504狀態(tài)碼，如下圖：

Nginx 502 狀態(tài)碼：

Nginx 504 狀態(tài)碼：

3) 問題定位分析

a. 從fpm-php對應的日志里發(fā)現(xiàn)大量的fpm-php子進程重啟,原因是每個子進程接受的請求數(shù)達到設定值。

b. 在大量的fpm-php子進程重啟過程中，如果有大量請求進來是無法響應的，所以Nginx收到大量的502、504報錯。

c. 同時在大量的fpm-php重啟時會消耗大量的CPU load， PHP不接受業(yè)務請求、不轉發(fā)數(shù)據(jù)，服務器流量直線下降。

4) 處理結論

經(jīng)過上述分析，最終定位確認是fpm-php子進程數(shù)配置太低，同時每個子進程接受的請求數(shù)max_requests設置太小。無法應對每天的流量高峰。

四、優(yōu)化建議

根據(jù)服務器的CPU/內存配置，適當增加children的數(shù)量和max_requests的請求數(shù)。如下圖，設置一個比較大的值。

五、優(yōu)化效果

1）增加fpm-php子進程數(shù)以及每個子進程接收的請求能減少php子進程大量重啟頻次；

2）可緩解業(yè)務高峰期對服務造成的壓力，降低業(yè)務影響。

六、寫在最后

基于互聯(lián)網(wǎng)在線化方式，袋鼠云為客戶提供云上網(wǎng)絡和資源規(guī)劃、應用架構規(guī)劃、性能優(yōu)化、監(jiān)控告警、系統(tǒng)健康檢查、業(yè)務大促護航、云上安全運營等全方位的專業(yè)運維服務，保障客戶業(yè)務系統(tǒng)在云上穩(wěn)定運行。