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， 其余耗费性能的地方，好比多余的操做，无心义的操做等等