生产环境线程池满问题排查

系统的网关模块出现大量的错误日志：

首先想到的是dubbo的服务端进程是不是出现了假死现象。
于是去生产服务器检查，发现用户目录下已经出现了大量的JStack日志。dubbo可以自动导出线程堆栈日志保留现场问题，可以通过设置"dump.directory"参数来指定Jstack日志的输出路径。未设置则默认输出在用户目录下，并且每10分钟输出一份文件。
顺便检查了一下服务性能，发现cpu和mem等一切正常。
分析JStack日志，可以看到400个dubboServerHander线程都处于等待状态，dump出来的日志全部都是jedis获取连接异常。
查看Jedis源码，当maxWait未设置（默认为-1）且blockWhenExhausted设置为true时，获取jedis连接会采用LinkedBlockingDeque的takeFirst方法，设置了maxWait参数则

		if (blockWhenExhausted) {
                if (p == null) {
                    if (borrowMaxWaitDuration.isNegative()) {
                        p = idleObjects.takeFirst();
                    } else {
                        p = idleObjects.pollFirst(borrowMaxWaitDuration);
                    }
                }
                if (p == null) {
                    throw new NoSuchElementException(appendStats(
                            "Timeout waiting for idle object, borrowMaxWaitDuration=" + borrowMaxWaitDuration));
                }
            } else if (p == null) {
                throw new NoSuchElementException(appendStats("Pool exhausted"));
            }

    public boolean isNegative() {
        return seconds < 0;
    }

 private final LinkedBlockingDeque<PooledObject<T>> idleObjects;

会调用pollFirst方法。两者的区别在于，takeFirst会一直阻塞直到获取连接池中的连接。而pollFirst则会设置一个时间，当超过这个时间则会从阻塞状态恢复。

由此可以猜想到，项目应该是没有设置Jedis的maxTime等参数，导致的dubbo线程在获取jedis的connection时，一直处于阻塞状态导致dubbo的线程池耗尽。debug一下代码，果然如此。

问题到这里并没有结束，必须要找到导致jedis获取不到连接池的根本原因才能从根本上杜绝此问题。
大致统计了一下晚高峰的交易，tps差不多在300左右，而redis的qps大约在1000以上，在这种压力不怎么大的情况下，最可能有两种情况会导致获取连接池要等待。
1.redis阻塞。仔细的检查了一下代码，不存在有导致redis阻塞的代码逻辑，没有keys *、redis锁这些。
2.redis命令执行时间过长。通过slowlog get 命令，发现全部log都是scan操作,而且执行时间都比较久。
由于我们dubbo的provide部署了4台服务,按照1000的qps计算，只要scan命令超过了4x8ms就会产生堵塞。而slowlog里面的scan操作几乎都在32ms以上。
至此，问题总算发现，于是，从以下几个方面进行优化
1.scan命令的count参数由10000改为5000
2.设置jedis的maxTime时间
3.修改maxActive和maxIdle参数，这里，按照最大的qps为20000计算，平均redis执行时间来计算出这两个参数的值。
4.告知运营人员在高峰期尽量避免触发scan的管理操作
优化完成后，观察了一周时间，果然没有再出现任何问题。