WAS关键性能参数配置及异常分析目录WAS关键性能参数配置及异常分析 (1)1.WAS性能关键参数配置 (3)1.1 JVM（Java虚拟机） (3)1.2 GC（详细垃圾回收） (3)1.3 Web Container (5)1.4 Data Source数据源 (6)1.4.1安装数据源驱动 (6)1.4.2配置全局数据源变量 (6)1.4.3配置数据源驱动 (6)1.4.4配置数据源 (7)1.4.5 Database连接池的参数配置 (10)1.5 其它关键参数 (11)1.5.1 EJB分发共享内存参数 (11)2.WAS性能分析工具 (11)2.1 WAS性能监控配置 (11)2.2 WAS性能监控 (11)3.WAS异常分析 (11)3.1 关键日志文件 (11)3.1 javacore、heapdump分析 (13)3.1.1 javacore的分析 (13)3.1.2 heapdump的分析 (19)1.WAS性能关键参数配置1.1 JVM（Java虚拟机）Heapsize（-Xms和-Xmx）：heapsize的大小依赖于系统平台和具体的应用等多种因素。
最大heapsize需要小于机器的物理内存，一般来说，默认最小heapsize为256m。
例如NG 设置的JVM为-Xms 512m，-Xmx 2048m。
如果在WAS应用服务器未设置JVM参数或者设置JVM参数不合理，会有可能告成应用服务器处理效率低或者造成OutOfMemoryError的情况。
备注：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垃圾回收时的数据，包括回收时间（频率）、长存区（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内存已耗尽，说明系统使用存在内存泄露（OOM）现象。
1.3Web ContainerWeb容器J2EE标准的实现，为serverlet和jsp提供运行环境。
例如，当一个HTTP请求通过要访问一个web组件（通常是一个serverlet或者是jsp），通常是将这个请求转发给web container处理完毕后再返回到web server。
Web Container的调优是通过对Web Container传输链中各个通道（TCP、HTTP、WebContainer）的参数调整进行的。
这些参数包括诸如ThreadPool的最大最小值，buffer 大小，timeout时间的大小，keep-alive的值等等。
一般配置WebContainer即可，需根据业务的实际使用情况进行值的配置，主要业务在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_PATH“新建”—>名称：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认证数据配置登陆账号信息；备注：修改完数据源需要重启动WAS服务（重启动应用也不能生效）1.4.5 Database连接池的参数配置在各自的数据源可配置该数据源的连接池大小配置，选择资源->JDBC->数据源->连接池，可配置连接池最小、最大连接数及连接超时时限等。
1.5 其它关键参数1.5.1 EJB分发共享内存参数用root用户登录命令行修改每个WebSphere安装路径的$WasIntallPath/AppServer/deploytool/itp/ejbdeploy.sh内容，根据主机资源情况将EJB 分发共享内存上限从默认256M修改为更大的值。
“$JAVA_CMD \-Xbootclasspath/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工具试图在发生非正常的情况时，自动获取并保留关键信息，其中包含堆栈跟踪、异常发生时的环境等相关信息。
可结合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/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应用发生致命错误前的运行状态，jvm 在无法工作前产生两个文件，分别为javacore及heapdump文件。
3.1.1 javacore的分析Javacore文件是一个java进程的快照，javacore文件中可以显示当时运行这个java 进程的所有线程的运行情况。
➢我们可以利用javacore来分析和判断一些故障，如：（1）100% CPU Usage （2）Crash或OOM（3）Hang/Performance ➢Javacore目录的设置在环境条目分别填入：➢Javacore的文件名Javacore文件的命名是根据系统的计算得来的，如javacore24802.1026159146.txt，而且是唯一的。
下列是根据操作系统的不同产生的名字不同：NG现AIX环境下产生的javacore文件：javacore.20130128.180057.13041766.0024➢Javecore的产生Javacore的产生有两种方式，一种是自动产生，一种是通过kill -3 PID进行生成。
自动产生Javacore，一般都是出现OOM的情况。
➢Javacore的分析（1）直接打开Javacore文件查看直接打开后，可以看到关键信息，可以看到每一个线程的执行栈，以stacktrace的方式显示。
通过对javacore的分析可以得到应用是否“卡”在某一点上，即在某一点运行的时间太长。
例如：可看出有java/lang/OutOfMemoryError的异常信息。
（2）运用javacore分析工具下载javacore运行工具jca:运行java –Xmx1024m –jar jca.jar:可看线程运行情况：请求线程可分为以下几种状态：死锁，Deadlock（重点关注）执行中，Runnable（重点关注）等待资源，Waiting on condition（重点关注）等待监控器检查资源，Waiting on monitor暂停，Suspended对象等待中，Object.wait()阻塞，Blocked（重点关注）停止，ParkedDeadlock：死锁线程，一般指多个线程调用间，进入相互资源占用，导致一直等待无法释放的情况。
Runnable：一般指该线程正在执行状态中，该线程占用了资源，正在处理某个请求，有可能正在传递SQL到数据库执行，有可能在对某个文件操作，有可能进行数据类型等转换。
Waiting on condition：等待资源，如果堆栈信息明确是应用代码，则证明该线程正在等待资源，一般是大量读取某资源，且该资源采用了资源锁的情况下，线程进入等待状态，等待资源的读取。