本文记录在jimdb压测过程中遇到的各种小坑,望能够抛砖引玉。

1.压测流量起来后,过了5分钟左右,发现ops突降,大概降了三分之一,然后稳定了下来

大概原因:此种情况,jimdb极有可能某个分片的连接数打满,从而导致分片的cpu达到100%。

调优方案:首先,默认分片连接数为1w,此时可以根据自己的需求,如果自己的docker数量很少,可以调整成2w,反之则3w。

                  然后,看程序中的操作,是不是有pipeline或者mget等操作,如果有,且程序日志中输出了大量的can't get jedis connection from jedis pool,则调整如下线程池,直至找到比较合适的值:

                image

                 如果程序中普通的redis命令操作比较多,则可以调整如下参数,注意maxIdelPerKey不要超过64,否则无效,MaxTotalPerKey太大会造成连接数过多,太少会造成频繁连接,需要根据具体压测情况设置合适的值:

               image

                另外,连接的超时时间等不可设置过长,建议设置如下:

              image

上面参数的调整,需要压测十几次甚至几十次,才能慢慢的调整出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, 其他耗费性能的地方,比如多余的操作,无意义的操作等等

posted on 2019-10-15 14:49  程序诗人  阅读(645)  评论(0编辑  收藏  举报