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 記憶體占用無關系。