6到飞起Arthas——记一次线上问题排查及调优

Arthas 是Alibaba开源的Java诊断工具，通过Java agent机制 attach到ava进程上，使用ASM技术对需要诊断的类进行字节码修改。（详细原理及用法参照官方文档https://arthas.aliyun.com/doc/en/）

线上诊断神器Arthas，强烈安利一波。好嘞，切回本次重点，记一次线上调优：

背景：

  公司自研的服务治理框架，sdk客户端在向控制中心寻址时，经常会出现寻址超时的情况（sdk客户端设置超时时间为3s）。虽然客户端会每5S会发送一次寻址请求，且请求到的数据会放入缓存中，如果请求失败，只是不会更新缓存。

因为只要在一定的时间内有一次寻址成功，sdk中就会缓存A应用依赖的其它服务的实例信息，在A应用需要调用其它服务时，是直接使用sdk缓存中的其它服务的实例信息进行负载均衡的。所以通常情况下不太会影响业务，但是这样依旧会存在很多问题：比如A依赖的服务的实例有变化（新增节点、删除节点、心跳上传失败、上下负载等等），客户端寻址超时，将无法更新缓存，sdk中的实例信息依旧是旧的，负载时可能会将流量打入到实际上已经不存活的节点上、或者无法将流量打入新增的节点上。。。这是很可怕的！！！

如图可以看到很多最大执行时间超过了3s：

 

服务注册和服务寻址作为服务治理框架最基本的功能，我们都无法给用户有力的保证，那岂不是很离谱。所以针对出现的寻址超时问题，进行了一次深入的问题排查。

---------------------------

前期种种问题排查、定位、代码逻辑梳理等工作不做赘述。在本文中只谈谈最终的问题定位以及优化方式。

因为只有生产环境的控制中心会频繁出现寻址超时问题（生产环境中，定时向客户端发送寻址请求的实例达到2w，寻址的TPS达到2000），在测试环境中很难模拟线上场景，很难复现问题，所以需要在生产环境中进行问题的排查。

作为基础组件，涉及到生产环境，那就必须保证在排查时不会对业务造成影响。

（顺便提一嘴，jvm提供了一些调优工具、命令，功能很强大&#