Redis性能分析案例二:redis Timeout wait for idle object问题排查

一、业务背景

    公司的业务场景主要是利用Redis来做集群节点间session共享;

二、报错原因

    Timeout wait for idle object意即Redis连接池里面没有空闲连接,没有空闲连接那说明池里面的连接泄漏或者连接始终保留active状态被占用(即Redis是阻塞状态,所有命令阻塞,保持active连接);
Redis性能分析案例二:redis Timeout wait for idle object问题排查_第1张图片
     由于代码上线很久,同时最近没有改动过,所以连接泄漏的情况是可以忽略的;
    那么我们直接排查Redis阻塞的问题;

三、排查过程

1. 确认问题的时间点

        由于我们排查的是历史原因,只能提供查询slowlog、redis.log 、info命令来获取一些信息;所以非常有必要确认问题的发生时间点,由上述截图可知,报错时间点是在17点38分38秒;

2. 查询redis.log

    redis.log日志我们主要查询一些日志报错、RDB信息输出、集群信息等;
    如图,在相关时间附近进行了大量的copy-on-write操作,即出现了大量的Redis内存数据修改操作;
Redis性能分析案例二:redis Timeout wait for idle object问题排查_第2张图片

3.查询redis.conf

        这时我们再查redis.conf 里面查询到的maxmemory是6G,相当于短时间内修改了1/3数据;此处截图未提供;

4. 查询info信息

        确认上一次rbd的fork耗时及时间,耗时不大,最多10几ms,可以忽略这方面的影响;此处截图未提供;

5. 查询slowlog

        查询历史的慢查询,存在以下zrem命令并发执行,且处理的的数据量大
Redis性能分析案例二:redis Timeout wait for idle object问题排查_第3张图片
        个别的del删除对象操作;
Redis性能分析案例二:redis Timeout wait for idle object问题排查_第4张图片
    由于我们排查的时间点是18点以后, 客户环境大部分人员已经下班,所以业务请求并不高,几乎没什么人访问;
    在这种状态下,我们都可以查到arem的删除对象,且存在历史的并发删除的情况;所以zrem在业务并发高的情况下导致问题的可能性极大;

6. 查询当前时间的monitor命令

        基本没有什么业务并发;无 实际参考价值;

四、结论及解决方案

    主要结论由来:
Redis性能分析案例二:redis Timeout wait for idle object问题排查_第5张图片
    处理方案:
        告知相关业务开发,如何导致问题,比如此处是存在并发rem删除大对象,处理上需要:
        1. 规避zrem使用
        2. 减少频率
        3. 减少zrem的对象大小,同时减少频率;

    处理结果:
        由于这个是和session相关的,客户环境当天下午出现了多次,直到服务苦苦支撑到下班时间点;如果问题不及时排查,那么第二天二次出现问题的概率是及其大的;
        当时也给提供的了以下的临时方案:
            停redis,删除清理RDB文件,或者flushall redis,使redis的数据量最小;
        最终在开发的紧急处理下,出了修复包,第二天正常到现在未出现问题;

你可能感兴趣的:(性能,调优,Redis,redis,数据库,nosql)