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

《WAS关键性能参数配置及异常分析》由会员分享，可在线阅读，更多相关《WAS关键性能参数配置及异常分析（24页珍藏版）》请在装配图网上搜索。

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

2、志文件123.1 javacore、heapdump分析14 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参数不合理，会有可能告成应用服务器处理效率低或者造成OutOfMemoryError的状况。备注：2m代表是2

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

4、red）在收回前、收回中、收回后的对比。在实际的应用中可通过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.3 Web Conta

5、inerWeb容器J2EE标准的实现，为serverlet和jsp供应运行环境。例如，当一个 恳求通过要访问一个web组件（通常是一个serverlet或者是jsp），通常是将这个恳求转发给web container处理完毕后再返回到web server。Web Container的调优是通过对Web Container传输链中各个通道（TCP、 、WebContainer）的参数调整进行的。这些参数包括诸如ThreadPool的最大最小值，buffer大小，timeout时间的大小，keep-alive的值等等。一般配置WebContainer即可，需依据业务的实际运用状况进行值的配置，主要

6、业务在WAS达到的应用连接数，其它值为默认值即可：1.4 Data Source数据源1.4.1安装数据源驱动拷贝驱动JAR包到/usr/websphere/AppServer/lib书目，如：cp ojdbc6.jar /usr/websphere/AppServer/lib配置全局数据源变量登陆限制台： s:/WAS IP:9043/ibm/console/logon.jsp（1）“环境” “WebSphere变量”，选择作用域为：集群=全部域（2）增加全局变量：ORACLE_JDBC_DRIVER_PATH “新建”名称：ORACLE_JDBC_DRIVER_PATH值：/usr/web

7、sphere/AppServer/lib备注：NG未用到全局变量。配置数据源驱动增加ORACLE驱动：资源JDBCJDBC供应程序配置数据源依据系统规划需求，按规划配置数据源。（1）登陆限制台： s:/WAS IP:9043/ibm/console/logon.jsp；（2）资源-JDBC-数据源 新增数据源（“名称和JDNI名称”与规划的ID和VALUE对应）；备注：建议数据库地址不干脆运用IP而用主机名代替，便利后续维护（3）J2C认证数据配置登陆账号信息；备注：修改完数据源须要重启动WAS服务（重启动应用也不能生效）1.4.5 Database连接池的参数配置在各自的数据源可配置该数据源

8、的连接池大小配置，选择资源-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性能监控后续补

9、写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

10、.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（plugi

11、n-cfg.xml and _plugin.log）的日志及配置文件，查看是否出现异样信息。例如 _plugin.log，可能提示一个连接无法正常发送到相关WAS Server，不过尝试连接其它WAS Server，这种状况可能是无法连接的Server处理较繁忙的状态或者网络中断。3.1 javacore、heapdump分析java程序在遇到致命异样时，为了能够保留java应用发生致命错误前的运行状态，jvm在无法工作前产生两个文件，分别为javacore及heapdump文件。3.1.1 javacore的分析Javacore文件是一个java进程的快照，javacore文件中可以显示当时

12、运行这个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的文件名Javacore文件的命名是依据系统的计算得来的，如，而且是唯一的。下列是

13、依据操作系统的不同产生的名字不同：NG现AIX环境下产生的javacore文件： Javecore的产生Javacore的产生有两种方式，一种是自动产生，一种是通过kill -3 PID进行生成。自动产生Javacore，一般都是出现OOM的状况。 Javacore的分析（1）干脆打开Javacore文件查看干脆打开后，可以看到关键信息，可以看到每一个线程的执行栈，以stacktrace的方式显示。通过对javacore的分析可以得到应用是否“卡”在某一点上，即在某 一点运行的时间太长。例如：可看出有java/lang/OutOfMemoryError的异样信息。（2）运用javacore分析

14、工具下载javacore运行工具jca:运行java Xmx1024m jar jca.jar:可看线程运行状况：恳求线程可分为以下几种状态：死锁，Deadlock（重点关注） 执行中，Runnable（重点关注） 等待资源，Waiting on condition（重点关注） 等待监控器检查资源，Waiting on monitor暂停，Suspended对象等待中，Object.wait()堵塞，Blocked（重点关注） 停止，Parked Deadlock：死锁线程，一般指多个线程调用间，进入相互资源占用，导致始终等待无法释放的状况。Runnable：一般指该线程正在执行状态中，该线程

15、占用了资源，正在处理某个恳求，有可能正在传递SQL到数据库执行，有可能在对某个文件操作，有可能进行数据类型等转换。Waiting on condition：等待资源，假如堆栈信息明确是应用代码，则证明该线程正在等待资源，一般是大量读取某资源，且该资源采纳了资源锁的状况下，线程进入等待状态，等待资源的读取。又或者，正在等待其他线程的执行等。Blocked：线程堵塞，是指当前线程执行过程中，所须要的资源长时间等待却始终未能获得到，被容器的线程管理器标识为堵塞状态，可以理解为等待资源超时的线程。这种状况在was的日志中，一般可以看到CPU饥渴，或者某线程已执行了XX秒的信息。一般建议的分析逻辑： 在

16、内存溢出时，分析Javacore文件中的线程内容，可以采纳自下而上的分析方法。 查看有多少线程被设置了Blocked状态，这些线程是在执行什么恳求，并且到了堆栈最终一步在等待什么资源 查找到这些Blocked线程等待的执行线程编号 接着查找该线程，分析其堆栈与状态与监控器的记录的信息。一般这些线程会处于Waiting on condition状态，因为这些线程也是因为资源迟迟未获得到或者执行时间过长始终处于等待状体，进一步导致队列中其他须要访问这些资源的线程都被设置为Blocked状态。 在找到线程后，我们就可以初步将问题缩小到哪些业务应用恳求存在问题，是哪一个类与哪一行代码，其等待的资源是什

17、么。备注：具体状况具体分析，后续需依据实际阅历完善。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_J

18、AVACORE_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文件的分析，短暂缺少分析阅历，后续完善更新。