本文內(nèi)容主要介紹，618醫(yī)藥供應(yīng)鏈質(zhì)量組一次軍演壓測(cè)發(fā)現(xiàn)的問(wèn)題及排查優(yōu)化過(guò)程。旨在給大家借鑒參考。

背景

本次軍演壓測(cè)背景是，2B業(yè)務(wù)線及多個(gè)業(yè)務(wù)側(cè)共同和B中臺(tái)聯(lián)合軍演。

現(xiàn)象

當(dāng)壓測(cè)商品卡片接口的時(shí)候，cpu達(dá)到10%，TPS只有240不滿足預(yù)期指標(biāo)，但是TP99已經(jīng)達(dá)到了1422ms。

排查

對(duì)于這種TPS不滿足預(yù)期目標(biāo)，但是TP99又超高，其實(shí)它的原因有很多中可能，通過(guò)之前寫(xiě)過(guò)的文章對(duì)性能瓶頸的一個(gè)分析方式《性能測(cè)試監(jiān)控指標(biāo)及分析調(diào)優(yōu)》，我們可以采用自下而上的策略去進(jìn)行排查：

首先是操作系統(tǒng)層面的CPU、內(nèi)存、網(wǎng)絡(luò)帶寬等，對(duì)于集團(tuán)內(nèi)部的壓測(cè)，機(jī)器的配置、網(wǎng)絡(luò)帶寬，這些因素運(yùn)維人員已經(jīng)配置到最優(yōu)的程度了，無(wú)需我們?cè)訇P(guān)心是否是因?yàn)橛布Y源系統(tǒng)層面導(dǎo)致的因素。

接下來(lái)從代碼層面和JVM層面進(jìn)行排查，可能是項(xiàng)目代碼中出現(xiàn)了線程阻塞，導(dǎo)致線程出現(xiàn)等待，響應(yīng)時(shí)間變長(zhǎng)，請(qǐng)求不能及時(shí)打到被測(cè)服務(wù)器上。對(duì)于這種猜測(cè)，我們可以在壓測(cè)過(guò)程中打線程dump文件，從dump文件中找到哪個(gè)線程一致處于等待狀態(tài)，從而找到對(duì)應(yīng)的代碼，查看是否可以進(jìn)行優(yōu)化。這塊同開(kāi)發(fā)一同分析整個(gè)接口的調(diào)用鏈路，商品卡片接口調(diào)用運(yùn)營(yíng)端的優(yōu)惠券的可領(lǐng)可用接口，通過(guò)查看此接口的ump監(jiān)控那個(gè)，發(fā)現(xiàn)調(diào)用量其實(shí)并不高。接下來(lái)通過(guò)查看運(yùn)營(yíng)端機(jī)器的日志發(fā)現(xiàn)，調(diào)用可領(lǐng)可用優(yōu)惠券接口已經(jīng)超時(shí)了，并且機(jī)器CPU已經(jīng)偏高，使用率平均在80%以上。是什么原因?qū)е抡{(diào)用可領(lǐng)可用接口大量超時(shí)，成為了問(wèn)題的關(guān)鍵點(diǎn)。

首先我們代碼層面分析，這個(gè)可領(lǐng)可用優(yōu)惠券接口還會(huì)調(diào)用一個(gè)過(guò)濾器進(jìn)行過(guò)濾，于是猜測(cè)是不是這個(gè)過(guò)濾器接口把CPU打滿了，但是通過(guò)監(jiān)控過(guò)濾器接口的ump中可以看到它的TP99并不是很高，說(shuō)明它的調(diào)用量沒(méi)有上去，這種猜測(cè)可能不成立。還好當(dāng)時(shí)代碼這設(shè)置了一個(gè)開(kāi)關(guān)是否使用過(guò)濾器，我們把過(guò)濾器的開(kāi)關(guān)關(guān)閉后。再次進(jìn)行壓測(cè)商品卡片接口，發(fā)現(xiàn)還是沒(méi)有解決問(wèn)題，TPS仍然不高，并且TP99還是很高。說(shuō)明這個(gè)猜測(cè)真是不成立的。

接下來(lái)我們轉(zhuǎn)換思路，查看JVM日志，是否從中尋找到一些蛛絲馬跡，果然從JVM的GC日志中可看到Y(jié)gc和Fgc的時(shí)間占用比較長(zhǎng)，其中Fullgc的時(shí)間占用時(shí)間達(dá)到了7165ms，并且從中可以查看jvm的參數(shù)配置，發(fā)現(xiàn)Xms 和Xmx配置的值都是1024，只有1個(gè)G。問(wèn)題的原因找到了，這臺(tái)被壓測(cè)的機(jī)器JVM參數(shù)配置的Xms 和Xmx值太小了，如果-Xmx指定偏小，應(yīng)用可能會(huì)導(dǎo)致java.lang.OutOfMemory錯(cuò)誤

對(duì)于JVM的介紹這部分比較龐大涉及到類(lèi)加載方式、JVM內(nèi)存模型、垃圾回收算法、垃圾收集器類(lèi)型、GC日志，在這就不做詳細(xì)說(shuō)明了，想要了解詳細(xì)內(nèi)容可以看看《深入理解 JAVA 虛擬機(jī)》這本書(shū)。

此處簡(jiǎn)單說(shuō)明下什么是Ygc和Fgc，以及Xms、Xmx的含義。

JVM內(nèi)存模型中，分為新生代、老年代和元空間，新生代又分為eden區(qū)、Survivor0、Survivor1區(qū)。對(duì)象優(yōu)先在Eden區(qū)分配，當(dāng)Eden區(qū)沒(méi)有足夠空間時(shí)會(huì)進(jìn)行一次Minor GC，執(zhí)行完第一次MGC之后，存活的對(duì)象會(huì)被移動(dòng)到Survivor（from）分區(qū)，當(dāng)Survivor區(qū)存儲(chǔ)滿了之后會(huì)進(jìn)行一次Ygc，但是Ygc一般不會(huì)影響應(yīng)用。當(dāng)老年代內(nèi)存不足的時(shí)候，會(huì)進(jìn)行一次Full GC，也就是Stop the world，系統(tǒng)將停止運(yùn)行，清理整個(gè)內(nèi)存堆（包括新生代和老年代） ，F(xiàn)ullGC頻率過(guò)大和時(shí)間過(guò)長(zhǎng)，會(huì)嚴(yán)重影響系統(tǒng)的運(yùn)行。

Xms，JVM初始分配的堆內(nèi)存

Xmx，JVM最大分配的堆內(nèi)存

一般情況這兩個(gè)參數(shù)配置的值是相等的，以避免在每次GC 后堆內(nèi)存重新進(jìn)行分配。

優(yōu)化

最后修改機(jī)器的JVM數(shù)配置

查看JVM配置參數(shù)

重啟后再次進(jìn)行壓測(cè)，我們的TPS指標(biāo)上來(lái)了，并且TP99的值也下去了。達(dá)到了預(yù)期的一個(gè)目標(biāo)。

總結(jié)

其實(shí)對(duì)于一個(gè)性能瓶頸問(wèn)題的分析排查定位，猶如醫(yī)生看病，需要望聞問(wèn)切，通過(guò)表面現(xiàn)象逐層的去排除一種種的可能性，最終找到其根本原因，對(duì)癥下藥解決問(wèn)題。本文介紹的也只是性能瓶頸問(wèn)題中的一個(gè)小小的部分，其實(shí)在壓測(cè)過(guò)程中還會(huì)遇到各種各樣的問(wèn)題，但是我們掌握了方法論，其實(shí)都可以按照相同的思路去排查，最終找到根源。

作者：京東健康 牛金亮

來(lái)源：京東云開(kāi)發(fā)者社區(qū)文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-471678.html

到了這里，關(guān)于記一次618軍演壓測(cè)TPS上不去排查及優(yōu)化的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！