本文內容主要介紹，618醫藥供應鏈質量組一次軍演壓測發現的問題及排查優化過程。旨在給大家借鑑參考。
背景
本次軍演壓測背景是，2B業務線及多個業務側共同和B中臺聯合軍演。
現象
當壓測商品卡片接口的時候，cpu達到10%，TPS只有240不滿足預期指標，但是TP99已經達到了1422ms。
排查
對於這種TPS不滿足預期目標，但是TP99又超高，其實它的原因有很多中可能，通過之前寫過的文章對性能瓶頸的一個分析方式《性能測試監控指標及分析調優》，我們可以採用自下而上的策略去進行排查：
首先是操作系統層面的CPU、內存、網絡帶寬等，對於集團內部的壓測，機器的配置、網絡帶寬，這些因素運維人員已經配置到最優的程度了，無需我們再關心是否是因爲硬件資源系統層面導致的因素。
接下來從代碼層面和JVM層面進行排查，可能是項目代碼中出現了線程阻塞，導致線程出現等待，響應時間變長，請求不能及時打到被測服務器上。對於這種猜測，我們可以在壓測過程中打線程dump文件，從dump文件中找到哪個線程一致處於等待狀態，從而找到對應的代碼，查看是否可以進行優化。這塊同開發一同分析整個接口的調用鏈路，商品卡片接口調用運營端的優惠券的可領可用接口，通過查看此接口的ump監控那個，發現調用量其實並不高。接下來通過查看運營端機器的日誌發現，調用可領可用優惠券接口已經超時了，並且機器CPU已經偏高，使用率平均在80%以上。是什麼原因導致調用可領可用接口大量超時，成爲了問題的關鍵點。
首先我們代碼層面分析，這個可領可用優惠券接口還會調用一個過濾器進行過濾，於是猜測是不是這個過濾器接口把CPU打滿了，但是通過監控過濾器接口的ump中可以看到它的TP99並不是很高，說明它的調用量沒有上去，這種猜測可能不成立。還好當時代碼這設置了一個開關是否使用過濾器，我們把過濾器的開關關閉後。再次進行壓測商品卡片接口，發現還是沒有解決問題，TPS仍然不高，並且TP99還是很高。說明這個猜測真是不成立的。
接下來我們轉換思路，查看JVM日誌，是否從中尋找到一些蛛絲馬跡，果然從JVM的GC日誌中可看到Ygc和Fgc的時間佔用比較長，其中Fullgc的時間佔用時間達到了7165ms，並且從中可以查看jvm的參數配置，發現Xms 和Xmx配置的值都是1024，只有1個G。問題的原因找到了，這臺被壓測的機器JVM參數配置的Xms 和Xmx值太小了，如果-Xmx指定偏小，應用可能會導致java.lang.OutOfMemory錯誤
對於JVM的介紹這部分比較龐大涉及到類加載方式、JVM內存模型、垃圾回收算法、垃圾收集器類型、GC日誌，在這就不做詳細說明了，想要了解詳細內容可以看看《深入理解 JAVA 虛擬機》這本書。
此處簡單說明下什麼是Ygc和Fgc，以及Xms、Xmx的含義。
JVM內存模型中，分爲新生代、老年代和元空間，新生代又分爲eden區、Survivor0、Survivor1區。對象優先在Eden區分配，當Eden區沒有足夠空間時會進行一次Minor GC，執行完第一次MGC之後，存活的對象會被移動到Survivor（from）分區，當Survivor區存儲滿了之後會進行一次Ygc，但是Ygc一般不會影響應用。當老年代內存不足的時候，會進行一次Full GC，也就是Stop the world，系統將停止運行，清理整個內存堆（包括新生代和老年代） ，FullGC頻率過大和時間過長，會嚴重影響系統的運行。
Xms，JVM初始分配的堆內存
Xmx，JVM最大分配的堆內存
一般情況這兩個參數配置的值是相等的，以避免在每次GC 後堆內存重新進行分配。
優化
最後修改機器的JVM數配置
查看JVM配置參數
重啓後再次進行壓測，我們的TPS指標上來了，並且TP99的值也下去了。達到了預期的一個目標。
總結
其實對於一個性能瓶頸問題的分析排查定位，猶如醫生看病，需要望聞問切，通過表面現象逐層的去排除一種種的可能性，最終找到其根本原因，對症下藥解決問題。本文介紹的也只是性能瓶頸問題中的一個小小的部分，其實在壓測過程中還會遇到各種各樣的問題，但是我們掌握了方法論，其實都可以按照相同的思路去排查，最終找到根源。
作者：京東健康 牛金亮
來源：京東雲開發者社區