本文內容主要介紹，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的值也下去了，達到了預期的一個目標，
總結
其實對于一個性能瓶頸問題的分析排查定位，猶如醫生看病，需要望聞問切，通過表面現象逐層的去排除一種種的可能性，最終找到其根本原因，對癥下藥解決問題，本文介紹的也只是性能瓶頸問題中的一個小小的部分，其實在壓測程序中還會遇到各種各樣的問題，但是我們掌握了方法論，其實都可以按照相同的思路去排查，最終找到根源，
作者：京東健康 牛金亮
來源：京東云開發者社區
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/554361.html
標籤：其他
上一篇：9.3. Hibernate框架
下一篇：返回列表