Closed Jaskey closed 4 years ago
"从报超时的服务端上看,找不到对应的超时的warn日志" 。1.有没有可能dubbo的com.alibaba.dubbo.rpc.filter这个目录的日志设置成了error级别? 2.服务端TimeoutFilter的timeout设置在provider侧,而不是consumer侧(
@feelwing1314 设置的超时就是provider设置的,其他超时是有warn日志的,所以不可能是error级别的问题
我这里也出现了类似的问题,
dubbo version 2.6.0
调用某个服务的方法,马上(几微秒)
返回 Invoke remote method timeout.
,重复尝试几次,有的时候又可以正常调用,有的时候又返回timeout。
provider 模块已经配置了timeout设置。
我也遇到一样的问题~ 如有答案,万分感谢
跪求权威解释
会不会是直接网络上丢了包?如果网络上传输就失败了,异常会是超时么
Network problems can lead to timeout. Although the server side is normal,consumer will appear timeout
@lovepoem 根据日志 "client elapsed: 0 ms, server elapsed: 1028 ms, timeout: 1000 ms", 可以推断,肯定不是客户端到服务端这一个方向的问题,应该是服务端回客户端的问题,但是服务端实际上耗时很短,所以如果真的是网络问题,那就是回程的问题。但是从来没发现去程有类似的问题啊,所以大概率和网络有关。
是否有可能和编解码这些地方有关系?
我这边曾今也出现类似的超时问题,两边的业务代码都没有异常,从远程调用到收到异常间隔也就几毫秒。但是却抛出超时异常。
后来就给服务方和消费方都加上timeout,就没有这个问题了。
我也遇到同样问题,com.alibaba.dubbo.rpc.RpcException: Invoke remote method timeout. method: takeAppAd, provider: dubbo://192.168.2.13:20805/com.douyu.wsd.adx.exchange.rpc.api.virtualaccount.AdLuaRService?actives=0&alive=60000&anyhost=true&application=adx-gateway&async=false&check=false&connections=4&corethreads=0&dispatcher=message&dubbo=2.6.0&generic=false&group=pro&interface=com.douyu.wsd.adx.exchange.rpc.api.virtualaccount.AdLuaRService&iothreads=33&keep.alive=true&lazy=false&loadbalance=roundrobin&logger=slf4j&methods=takeWebAd,isWebLibertyUser,takeAppAd,isAppLibertyUser&monitor=dubbo%3A%2F%2F10.11.0.55%3A2181%2Fcom.alibaba.dubbo.registry.RegistryService%3Fapplication%3Dadx-gateway%26backup%3D10.11.0.22%3A2181%2C10.11.0.26%3A2181%26dubbo%3D2.6.0%26logger%3Dslf4j%26organization%3Dwsd%26owner%3Dwsd-java%26pid%3D1210993%26protocol%3Dregistry%26refer%3Ddubbo%253D2.6.0%2526interface%253Dcom.alibaba.dubbo.monitor.MonitorService%2526pid%253D1210993%2526timestamp%253D1532628089853%26registry%3Dzookeeper%26timestamp%3D1532628089837&optimizer=com.douyu.adx.exchange.dubbo.internal.SerializationOptimizerImpl&organization=wsd&owner=wsd-java&pid=1210993&protocol=dubbo&queues=0®ister.ip=192.168.2.9&remote.timestamp=1532629098461&retries=1&revision=0.0.1-SNAPSHOT&sent=false&serialization=kryo&service.filter=exceptionFilter&side=consumer&threadname=AdxRServiceConsumer&threads=2147483647&timeout=900×tamp=1532628089789&version=1.0.0, cause: Waiting server-side response timeout by scan timer. start time: 2018-07-27 17:56:13.067, end time: 2018-07-27 17:56:13.984, client elapsed: 0 ms, server elapsed: 917 ms, timeout: 900 ms, request: Request [id=82601558, version=2.0.0, twoway=true, event=false, broken=false, data=RpcInvocation [methodName=takeAppAd, parameterTypes=[class com.douyu.wsd.framework.common.domain.StdRequest, interface java.util.Map], arguments=[StdRequest{tid='d1cd7b19dfa1453b94c8eb92d98659a3', ts=1532685373066, data={"app":"{\"aname\":\"斗鱼直播\",\"pname\":\"air.tv.douyu.android\"}","mdid":"phone","uid":"128636735","posid":"800039","client_sys":"android","cate1":"15","cate2":"270","imei":"868060039348334","chanid":"32","device":"{\"addid\":\"69a88d50cbc41a75\",\"devtype\":\"0\",\"h\":\"2160\",\"idfa\":\"\",\"imei\":\"868060039348334\",\"mac\":\"02:00:00:00:00:00\",\"mfrs\":\"OPPO\",\"model\":\"OPPO-R11st\",\"nt\":\"1\",\"op\":\"1\",\"os\":\"Android\",\"osv\":\"7.1.1\",\"ua\":\"Douyu_Android\",\"w\":\"1080\"}","roomid":"100","token":"128636735_12_c5f2a7e1f5f81815_1_69874863"}}, {content-length=599, cookie=acf_uid=128636735; acf_did=eddb5774190e008787999c0870805111, auth=dd56178541ba50125972f066cad47bd1, channel=32, x-via=1.1 PSzjhzsdyd6mw47:1 (Cdn Cache Server V2.0), x-forwarded-for=218.205.75.47, x-real-ip=218.205.75.47, requestTime=1532685373066, user-device=ZWRkYjU3NzQxOTBlMDA4Nzg3OTk5YzA4NzA4MDUxMTF8djQuNi4w, clientIp=39.182.109.142, host=rtbapi.douyucdn.cn, connection=close, content-type=application/x-www-form-urlencoded, time=1532685372, cdn-src-ip=39.182.109.142, aid=android1, accept-encoding=gzip, user-agent=android/4.6.0 (android 7.1.1; ; OPPO+R11st)}], attachments={path=com.douyu.wsd.adx.exchange.rpc.api.virtualaccount.AdLuaRService, interface=com.douyu.wsd.adx.exchange.rpc.api.virtualaccount.AdLuaRService, version=1.0.0, timeout=900, sw3=104.22761.15326853730678968|0|104|104|-50|#com.douyu.wsd.adx.exchange.rpc.api.virtualaccount.AdLuaRService.takeAppAd(StdRequest,Map)|#com.douyu.wsd.adx.exchange.rpc.api.virtualaccount.AdLuaRService.takeAppAd(StdRequest,Map)|104.22761.15326853730678969, group=pro}]], channel: /192.168.2.9:41504 -> /192.168.2.13:20805
at com.alibaba.dubbo.rpc.protocol.dubbo.DubboInvoker.doInvoke(DubboInvoker.java:98)
at com.alibaba.dubbo.rpc.protocol.AbstractInvoker.invoke(AbstractInvoker.java:142)
at com.alibaba.boot.dubbo.listener.ConsumerInvokeStaticsFilter.invoke(ConsumerInvokeStaticsFilter.java:32)
at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:68)
at com.alibaba.dubbo.monitor.support.MonitorFilter.invoke$original$tDp0wZPU(MonitorFilter.java:64)
服务端响应时间最长时间是345ms
配置信息: dubboProtocol: name: dubbo port: 20805 dispatcher: message serialization: kryo keepAlive: true optimizer: com.douyu.adx.exchange.dubbo.internal.SerializationOptimizerImpl threads: 1000 queues: 2000 Service:@Service( interfaceClass = AdLuaRService.class, protocol = PROTOCOL_DUBBO, retries = 0, parameters = {"threadname", "AdLuaRService"}, filter = "exceptionFilter", connections = 10, timeout = 800 )
如果是网络原因,有哪些方能能够证明?
@lovepoem @chickenlj
It seems most of the users face the same problem , can you provide some advice?
provider的业务方法执行的时间PT=5ms,但是 consumer调用的时间CT=consumer本地代码执行时间CLT(生成stub、两次编解码) +网络请求时间NRT1 +网络响应时间NRT2 +provider本地的dubbo代码执行时间PLT(生成skeleton、两次编解码) +PT
这种情况,建议consumer端设置一个较长的超时比如 Provider=1s,Consumer=5s, 这样如果provider超时,Consumer能拿到异常,也不用等5s, 如果Provider没有超时,Consumer有足够的时间等到拿到结果,避免P正常,C超时。
@kimmking , 但是如果网络正常的情况下,现在这种很奇怪的场景就是损失在 CLT(stub+编解码)?什么情况下会损失几秒
这个是对应的图标,在并发高的时候,consumer的时间会有很大的波动,而且provider的时间不变!问一下这种情况能从哪些方面来优化?
这种情况是不是大多数出现在服务发版新实例上线的时候?也常出现在 response很小的情况,如果没有设置 tcpNoDelay = true,会出现这种现象。
@fingthinking 设置了这个现象就解决了?
@drluorose 你这种情况,可以设置订阅端的connections属性,给访问压力大的service独立一条或几条长连接出来避免争抢,否则可能会在密集时被限流。
另外需要考虑的是,压力上来的时候,consumer端的load、cpu.switches/irq/softirq/idle的情况如何
@fingthinking 设置了这个现象就解决了?
加了这个之后,会有所改善,另外建议设置一下 netty3 的 backlog 参数,netty3默认是用的 jdk 默认设置为50,netty4默认读取/proc/sys/net/core/somaxconn
配置
@Jaskey is it ok now?
遇到了这个情况,服务端处理的很快,但是回客户端的时候是几s 后了,抓包也发现是这种情况
线上环境dubbo调用超时:Caused by: com.alibaba.dubbo.remoting.TimeoutException: Waiting server-side response timeout by scan timer. start time: 2018-10-18 12:23:28.116, end time: 2018-10-18 12:33:28.130, client elapsed: 0 ms, server elapsed: 600014 ms, timeout: 600000 ms, request: Request;请问这个和cached线程池设置200有没有关系呢?
@FS1360472174 @Jaskey How can I reproduce this issue in my local machine? can you upload a demo ?
我们也遇到过,这种奇怪的现象曾经也怀疑过各种 IO情况,但最后定位是线程池不足,请求压根无法进入dubbo线程池,dubbo框架也没有打印异常,当然请求入参出参也没打印,客户的表现就是超时。
遇到了这个情况,服务端处理的很快,但是回客户端的时候是几s 后了,抓包也发现是这种情况 @FS1360472174 你解决了吗 我最近也遇到相同的问题
看来同样的问题大家都碰到了很多啊
有时是服务端接收消息延迟,有时是调用端接收结果延迟,最终都是超时
用链路追踪系统跟踪一下,看看RPC的时间分布:网络传输层or业务处理层
如果是网络原因,有哪些方能能够证明?
集成分布式链路追踪系统能快速定位是否是网络引起,对于偶发性问题使用tcpdump凭靠运气。对于queues: 2000
,耗时可能在排队等待执行,不建议配置。connections = 10
会使消费者应用至少创建10个cached线程池,我们前段时间在生产环境遇到,某提供者应用有5个服务设置了connections=50
,对于单个提供者实例,每个消费者至少会创建50*5=250个cached线程池(每服务每连接,见DubboProtocol#refer
)。
遇到了这个情况,服务端处理的很快,但是回客户端的时候是几s 后了,抓包也发现是这种情况
我们在生产环境(Kubernetes)通过链路追踪系统发现网络上耗时达几秒,通过抓包证实确实是网络引起。接下来就交给运维处理 @gangxing
如果超时问题发生比较频繁,在没有链路追踪系统辅助下,可以借助greys, arthas
命令在线debug消费者端耗时,需要一步一步追踪看看最耗时的步骤,对于高并发系统需评估工具对于系统性能的影响。
我们在生产环境也遇到偶发性超时,最终定位到问题根源是提供者端Netty IO一直报ClassNotFoundException
,因为暴露的API没有向前兼容:joy:,修复掉这个就正常了。
@edwardlee03 怎么修复呢?
我这边也遇到类似问题,在provider设置超时时间为2s,在consumer端监控调用栈耗时,发现偶尔有超时(一天时间有10几个请求左右),超时的时间点不规律。 apm监控到超时的时候有请求发到zookeeper,而且正好都超过2s
@edwardlee03 怎么修复呢?
@gosenme 根据ClassNotFoundException
可知道哪个类,依赖哪个jar,然后升级提供者或消费者应用依赖的jar,使其不再报这个异常即可。Dubbo社区增加了Cache<ClassName>
类加载异常缓存,避免重复并发同步地加载类信息。
@Jaskey 请问服务端是否开启了系统自带的监控服务?注册中心客户端用的是哪个,是否有设置密码? 如果密码中有@符号,会遇到类似的问题。
如果超时问题发生比较频繁,在没有链路追踪系统辅助下,可以借助
greys, arthas
命令在线debug消费者端耗时,需要一步一步追踪看看最耗时的步骤,对于高并发系统需评估工具对于系统性能的影响。
想请教下具体怎么追踪呢?我最近生产环境也遇到这个问题了。 @edwardlee03
烽火拿你这个问题问我我也是醉了。。。
如果超时问题发生比较频繁,在没有链路追踪系统辅助下,可以借助
greys, arthas
命令在线debug消费者端耗时,需要一步一步追踪看看最耗时的步骤,对于高并发系统需评估工具对于系统性能的影响。想请教下具体怎么追踪呢?我最近生产环境也遇到这个问题了。 @edwardlee03
首先看工具官方文档(Greys-Java线上问题诊断工具PDF,Java诊断利器Arthas),见快速入门里的安装和启动步骤,能很快上手。再不行就搜索引擎一搜不就有很多使用教程哦,切记搜索引擎是你的老师和朋友。
线上环境dubbo调用超时:Caused by: com.alibaba.dubbo.remoting.TimeoutException: Waiting server-side response timeout by scan timer. start time: 2018-10-18 12:23:28.116, end time: 2018-10-18 12:33:28.130, client elapsed: 0 ms, server elapsed: 600014 ms, timeout: 600000 ms, request: Request;请问这个和cached线程池设置200有没有关系呢?
异常信息说”服务端处理超时“,说明提供者处理慢了,提示的很明显了。
我们也遇到过,这种奇怪的现象曾经也怀疑过各种 IO情况,但最后定位是线程池不足,请求压根无法进入dubbo线程池,dubbo框架也没有打印异常,当然请求入参出参也没打印,客户的表现就是超时。
提供者线程池满了,也会打印日志,一般异常都会输出相关日志,dubbo框架异常输出还可以的。或者你没找到相关日志
除了网络问题,还可能有其他原因么,我司也出现了这种短时抖动,服务端完全是没有延迟的报错
这个问题有解决方案了吗,我们在最近使用的过程中也遇到了 客户端调用超时,服务端完全正常,偶现. 大概率不是网络问题,我们对客户端压测,停止后 服务端服务正常, 客户端调用一直超时,然后过来几个小时之后就自动恢复了.现在每天会爆几千个这样的异常,概率不大.
@PKFresher dubbo有集成分布式链路追踪功能么?打开dubbo访问日志,主要看耗时在哪个阶段,然后再逐层剖析进去
@PKFresher dubbo有集成分布式链路追踪功能么?打开dubbo访问日志,主要看耗时在哪个阶段,然后再逐层剖析进去
建议直接使用skywalking吧
我们也遇到过,这种奇怪的现象曾经也怀疑过各种 IO情况,但最后定位是线程池不足,请求压根无法进入dubbo线程池,dubbo框架也没有打印异常,当然请求入参出参也没打印,客户的表现就是超时。
“最后定位是线程池不足”,这个是否是在服务端的日志中发现了Thread pool is EXHAUSTED! 故障呢?
我想问一下有没有人解决?我们生产也是偶尔的超时,链路监控没有上,希望有碰到过然后解决的出来解答一下。我们线上dubbo线程池满的报错会有,不是因为线程池满报的这个超时
线上的问题已经定位到是因为5分钟执行一次的定时任务操作大对象,导致过一段时间那个服务节点要执行GC。这个时候请求过来只能等GC结束导致dubbo请求超时。
除了网络问题,还可能有其他原因么,我司也出现了这种短时抖动,服务端完全是没有延迟的报错
可能的原因: 1.请求阻塞在工作者队列里排队,消耗了大部分时间; 2.API.jar升级引起类不兼容加载不到,频繁加载某一个类会引起阻塞,可以看下ClassLoader源码。dubbo新版本已修复这个问题。 3.较长时间的GC停顿
A调用服务B,超时时间1秒,从某些请求来看超时了两次,重试了两次,第三次成功了,耗时仅4ms。
客户端有类似日志:
有以下两个奇怪的地方:
以下是我的分析:
猜测和dubbo 服务端进入业务线程前的排队有关,但是我们没有设置queue的长度,所以默认应该是不排队的,线程池耗尽应该抛出的异常不是timeout。
即使排队了,但是服务端没有找到此上下文的超时日志,感觉像完全没有收到此请求?
会不会是直接网络上丢了包?如果网络上传输就失败了,异常会是超时么?此请求是一个对象,转换为JSON后有几K。
求解答