jimdb壓測踩坑記

本文記錄在jimdb壓測過程當中遇到的各類小坑，望可以拋磚引玉。

1.壓測流量起來後，過了5分鐘左右，發現ops突降，大概降了三分之一，而後穩定了下來

大概緣由：此種狀況，jimdb極有可能某個分片的鏈接數打滿，從而致使分片的cpu達到100%。

調優方案：首先，默認分片鏈接數爲1w，此時能夠根據本身的需求，若是本身的docker數量不多，能夠調整成2w，反之則3w。

                  而後，看程序中的操做，是否是有pipeline或者mget等操做，若是有，且程序日誌中輸出了大量的can't get jedis connection from jedis pool，則調整以下線程池，直至找到比較合適的值：

               

                 若是程序中普通的redis命令操做比較多，則能夠調整以下參數，注意maxIdelPerKey不要超過64，不然無效，MaxTotalPerKey太大會形成鏈接數過多，太少會形成頻繁鏈接，須要根據具體壓測狀況設置合適的值：

              

                另外，鏈接的超時時間等不可設置過長，建議設置以下：

             

上面參數的調整，須要壓測十幾回甚至幾十次，才能慢慢的調整出jimdb合理的參數值，合理的表現就是：

好比說第一波壓測，jimdb參數優化前，慢慢起量，併發到5000的時候，jimdb由於某個分片鏈接數和cpu太高，掛了。那麼參數的調優，就能夠以5000併發爲基礎慢慢調整，直至調整出5000併發不會將jimdb分片打掛的狀況。則視爲當前jimdb調整參數合理。更加理想的狀況就是，jimdb參數調整完畢後，你加500甚至1000併發上去，jimdb還能扛得住，這種狀況，則說明jimdb參數調整很是合理。

切忌遇到jimdb分片掛了後，覺得是性能問題，而後更換分片操做，因爲新分片追加上來後，鏈接數都被清理光了，再起壓測，由於壓力反而不會很大，因此反而顯得正常，可是此種狀況下是及其不正常的，極有可能重啓docker集羣后再壓測，依然會掛。

一旦jimdb分片打掛後，從新進行下一波壓得的時候，記得將docker集羣的全部機器重啓一下，以便於清理掉鏈接數，不然的話，直接進行壓測，會頻頻的致使分片數掛掉的狀況。

調整參數後，效果不明顯的話，也建議重啓下docker集羣。

若是不想重啓jimdb集羣的話，jimdb中清理集羣命令也能夠達到釋放鏈接數的目的。

 

2. 壓測流量起來過程當中，有一個點，總體ops爲0

分爲幾種狀況

狀況1，須要檢查程序中是否有jmq生產，而後監控下jmq生產性能，若是壓測過程當中在某個點踩中了jmq生產的tp max點（通常會是2002ms，4002ms左右），會形成當前點ops爲0；

狀況2，須要檢查程序中是否有fullgc產生或者頻繁的younggc（一分鐘超過三四十次），且youggc耗時廣泛超過40ms以上

狀況3，jvm老年代不釋放，好比本地緩存寫成了static，滿了後又沒有過時策略等（參見tomact中session保持）

其餘狀況。。。。。

 

3. 壓測過程當中，感受沒什麼jimdb瓶頸，加docker後方法ops死活上不去或者上去的一點兒不明顯

若是你程序中有jmq生產，在jmq生產性能這塊，若是數據容許丟失，可讓jmq運維給你換成異步刷盤，同時加一些broker，則ops將會有明顯提高

其餘狀況。。。。

 

4. 方法總體tp999不好

狀況1， jmq生產性能或者消費性能

狀況2， jimdb參數設置，能夠參考第一條，經過壓測獲取合理值

狀況3， 垃圾收集器設置，實踐證實，G1垃圾收集器不只能夠用於大於4G的堆內內存上，也能夠用於小於4G的堆內內存上

狀況4， jvm堆內內存設置

狀況5， 其餘耗費性能的地方，好比多餘的操做，無心義的操做等等