文章转自WebSphere 中国论坛

 

[WAS维护管理] WAS问题解决思路预研



一、对外表现

1.应用访问速度慢、应用报错(WAS性能差)

2.应用(server)停止对外服务无法访问(WAS服务挂起或者服务器宕机)

二、xxx系统我们发现过的问题

1.WAS内存处理大对象内存分配bug(大报文(20M)-小报文(20M)-20M)

2.内存回收碎片(java heap free memory很多,一个很小的报文都申请不到内存)

3.WAS MDB侦听MQ队列问题

三、排查思路

思路:

1.查看收集服务器性能指标,内存使用、CPU使用包括磁盘I/O等。

2.查看收集操作系统级日志。

3.根据服务器的性能指标以及操作系统级日志,基本定位是否存在影响性能的瓶颈,通过排除那些不是导致问题发生的因素,以缩小问题的范围,可以使问题简单化,并且避免浪费时间。举例:

CPU使用不高,用户感觉交易响应时间很长,可以断定是由于系统的某一小部分造成了瓶颈,导致了所有的请求都在等待。我们可以考虑,线程池的数量开的太小,导致所有的请求都在排队等待进入线程池,因为没有可用的线程使用,所以这个交易请求一直在排队,导致交易响应时间很长。数据库连接池开的太小,也会有同样的表现。

CPU使用很高,用户感觉交易响应时间很长,比较复杂。可能的根源之一是硬件资源不够。 根源之二是应用系统中产生了多个大对象。根源之三是程序算法有问题。 解决思路如下:用性能分析器, 对运行环境进行分析,分析哪个类甚至于哪个函数消耗了这么多的CPU,并找到相应的解决方案。

4.收集分析WAS日志

当应用服务器发生挂起、或者发生out-of-memory等现象时,为了更好的全面分析问题,则需要收集一定的日志信息,一般情况下我们需要收集以下这些日志:

1)收集垃圾回收日志native_stderr.log或者native_stdout.log。

2)收集应用服务器(install_root/profiles/profile_name/logs/server_name)下所有的日志(systemout)。

3)收集install_root/profiles/profile_name/目录下的JavaCore文件和Heapdump文件,如果没有这些文件,可以在服务器没有响应的时候,运行命令来生成这些文件,对于IBM JDK中可以运行kill -3 PID_Java_jvm,然后每隔两分钟,重复执行该命令,至少3次,通过该命令生成的JavaCore文件会在install_root/ profiles目录下。

4)收集首个故障数据捕捉日志<profile_home>/logs/ffdc。

5)收集Web server服务器,插件Plug-in(plugin-cfg.xml and http_plugin.log)的日志及配置文件。

6)如果应用程序具有自身的日志文件,也应收集对应的日志文件。

5.应用分析工具基本定位问题

1)使用WAS自带工具分析(管理控制台的故障诊断、日志分析器等)。

2)使用其他分析工具,可分析对象报错相关日志文件以及java core ,heap dump文件等(GC、DUMP)。

6.确定问题所在找出解决问题办法

7.重现场景,进行相关测试(包括升级新的补丁程序、调整参数、修改应用等)



四、专题

1.分析方法讨论

1)应用日志

一般说明应用程序存在问题,查看分析相关日志:System.Out.log 、SystemErr.log、activity.log定位应用程序引起的问题。

日志介绍

System.Out.log 、SystemErr.log 属于JVM 日志。WebSphere Application Server 写格式化的消息到 System.out日志。另外,应用程序和其他代码可以写入这些日志,通过print() 和 println() 方法实现。有些开发工具箱(Developer Kit)内置如 Throwable 类的 printStackTrace() 方法也可以写入这些日志。通常,System.out 日志用于监控应用程序服务器的运行是否正常。System.out 日志可用于问题确定,但建议改为使用 IBM 服务日志和日志分析器的高级能力。

System.err 日志包含异常堆栈跟踪信息,这在执行问题分析时很有用。

因为每个应用程序服务器都代表 JVM,所以每个应用程序服务器和它的所有应用程序都有一组 JVM 日志,缺省情况下该日志位于 installation_root/profiles/profile_name/logs/server_name 目录。在 WebSphere Application Server Network Deployment 配置的情况下,也为 Deployment Manager 和每个节点管理器创建 JVM 日志,因为它们也代表 JVM。

activity.log为IBM 日志,应用程序服务器从各种 WebSphere Application Server 组件的活动创建服务或活动日志文件。服务或活动日志文件(activity.log)是二进制文件,它位于 install_root 的 logs 目录中,我们可以使用日志分析器用于查看服务或活动日志文件。

查看 JVM 日志

JVM 日志是作为纯文本文件写的。因此,查看这些日志没有特殊的要求。它们位于 installation_directory/profiles/profile_name/logs/server_name 目录中,并在缺省情况下命名为 SystemOut.log 和 SystemErr.log。

日志格式:

根据 JVM 日志配置的不同,格式化的消息可以用基本或高级格式写入 JVM 日志。

消息格式 格式化的消息可以使用这两种格式中的一种写入 JVM 日志:

基本格式 这是 WebSphere Application Server 的较早版本中使用的格式。

高级格式 如果可能,则通过添加有关事件的信息来扩展基本格式。

下面是一些日志常用格式,可以帮助我们更好的查看日志,可能找到的采用这些格式的各种字段如下:

TimeStamp

时间戳记是使用其被格式化所处于的进程语言环境格式化的。它包含标准日期(例如,YYMMDD),以毫秒为精度的 24 小时时间和时区。

ThreadId

从发出消息的线程的散列代码生成的 8 个字符的十六进制值。

ThreadName

发出消息或跟踪事件的 Java 线程名。

ShortName

发出消息或跟踪事件的记录组件的缩写名称。这通常是 WebSphere Application Server 内部组件的类名,但也可以是一些用户应用程序的其他标识。

LongName

发出消息或跟踪事件的记录组件的全名。这通常是 WebSphere Application Server 内部组件的标准类名,但也可以是一些用户应用程序的其他标识。

EventType

表明消息或跟踪事件类型的一个字符字段。消息类型是大写的。可能值包括:

F致命消息。

E错误消息。

W警告消息。

A审计消息。

I参考消息。

C配置消息。

D详细信息消息。

O通过用户应用程序或内部组件直接写入 System.out 的消息。

R通过用户应用程序或内部组件直接写入 System.err 的消息。

Z表明不可识别的类型的占位符。

类名:发出消息或跟踪事件的类。

方法名称:发出消息或跟踪事件的方法。

组织:拥有发出消息或跟踪事件的应用程序的组织。

产品:发出消息或跟踪事件的产品。

组件:发出消息或跟踪事件的产品内的组件。

基本格式

以基本格式显示的消息事件使用下列格式。符号 <name> 表明将总是在基本格式消息中出现的必需字段。符号 [name] 表明将被包括的可选的或有条件的字段,如果可以确定它们的话。

<timestamp><threadId><shortName><eventType>[className][methodName]<message>

高级格式

以高级格式显示的消息事件使用下列格式。表示法 <name> 用于表明将总是以消息条目的高级格式出现的必需字段。表示法 [name] 用于表明将被包括的可选的或有条件的字段(如果可以确定它们的话)。

<timestamp><threadId><eventType><UOW><source=longName>[className][methodName]<Organization><;Product><Component>[thread=threadName]<message>

2)内存泄漏

使用工具:

日志格式:

TCBS系统:An Out of Memory error is generally indicated when a java.lang.OutofMemoryError exception is thrown.

联网核查日志格式: 跟踪日志native_stderr.log 和 native_stdout.log



< AF[2007]: Allocation Failure. need 41943056 bytes, 17284 ms since last AF>

< AF[2007]: managing allocation failure, action=2 (495013168/1073674752)>

<GC(2007): GC cycle started Mon Jun 25 08:21:38 2007

<GC(2007): freed 463326696 bytes, 89% free (958339864/1073674752), in 915 ms>

<GC(2007): mark: 122 ms, sweep: 20 ms, compact: 773 ms>

<GC(2007): refs: soft 0 (age >= 32), weak 0, final 544, phantom 7>

<GC(2007): moved 1919434 objects, 110061376 bytes, reason=1, used 29960 more bytes>

< AF[2007]: managing allocation failure, action=3 (958339864/1073674752)>

< AF[2007]: managing allocation failure, action=4 (958339864/1073674752)>

< AF[2007]: managing allocation failure, action=6 (958339864/1073674752)>

JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.

JVMDG315: JVM Requesting Heap dump file

JVMDG318: Heap dump file written to /picpdata/dump/PICPNode01/heapdump172112.1182730898.phd

JVMDG303: JVM Requesting Java core file

JVMDG304: Java core file written to /picpdata/dump/PICPNode01/javacore172112.1182730902.txt

JVMDG274: Dump Handler has Processed OutOfMemory.

< AF[2007]: Insufficient space in Javaheap to satisfy allocation request>

< AF[2007]: completed in 9600 ms>

打开详细垃圾回收日志方法:

应用程序服务器 > server1 > 进程定义 > Java 虚拟机,勾选如下图所示:

WQN.jpg

保存修改

分析方法:

3)Java core ,heap dump

使用工具:

分析方法:

4)其他

2.was性能调优

部署在WAS上的J2EE应用程序,其性能是由多个因素决定的。比如网络、数据库、内存分配、WAS服务器的配置以及应用程序的设计。对于一个标准的J2EE应用,一个请求到来时,往往需要经过多次转发:网络 > Web服务器Web容器 > EJB容器 > 数据库。而每一次转发,都可能造成请求处理的瓶颈,使得应用程序整体性能下降。如果我们把每一次转发的待处理资源都看成一个队列,如图:





调优的基本步骤如下:

1)设置的是Web Server的最大并发用户:

这个设置是在conf/httpd.conf这个文件里面配置的。在Unix系统中,对应的属性是MaxClient。

2)设置Web Container的最大、最小并发用户:

在管理控制台中点击应用程序服务器 > server1 > 线程池 >WebContainer,根据测试性能情况和应用情况输入合适的最小、最大进程数。

3)对象请求代理(ORB)的线程池大小:

在管理控制台中点击应用程序服务器 > server1 > ORB 服务 > 线程池,根据测试性能情况和应用情况输入合适的最小、最大进程数。

4)设置数据库的连接池属性:

JDBC 提供者 >数据库JDBC驱动名称 > 数据源 > 数据源名称> 连接池 ,根据测试性能情况和应用情况输入合适的最小、最大连接数。

5)JVM堆参数设置的性能调优:

应用程序服务器 > server1 > 进程定义 > Java 虚拟机,根据硬件物理内存和应用情况输入合适的初始堆大小、最大堆大小。

(XX系统)K值调整针对WAS内存碎片问题IBM建议值:-Xk30000 -Xk24000,2400k (core dump抛出建议值)

6)ORB参数调用方式的性能调优:

应用程序服务器 > server1 > ORB 服务>选中按引用传递。

7)关闭动态加载开关:

企业应用程序 > 应用名称 > 关闭启动类重新装入开关。

关闭会话序列化,应用程序服务器 > server1 > 会话管理 > 分布式环境设置 > 分布式会话选择无即可。

这个调优的步骤只是涉及了利用WAS服务器参数的调整来优化应用程序的性能,实际上性能的好坏很大部分是取决于应用的设计。系统上线前进行的性能测试也是重要的工作之一。

3.WAS自动化部署及实时监控专题讨论

五、其他