WAS关键性能参数配置及异常

1、WAS关键性能参数配置及异常分析文档更改历史记录日期版本号描述作者2013-02-03V1.0编写林茂楠目录WAS关键性能参数配置及异常分析11.WAS性能关键参数配置41.1 JVM（Java虚拟机）41.2 GC（详细垃圾回收）41.3 Web Container61.4 Data Source数据源71.4.1安装数据源驱动71.4.2配置全局数据源变量71.4.3配置数据源驱动71.4.4配置数据源81.4.5 Database连接池的参数配置111.5 其它关键参数121.5.1 EJB分发共享内存参数122.WAS性能分析工具122.1 WAS性能监控配置122.2 WAS性能监控

2、123.WAS异常分析123.1 关键日志文件123.1 javacore、heapdump分析143.1.1 javacore的分析143.1.2 heapdump的分析201.WAS性能关键参数配置1.1 JVM（Java虚拟机）Heapsize（-Xms和-Xmx）：heapsize的大小依赖于系统平台和具体的应用等多种因素。最大heapsize需要小于机器的物理内存，一般来说，默认最小heapsize为256m。例如NG设置的JVM为-Xms 512m，-Xmx 2048m。如果在WAS应用服务器未设置JVM参数或者设置JVM参数不合理，会有可能告成应用服务器处理效率低或者造成OutO

3、fMemoryError的情况。备注：2m代表是2m的程序对象1.2 GC（详细垃圾回收）GC（Garbage Collection）：当需要分配的内存空间不再使用的时候，JVM将调用垃圾回收机制来回收内存空间。一般来说，良好的GC状态需要保证相邻两次垃圾回收的平均间隔时间应当是单次垃圾回收所需时间的至少5-6倍。GC的调优是通过在模拟压力的情况下不断调整最大最小heapsize来实现的，并不是heapsize设置越大越好。通过在WAS应用服务器配置详细垃圾回收，从而可以使WAS在运行时生成native_stderr.log，native_stderr.log日志帮助分析JVM在进行GC垃圾回

4、收时的数据，包括回收时间（频率）、长存区（tenured）在收回前、收回中、收回后的对比。在实际的应用中可通过native_stderr.log来发现WAS JVM的性能问题并做出相应的JVM参数调整。回收前一次：回收最新一次前后两次GC运行对比，可看行回收间隔为7S，一次GC运行时间不到1S，JVM的设置在较理想的状态值。例如出现OOM的情况，可通过WAS产生的javacore及heapdump进行分析定位，并结合GC产生的native_stderr.log进行分析确认：GC耗时超过21S ，GC内存回收前的可用内存为0，GC内存回收后的可用内存为0%，可用JVM内存已耗尽，说明系统使用存在

5、内存泄露（OOM）现象。1.3 Web ContainerWeb容器J2EE标准的实现，为serverlet和jsp提供运行环境。例如，当一个HTTP请求通过要访问一个web组件（通常是一个serverlet或者是jsp），通常是将这个请求转发给web container处理完毕后再返回到web server。Web Container的调优是通过对Web Container传输链中各个通道（TCP、HTTP、WebContainer）的参数调整进行的。这些参数包括诸如ThreadPool的最大最小值，buffer大小，timeout时间的大小，keep-alive的值等等。一般配置WebCo

6、ntainer即可，需根据业务的实际使用情况进行值的配置，主要业务在WAS达到的应用连接数，其它值为默认值即可：1.4 Data Source数据源1.4.1安装数据源驱动拷贝驱动JAR包到/usr/websphere/AppServer/lib目录，如：cp ojdbc6.jar /usr/websphere/AppServer/lib1.4.2配置全局数据源变量登陆控制台：https:/WAS IP:9043/ibm/console/logon.jsp（1）“环境”> “WebSphere变量”，选择作用域为：集群=所有域（2）增加全局变量：ORACLE_JDBC_DRIVER_PA

7、TH “新建”>名称：ORACLE_JDBC_DRIVER_PATH值：/usr/websphere/AppServer/lib备注：NG未用到全局变量。1.4.3配置数据源驱动增加ORACLE驱动：资源>JDBC>JDBC提供程序1.4.4配置数据源根据系统规划需求，按规划配置数据源。（1）登陆控制台：https:/WAS IP:9043/ibm/console/logon.jsp；（2）资源->JDBC->数据源 新增数据源（“名称和JDNI名称”与规划的ID和VALUE对应）；备注：建议数据库地址不直接使用IP而用主机名代替，方便后续维护（3）J2C认证数据

8、配置登陆账号信息；备注：修改完数据源需要重启动WAS服务（重启动应用也不能生效）1.4.5 Database连接池的参数配置在各自的数据源可配置该数据源的连接池大小配置，选择资源->JDBC->数据源->连接池，可配置连接池最小、最大连接数及连接超时时限等。1.5 其它关键参数1.5.1 EJB分发共享内存参数用root用户登录命令行修改每个WebSphere安装路径的$WasIntallPath/AppServer/deploytool/itp/ejbdeploy.sh内容，根据主机资源情况将EJB分发共享内存上限从默认256M修改为更大的值。“$JAVA_CMD -Xbo

9、otclasspath/a:$ejbd_bootpath -Xms256m Xmx256m”2.WAS性能分析工具2.1 WAS性能监控配置后续补写2.2 WAS性能监控后续补写3.WAS异常分析3.1 关键日志文件（1）SystemOut.log、SystemErr.log、was_server/logs/ffdc目录的日志查看最新WAS异常时段的SystemOut.log、SystemErr.log日志，搜索Error、Exception、Thread、OutOfMemory等相关关键字进行分析定位异常情况。查看保留ffdc目录的日志文件，ffdc工具试图在发生非正常的情况时，自动获取并保

10、留关键信息，其中包含堆栈跟踪、异常发生时的环境等相关信息。可结合SystemOut.log、SystemErr.log等相关日志进行异常的定位。NGBOSS的SystemOut.log、SystemErr.log日志存放位置：/waslogs目录（2）native_stderr.log、native_stdout.lognative_stderr.log日志可查看出JVM垃圾回收的记录及每次GC的间隔时间及运行时间，如下图所示：红色标识分别为：GC运行时间点、垃圾回收前内存情况、垃圾回收后内存情况、GC运行时间长。从结果可看出JVM中已无内存可再回收，JVM处于OOM的状态。可以看出java/

11、lang/OutOfMemoryError：(3) 收集Web server服务器日志收集IHS日志（access_log、error_log）及插件Plug-in（plugin-cfg.xml and http_plugin.log）的日志及配置文件，查看是否出现异常信息。例如http_plugin.log，可能提示一个连接无法正常发送到相关WAS Server，不过尝试连接其它WAS Server，这种情况可能是无法连接的Server处理较繁忙的状态或者网络中断。3.1 javacore、heapdump分析java程序在遇到致命异常时，为了能够保留java应用发生致命错误前的运行状态，j

12、vm在无法工作前产生两个文件，分别为javacore及heapdump文件。3.1.1 javacore的分析Javacore文件是一个java进程的快照，javacore文件中可以显示当时运行这个java进程的所有线程的运行情况。Ø 我们可以利用javacore来分析和判断一些故障，如：（1）100% CPU Usage（2）Crash或OOM（3）Hang/Performance Ø Javacore目录的设置在环境条目分别填入：名称值描述IBM_HEAPDUMPDIR/wasdump/heapdump/<servername>Heapdump重定向IBM_

13、JAVACOREDIR/wasdump/heapdump/<servername>Javacore重定向IBM_COREDIR/wasdump/heapdump/<servername>Core重定向Ø Javacore的文件名Javacore文件的命名是根据系统的计算得来的，如javacore24802.1026159146.txt，而且是唯一的。下列是根据操作系统的不同产生的名字不同：NG现AIX环境下产生的javacore文件：javacore.20130128.180057.13041766.0024Ø Javecore的产生Javacore

14、的产生有两种方式，一种是自动产生，一种是通过kill -3 PID进行生成。自动产生Javacore，一般都是出现OOM的情况。Ø Javacore的分析（1）直接打开Javacore文件查看直接打开后，可以看到关键信息，可以看到每一个线程的执行栈，以stacktrace的方式显示。通过对javacore的分析可以得到应用是否“卡”在某一点上，即在某 一点运行的时间太长。例如：可看出有java/lang/OutOfMemoryError的异常信息。（2）运用javacore分析工具下载javacore运行工具jca:运行java Xmx1024m jar jca.jar:可看线程运行

15、情况：请求线程可分为以下几种状态：死锁，Deadlock（重点关注） 执行中，Runnable（重点关注） 等待资源，Waiting on condition（重点关注） 等待监控器检查资源，Waiting on monitor暂停，Suspended对象等待中，Object.wait()阻塞，Blocked（重点关注） 停止，Parked Deadlock：死锁线程，一般指多个线程调用间，进入相互资源占用，导致一直等待无法释放的情况。Runnable：一般指该线程正在执行状态中，该线程占用了资源，正在处理某个请求，有可能正在传递SQL到数据库执行，有可能在对某个文件操作，有可能进行数据类型等

16、转换。Waiting on condition：等待资源，如果堆栈信息明确是应用代码，则证明该线程正在等待资源，一般是大量读取某资源，且该资源采用了资源锁的情况下，线程进入等待状态，等待资源的读取。又或者，正在等待其他线程的执行等。Blocked：线程阻塞，是指当前线程执行过程中，所需要的资源长时间等待却一直未能获取到，被容器的线程管理器标识为阻塞状态，可以理解为等待资源超时的线程。这种情况在was的日志中，一般可以看到CPU饥渴，或者某线程已执行了XX秒的信息。一般建议的分析逻辑：Ø 在内存溢出时，分析Javacore文件中的线程内容，可以采用自下而上的分析方法。Ø 查看

17、有多少线程被设置了Blocked状态，这些线程是在执行什么请求，并且到了堆栈最后一步在等待什么资源Ø 查找到这些Blocked线程等待的执行线程编号Ø 继续查找该线程，分析其堆栈与状态与监控器的记录的信息。一般这些线程会处于Waiting on condition状态，因为这些线程也是因为资源迟迟未获取到或者执行时间过长一直处于等待状体，进一步导致队列中其他需要访问这些资源的线程都被设置为Blocked状态。Ø 在找到线程后，我们就可以初步将问题缩小到哪些业务应用请求存在问题，是哪一个类与哪一行代码，其等待的资源是什么。备注：具体情况具体分析，后续需根据实际经验完

18、善。3.1.2 heapdump的分析heapdump文件是一个二进制文件，它保存了某一时刻jvm堆中对象情况，这种文件需要相应的工具进行分析，可以从网上下载最新的分析工具。因打开heapdump文件对系统内存要求较高，一般只能借用64位的服务器进行分析问题。HeapDump的生成开关export IBM_HEAPDUMP=trueexport IBM_HEAP_DUMP=trueexport IBM_HEAPDUMP_OUTOFMEMORY=trueexport IBM_JAVADUMP_OUTOFMEMORY=trueexport IBM_JAVACORE_OUTOFMEMORY=trueexport IBM_HEAPDUMPDIR=<directory_path>注意