WAS 常见问题及解答(六)

性能

1. WAS 的重要优化参数有哪些？
2. 性能调优的基本步骤是怎样的？
3. 如何合理的使用缓存机制？
4. WAS 性能差的几种表现和解决方法？
5. 我应该怎样去判断应用程序服务器的性能是否满足要求，都有哪些指标？
6. 系统中产生大对象对性能的影响怎洋？
7. 如何解决内存泄漏问题？
8. 如何解决系统宕机问题？
9. WAS 运行在什么平台上性能最好？是Intel、UNIX、pSeries/AIX、Sun/Solaris，还是 zSeries/zOS？
10. 运行应用程序所需 CPU 的最小数量和最大数量是多少？

 

1. WAS 的重要优化参数有哪些？

答：
在着手进行应用程序服务器的优化之前，首先进行应用程序和操作系统的优化是一个更好的选择。尤其是应用程序的优化，通过对应用程序中影响性能的部分进行重新的设计和调整，往往能够带来比单纯的参数调优更为巨大的性能提升。对于一般的J2EE应用程序而言，WAS中最重要的优化参数包括针对JVM、Web Container和Data Source等的。

· JVM
Heapsize（-Xms和-Xmx）：heapsize的大小依赖于系统平台和具体的应用等多种因素。最大heapsize需要小于机器的物理内存，一般来说，设置最大heapsize为512m是一个常见的起点。同时，在生产环境中，最好将Xms设置为小于Xmx的值。

GC（Garbage Collection）：一般来说，良好的GC状态需要保证相邻两次垃圾回收的平均间隔时间应当是单次垃圾回收所需时间的至少5-6倍。GC的调优是通过在模拟压力的情况下不断调整最大最小heapsize来实现的。

Heap Fragmentation：heap碎片的问题在JVM中存在大对象的情况下尤为突出。减少碎片的方法包括调整pCluster（-Xp）和kCluster（-Xk）参数。更多的JVM调优参数内容，参考JDK diagnostic Guide。

以及WAS V6.1信息中心的相关内容：
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunejvm_v61.html

· Web Container
对Web Container的调优是通过对Web Container传输链中各个通道（TCP、HTTP、WebContainer）的参数调整进行的。这些参数包括诸如ThreadPool的最大最小值，buffer大小，timeout时间的大小，keep-alive的值等等。各个参数的含义及具体调整方法参见WAS V6.1信息中心：
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunechain.html

· Data Source
对Data Source的优化包括两个方面。一是JDBC Driver的选取，尽可能应使用Type 4的JDBC driver，这种driver是纯java的，适用于client/server模式，并提供比type2和legacy/CLI的driver更好的性能。另一方面是Database连接池的参数设置，主要包括最大和最小连接以及timeout的设置。具体的设置于应用程序的特性和并发用户量相关，一般来说，可设置最小连接为1且最大连接为30，作为一个继续调优的起点。除了JVM，Web Container和Data Source之外，WAS的性能调优还包括很多其他方面的内容，如JMS、EJB、Session、Dynamic Cache等等。关于性能优化的更多内容，可参见WAS V6.1信息中心：
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/welc6toptuning.html

另外，WAS 提供了若干工具，可以用于帮助衡量其性能。WAS 中免费提供的 Tivoli® Performance Viewer（TPV）允许客户对关键资源（如 JVM、Web 容器和 EJB 容器以及远程连接池）进行监视。这款工具使用非常方便，可以用于确定应用程序使用可用资源的方式，还可以提供针对行为不正常的远程资源的信息。例如，如果数据库连接池显示为了获得连接进行了多次尝试，则可能表示远程数据过载，或者需要优化数据库，或者需要向不够大的池中添加更多的连接。与此类似， WAS还提供了 Runtime Performance Advisor 功能，可以就系统中的潜在优化问题向管理员提供反馈。

WAS Information Center （http://www.ibm.com/software/webservers/appserv/was/library/）包含了一个优化参数列表，还包括一个优化参数“热点列表”，其中描述最常用的经过调整的参数。这是一份不错的参考资料，有助于您了解在该产品内调整内存和资源的基本知识。其他的不错的参考资料包括 IBM® 红皮书，如 WebSphere Application Server V6 Scalability and Performance Handbook》。

 

2. 性能调优的基本步骤是怎样的？

答：
部署在WAS上的J2EE应用程序，其性能是由多个因素决定的。例如网络、数据库、内存分配、WAS服务器的配置以及应用程序的设计。对于一个标准的J2EE应用，一个请求到来时，往往需要经过多次转发：网络 > Web服务器Web容器 > EJB容器 > 数据库。而每一次转发，都可能造成请求处理的瓶颈，使得应用程序整体性能下降。如果我们把每一次转发的待处理资源都看成一个队列，如图3：
图3 待处理资源队列



对于WAS调优，要记住的一个基本原则就是，使得在队列中等待的请求的数量最小化。在实践中我们发现，为了达到这个目的，最有效的配置方式就是使得队列成为一个“漏斗”。也就是说，越靠近客户端的队列，其容量越大，而后面的队列，其容量要略小于或等于前面的队列。按照这个原则，调优的基本步骤如下：

· 设置的是Web Server的最大并发用户：

o 这个设置是在conf/httpd.conf这个文件里面配置的。在Unix系统中，对应的属性是MaxClient；在Windows系统中，对应的属性是ThreadsPerChild。

· 设置Web Container的最大、最小并发用户：

o 在管理控制台中点击应用程序服务器 > server1 > 线程池 >WebContainer，根据观察的性能情况和应用情况输入合适的最小、最大进程数。

· 对象请求代理（ORB）的线程池大小：

o 在管理控制台中点击应用程序服务器 > server1 > ORB 服务 > 线程池，根据观察的性能情况和应用情况输入合适的最小、最大进程数。

· 设置数据库的连接池属性：

o JDBC 提供者 >数据库JDBC驱动名称 > 数据源 > 数据源名称> 连接池，根据观察的性能情况和应用情况输入合适的最小、最大连接数。

· JVM堆参数设置的性能调优：

o 应用程序服务器 > server1 > 进程定义 > Java 虚拟机，根据硬件物理内存和应用情况输入合适的初始堆大小、最大堆大小。

· ORB参数调用方式的性能调优：

o 应用程序服务器 > server1 > ORB 服务>选中按引用传递。

· 关闭动态加载开关：

o 企业应用程序 > 应用名称 > 关闭启动类重新装入开关。

o 关闭会话序列化，应用程序服务器 > server1 > 会话管理 > 分布式环境设置 > 分布式会话选择无即可。

这个调优的步骤只是涉及了利用WAS服务器参数的调整来优化应用程序的性能，实际上性能的好坏很大部分是取决于应用的设计。好的性能源自好的代码设计。一般说来，性能调优大概可以提高10％－40％效率，而糟糕的代码设计却会使得性能几倍的下降。

 

3. 如何合理的使用缓存机制？

答：
WAS 中可以用很多种手段实现缓存。其中最常见的一种，就是在应用中使用开发的手段缓存一些中间结果。但这种缓存是一把双刃剑。用好了可以很好地提高性能，如果掌握不好，使用过度了，则会对底层 JVM 的 Heap 造成很大的威胁。一般 JVM Heap 出现OutOfMemery（内存泄漏）的问题，都是应用中直接或者间接的缓存技术滥用的后果。所以缓存技术拿捏得当非常重要，也比较不容易。 下面主要谈谈 WAS 产品本身提供的缓存功能。

WAS 提供动态缓存机制，可以对 Web 命令、 Servlet 输出和 JavaServer Pages（JSP）文件进行高速缓存，从而提高应用程序的性能。动态高速缓存服务在应用服务器 JVM 中工作，拦截对可高速缓存对象的调用。例如，它通过 servlet 的 service 方法或命令执行方法拦截调用，以及将对象的输出存储到高速缓存，或者对来自于动态高速缓存的对象内容进行处理。

在 WAS 中可以通过配置实现常用的高速缓存对象、功能和模块有：

· Servlet 高速缓存

· Portlet 片段高速缓存

· Edge Side Include 高速缓存

· Web 命令高速缓存

· Web Service 高速缓存

· Web Service 客户机高速缓存

关于WAS的缓存功能，详细信息请参见：
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/welc6tech_dyn.html


对于WAS中的缓存机制，和应用开发中的缓存类似，也要掌握好缓存的“度”，避免滥用，即题目中问的“如何合理的使用”？原则有如下几点：

1. 不是缓存用得越多越好。只要是 WAS 中提供了缓存机制的环节，统统都用上。这是错误的。

对于这一原则，有一个非常简单的方法可以确定是否采用缓存，采用哪些缓存技术：如果实现缓存本身相对于您的拓扑结构或者您所掌握的技术来说，显得非常的复杂，那么完全可以不用。举例来说，虽然 Edge Component 中提供了很好的缓存技术，但您的生产环境中，原本就没有考虑 Edge Component，现在为了缓存而缓存，非要把 Edge Component 加进去，使得拓扑偏离了原先的设计，变得更复杂化，就很没有必要了。

2. 确认您想缓存的对象是否真的需要缓存。这一点事先比较难以判断。因为生产环境真实的使用情况是千变万化的。最佳的方法就是在真实环境中对缓存进行监控，查看被缓存对象的命中率。如果某些缓存环节利用率极低，或者某个对象命中缓存的概率非常小，则完全可以取消这样的缓存。对于利用率高的缓存，可以在内存使用比较平稳的前提下适当增大力度。 关于缓存监控的方法，请参考WAS的InfoCenter，利用高速缓存监视器器对动态高速缓存进行适当调整。网址如下：
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/cdyn_cachemonitor.html

 

4. WAS 性能差的几种表现和解决方法？

答：
系统性能差一般的情况下有以下表现：

1. CPU使用不高， 用户感觉交易响应时间很长。

2. CPU使用很高，用户感觉交易响应时间很长。对于第一种情况，可以断定是由于系统的某一小部分造成了瓶颈，导致了所有的请求都在等待。简单举例来说，线程池的数量开的太小，导致所有的请求都在排队等待进入线程池，因为没有可用的线程使用，所以这个交易请求一直在排队，导致交易响应时间很长。如果数据库连接池开的太小，也会有同样的表现。

对于第二种情况，比较复杂。可能的根源之一是硬件资源不够。根源之二是应用系统中产生了多个大对象。根源之三是程序算法有问题。解决思路如下：用性能分析器，如RAD或JProfiler, 对运行环境进行分析，分析哪个类甚至于哪个函数消耗了这么多的CPU，并找到相应的解决方案。

有关 WebSphere 性能的更多资源，请参阅 developerWorks 中国站点的文章《专家访谈：Stacy Joines 和 Gary Hunt 谈 WebSphere 性能》。

 

5. 我应该怎样去判断应用程序服务器的性能是否满足要求，都有哪些指标？

答：
在遇到性能问题时，尝试使用Tivoli Performance Viewer，并一一察看如下最重要的10个监视项目：

· Servlets 和Enterprise JavaBeans

1. 平均响应时间

2. 请求数（事务）

3. 活的HTTP Session数

· 线程池

4. web 服务器线程

5. web容器和EJB容器线程池

· 数据源

6. 数据源连接池大小

· Java 虚拟机

7. JVM内存，垃圾收集统计

· Web，应用程序，和数据库服务器上的系统资源

8. CPU利用率

9. 磁盘和网络I/O

10. Paging活动

同时，可配合使用Tivoli Performance Advisor，它们可帮助您调整您的系统，对设置不足给出建议。

有关 WebSphere 调优工具的更多资源，请访问 developerWorks 中国站点文章和教程：

· 《Ruth Willenborg 关于性能工具的提示：选择 WebSphere 性能工具》

· 《性能监测，诊断和优化》

· 《WebSphere应用服务器内存泄漏探测与诊断工具选择最佳实践》

 

6. 系统中产生大对象对性能的影响怎样？

答：
我们经常遇到如下的例子，如果一个报表系统运行在WAS里，用户经常抱怨系统的响应时间太长，反应太慢的情况。问题的根本原因是报表系统会产生一些大对象，而这个大对象的数值如果超过2M, JVM一定要在有限的空间里为对象找到连续的空间。如果JVM为这个对象找不到连续的空间，就会对整个内存空间进行整理，如果大对象比较多，由于JVM对内存空间的频繁整理会对系统的性能有着急剧的影响。造成系统的响应时间非常慢，所以应用程序应尽量避免产生大对象，或者用一个链表的结构来表达大对象，本质上把一个大对象拆成几个可以联接的小对象，让JVM可以很容易的分配内存空间。

 

7. 如何解决内存泄漏问题？

答：
由于系统的复杂性，不可能通过程序来确定内存泄漏的根源，因为内存泄漏的根源可以是来源于自己写的应用，开放源码的组件，JDBC组件，甚至可以怀疑WAS本身也能造成内存泄漏。但也有一个解决思路，就是在应用程序已经发生内存泄漏时，把当前的内存中的所有对象做一个快照。从这些所有的对象中做分析，找到怀疑的地方，并写测试案例来进行验证。正常的情况下，要在不同的时间点上做几个内存快照。IBM提供了几个分析工具，MemDumpDiag，HeapRoots，利用这些工具可以对系统内存的使用进行辅助分析。另外一个有效的办法是WebSphere还可以把GC（Garbage Collection）的log打印到SystemErr.log上，通过分析GC的日志可以得到很多的直观上的对内存的使用，如内存的随着时间的变化情况等。IBM 提供的工具是“IBM Pattern Modeling and Analysis Tool for Java Garbage Collector”，这个工具可以对GC进行分析统计。 有关在 WAS 中解决内存泄漏的更多资源，请参阅 developerWorks 中国站点的文章：

· 《WebSphere Application Server 中的内存泄漏检测与分析：第 1 部分：内存泄漏概述》

· 《WebSphere Application Server 中的内存泄漏检测与分析：第 2 部分：用于泄漏检测与分析的工具和功能》

· 《WebSphere应用服务器内存泄漏探测与诊断工具选择最佳实践》

 

8. 如何解决系统宕机问题？

答：
WAS系统不会轻易的宕机，因为WAS 容器能对它的内存和线程进行控制，大部分的情况是由于内存问题造成系统宕机，如果这种情况发生，WAS缺省的情况下会产生JavaCore文件和Heap Dump文件，需要对这两个文件进行分析。另外的能导致系统宕机的情况是WAS调用外部程序，如对C/C++程序的调用，这些JNI调用也有可能造成系统宕机，如遇这种情况，从WAS出发找不到问题的根源的，需要从外部程序（C/C++）进行查找问题的根源。

 

9. WAS 运行在什么平台上性能最好？是Intel、UNIX、pSeries/AIX、Sun/Solaris，还是 zSeries/zOS？

答：
这里有几个关于WAS在不同平台上的性能总结。当然您要清楚，在选择WAS运行的平台时需要考虑众多的因素，不仅是性能。

· WAS 几乎完全是一个Java应用程序（除了有一小部分平台相关的代码），基础代码对任何平台都是一样的（除了zSerires/zOS）。因此，性能的任何差别主要依赖底层硬件、操作系统和JVM的性能。

· WebSphere的性能主要依赖于JVM的性能。JVM是本地代码，由IBM或者操作系统提供者提供。IBM开发的JVM具有非常好的性能和可扩展性。pSeries平台上WebSphere 正是使用IBM的JVM，它有着相当突出的性能和可扩展性。关于JVM性能基准的更多资源，请访问以下站点：http://www.spec.org。

· WAS代码对SMP（对称多处理，Symmetrical Multi-Processing）处理器的可量测性做了优化，通常的规则是：基于UNIX，iSeries/OS400和zSeries/zOS的SMP 扩展结果比基于Intel的更强。而在UNIX操作系统中，AIX有最高的SMP扩展特性。

 

⒑ 问题：运行应用程序所需 CPU 的最小数量和最大数量是多少？

答：
现代操作系统通常在进程调度方面表现得很出色，从而最大程度减少了上下文切换。上下文切换是在操作系统调度程序用另一个进程替换 CPU 上正在运行的一个进程时发生的，而且是各种因素作用的结果，例如作业（或进程）优先级、是否等待其他资源（如 I/O）、进程是否将用完所有分配给它的 CPU 周期（时间片）等。但是，在执行上下文切换时，虽然现代操作系统表现很“出色”，却并非“完美无缺”，因为进程在每次进行上下文切换时，它都将停止运行——这将导致吞吐量出现延迟（和性能下降）。如果我们确实不希望出现任何上下文切换，则系统中的 CPU 数要大于该系统中运行的进程数。而这完全不切合实际，因为在一个系统中安装这么多的 CPU，几乎没有任何组织能负担得起，而且也没有必要，因为大多数进程都不要求对 CPU 进行持续访问。因此，我们应该转而研究一些最重要的进程，这些进程在本文中即指系统中应用服务器运行时所使用的JVM。

起初，我们假定每个应用服务器 JVM 应该采用至少一个 CPU；这样就有可能最大程度减少发生上下文切换的次数——至少就将用完时间片这一因素而言是如此（如上所述，导致上下文切换还有其他因素）。但是除非您在运行所有服务器时占用了全部 CPU 资源，否则，在应用程序请求（该请求随即被转换为对操作系统资源的请求）到达应用服务器时，很可能存在可用的 CPU 周期。因此，运行的应用服务器数量有可能大于 CPU 数量。

不过，如果要获得可以在环境中运行的服务器的准确数量，则还得采用视情况而定之类的方式进行回答。这是因为该数量实际上取决于负荷、应用程序、吞吐量和响应时间要求等，确定这个准确数量的唯一方法是在环境中运行测试。

在开发环境（其中负荷可能是每个应用服务器只有一个用户）中，您会期望每个 CPU 运行的应用服务器实例数量是生产环境中的应用服务器数量的数倍，这种想法很合理。尽管如此，也很难确定具体的应用服务器数量，虽然为所有应用服务器添加足够的内存也是个相当重要的因素。根据经验，所有 WebSphere Application Server JVM 进程加在一起的大小不应超过服务器上未使用物理内存的 80%。在计算该数字可以达到的最大数目时，您必须考虑的不仅有最大堆大小，而且还有除最大堆大小之外的 Java? 字节码解释器的进程大小（这个大小在操作系统进程表中列出）。字节码解释器向进程表大约添加 65MB（除了最大堆大小 128MB 之外），并随最大堆大小的增加而增加。

在解决了 CPU 的最小数量后，您可能要问，最大 CPU 数量是多少？如果您了解到回答也是视情况而定，那不必感到惊讶。一个非常高效且经过精心编写的应用程序只通过一个应用服务器进程即可使用多个 CPU。事实上，WebSphere Performance Lab 在运行涉及 Trade 性能基准时，使用了 12 个 CPU（有时更多）。而期望大多数应用程序具有这种伸缩性可能是不合理的，但大多数经过精心编写的应用程序都应能通过应用服务器使用多个 CPU（实际上，只使用一个 CPU 通常表示存在应用程序瓶颈）。在任何情况下，由 Tom Alcott 在 WebSphere Scalability 一书讲述的确定最佳克隆（或应用服务器实例）数的指导原则仍然适用：

一般情况下，您应调整一个应用服务器的实例来观察吞吐量和性能，然后逐步增加克隆数量，在添加每个克隆时，对性能和吞吐量进行测试。通过这种方式，可以确定为环境提供最佳吞吐量和性能所需的克隆数。通常，在 CPU 利用率达到稍微低于 75% 时，可以通过另添加克隆来提高吞吐量。

而且如您所见，对此问题的最终回答还是视情况而定。