jmeter性能測(cè)試及性能調(diào)優(yōu)

1、Contents目 錄一. 性能測(cè)試實(shí)施流程介紹二. 性能測(cè)試腳本介紹三. 性能測(cè)試監(jiān)控介紹四. 性能測(cè)試分析介紹五. 性能測(cè)試測(cè)試報(bào)告介紹Contents目 錄 一.性能測(cè)試實(shí)施流程介紹 1.了解什么是性能測(cè)試 2.性能測(cè)試流程 3.性能測(cè)試常見(jiàn)類(lèi)型 4.常用性能測(cè)試工具分類(lèi) 1.性能測(cè)試?yán)镎?性能測(cè)試是通過(guò)自動(dòng)化的測(cè)試工具模擬多種正常、峰值以及異常負(fù)載條件來(lái)對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測(cè)試。 性能是衡量在一個(gè)環(huán)境下運(yùn)行一個(gè)或多個(gè)應(yīng)用程序的效率 主要的指標(biāo)一般是響應(yīng)時(shí)間，tps， 交易成功率 2.性能測(cè)試流程: 3.性能測(cè)試常見(jiàn)類(lèi)型： 4.常用性能測(cè)試工具分類(lèi)：.Loadrunner LoadR

2、unner 是一種預(yù)測(cè)系統(tǒng)行為和性能的負(fù)載測(cè)試工具。通過(guò)以模擬上千萬(wàn)用戶實(shí)施并發(fā)負(fù)載及實(shí)時(shí)性能監(jiān)測(cè)的方式來(lái)確認(rèn)和查找問(wèn)題，LoadRunner 能夠?qū)φ麄€(gè)企業(yè)架構(gòu)進(jìn)行測(cè)試。通過(guò)使用LoadRunner ，企業(yè)能最大限度地縮短測(cè)試時(shí)間，優(yōu)化性能和加速應(yīng)用系統(tǒng)的發(fā)布周. .Jmeter JMeter是Apache組織的開(kāi)放源代碼項(xiàng)目，它是功能和性能測(cè)試的工具，100%的用java實(shí)現(xiàn)。這個(gè)工具相對(duì)于上面的LoadRunner來(lái)說(shuō)，是比較輕量級(jí)的工具，便于安裝且免費(fèi)開(kāi)源。不僅可以進(jìn)行功能測(cè)試也可以進(jìn)行性能測(cè)試，一般可以用來(lái)做接口測(cè)試。這款工具學(xué)習(xí)起來(lái)也非常的容易，只要用這個(gè)工具做過(guò)幾次測(cè)試，就可以非

3、常熟悉的運(yùn)用了。Contents目 錄 二.性能測(cè)試腳本介紹 1.事務(wù) 2.參數(shù)化 3.斷言 4.關(guān)聯(lián) 5.集合點(diǎn) 6.思考時(shí)間 1.事務(wù)：用戶自定義的一個(gè)標(biāo)識(shí)，用來(lái)衡量不同的操作所花費(fèi)的時(shí)間，事務(wù)時(shí)間反映的是一個(gè)操作過(guò)程的響應(yīng)時(shí)間。 2.參數(shù)化：參數(shù)化作為測(cè)試腳本中最基本的使用技巧，需要每個(gè)從事性能測(cè)試的小伙伴都能熟練掌握。 在測(cè)試工具中，每一個(gè)模擬用戶都是一個(gè)線程，而在我們的仿真模型里，每一個(gè)用戶都應(yīng)該是一個(gè)真實(shí)的業(yè)務(wù)實(shí)體，每個(gè)用戶代表的業(yè)務(wù)含義、他可以去處理的業(yè)務(wù)以及在處理業(yè)務(wù)的過(guò)程中可以操作的數(shù)據(jù)都應(yīng)該是不同的，這樣才可以更真實(shí)的表達(dá)現(xiàn)實(shí)世界中系統(tǒng)使用的負(fù)載模型。為了達(dá)到這個(gè)目的，將測(cè)

4、試工具的每一個(gè)線程和仿真模型中的每一個(gè)用戶及操作對(duì)應(yīng)起來(lái)，就需要使用到參數(shù)化的腳本處理。 說(shuō)的有些太嚴(yán)肅了，簡(jiǎn)單舉個(gè)例子，比如我們要測(cè)試用戶注冊(cè)的功能，注冊(cè)的用戶名是不允許重復(fù)的。我們錄制完 的 腳本都是hard code，直接進(jìn)行并發(fā)測(cè)試的話，無(wú)疑所有模擬用戶的線程在注冊(cè)的時(shí)候輸入的都是相同的用戶名和密碼，這樣肯定是會(huì)有很多錯(cuò)誤請(qǐng)求無(wú)法達(dá)到服務(wù)端，也就不能產(chǎn)生我們預(yù)期的負(fù)載壓力。這時(shí)候，針對(duì)用戶名就需要我們使用參數(shù)化的技巧來(lái)實(shí)現(xiàn)，每個(gè)注冊(cè)的用戶每次注冊(cè)都使用不同的用戶名來(lái)填寫(xiě)注冊(cè)信息。 3 .斷言: jmeter中有個(gè)元件叫做斷言（Assertion），它的作用和loadrunner中的檢查

5、點(diǎn)類(lèi)似； 用于檢查測(cè)試中得到的響應(yīng)數(shù)據(jù)等是否符合預(yù)期，用以保證性能測(cè)試過(guò)程中的數(shù)據(jù)交互與預(yù)期一致。 使用斷言的目的：在request的返回層面增加一層判斷機(jī)制；因?yàn)閞equest成功了，并不代表結(jié)果一定正確。 3.1.斷言與beanshell組合使用 . 首先存儲(chǔ)一個(gè)接口的響應(yīng)結(jié)果 . 變量存儲(chǔ)好后，再需要斷言的接口后面添加BeanShell斷言，使用Failrue來(lái)標(biāo)識(shí)斷言失敗，F(xiàn)ailureMessage標(biāo)示斷言失敗的原因， 4.關(guān)聯(lián)（correlation）：在腳本回放過(guò)程中，客戶端發(fā)出請(qǐng)求，通過(guò)關(guān)聯(lián)函數(shù)所定義的左右邊界值（也就是關(guān)聯(lián)規(guī)則），在服務(wù)器所響應(yīng)的內(nèi)容中查找，得到相應(yīng)的值，已變

6、量的形式替換錄制時(shí)的靜態(tài)值，從而向服務(wù)器發(fā)出正確的請(qǐng)求，這種動(dòng)態(tài)獲得服務(wù)器響應(yīng)內(nèi)容的方法被稱(chēng)作關(guān)聯(lián)。 5.集合點(diǎn)：集合點(diǎn)用以同步虛擬用戶，以便恰好在同一時(shí)刻執(zhí)行任務(wù)。在測(cè)試計(jì)劃中，可能會(huì)要求系統(tǒng)能夠承受1000 人同時(shí)提交數(shù)據(jù)，在LoadRunner 中可以通過(guò)在提交數(shù)據(jù)操作前面加入集合點(diǎn)，這樣當(dāng)虛擬用戶運(yùn)行到提交數(shù)據(jù)的集合點(diǎn)時(shí)，LoadRunner 就會(huì)檢查同時(shí)有多少用戶運(yùn)行到集合點(diǎn)，如果不到1000 人，LoadRunner 就會(huì)命令已經(jīng)到集合點(diǎn)的用戶在此等待，當(dāng)在集合點(diǎn)等待的用戶達(dá)到1000 人時(shí)，LoadRunner 命令1000 人同時(shí)去提交數(shù)據(jù)，從而達(dá)到測(cè)試計(jì)劃中的需求。 jmet

7、er也是，Number of Simulated Users to Group by的意思是分批執(zhí)行請(qǐng)求。當(dāng)線程數(shù)到達(dá)設(shè)置的數(shù)量后，才開(kāi)始發(fā)送請(qǐng)求。 例如設(shè)置為5，如果啟動(dòng)的線程數(shù)到了4是不發(fā)送請(qǐng)求的，之后當(dāng)再啟動(dòng)一個(gè)線程，線程數(shù)為5的時(shí)候才開(kāi)始發(fā)送請(qǐng)求。 這樣就相當(dāng)于設(shè)置了集合點(diǎn)。只有達(dá)到我們想要的并發(fā)線程數(shù)的時(shí)候才開(kāi)始并發(fā)。 如果我們的并發(fā)線程數(shù)為10，那我們就可以設(shè)置線程組的線程數(shù)為10，加個(gè)Synchronizing Timer，設(shè)置為10就可以。 Timout的意思是等待請(qǐng)求多久后，不管線程數(shù)有沒(méi)有到達(dá)設(shè)置的并發(fā)數(shù)量都開(kāi)始運(yùn)行測(cè)試。 6.思考時(shí)間：用戶自定義的一個(gè)標(biāo)識(shí)，用來(lái)衡量不同的

8、操作所花費(fèi)的時(shí)間，事務(wù)時(shí)間反映的是一個(gè)操作過(guò)程的響應(yīng)時(shí)間。Pacing：請(qǐng)求和請(qǐng)求之間的間隔 先明確一些概念： 1）定時(shí)器是在每個(gè)sampler（采樣器）之前執(zhí)行的，而不是之后； 是的，你沒(méi)有看錯(cuò)，不管這個(gè)定時(shí)器的位置放在sampler之后，還是之下，它都在sampler之前得到執(zhí)行。 2）定時(shí)器是有作用域的；當(dāng)執(zhí)行一個(gè)sampler之前時(shí)，所有當(dāng)前作用域內(nèi)的定時(shí)器都會(huì)被執(zhí)行； 3）如果希望定時(shí)器僅應(yīng)用于其中一個(gè)sampler，則把該定時(shí)器作為子節(jié)點(diǎn)加入； 4）如果希望在sampler執(zhí)行完之后再等待，則可使用Test Action；一、固定定時(shí)器（Constant Timer）毫無(wú)疑問(wèn)，這是

9、最重要的定時(shí)器。需要注意的是，固定定時(shí)器的延時(shí)不會(huì)計(jì)入單個(gè)sampler的響應(yīng)時(shí)間，但會(huì)計(jì)入事務(wù)控制器的時(shí)間。如下圖，固定定時(shí)器的時(shí)長(zhǎng)設(shè)為300毫秒。定時(shí)器時(shí)長(zhǎng)并不計(jì)入java請(qǐng)求的響應(yīng)時(shí)間，但被計(jì)入“事務(wù)控制器”的總時(shí)間如果你堅(jiān)持看到這里，并且對(duì)loadrunner的think time和pacing這兩個(gè)概念還有記憶的話，我們可以有答案了：對(duì)于“java請(qǐng)求”這個(gè)sampler來(lái)說(shuō)，定時(shí)器相當(dāng)于loadrunner中的pacing；對(duì)于“事務(wù)控制器”來(lái)說(shuō)，定時(shí)器相當(dāng)于loadrunner中的think time。我們通常說(shuō)的響應(yīng)時(shí)間，應(yīng)該大部分情況下是針對(duì)某一個(gè)具體的sampler（htt

10、p請(qǐng)求），而不是針對(duì)一組sampler組合的事務(wù) Contents目 錄 三.性能測(cè)試運(yùn)行及監(jiān)控介紹 1.性能測(cè)試腳本的運(yùn)行 2.性能測(cè)試資源的監(jiān)控 1.性能測(cè)試腳本的運(yùn)行： 1.1 .性能側(cè)測(cè)試幾種類(lèi)型的設(shè)置： . 基準(zhǔn)測(cè)試的設(shè)置： .負(fù)載測(cè)試的設(shè)置： .混合場(chǎng)景的設(shè)置： https:/ .穩(wěn)定性場(chǎng)景的設(shè)置： 1.2.腳本的運(yùn)行有兩種： 1.2.1.第一種： .設(shè)置線程組頁(yè)面 . 設(shè)置好的腳本放到壓力發(fā)起機(jī)上 . 運(yùn)行命令： .Jmeter -n -t /home/baseuser/ljd/zzt.jmx -l /home/baseuser/ljd/zzt.jtl -e -o /home/b

11、aseuser/ljd/wuliaoleixing .把收集到信息拉到本地電腦上-n表示以nogui方式運(yùn)行測(cè)試計(jì)劃-t表示測(cè)試計(jì)劃，后面跟測(cè)試計(jì)劃名稱(chēng)-l表示測(cè)試結(jié)果，后面跟測(cè)試結(jié)果文件名稱(chēng)1.2.2第二種： 負(fù)載運(yùn)行： 由于jmeter是java寫(xiě)的，效率沒(méi)loadrunner那么好，loadrunner是c語(yǔ)言寫(xiě)的. Jmeter是有一臺(tái)主控機(jī)來(lái)控制很多的負(fù)載機(jī)，client主動(dòng)去連 server, server只要打開(kāi)一個(gè)服務(wù)就行，腳本放在主控機(jī)上的，就是是這樣的一個(gè)過(guò)程。Saver上必須先安裝jmeter工具，然后改下配置文件。 修改配置文件如下： 在bin下面找到一個(gè)文件prope

12、rtics cd apache-jmeter-3.2/ cd bin ./jmeter-server 假設(shè)，我的腳本里線程設(shè)置100，那么3臺(tái)每臺(tái)Saver就300. Loadrunner可以每臺(tái)機(jī)器單獨(dú)設(shè)置，但jmeter不行2、在控制機(jī)執(zhí)行分布式命令jmeter -n -t testplan/comic.jmx -r -l testResult/result1.jtl 啟動(dòng)所有從機(jī)執(zhí)行腳本2.性能測(cè)試資源的監(jiān)控： 2 .1安裝工具nmon: (我這邊有下載的工具及安裝步驟） 2.2 用nmon 監(jiān)控工具收集后臺(tái)資源 收集命令： ./nmon_x86_64_centos6 -f -s 6 -

13、c 30 說(shuō)明：-f 以文件的形式輸出，默認(rèn)輸出是機(jī)器名+日期.nmon的格式，也可以用-F指定輸出的文件名，例如:-s是采樣頻率，隔多長(zhǎng)時(shí)間收集一次，這里我指定的是6秒一次；-c是采樣次數(shù)，一共要收集多少次，這里我指定的是30次。 2.3 用nmon分析工具形成圖表形式的文檔 分析工具：Contents目 錄 四.性能測(cè)試分析介紹 1. 操作系統(tǒng)性能監(jiān)控分析（cpu，內(nèi)存， 磁盤(pán)io） 2.jvm堆模型，gc垃圾收集監(jiān)控分析 3. tomca(中間件）監(jiān)控分析 4.針對(duì)錯(cuò)誤提示信息的分析 1.1 .cpu : 單線程死鎖 這個(gè)判斷 流程比較多，生產(chǎn)上基本不會(huì)有問(wèn)題， 1.2 .查看cpu利用

14、率比較高的線程實(shí)現(xiàn)： 1.L 1.3 .cpu常用命令詳解： uptime： 滿足什么會(huì)于運(yùn)行對(duì)列： 1.沒(méi)有在等待i/o操作的結(jié)果 2.沒(méi)有主動(dòng)進(jìn)入等待狀態(tài)（沒(méi)有調(diào)用“wait”） 3.沒(méi)有被停止（等待終止）L 1.3 .cpu常用命令詳解： top： L 1.3 .cpu常用命令詳解： top： L buffer和cache的作用是縮短i/0系統(tǒng)的調(diào)用的時(shí)間，比如讀寫(xiě)等，一般一個(gè)系統(tǒng) 而言，如果 cache的值越大，說(shuō)明cache住的文件數(shù)多，如果頻繁地訪問(wèn)文件都能被命中，很明顯會(huì)比讀取磁盤(pán)調(diào)用快，磁盤(pán)的io必定會(huì)減小。 cache的命中率是關(guān)鍵，如果頻繁訪問(wèn)的文件不能被命中，對(duì)cache

15、而言是個(gè)比較大的資源浪費(fèi)，此時(shí)應(yīng)考慮drop cache并且提升對(duì)應(yīng)的cache命中率。命令： Free -m sync Echo 3 /proc/sys/vm/drop _caches L 1.2 .內(nèi)存： 內(nèi)存使用率：內(nèi)存使用率=（1-空閑內(nèi)存/總內(nèi)存大?。?100% 或 內(nèi)存使用率=（總內(nèi)存-空閑內(nèi)存-cached緩存-buffers緩存）/總內(nèi)存 內(nèi)存使用率：無(wú)性能壓力：0%50%、有一定性能壓力：50%70%、達(dá)到性能閥值：70%80%、嚴(yán)重性能問(wèn)題：80%100%內(nèi)存使用率長(zhǎng)時(shí)間處于95%以上 -P1級(jí)bug內(nèi)存使用率長(zhǎng)時(shí)間處于90%以上 -P2級(jí)bug 1.2 .磁盤(pán)： IO瓶頸

16、往往是我們可能會(huì)忽略的地方（我們常會(huì)看top、free、netstat等等，但經(jīng)常會(huì)忽略IO的負(fù)載情況），今天給大家詳細(xì)分享一下如何確認(rèn)一臺(tái)服務(wù)器的IO負(fù)載是否到達(dá)了瓶頸，以及可能優(yōu)化、定位的點(diǎn)。 先來(lái)看一臺(tái)典型的IO密集型服務(wù)器的cpu統(tǒng)計(jì)圖： 可以看到，CPU總使用率不高，平均1.1%，max到5.6%，雖然大部分都耗在了iowait上，但才百分之五左右，應(yīng)該還沒(méi)到瓶頸吧？這里要特別注意：iowaitIO負(fù)載，要看真實(shí)的IO負(fù)載情況，一般使用iostat x 命令$ iostat x 1avg-cpu: %user %nice %system %iowait %steal %idle 0.

17、04 0.00 0.04 4.99 0.00 94.92Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %utilsda 0.00 81.00 104.00 4.00 13760.00 680.00 133.70 2.08 19.29 9.25 99.90sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00sda3

18、 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00sda4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00sda5 0.00 81.00 104.00 4.00 13760.00 680.00 133.70 2.08 19.29 9.25 99.90這里重點(diǎn)指標(biāo)是svctm和util這兩列svctm指的是“平均每次設(shè)備I/O操作的服務(wù)時(shí)間 (毫秒)”%util指的是“一秒鐘I/O 操作的利用率，或者說(shuō)一秒中有多少時(shí)間 I/O 隊(duì)列是非空的?！蔽覀冞@里發(fā)現(xiàn)%util已經(jīng)接近1

19、00%，可以知道其實(shí)目前這臺(tái)服務(wù)器的IO已經(jīng)到達(dá)瓶頸了。那為什么最前面的cpu統(tǒng)計(jì)圖的iowait項(xiàng)只有5.5%左右呢？因?yàn)檫@個(gè)iowait（也就是top里的wa%）指的是從整體來(lái)看，CPU等待IO的耗時(shí)占比：%wa iowait也就是說(shuō)，CPU拿出一部分時(shí)間來(lái)等待IO完成（iowait），但從磁盤(pán)的角度看，磁盤(pán)的利用率已經(jīng)滿了（util%），這種情況下，CPU使用率 可能不高，但是系統(tǒng)整體QPS已經(jīng)上不去了，如果加大流量，會(huì)導(dǎo)致單次IO耗時(shí)的繼續(xù)增加（因?yàn)镮O請(qǐng)求都堵在隊(duì)列里了），從而影響系統(tǒng)整體的處理性能。確認(rèn)了IO負(fù)載過(guò)高后，可以使用iotop工具具體查看IO負(fù)載主要是落在哪個(gè)進(jìn)程上了。

20、詳解iostat 命令rrqm/s: 每秒進(jìn)行 merge 的讀操作數(shù)目。wrqm/s: 每秒進(jìn)行 merge 的寫(xiě)操作數(shù)目。r/s: 每秒完成的讀 I/O 設(shè)備次數(shù)。w/s: 每秒完成的寫(xiě) I/O 設(shè)備次數(shù)。rsec/s: 每秒讀扇區(qū)數(shù)。wsec/s: 每秒寫(xiě)扇區(qū)數(shù)。rkB/s: 每秒讀字節(jié)數(shù)。wkB/s: 每秒寫(xiě)字節(jié)數(shù)。avgrq-sz: 平均每次設(shè)備I/O操作的數(shù)據(jù)大小 (扇區(qū))。avgqu-sz: 平均I/O隊(duì)列長(zhǎng)度。await: 平均每次設(shè)備I/O操作的等待時(shí)間 (毫秒)。svctm: 平均每次設(shè)備I/O操作的服務(wù)時(shí)間 (毫秒)。%util: 一秒中有百分之多少的時(shí)間用于 I/O 操

21、作(使用率)或者說(shuō)一秒中有多少時(shí)間 I/O 隊(duì)列是非空的。如果 %util 接近 100%，說(shuō)明產(chǎn)生的I/O請(qǐng)求太多，I/O系統(tǒng)已經(jīng)滿負(fù)荷，該磁盤(pán)可能存在瓶頸。await: await的大小一般取決于服務(wù)時(shí)間(svctm) 以及 I/O 隊(duì)列的長(zhǎng)度和 I/O 請(qǐng)求的發(fā)出模式。如果 svctm 比較接近 await，說(shuō)明I/O 幾乎沒(méi)有等待時(shí)間；如果 await 遠(yuǎn)大于 svctm，說(shuō)明 I/O隊(duì)列太長(zhǎng)，應(yīng)用得到的響應(yīng)時(shí)間變慢，r/s+w/s 類(lèi)似于交款人的總數(shù)平均隊(duì)列長(zhǎng)度(avgqu-sz)類(lèi)似于單位時(shí)間里平均排隊(duì)人的個(gè)數(shù)平均服務(wù)時(shí)間(svctm)類(lèi)似于收銀員的收款速度平均等待時(shí)間(await

22、)類(lèi)似于平均每人的等待時(shí)間平均I/O數(shù)據(jù)(avgrq-sz)類(lèi)似于平均每人所買(mǎi)的東西多少I(mǎi)/O 操作率 (%util)類(lèi)似于收款臺(tái)前有人排隊(duì)的時(shí)間比例。 2.jvm堆模型，gc垃圾收集監(jiān)控分析 內(nèi)存的溢出: Out Of memory Java虛擬機(jī)中的OOm 內(nèi)存的溢出可能有兩種：1.代碼寫(xiě)的不好 2.堆內(nèi)存分配的太小了 此處代碼演示 -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=C:/ 2.2堆內(nèi)存的重點(diǎn)： 這里有兩點(diǎn)：GC:不會(huì)導(dǎo)致java程序的暫停，快速的收集下就可以了FULL GC :但是一旦發(fā)生fu

23、ll gc ，java里有一個(gè)非常重要的概念 stop the word ，用戶的線程就全部胡暫停了。 假設(shè)在大量并發(fā)時(shí)，在大量的full gc ，用戶的線程暫停了，就會(huì)影響速度。這里經(jīng)歷了兩次full gc 任然不能回收，就內(nèi)存溢出了 DefNew:年輕代，串行垃圾回收器5478K-640K(6144K):執(zhí)行前，之行后，(6144K)新生代最大的大小0.0205187 secs：所花的時(shí)間Times: user=0.02 sys=0.00, real=0.02 secs ：回收時(shí),用戶占了多少時(shí)間，系統(tǒng)太占了多少時(shí)間，真實(shí)的人的感受時(shí)間Tenured：老年代回收 Metaspace：永久代

24、回收Full gc :整個(gè)堆回收 命令行工具：Jstatjmp 主要看FGC，值不能太大 S0C：年輕代中第一個(gè)survivor（幸存區(qū)）的容量 (字節(jié)) S1C：年輕代中第二個(gè)survivor（幸存區(qū)）的容量 (字節(jié)) S0U：年輕代中第一個(gè)survivor（幸存區(qū)）目前已使用空間 (字節(jié)) S1U：年輕代中第二個(gè)survivor（幸存區(qū)）目前已使用空間 (字節(jié)) EC：年輕代中Eden（伊甸園）的容量 (字節(jié)) EU：年輕代中Eden（伊甸園）目前已使用空間 (字節(jié)) OC：Old代的容量 (字節(jié)) OU：Old代目前已使用空間 (字節(jié)) PC：Perm(持久代)的容量 (字節(jié)) PU：P

25、erm(持久代)目前已使用空間 (字節(jié)) YGC：從應(yīng)用程序啟動(dòng)到采樣時(shí)年輕代中g(shù)c次數(shù) YGCT：從應(yīng)用程序啟動(dòng)到采樣時(shí)年輕代中g(shù)c所用時(shí)間(s) FGC：從應(yīng)用程序啟動(dòng)到采樣時(shí)old代(全gc)gc次數(shù) FGCT：從應(yīng)用程序啟動(dòng)到采樣時(shí)old代(全gc)gc所用時(shí)間(s) GCT：從應(yīng)用程序啟動(dòng)到采樣時(shí)gc用的總時(shí)間(s) NGCMN：年輕代(young)中初始化(最小)的大小 (字節(jié)) NGCMX：年輕代(young)的最大容量 (字節(jié)) NGC：年輕代(young)中當(dāng)前的容量 (字節(jié)) OGCMN：old代中初始化(最小)的大小 (字節(jié)) OGCMX：old代的最大容量 (字節(jié)) O

26、GC：old代當(dāng)前新生成的容量 (字節(jié)) PGCMN：perm代中初始化(最小)的大小 (字節(jié)) PGCMX：perm代的最大容量 (字節(jié)) PGC：perm代當(dāng)前新生成的容量 (字節(jié)) S0：年輕代中第一個(gè)survivor（幸存區(qū)）已使用的占當(dāng)前容量百分比 S1：年輕代中第二個(gè)survivor（幸存區(qū)）已使用的占當(dāng)前容量百分比 E：年輕代中Eden（伊甸園）已使用的占當(dāng)前容量百分比 O：old代已使用的占當(dāng)前容量百分比 P：perm代已使用的占當(dāng)前容量百分比 S0CMX：年輕代中第一個(gè)survivor（幸存區(qū)）的最大容量 (字節(jié)) S1CMX ：年輕代中第二個(gè)survivor（幸存區(qū)）的最大

27、容量 (字節(jié)) ECMX：年輕代中Eden（伊甸園）的最大容量 (字節(jié)) DSS：當(dāng)前需要survivor（幸存區(qū)）的容量 (字節(jié))（Eden區(qū)已滿） TT： 持有次數(shù)限制 MTT ： 最大持有次數(shù)限制 主要看FGC，值不能太大4.1 JVM 調(diào)優(yōu)對(duì)于jvm調(diào)優(yōu)的主要目的是減少GC的頻率和Full GC 的次數(shù)，過(guò)多的GC和Full GC會(huì)占用很多的系統(tǒng)資源（主要是CPU）影響系統(tǒng)的吞吐量，特別要關(guān)注Full GC，因?yàn)樗菍?duì)整個(gè)堆進(jìn)行整理，導(dǎo)致Full GC 的一般幾種情況：1.老年代空間不足2.調(diào)優(yōu)時(shí)盡量讓對(duì)象在新生代GC被回收，讓新生代多存活一段時(shí)間和不要?jiǎng)?chuàng)建過(guò)大的對(duì)象以及數(shù)組避免直接在老年代創(chuàng)建對(duì)象3.增加持久代的空間4.垃圾回收機(jī)制不要手動(dòng)觸發(fā)(System.gc()，盡量依靠JVN的自身的回收機(jī)制調(diào)優(yōu)過(guò)程主要是通過(guò)控制堆內(nèi)存的各個(gè)部分的比例和GC的策略來(lái)實(shí)現(xiàn)，下面看一下各比例不良導(dǎo)致的一些情況：1.新生代設(shè)置過(guò)小一是新生代GC數(shù)非常頻繁，增大系統(tǒng)消耗，二是導(dǎo)致大對(duì)象直接進(jìn)入老年代，占據(jù)老年代的剩余空間，誘發(fā)Full GC2.新生代設(shè)置過(guò)大一是新生代設(shè)置過(guò)大會(huì)導(dǎo)致老年代過(guò)小(堆的大小是一定的)，從而誘發(fā)