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)收集首个故障数据捕捉日志/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.重现场景，进行相关测试(包括升级新的补丁程序、调整参数、修改应用等)

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 服务>选中按引用传递。

分析了当悔伏前比较流行的几个不同肆纳公司不同版本JVM的最大内碧雹携存，得出来的结果如下：公司JVM版本 最大内存(兆)client 最大内存(兆)serverSUN 1.5.x 1492 1520SUN 1.5.5(Linux) 2634 2660SUN 1.4.2 1564 1564SUN 1.4.2(Linux) 1900 1260IBM

�故荖ative thread无法创建，前者用MaxPermSize调整（IBM JDK没这个参数），后者调小最大堆大小或者Xss调整每个线程分配内存的大小。如果是常见的堆的溢出，确保OutOfMemory时能生成heapdump文件，用Dump analyzer或者MDD4J分析dump文件，找到堆中占用空间总数差春最大的（或者数量最多的）对象。然后调整堆范围到一个比较小的区间，比如256M～384M，重新启动服务器，在运行1小时候手动做一次heapdump，运行4小时后做一次heapdump，运行8小时候做一次（间隔仅作参考）。然后分析一下三者的区别，看看哪个对象数量增长很多，占用空间增加很大。结合OutOfMemory时候的分析，应该能锁定问题的源头。 huweihong: 内存溢出是使用WAS时会经常遇到的问题。1.现在WAS的控制台上打开详细垃圾回收。一旦出现OOM的错误时，会在nativeerr.log中有记录，也可以从这个日志中看出内存分配的情况。2。参见hashei的者冲回帖把相关日志收集齐，使用ISA中的相关工具进行日志分析，会看到一些提示的。有的时候内存溢出是WAS自身引入的，可以看看是不是有相关的补丁包。还有多数都是自己开发程序的问题，使用的对象没有释放。这个就要具体情况具体分析了。其实解决所有的问题的思路就是：大胆假设，小心求证。我的经验。：） 呵呵，其实我感觉95%以上的OOM发生都是和代码本身的质量有关系的，以下是我的一点小思路,不知道对大家是否有帮助:OOM的情况,必定会产生宕机日志,所以,首先从分析宕机日志开始.分析工具很多,根据侧重点不同进行选取即可.一般情况下无非就是两重情况:大对象和内存泄露.于是,赶紧查查业务代码,是那些地方产生的.一个好的框架会帮你节省不少首庆歼体力活的.不过我感觉一般的大对象大都是RS引起的,不小心查了几万行数据又不做分页,不宕机都不行啊。

---