图看不见。 这种情况下,需要进一步提供consumer端的详细监控数据和指标,如jvm内存使用,进程cpu,请求压力,各接口的性能指标等,问题多半在consumer或实际的业务特性(例如死锁)。
best regards, Jason > On Jun 25, 2019, at 14:05, Huxing Zhang <hux...@apache.org> wrote: > > Forwarding to dev@ list. > For further questions, please ask on the dev@dubbo.apache.org > <mailto:dev@dubbo.apache.org> mailing list. > > On Fri, Jun 21, 2019 at 12:18 PM snow <s...@mozhes.com > <mailto:s...@mozhes.com>> wrote: > 很抱歉,打扰到了你,我们是一个上海的创业团队,用了dubbo的微服务,但是近期却出现了一些很不明朗的问题。无奈之举,找了很多人帮忙,困扰了良久。 > > 下面是问题描述,如果有可能,希望 麻烦大佬能帮忙查看,十分感谢!! > > 1.项目服务器配置: > > 四台:一台12核96G, 三台8核32G > > 2.应用服务信息: > > 项目拆分为七个服务,每台服务器上都会部署这七个服务 > > 其中一个服务(简称api服务)作为用户请求入口,通过dubbo对另外六个服务进行调用 > > 注册中心:单机zookeeper > > 3.问题: > > 项目常态下接口平均响应时间90ms左右, 运行一段时间后(目前是约一天左右), 会出现部分机器上的api服务调用dubbo服务耗时增长, > 直至无法在超时时间内响应(超时时间配置的是30秒), 引起崩溃。(注:不是四台机器上的api调用dubbo服务都会超时, 其中1~2台, > 每次崩溃的机器也不一样) > > 崩溃时服务器cpu, 内存, 带宽出入均正常。 > > 数据库cpu, 内存, 连接数正常,没有慢查询。 > > dubbo监控图显示provider耗时正常, consumer耗时很高 > > -- 崩溃前后平均响应时间走势图 > > > > -- 崩溃前后请求量走势图 > > > > -- 崩溃前后部分dubbo接口监控走势图 > > > > -- 异常摘要截图 > > > > > > > > -- > Best Regards! > Huxing