存溢出深度解析：從JVM調(diào)優(yōu)到分布式壓測的完整解決方案)
1. 項目概述JMeter內(nèi)存溢出性能測試工程師的“頭號公敵”如果你正在用JMeter做性能測試尤其是模擬高并發(fā)或者長時間運(yùn)行的壓測場景那么屏幕前突然彈出的那個“java.lang.OutOfMemoryError: Java heap space”錯誤大概率會讓你心頭一緊測試進(jìn)度瞬間中斷。這個錯誤就是我們常說的JMeter內(nèi)存溢出。它不是什么高深的玄學(xué)問題而是每一個性能測試工程師在進(jìn)階路上幾乎必然會遇到的“攔路虎”。簡單來說它就是JMeter這個Java程序在運(yùn)行過程中向JVMJava虛擬機(jī)申請的內(nèi)存不夠用了導(dǎo)致程序崩潰。但背后的原因遠(yuǎn)不止“內(nèi)存不夠”這么簡單可能涉及腳本設(shè)計、監(jiān)聽器使用、測試策略乃至JVM調(diào)優(yōu)等多個層面。今天我就結(jié)合自己這些年踩過的坑和填過的坑把這個問題的來龍去脈、解決思路和實(shí)操細(xì)節(jié)掰開揉碎了講清楚。無論你是剛接觸JMeter的新手還是正在被大并發(fā)壓測困擾的老手這篇文章都能給你一套從診斷到根治的完整方案。2. 內(nèi)存溢出根因深度剖析不只是“內(nèi)存太小”在動手解決問題之前我們必須先搞清楚JMeter為什么會“吃”掉那么多內(nèi)存。很多人一看到“Java heap space”第一反應(yīng)就是去改JVM參數(shù)把-Xmx調(diào)大。這固然是一種方法但往往是治標(biāo)不治本甚至可能讓問題惡化。我們需要像偵探一樣層層深入。2.1 JVM內(nèi)存模型與JMeter的運(yùn)行機(jī)制JMeter是一個100%純Java開發(fā)的桌面應(yīng)用它的所有運(yùn)行都依賴于JVM。JVM的內(nèi)存區(qū)域主要分為堆Heap、棧Stack、方法區(qū)Metaspace等。對于JMeter內(nèi)存溢出我們最需要關(guān)注的是堆內(nèi)存。堆內(nèi)存Heap這是JVM中最大的一塊內(nèi)存區(qū)域幾乎所有通過new關(guān)鍵字創(chuàng)建的對象實(shí)例和數(shù)組都存放在這里。它也是垃圾回收器Garbage Collector, GC主要管理的區(qū)域。JMeter在運(yùn)行測試時會創(chuàng)建大量的對象每一個虛擬用戶線程的上下文信息、每一個HTTP請求和響應(yīng)的數(shù)據(jù)、監(jiān)聽器收集的采樣結(jié)果等等都會在堆中分配內(nèi)存。內(nèi)存溢出OOM的本質(zhì)當(dāng)JMeter應(yīng)用程序創(chuàng)建的這些對象總量超過了JVM堆內(nèi)存的最大容量由-Xmx參數(shù)設(shè)定并且垃圾回收器經(jīng)過多次努力也無法回收足夠的空閑內(nèi)存來容納新對象時JVM就會拋出OutOfMemoryError: Java heap space錯誤導(dǎo)致JMeter進(jìn)程崩潰。2.2 導(dǎo)致JMeter堆內(nèi)存暴漲的四大“元兇”根據(jù)我的經(jīng)驗JMeter內(nèi)存溢出很少是單一原因造成的通常是以下幾個因素共同作用的結(jié)果高并發(fā)線程數(shù)這是最直接的因素。啟動的線程數(shù)越多每個線程獨(dú)立維護(hù)的上下文如Cookie管理器、緩存、變量等就越多瞬間創(chuàng)建的對象數(shù)量呈線性甚至指數(shù)級增長。一個配置不當(dāng)?shù)那Ъ壊l(fā)測試足以在幾秒內(nèi)撐爆默認(rèn)的1GB堆內(nèi)存。“貪婪”的監(jiān)聽器這是新手最容易踩的巨坑。JMeter的監(jiān)聽器特別是查看結(jié)果樹View Results Tree和聚合報告Aggregate Report在默認(rèn)設(shè)置下會在內(nèi)存中完整保存每一個請求的響應(yīng)數(shù)據(jù)。想象一下你進(jìn)行一輪10萬次請求的測試如果每個響應(yīng)體平均10KB“查看結(jié)果樹”監(jiān)聽器就會試圖在內(nèi)存中保留將近1GB的原始數(shù)據(jù)這還沒算上對象本身的內(nèi)存開銷。這就是為什么在命令行執(zhí)行壓測時必須禁用這些監(jiān)聽器。腳本設(shè)計缺陷腳本邏輯不當(dāng)也會導(dǎo)致內(nèi)存無法釋放。不合理的循環(huán)或定時器可能導(dǎo)致請求無限堆積。大型文件的參數(shù)化使用CSV Data Set Config讀取一個巨大的文件如幾十萬行的用戶數(shù)據(jù)并且設(shè)置為“All threads”共享模式這會把整個文件加載到內(nèi)存中。正則表達(dá)式或JSON提取器處理超大響應(yīng)如果從一個巨大的響應(yīng)體中提取數(shù)據(jù)提取出的變量可能會占用大量內(nèi)存。JVM垃圾回收GC效率低下即使對象不再被引用也需要垃圾回收器來回收內(nèi)存。如果堆內(nèi)存設(shè)置得過小會導(dǎo)致GC異常頻繁稱為“GC Thrashing”大量CPU時間被用于垃圾回收而非執(zhí)行測試整體吞吐量下降同時GC本身也會產(chǎn)生臨時對象進(jìn)一步加劇內(nèi)存壓力。反之如果堆內(nèi)存設(shè)置得過大單次GC的停頓時間Stop-The-World會很長可能導(dǎo)致JMeter響應(yīng)遲緩。注意很多人誤以為“內(nèi)存泄漏”是主因。在JMeter標(biāo)準(zhǔn)腳本中真正的內(nèi)存泄漏即對象永遠(yuǎn)無法被GC回收并不常見。更多情況是短期內(nèi)的對象創(chuàng)建速率遠(yuǎn)遠(yuǎn)高于垃圾回收速率屬于“內(nèi)存壓力”過大而非嚴(yán)格意義上的泄漏。但設(shè)計糟糕的插件或自定義代碼可能導(dǎo)致泄漏。3. 系統(tǒng)性解決方案從調(diào)優(yōu)到架構(gòu)的進(jìn)階之路解決內(nèi)存溢出我推薦一個從易到難、從內(nèi)到外的系統(tǒng)性排查和解決路徑先優(yōu)化腳本和配置再調(diào)整JVM參數(shù)最后考慮架構(gòu)升級。3.1 第一步腳本與配置優(yōu)化成本最低效果顯著這是你應(yīng)該首先嘗試的往往能解決80%的問題。精簡或禁用監(jiān)聽器非GUI模式命令行執(zhí)行壓測時務(wù)必禁用所有非必要的監(jiān)聽器。使用-l參數(shù)指定結(jié)果保存為JTL文件后續(xù)再用GUI模式打開聚合報告等監(jiān)聽器進(jìn)行分析。在GUI模式設(shè)計調(diào)試腳本時永遠(yuǎn)不要開啟“查看結(jié)果樹”去進(jìn)行壓測。它僅用于調(diào)試單個請求。調(diào)試完畢后務(wù)必禁用或刪除它。使用更“輕量”的監(jiān)聽器。比如用“聚合報告”代替“圖形結(jié)果”前者只存儲統(tǒng)計摘要不存原始數(shù)據(jù)。實(shí)操技巧我習(xí)慣在測試計劃中單獨(dú)創(chuàng)建一個“調(diào)試線程組”里面只放一兩個線程和“查看結(jié)果樹”。正式的壓測線程組里一個監(jiān)聽器都不放。通過${__P(test.type,)}屬性來動態(tài)控制是否啟用調(diào)試線程組。優(yōu)化腳本邏輯清理不必要的測試數(shù)據(jù)定期使用“清除”按鈕掃帚圖標(biāo)清除已有結(jié)果。合理使用CSV數(shù)據(jù)文件對于大型參數(shù)文件使用CSV Data Set Config時將“共享模式”設(shè)置為Current thread group或Current thread避免全局共享導(dǎo)致全量加載。考慮使用__StringFromFile或__File函數(shù)進(jìn)行按需讀取。限制響應(yīng)數(shù)據(jù)保存在HTTP請求等取樣器中可以只保存必要的部分。對于不需要檢查的響應(yīng)可以勾選“Save response as MD5 hash?”來僅保存哈希值極大減少內(nèi)存占用。謹(jǐn)慎使用后置處理器避免使用正則表達(dá)式提取器處理巨大的響應(yīng)體。如果必須處理確保表達(dá)式是精確的避免“貪婪匹配”導(dǎo)致內(nèi)存占用過高。3.2 第二步JVM堆內(nèi)存調(diào)優(yōu)對癥下藥量力而行當(dāng)腳本優(yōu)化到極致后如果仍需支撐更大規(guī)模的測試就需要調(diào)整JMeter啟動時的JVM參數(shù)了。這是直接解決“Java heap space”錯誤的方法。定位配置文件Windows系統(tǒng)編輯jmeter.bat或jmeter腳本如果你用的是jmeter而不是jmeter.bat。Linux/Mac系統(tǒng)編輯jmeterShell腳本或jmeter.sh。關(guān)鍵參數(shù)解析與修改 打開配置文件找到設(shè)置HEAP環(huán)境變量的部分。通常看起來像這樣set HEAP-Xms1g -Xmx1g -XX:MaxMetaspaceSize256m我們需要修改的是-Xms和-Xmx以及可能添加新生代參數(shù)。-Xms: 堆內(nèi)存的初始大小。例如-Xms512m表示啟動時分配512MB。-Xmx: 堆內(nèi)存的最大大小。例如-Xmx4g表示最大可以擴(kuò)展到4GB。-XX:NewSize 和 -XX:MaxNewSize: 設(shè)置新生代Young Generation的初始和最大大小。新生代是大部分新對象產(chǎn)生和死亡的地方頻繁的Minor GC發(fā)生于此。合理設(shè)置可以提升GC效率。一個經(jīng)過實(shí)戰(zhàn)檢驗的配置示例針對一臺擁有16GB物理內(nèi)存的壓測機(jī)set HEAP-Xms2g -Xmx8g set NEW-XX:NewSize1g -XX:MaxNewSize2g修改說明將最大堆內(nèi)存-Xmx從默認(rèn)的1g提升到8g。這里有個重要原則-Xmx值最好不要超過你物理內(nèi)存的50%-70%。因為操作系統(tǒng)、JMeter GUI如果使用、以及其他進(jìn)程都需要內(nèi)存。設(shè)為8g對于16g的機(jī)器是一個比較安全的值。將初始堆內(nèi)存-Xms也設(shè)為2g避免運(yùn)行時頻繁向系統(tǒng)申請內(nèi)存。顯式設(shè)置了新生代大小。對于JMeter這種會創(chuàng)建大量短生命周期對象如每次請求的響應(yīng)對象的應(yīng)用給新生代分配較大空間如堆的1/4到1/2是有益的可以讓這些對象在新生代的Minor GC中就被快速回收避免過早進(jìn)入老年代。這里設(shè)置了1g初始最大2g。修改步驟用文本編輯器如Notepad以管理員身份打開jmeter.bat。搜索“HEAP”關(guān)鍵字。將原配置替換為上述示例配置。保存文件。重啟JMeter必須重啟修改才會生效。重要心得-Xmx不是越大越好設(shè)置過大例如超過物理內(nèi)存會導(dǎo)致操作系統(tǒng)使用硬盤交換分區(qū)Swap性能急劇下降JMeter會變得奇卡無比甚至引發(fā)更嚴(yán)重的系統(tǒng)級問題。始終監(jiān)控壓測機(jī)的整體內(nèi)存使用情況通過任務(wù)管理器或top命令確保還有充足的空余內(nèi)存。3.3 第三步進(jìn)階與分布式壓測終極方案如果單臺機(jī)器即使優(yōu)化了腳本和JVM參數(shù)仍無法滿足你的并發(fā)要求例如需要模擬上萬用戶那么你必須考慮分布式壓測。分布式壓測原理 由一臺機(jī)器作為控制機(jī)Controller負(fù)責(zé)管理測試、分發(fā)腳本、收集結(jié)果。其他多臺機(jī)器作為施壓機(jī)Agent/Slave實(shí)際執(zhí)行測試計劃生成負(fù)載。這樣負(fù)載和內(nèi)存消耗就被分?jǐn)偟搅硕嗯_機(jī)器上。實(shí)施步驟環(huán)境準(zhǔn)備在所有機(jī)器控制機(jī)和施壓機(jī)上安裝相同版本的JMeter和JDK。配置施壓機(jī)在每個施壓機(jī)上運(yùn)行jmeter-server.batWindows或jmeter-serverLinux/Mac啟動服務(wù)。默認(rèn)使用1099端口。配置控制機(jī)編輯控制機(jī)上的jmeter.properties文件找到remote_hosts配置項添加所有施壓機(jī)的IP地址和端口例如remote_hosts192.168.1.101:1099,192.168.1.102:1099。運(yùn)行測試在控制機(jī)GUI中選擇“運(yùn)行” - “遠(yuǎn)程啟動”來啟動指定或所有施壓機(jī)。或者在命令行使用-R 192.168.1.101:1099,192.168.1.102:1099參數(shù)。分布式壓測的注意事項網(wǎng)絡(luò)帶寬控制機(jī)和施壓機(jī)之間、施壓機(jī)和被測系統(tǒng)之間需要有高速、穩(wěn)定的網(wǎng)絡(luò)連接否則網(wǎng)絡(luò)可能成為瓶頸。數(shù)據(jù)文件同步如果腳本中使用CSV等參數(shù)化文件需要確保所有施壓機(jī)上的文件路徑和內(nèi)容一致。可以使用共享存儲如NFS或腳本同步工具。時鐘同步所有機(jī)器的時間應(yīng)基本同步以確保日志時間戳一致。防火墻確保1099端口以及可能用到的其他高端口在施壓機(jī)上是開放的允許控制機(jī)訪問。4. 實(shí)戰(zhàn)排查與監(jiān)控當(dāng)問題發(fā)生時如何快速定位即使做好了預(yù)防在復(fù)雜的測試場景中內(nèi)存溢出仍可能發(fā)生。這時我們需要一套排查方法。4.1 問題現(xiàn)象與初步判斷GUI界面卡死無響應(yīng)可能是堆內(nèi)存即將耗盡GC占用了幾乎所有CPU時間。命令行模式測試突然中止在日志中控制臺或jmeter.log文件看到明確的java.lang.OutOfMemoryError: Java heap space錯誤。錯誤率伴隨測試進(jìn)行逐漸升高在聚合報告中隨著測試時間推移錯誤率特別是超時錯誤不斷上升可能是內(nèi)存不足導(dǎo)致處理請求變慢。4.2 使用監(jiān)控工具定位瓶頸JMeter自身監(jiān)聽器PerfMon Metrics Collector這是一個插件監(jiān)聽器需要安裝。它可以監(jiān)控施壓機(jī)本身的系統(tǒng)資源包括內(nèi)存使用率、CPU、磁盤IO等。將它添加到測試計劃中連接到localhost可以實(shí)時看到JMeter進(jìn)程的內(nèi)存消耗曲線。如果曲線持續(xù)增長直至接近-Xmx設(shè)定值然后崩潰這就是典型的內(nèi)存溢出。JVM內(nèi)置工具jConsole / jVisualVM隨JDK分發(fā)。連接到JMeter進(jìn)程本地或遠(yuǎn)程可以直觀看到堆內(nèi)存、永久代、線程、類的實(shí)時使用情況甚至可以進(jìn)行堆轉(zhuǎn)儲Heap Dump分析。命令行監(jiān)控在啟動JMeter時添加JVM參數(shù)-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:gc.log可以將詳細(xì)的GC日志輸出到文件。分析這個日志可以看GC頻率、暫停時間、回收效果判斷是否是GC問題。4.3 生成與分析堆轉(zhuǎn)儲Heap Dump這是最強(qiáng)大的終極手段可以告訴你堆里到底塞滿了什么對象。生成堆轉(zhuǎn)儲在出現(xiàn)OOM時JVM自動生成添加JVM參數(shù)-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump.hprof。手動生成使用jmap工具或通過jVisualVM觸發(fā)。分析堆轉(zhuǎn)儲 使用專業(yè)工具分析生成的.hprof文件Eclipse MAT (Memory Analyzer Tool)功能強(qiáng)大是首選。它可以自動分析泄漏疑點(diǎn)生成報告告訴你哪個對象占用了最多的內(nèi)存以及是誰在引用它。jVisualVM內(nèi)置分析功能但相對簡單。分析思路打開堆轉(zhuǎn)儲后通常查看“Histogram”直方圖或“Dominator Tree”支配樹。按“Retained Heap”支配內(nèi)存排序排在最前面的類就是內(nèi)存消耗的“罪魁禍?zhǔn)住薄Ｔ贘Meter的上下文中你很可能會發(fā)現(xiàn)大量byte[]響應(yīng)體數(shù)據(jù)、SampleResult對象采樣結(jié)果、或者某些監(jiān)聽器相關(guān)的對象。這就能直接印證我們之前的判斷——是不是監(jiān)聽器沒關(guān)是不是某個請求的響應(yīng)太大了5. 常見問題與避坑指南實(shí)錄這里記錄了我自己和團(tuán)隊在多年實(shí)踐中遇到的一些典型問題和解決技巧。Q1: 我已經(jīng)把-Xmx調(diào)到很大了比如機(jī)器32G我設(shè)了24G但JMeter啟動很慢運(yùn)行也卡甚至還是報OOM。原因與解決這很可能觸發(fā)了“大內(nèi)存頁”和GC停頓問題。過大的堆會導(dǎo)致單次Full GC停頓時間極長表現(xiàn)為程序“卡死”。此外JVM自身管理大堆也需要開銷。解決方案回歸根本首先嚴(yán)格執(zhí)行3.1節(jié)的腳本優(yōu)化特別是禁用監(jiān)聽器。考慮使用G1垃圾回收器它專為減少大堆的停頓時間而設(shè)計。在JMeter啟動參數(shù)中添加-XX:UseG1GC -XX:MaxGCPauseMillis200。這告訴JVM使用G1回收器并目標(biāo)設(shè)定每次GC停頓不超過200毫秒。如果真的需要極大并發(fā)請果斷采用分布式壓測而不是無限制調(diào)高單機(jī)堆內(nèi)存。Q2: 在非GUI命令行模式下運(yùn)行已經(jīng)用了-n和-l但內(nèi)存還是增長得很快。原因雖然禁用了GUI但測試計劃中可能仍然包含了消耗內(nèi)存的監(jiān)聽器如聚合報告如果配置了保存所有數(shù)據(jù)、或者后置處理器產(chǎn)生了大量數(shù)據(jù)。排查使用-t指定測試計劃后用-p或--propfile指定一個只包含最精簡配置的.properties文件。或者在GUI中創(chuàng)建一個絕對干凈的測試計劃無任何監(jiān)聽器再保存為jmx文件用于命令行執(zhí)行。Q3: 分布式壓測時控制機(jī)也報OOM了。原因控制機(jī)雖然不產(chǎn)生負(fù)載但它要收集所有施壓機(jī)返回的樣本結(jié)果。如果線程數(shù)極多、測試時間長收集的結(jié)果數(shù)據(jù)量也會非常龐大。解決在控制機(jī)的jmeter.properties中同樣需要調(diào)大-Xmx。更關(guān)鍵的是在控制機(jī)上配置結(jié)果收集的優(yōu)化。例如使用“聚合報告”監(jiān)聽器時可以勾選“Save Table Data (CSV)”而不是將數(shù)據(jù)全留在內(nèi)存中。或者讓每個施壓機(jī)將結(jié)果直接寫入本地文件使用-l參數(shù)測試結(jié)束后再手動合并分析。Q4: 調(diào)整了JVM參數(shù)但似乎沒生效檢查點(diǎn)確認(rèn)你修改的是啟動JMeter時實(shí)際使用的腳本文件。如果你通過桌面快捷方式啟動它可能指向了另一個副本。修改后必須關(guān)閉所有JMeter窗口并重新啟動。在JMeter啟動時查看控制臺命令行窗口輸出的前幾行日志通常會打印出JVM參數(shù)確認(rèn)你設(shè)置的-Xms和-Xmx是否已正確加載。一個關(guān)鍵的避坑技巧始終使用版本管理對于JMeter的測試腳本.jmx和配置文件.properties, .bat我強(qiáng)烈建議使用Git等版本管理工具。在調(diào)整JVM參數(shù)、修改腳本配置后進(jìn)行提交并寫好注釋。這樣當(dāng)某次測試出現(xiàn)內(nèi)存問題時你可以快速回溯到之前的穩(wěn)定版本進(jìn)行對比精準(zhǔn)定位是哪個改動引入了問題。這比憑記憶要可靠得多。內(nèi)存溢出問題本質(zhì)上是資源管理與需求之間的博弈。解決它沒有一勞永逸的銀彈而是一個“優(yōu)化腳本 - 調(diào)整JVM - 升級架構(gòu)”的持續(xù)過程。掌握這套方法論你就能從容應(yīng)對各種規(guī)模的性能測試挑戰(zhàn)讓JMeter真正成為你手中穩(wěn)定可靠的壓測利器。 JMeter內(nèi)存溢出深度解析：從JVM調(diào)優(yōu)到分布式壓測的完整解決方案
1. 項目概述JMeter內(nèi)存溢出性能測試工程師的“頭號公敵”如果你正在用JMeter做性能測試尤其是模擬高并發(fā)或者長時間運(yùn)行的壓測場景那么屏幕前突然彈出的那個“java.lang.OutOfMemoryError: Java heap space”錯誤大概率會讓你心頭一緊測試進(jìn)度瞬間中斷。這個錯誤就是我們常說的JMeter內(nèi)存溢出。它不是什么高深的玄學(xué)問題而是每一個性能測試工程師在進(jìn)階路上幾乎必然會遇到的“攔路虎”。簡單來說它就是JMeter這個Java程序在運(yùn)行過程中向JVMJava虛擬機(jī)申請的內(nèi)存不夠用了導(dǎo)致程序崩潰。但背后的原因遠(yuǎn)不止“內(nèi)存不夠”這么簡單可能涉及腳本設(shè)計、監(jiān)聽器使用、測試策略乃至JVM調(diào)優(yōu)等多個層面。今天我就結(jié)合自己這些年踩過的坑和填過的坑把這個問題的來龍去脈、解決思路和實(shí)操細(xì)節(jié)掰開揉碎了講清楚。無論你是剛接觸JMeter的新手還是正在被大并發(fā)壓測困擾的老手這篇文章都能給你一套從診斷到根治的完整方案。2. 內(nèi)存溢出根因深度剖析不只是“內(nèi)存太小”在動手解決問題之前我們必須先搞清楚JMeter為什么會“吃”掉那么多內(nèi)存。很多人一看到“Java heap space”第一反應(yīng)就是去改JVM參數(shù)把-Xmx調(diào)大。這固然是一種方法但往往是治標(biāo)不治本甚至可能讓問題惡化。我們需要像偵探一樣層層深入。2.1 JVM內(nèi)存模型與JMeter的運(yùn)行機(jī)制JMeter是一個100%純Java開發(fā)的桌面應(yīng)用它的所有運(yùn)行都依賴于JVM。JVM的內(nèi)存區(qū)域主要分為堆Heap、棧Stack、方法區(qū)Metaspace等。對于JMeter內(nèi)存溢出我們最需要關(guān)注的是堆內(nèi)存。堆內(nèi)存Heap這是JVM中最大的一塊內(nèi)存區(qū)域幾乎所有通過new關(guān)鍵字創(chuàng)建的對象實(shí)例和數(shù)組都存放在這里。它也是垃圾回收器Garbage Collector, GC主要管理的區(qū)域。JMeter在運(yùn)行測試時會創(chuàng)建大量的對象每一個虛擬用戶線程的上下文信息、每一個HTTP請求和響應(yīng)的數(shù)據(jù)、監(jiān)聽器收集的采樣結(jié)果等等都會在堆中分配內(nèi)存。內(nèi)存溢出OOM的本質(zhì)當(dāng)JMeter應(yīng)用程序創(chuàng)建的這些對象總量超過了JVM堆內(nèi)存的最大容量由-Xmx參數(shù)設(shè)定并且垃圾回收器經(jīng)過多次努力也無法回收足夠的空閑內(nèi)存來容納新對象時JVM就會拋出OutOfMemoryError: Java heap space錯誤導(dǎo)致JMeter進(jìn)程崩潰。2.2 導(dǎo)致JMeter堆內(nèi)存暴漲的四大“元兇”根據(jù)我的經(jīng)驗JMeter內(nèi)存溢出很少是單一原因造成的通常是以下幾個因素共同作用的結(jié)果高并發(fā)線程數(shù)這是最直接的因素。啟動的線程數(shù)越多每個線程獨(dú)立維護(hù)的上下文如Cookie管理器、緩存、變量等就越多瞬間創(chuàng)建的對象數(shù)量呈線性甚至指數(shù)級增長。一個配置不當(dāng)?shù)那Ъ壊l(fā)測試足以在幾秒內(nèi)撐爆默認(rèn)的1GB堆內(nèi)存。“貪婪”的監(jiān)聽器這是新手最容易踩的巨坑。JMeter的監(jiān)聽器特別是查看結(jié)果樹View Results Tree和聚合報告Aggregate Report在默認(rèn)設(shè)置下會在內(nèi)存中完整保存每一個請求的響應(yīng)數(shù)據(jù)。想象一下你進(jìn)行一輪10萬次請求的測試如果每個響應(yīng)體平均10KB“查看結(jié)果樹”監(jiān)聽器就會試圖在內(nèi)存中保留將近1GB的原始數(shù)據(jù)這還沒算上對象本身的內(nèi)存開銷。這就是為什么在命令行執(zhí)行壓測時必須禁用這些監(jiān)聽器。腳本設(shè)計缺陷腳本邏輯不當(dāng)也會導(dǎo)致內(nèi)存無法釋放。不合理的循環(huán)或定時器可能導(dǎo)致請求無限堆積。大型文件的參數(shù)化使用CSV Data Set Config讀取一個巨大的文件如幾十萬行的用戶數(shù)據(jù)并且設(shè)置為“All threads”共享模式這會把整個文件加載到內(nèi)存中。正則表達(dá)式或JSON提取器處理超大響應(yīng)如果從一個巨大的響應(yīng)體中提取數(shù)據(jù)提取出的變量可能會占用大量內(nèi)存。JVM垃圾回收GC效率低下即使對象不再被引用也需要垃圾回收器來回收內(nèi)存。如果堆內(nèi)存設(shè)置得過小會導(dǎo)致GC異常頻繁稱為“GC Thrashing”大量CPU時間被用于垃圾回收而非執(zhí)行測試整體吞吐量下降同時GC本身也會產(chǎn)生臨時對象進(jìn)一步加劇內(nèi)存壓力。反之如果堆內(nèi)存設(shè)置得過大單次GC的停頓時間Stop-The-World會很長可能導(dǎo)致JMeter響應(yīng)遲緩。注意很多人誤以為“內(nèi)存泄漏”是主因。在JMeter標(biāo)準(zhǔn)腳本中真正的內(nèi)存泄漏即對象永遠(yuǎn)無法被GC回收并不常見。更多情況是短期內(nèi)的對象創(chuàng)建速率遠(yuǎn)遠(yuǎn)高于垃圾回收速率屬于“內(nèi)存壓力”過大而非嚴(yán)格意義上的泄漏。但設(shè)計糟糕的插件或自定義代碼可能導(dǎo)致泄漏。3. 系統(tǒng)性解決方案從調(diào)優(yōu)到架構(gòu)的進(jìn)階之路解決內(nèi)存溢出我推薦一個從易到難、從內(nèi)到外的系統(tǒng)性排查和解決路徑先優(yōu)化腳本和配置再調(diào)整JVM參數(shù)最后考慮架構(gòu)升級。3.1 第一步腳本與配置優(yōu)化成本最低效果顯著這是你應(yīng)該首先嘗試的往往能解決80%的問題。精簡或禁用監(jiān)聽器非GUI模式命令行執(zhí)行壓測時務(wù)必禁用所有非必要的監(jiān)聽器。使用-l參數(shù)指定結(jié)果保存為JTL文件后續(xù)再用GUI模式打開聚合報告等監(jiān)聽器進(jìn)行分析。在GUI模式設(shè)計調(diào)試腳本時永遠(yuǎn)不要開啟“查看結(jié)果樹”去進(jìn)行壓測。它僅用于調(diào)試單個請求。調(diào)試完畢后務(wù)必禁用或刪除它。使用更“輕量”的監(jiān)聽器。比如用“聚合報告”代替“圖形結(jié)果”前者只存儲統(tǒng)計摘要不存原始數(shù)據(jù)。實(shí)操技巧我習(xí)慣在測試計劃中單獨(dú)創(chuàng)建一個“調(diào)試線程組”里面只放一兩個線程和“查看結(jié)果樹”。正式的壓測線程組里一個監(jiān)聽器都不放。通過${__P(test.type,)}屬性來動態(tài)控制是否啟用調(diào)試線程組。優(yōu)化腳本邏輯清理不必要的測試數(shù)據(jù)定期使用“清除”按鈕掃帚圖標(biāo)清除已有結(jié)果。合理使用CSV數(shù)據(jù)文件對于大型參數(shù)文件使用CSV Data Set Config時將“共享模式”設(shè)置為Current thread group或Current thread避免全局共享導(dǎo)致全量加載。考慮使用__StringFromFile或__File函數(shù)進(jìn)行按需讀取。限制響應(yīng)數(shù)據(jù)保存在HTTP請求等取樣器中可以只保存必要的部分。對于不需要檢查的響應(yīng)可以勾選“Save response as MD5 hash?”來僅保存哈希值極大減少內(nèi)存占用。謹(jǐn)慎使用后置處理器避免使用正則表達(dá)式提取器處理巨大的響應(yīng)體。如果必須處理確保表達(dá)式是精確的避免“貪婪匹配”導(dǎo)致內(nèi)存占用過高。3.2 第二步JVM堆內(nèi)存調(diào)優(yōu)對癥下藥量力而行當(dāng)腳本優(yōu)化到極致后如果仍需支撐更大規(guī)模的測試就需要調(diào)整JMeter啟動時的JVM參數(shù)了。這是直接解決“Java heap space”錯誤的方法。定位配置文件Windows系統(tǒng)編輯jmeter.bat或jmeter腳本如果你用的是jmeter而不是jmeter.bat。Linux/Mac系統(tǒng)編輯jmeterShell腳本或jmeter.sh。關(guān)鍵參數(shù)解析與修改 打開配置文件找到設(shè)置HEAP環(huán)境變量的部分。通常看起來像這樣set HEAP-Xms1g -Xmx1g -XX:MaxMetaspaceSize256m我們需要修改的是-Xms和-Xmx以及可能添加新生代參數(shù)。-Xms: 堆內(nèi)存的初始大小。例如-Xms512m表示啟動時分配512MB。-Xmx: 堆內(nèi)存的最大大小。例如-Xmx4g表示最大可以擴(kuò)展到4GB。-XX:NewSize 和 -XX:MaxNewSize: 設(shè)置新生代Young Generation的初始和最大大小。新生代是大部分新對象產(chǎn)生和死亡的地方頻繁的Minor GC發(fā)生于此。合理設(shè)置可以提升GC效率。一個經(jīng)過實(shí)戰(zhàn)檢驗的配置示例針對一臺擁有16GB物理內(nèi)存的壓測機(jī)set HEAP-Xms2g -Xmx8g set NEW-XX:NewSize1g -XX:MaxNewSize2g修改說明將最大堆內(nèi)存-Xmx從默認(rèn)的1g提升到8g。這里有個重要原則-Xmx值最好不要超過你物理內(nèi)存的50%-70%。因為操作系統(tǒng)、JMeter GUI如果使用、以及其他進(jìn)程都需要內(nèi)存。設(shè)為8g對于16g的機(jī)器是一個比較安全的值。將初始堆內(nèi)存-Xms也設(shè)為2g避免運(yùn)行時頻繁向系統(tǒng)申請內(nèi)存。顯式設(shè)置了新生代大小。對于JMeter這種會創(chuàng)建大量短生命周期對象如每次請求的響應(yīng)對象的應(yīng)用給新生代分配較大空間如堆的1/4到1/2是有益的可以讓這些對象在新生代的Minor GC中就被快速回收避免過早進(jìn)入老年代。這里設(shè)置了1g初始最大2g。修改步驟用文本編輯器如Notepad以管理員身份打開jmeter.bat。搜索“HEAP”關(guān)鍵字。將原配置替換為上述示例配置。保存文件。重啟JMeter必須重啟修改才會生效。重要心得-Xmx不是越大越好設(shè)置過大例如超過物理內(nèi)存會導(dǎo)致操作系統(tǒng)使用硬盤交換分區(qū)Swap性能急劇下降JMeter會變得奇卡無比甚至引發(fā)更嚴(yán)重的系統(tǒng)級問題。始終監(jiān)控壓測機(jī)的整體內(nèi)存使用情況通過任務(wù)管理器或top命令確保還有充足的空余內(nèi)存。3.3 第三步進(jìn)階與分布式壓測終極方案如果單臺機(jī)器即使優(yōu)化了腳本和JVM參數(shù)仍無法滿足你的并發(fā)要求例如需要模擬上萬用戶那么你必須考慮分布式壓測。分布式壓測原理 由一臺機(jī)器作為控制機(jī)Controller負(fù)責(zé)管理測試、分發(fā)腳本、收集結(jié)果。其他多臺機(jī)器作為施壓機(jī)Agent/Slave實(shí)際執(zhí)行測試計劃生成負(fù)載。這樣負(fù)載和內(nèi)存消耗就被分?jǐn)偟搅硕嗯_機(jī)器上。實(shí)施步驟環(huán)境準(zhǔn)備在所有機(jī)器控制機(jī)和施壓機(jī)上安裝相同版本的JMeter和JDK。配置施壓機(jī)在每個施壓機(jī)上運(yùn)行jmeter-server.batWindows或jmeter-serverLinux/Mac啟動服務(wù)。默認(rèn)使用1099端口。配置控制機(jī)編輯控制機(jī)上的jmeter.properties文件找到remote_hosts配置項添加所有施壓機(jī)的IP地址和端口例如remote_hosts192.168.1.101:1099,192.168.1.102:1099。運(yùn)行測試在控制機(jī)GUI中選擇“運(yùn)行” - “遠(yuǎn)程啟動”來啟動指定或所有施壓機(jī)。或者在命令行使用-R 192.168.1.101:1099,192.168.1.102:1099參數(shù)。分布式壓測的注意事項網(wǎng)絡(luò)帶寬控制機(jī)和施壓機(jī)之間、施壓機(jī)和被測系統(tǒng)之間需要有高速、穩(wěn)定的網(wǎng)絡(luò)連接否則網(wǎng)絡(luò)可能成為瓶頸。數(shù)據(jù)文件同步如果腳本中使用CSV等參數(shù)化文件需要確保所有施壓機(jī)上的文件路徑和內(nèi)容一致。可以使用共享存儲如NFS或腳本同步工具。時鐘同步所有機(jī)器的時間應(yīng)基本同步以確保日志時間戳一致。防火墻確保1099端口以及可能用到的其他高端口在施壓機(jī)上是開放的允許控制機(jī)訪問。4. 實(shí)戰(zhàn)排查與監(jiān)控當(dāng)問題發(fā)生時如何快速定位即使做好了預(yù)防在復(fù)雜的測試場景中內(nèi)存溢出仍可能發(fā)生。這時我們需要一套排查方法。4.1 問題現(xiàn)象與初步判斷GUI界面卡死無響應(yīng)可能是堆內(nèi)存即將耗盡GC占用了幾乎所有CPU時間。命令行模式測試突然中止在日志中控制臺或jmeter.log文件看到明確的java.lang.OutOfMemoryError: Java heap space錯誤。錯誤率伴隨測試進(jìn)行逐漸升高在聚合報告中隨著測試時間推移錯誤率特別是超時錯誤不斷上升可能是內(nèi)存不足導(dǎo)致處理請求變慢。4.2 使用監(jiān)控工具定位瓶頸JMeter自身監(jiān)聽器PerfMon Metrics Collector這是一個插件監(jiān)聽器需要安裝。它可以監(jiān)控施壓機(jī)本身的系統(tǒng)資源包括內(nèi)存使用率、CPU、磁盤IO等。將它添加到測試計劃中連接到localhost可以實(shí)時看到JMeter進(jìn)程的內(nèi)存消耗曲線。如果曲線持續(xù)增長直至接近-Xmx設(shè)定值然后崩潰這就是典型的內(nèi)存溢出。JVM內(nèi)置工具jConsole / jVisualVM隨JDK分發(fā)。連接到JMeter進(jìn)程本地或遠(yuǎn)程可以直觀看到堆內(nèi)存、永久代、線程、類的實(shí)時使用情況甚至可以進(jìn)行堆轉(zhuǎn)儲Heap Dump分析。命令行監(jiān)控在啟動JMeter時添加JVM參數(shù)-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:gc.log可以將詳細(xì)的GC日志輸出到文件。分析這個日志可以看GC頻率、暫停時間、回收效果判斷是否是GC問題。4.3 生成與分析堆轉(zhuǎn)儲Heap Dump這是最強(qiáng)大的終極手段可以告訴你堆里到底塞滿了什么對象。生成堆轉(zhuǎn)儲在出現(xiàn)OOM時JVM自動生成添加JVM參數(shù)-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump.hprof。手動生成使用jmap工具或通過jVisualVM觸發(fā)。分析堆轉(zhuǎn)儲 使用專業(yè)工具分析生成的.hprof文件Eclipse MAT (Memory Analyzer Tool)功能強(qiáng)大是首選。它可以自動分析泄漏疑點(diǎn)生成報告告訴你哪個對象占用了最多的內(nèi)存以及是誰在引用它。jVisualVM內(nèi)置分析功能但相對簡單。分析思路打開堆轉(zhuǎn)儲后通常查看“Histogram”直方圖或“Dominator Tree”支配樹。按“Retained Heap”支配內(nèi)存排序排在最前面的類就是內(nèi)存消耗的“罪魁禍?zhǔn)住薄Ｔ贘Meter的上下文中你很可能會發(fā)現(xiàn)大量byte[]響應(yīng)體數(shù)據(jù)、SampleResult對象采樣結(jié)果、或者某些監(jiān)聽器相關(guān)的對象。這就能直接印證我們之前的判斷——是不是監(jiān)聽器沒關(guān)是不是某個請求的響應(yīng)太大了5. 常見問題與避坑指南實(shí)錄這里記錄了我自己和團(tuán)隊在多年實(shí)踐中遇到的一些典型問題和解決技巧。Q1: 我已經(jīng)把-Xmx調(diào)到很大了比如機(jī)器32G我設(shè)了24G但JMeter啟動很慢運(yùn)行也卡甚至還是報OOM。原因與解決這很可能觸發(fā)了“大內(nèi)存頁”和GC停頓問題。過大的堆會導(dǎo)致單次Full GC停頓時間極長表現(xiàn)為程序“卡死”。此外JVM自身管理大堆也需要開銷。解決方案回歸根本首先嚴(yán)格執(zhí)行3.1節(jié)的腳本優(yōu)化特別是禁用監(jiān)聽器。考慮使用G1垃圾回收器它專為減少大堆的停頓時間而設(shè)計。在JMeter啟動參數(shù)中添加-XX:UseG1GC -XX:MaxGCPauseMillis200。這告訴JVM使用G1回收器并目標(biāo)設(shè)定每次GC停頓不超過200毫秒。如果真的需要極大并發(fā)請果斷采用分布式壓測而不是無限制調(diào)高單機(jī)堆內(nèi)存。Q2: 在非GUI命令行模式下運(yùn)行已經(jīng)用了-n和-l但內(nèi)存還是增長得很快。原因雖然禁用了GUI但測試計劃中可能仍然包含了消耗內(nèi)存的監(jiān)聽器如聚合報告如果配置了保存所有數(shù)據(jù)、或者后置處理器產(chǎn)生了大量數(shù)據(jù)。排查使用-t指定測試計劃后用-p或--propfile指定一個只包含最精簡配置的.properties文件。或者在GUI中創(chuàng)建一個絕對干凈的測試計劃無任何監(jiān)聽器再保存為jmx文件用于命令行執(zhí)行。Q3: 分布式壓測時控制機(jī)也報OOM了。原因控制機(jī)雖然不產(chǎn)生負(fù)載但它要收集所有施壓機(jī)返回的樣本結(jié)果。如果線程數(shù)極多、測試時間長收集的結(jié)果數(shù)據(jù)量也會非常龐大。解決在控制機(jī)的jmeter.properties中同樣需要調(diào)大-Xmx。更關(guān)鍵的是在控制機(jī)上配置結(jié)果收集的優(yōu)化。例如使用“聚合報告”監(jiān)聽器時可以勾選“Save Table Data (CSV)”而不是將數(shù)據(jù)全留在內(nèi)存中。或者讓每個施壓機(jī)將結(jié)果直接寫入本地文件使用-l參數(shù)測試結(jié)束后再手動合并分析。Q4: 調(diào)整了JVM參數(shù)但似乎沒生效檢查點(diǎn)確認(rèn)你修改的是啟動JMeter時實(shí)際使用的腳本文件。如果你通過桌面快捷方式啟動它可能指向了另一個副本。修改后必須關(guān)閉所有JMeter窗口并重新啟動。在JMeter啟動時查看控制臺命令行窗口輸出的前幾行日志通常會打印出JVM參數(shù)確認(rèn)你設(shè)置的-Xms和-Xmx是否已正確加載。一個關(guān)鍵的避坑技巧始終使用版本管理對于JMeter的測試腳本.jmx和配置文件.properties, .bat我強(qiáng)烈建議使用Git等版本管理工具。在調(diào)整JVM參數(shù)、修改腳本配置后進(jìn)行提交并寫好注釋。這樣當(dāng)某次測試出現(xiàn)內(nèi)存問題時你可以快速回溯到之前的穩(wěn)定版本進(jìn)行對比精準(zhǔn)定位是哪個改動引入了問題。這比憑記憶要可靠得多。內(nèi)存溢出問題本質(zhì)上是資源管理與需求之間的博弈。解決它沒有一勞永逸的銀彈而是一個“優(yōu)化腳本 - 調(diào)整JVM - 升級架構(gòu)”的持續(xù)過程。掌握這套方法論你就能從容應(yīng)對各種規(guī)模的性能測試挑戰(zhàn)讓JMeter真正成為你手中穩(wěn)定可靠的壓測利器。