WAS性能调优
was的性能优化
Websphere性能分析与优化——从Heapdump浅谈JVM堆设置不同版本的JDK可以设置的JVM堆大小是不一样的，而JVM堆的大小直接制约系统的性能，合理设置每个应用服务器中的JVM堆，在系统性能优化中是十分关键的一步。
一般来说，JVM堆可设置的大小受其版本限制，可分为以下两大类：1、32位的JDK，JVM堆最大可设置到1.5G左右2、64位的JDK，JVM堆大小暂无限制那我们该如何调整JVM的堆大小呢？在Was上如何去设定一个合理的值且多大的值才算是合理的呢？首先我们来了解下JVM堆大小对系统有哪些主要的影响，在JVM堆不足的情况下将会导致系统：1、频繁的垃圾回收（引发系统资源紧张情况，集群环境下CPU资源消耗就更严重）2、OOM，内存溢出（out of memory）系统繁忙时，一般都是在处理大量的客户端请求，或是在进行多个复杂的计算，它们都需要向JVM堆申请空间进行对象的创建。
在堆空间不足的情况下，应用系统会出现以下一些情况，从而大大降低客户的感知度：1、请求操作响应时间长2、请求操作失败，资源等待操作，内存溢出为了保证系统的性能，提高系统稳定性，我们就需要对JVM堆的详细使用情况刨根问底，以此估出一个合理的值来设置JVM堆大小。
有专家给出建议，Was每个Server的线程池不宜配置过大，一般建议值在50-120之间，而JVM堆则设置在2G内。
这个建议针对大部分系统都是适用的，如果在这个配置上系统运行还出现性能问题，可先从应用程序角度着手优化。
因为无论线程池的线程大小是多少，每个线程给系统带来的主要压力就是JVM堆资源的占用。
在32位的Java虚拟机上，JVM堆最大可设置到1.5G左右。
假设请求从客户端来到Was，Was从线程池中分配一个线程处理这个请求，同时从JVM堆空间申请相应的资源进行操作。
假设这是一个上传5MB的Excel的线程，那么在上传与处理这个Excel过程中，线程占用的JVM堆的资源会越来越多，甚至有可能需要向JVM堆申请超过30MB的空间（当然30MB的堆空间不是绝对，这与代码设计密切相关，如果到Excel上传过程中，还要进行分析，封装，持久化等操作）。
WAS常见问题处理与系统维护建议
系统维护建议
健康检查 问题管理 补丁管理
Q&A
Page 3
<Document Title> | <Date>
IBM Confidential
© 2008 IBM Corporation
Global Technology Services
Page 8
Global Technology Services
Client Focus Commitment Collaboration
WAS的基本组件
Page 9
<Document Title> | <Date>
IBM Confidential
© 2008 IBM Corporation
Global Technology Services
Client Focus Commitment Collaboration
Java堆内存溢出 – 内存泄漏
正常情况下堆内存的大小应该是均值稳定的锯齿状图形
Page 19
<Document Title> | <Date>
IBM Confidential
堆内存耗尽
内存泄漏 内存使用量短时间内达到最大值（如很大的数据库查询结果集）
大对象分配
即为大对象 可添加JVM参数找出大对象：-Xdump:stack:events=allocation,filter=#5m
>64KB
堆内存碎片化（主要是V6.0及以前的版本）
pinned
Page 5
<Document Title> | <Date>
性能调优总结
深圳割接性能调优总结BSS测试部：邹家勇HSC从一开始对订购关系与三户资料同步接口进行压测时，不能满足性要求到最后性能压测结果达到要求的10倍性能以上，经过了以下几个关键的优化步骤。
调优过程：在压测时首先要排除的是高消耗SQL（经过AWR报告分析后HSC没有出现高消耗SQL）本次SZ割接压测经过以下几个关键点的调优：1)脚本参数调优（数据已存在，字段值太长错误较多调节脚本参数模式及参数长度）2)JDBC配置调优(JDBC使用率100%，连接数调成100后，极限测试时使用在80个连接左右）3)WAS配置调优（主要是webcontainer调成200，极限测试时使用达到200，但主机CPU资源消耗在50%以上，且TPS也超过指标10来倍，不再增加配置）4)IHS配置调优（主要是http.conf文件参数调整）5)linux系统调优（主要是网络参数调整，及open file调整）6)Systemout日志中不打印应用日志（减少不必要的磁盘IO消耗）。
下面逐一分解每个关键调优时出现的问题及定位脚本参数调优举例说明：在测试过程中，通过查看WAS日志，报大量的主键冲突，经查明后，发现是发送的报文中写表的主键字段值重复导致，经过对主键字段的重新参数化后，不再出现主键冲突，大量主键冲突也不符合平台业务交易场景！（原来红色部分值采用一段随机值或序列发现还有重复的值出现（测试工具本身问题））订购关系脚本Action(){lr_think_time(3);lr_start_transaction("订购关系同步_SubProductSyn_request");soap_request("StepName=SOAP Request","URL=http://{IP}:{port}/Nodehsc/services/HscService?wsdl","SOAPEnvelope=""<S:Envelope xmlns:S=\"/soap/envelope/\">""<S:Body>""<SubProductSynRequest xmlns=\"/webservice\">""<RequestMessage>""<MessageHeader>""<Msisdn>195{servnumber}</Msisdn>""<AreaNo>{region}</AreaNo>""<CommandId>SubProductSyn</CommandId>""<Version>1.0</Version>""<TransID>SZ{transid2}{transid1}{transid}</TransID>""<LogID>0</LogID>""<SeqID>0</SeqID>""<MaxSeqId>1</MaxSeqId>""<Recdate>{date}</Recdate>""<InterFrom>EDFS-----</InterFrom>""<OperID>auto</OperID>""</MessageHeader>""<MessageBody>""<TradeType>ChangeProduct</TradeType>""<OrderID>{region}99{OrderID}</OrderID>""<SubsProductList>""<orderlineid>{region}99{OrderID}</orderlineid>""<SubProduct>""<OperType>I</OperType>""<Subsprodid>{region}99{subsprodid1}{subsprodid}</Subsprodid>""<IsMainProd>0</IsMainProd>""<Subsid>{region}99{subsid}</Subsid>""<Prodid>prod.{prodid1}{prodid2}</Prodid>""<Packageid></Packageid>""<Packageprodid></Packageprodid>""<Productkind>0</Productkind>""<BillId>{BillId}</BillId>""<BasePrice>0.0</BasePrice>""<Fee>0.0</Fee>""<StartDate>{date}</StartDate>""<EndDate>20991231235959</EndDate>""<GrpSubsid>{subsprodid}</GrpSubsid>""<Status>1</Status>""<Donortype></Donortype>""<Donorsubsid></Donorsubsid>""<Donorsubsprodid></Donorsubsprodid>""<SubProdAttrList>""<SubProdAttr>""<Optype>I</Optype>""<Subsid>{region}99{subsid}</Subsid>""<Serviceid>Ptest{servicesid}</Serviceid>""<Attrid>ttPtest{servicesid}</Attrid>""<AttrValue>195{servnumber}</AttrValue>""<STARTDATE>{date}</STARTDATE>""<ENDDATE>20991231235959</ENDDATE>""</SubProdAttr>""</SubProdAttrList>""</SubProduct>""</SubsProductList>""<SubServiceList>""<SubService>""<OperType>I</OperType>""<Subsid>{region}99{subsid}</Subsid>""<Serviceid>Ptest{servicesid}</Serviceid>""<Prodid>prod.{prodid1}{prodid2}</Prodid>""<SubsProdOid>{region}99{subsprodid}</SubsProdOid>""<ServiceStatus>1</ServiceStatus>""<StartDate>{date}</StartDate>""<EndDate>20991231235959</EndDate>""<servType></servType>""<SubServType></SubServType>""<SubsServResoureList>""<SubsServResoure>""<ResClass>{ResClass}</ResClass>""<Optype>I</Optype>""<SubsProdOid>{region}99{subsprodid}</SubsProdOid>""<ResType>50</ResType>""<Resid>521</Resid>""<StartDate>{date}</StartDate>""<EndDate>20120908030405</EndDate>""</SubsServResoure>""</SubsServResoureList>""</SubService>""</SubServiceList>""</MessageBody>""</RequestMessage>""</SubProductSynRequest>""</S:Body>""</S:Envelope>","SOAPAction=SubProductSyn","ResponseParam=response","Snapshot=t1370244229.inf",LAST);lr_end_transaction("订购关系同步_SubProductSyn_request",LR_AUTO);web_find("web_finded","What=成功","RightOf=ResultDesc>","LeftOf=</ResultDesc",LAST);return 0;}调整如下：1．"<TransID>SZ{transid2}{transid1}{transid}</TransID>"Transid为写日志表主键（22位长度）：分成三段，每段取用6位随机值，在大并发的情况下，几乎不会随机到相同的值2．"<Subsprodid>{region}99{subsprodid1}{subsprodid}</Subsprodid>"Subsprodid:为订购表主键：分成三段region为序列值，subsprodid1为6位随机值，subsprodid为5位随机值。
was性能问题的发现和处理
测试部
目
1
录
检查was状态
2
WAS v5 监控 WAS v6 监控 应用服务器响应慢时查看
3
4
1 、检查WAS状态
1 检查IHS状态
• 确认用户使用的端口号，如果是80，可使用命
令“telnet ip port”，其中port可以是80，如
果总是显示“正在连接”，说明IHS连接被占 用，此时检查WAS状态 • 检查IHS的日志文件有没有报错信息，一般日 志文件在/IBMHttpServer/log/error.log中，如
果M/WebSphere/AppServer/logs/Server1/ Systemout.log文件和SystemError.log中查
找Exception信息，如锁超时或死锁等
• 在安装目录下使用命令生成线程转储文件具 体分析
生成线程转储文件
• 使用wsadmin命令提示符，获得该问题应用服 务器的句柄： wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*] • 生成线程转储： wsadmin>$AdminControl invoke $jvm dumpThreads • 在安装根目录中查找输出文件： javacore.date.time.id.txt
线程转储文件的参数
• state:R的用户线程：是活动的并在强制转储或
进程退出时运行，可以确定当时该线程正在运行
的是哪个模块 • state:WC的用户线程，可以确定在等待数据源、 jms等的资源响应或程序处于sleep状态
2 、WAS 5 监控
WAS7 ND+IHS性能调优出现的相关问题解决办法
at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:668)
加上这个参数之后，再做测试，则上述问题解决。 集群环境下能够支撑200并发提交工作流请求，持续运行2天。
这个参数应该是WAS7新加的，因为加这个参数有版本要求，必须是 7.0.0.13 之后的版本，否则会报错。
3、附件上传数据流量测试
这个模块目前正在测试，如有问题再说。
呜呼哀哉。。。 希望压力测试的时候，测试人员以后别犯这种低级错误了。真是浪费人力。不过话说回来，我们的平台框架在设计的时候应该也是有点问题的。因为在session中存入了大量的对象，这肯定会限制单个节点的最大用户在线数量。就目前的压力测试情况来看，如果系统有12000个用户在线的话，系统就死翘翘了。
[11-10-21 3:28:12:760 CST] 000001f1 ThreadMonitor W WSVR0605W: 线程“WebContainer : 662”（000002f4）已保持活动状态 621688 毫秒，此线程可能已挂起。在服务器中共有 177 个线程可能处于挂起状态。
at java.util.Collections$SynchronizedSet.hashCode(Collections.java:835)
下面是出错日志摘要：
IHS error.log ：
[Thu Oct 20 10:58:24 2011] [notice] mpmstats: reached MaxClients (4000/4000)
WAS关键性能参数配置及异常分析
W A S关键性能参数配置及异常分析------------------------------------------作者xxxx------------------------------------------日期xxxxWAS关键性能参数配置及异常分析目录WAS关键性能参数配置及异常分析 (2)性能关键参数配置 (4)1.1 JVM（Java虚拟机） (4)1.2 GC（详细垃圾回收） (4)Web Container (6)1.4 Data Source数据源 (7)安装数据源驱动 (7)配置全局数据源变量 (8)配置数据源驱动 (8)配置数据源 (9)1.4.5 Database连接池的参数配置 (11)1.5 其它关键参数 (12)1.5.1 EJB分发共享内存参数 (12)性能分析工具 (13)2.1 WAS性能监控配置 (13)2.2 WAS性能监控 (13)异常分析 (13)3.1 关键日志文件 (13)3.1 javacore、heapdump分析 (15)3.1.1 javacore的分析 (15)3.1.2 heapdump的分析 (21)1.WAS性能关键参数配置JVM（Java虚拟机）Heapsize（-Xms和-Xmx）：heapsize的大小依赖于系统平台和具体的应用等多种因素。
最大heapsize需要小于机器的物理内存，一般来说，默认最小heapsize为256m。
例如NG设置的JVM为-Xms 512m，-Xmx 2048m。
如果在WAS应用服务器未设置JVM参数或者设置JVM参数不合理，会有可能告成应用服务器处理效率低或者造成OutOfMemoryError的情况。
备注：2m代表是2m的程序对象GC（详细垃圾回收）GC（Garbage Collection）：当需要分配的内存空间不再使用的时候，JVM 将调用垃圾回收机制来回收内存空间。
一般来说，良好的GC状态需要保证相邻两次垃圾回收的平均间隔时间应当是单次垃圾回收所需时间的至少5-6倍。
WAS常见问题处理与系统维护建议
Page 15
<D❖ocum6e4nt-Tbitliet>环| <境Date寻> 址空间非常大，本地内存理论上可以很大
执行脚本文件： ❖ C:\<was_home>\profiles\<profile_name>\bin>wsadmin -f myScript.py
Page 11
<Document Title> | <Date>
❖ WebSphere Application Server (WAS) 介绍 ❖ WAS常见性能问题处理
❖ 系统维护建议
健康检查 问题管理 补丁管理
❖ Q&A
Page 14
<Document Title> | <Date>
WAS使用的内存
❖ Java 堆内存（Java heap)
存放Java对象的内存空间
通过-Xms（初始堆大小）和-Xmx（最大堆大小）设置，并在运行过程中由 JVM动态调整
❖ 基于web的管理工具 -- 管如理何控制管台理WAS
❖ 基于脚本编制的管理工具 -- wsadmin
Page 9
<Document Title> | <Date>
❖ 单机环境如：何运管行理在W本ASse–r管ve理r上控，制只台能管理自 己
❖ ND环境：运行在dmgr上，可管理单元中所 有的server，通过“同步”操作将配置更改 同步到各个节点
内存问题 响应慢/线程挂起 高CPU crash宕机
❖ 系统维护建议
健康检查 问题管理 补丁管理
❖ Q&A
Page 2
<Document Title> | <Date>
WebSphere性能调优-垃圾收集器
WebSphere 性能调优-垃圾收集器基于 WebSphere 构建的企业应用，时常会出现性能问题，在严重的情况下还会提示出内存溢出，这是 一件很让人恼怒的事情。
在 WebSphere Application Server(Was)运行的时候，内存溢出，会生成大量的 溢出文件，如 Javacore, Heapdump 等文件，占用了大量的磁盘空间。
在这种情况下，时常会出现一连串的 系统问题，如部署在 Was 的所有应用服务都报错，Was 连控制台也无法访问等。
为解决问题，我们通常会选择重新启动整个 Was 或者服务器，然后分析运行日志 SystemOut.log、yst emErr.log、ative_stdout.log、native_stderr.log 和系统内存溢出的时候产生的 Javacore、Heapdump 文件来寻找出问题。
那么，为什么会出现内存溢出呢？ 应用服务器在运行过程中需要创建很多对象，而在应用服务器的堆空间大小有限的情况下，请求进程 不断申请空间来创建与存放对象，在达到上限时而服务器又没能释放出空间来处理申请空间的请求就会出 现内存溢出情况。
这就像吹气球，当气球中的气体到达一定程度时，气球就会被撑爆。
（32 位的 JDK 的 J vm 堆空间分配最大支持 1.5G 的大小，超过则无法正常启动。
而 64 位的 JDK 堆大小分配无限制，其大小受 到服务器的内存限制。
）通常在投入生产的系统中，出现溢出一般都是对象分配不合理导致的。
在此，让我们先了解下 Java 世界里，对象与对象管理是怎么一回事。
在 Java 的体系中，所有的类作为一个对象（包括 Jdk 本身提供的类，应用中由开发人员编写的类）， 都是直接或者间接继承了 ng.object 产生的。
这些类被创建的时候都会向 Jvm 堆申请一定的内存空 间存放，因此在 Jvm 堆空间里会存放各式各样的对象，有的是静态类型，有的是私有类型等等，而这些对 象都是通过垃圾收集器进行管理的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1.设置Web Container的最大、最小并发用户
在管理控制台中点击应用程序服务器> server1 > 线程池>WebContainer（默认为10,50），根据观察的性能情况和应用情况输入合适的最小、最大进程数。
如将最大进程数改为：1000，最小进程值改为400，Default（默认为5,20）、TCPChannel.DCS（默认为5,20）进程值同样改为最大值1000，最小值400，并选上允许线程分配超过最大线程大小，如下图：
2.对象请求代理（ORB）的线程池大小：
在管理控制台中点击应用程序服务器> server1 > ORB 服务> 线程池，根据观察的性能情况和应用情况输入合适的最小、最大进程数。
如将最大进程数改为：400，最小值改为20，（默认是10和50）并选上允许线程分配超过最大线程大小，如下图所示
3.JVM堆参数设置的性能调优
应用程序服务器> server1 > 进程定义> Java 虚拟机，根据硬件物理内存和应用情况输入合适的初始堆大小、最大堆大小。
如将初始堆大小改为768、最大堆大小改为2048。
2048为最大值，如下图所示：
通用JVM参数改为：-Djava.awt.headless=true
4.设置数据库的连接池属性：
JDBC 提供者>数据库JDBC驱动名称> 数据源> 数据源名称> 连接池，根据观察的性能情况和应用情况输入合适的最小、最大连接数。
最小值为：20，最大值为：50。
分别更改uissdbpool、uissdbpoolgw连接池的属性，如下图所示：
5.ORB参数调用方式的性能调优：
应用程序服务器> server1 > ORB 服务>选中按引用传递。
如下图所示；
6.修改uiss-gw的类装入器，如下图
7.日志记录配
将JVM日志文什件大小改为2MB，历史日志文件大小改为10。
默认为2和1 1,更改http server的配置文件参数KeepAlive。
原因：这个值说明是否保持客户与HTTP SERVER的连接，如果设置为ON，则请求数到达MaxKeepAliveRequests设定值时请求将排队，导致响应变慢。
方法：打开ibm http server安装目录，打开文件夹conf，打开文件httpd.conf,查找KeepAlive值，改ON为OFF,其默认为ON
2,更改http server的配置文件参数ThreadsPerChild值到更大数目，默认为50 原因：服务器响应线程的数量
方法：打开ibm http server安装目录，打开文件夹conf，打开文件httpd.conf,查找ThreadsPerChild值，默认为50，改到更大数目,视用户数多少而定,一般改到客户机数量的1.1倍，如200台，则设为220
3，关闭http server日志纪录
原因：http server的日志IO影响性能
方法：打开ibm http server安装目录，打开文件夹conf，打开文件httpd.conf,查找CustomLog值，找到没有注释的那行(行的开头没有符号"#"),将那行用符号"#"注释掉，以关闭日志纪录，提高处理性能。
4,更改Websphere的服务器处理线程数
原因：线程的数量影响同时并发的请求数量
方法：打开管理控制台，依次打开目录树，服务器->server1->web容器->线程池，修改"最大大小"的值,默认是50,改到更大数目,具体视总用户数量和机器的配置而定，一般设置其等于或小于http server设置的MaxKeepAliveRequests的值。
WS优化的经验：
1．Java 虚拟机初始堆大小和最大堆大小(位置：server1 > 进程定义>java 虚拟机)
WS通常默认是256，可以适当调整最大堆为512。
不过也不要调的过大，小心WS启不启来，有一次我把初始堆调成768最大堆调成了2048，当我startserver -server1 时就提示WS无法初始化，原因是内存不足，所以一定要根据机子的性能来调整
2．web容器的线程池最小大小和最大大小
3．Jdbc连接池属性
这个最难把握，因为最大连接数、最小连接数、连结超时、获得时间等等都要依据数据库及网张络的性能来调整。
而且获得时间、不使用超时、时效超时是互相联系的一组参数，一般来说：获得时间要小于不使用超时及时效超时，且三个不能为零，是最好的!
4．启用servlet高速缓存
5．语句高速缓存大小。