性能问答>Dubbo消费者请求该服务间歇性出现请求超时,不知道是Dubbo服务提供者的问题,还是其它问题>
7回复

Dubbo消费者请求该服务间歇性出现请求超时,不知道是Dubbo服务提供者的问题,还是其它问题


环境参数
  • 操作系统Linux
  • 操作系统版本CentOS6.4
  • JDK版本JDK8
  • 内存8GB
  • CPU核数4
  • 操作系统位数64位
1.txt.0357.59KB
查看详情

这是服务提供者的日志。服务消费者请求这个服务提供者的时候,会间歇性出现请求超时,但是还没有定位到具体的原因,个人觉得大概可能的原因:

  1. 提供者dubbo线程池过少?导致给消费者返回过慢
  2. 提供者的业务执行过慢,导致堵塞,超时
  3. 其它原因,例如网络IO等
7195 阅读
请先登录,再评论

方向不太对。如果说我内存溢出、或者GC时间长之类问题,我可以利用堆Dump来分析问题。但是超时的话,更多的是线程、处理逻辑方面的问题。

可以先用arthas的trace命令分析下,最大的时间消耗是消耗在哪个方法上。

12年前

你这个问题的原因我可以理解成
数据库连接池较小,dubbo服务端的连接池较大,导致dubbo请求过来,等待分配数据库连接执行sql拿到结果这个过程超过了dubbo请求的超时时间,然后客户端关闭连接导致的么?

2年前

线程Dump的这个瞬间,Dubbo服务线程池只有一个线程在从Redis读数据。
结合监控数据,根据TPS和平均RT,可以推算并发处理量,从而判断线程池大小是否够用。也可以看出是否有某些业务请求耗时过大。可以尝试Dubbo的telnet功能 http://dubbo.apache.org/zh-cn/docs/user/references/telnet.html 执行 status -l 查看线程池繁忙情况。
如果服务提供者线程池持续空闲,而消费者请求超时,再排查二者之间的网络问题,一般这种情况比较少。还是服务端处理慢的可能性比较大。

2年前
2年前回复
回复 shihui:

请教下,从Redis读数据,这个是怎么看出来?

2年前回复
回复 李文文_282787:

这个dump文件未看出卡在数据库上的迹象,有可能不是问题发生的时间点

2年前回复
查看更多