问题描述

  • 线上突然出现Dubbo超时调用,时间刚好为Consumer端设置的超时时间。
  • 有好几个不同的接口都报超时了
  • 第1次调用超时,第2次(或第3次)重试调用非常快(正常水平)
  • Dubbo调用超时的情况集中出现了3次,每次都是过一会自动恢复

排查

排查日志

看到调用超时,首先就拿着traceId去服务提供方查日志。

奇怪的是,在服务提供方的业务日志里面,只有正常的调用日志(耗时正常),没有超时调用的日志。

从正常的调用日志里面看,一切都是正常的,看不出所以然。

给人的感觉就是超时那次请求的调用没有达到服务提供方。

此时系统活动情况

通过系统历史监控,我们发现除了gc比平时稍微高一点外(也在正常水位),没有其他的异常;CPU、内存、网络等指标都在正常范围。

查看Dubbo线程活动情况

第2次系统集中超时报警的做的第一件事就是登录到那台服务器查看dubbo线程活动情况:看下能不能找到阻塞在哪一行代码。很遗憾,所有的dubbo线程都没有阻塞,都是正常的WAITING状态。

并没有明显表明阻塞在某段代码,这可难倒我们了:如果没有阻塞的话,为什么dubbo调用方会报超时?继续看代码

该接口是否存在阻塞的代码?

硬着头皮重新看代码每一个分支,突然发现底层的一个方法中有http调用!会不会是这个http调用导致的超时?如果是的话,那么不同的接口调用超时的情况就说的通了,因为上层大部分接口都会调用这个底层方法。

怀揣着激动的心,仔细看了http调用的逻辑:用的是JDK提供的HttpURLConnection,其中只用了HttpURLConnection#getContentLength方法,并且也在finally代码块中将这个连接关闭了。好像也不是这个引起的,起初还以为getContentLength会把文件给下载下来,但是看了接口文档以后发现只会去读头信息中的ContentLength。

    /**
* Returns the value of the {@code content-length} header field.
* <P>
* <B>Note</B>: {@link #getContentLengthLong() getContentLengthLong()}
* should be preferred over this method, since it returns a {@code long}
* instead and is therefore more portable.</P>
*
* @return the content length of the resource that this connection's URL
* references, {@code -1} if the content length is not known,
* or if the content length is greater than Integer.MAX_VALUE.
*/
public int getContentLength() {
long l = getContentLengthLong();
if (l > Integer.MAX_VALUE)
return -1;
return (int) l;
}

代码阻塞的情况可能性也不大,因为重试请求不会超时:如果代码阻塞,那么重试请求大概率也会超时。

数据访问层是否有异常情况

既然代码没有阻塞,那么有没有可能是数据访问层的异常造成的呢?毕竟不止一个接口存在超时的问题,如果是底层数据访问层的异常导致,那么也说得通。

重点排查了mysql,但结果是令人失望的:并没有慢SQL;并且dubbo超时期间,mysql实例的CPU和内存水位都是正常的。

除了mysql、redis实例本身指标正常外,基于上面同样的理由:如果数据访问层有问题,那么重试基本上也会超时。所以数据访问层导致超时的线索也被排除。

有没有可能是Dubbo层面的问题

排查再次陷入僵局,逼迫着我们重新梳理排查思路:

  1. 除了代码阻塞
  2. 除了数据访问层异常
  3. 除了超时请求,其他请求的日志都是正常的

那么还有可能会导致超时呢?会不会是Dubbo本身异常导致的?

此时有一个关键的线索进入我们的视野:超时的那次请求去哪儿了?

在服务提供方的日志里面没有超时请求的的日志,只有重试请求成功的业务日志。太奇怪了,就算超时总的留下日志的吧,日志都不留,欺负我胖虎吗?!

到这里想到超时的请求可能是一个突破口,于是开始看Dubbo的相关的源码和文档。

从官方文档中的服务端调用链一层层往下查

AllChannelHandler源码中看到了令人兴奋的注释:



兴奋之余,为了避免理解偏差,还特地用百度翻译了一下



没错,如果线程池已经满了,那么服务端不会返回,直到客户端超时!这不是正式我们碰到的问题吗?!

并且此时还没有进入业务代码,所以没有打印业务日志,这样就可以解释为什么没有服务提供方没有超时请求的日志了。

别激动,这里明明有返回threadpool is exhausted异常信息,怎么能说没有返回呢?

别急,这是另外一个项目引用的dubbo,版本是2.6.2。

回到出问题的那个项目,查看dubbo版本:2.8.6,查看AllChannelHandler源码:是的在2.8.6版本中,并没有返回这个错误



问题好像找到了,OK,剩下的就是验证了。

验证

准备

  • 将DubboServerHandler线程池的最大线程数调到5
  • 使用Apache Bench进行压测:200请求、并发10个线程

case1:复现问题

  • Dubbo使用2.8.8版本
  • 预期:部分请求超时报错,重试耗时正常
  • 压测结果符合预期:部分接口报错超时,并且重试请求耗时正常

case2:验证猜想

  • Dubbo使用2.6.2版本
  • 预期:部分请求报错线程池耗尽threadpool is exhausted,并且重试大概率也会报该错误
  • 压测结果符合预期

至此,基本判定线上Dubbo调用超时的问题就是因为线程池耗尽引起的。

这个超时问题前前后后查了一周左右,排查过程中试了很多排查方向,为了叙述方便就没有展开。


避坑指南

  1. 合理设置Dubbo线程池大小。默认是200
  2. 合理设置超时时间。如果真出现了Dubbo调用超时的情况,合理的超时时间能够避免服务调用方被打爆
  3. Dubbo接口必须有返回值。从AllChannelHandler#received的源码和注释中可以看到只有有返回值的接口才会返回线程池耗尽的错误信息;其它的情况则不会将错误信息返回给调用方,直到调用方超时。

不可忽视的Dubbo线程池的更多相关文章

  1. 用了很多年Dubbo,连Dubbo线程池监控都不知道,觉得自己很厉害?

    前言 micrometer中自带了很多其他框架的指标信息,可以很方便的通过prometheus进行采集和监控,常用的有JVM的信息,Http请求的信息,Tomcat线程的信息等. 对于一些比较活跃的框 ...

  2. 动态线程池框架 DynamicTp v1.0.6版本发布。还在为Dubbo线程池耗尽烦恼吗?还在为Mq消费积压烦恼吗?

    DynamicTp 简介 DynamicTp 是一个基于配置中心实现的轻量级动态线程池管理工具,主要功能可以总结为 动态调参.通知报警.运行监控.三方包线程池管理等几大类. 经过几个版本迭代,目前最新 ...

  3. dubbo 线程池

    在dubbo调用过程中被调用方有两个线程池:io线程池,业务线程池. 这也是dubbo调优的点. 配置信息: <dubbo:protocol name="dubbo" dis ...

  4. dubbo线程池的拒绝策略

    jdk自带的原生的拒绝策略抛出的异常信息不够详细,而dubbo对拒绝策略进行了改写,抛出的信息更具有参考价值,值得我们借鉴. jdk自带的原生拒绝策略抛出的信息: // ThreadPoolExecu ...

  5. dubbo线程池作用于接口而不是方法

    记一次线上dubbo服务超时和线程池满问题排查 可能调用的接口没问题,但是该服务中的其他接口占用完了线程池,导致调用超时被拒绝处理.

  6. Dubbo学习笔记8:Dubbo的线程模型与线程池策略

    Dubbo默认的底层网络通讯使用的是Netty,服务提供方NettyServer使用两级线程池,其中 EventLoopGroup(boss) 主要用来接受客户端的链接请求,并把接受的请求分发给 Ev ...

  7. 记一次线上dubbo服务超时和线程池满问题排查

    线上某dubbo服务A调用dubbo服务B的接口X方法,调用端A日志中出现了很多超时的情况,提供端B该接口X超时时间设置为60s: 查看提供端B的日志,报了很多线程池满的异常: Caused by: ...

  8. HIPPO-4J 1.3.0 正式发布:支持 Dubbo、RibbitMQ、RocketMQ 框架线程池

    文章首发在公众号(龙台的技术笔记),之后同步到个人网站:xiaomage.info Hippo-4J 距离上一个版本 1.2.1 已经过去一个月的时间.在此期间,由 8 位贡献者 提交了 170+ c ...

  9. 简单RPC框架-业务线程池

    *:first-child { margin-top: 0 !important; } body>*:last-child { margin-bottom: 0 !important; } /* ...

随机推荐

  1. Unity——FSM有限状态机

    FSM有限状态机 一.设计思路 1.共同的状态父类,提供可重写的进入,保持,退出该状态的生命周期方法: 2.状态机,管理所有状态(增删查改),状态机运行方法(Run): 3.在角色控制器中,实例化状态 ...

  2. mysql从零开始之MySQL DELETE 语句

    MySQL DELETE 语句 你可以使用 SQL 的 DELETE FROM 命令来删除 MySQL 数据表中的记录. 你可以在 mysql> 命令提示符或 PHP 脚本中执行该命令. 语法 ...

  3. 极简SpringBoot指南-Chapter01-如何用Spring框架声明Bean

    仓库地址 w4ngzhen/springboot-simple-guide: This is a project that guides SpringBoot users to get started ...

  4. ShardingSphere 知识库更新 | 官方样例集助你快速上手

    Apache ShardingSphere 作为 Apache 顶级项目,是数据库领域最受欢迎的开源项目之一.经过 5 年多的发展,ShardingSphere 已获得超 14K Stars 的关注, ...

  5. 论文解读(MPNN)Neural Message Passing for Quantum Chemistry

    论文标题:DEEP GRAPH INFOMAX 论文方向:  论文来源:ICML 2017 论文链接:https://arxiv.org/abs/1704.01212 论文代码: 1 介绍 本文的目标 ...

  6. fastdfs单节点部署

    fastdfs单机版搭建 参考链接:https://blog.csdn.net/prcyang/article/details/89946190 搭建步骤 安装依赖 ​ yum -y install ...

  7. GAN实战笔记——第二章自编码器生成模型入门

    自编码器生成模型入门 之所以讲解本章内容,原因有三. 生成模型对大多数人来说是一个全新的领域.大多数人一开始接触到的往往都是机器学习中的分类任务--也许因为它们更为直观:而生成模型试图生成看起来很逼真 ...

  8. 对epoll机制的学习理解v1

    epoll机制 wrk用非阻塞多路复用IO技术创造出大量的连接,从而达到很好的压力测试效果.epoll就是实现IO多路复用的关键. 本节是对epoll的本质的学习总结,进一步的参考资料为: <深 ...

  9. Vulnhub实战-FALL靶机👻

    Vulnhub实战-FULL靶机 下载地址:http://www.vulnhub.com/entry/digitalworldlocal-fall,726/ 1.描述 通过描述我们可以知道这个靶机枚举 ...

  10. 【UE4 C++ 基础知识】<11>资源的同步加载与异步加载

    同步加载 同步加载会造成进程阻塞. FObjectFinder / FClassFinder 在构造函数加载 ConstructorHelpers::FObjectFinder Constructor ...