本文记录在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， 其他耗费性能的地方，比如多余的操作，无意义的操作等等