一、問題現象

服務現象

服務介面的TP99效能降低

ES現象

• YGC：耗時極其不正常, 峰值200+次，耗時7s+
• FULL GC：不正常,次數為1但是頻繁，STW 5s
• 慢查詢：存在慢查詢5+

二 解決過程

1、去除干擾因素

• 從現象上看應用是由於某種原因導致JVM記憶體使用率不斷增長，觸發了頻繁的YGC進而觸發FGC（此時只是大膽的猜測）。
• 此時ES的JVM設定是JVM記憶體40G，使用CMS垃圾回收器。40G的記憶體使用CMS垃圾回收器效能顯然不如G1更合適
• 找ES運維同學垃圾回收器由CMS修改為G1

（tips:不是所有的ES都適合G1,針對很多大查詢的G1的Full GC會導致GC模式退化為序列掃描整個堆，導致幾十秒甚至是分鐘級別的暫停。這種長時間的暫停不僅影響使用者的查詢，還容易造成節點間的通訊超時，導致master、dataNode脫離叢集，影響叢集穩定性。）

修改為G1後的GC變化：

• YGC：耗時極正常, 峰值35+次，耗時800ms
• FULL GC：正常,次數為0
• 慢查詢：存在慢查詢10+

2、查詢問題

ES的JVM垃圾回收器調整後，傑夫介面的服務介面的效能並沒有因為GC問題的解決而解決。

• 通過和ES側同學的溝通了解到，這個ES叢集的refresh極其異常，refresh：2w+。

• ES監控中的慢查詢語句單獨去執行並不慢

原因：

應用中和ES的互動使用的是3.1.9.RELEASE 版本的spring-data-elasticsearch的包，ES資料同步工作是通過該API的中的save方法進行儲存資料的，如下圖所示，該版本的save操作每次save後都會進行refresh操作

<groupId>org.springframework.data</groupId>
<artifactId>spring-data-elasticsearch</artifactId>
<version>3.1.9.RELEASE</version>

為什麼每次refresh會對查詢產生影響呢，今天咱們也趕個時髦，讓GPT給咱們回覆下試試：

3、修復方案

• 升級spring-data-elasticsearch 的版本到4.x以上，由於spring-data-elasticsearch高本版不相容低版本改動成本較大，該專案中的所有涉及API操作的地方都需要改動

• save操作改用operation進行操作（目前選擇的該方案，改動較少）

慢查詢已經消失

refresh的次數也降了下來

三、問題解決

最終的業務服務介面效能正常了。

教員常說我們總是被經驗主意和投機主義左右我們的思想，破局這一問題的根本解決方式是隻有實事求是，實踐是真理的標準。

作者：京東物流 王義傑

來源：京東雲開發者社群 自猿其說Tech 轉載請註明來源