一、業務背景+系統架構

本次場景為kafka+storm+redis+hbase，通過kafka的數據，進入storm的spout組件接收，轉由storm的Bolt節點進行業務邏輯處理，最後再推送進kafka。

表數據相關的邏輯為：查詢Hbase表數據，首次查詢會寫入redis和storm cache，再次查詢，會直接從redis或cache中取值。

storm應用：

二、性能測試場景

1.數據：json類型的用戶偏好數據700萬

2.灌入方式：java腳本

3.hbase表:生產全量數據導入

4.storm集群：5臺 （Nimbus+sup01+sup02+sup03+sup04）

三、性能過程截圖

三分鐘時處理數據量:

storm響應時間（不包含kafka延時）

十三分鐘處理數據量：

從stormUI接口估算出的TPS大約為970左右，遠沒有達到我們業務要求。

四、性能瓶頸分析：

1、直接查看storm應用服務器的情況：

發現 cpu從20%直接到80%

CPU資源顯然在user態消耗的更多，判斷為用戶類進程占用的cpu時間片更多。

2、我們按消耗cpu資源的大小對進程進行排序，抓出最大的進程號16889,然後打印進程下面的線程：

命令：ps -mp pid -o THREAD,tid,time

3.挑出占用cpu時間最高的線程，打印線程棧信息，註意線程id（tid）必須轉化成16進制

命令：printf "%x\n" tid

jstack pid |grep tid -A 30

此處不逐一舉例線程信息，Niubus主機和其他從機都需選取一些線程進行打印，發現耗時長的線程大部分都處於Blocked狀態，線程狀態為執行getcontentmodelscore方法。

檢查getcontentmodelscore這部分代碼：

發現這部分代碼邏輯為從Hbase中獲取得分數據和推薦商品數據，判斷為hbase性能不佳引起的性能低下，由於PRE環境HBASE條件有限，沒有監聽端口，也無權限進行配置優化，此問題暫時沒有進一步解決方案。

五、第二種排查方案：

由於stormUI提供了可視化的界面，我們可以點開處理時間長的bolt下找到對應的端口號：

在host一欄查到對應的機器地址，通過Jps -m |grep 命令找到對應的進程號，此方法適用於多個業務系統公用一個集群，需要快速定位Pid的時候。

六、附redis監控：

在redis工具中敲入info,查看連接數和使用內存。

由於redis是在內存中運行，不需要考慮命中率；redis單線程運行，如果redis查得慢的話基本可能是一次獲取的數據太多了或者程序邏輯不對，不需要考慮慢查詢。對於redis，只要不一次獲取太多的Key-value，基本不會出現性能問題。

七、strorm worker executor配置問題：

storm中worker代表了進程，比如配置10個worker,5臺機器，每個機器會均衡分配2個worker,executor代表線程數，對於每個Bolt，spout節點都可增大減小線程數，達到最佳的處理數據效率。

在本次壓測時，10個worker配置了100個線程數，發現性能遠不如10個worker配置60個線程，對於kafka，我們知道，一個kafka分區只需對應一個線程，多配置的線程也會處於閑置狀態，但並沒出現由於多配置線程兒造成的性能降低。而對於storm，對於多配置的線程，反而出現了性能的嚴重降低。此問題暫時未知道具體原因。

TPS低，CPU高--記一次storm壓測問題排查過程