[實戰] PHP WorkerMan CPU太高致使的業務延時 排查與優化

WorkerMan介紹

官方項目地址：https://www.workerman.net/features

workerman是一個高性能的PHP socket 服務器框架，workerman基於PHP多進程以及libevent事件輪詢庫，
PHP開發者只要實現一兩個接口，即可以開發出本身的網絡應用，例如Rpc服務、聊天室服務器、手機遊戲服務器等。

workerman的目標是讓PHP開發者更容易的開發出基於socket的高性能的應用服務，
而不用去了解PHP socket以及PHP多進程細節。 

workerman自己是一個PHP多進程服務器框架，具備PHP進程管理以及socket通訊的模塊，
因此不依賴php-fpm、nginx或者apache等這些容器即可以獨立運行。

業務場景

終端機經過互聯網走TCP協議經過NGinx反向代理服務器與線上PHP服務器中的WorkerMan進程通信，屬於長鏈接，對實時性要求較高。

系統與應用環境

# uname -r
3.10.0-693.11.1.el7.x86_64

# cat /etc/centos-release
CentOS Linux release 7.4

Workerman   version:3.5.5
PHP         version:5.6.36

# php -m
[PHP Modules]

event
phpiredis
這裏只列出了高併發相關的已經加載的模塊

現象

終端機經過掃碼形式進行打開，發如今掃碼後會有大約5-10秒的延時纔開始下一流程工做。體驗變得很糟糕。

排查過程

由於終端機是與Workerman通信的，所以，直接查看此應用的狀況

Workerman 實時鏈接狀況

經過htop指令，發現Workerman佔用的CPU核心(CPU 1)仍是特別高的。

按理說，剛增長的CPU核數，應該能夠改善CPU高的問題啊。不過呢，仔細觀察，本機的業務分爲傳統PHP類和Workerman,按照官方的手冊講到的，Workerman並不跟php-fpm有太多的影響。實際中確實也反映出來了，跟Workerman鏈接的終端會延時，同一時刻，相關的PHP訪問卻不受影響，除非整個服務器的CPU都超高。

開始把問題瞄向了磁盤IO和網絡IO瓶頸上面，不過當我調出相關的性能監控的時候，發現並非這個緣由。雖說有寫日誌的行爲，在SSD磁盤的上面仍是沒有壓力的。

隨即尋求Workman官方技術羣主幫助，經過狀態頁和相關監控系統指令，產生了疑問：
業務有啥耗費cpu的操做麼？請求量不大怎麼cpu這麼高？

經過mpstat查看每一個核的CPU情況，發現運行Workerman的CPU核心確實存在CPU高的現象

因而，當即使用strace命令跟蹤下狀況

strace命令是一個集診斷、調試、統計與一體的工具，咱們可使用strace對應用的系統調用和信號傳遞的跟蹤結果來對應用進行分析，以達到解決問題或者是瞭解應用工做過程的目的。

strace -ttp 進程號

其中每一行是一個系統調用，從這個信息中咱們很容易看到進程在作一些什麼事情，能夠定位到進程卡在哪裏，卡在鏈接仍是讀取網絡數據等

在與終端機發送消息是一去一回，有一個FD=10的操做至關的頻繁，刷新的很是快。

使用lsof跟蹤此進程

# lsof -p 24373 | grep 10

能夠看出，這個就是本機向redis主機通信(沒有采用默認的6379端口號)

會不會是redis的瓶頸引起的？

再次確認了所鏈接的Redis配置以下

內網每秒發包數不到2000 pps,遠遠沒達到極限的5萬pps

事實證實，並非由於Redis服務的瓶頸。

定位問題

與開發人員進行溝通，得知這是終端設備查詢的操做。並且訪問的數據都相同，這樣瘋狂訪問redis,致使了cpu利用率太高，就容易延遲了。

至此，基本定位出問題了，剩下的就交給開發進行優化了。

解決方案

1.減小查詢返回的量

2.將每次一種狀態生成的redis操做的頻繁指令合併到多個指令數據集合操做一條redis操做。

3.將遍歷方法變成校對產生變化的值，從而減小量級。

取值時間 9:00-21:00

WorkerMan主機平均負載

優化前

優化後

WorkerMan進程CPU使用率

優化前

優化後

redis主機網絡流入流出數據包數(pps)

優化前

優化後 ，由於是經過2次優化處理，因此這張圖能很明顯的看出對比變化

目前線上業務延時已經恢復正常，優化還在進行中，重點將會是WorkerMan進程的CPU優化，不知各位看官有什麼多進程處理的好方案呢？