一、对外表现

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 的较早版本中使用的格式。

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

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

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

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

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

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

发出消息或跟踪事件的记录组件的全名。这通常是 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

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

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


下载 (17.74 KB)

保存修改

分析方法：

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自动化部署及实时监控专题讨论

五、其他