websphere优化
WebSphere7部署、调试和调优
WebSphere 7.0 使用作者：李琳目录1 部署应用 (2)1.1 数据源配置 (2)1.1.1 配置JDBC提供程序 (2)1.1.2 配置JNDI数据源 (2)1.1.3 安全配置 (3)1.2 部署应用程序 (3)1.3 配置热部署（动态加载） (4)1.3.1 更新程序的动态加载 (4)1.3.2 服务器加载策略 (4)1.3.3 JSP加载策略 (4)2 在WebSphere7上调试应用程序 (5)2.1 设置Websphere为调试状态 (5)2.2 部署应用程序 (5)2.3 MyEclipse/Eclipse配置 (5)2.3.1 配置远程跟踪 (5)2.3.2 配置部署目录 (6)2.3.3 调试 (7)3 性能监视 (8)3.1 PMI设置 (8)3.2 TPV监控 (8)4 JVM的参数调节和监控 (9)4.1 JVM的参数调节 (9)4.2 JVM的运行监控 (10)5 线程池 (10)5.1 IBM HTTP Server (10)5.2 Web容器线程池 (11)5.2.1 Web容器线程池参数 (11)5.2.2 Web容器线程池监控 (11)5.3 数据库连接池的参数调节和监控 (11)5.3.1 数据库连接池的参数调节 (11)5.3.2 数据库连接池的运行监控 (12)6 设置Servlet高速缓存 (12)7 Web响应监控 (13)1部署应用1.1数据源配置数据源配置分为三步：1)配置JDBC提供程序2)配置JNDI数据源3)安全配置1.1.1配置JDBC提供程序配置JDBC提供程序，需要相应的JDBC驱动软件包。
如Oracle是ojdbc6.jar。
1)进入资源/JDBC/JDBC提供程序。
2)选择作用域3)选择新建一个提供程序。
4)选择正确的数据库类型Oracle。
5)选择提供程序类型为Oracle JDBC Driver。
6)选择实现类型为连接池数据源。
WebSphere配置文档(性能参数调优)
WebShpere经常使用配置一、W ebSphere中JVM内存配置第一进入WebShpere治理操纵台，然后点击效劳器选项里面的应用程序效劳器进入下面界面：点击server1进入下面界面：点击Java和进程治理里面的进程概念进入下面界面：点击Java虚拟机进入下面界面：在那个页面的下方有初始堆大小和最大堆大小两个参数是设置JVM内存大小，必然要把两个参数设置的一样大。
如图：二、W ebSphere中JVM内存监控利用说明进入WebSphere操纵台，点击监控和调整中性能查看器中的当前活动，如以下图所示：点击server1进入以下图界面：点击性能模块，选择里面的JVM运行中，会谈出询问你是不是安装SVG查看器，点击确信。
如以下图：确信后会显现以下图：用下拉条拖动到以下图所示的地址点击win98-XP下载文件，下载完毕后安装，然后点击查看模块按钮，就会显现以下图：如此就能够够监控内存的转变了。
三、关于WebContainer线程池大小进行调整为了知足多个客户端造成的大的客户端并发数量，关于WebContainer的线程池大小进行调整。
此线程池大小代表了WebSphere所能够保护的最大及最小同时响应并发客户端请求的线程数。
建议将WebContainer最大和最小大小都设为120。
不要选择具体调整方式为： > > > WebContainer 界面中调整。
(1)(2)(3)(4)四、W ebSphere的数据源配置第一进入WebShpere操纵台，点击环境选项下的WebShpere变量，如下图：在本页下方有个参数，如下图：点击进入后在值这一项中输入ORACLE_ JDBC驱动的途径, 如下图：点击确信按钮并保留配置。
然后成立连接池，点击左面导航栏里面的资源中的JDBC提供程序，如下图：在图的下方，点击新建按钮，进入添加页面，如下图：按实际情形进行选择，如下图：选择好后点击下一步，如下图：在本页下方有一个类途径，按真实情形填写，如下图：点击确信按钮并保留配置，就添加成功了，如下图：点击Oracle JDBC Driver后进入修改界面，如下图：：在页面的右边，有个数据源选项，如下图：：点击进入，如下图：：点击新建按钮后，进入新建页面，如下图：：然后把JNDI名称改成和应用的数据源的名称一样，把“将此数据源用于容器治理的持久化性（CMP）”那个选项去除掉，如下图：：在那个页面的下方有一个Oracle数据源属性，把里面的URL依如实际情形配置一下，如下图：然后点击确认并保留配置，就添加成功了，如下图：：然后点击Oracle JDBC Driver DataSource，进入修改界面，如下图：：在页面的右面的相关项里面有个，点击进入，如下图：点击新建按钮，进入新建页面，如下图：依如实际情形填写，如下图：点击确信并保留，就添加成功了，如下图：然后退到Oracle JDBC Driver DataSource页面，如下图：在图的下方有个组件治理的认证别名，把你适才添加的认证选择上，如下图：然后点击确信并保留，如此就配置数据连接池就配置好了，能够点击页面上面的测试连接进行测试。
websphere集群优化
WebSphere应用程序服务器集群的部署和调优核心提示：本文通过对WebSphere集群实施过程的描述以及部分参数的调整，阐释了WebSphere应用程序服务器的系统架构，及其参数调整。
文中所部署的系统，上线后至本文完成，保持了7*24小时无故障运行，根据实际测试及用户反馈系统性能有了成倍的提高，充分显示了集群的高可用和扩展性。
随着java技术的广泛应用，中间件平台逐渐成为应用系统的重要组成部分，进而对中间件系统的高可用和整体性能提出了很高的要求。
本文主要讨论新疆电信XX平台部署使用WebSphere应用程序服务器集群及其调优的经验。
<BR>一、业务挑战XX平台，应用程序A、B、C部署在单机环境，操作系统为Linux，中间件为WebSphere 6.1应用程序服务器，随着业务开展，用户数不断增加，逐渐出现了页面打开缓慢，中间件频繁挂起的问题，影响用户使用业务，有必要进行软硬件升级并保证系统至少能达到99%的可用性。
二、系统部署方案的选择方案一是主机数量为3台，分别部署应用程序A、B、C到三台主机上，每台主机承载一个应用程序，一台主机发生故障不影响其他业务，但发生故障主机所承载业务失效。
不产生冗余，服务器MTBF60000小时无故障。
方案二是主机数量为4台，应用程序A、B、C部署到三台主机组成的WebSphere集群，一台主机发生故障不影响任何业务，出现故障后脱离集群，恢复后重新加入集群即可，另增加一台服务器作为部署管理器和HTTP服务器。
有冗余产生，服务器MTBF180000小时无故障。
对比以上方案，方案2采用集群环境后，系统的高可用性有明显提高，且部署使用了独立的Http服务器，隐蔽了系统的逻辑架构，相比WebSphere自带的http服务，IHS服务器更加健壮、安全。
<BR>三、规划系统架构主机iisp.dm 安装部署管理器（概要文件类型为deployment manager）、IHS（IBM HTTPServer）；主机iisp.cust、iisp.rpt、iisp.ap分别安装应用程序服务器（概要文件类型为应用程序服务器）。
WebSphere参数调优
(1)选定应用程序服务器的 JVM 堆是否与同一机器上的其它应用程序服务器 JVM 堆共享物理内存。例如，您是以本地方式还是以远程方式运行监视器？
(2)指定 JVM 堆驻留在物理内存中并防止交换到磁盘。
(3)将起始 JVM 堆大小设置为最大 JVM 堆大小的 1/4。
(4)如果机器上只有一个应用程序服务器，则将最大 JVM 堆大小设置为以下值：
5、应用程序服务器 > server1 >进程定义 >Java 虚拟机->初始堆大小
Java 虚拟机（JVM）堆大小设置将影响 Java 对象的无用数据收集。堆设置过大，会占用过多的内存，使内存资源耗尽，从而会频繁的进行I/O操作来使用虚拟内存。堆设置过小，会使得对象可分配空间变小，从而会频繁的使用垃圾收集机制来释放内存空间，而每次垃圾收集，都会耗ueueConnectionFactory.createQueueConnection() 方法将等待“in use”连接变为可用。对于这种情况，该方法等待连接的最大等待时间是由连接池的连接超时属性指定的
9、资源 -> WebSphere JMS 提供程序->WebSphere 队列连接工厂->点击所创建的工厂->配置->会话池
二、具体参数设置
省略！
4、应用程序服务器 > server1 >Web 容器->定制属性
MaxKeepAliveConnections：表示系统同时保存的最大连接个数，超过这一个数时最近最少被使用的连接将被关闭, 整型，缺省值是：300；
MaxKeepAliveRequests：客户端请求被保持到一个请求队列，此属性用于决定请求队列可保持的最大客户端请求数，整型，缺省值是：100；
WebsphereJVM堆分析与优化
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上传过程中，还要进行分析，封装，持久化等操作）。
websphere业务系统优化与IT整合
WebSphere: 业务系统优化与IT整合解决方案手册- 1 -业务系统化随着中国市场的迅猛发展和日益国际化，所有传统行业都在进行进一步细分，跨部门、跨企业合作正成为大势所趋。
从大中型国有企业、银行、电信运营商，到政府部门、医疗、教育、保险再到制造、零售、电子、航空航天，各个行业均面临着来自客户和合作伙伴不断增长变化的需求以及来自竞争对手的挑战压力。
在这样的情况下，各个企事业单位必须对现有的业务进行系统化、标准化、流程化，适应日益变化的市场需求，优化运营，提升市场竞争能力。
作为一种以帮助企业实现业务系统化为目标的解决方案框架，IBM SOA面向服务架构帮助企业对外实现了业务流程整合，增加了业务灵活性，使企业能够更加快捷、轻松、经济地实现业务目标; 对内消除了团队之间、部门之间、公司之间的壁垒，确保组织内部报告的一致性。
行业最佳运营快速实施解决方案随着国际市场合作、国际经济一体化成为市场发展的趋势时，众多国内银行、保险、电信、医疗等大型企业和政府部门在行业信息化道路上缺少可供参考的范本，由此出现了一系列部署问题: 投入大量资金进行探索，却发现最终无法满足业务目标; 缺乏前瞻性的全面规划，信息畅通无法保障，服务架构缺乏弹性，最终导致维护成本的持续攀高，收效比理想预期相距甚远。
为了帮助客户避免走弯路，IBM将其在全球各大行业实施的最佳成功客户和解决方案进行了标准化和模块化，可直接将复制的服务组件模版引入国内市场，在标准的行业解决方案平台上快速实现行业最佳解决方案，快速实现价值。
- 2 -企业业务流程整合平台随着企业内部部门分划以及跨部门合作的发展，业务流程进一步细分，企业将出现管理复杂、监控困难、信息获取不及时等弊病，给业务的进一步发展壮大带来很大阻碍。
如何进行业务流程整合? 这已经不仅仅是一个技术问题，更是一个管理上的问题，关系到企业的实际经济利益。
企业流程复杂不便于企业实时监控，以往流程简化又阻碍新流程开发，企业在流程管理、整合方面进退两难。
WebSphere优化
WebSphere7 优化一、配置JTA时间展开主控制台左边的菜单树“服务器→服务器类型→WebSphere Application Server”，点击进入如下图所示页面：点击“server1”，进入如下图所示页面：展开右侧“容器设置→容器服务”，进入如下图所示页面：点击“事务服务”，进入如下图所示页面：按照如上图所示页面参数设置，最后点击【保存】，即可完成JTA时间的配置工作。
二、配置JDBC时间展开主控制台左边的菜单树“资源→JDBC→JDBC提供程序”，点击进入如下图所示页面：点击蓝色的“DB2 Universal JDBC Driver Provider”,进入如下图所示页面：点击右侧的“数据源”，进入如下图所示页面：然后点击“topicms3ds”，进入如下图所示页面：点击右侧的“连接池属性”，进入如下图所示页面：按照上图所示参数进行设置即可完成JDBC连接时间的配置工作。
（最大连接数仅适用河南，其它地市可根据实际was节点进行调整，如果节点比较少，可增加最大连接数）三、配置JDBC连接数据库的隔离级别展开主控制台左边的菜单树“资源→JDBC→数据源”，点击进入如下图所示页面：然后点击“topicms3ds”，进入如下图所示页面：点击“定制属性”进入如下图所示界面：打开数据源的定制属性，按照上图所示把值改为2即可完成JDBC连接数据库的隔离级别的配置工作。
四、增加定制属性useRRASetEquals?展开主控制台左边的菜单树“资源→JDBC→数据源”，点击进入如下图所示页面：然后点击“topicms3ds”，进入如下图所示页面：点击“定制属性”进入如下图所示界面：点击新建创建如下图所示属性：五、配置java虚拟机点击“Server1”，点击java和进程管理，点击“进程定义”——“java 虚拟机”按照上图所示参数设置后，点击保存即可（此设置要依据服务器配置而定）。
六、配置JVM 日志展开控制台左边的树，进入“故障诊断→日志和跟踪进入如下图所示页面：点击server1进入如下图所示页面：点击JVM 日志进入如下图所示页面：如上图参数所示进行设置后保存即可。
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 堆空间里会存放各式各样的对象，有的是静态类型，有的是私有类型等等，而这些对 象都是通过垃圾收集器进行管理的。
利用负载均衡技术对WEBSPhere应用做优化
对于内部征管系统设计的解决方案应该提供无限的可扩展性和投资保护，对于用户而言可以灵活的扩大服务器群和服务器的数量，确保当前系统网络方案的所有投资都可以在未来得到最大限度的利用。
对于WebSphere系统平台的各个处理架构中，不可能只采用一台服务器解决所 有用户的访问请求。现在较为流行的网络结构配置为多台Web服务器通过可做应用负载均衡的负载均衡设备平均分配用户请求，以对最终用户提供服务。
2、WebSphere系统平台的可靠性提高:
随着电信的网路建设的不断扩容，系统用户的不断激增，如果只有单台的web服务器出现宕机或web服务停止等故障，容易造成服务器节点的单点故障。通过具有负载均衡能力的设备的使用，通过web服务器组的方式，能够保证和实现系统的冗余，同时通过两台负载均衡设备的使用，能够保证当一台服务器负载均衡设备出现问题，后台的web服务仍然能够通过另一台负载均衡设备正常工作，当正常情况时两台负载均衡设备同时工作，最大程度的保证了链路的畅通和用户投资，实现了365X24的不间断服务保障。
4、WebSphere系统平台的管理性提高：
对于Web应用来说，对服务器的维护经常需要对服务或者服务器进行重启工作，所以经常涉及到服务器的下线和上线的问题。系统应当有良好的机制保证服务器的维护工作不会对用户产生影响。这点通常是通过负载均衡设备来实现。
当服务器要重新投入到工作中时，或有新的服务器加入时，在负载均衡产品对该服务器设置为Warmup状态，负载均衡产品会在一定时间内从较少用户请求Session到最大用户请求分发给该服务器，保障系统的安全稳定运行。
利用负载均衡技术对WEBSPhere应用做优化
WebSphere的性能优化
五、隔离CMS系统，服务器优化从前面的介绍，大家应该记得，我们开始是固定CMS，分离其它应用，但遭遇失败。
现在是反过来，干脆把CMS系统赶出WAS平台。
说实话，项目经理做这个决定，我认为已经是鼓出很大勇气了。
当时我们想在一个备用AIX机上安装CMS产品测试，但最后还是没有做成：CMS这类文章发布系统很难安装，也不好测试，又没有liscence，而且还有一堆准备工作。
绝对没有著名的openCMS安装那么简单，当然功能远远比它复杂。
而且，我们当时也低估了后来的工作，总觉得问题好解决。
在很遥远的06年中期，CMS厂商在客户那边一台AIX的Tomcat上部署了一套CMS产品。
但当时客户执意要求将其跑在WAS上，也就是现在的情况。
最开始，客户还要求我们必须用WAS的集群(我们买的就是WAS 的ND版)，无奈该CMS不支持。
要是集群，又是死伤一遍。
其实，现在想想，我们当时太被动，CMS这种东西，就供公司的几十个编辑用，一个普通Tomcat就完全够用。
而且，把它和面向公网的Internet应用混在一起，完全没有必要。
也许，被动是因为我的实力造成的。
我们决定背水一战时，已经做过周密的计划：某年某月某日晚上8:00......CMS产品负责人现场切换xx（我）负责WAS相关参数调整yy负责AIX参数。
zz负责应用的测试…..总之，该行动涉及到客户方、产品提供商、公司高层、项目组。
每个人都密切关注，不下20人。
每个人都守在电脑前，随时听候调遣，当天晚上，我们都没有准备回家睡觉，大家齐心协力。
真没想到，整个式切换工作，一个小时就顺利完成！第二天，客户编辑打开浏览器，她们一定想不到昨晚大家准备经历一场厮杀….系统持续平稳地运行了一周，然后是漫长的五一，我回湖北黄冈老家休息了八天。
回来时，一切依旧。
当天晚上，我们这边主要做了两项工作：1、JVM的Heap参数，共五个。
2、AIX的IO、Paging Space等共六个。
当然还有其他人的工作，譬如测试、监控。