线上Skywalking把OAP的CPU打挂，重启后亦是如此

背景

1. oap服务端首先告警，cpu load飙升至上万（4c8g机器），集群内三台机器陆续崩溃。

2. 重启三台oap后，几分钟内，又都被击垮。
3. oap崩盘后，业务服务A单台机器，内存使用飙涨（使用率达到93%），线上紧急摘量。

4. 业务服务B所有机器，也出现内存飙涨，线上立即摘量重启。

5. 服务A，B机器，全部内存飙升，立即线上摘量重启。

问题定位

1. 首先出现内存飙涨的服务A机器，摘量后，保存堆栈信息，并未立即重启。

定位到skywalking对应endpoint类实例，在堆中积攒过多。

2. 服务A重启后，内存仍在异常爬升。

3. 同时，在线上做AB对照组，可以确定接入skywalking导致。

4. 登陆oap机器，查看进程关联线程情况。(使用”top -c“，查看具体进程列表，并按”P“键，对CPU使用率降序。 再使用”top -Hp pid“，对捞出具体线程)

5. 发现起了700多个线程，随机抓取几个线程，看看究竟在做些什么。（使用”jstack -l pid > .file.stack“，导出线程堆栈，再将线程对应PID的十六进制，进行搜索 "grep -C 20 '2093' pid.stack"）

6. 发现线程都在做endpoint端点注册，为什么有这么多端点注册，去kibana上看看es数据，发现都是整数型的端点。

7. 再去oap机器上，看下上报端口（11800）被哪些ip调用。

问题汇总

1. 服务A，对外提供的http接口uri中，带有userId，导致每个接口都被当成独立端点上报。

2. 服务B，调用服务A流量过大（tps: 3000），导致oap接收，上报数据剧增。

3. 为何skywalking的agent，会影响业务服务，初步怀疑是内存缓存机制导致。

解决方案

1. 针对服务A流量过大，导致上报数量剧增，有两种方案解决：

• 调整上报采样率
• 机器扩容（三台4c8g → 8c16g）

2. 服务A，B端点上报剧增，需要更改agent上报规则。

• 将上报端口（针对feign调用，做到改动影响最小化）中的userId匹配为“*”，统一上报uri。

3. skywalking影响业务服务

• 当oap无法提供服务，会保存未注册端点列表，这个值未设置，走默认值。

• 未注册端点默认值为1亿个，导致机器内存增大，从而影响业务服务的原因找到了。

• 当oap正常时，为何cpu会飙升，看这个代码，会先从endpoint缓存中，获取端点值。

• endpoint上报缓存，最大为10万条，由于服务A，B的uri各自独立，导致上报频率剧增原因找到了。

总结

• 更新项目中使用的skywalking的agent包。
• 修改配置dictionary.endpoint_name_buffer_size=100000