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 堆空间里会存放各式各样的对象，有的是静态类型，有的是私有类型等等，而这些对 象都是通过垃圾收集器进行管理的。
was8.5性能优化
WebSphere(was8.5)性能优化2018年8月10日整理目录1.WAS中的基本调优步骤 (3)2.WAS 性能差的几种表现及解决方法 (4)3.案例说明 (4)4.WAS配置优化概要 (5)4.1 服务线程池 (5)4.2 数据源连接池 (7)4.3 数据源语句高速缓存大小 (9)4.4 JVW堆参数设置 (11)4.5 设置会话管理 (13)4.6 WEB容器高速缓存开启 (14)4.6 调整JVW日志 (16)5.TPV 监控列表 (17)1.WAS中的基本调优步骤部署在WAS上的J2EE应用程序，其性能是由多个因素决定的。
例如网络、数据库、内存分配、WAS服务器的配置以及应用程序的设计。
对于一个标准的J2EE应用，一个请求到来时，往往需要经过多次转发：网络 > Web服务器Web容器 > EJB容器 > 数据库。
而每一次转发，都可能造成请求处理的瓶颈，使得应用程序整体性能下降。
如果我们把每一次转发的待处理资源都看成一个队列，如图3：待处理资源队列对于WAS调优，要记住的一个基本原则就是，使得在队列中等待的请求的数量最小化。
在实践中我们发现，为了达到这个目的，最有效的配置方式就是使得队列成为一个“漏斗”。
也就是说，越靠近客户端的队列，其容量越大，而后面的队列，其容量要略小于或等于前面的队列。
按照这个原则，调优的基本步骤如下：1.设置的是Web Server的最大并发用户：这个设置是在conf/httpd.conf这个文件里面配置的。
在Unix系统中，对应的属性是MaxClient；在Windows系统中，对应的属性是ThreadsPerChild。
2.设置Web Container的最大、最小并发用户：在管理控制台中点击应用程序服务器 > server1 > 线程池 >WebContainer，根据观察的性能情况和应用情况输入合适的最小、最大进程数。
WAS中间件服务器介绍
WAS中间件服务器介绍WAS中间件服务器介绍1、概述WAS（WebSphere Application Server）是IBM公司开发的一种中间件服务器，用于提供企业级应用程序的运行环境和基础设施。
它可以在多种操作系统上运行，并支持多种编程语言和开发框架。
本文将详细介绍WAS中间件服务器的各个方面。
2、功能特性2·1 应用程序部署WAS提供了强大的应用程序部署功能，支持将应用程序打包成可部署的文件，然后在服务器上进行安装和配置。
它还提供了自动化的部署工具，可以简化应用程序的发布和更新过程。
2·2 事务管理WAS支持分布式事务处理，可以保证多个相关操作的一致性和原子性。
它提供了事务管理器和事务日志功能，确保在发生故障或异常情况下数据的完整性。
2·3 高可用性和负载均衡WAS具备高可用性和负载均衡的能力，可以通过多台服务器实现应用程序的冗余部署和负载分担。
它提供了故障恢复和故障转移的功能，保证应用程序的持续可用性。
2·4 安全性和认证授权WAS提供了丰富的安全功能，包括身份认证、访问控制和数据加密等。
它支持多种身份认证方式，如基于用户名密码的认证、证书认证和单点登录。
同时，它还提供了细粒度的授权机制，可以对用户进行精确的权限控制。
2·5 监控和性能调优WAS内置了监控和性能调优工具，可以实时监测应用程序的运行状态和性能指标。
通过这些工具，可以及时发现并解决潜在的性能瓶颈，提升应用程序的性能和响应速度。
3、部署架构3·1 单节点部署单节点部署是将WAS安装在单台服务器上，适用于小型应用程序或开发测试环境。
在此架构下，WAS担任应用程序的运行和管理角色。
3·2 多节点部署多节点部署是将WAS安装在多台服务器上，通过集群技术实现应用程序的冗余和负载均衡。
在此架构下，WAS集群中的各个节点相互协作，共同提供应用程序的服务。
4、集成与扩展WAS支持与其他中间件和系统的集成，可以与数据库、消息队列、企业服务总线等进行无缝连接。
IBM WAS的几个性能分析工具
1.heapdump分析工具ha439.jar2.javacore分析工具jca437.jar3.native_stderr分析工具ga439.jar其中，在使用的时候，日志文件较大的话，要使用java -jar -Xmx参数增大最大内存值。
在分析native_stderr日志，即GC信息分析的时候工具可能出现日期时间数据不能解析的异常，这时你要试着替换检查一下日志文件中的日期时间格式，我记得是要增加或减少一个空格。
（以前遇到过这个问题，GOOGLE全球都没发现有人给个答案，结果自己把它试出来了）调用方式在cmd下运行命令：java -Xmx768m -jar ha439.jarjava -Xmx512m -jar jca437.jarWebsphere性能优化——面向切面分析Javacore一般情况下，我们会通过调整参数来提高系统性能，如线程池大小、连接池大小或者ORB 池等，也可以利用IHS实现静态文件分离，以上方式都是通过配置调整，利用并行或压力分离等方式实现对系统的优化。
我们还可以更换运算率更高的服务器，或者增加更多的物理服务器，通过硬件角度扩展达到性能调优的目的，但这种硬件扩容调优方式会使得项目的成本费用会大大增加，且优化成效还不一定能达到期待值。
当然，在以数据库操作为主的业务系统还可以调整数据库的参数，例如内存占用比率，增加命中，缓冲等的优化。
但以上这些优化方式都是从系统周边环境的角度进行考虑的，如果我们不了解我们的业务应用代码在JVM中是如何运行的，又或者各执行的请求是如何进行处理的，其处理的过程及处理步骤处于什么状态下，就盲目开展优化工作，就有了点瞎子过河——摸不着边的意思了。
因此，尽可能收集更多的信息，会让我们的优化工作事半功倍！除了自己实现线程请求监控记录外，我们还可以通过Javacore文件来进行线程转储。
通过采集和分析Javacore，了解JVM的运行情况，可以使我们更清晰地了解系统的整体运行情况，帮助我们判断系统是否运行正常，或是在繁忙时存在哪些隐患。
WAS系统性能调优建议
应用程序调整建议
1.搜索应用中所有的System.out.println（），注释掉类似的代码，非常影响性能。循环中慎用。
2.字符串连接+，采用StringBuffer.append的方式，可以提高代码性能。
3.避免对资源(JNDI,File,DS)的访问语句重复循环调用，优化这部分代码。循环中慎用。
数据源
1.JDBC驱动选择支持XA或非XA的JDBC Driver，依据应用是否是2阶段提交。通常用oracle提供的ojdbc14.jar。
2.JDBC数据源配置对性能有显著的影响。
调整：资源> JDBC提供程序> JDBC_provider >数据源> data_source >连接池设置
最小连接数。建议设置为20，实际生产环境并发数在100左右可以考虑设置为30
WebSphere Application Server数据源属性
日志文件大小调整
在压力测试和生产环境，为保障保留更多的日志信息，要调整JVM日志文件的大小和个数。
“故障诊断>日志和跟踪”，点击“server1”点击“JVM日志”
找到System.out栏，修改“文件大小最大大小”的值为20，“历史日志文件的最大数”的值为10。
3.当客户机数突然增加时，某些客户机可能会接收到“连接被拒绝”错误消息。增大ListenBacklog和StartServer参数有助于减少或消除此错误。
4.如果系统中静态图片比较多，可以配置HTTPServer做静态页面缓存，可以提高页面显示效率。
5.可考虑关闭HTTPServer的日志。
注释配置文件中行CustomLog logs/access.log common。调试阶段不必注释，便于查找问题。
实验4：WAS性能调优基本参数
1、调整JVM堆大小操作方法：登录W AS控制台：修改初始堆大小，与最大堆大小。
勾选垃圾回收或者直接修改server.xml文件/was/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/loopbackNode01Cell/nodes/F UNDAPPNode01/servers/server1/server.xml在<jvmEntries>元素中，initialHeapSize="256" maximumHeapSize="512"重启server2、开启servlet高速缓存WAS7.0后的版本建议开启。
3、WebContainer线程池。
调整为50至150登录W AS控制台：或者直接修改server.xml文件/was/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/loopbackNode01Cell/nodes/F UNDAPPNode01/servers/server1/server.xml在<threadPools name=”WebContainer”>元素中，如下属性minimumSize="50" maximumSize="150"4、调整数据源连接池的大小调整为100 至1005、调整语句高速缓存大小（根据实际情况调整）6、将监控的级别调整为“扩展”7、7、设置日志表示Out和Err日志都是1天生成一次，总共保留50天的日志。
不要启用服务日志，没用。
WAS性能调优
性能调优的基本步骤部署在WAS上的J2EE应用程序，其性能是由多个因素决定的。
例如网络、数据库、内存分配、WAS服务器的配置以及应用程序的设计。
对于一个标准的 J2EE 应用，一个请求到来时，往往需要经过多次转发：网络 > Web服务器Web容器 > EJB容器 > 数据库。
而每一次转发，都可能造成请求处理的瓶颈，使得应用程序整体性能下降。
如果我们把每一次转发的待处理资源都看成一个队列，如图3：待处理资源队列对于WAS调优，要记住的一个基本原则就是，使得在队列中等待的请求的数量最小化。
在实践中我们发现，为了达到这个目的，最有效的配置方式就是使得队列成为一个“漏斗”。
也就是说，越靠近客户端的队列，其容量越大，而后面的队列，其容量要略小于或等于前面的队列。
按照这个原则，调优的基本步骤如下：∙设置的是Web Server的最大并发用户：o这个设置是在conf/httpd.conf这个文件里面配置的。
在Unix系统中，对应的属性是MaxClient；在Windows系统中，对应的属性是ThreadsPerChild。
∙设置Web Container的最大、最小并发用户：o在管理控制台中点击应用程序服务器> server1 > 线程池>WebContainer，根据观察的性能情况和应用情况输入合适的最小、最大进程数。
o Web容器线程池要点就是：“通常，对于每个服务器CPU，5 至10 个线程将会提供最佳吞吐量”（现在的一个cpu可以用核来代替）。
比如你的PcServer有2块CPU，每块CPU都是4核，那么你一个Application Server可以设置的最小值和最大值可以分别为40、80。
但是一般考虑到能充分利用CPU和Memory，或者为不同的应用启用不同的application server，一台PcServer上并不仅有这么一个appserver，而且还有别的进程在占用着CPU，所以默认的10到50（Linux 系统上25 个）是一个比较合适的值，当然更准确的值需要通过性能测试来确定。
was工程师面试题
was工程师面试题为了准确满足题目要求，我将按照面试题的格式进行回答，以下是关于"WAS工程师面试题"的文章：WAS工程师面试题一、问题描述在进行WAS（WebSphere Application Server）工程师面试时，通常会涉及以下问题：1. 请介绍一下WAS的基本概念和特点。
2. 你有使用过的WAS的版本有哪些？各版本之间有什么差异？3. 请解释WAS的集群和负载均衡是如何工作的。
4. 你对WAS的高可用性有了解吗？请谈谈你的观点。
5. 请解释WAS的安装和配置过程。
6. 你有使用过的WAS相关工具有哪些？请描述一下它们的具体作用。
7. 在使用WAS时，你遇到过哪些常见问题？你是如何解决的？二、回答1. 关于WAS的基本概念和特点WAS是IBM的一款Java应用服务器，用于构建、部署和管理可扩展的企业应用程序。
它提供了一个运行环境，允许开发人员将Java EE （Enterprise Edition）应用程序部署到WAS服务器上。
WAS的特点包括良好的扩展性、高可靠性、高性能和可管理性。
2. 使用过的WAS的版本及差异我使用过WAS 8.5和WAS 9.0这两个常见的版本。
WAS 9.0相较于WAS 8.5具有以下一些差异和改进：- WAS 9.0支持Java EE 7规范，提供了更多的功能和API。
- WAS 9.0引入了Liberty Profile作为一种轻量级的WAS配置，方便了开发和部署过程。
- WAS 9.0增加了对微服务架构和云环境的支持。
- 在JDK版本上，WAS 9.0要求使用Java 8及以上版本。
3. 集群和负载均衡的工作原理在WAS中，集群和负载均衡可以提高应用程序的可用性和性能。
集群指通过多个WAS服务器共同处理应用程序请求，实现在不同服务器之间的负载均衡。
负载均衡是指将请求分发到集群中的各个成员服务器，从而使得每个服务器负载相对均衡，提高系统的整体性能。
WAS监控调优思路及工具汇总
WAS——侯泰浩一、WAS么IBM WAS称IBMWebSphere Applic ation Server，和Weblo gic一样， App Server）之一1.1术语WAS: r, 中间件 程序;IHS: Re r, WAS中 集群管 节点;g ent, WAS中 节点监听程序;JVM: n e, Java虚拟机;GC: Gabage Collec tion, 收1.2W AS ND集群 系结构WAS集群由一组 组成，每个 上部署了同样 程序。
通过集群可以实现可扩展性 更多客户，提高吞吐量），负载均衡 平衡负载资源，使资源得以有效利 ），高可 性 提供故障恢复和补偿机制，在关键性业中提供容错功能）。
下图 ND分布式环境 系结构，包括单元、节点、 等 。
WAS群集 了实现集中管 和负载均衡同可以实现故障转移，一个2节点群集 如下：其中，Deploy mentM anage r通过每个节点上 N o deAgent成对AppS erver、 布以 和 ，实现集中管。
如 多个I HS， 实现负载均衡和分 ，可以使 负载分功能。
每个节点上A ppSe rver可以 多个。
二、WAS参数三、WAS 调优思路3.1 思路部署在S上 程序，其性能 由多个因素决定 。
例如网络、数据库、内存分 、WAS以 程序设计。
对于一个标准 J2EE，一个请求到来 ，往往需要经过多次转 ：网络 > Web Web容 > EJB容 > 数据库。
而每一次转，都可能造成请求处 瓶颈，使得 程序 性能下降。
如 我们把每一次转 待处 资源都看成一个队列，如下图：待处 资源队列对于调优，要记住 一个 原则就 ，使得在队列中等待 请求 数量最小化。
在实践中我们 现， 了达到这个目 ，最有效 方式就 使得队列成 一个“漏斗”。
中间件（WAS、WMQ）运维9个常见难点解析
中间件（WAS、WMQ）运维9个常见难点解析包括WAS、WMQ在安装、巡检、监控、优化过程中的常见难点。
安装1、was 负载均衡的机制的粘连性，was负载均衡异常？有⼀个case系统，部署在was集群环境，应⽤是集群环境，有的时候当⼀个节点异常的时，客户端访问该系统就会抛出异常，按正常情况，该会话应该不会断或者断了再连接⼀次就会到另⼀个节点，但是好多时候不管客户端如何连接，都不⾏，该正常的客户端⼀直是正常的，不正常重启机器也不正常。
当然其他新连接的节点也没啥问题，直到重启了故障节点的应⽤，原先不能正常访问的客户端才正常，就算当时清除浏览器缓存也不好使，哪位有这⽅⾯的经验可以多谈谈。
答：1，这是故障转移，was有内部机制可以做到1）内存到内存复制技术可以，缺点，因每台服务器共享session，所以占⽤内存⽐较⼤（如果server很少，可以考虑使⽤）。
2）存储到数据苦或者其他地⽅也可以实现。
推荐使⽤，但是实现较复杂2、如何⼤批量的完成WAS的安装和部署？有哪些⼯具和⽅法？如：⼏百台或上千台WAS服务器的安装和部署答：1，wsadmin 去写脚本是个好办法，配合虚拟化去做。
2，还有上千台的已经不适合去⽤商业软件了，建议去考虑下开源的软件，或者云平台了。
3、was安装低版本升级需要注意哪些⽅⾯？需要重新缴费吗？答：1，was 6 官⽅已经不再提供⽀持，除⾮额外买服务。
2，从2018年4⽉开始，将不再⽀持Java SE 6 与 WebSphere Application Server 配合使⽤，建议更新为 Java SE 7 或 83，WAS V7.0.x 和 V8.0.x 和 Portal Server V8.0.x 于 April 30, 2018 End Of Service低版本注意事项：1，规划好磁盘空间，内存和CPU2，规划好安装⽬录，尽量做到安装⽬录统⼀，规范。
3，了解好业务量⼤⼩，并发等等，⽅便你设计你的was部署⽅案。
WAS性能调优
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=true4.设置数据库的连接池属性：JDBC 提供者>数据库JDBC驱动名称> 数据源> 数据源名称> 连接池，根据观察的性能情况和应用情况输入合适的最小、最大连接数。
最小值为：20，最大值为：50。
分别更改uissdbpool、uissdbpoolgw连接池的属性，如下图所示：5.ORB参数调用方式的性能调优：应用程序服务器> server1 > ORB 服务>选中按引用传递。
如下图所示；6.修改uiss-gw的类装入器，如下图7.日志记录配将JVM日志文什件大小改为2MB，历史日志文件大小改为10。
- 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．语句高速缓存大小。