關於storm程序性能壓測記錄及總結

STORM性能壓測步驟記錄及總結

壓測前的準備

　　 1.明確壓測計劃和方案。

　　　　(1).首先肯定本次壓測的目的是什麼。
　　　　(2).例如是驗證目標工程是否可以達到預約的性能指標，仍是須要經過調整壓測資源的分配，通過屢次壓測比對結果，發現性能瓶頸的所在。
　　　　(3).壓測指標通常來講是根據往年同時段或者最近一次大促峯值的數據量按照必定比例增長後評估得出的。

可能會影響性能幾個因素：
a.    機器數、
b.    worker數、
c.    執行器數（這裏體現爲worker數和執行器的配比）、
d.    接收topic的partition數
e.    程序代碼內部的邏輯複雜度

壓測指標
a.    CUP使用狀況；
b.    內存使用狀況；
c.    最大瞬間處理峯值TPS；
d.    持續峯值TPS（可以持續三分鐘以上的最大值）；
e.    平均TPS；
f.    spout數據下發到每一個partition是否均勻；
g.    網絡IO；

  　　2. 準備好壓測所須要的數據。

　　　　(1)通常來講須要根據壓測指標的tps來準備相應數量的數據，儘可能保證灌入的數據能夠持續處理10分鐘以上，時間過短的話不足以保證數據處理的穩定性。

　　　　(2)肯定數據是否能夠重複灌入。因爲可能須要進行屢次壓測，或者壓測數據不夠的時候，首先要肯定能否重複使用數據，好比須要將第一次接收的數據存入redis或者hbase表中，後面存在去重或者其餘重複數據處理邏輯，那麼使用重複數據就會對壓測結果形成影響。

　　  3.提早報備

進行壓測以前先在羣中知會一下，以避免有其餘人同時在進行別的操做而對壓測結果形成影響。

 　　 4. 對壓測拓撲對象進行分析。

a.肯定拓撲中有多少spout和bolt，搞清楚它們之間的聯繫和處理邏輯，肯定有多少種日誌須要進行壓測，單場景仍是混合場景。

b.對於涉及到數據寫入redis、hbase、hive等，若是存在去重或者其餘重複數據處理邏輯，須要在壓測前將其進行清空處理。

 　　  5.提早打開對應服務器上cpu等監控界面

查看cpu和內存：  /nmon下     ./nmon_x86_64_centos6

 

 若是有專門的監控頁面或工具（如zabbix等）則會更加便捷，可以一站式的監控多項指標。

 

 

壓測步驟

第一步：向kafka灌入數據

注：發送數據以前必定要保證storm UI上的對應拓撲已經殺死或者是Deactive狀態，不然數據發送以後會立刻被消費掉，沒法堆積到大量的數據達到壓測效果。

 

 直接在服務器上向kafka發送數據

此方法須要先將事先準備好的壓測數據上傳至服務器上，使用linux命令進行數據發送。

 

 

注：此方法可能出現灌入數據在分區上分佈不均勻的狀況，酌情使用。

cat /data/testdata/10033593/kafkadata/storm-expose-access/10.246.4* | /home/storm/software/kafka/bin/kafka-console-producer.sh --broker-list "broker地址" --topic storm_expose_access

 

 

第二步：啓動拓撲並記錄監控數據

當灌入數據達到預期達到以前預估的量的時候（保證灌入的數據能夠持續處理10分鐘以上），就能夠開始進行壓測了。

1. 使用拓撲啓動命令啓動拓撲。
2. 打開storm UI界面，進行數據記錄。
3. 若是配置有監控界面，可直接採用讀取監控頁面的數據來進行指標檢測和記錄。

因爲拓撲內部進程徹底啓動須要必定的時間，所以在前幾十秒中，是不進行數據處理的。所以最好從1min後再開始進行記錄。

 

1. Cpu監控

待cpu穩定後，觀察cpu利用率是否在正常範圍內，通常是75%如下。

 

1. 查看拓撲進程分佈

因爲當拓撲分配多個worker的時候，拓撲進程可能隨機分佈到storm UI上面的幾個服務器上，所以須要肯定哪幾臺。

(1)     到storm UI上面查看集羣所在的服務器

(2)     分別到這幾臺服務器上查看目標拓撲的進程號，查詢不到時表示目標拓撲在該服務器上沒有分配進程

查詢命令：  jps –m （或jps –m | grep 拓撲名）

下圖中24922 即爲dfp_sa_log在該臺服務器上的進程號（一臺服務器上能夠有多個）

 

 

1. 查看內存FullGC次數

根據年老代分區的內存變化狀況判斷JVM是否進行FullGC，記錄內存在監控時間段內的FullGC次數。
應該儘量減小Full GC的次數。在對JVM調優的過程當中，很大一部分工做就是對於FullGC的調節

根據上面的方法獲得的目標拓撲的進程號，能夠查看該進程在當前服務器上的FullGC次數。

查詢命令：jstat -gcutil  +進程號

 

 

第三步：根據監控數據進行分析調整

1．  Tps

選擇兩個時間點記錄的數據量，取差值除以時間差，可得出tps。儘可能選取時間間隔較長的進行計算，這樣得出的結果屬於系統穩定以後的數據，通常比較接近真實狀況。

（1）當計算得出的tps跟預期指標相差不大時，說明當前系統能夠知足性能要求。將壓測過程當中的數據記錄下來整理成文檔便可。

（2）當監控到的tps與預期指標相差甚遠的時候，就須要對壓測過程當中可能形成tps上不去的緣由進行定位分析了。

 i.查看壓測過程當中拓撲中各個spout和bolt對應的capacity值，若是很是接近於1，或者已經超過1，則說明該spout/bolt已經達處處理極限。此時可對其分配幾個excutor再壓壓看

 ii. Spout的執行器數太少。當spout分配的執行器數小於topic分區數的時候，可能會形成接收到的數據不能及時下發給處理單元，形成tps太低，能夠增長執行器數（excutor）數等於分區數在進行觀察

 iii.Topic分區影響，當tps相對於壓測指標太低，同時各個bolt的capacity值都沒有達處處理極限時，多是topic分區較少從而入口接收數據的能力達不到形成的。可建議後期增長topic的分區數。

 iv. Redis讀取/寫入影響，若是邏輯中存在redis讀取或者寫入操做的時候，可能也會對tps形成影響

 v.邏輯過重致使，如關聯mysql維表或者hbase

vi.外部rsf接口影響

 

2．  Cpu

待cpu穩定後，觀察cpu利用率，若是在75%如下則表示正常

若是CPU利用率太高，可使用top命令查看當前佔用率較高的是哪些進程，具體想要分析出cpu高的問題還須要其餘手段。

 

3．  內存FullGC

若是內存FullGC過於頻繁，則說明該拓撲處理過程當中內存消耗過大，短期內就須要清空一下內存，須要進行優化；或者也可能跟應用的邏輯和分配的資源有關。

經過jmap dump了jvm的堆內存，用visualvm查看dump出來的文件，進行進一步的分析調優。

 

通常來講，測試環境與實際生產環境上的資源配置相差較大，所以咱們在測試環境上得出的結果通常與生產仍是有必定差別。這可能就須要咱們經過按照必定的比例調整測試環境上的配置資源數，分別得出分配不一樣資源時的結果，而後再根據這些結果進行線性估算得出在生產上可能須要的資源數，壓測結果可供調整生產環境時進行參考。