WAS优化建议.pptVIP

WAS优化建议 建议1： 开启GC 详细日志以及手动转储dump文件。 目的： 分析OutOfMemory问题。 开启JVM GC详细垃圾回收日志，分析JVM Java Heap中是否存在大对象、回收频繁以及碎片问题。 手动转储内存堆，采集正常、高峰期间的heapdump文件。与OOM期间产生的heapdump文件，能够知道class以及object数量、引用区别，比对次数越多，定位更准确。 动作： 进入WAS管理控制台，选择应用服务器的”JVM虚拟机”页面，选中“详细垃圾回收”单选框，保存并同步节点后，重启应用服务器生效。 手动转储内存堆 kill -3 java_pid， heapdump比较使用ISA工具中的MDDJ4工具进行分析 /developerworks/cn/websphere/library/techarticles/0710_pengfei/index.html 更改动作影响： 在目录中实时输出日志，开启详细垃圾回收日志对WAS性能影响3-10%左右。 手动采集heapdump文件期间， WAS应用服务器无法响应。一般1～3分钟完成。 WAS优化建议 建议2： 定时收集WAS资源统计。 目的： 分析Servlet、WebContainer、JDBC Connect Pool等资源使用情况。 动作： #dmgr_profiles/bin/wsadmin.sh –conntype SOAP –username admin -password admin wsadmin set obj [$AdminControl queryNames *:,process=essapp1,name=PerfPrivateMBean,type=PerfPrivate,*] wsadmin $AdminControl invoke $obj getServerStats 更改动作影响： 收集WAS PMI数据期间对WAS性能有影响，考虑特定时间执行 WAS优化建议 建议3： Was进程启动用户Ulimit 参数调整 目的： ulimit设置，是操作系统对资源的限制，包括一个进程最大可以打开多少文件等等。 WAS应用服务器的启动用户，它的ulimit设置有些数值过小，比如单个进程最大数据块大小、单个进程中最大文件数量等，有可能导致进程OutOfMemory(OOM)或文件打开失败。 调整was用户的ulimit参数，设置为unlimited，包括data、stack、memory、nofiles等参数 动作： 编辑was启动用户的.profile文件，在文件内容增加一下命令，或者直接在命令行中执行下面命令 ulimit –m unlimited ulimit –d unlimited ulimit –s unlimited ulimit –n 20000 重启WAS应用服务器生效 更改动作影响： 单个进程使用更多系统资源 需要重启WAS应用服务器 WAS优化建议 建议4： 调整JVM GC (垃圾回收)策略，针对停顿时间进行优化 目的： 当前JVM GC使用缺省策略optthruput 。它是一个追踪收集器，称为标志-扫描-压缩（mark-sweep-compact） 串行收集器， 调整JVM GC针对停顿时间进行优化，通过并发地执行一部分垃圾收集，在高吞吐量和短 GC 停顿之间进行折中。应用程序停顿的时间更短。 /developerworks/cn/java/j-ibmjava2/ 动作： 进入WAS管理控制台，选择应用服务器的”JVM虚拟机”页面，在“通用JVM参数”输入框，插入一下设置“-Xgcplicy:optavgpause”，保存并同步节点后，重启应用服务器生效 更改动作影响： 需要重启WAS应用服务器 WAS优化建议 建议5： 调整ThreadPool池参数，连接数最小值与最大值保持一致 目的： 当前ThreadPool池中，连接数最小值是最大值的一半。连接数线程存在定时清理，如果不足还需要重新创建线程。创建(mallc)与销毁(fork)次数相对过多。创建线程也是很耗系统资源的。 可以考虑将连接数最小值与最大值设置一样，线程创建与销毁相对就少，或者基本没有。一般相对与创建线程来说，线程上下文切换的消耗就小的多。 动作： 进入WAS管理控制台，选择应用服务器的ThreadPool设置页面，将其中的最小值与最大值设置相同，保存并同步节点后，重启应用服务器生效 更改动作影响： 一次性分配资源 需要重启WAS应用服务器 WAS优化建议 建议6： 调整JVM GC (垃圾回收)策略，针对碎片问题进行优化 目的： 堆的碎片问题(Heap Fragmentation)在JVM中存