图看不见。 这种情况下，需要进一步提供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
