服務現象
服務介面的 TP99 效能下降。
ES現象
ygc：耗時極度異常，峰值為200+次，耗時7s+滿 GC：數字異常，數字為1但頻次，STW 5s慢查詢：有5+慢查詢
1.令人驚訝的是，由於某種原因，該應用程式導致 JVM 記憶體使用量增長，觸發頻繁的 YGC，然後觸發 FGC（此時只是乙個大膽的猜測）。
2.本例中，ES 的 JVM 配置為 40G JVM 記憶體，使用 CMS 垃圾 ** 裝置。 40G記憶體使用CMS垃圾**效能明顯不如G1（參考。
3.查詢 ES O&M 同學的垃圾 ** 裝置從 CMS 修改為 G1
提示：並不是所有的 ES 都適合 G1，很多大查詢的 G1 全 GC 會導致 GC 模式退化為整個堆的串列埠掃瞄，導致幾十秒甚至幾分鐘級別的暫停。 這種長時間的暫停不僅會影響使用者查詢，還容易造成節點之間的通訊超時，導致主節點和資料節點離開集群，影響集群的穩定性。 ）
修改為 G1 後的 GC 變化：
ygc：所需時間極正常，峰值時間為35+，耗時800msFull GC：正常，查詢次數為0，慢查詢10+
調整 ES 的 JVM 垃圾 ** 後，由於 GC 問題的解決，Jeff 介面的服務介面效能沒有得到解決。
通過與ES端同學的交流，了解到這個ES集群的重新整理非常異常，重新整理：2W+。 
ES 監控中慢查詢語句單獨執行不慢
原因：應用程式中與 ES 的互動使用 31.9.spring-data-elasticsearch包的發布版本，ES資料同步通過API中的s**e方法儲存資料，如下圖所示，s**e操作的版本會在每次s**e之後執行一次重新整理操作。
org.springframework.dataspring-data-elasticsearch3.1.9.release
為什麼每次重新整理都會對查詢產生影響，今天就來趕上潮流吧，讓 GPT 回覆我們試試：
1.將spring-data-elasticsearch版本公升級到4x，因為spring-data-elasticsearch的高版本與低版本不相容，且更改低版本的成本較大，因此需要更改專案中涉及API操作的所有部分。
2.s**e 操作改為通過操作操作（當前選擇的方案幾乎沒有變化）。
慢查詢消失了。
重新整理次數也有所下降。
最後，業務服務介面效能正常。
老師們常說，我們總是受到經驗思想和機會主義的影響，而解決這個問題的根本辦法是實事求是，實踐是真理的標準。
作者：京東物流 王一傑.*：京東雲開發者社群自猿說技術**請註明**。