WAS关键性能参数配置及异常分析.docx
- 文档编号:30446067
- 上传时间:2023-08-15
- 格式:DOCX
- 页数:21
- 大小:2.21MB
WAS关键性能参数配置及异常分析.docx
《WAS关键性能参数配置及异常分析.docx》由会员分享,可在线阅读,更多相关《WAS关键性能参数配置及异常分析.docx(21页珍藏版)》请在冰豆网上搜索。
WAS关键性能参数配置及异常分析
WAS关键性能参数配置及异常分析
文档更改历史记录
日期
版本号
描述
作者
2013-02—03
V1。
0
编写
林茂楠
1.WAS性能关键参数配置
1。
1JVM(Java虚拟机)
Heapsize(—Xms和—Xmx):
heapsize的大小依赖于系统平台和具体的应用等多种因素。
最大heapsize需要小于机器的物理内存,一般来说,默认最小heapsize为256m.例如NG设置的JVM为-Xms512m,-Xmx2048m。
如果在WAS应用服务器未设置JVM参数或者设置JVM参数不合理,会有可能告成应用服务器处理效率低或者造成OutOfMemoryError的情况。
备注:
2m代表是2m的程序对象
1。
2GC(详细垃圾回收)
GC(GarbageCollection):
当需要分配的内存空间不再使用的时候,JVM将调用垃圾回收机制来回收内存空间。
一般来说,良好的GC状态需要保证相邻两次垃圾回收的平均间隔时间应当是单次垃圾回收所需时间的至少5—6倍。
GC的调优是通过在模拟压力的情况下不断调整最大最小heapsize来实现的,并不是heapsize设置越大越好。
通过在WAS应用服务器配置详细垃圾回收,从而可以使WAS在运行时生成native_stderr.log,native_stderr。
log日志帮助分析JVM在进行GC垃圾回收时的数据,包括回收时间(频率)、长存区(tenured)在收回前、收回中、收回后的对比.在实际的应用中可通过native_stderr.log来发现WASJVM的性能问题并做出相应的JVM参数调整.
回收前一次:
回收最新一次
前后两次GC运行对比,可看行回收间隔为7S,一次GC运行时间不到1S,JVM的设置在较理想的状态值。
例如出现OOM的情况,可通过WAS产生的javacore及heapdump进行分析定位,并结合GC产生的native_stderr.log进行分析确认:
GC耗时超过21S,GC内存回收前的可用内存为0,GC内存回收后的可用内存为0%,可用JVM内存已耗尽,说明系统使用存在内存泄露(OOM)现象。
1.3WebContainer
Web容器J2EE标准的实现,为serverlet和jsp提供运行环境。
例如,当一个HTTP请求通过要访问一个web组件(通常是一个serverlet或者是jsp),通常是将这个请求转发给webcontainer处理完毕后再返回到webserver。
WebContainer的调优是通过对WebContainer传输链中各个通道(TCP、HTTP、WebContainer)的参数调整进行的.这些参数包括诸如ThreadPool的最大最小值,buffer大小,timeout时间的大小,keep—alive的值等等。
一般配置WebContainer即可,需根据业务的实际使用情况进行值的配置,主要业务在WAS达到的应用连接数,其它值为默认值即可:
1。
4DataSource数据源
1.4。
1安装数据源驱动
拷贝驱动JAR包到/usr/websphere/AppServer/lib目录,如:
cpojdbc6。
jar/usr/websphere/AppServer/lib
1.4.2配置全局数据源变量
登陆控制台:
https:
//WASIP:
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:
//WASIP:
9043/ibm/console/logon.jsp;
(2)资源—〉JDBC—>数据源新增数据源(“名称和JDNI名称”与规划的ID和VALUE对应);
备注:
建议数据库地址不直接使用IP而用主机名代替,方便后续维护
(3)J2C认证数据配置登陆账号信息;
备注:
修改完数据源需要重启动WAS服务(重启动应用也不能生效)
1.4。
5Database连接池的参数配置
在各自的数据源可配置该数据源的连接池大小配置,选择资源—>JDBC—>数据源—〉连接池,可配置连接池最小、最大连接数及连接超时时限等。
1。
5其它关键参数
1。
5。
1EJB分发共享内存参数
用root用户登录命令行修改每个WebSphere安装路径的$WasIntallPath/AppServer/deploytool/itp/ejbdeploy。
sh内容,根据主机资源情况将EJB分发共享内存上限从默认256M修改为更大的值。
“$JAVA_CMD\
—Xbootclasspath/a:
$ejbd_bootpath\
-Xms256m–Xmx256m”
2。
WAS性能分析工具
2。
1WAS性能监控配置
后续补写
2。
2WAS性能监控
后续补写
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.log
native_stderr。
log日志可查看出JVM垃圾回收的记录及每次GC的间隔时间及运行时间,如下图所示:
红色标识分别为:
GC运行时间点、垃圾回收前内存情况、垃圾回收后内存情况、GC运行时间长.从结果可看出JVM中已无内存可再回收,JVM处于OOM的状态。
可以看出java/lang/OutOfMemoryError:
(3)收集Webserver服务器日志
收集IHS日志(access_log、error_log)及插件Plug—in(plugin—cfg。
xmlandhttp_plugin.log)的日志及配置文件,查看是否出现异常信息。
例如http_plugin.log,可能提示一个连接无法正常发送到相关WASServer,不过尝试连接其它WASServer,这种情况可能是无法连接的Server处理较繁忙的状态或者网络中断。
3。
1javacore、heapdump分析
java程序在遇到致命异常时,为了能够保留java应用发生致命错误前的运行状态,jvm在无法工作前产生两个文件,分别为javacore及heapdump文件。
3。
1.1javacore的分析
Javacore文件是一个java进程的快照,javacore文件中可以显示当时运行这个java进程的所有线程的运行情况。
Ø我们可以利用javacore来分析和判断一些故障,如:
(1)100%CPUUsage
(2)Crash或OOM
(3)Hang/Performance
ØJavacore目录的设置
在环境条目分别填入:
名称
值
描述
IBM_HEAPDUMPDIR
/wasdump/heapdump/ Heapdump重定向 IBM_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的产生有两种方式,一种是自动产生,一种是通过kill-3PID进行生成。 自动产生Javacore,一般都是出现OOM的情况. ØJavacore的分析 (1)直接打开Javacore文件查看 直接打开后,可以看到关键信息,可以看到每一个线程的执行栈,以stacktrace的方式显示。 通过对javacore的分析可以得到应用是否“卡”在某一点上,即在某一点运行的时间太长。 例如: 可看出有java/lang/OutOfMemoryError的异常信息。 (2)运用javacore分析工具 下载javacore运行工具jca: 运行java–Xmx1024m–jarjca。 jar: 可看线程运行情况: 请求线程可分为以下几种状态: 死锁,Deadlock(重点关注) 执行中,Runnable(重点关注) 等待资源,Waitingoncondition(重点关注) 等待监控器检查资源,Waitingonmonitor 暂停,Suspended 对象等待中,Object.wait() 阻塞,Blocked(重点关注) 停止,Parked Deadlock: 死锁线程,一般指多个线程调用间,进入相互资源占用,导致一直等待无法释放的情况。 Runnable: 一般指该线程正在执行状态中,该线程占用了资源,正在处理某个请求,有可能正在传递SQL到数据库执行,有可能在对某个文件操作,有可能进行数据类型等转换。 Waitingoncondition: 等待资源,如果堆栈信息明确是应用代码,则证明该线程正在等待资源,一般是大量读取某资源,且该资源采用了资源锁的情况下,线程进入等待状态,等待资源的读取。 又或者,正在等待其他线程的执行等。 Blocked: 线程阻塞,是指当前线程执行过程中,所需要的资源长时间等待却一直未能获取到,被容器的线程管理器标识为阻塞状态,可以理解为等待资源超时的线程.这种情况在was的日志中,一般可以看到CPU饥渴,或者某线程已执行了XX秒的信息。 一般建议的分析逻辑: Ø在内存溢出时,分析Javacore文件中的线程内容,可以采用自下而上的分析方法. Ø查看有多少线程被设置了Blocked状态,这些线程是在执行什么请求,并且到了堆栈最后一步在等待什么资源 Ø查找到这些Blocked线程等待的执行线程编号 Ø继续查找该线程,分析其堆栈与状态与监控器的记录的信息。 一般这些线程会处于Waitingoncondition状态,因为这些线程也是因为资源迟迟未获取到或者执行时间过长一直处于等待状体,进一步导致队列中其他需要访问这些资源的线程都被设置为Blocked状态. Ø在找到线程后,我们就可以初步将问题缩小到哪些业务应用请求存在问题,是哪一个类与哪一行代码,其等待的资源是什么。 备注: 具体情况具体分析,后续需根据实际经验完善。 3.1.2heapdump的分析 heapdump文件是一个二进制文件,它保存了某一时刻jvm堆中对象情况,这种文件需要相应的工具进行分析,可以从网上下载最新的分析工具。 因打开heapdump文件对系统内存要求较高,一般只能借用64位的服务器进行分析问题。 HeapDump的生成开关 –exportIBM_HEAPDUMP=true –exportIBM_HEAP_DUMP=true –exportIBM_HEAPDUMP_OUTOFMEMORY=true –exportIBM_JAVADUMP_OUTOFMEMORY=true –exportIBM_JAVACORE_OUTOFMEMORY=true –exportIBM_HEAPDUMPDIR=〈directory_path〉 注意: –通常HeapDump会比较大,尤其是在Heap内存设置很大的情况下 –为了重现问题,得到现场数据,建议先把HeapDump调小,推荐1G以下 –在Window上,如果HeapDump大于1G,可能会无法打开,出现OOM错误 –启动HeapAnalyzer需要指定-Xmx参数 例子: (1)启动工具: Java–Xmx2048m–jarha405。 jar (2) 内存按树状引用关系显示 (3)内存按对象和类型显示 (4)找到怀疑泄漏的内存对象进行分析 再结合javacore文件定位确认应用代码: 提交研发解决分析 备注: heapdump文件的分析,暂时缺少分析经验,后续完善更新。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- WAS 关键 性能参数 配置 异常 分析