1、WAS 关键性能参数配置及异常分析文档更改历史记录日期 版本号 描述 作者2013-02-03 V1.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.
2、WAS 性能分析工具 .122.1 WAS 性能监控配置 122.2 WAS 性能监控 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
3、，-Xmx 2048m。如果在 WAS 应用服务器未设置 JVM 参数或者设置 JVM 参数不合理，会有可能告成应用服务器处理效率低或者造成 OutOfMemoryError 的情况。备注：2m 代表是 2m 的程序对象1.2 GC（详细垃圾回收）GC（Garbage Collection）：当需要分配的内存空间不再使用的时候，JVM 将调用垃圾回收机制来回收内存空间。一般来说，良好的 GC 状态需要保证相邻两次垃圾回收的平均间隔时间应当是单次垃圾回收所需时间的至少 5-6 倍。GC 的调优是通过在模拟压力的情况下不断调整最大最小 heapsize 来实现的，并不是 heapsize 设置越大
4、越好。通过在 WAS 应用服务器配置详细垃圾回收，从而可以使 WAS 在运行时生成native_stderr.log，native_stderr.log 日志帮助分析 JVM 在进行 GC 垃圾回收时的数据，包括回收时间（频率）、长存区（tenured）在收回前、收回中、收回后的对比。在实际的应用中可通过 native_stderr.log 来发现 WAS JVM 的性能问题并做出相应的 JVM 参数调整。回收前一次：回收最新一次前后两次 GC 运行对比，可看行回收间隔为 7S，一次 GC 运行时间不到 1S，JVM 的设置在较理想的状态值。例如出现 OOM 的情况，可通过 WAS 产生的 j
5、avacore 及 heapdump 进行分析定位，并结合 GC 产生的 native_stderr.log 进行分析确认：GC 耗时超过 21S ，GC 内存回收前的可用内存为 0，GC 内存回收后的可用内存为 0%，可用 JVM 内存已耗尽，说明系统使用存在内存泄露（OOM）现象。1.3 Web ContainerWeb 容器 J2EE 标准的实现，为 serverlet 和 jsp 提供运行环境。例如，当一个 HTTP请求通过要访问一个 web 组件（通常是一个 serverlet 或者是 jsp），通常是将这个请求转发给 web container 处理完毕后再返回到 web serv
6、er。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
7、.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 配置数据源根据系统
8、规划需求，按规划配置数据源。（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
9、其它关键参数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、Syst
10、emErr.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 日志存放位置：/wa
11、slogs 目录（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
12、 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 进程的快照，j
13、avacore 文件中可以显示当时运行这个 java进程的所有线程的运行情况。 我们可以利用 javacore 来分析和判断一些故障，如：（1）100% CPU Usage（2）Crash 或 OOM（3）Hang/Performance Javacore 目录的设置在环境条目分别填入：名称 值 描述IBM_HEAPDUMPDIR /wasdump/heapdump/Heapdump 重定向IBM_JAVACOREDIR /wasdump/heapdump/Javacore 重定向IBM_COREDIR /wasdump/heapdump/Core 重定向 Javacore 的文件名Javac
14、ore 文件的命名是根据系统的计算得来的，如 javacore24802.1026159146.txt，而且是唯一的。下列是根据操作系统的不同产生的名字不同：NG 现 AIX 环境下产生的 javacore 文件：javacore.20130128.180057.13041766.0024 Javecore 的产生Javacore 的产生有两种方式，一种是自动产生，一种是通过 kill -3 PID 进行生成。自动产生 Javacore，一般都是出现 OOM 的情况。 Javacore 的分析（1）直接打开 Javacore 文件查看直接打开后，可以看到关键信息，可以看到每一个线程的执行栈，以
15、 stacktrace 的方式显示。通过对 javacore 的分析可以得到应用是否“卡”在某一点上，即在某 一点运行的时间太长。例如：可看出有 java/lang/OutOfMemoryError 的异常信息。（2）运用 javacore 分析工具下载 javacore 运行工具 jca:运行 java Xmx1024m jar jca.jar:可看线程运行情况：请求线程可分为以下几种状态：死锁，Deadlock（重点关注） 执行中，Runnable（重点关注） 等待资源，Waiting on condition（重点关注） 等待监控器检查资源，Waiting on monitor暂停，Su
16、spended对象等待中，Object.wait()阻塞，Blocked（重点关注） 停止，ParkedDeadlock：死锁线程，一般指多个线程调用间，进入相互资源占用，导致一直等待无法释放的情况。Runnable：一般指该线程正在执行状态中，该线程占用了资源，正在处理某个请求，有可能正在传递 SQL 到数据库执行，有可能在对某个文件操作，有可能进行数据类型等转换。Waiting on condition：等待资源，如果堆栈信息明确是应用代码，则证明该线程正在等待资源，一般是大量读取某资源，且该资源采用了资源锁的情况下，线程进入等待状态，等待资源的读取。又或者，正在等待其他线程的执行等。Bl
17、ocked：线程阻塞，是指当前线程执行过程中，所需要的资源长时间等待却一直未能获取到，被容器的线程管理器标识为阻塞状态，可以理解为等待资源超时的线程。这种情况在was 的日志中，一般可以看到 CPU 饥渴，或者某线程已执行了 XX 秒的信息。一般建议的分析逻辑： 在内存溢出时，分析 Javacore 文件中的线程内容，可以采用自下而上的分析方法。 查看有多少线程被设置了 Blocked 状态，这些线程是在执行什么请求，并且到了堆栈最后一步在等待什么资源 查找到这些 Blocked 线程等待的执行线程编号 继续查找该线程，分析其堆栈与状态与监控器的记录的信息。一般这些线程会处于Waiting o
18、n condition 状态，因为这些线程也是因为资源迟迟未获取到或者执行时间过长一直处于等待状体，进一步导致队列中其他需要访问这些资源的线程都被设置为Blocked 状态。 在找到线程后，我们就可以初步将问题缩小到哪些业务应用请求存在问题，是哪一个类与哪一行代码，其等待的资源是什么。备注：具体情况具体分析，后续需根据实际经验完善。3.1.2 heapdump 的分析heapdump 文件是一个二进制文件，它保存了某一时刻 jvm 堆中对象情况，这种文件需要相应的工具进行分析，可以从网上下载最新的分析工具。因打开 heapdump 文件对系统内存要求较高，一般只能借用 64 位的服务器进行分析
19、问题。HeapDump 的生成开关export IBM_HEAPDUMP=trueexport IBM_HEAP_DUMP=trueexport IBM_HEAPDUMP_OUTOFMEMORY=trueexport IBM_JAVADUMP_OUTOFMEMORY=trueexport IBM_JAVACORE_OUTOFMEMORY=trueexport IBM_HEAPDUMPDIR=注意：通常 HeapDump 会比较大，尤其是在 Heap 内存设置很大的情况下为了重现问题，得到现场数据，建议先把 HeapDump 调小，推荐 1G 以下在 Window 上，如果 HeapDump 大于 1G，可能会无法打开，出现 OOM 错误启动 HeapAnalyzer 需要指定-Xmx 参数例子：(1)启动工具：Java Xmx2048m jar ha405.jar(2) 内存按树状引用关系显示(3)内存按对象和类型显示(4) 找到怀疑泄漏的内存对象进行分析再结合 javacore 文件定位确认应用代码：提交研发解决分析备注：heapdump 文件的分析，暂时缺少分析经验，后续完善更新。
