同时修改"refresh rate",把缺省的10秒刷新时间改成1秒(从"Option"菜单里选择"Set Refresh Rate..."). 但因为它会加重系统负荷,所以请在不需要 时修改回来. 选中左边的"JVM Runtime",并选择右边的"View Chart" tab,可见图:
"Used memory" -- 当前堆(heap)大小 "Total memory" -- 分配给JVM的内存总量 "Free memory" – Total 和 Used 的差值,如果它接近"0",代表需要增加分配给JVM的内存总量 所以,此图很好的标识了堆大小随时间的变化.总的说来,堆初始增长;当GC运行,堆大小会减少;直到GC运行结束,堆会再增加.根据此图,可以监控是否环 境的变化需要对GC再做修改.比如,如果"Used memory"急速增加,或者GC运行很频繁,就需要增加"initial heap size"; 如果"total memory"在一段时间 内持续增加,说明你的应用可能出现了"object leak"现象,它最终会造成应用"OutOfMemoryExceptions".
在i系列上,有两个参数会影响GC的性能: (1) Initial Heap Size -- 在Java命令行用"-Xms (or -ms)"来进行设定,比如"java -Xms256m MyClass"就代表了Java运行时初始分配的堆(内存)大小是 256MB.此参数也可以通过WAS主控台用图形化界面进入"JVM Settings"来填写参数,如下图所示. (2) Maximum Heap Size -- 在Java命令行用"-Xmx (or -mx)"来进行设定,但一般建议不要修改缺省值 *NOMAX.此参数也可以通过WAS主控台用图形化界面 进入"JVM Settings"来填写参数,如下图所
小节: 还是强调,最好的优化GC的方法就是不断监控系统运行情况和性能数据从而不断调整"initial heap size"来测试.一般来说,设置"initial heap size"使得 GC间隔在10-15秒是比较合适的. 如果是单路或双路处理器,建议从设置"initial heap size"值为32MB/64MB开始监控测试; 如果是4路或8路处理器,建议从设置"initial heap size"为 256MB/512MB开始监控测试; 如果是12路或24路处理器,建议从设置"initial heap size"为1GB开始监控测试. 如果系统内存不足够大,最好保持GC的"initial heap size"值较低,增加GC运行频率,减小堆值,从而确保整个堆内容都在内存里,而不用在硬盘和内存间调 用.用WRKSYSSTS命令或系统的收集服务查看"non-database paging/faulting rates".在非"warm-up"阶段,如果"non-database paging rates"持续超过"10 faults per second",说明"initial heap size"太大了.当然,在混合应用使用的内存池里,"non-database paging rates"过高不一定是JVM的GC设置引起的. 所以最好隔离JVM应用在单独的内存池里运行,这样监控到的指标才更准确. 如果内存过于吃紧,可以设置"maximum heap size"值.缺省它是*NOMAX,所以GC何时运行就只和"initial heap size"有关.但如果修改"maximum heap size" 成为一个真实值,GC在它达到时也会运行.但不同于平常,当"maximum heap size"达到并激活GC,所有应用的线程会被挂起,直到GC运行完成.从而,应用会有 不可预测的暂停行为(pause times).所以,"maximum heap size"的设置要作为对付异常堆增长而引发的内存溢出的最后一道屏障. 除了调节GC,也可以调节应用,使得它少产生对象.这是一个所有平台上的共同问题,在此不再详细讨论. 所以说,在OS/400里,JVM的性能如果涉及到对GC的调节,通常只有一个参数可改 -- "initial heap size" (其它平台上可能有50到60个参数要调); 而有无 数工具来辅助监控和分析GC性能.在应用不做任何改动的情况下,当应用达到平稳运行状态,几分钟的性能监控和正确的参数修改,就可以极大的提高 Java/WAS应用的性能.
参考资料: /iseries/perfmgmt/ /servers/eserver/iseries/perfmgmt/webjtune.html /was400/51/english/info/rzaiz/51/perf/prftunehot.htm /servers/enable/site/education/ibp/perf_analysis/index.htm
示.
注意,i系列上对"initial heap size"的定义是很独特的.在非OS/400平台上,"initial heap size"只是代表初始分配给JVM的内存值,GC何时运行是JVM根据 何时有空闲等条件来决定的;当初始分配的内存不够用,系统会为JVM增加内存分配,直到达到"maximum heap size",所以"maximum heap size"对GC就很有影 响,或者由它触发了一次GC,或者报"Out of Memory"的错误. 但在i系列上基本不需要设置"maximum heap size"(缺省值*NOMAX).因为在i系列里,垃圾回收的执行是基于"initial heap size"参数.它实际上是一个阙值, 来触发垃圾回收.请注意,它不是绝对heap size,而是上次GC到这次GC之间的堆的增长大小.所以,当JVM对内存的占用首次达到这个值, GC会运行,会有部分 内存被释放.在这次剩余内存空间基础上,当有和"initial heap size"标识大小的内存空间又被JVM占用,GC才会再一次自动运行."initial heap size"设得 越大,GC运行频率越低,但在两次GC执行其间JVM占用的内存资源越多,下次GC运行时间也会加长.所以通过调节"initial heap size"的值就可以试图找到一 个GC运行频率和heap size大小的最优平衡点.
(6)i系列上的"Job Watcher tool"工具也可以用来监控 JVM heap size,信息抓取频率高达每秒10次.Job Watcher 可用在单独的Java/WAS应用上. 详细信息请参阅 /i_dir/idoctor.nsf/jw.html .
(2)Verbose GC 如果希望收集GC运行时的更多数据,可以使用"-verbose GC",抓取出信息放入"System.out"里.这些信息包括: 当前堆大小(heap size),被回收的对象的 数量和大小,堆中所存在的对象数量,回收运行所花费的时间等信息. 激活"Verbose GC"的方法很简单,只需在Java命令行添加参数"-verbosegc"即可, 或者在WAS主控台用图形化界面点中参数"Verbose Mode Garbage Collection",如 检查GC是否运行高效的最简单方法就是查看CPU分给GC执行的时间百分比.可以使用PEX(Performance Explorer),收集 trace profile 数据,用*PROGRAM 选项生成报告.在报告的最后一段将有系统分给各个程序运行的CPU时间百分比,如图:
得到的结果格式如下(在"System.out"里):
重要参数解释 -GC 4 : 代表是自JVM启动后的第四次GC回收运行. Live objects : 当前在JVM里处于活动状态的对象数量 Collected objects : 在这次GC里被回收的对象数量 Collected(KB) : 在这次GC里被回收的对象总大小 Current heap(KB): 当前堆大小 Current threshold(KB): 当前阙值,也就是"initial heap size"值 Collect (milliseconds): 这次GC运行时间 Current cycle allocation(KB): 这次GC开始运行到目前为止这段时间内分配的内存量(因为Java应用在GC其间是不用停止的) Previous cycle allocation(KB): 上一次GC开始运行和这次GC开始运行这段时间内增加的内存量,其实它就应该和"initial heap size"大致一样 如上图所示,第四次GC花费了4秒多才运行完成.因为Java应用在GC其间是不停的,所以在这4秒其间,应用又占用了超过200MB内存,是阙值的40%.通过分 析,可以猜想本次GC和下次GC的时间间隔将大约是10秒.本次GC回收了大约5百万个对象,留下了大约2百50万个对象.所以,通过使用"verbose GC"就可以 了解应用是如何使用heap的. 通常,每次GC执行的时间越短越好,比如1-2秒;如果是WAS应用,5-10秒也是可以接受的,所以通过减小"initial heap size"而保持GC执行时"heap size" 小,就可以实现这个目标; 但保持两次GC执行间隔长也有利于性能,这个可以通过增加"initial heap size"实现.看来这两个指标是矛盾的.调节 "initial heap size"值就是试图找到它们的最优平衡点.通过方法(1)查看CPU消耗时间是最好的方法.但如果OS/400里没有安装付费软件 PT1(Performance Tools),就只能用方法(2)了.当然,别忘记最直观的应用吞吐量和响应时间.