本文記錄在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， 其他耗費性能的地方，比如多餘的操作，無意義的操作等等