优化 Java 垃圾收集器改进系统性能
2008-01-05 08:30:24 来源:WEB开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚悢鍏尖拻閻庨潧澹婂Σ顔剧磼閻愵剙鍔ょ紓宥咃躬瀵鎮㈤崗灏栨嫽闁诲酣娼ф竟濠偽i鍓х<闁绘劦鍓欓崝銈囩磽瀹ュ拑韬€殿喖顭烽幃銏ゅ礂鐏忔牗瀚介梺璇查叄濞佳勭珶婵犲伣锝夘敊閸撗咃紲闂佽鍨庨崘锝嗗瘱闂備胶顢婂▍鏇㈠箲閸ヮ剙鐏抽柡鍐ㄧ墕缁€鍐┿亜韫囧海顦﹀ù婊堢畺閺屻劌鈹戦崱娆忓毈缂備降鍔庣划顖炲Φ閸曨垰绠抽悗锝庝簽娴犻箖姊洪棃娑欐悙閻庢矮鍗抽悰顕€宕堕澶嬫櫖濠殿噯绲剧€笛囧箲閸ヮ剙钃熼柣鏂挎憸閻熷綊鏌涢…鎴濇灈妞ゎ剙鐗嗛—鍐Χ鎼粹€茬凹缂備緡鍠楅幐鎼佹偩閻戣棄纭€闁绘劕绉靛Λ鍐春閳ь剚銇勯幒鎴濐伀鐎规挷绀侀埞鎴︽偐閹绘帩浼€缂佹儳褰炵划娆撳蓟濞戞矮娌柟瑙勫姇椤ユ繈姊洪柅鐐茶嫰婢т即鏌熼搹顐e磳闁挎繄鍋涢埞鎴犫偓锝庘偓顓涙櫊閺屽秵娼幏灞藉帯闂佹眹鍊曢幊鎰閹惧瓨濯撮柛鎾村絻閸撳崬顪冮妶鍡楃仸闁荤啿鏅涢悾鐑藉Ψ瑜夐崑鎾绘晲鎼粹剝鐏嶉梺缁樻尰濞叉﹢濡甸崟顖氱疀闂傚牊绋愮花鑲╃磽娴h棄鐓愭慨妯稿妿濡叉劙骞樼拠鑼槰闂佸啿鎼崐濠毸囬弶搴撴斀妞ゆ梻銆嬪銉︺亜椤撶偛妲婚柣锝囧厴楠炴帡骞嬮弮鈧悗濠氭⒑鐟欏嫭鍎楅柛妯衡偓鐔插徍濠电姷鏁告慨鐑藉极閸涘﹥鍙忔い鎾卞灩绾惧鏌熼崜褏甯涢柍閿嬪灦閵囧嫰骞掗崱妞惧缂傚倷绀侀ˇ閬嶅极婵犳氨宓侀柛鈩冪⊕閸婄兘鏌涘┑鍡楊伀妞ゆ梹鍔曢埞鎴︽倻閸モ晝校闂佸憡鎸婚悷锔界┍婵犲洦鍤冮柍鍝勫暟閿涙粓姊鸿ぐ鎺戜喊闁告瑥楠搁埢鎾斥堪閸喓鍘搁柣蹇曞仧绾爼宕戦幘璇茬疀濞达絽鎲¢崐顖炴⒑绾懎浜归悶娑栧劦閸┾偓妞ゆ帒鍟惃娲煛娴e湱澧柍瑙勫灴閹瑩寮堕幋鐘辨闂備礁婀辨灙闁硅姤绮庨崚鎺楀籍閸喎浠虹紓浣割儓椤曟娊鏁冮崒娑氬幈闂佸搫娲㈤崝宀勬倶閻樼粯鐓曢柟鑸妼娴滄儳鈹戦敍鍕杭闁稿﹥鐗犲畷婵嬫晝閳ь剟鈥﹂崸妤€鐒垫い鎺嶈兌缁犲墽鈧厜鍋撳┑鐘辩窔閸嬫鈹戦纭烽練婵炲拑绲垮Σ鎰板箳閹冲磭鍠撻幏鐘绘嚑閼稿灚姣愰梻鍌氬€烽懗鑸电仚濠电偛顕崗妯侯嚕椤愩倖瀚氱€瑰壊鍠栧▓銊︾節閻㈤潧校缁炬澘绉瑰鏌ュ箵閹烘繄鍞甸柣鐘烘鐏忋劌顔忛妷褉鍋撶憴鍕碍婵☆偅绻傞~蹇涙惞閸︻厾锛滃┑鈽嗗灠閹碱偊锝炲鍥╃=濞达綁顥撻崝宥夋煙缁嬪灝鏆遍柣锝囧厴楠炲鏁冮埀顒傜不婵犳碍鍋i柛銉戝啰楠囬悗瑙勬尭缁夋挳鈥旈崘顔嘉ч柛鈩兠棄宥囩磽娴e壊鍎愰柛銊ュ缁顓兼径瀣偓閿嬨亜閹哄秶顦︾€殿喖鐏濋埞鎴﹀煡閸℃浠梺鍛婎焼閸曨収娲告俊銈忕到閸燁垶宕愰崹顐e弿婵☆垳鍘ф禍楣冩倵濮樼偓瀚�

2006 年 11 月 30 日
在系统的性能测试过程中,当系统的处理能力有某种变化趋势时, 除了关于等待队列、执行线程,EJB 池以及数据库连接池和 Statement Cache 方面的调优外,还要考虑到 java 垃圾收集器(Garbage Collection,本文简称 GC)对系统性能的影响。本文介绍了如何分析系统的处理能力和 GC 之间的关系,以及如何通过改进 JVM 的配置来优化 GC,以提高系统的性能。
项目背景
某个大型项目的 CPU100% 的压力性能测试, 用以检查在系统运行环境不正常的情况下,系统可以运行到何种程度。测试过程是: 请求测试的模拟器向系统不断发出大量请求, 系统接受由模拟器发出的请求,然后将请求置于一个任务池中,假如当前有空闲的线程,则该线程会从任务池中取出一个任务进行处理,假如没有空闲的线程,则该任务一直会待在任务池中,直到有空闲的线程来处理它。因此,任务池的队列的长度从某种意义上可以代表整个系统的处理能力,任务池队列的长度用 Q 值来表示,假如 Q 值超出了一定限额,将会有流量控制的线程将超出限额的待处理任务丢弃,以保证系统的稳定性。
整个测试要求得到系统所在服务器的负载达到将近 100% 时,系统的吞吐量,相应时间以及在超负荷下业务请求成功率。
问题现象描述
在测试过程中,任务池中累积的任务数起伏很大,正常时累积的任务数很小,但是每隔一段时间会累积大量的任务。由于累积的任务数超出任务池流量控制所定义的限额,所以每隔一段时间,大量的待处理任务被清除。因此测试结束后得到的在超负荷下业务请求成功率也不是很理想。
应用服务器的物理部署
一台AIX服务器(4CPU,4GMemory)来部署本Web应用程序;Web应用程序部署在中间件应用服务器上;部署了一个节点(Node),只配置一个应用服务器实例(Instance),没有做Cluster部署。
分析
检测WebSphere application Server上的Web Container,EJB Container , ORB Service,数据库连接池等设置均合理,然后怀疑问题的现象是不是与系统GC有关。当前Java Virtual Machine的配置为: Initial Heap Size:256 , Maximum Heap Size: 3072。
为了验证任务池中累积的任务数的大幅度变化和系统GC是否存在一定的关系,通过对任务池的累积任务数和系统GC进行采样, 将采样后的数据进行分析,用以得出二者的关系。采样时遵循Nyquist采样定例: 采样频率要大于被采集对象的频率的2倍。 否则,采样点很可能每次位于被采集对象的波形的某个点上,从而不能正确反映被采集对象的变化规律。
采样
通过观察,发现任务池的任务数目(以下用Q值代替)的变化周期大概是5到6秒,因此根据Nyquist采样定例,采样的时间间隔不能超过2-3秒,所以按照每秒来采样。 测试时间是3分钟,采样180次,系统的当前负载率是99%。采样图如下所示:
图一 任务池Q值的采样图
由于系流量控制要求的限额是450个任务,也就是任务池中最多能累积450个任务,当任务池中累积的任务数超过450时,多余的任务会被流量控制直接丢弃,从上图可以看出,系统的Q值在很多时刻都大于450,因此多次被丢弃任务,从而导致了任务请求成功率不高。
系统GC的采样
1: 在WebSphere Administrative Console上, 点击进入:Servers, 然后Application servers > server1 > PRocess Definition > Java Virtual Machine, 在Configuration面板上,选上Verbose garbage collection选项。
图二 WebSphere Application Server的JVM配置示图
2:进入<%WebSphere Application Server的安装目录%>/profiles/<%所在的profiles%>/logs/ <%所在的Server%>, 可以看到native_stderr.log文件,将其清空
3:在高负载的条件下,进行高压测试3分钟
4:将native_stderr.log文件拷贝出来,用GCCollector工具进行分析,其中native_stderr.log文件上记录了系统GC的数据。
5:安装GCCollector工具: 下载完GCCollector.zip后,解压缩,将里面Lib里的3个文件 jfreechart-1.0.0-rc1.jar,jcommon-1.0.0-rc1.jar 和GCCollector.jar拷贝至JRE的lib目录下,然后在命令行控制台上进入JRE的安装目录,而后运行: java -classpath jfreechart-1.0.0-rc1.jar;jcommon-1.0.0-rc1.jar -jar GCCollector.jar。
更多精彩
赞助商链接