1. 背景
HSF-go 在钉钉落地的过程中，业务方在云上环境 ASK 集群内发现了压测后内存不能及时回收的问题。于是在本文章中，通过部署在 ASK 集群内的 HSF-go 服务进行压测，从而尝试排查问题。
2. 压测方案
- 集群环境
阿里云 ASK 集群
- 容器环境
alios7
- 服务部署
服务使用与业务方尽可能一致的方案， HSF-go v0.2.4 开发，采用 Triple 协议， Hessian 序列化暴露和调用服务。
测试 Client 、Server 部署在 ASK 集群内，由外部施压机请求UserProviderProxy 服务（client），调用UserProvider服务（server）
- 监控指标
监控 Client 和 Server 对应容器的container_memory_rss 指标，通过Prometheus 收集。
container_memory_rss{pod_name="ask-client-66cd97557d-rbjlw", id="/"}
container_memory_rss{pod_name="ask-server-79c5c455-264rd", id="/"}
- 压测过程
由于 client 服务同时包含了HSF-go client 和 server，因此重点关注client指标即可。
首先部署服务，成功部署之后，记录初始容器 RSS 值和进程 RES 值。
压测时，施压机器以200并发请求10k的数据，数据会经过全部链路。
经过多次压测和停止，记录压测时和停止后 RSS 值和进程 RES 值，观察进程 RES 是否得到合理释放，观察容器 RSS 值是否下降。
尝试使用 pprof 采集内存信息，观察是否存在内存泄露情况
- 压测结论
经过多轮压测观察，和pprof 内存信息采集。分析结论为RSS 指标下降合理，进程 RES 指标多次释放后数值趋于稳定，pprof 观察内存无泄露。
单进程空闲时占据 RES 大约为50M，容器 RSS 稳定状态约为150M，容器启动时，进程和容器都会逐步产生缓存。
3. 测试细节
3.1 压测之前
部署服务，记录容器 RSS 数值
进程启动时，进程 RES 为30M左右
查看启动时 heap 内存，无可优化点
3.2 第一轮压测
压测时，进程 RES 变动较大，记录进程 约为100-150M
压测停止后，进程 RES 快速下降，经过2min gc后，回降为40M左右
容器 RSS 指标压测时在175M左右，压测结束回降至120M。
容器在经过第一轮压测后，RSS 数据上涨20M，进程 RES 上涨10M左右。通过 pprof 分析内存增多为 http2 Buffer
3.3 多轮压测
进程 RES 数值稳定在46M左右，进程 pprof 未发现内存泄露异常。
经过多轮压测，每轮压测后 RSS 回降后数值略有升高，应该与计算方式有关，与进程 in use 内存占用无关系。