數棧運維案例：客戶生產服務器CPU負載異常處理

1、問題背景

一天下午，你們都在忙着各自的事情，忽然小組人員都同時收到了短信提醒，覺得是公司發獎金了，非常開心，咋一看「某某客戶服務器cpu使用率100%，請及時處理！」原來是告警短信，同時看到釘釘羣裏發出了大量的告警信息……

2、故障回顧

告警提示」CPU使用率到達98%」 ，打開阿里雲控制檯，經過雲監控發如今下午15:06-16:46左右，雲上機器某四臺集羣服務器cpu使用率波動較大（先降後升），負載太高，網絡流量達到必定峯值就出現降低趨勢，TCP鏈接數先是出現降低趨勢，後面出現上升狀態。現象以下圖：

CPU先降後升使用率狀況：使用率接近100%

系統平均負載先升後降狀況：load超過40

網絡流入流量：網絡帶寬流入流出先降後升

TCP 鏈接數狀況：先升後降

3、問題排查過程

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收到大量的50二、504報錯。

c. 同時在大量的fpm-php重啓時會消耗大量的CPU load， PHP不接受業務請求、不轉發數據，服務器流量直線降低。

4) 處理結論

通過上述分析，最終定位確認是fpm-php子進程數配置過低，同時每一個子進程接受的請求數max_requests設置過小。沒法應對天天的流量高峯。

4、優化建議

根據服務器的CPU/內存配置，適當增長children的數量和max_requests的請求數。以下圖，設置一個比較大的值。

5、優化效果

1）增長fpm-php子進程數以及每一個子進程接收的請求能減小php子進程大量重啓頻次；

2）可緩解業務高峯期對服務形成的壓力，下降業務影響。

6、寫在最後

基於互聯網在線化方式，袋鼠云爲客戶提供雲上網絡和資源規劃、應用架構規劃、性能優化、監控告警、系統健康檢查、業務大促護航、雲上安全運營等全方位的專業運維服務，保障客戶業務系統在雲上穩定運行。

數棧是雲原生—站式數據中臺PaaS，咱們在github和gitee上有一個有趣的開源項目：FlinkX，FlinkX是一個基於Flink的批流統一的數據同步工具，既能夠採集靜態的數據，也能夠採集實時變化的數據，是全域、異構、批流一體的數據同步引擎。你們喜歡的話請給咱們點個star！star！star！

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

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