作者：阿 龍
袋鼠雲高級運維工程師
多年應用運維/管理經驗，擅長中間件調優、devops運維;參與主導互聯網醫療、金融等多領域運維工作，曾獨立負責多家企業上雲及雲上運維工作，保障客戶業務穩定運行。
問題背景
一天下午，大家都在忙着各自的事情，突然小組人員都同時收到了短信提醒，以爲是公司發獎金了，很是開心，咋一看“某某客戶服務器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）可緩解業務高峯期對服務造成的壓力，降低業務影響。
寫在最後
基於互聯網在線化方式，袋鼠云爲客戶提供雲上網絡和資源規劃、應用架構規劃、性能優化、監控告警、系統健康檢查、業務大促護航、雲上安全運營等全方位的專業運維服務，保障客戶業務系統在雲上穩定運行。
如果您還想進一步瞭解雲上運維服務，歡迎聯繫袋鼠雲。