一个使用高并发高线程数 Server 使用异步数据库客户端造成的超时问题

现象

今天在做一个项目时, 将 tomcat 的 maxThreads 加大, 加到了 1024, tomcat 提供的服务主要是做一些运算, 然后插入 redis, 查询 redis, 最后将任务返回给客户端

在做压测时, 同时开了 1000 个线程, 并发发起 http 请求去访问 tomcat 的服务, 结果在第一次访问 tomcat 时出现了一系列的 redis 查询超时, 例如 1000 个并发发起 10W 次请求, 可能头 1W 次请求会有 2000 次左右的 redis 超时造成服务失败, 但是之后就再不会出现 redis 超时的情况.

解决

通过观察 vmstat, 发现在出现超时时, r (运行队列) 特别高, 达到 12~25, 持续时间为 2~3 秒, 这段时间出现了很多 redis 超时. 而以后不出现超时时, r 值都保持在 5 左右. 此时, 通过缩减 tomcat 线程数, 减到 200, 再重新测试, 则没有出现超时.

分析

这是因为我的 redis 客户端是异步客户端, 但是我在使用它的时候是用异步客户端模拟同步客户端执行(调用 future.get()), 客户端内部使用 netty 实现, netty 的工作线程只有 4 或 8 个. 当我们刚启动 tomcat 服务时, 没有预热, 系统性能较差, 此时排队任务多的话, 会让巨大的 tomcat 业务线程(1024个)占据 cpu 的任务队列, 而 netty 工作线程较少, 得不到 cpu 时间执行, 最后造成超时.

这里最大的问题在于在同步的 tomcat 业务代码中使用了异步的 redis 客户端, 因为 tomcat 业务线程数量大, 占据了大量 cpu 时间, 让 redis 客户端线程得不到执行, 最后导致了问题出现.

如果说这里将 tomcat 的业务处理改为异步处理 (使用 servlet 3.0), 那么则可以大量缩减 tomcat 的业务线程, 这样既可以减少业务线程切换, 又可以让 redis 客户端线程得到更多的执行时间.

延伸

抛开使用异步的 redis 客户端不说, 如果使用的是一个传统的同步 db 客户端, 那么 db 客户端的执行线程就是业务线程, 线程的 cpu 时间是均等的, 则不会出现这个超时的问题. 那么应该如何界定何时应该启用多少线程?

当我们的业务线程内有 io 操作, 例如 mysql 的操作时, 如果这个操作很耗时, 例如需要执行 2s, 我们则应该分配更多地线程. 假设此时并发 1000 请求, 而只有 8 个业务线程, 那么这 8 个业务线程只能执行 8 个任务, 而且因为实在等待 mysql 的 io 返回, cpu 此时处于闲置状态, 另外的 992 个请求因为没有线程执行, 只能排队等待. 所以此时如果分配更多的业务线程, 则可以更有效地利用 cpu 资源.

而如果业务处理是 cpu 密集型的, 则应该使用更少的线程. 因为此时 cpu 会处于繁忙状态, 增加更多地线程也不会让线程得到执行时间片, 反而会增加线程切换的开销.

总结

对于我的业务场景, 最好的方式应该是减少业务线程, 并将业务处理使用 servlet 3.0 改为全异步的方式. 原因是因为使用的是异步的 redis 客户端, 它不会让线程处于闲置的等待状态, 这样既能减少线程切换, 又能合理的分配 tomcat 业务线程与 redis 客户端线程的执行时间片.

巴特西

一个使用高并发高线程数 Server 使用异步数据库客户端造成的超时问题

现象

解决

分析

延伸

总结

最新文章

热门文章