Chinaunix首页 | 论坛 | 博客
  • 博客访问: 3013516
  • 博文数量: 535
  • 博客积分: 15788
  • 博客等级: 上将
  • 技术积分: 6507
  • 用 户 组: 普通用户
  • 注册时间: 2007-03-07 09:11
文章分类

全部博文(535)

文章存档

2016年(1)

2015年(1)

2014年(10)

2013年(26)

2012年(43)

2011年(86)

2010年(76)

2009年(136)

2008年(97)

2007年(59)

分类:

2007-10-07 18:01:03

websphere调整应用程序服务环境
调整应用程序服务环境
为何以及何时执行此任务

要优化您的 WebSphere Application Servers 达到它们最完全的扩展,除了在调整参数活动表中和调整性能参数索引中建议的过程和参数以外,使用性能顾问程序。

性能顾问程序

性能顾问程序使用性能监控基础结构(PMI)数据来建议对对象请求代理程序(ORB)服务线程池、Web 容器线程池、连接池大小、持久的会话大小和时间以及预编译语句高速缓存大小作出配置更改。Runtime Performance Advisor 在应用程序服务器进程中运行,而另一个顾问程序在 Tivoli Performance Viewer(TPV)中运行。要获取更多信息,请参阅文章(使用 Runtime Performance Advisor和使用 Tivoli Performance Viewer 中的性能顾问程序)。

调整参数活动表

查看调整参数活动表,它是调整参数索引的子集。这些热门参数对于性能的影响重大。

调整指南主要针对服务器调整。如果您要调整应用程序,请参阅性能:学习资源一文以获取关于调整应用程序的更多信息。

方便起见,包含了调整其他产品(如 DB2)、Web 服务器和操作系统中的参数的过程。因为这些产品可能更改,所以请将这些描述作为建议考虑。

每个 WebSphere Application Server 进程具有多个影响应用程序性能的参数。您可以使用 WebSphere Application Server 管理控制台配置和调整应用程序、Web 容器、Enterprise Java Beans(EJB)容器、管理域中的应用程序服务器和节点。

首先,查看调整参数活动表,这是调整参数索引的子集。这些参数对性能有重要的影响。因为这些参数与应用程序相关,所以特定应用程序和环境的参数设置可改变。

调整参数索引中的每个参数链接到的信息解释参数,提供调整参数的原因,如何查看或设置参数,以及缺省值和建议值。
调整应用程序服务器
WebSphere Application Server 包含必须相应调整以支持您的端到端电子商务应用程序的定制需要的相关组件。

调整 Java 虚拟机
Java 虚拟机(JVM)提供多个调整参数,这些参数影响 WebSphere Application Server 的性能(主要是 Java 应用程序),以及应用程序的性能。

调整应用程序
包含 Web 模块、EJB 模块、客户机模块、Web service 和应用程序服务的几个主题由应用程序编程模型组成,并提供支持已部署应用程序的许多服务。

调整数据库
WebSphere Application Server 支持集成多个不同的数据库系统。每个数据库系统以其自己的方式调整。为了您的方便起见,提供 DB2 调整参数。

调整安全性
安全性可能会影响性能,这取决于采用了某些操作。

调整硬件容量和设置
必须考虑一些影响性能的硬件因素。

调整操作系统
此部分讨论在服务器环境中调整操作系统的注意事项。

用于分布式平台的 TCP/IP 调整提示
此部分讨论调整 TCP/IP 的注意事项。

调整 Web 服务器
WebSphere Application Server 产品提供用于几个 Web 服务器品牌和版本的插件。每个 Web 服务器操作系统组合都有特定的调整参数,这些参数可影响应用程序性能。

11:01 | 永久链接 | 浏览 (1520) | 评论 (5) | 收藏 |

评论 共 5 条 发表评论

jaesonchen 2006-10-31 11:03
调整应用程序服务器
为何以及何时执行此任务

WebSphere Application Server 包含一些相互关联的组件,它们必须和谐地调整以支持您的端到端电子商务应用程序的定制需要。
这组相关的组件被称为排队网络。排队网络有助于系统在维护整个系统稳定性时实现最大吞吐量。

下列步骤描述可改进您应用程序服务器性能的各种调整任务。您可选择实现任何这些应用程序服务器设置。

此任务的步骤(取决于配置)

调整对象请求代理程序。 对象请求代理程序(ORB)使用因特网 InterORB 协议(IIOP)管理客户机和服务器之间的交互。在分布式网络环境中,它支持客户机请求和从服务器接收到的响应。您可使用下列参数调整 ORB:
设置按引用传递(com.ibm.CORBA.iiop.noLocalCopies),如对象请求代理程序服务设置中所述。
设置连接高速缓存最小值(com.ibm.CORBA.MaxOpenConnections),如对象请求代理程序服务设置中所述。
设置最大大小,如线程池设置 中所述
设置 com.ibm.CORBA.ServerSocketQueueDepth,如对象请求代理程序定制属性中所述。
设置 com.ibm.CORBA.FragmentSize,如对象请求代理程序定制属性中所述。
对象请求代理程序调整准则提供关于使用这些参数来调整 ORB 的提示。

调整 XML 解析器定义。
描述:通过将 XML 解析器定义添加到 ${install_root}/jre/lib 目录中的 jaxp.properties 和 xerxes.properties 文件,以利于服务器启动。因为提供了新版本的 Xerces 时,所以 XMLParserConfiguration 值可能会更改。
如何查看或设置:在两个文件中都插入下列行:
javax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
javax.xml.parsers.DocumentBuildFactory=org.apache.xerces.jaxp.
DocumentBuilderFactoryImpl
org.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.
StandardParserConfiguration
缺省值:无
建议值:无
调整动态高速缓存服务。 使用动态高速缓存服务可改进性能。请参阅任务概述:使用动态高速缓存服务来改进性能以获取关于使用动态高速缓存服务和该服务如何影响应用程序服务器性能的信息。
调整 Web 容器。 WebSphere Application Server Web 容器管理到 servlet、JSP 和 Web service 的所有 HTTP 请求。请求流经传输链到达 Web 容器。传输链定义 Web 容器的性能的重要调整参数。WebSphere Application Server 正在侦听以获取 HTTP 请求的每个 TCP 端口都有传输链。例如,在 Web 容器入站通道链定义缺省的 HTTP 端口 9080。使用下列参数调整 Web 容器:
由服务器线程的池处理 HTTP 请求。可以配置 Web 容器的最小线程池大小和最大线程池大小以获取最佳性能。通常,对于每个服务器 CPU,5 至 10 个线程将会提供最佳吞吐量。配置的线程数并不代表 WebSphere 可以并发处理的请求数。当所有线程都处于忙碌状态时,请求在传输链中排队。要指定线程池设置:
单击服务器 > 应用程序服务器 > server_name Web 容器设置 > Web 容器 > Web 容器传输链。
选择正常入站链为服务请求。这通常被命名为 WCInboundDefault,在端口 9080 上。
单击 TCP 入站通道(TCP_2)。
在“相关项”下设置线程池。
选择 Web 容器。
输入最小大小和最大大小的值。
HTTP 1.1 协议提供“保持活动”功能使得 HTTP 客户机和服务器间的 TCP 连接在请求间保持打开状态。缺省情况下,许多请求或超时周期后,WebSphere Application Server 将关闭给定的客户机连接。关闭连接后,如果客户机发出另一个请求将重新创建连接。过早关闭连接会降低性能。为“保持活动”输入最大持久请求数的值以指定单个 HTTP 连接上允许的请求数。输入持久超时的值以指定 HTTP 传输通道允许套接字在请求间保持空闲状态的时间量(以秒为单位)。要指定最大持久请求数和持久超时的值:
单击服务器 > 应用程序服务器 > server_name Web 容器设置 > Web 容器 > Web 容器传输链。
选择正常入站链为服务请求。这通常被命名为 WCInboundDefault,在端口 9080 上。
单击 HTTP 入站通道(HTTP_2)。
输入最大持久请求数和持久超时的值。
调整 EJB 容器。 当您创建应用程序服务器时,EJB 容器自动创建。在部署 EJB 容器后,您可使用下列参数进行可改进性能的调整。
设置清除时间间隔和高速缓存大小,如EJB 高速缓存设置中所述。
当汇编 EJB 模块时,将 CMP Enterprise beans 分成多个 Enterprise bean 模块。
也可以参阅 EJB 方法调用排队。

调整会话管理。 会话管理的已安装缺省设置对于性能是最理想的。请参阅调整会话管理和调整参数设置以获取关于调整会话管理的更多信息。
调整数据源。 数据源用于从数据库访问数据。下列参数揭示连接池中的物理连接数可如何改变性能。
查看关于连接池的信息。
设置连接池最大值和连接池最小值,如连接池设置中所述。
设置语句高速缓冲区大小,如数据源设置中所述。

jaesonchen 2006-10-31 11:04
调整 Java 虚拟机
为何以及何时执行此任务

应用程序服务器作为一个 Java 进程,需要一个 Java 虚拟机(JVM)运行和支持在它上面运行的 Java 应用程序。作为配置应用程序服务器的一部分,您可微调增强 JVM 的系统使用的设置。除了下列调整参数,另见Java 内存调整提示。

使用下列 JVM 参数(包括 IBM Developer Kit 1.4.2 的垃圾回收选项)以调整 Java 虚拟机。要获取关于查看和更改 JVM 配置的指示信息,转至使用 JVM。要获取关于指定任何下列设置的信息,转至Java 虚拟机设置。

此任务的步骤(取决于配置)

指定下列任一或所有通用 JVM 参数。 这些可选命令行参数传递给启动应用程序服务器进程的 Java 虚拟机代码。
快速启动(-Xquickstart)
避免类验证(-Xverify:none)
类垃圾回收(-Xnoclassgc)
垃圾回收线程(-Xgcthreads)
垃圾回收策略(-Xgcpolicy)
Sun JDK 1.4.2 世代垃圾回收(-XX)
您可在 上找到有关世代垃圾回收的更多信息。

Sun Java Development Kit 1.4.2 HotSpot JVM 暖机(-server)
堆压缩(-Xnocompactgc)
初始系统堆大小(-Xinitsh)
设置初始堆大小。
设置最大堆大小。

jaesonchen 2006-10-31 11:06
Java 内存调整提示
用 Java 语言写的企业应用程序涉及复杂对象关系,并利用大量对象。虽然,Java 语言会自动管理与对象生命周期关联的内存,但了解对象的应用程序使用模式是重要的。特别要验证以下内容:
应用程序不是过度使用的对象
应用程序不是漏掉的对象
已正确设置 Java 堆参数以处理给定的对象使用模式
了解垃圾回收的效果对应用这些管理技术是必需的。

垃圾回收瓶颈

检查 Java 垃圾回收可了解应用程序正在如何利用内存。垃圾回收是 Java 的特质。通过从应用程序写程序除去内存管理负担,Java 应用程序比用不提供垃圾回收的语言写的应用程序更健壮。只要应用程序不在滥用对象,此健壮性就适用。垃圾回收通常使用正确运行的应用程序的总执行时间的 5% 到 20%。如果不受管,则垃圾回收会是应用程序的某个最大瓶颈,特别是当运行在对称多处理(SMP)服务器上。在大多数垃圾回收循环期间,Java 虚拟机(JVM)使用并行垃圾收集器,最大程度地利用了 SMP,其中 Sun HotSpot 1.3.1 JVM 具有单线程的垃圾收集器。要获取有关在 Solaris Operating Environment 中的垃圾回收的更多信息,请参阅性能:学习资源。

垃圾回收标尺

您可以使用垃圾回收评价应用程序性能运行状况。通过在执行固定工作负载期间监控垃圾回收,您可了解应用程序是否是过度使用的对象。垃圾回收甚至可以检测到内存泄漏的存在。

您可以使用 Tivoli Performance Viewer 中的对象统计信息或使用 verbose:gc JVM 配置设置监控垃圾回收统计信息。verbose:gc 格式在不同的 JVM 之间或发行版级别之间不是标准化的。要获取 IBM verbose:gc 输出的描述和有关 IBM 垃圾收集器的更多信息,请参阅性能:学习资源。

要获取此类型研究,将最小和最大堆大小设置为同一值。选择与生产用法尽可能匹配的有代表性的、重复的工作负载,包括用户错误。

要确保有意义的统计信息,请运行固定工作负载直到应用程序状态稳定为止。通常要用几分钟的时间来达到稳定状态。

检测过度使用的对象

您可以通过观察 JVM 运行时的计数器,使用 Tivoli Performance Viewer 检查应用程序是否是过度使用的对象。您不得不设置 -XrunpmiJvmpiProfiler 命令行选项以及 JVM 模块最大级别,以便启用 Java 虚拟机概要分析程序接口(JVMPI)计数器。垃圾回收之间的最佳平均时间为至少是单次垃圾回收的平均持续时间的 5 到 6 倍。如果没有达到此数字,则应用程序将多用 15% 的时间用于垃圾回收。

如果信息表明垃圾回收瓶颈,则有两种方法清除瓶颈。最划算的方法是优化应用程序以实施对象高速缓存和池。使用 Java 概要分析程序确定把哪些对象作为目标。如果您无法优化应用程序,则添加内存、处理器和克隆可能会有帮助。添加的内存允许每个克隆保持合理的堆大小。添加的处理器允许克隆并行运行。

检测内存泄漏

内存泄漏在 Java 语言中是造成垃圾回收瓶颈的一个危险因素。内存泄漏比内存过度使用更有破坏性,因为内存泄漏最终会导致系统不稳定。随着时间的过去,垃圾回收会发生得更加频繁,直到堆用尽,而且 Java 代码失败并返回致命的缺乏内存异常。当未使用的对象具有从未释放的引用时,发生内存泄漏。内存泄漏通常发生在集合类(如 Hashtable)中,这是因为表总是具有对对象的引用(甚至在删除真实的引用后)。

高工作负载总会引起应用程序在生产环境中部署后立即崩溃。这对于泄漏应用程序尤其正确,其中高工作负载会促进泄漏的放大率,而且会发生内存分配故障。

进行内存泄漏测试的目标是扩大数字。根据无法进行垃圾回收的字节或千字节量评测内存泄漏。此精细任务将区别有用和不可用内存的预期大小之间的这些量。如果扩大数字,这会导致更大的间隔和更易于标识不一致性,则完成此任务会更简便。以下列表包含有关内存泄漏的重要结论:
长期运行测试
内存泄漏问题可能在一段时间后才会显现,因此,在长期运行测试期间易于找到内存泄漏。短期测试可能导致错误的警报。有时,当 Java 语言中发生内存泄漏时,很难知道,尤其当在一段给定时间内,内存使用情况表面上突然地或单调地增加时。很难检测内存泄漏的原因是由于这些种类的增加可能有效或可能是开发者的意图。您可以通过将应用程序运行一段较长的时间,来了解如何区分延迟使用的对象和完全未使用的对象。进行长期运行应用程序测试能帮助您更好地确定延迟使用对象是否正在实际发生。

重复测试
在很多情况下,内存泄漏问题通过同一测试用例的连续重复而发生。内存泄漏测试的目标是建立不能使用的内存和使用的内存(根据它们的相对大小)之间的大间隔。通过一次又一次地重复同一方案,渐进地增加间隔。如果由执行测试用例引起的泄漏数太小以至于很难在某次运行中明显地显示出来,则进行此测试会有帮助。

您可以在系统级别或模块级别上使用重复测试。进行模块化测试的优点是较好控制。当设计模块在不创建外部副作用(如内存使用情况)的情况下保持专用模块时,对内存泄漏进行测试较简便。首先,在运行模块前记录内存使用情况。然后,重复运行一组固定的测试用例。在测试运行结束时,为重大更改记录和检查当前消息使用情况。请记住,当通过将 System.gc() 插入到模块(您要垃圾回收发生的地方)中,或使用概要分析工具强迫事件发生时,必须建议使用垃圾回收。

并发性测试
某些内存泄漏问题可能仅当几个线程运行在应用程序中时发生。不幸地是,由于程序逻辑中添加的新出现的问题,同步点很容易受到内存泄漏的影响。编程粗心可能会导致保存或未释放的引用。系统中增加的并发性通常会推动或促进内存泄漏事件。增加并发性最常见的方法就是增加测试驱动程序中的客户机数。

当选择将哪些测试用例用于进行内存泄漏测试时,考虑以下各点:
好的测试用例会经历创建对象的应用程序区域。大多数时间,需要应用程序的知识。方案的描述可以建议创建数据空间,如添加新记录、创建 HTTP 会话、执行事务和搜索记录。
查看使用对象集合的区域。通常,内存泄漏由同一类中的对象组成。同样,集合类(如 Vector 和 Hashtable)是通过调用相应的插入方法,隐式存储对对象的引用的常见位置。例如,Hashtable 对象的 get 方法不会除去其对已检索对象的引用。
Tivoli Performance Viewer 可以帮助查找内存泄漏。要获取最佳结果,请用渐增的持续时间重复实验,象 1000、2000 和 4000 页请求。使用的内存的 Tivoli Performance Viewer 图应该具有锯齿形状。图上的每个下降对应于垃圾回收。如果发生以下某种情况,则存在内存泄漏:
每次垃圾回收显著增加后,立即使用的内存量。锯齿模式更象楼梯。
锯齿模式具有不规则的形状。
同样,查看已分配的对象数和已释放的对象数之间的差异。如果两个增长之间的间隔超出时间,则存在内存泄漏。
表明重工作负载(应用程序服务器的 CPU 利用率一直接近 100%)期间可能的泄漏,但似乎会在接下来的较轻或接近空闲的工作负载期间恢复的堆消耗,是堆碎片整理的指示。当 JVM 可以在垃圾回收循环期间释放足够的对象以满足内存分配请求时,发生堆碎片整理,但 JVM,没有时间将堆中小的空闲内存区域压缩到较大的邻近空间。

当释放小对象(小于 512 个字节)时,会发生另一种格式的堆碎片整理。会释放对象,但不会恢复存储器,导致内存分段直到已运行堆压缩。

要避免堆碎片整理,打开 JVM 高级设置命令行实参中的 -Xcompactgc 标志。-Xcompactgc 函数会验证每个垃圾回收循环是否除去分段存储。然而,压缩是代价相对高昂的操作。请参阅Java 虚拟机设置中的堆压缩命令行实参(-Xnocompactgc),以获取更多信息。

Java 堆参数

Java 堆参数还会影响垃圾回收行为。增加堆大小会支持更多对象创建。由于大的堆要用较长时间进行填充,所以在垃圾回收发生前应用程序会运行较长时间。然而,较大的堆也会用较长时间进行压缩,和引起垃圾回收发生。请参阅Java 虚拟机设置中有关 Java 堆大小的部分,以获取更多信息。

对于性能分析,初始堆大小和最大堆大小应该相等。

当调整 Java 应用程序的工作集大小未知的生产系统时,初始堆大小的适宜的启动值是最大堆大小的 25%。然后,JVM 尝试使堆大小适应应用程序的工作集大小。

此插图表示三个 CPU 概要文件,每个概要文件都在运行具有变动的 Java 堆设置的固定工作负载。在中间的概要文件中,将初始堆大小和最大堆大小设置为 128MB。发生四次垃圾回收。垃圾回收的总时间大约是运行总时间的 15%。当堆参数加倍为 256MB 时(如在顶部的概要文件中所示),在两次垃圾回收之间的工作时间的长度会增加。仅发生三次垃圾回收,但每次垃圾回收的工作时间长度也会增加。在第三个概要文件中,堆大小减少为 64MB,而且会显示出相反的效果。使用较小的堆大小,两次垃圾回收之间的时间和每次垃圾回收的时间也会较短。对于所有三种配置,垃圾回收的总时间大约是 15%。此示例说明有关 Java 堆大小和其与对象利用率的关系的重要概念。在 Java 应用程序中总是有垃圾回收的成本。

运行一系列改变 Java 堆设置的测试实验。例如,用 128MB、192MB、256MB 和 320MB 运行实验。在每次实验期间,监控全部内存使用情况。如果您太多扩展堆,则可能发生内存分页。使用 vmstat 命令或 Windows NT 或 Windows 2000 性能监视器检查页面调度。如果发生页面调度,则减少堆大小或将更多的内存添加到系统。当所有运行都完成时,比较以下各统计信息:
垃圾回收调用次数
一次垃圾回收调用的平均持续时间
一次垃圾回收调用的工作时间长度和两次垃圾回收调用之间的平均时间之间的比率
如果应用程序不是过度使用的对象而且没有内存泄漏,则达到稳定内存利用率的状态。垃圾回收也会发生得较不频繁,而且持续时间短。
如果堆可用空间稳定在 85% 或更多,则考虑减少堆大小的最大值,这是因为应用程序服务器和应用程序未充分利用为堆分配的内存。

要获取有关垃圾回收的更多信息,请参阅性能:学习资源。

有关可从 IBM Support 处获取的关于已知问题及其解决方法的当前信息,请参阅 IBM Support 页面。

IBM Support 拥有的文档可节省您收集解决此问题所需信息的时间。在打开 PMR 前,请参阅 IBM Support 页面。


jaesonchen 2006-10-31 11:08
调整操作系统
为何以及何时执行此任务

下列调整参数特定于操作系统。因为这些不是 WebSphere Application Server 产品,所以注意产品可更改,而且结果可改变。
此任务的步骤(取决于配置)

调整 Windows NT 或 Windows 2000 操作系统
TcpTimedWaitDelay
描述:确定 TCP/IP 可释放已关闭连接并重用其资源前,必须经过的时间。关闭和释放之间的此时间间隔通称 TIME_WAIT 状态或两倍最大段生命周期(2MSL)状态。此时间期间,重新打开到客户机和服务器的连接的成本少于建立新连接。减少此条目的值允许 TCP/IP 更快地释放已关闭的连接,为新连接提供更多资源。如果运行的应用程序需要快速释放和创建新连接,而且由于 TIME_WAIT 中存在很多连接,导致低吞吐量,则调整此参数。
如何查看或设置:
使用 regedit 命令访问 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters 注册表子键并创建名为 TcpTimedWaitDelay 的新 REG_DWORD 值。
将此值设置为十进制 30,其为十六进制 0x0000001e。该值将等待时间设置为 30 秒。
停止并重新启动系统。
缺省值:0xF0,它将等待时间设置为 240 秒(4 分钟)。
建议值:最小值为 0x1E,它将等待时间设置为 30 秒。
MaxUserPort
描述:确定在应用程序从系统请求可用用户端口时,TCP/IP 可指定的最高端口号。
如何查看或设置:
使用 regedit 命令访问 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters 注册表子键并创建名为 MaxUserPort 的新 REG_DWORD 值。
停止并重新启动系统。
缺省值:无
建议值:至少十进制 32768。
注:当在 Windows NT 或 Windows 2000 操作系统上调整 WebSphere Application Server 时,同时使用这两个参数。

调整 AIX
TCP_TIMEWAIT
描述:确定 TCP/IP 可释放已关闭连接并重用其资源前,必须经过的时间。关闭和释放之间的此时间间隔通称 TIME_WAIT 状态或两倍最大段生命周期(2MSL)状态。此时间期间,重新打开到客户机和服务器的连接的成本少于建立新连接。减少此条目的值允许 TCP/IP 更快地释放已关闭的连接,为新连接提供更多资源。如果运行应用程序需要快速释放、创建新的连接,并且由于许多连接处于 TIME_WAIT 状态而导致低吞吐量,则调整此参数。
如何查看或设置:
发出下列命令,将 TCP_TIMEWAIT 状态设置为 15 秒:
/usr/sbin/no –o tcp_timewait =1
安装了 DB2 的 AIX 操作系统
描述:将 DB2 日志文件从物理数据库文件中分隔出来可增加性能。您还可将日志记录和数据库文件从包含日志文件系统(JFS)服务的驱动器中分隔出来。AIX 为 JFS 日志记录使用特定卷组和文件系统。
如何查看或设置:使用 AIX filemon 实用程序查看所有文件系统输入和输出,并在战略上选择 DB2 日志的文件系统。然后,根据DB2 调整参数设置 DB2 日志位置。
缺省值:文件的缺省位置是 \home\\sqllib\db2dump。
建议值:把文件移动到与 DB2 数据分开的、并且具有最小输入或输出活动的磁盘上。
AIX 文件描述符(ulimit)
描述:指定允许的打开文件数。缺省设置通常足够用于大多数应用程序。如果此参数的值设置过低,则显示内存分配错误。
如何查看或设置:检查关于 ulimit 命令的 UNIX 参考页面以获取不同 shell 的语法。对于 KornShell shell(ksh),要将 ulimit 设置为 2000,发出 ulimit -n 2000 命令。使用 ulimit -a 命令显示系统资源上所有限制的当前值。
缺省值:对于 AIX 系统,缺省设置为 2000。
建议值:2000
AIX TCP_KEEPIDLE
描述:“保持活动”包确保连接处于 active/ESTABLISHED 状态。
如何查看或设置:使用 no 命令以确定当前值或设置该值。直到下次您重新启动机器后,更改才会生效。要永久更改该值,则将 no 命令添加到 /etc/rc.net 目录。例如:
no -o tcp_keepidle=600

缺省值:14400 毫秒。
建议值:600 毫秒。
其他 AIX 信息
还存在很多本文档未涉及的其他 AIX 操作系统设置要考虑。您可调整的其他设置如下所示:
适配器发送和接收队列
TCP/IP 套接字缓冲区
IP 协议 mbuf 池性能
更新文件描述符
更新调度程序
要获取关于 AIX 操作系统的更多信息,请参阅 性能:学习资源。
调整 Solaris 操作系统
Solaris 文件描述符(ulimit)
描述:指定允许的打开文件数。如果此参数的值太小,则在 WebSphere Application Server stderr.log 文件中会显示打开太多文件错误。
如何查看或设置:检查关于 ulimit 命令的 UNIX 参考页面以获取不同 shell 的语法。对于 KornShell(ksh)shell 程序,使用 ulimit -n 1024 命令。使用 ulimit -a 命令显示系统资源上所有限制的当前值。
缺省值:无
建议值:2000
Solaris TCP_TIME_WAIT_INTERVAL
描述:通知 TCP/IP 保留已关闭连接控制块多久。在应用程序完成 TCP/IP 连接后,控制块保留指定的时间。当高连接率发生时,大量 TCP/IP 连接累加,而且可减慢服务器性能。服务器在某些峰值期间会延迟。如果服务器延迟,netstat 命令显示对 HTTP 服务器打开的许多套接字处于 CLOSE_WAIT 或 FIN_WAIT_2 状态。可视延迟最多可发生 4 分钟,其间服务器无法发送任何响应,但是 CPU 利用率保持很高,带有系统进程中的所有活动。
如何查看或设置:使用 get 命令确定当前时间间隔,并使用 set 命令将时间间隔指定为 30 秒。例如:
ndd -get /dev/tcp tcp_time_wait_interval
ndd -set /dev/tcp tcp_time_wait_interval 30000
缺省值:对于 Solaris 操作系统,缺省等待时间间隔为 2400000 毫秒(相当于 4 分钟)。
建议值:30000 毫秒。
Solaris TCP_FIN_WAIT_2_FLUSH_INTERVAL
描述:指定禁止处于 FIN_WAIT_2 状态中的连接保持该状态的计时器时间间隔。当高连接率发生时,大量 TCP/IP 连接累加,而且可减慢服务器性能。服务器在峰值期间会延迟。如果服务器延迟,使用 netstat 命令显示向 HTTP 服务器打开着的许多套接字处于 CLOSE_WAIT 或 FIN_WAIT_2 状态。可视延迟最多可发生 4 分钟,其间服务器无法发送任何响应,但是 CPU 利用率保持很高,带有系统进程中的所有活动。
如何查看和设置:您可以通过使用下列命令将当前时间间隔设置为 67.5 秒:
ndd -get /dev/tcp tcp_fin_wait_2_flush_interval
ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 67500
缺省值:675000 毫秒。
建议值:67500 毫秒。
Solaris TCP_KEEPALIVE_INTERVAL
描述:“保持活动”包确保连接处于 active/ESTABLISHED 状态。
如何查看或设置:使用 ndd 命令确定当前值或设置该值。例如:
ndd -set /dev/tcp tcp_keepalive_interval 300000

缺省值:7200000 毫秒。
建议值:300000 毫秒。
Solaris 内核 semsys:seminfo_semume
描述:限制每个进程最大信号量撤销条目。因为此设置指定最大值,所以参数不会导致使用附加内存,除非它需要。
如何查看或设置:如果运行 /usr/sbin/sysdef 命令,则此值显示为 semume 参数。/etc/system 文件中可有一个条目用于此调整参数。通过 /etc/system 条目设置此参数:
set semsys:seminfo_semume = 1024
缺省值:10
建议值:无
Solaris 内核 semsys:seminfo_semume
描述:限制每个进程最大信号量撤销条目。因为此设置指定最大值,所以参数不会导致使用附加内存,除非它需要。
如何查看或设置:如果运行 /usr/sbin/sysdef 命令,则此值显示为 semume 参数。/etc/system 文件中可有一个条目用于此调整参数。通过 /etc/system 条目设置此参数:
set semsys:seminfo_semume = 1024
缺省值:10
建议值:无
Solaris 内核 semsys:seminfo_semopm
描述:如果运行 /usr/sbin/sysdef 命令,则显示为 semume 参数。/etc/system 文件中可存在用于此调整参数的条目。
如何查看或设置:通过 /etc/system 条目设置此参数:
semsys:seminfo_semopm = 200
缺省值:无
建议值:16384
调整 HP-UX 11i
修改 HP-UX 11i 设置以大大提高 WebSphere Application Server 性能。要获取关于 HP 性能调整参数的其他信息,请参阅 性能:学习资源。

Java 虚拟机(JVM)虚拟页面大小
描述:将 JVM 指示信息和数据页面大小设置为 64MB 将提高性能。
如何查看或设置:使用 chatr +pi64M +pd64M /opt/WebSphere/AppServer/java/bin/PA_RISC2.0/native_threads/java 命令。命令输出提供进程可执行文件的当前操作系统特征。
缺省值:4MB(如果未指定)
建议值:64MB
HP-UX 11i TCP_CONN_REQUEST_MAX
描述:指定当服务器没有任何可用线程时,操作系统可排队的最大连接请求数。当高连接率发生时,大量 TCP/IP 连接请求构建,并删除客户机连接。当客户机在等待连接后开始超时时,调整此设置。通过发出 netstat -p tcp 命令验证此情况。查找下列值:connect requests dropped due to full queue
如何查看或设置:通过使用 ndd -set /dev/tcp tcp_conn_request_max 1024 命令设置此参数。
缺省值:4096
建议值:多数情况下缺省值应已足够。如果缺省值不够,考虑调整为 8192。
HP-UX 11i 内核参数建议
描述:使用 DB2 或 Oracle 数据库的下列内核参数设置以获得最佳性能:内核参数 WebSphere Application Server 设置 DB2 设置 Oracle 设置
maxuprc -- 512 --
maxfiles 2,048 -- --
maxfiles_lim 2,048 -- --
nkthread 10,000 -- --
max_thread_proc 2,048 -- --
nproc -- 1,028 --
nflocks -- 8,192 --
ninode -- 2,048 --
nfile -- 8,192 --
msgseg -- 32,767 --
msgmnb -- 65,535 --
msgmax -- 65,535 --
msgtql -- 1,024 --
msgmap -- 258 --
msgmni -- 256 --
msgssz -- 16 --
semmni -- 512 70
semmap -- 514 --
semmns -- 1,024 200
semmnu -- 1,024 --
shmmax -- 966,367,642 1 GB
shmmseg -- 16 10
shmmni -- 300 100

如何查看或设置:使用 HP-UX SAM 实用程序设置内核参数。请参阅文档,以获得关于您的操作系统的指示。
缺省值:无
建议值: 请参阅表
用于 WebSphere MQ 5.3 的 HP-UX 11i 内核参数建议
描述:嵌入式消息传递使用 WebSphere MQ 5.3。下列是 WebSphere MQ 5.3 建议的内核参数设置:内核参数 设置
shmmax 536870912
shmseg 1024
shmmni 1024
shmem 1
sema 1
semaem 16384
semvmx 32767
semmns 16384
semmni 1024 (semmni < semmns)
semmap 1026 (semmni +2)
semmnu 2048
semume 256
msgmni 50
msgtql 256
msgmap 258 (msgtql +2)
msgmax 4096
msgmnb 4096
msgssz 8
msgseg 1024
maxusers 32
max_thread_proc 66
maxfiles 1024
nfile 10000

如何查看或设置:使用 HP-UX SAM 实用程序设置内核参数。请参阅文档,以获得关于您的操作系统的指示。
缺省值:无
建议值: 请参阅表
世代垃圾回收 nursery 大小
描述:WebSphere Application Server V5 与基于 Sun Hotspot 技术的 HP 本机 JVM 一起提供。其功能之一是使用将堆分割为新代和旧代的世代垃圾回收。必须使用性能分析工具(如 Glance)确定新代或 nursery 的适当大小。如果正确选择 nursery 大小,垃圾回收的开销会减少并改进吞吐量和响应时间。
如何查看或设置:在一般 Java 选项上使用 -Xmn 命令,例如,使用 -Xmn512m 将 nursery 大小设置为 512MB。
缺省值:三分之一的最大堆大小。
建议值:当创建几个短暂的对象时,将值设置为堆大小最大值的二分之一。
调整 Linux
timeout_timewait 参数
描述:确定 TCP/IP 可释放已关闭连接并重用其资源前,必须经过的时间。关闭和释放之间的此时间间隔通称 TIME_WAIT 状态或两倍最大段生命周期(2MSL)状态。此时间期间,重新打开到客户机和服务器的连接的成本少于建立新连接。减少此条目的值允许 TCP/IP 更快地释放已关闭的连接,为新连接提供更多资源。如果运行应用程序需要快速释放、创建新的连接,并且由于许多连接处于 TIME_WAIT 状态而导致低吞吐量,则调整此参数。
如何查看或设置:
发出下列命令,将 timeout_timewait 参数设置为 30 秒:
/sbin/sysctl -w net.ipv4.vs.timeout_timewait=30
SLES8 SP2A - sched_yield_scale 调整
描述:Linux 调度程序对过度的上下文交换非常敏感,因此已将修订程序集成到 SLES8 内核分发,以便在线程发生处理时引进延迟。此修订程序在 SLES8 SP3 中自动启用,但在 SLES8 SP2A 或以上版本中必须明确地启用。
如何查看或设置:
如果您运行任何 SP2A 以下版本的 SLES8 service pack,升级到 SP2A。
发出命令 sysctl -w sched_yield_scale=1。
缺省值:0
建议值:1
RedHat Advanced Server 2.1 内核更新
描述:RedHat Advanced Server 2.1 的内核更新已实现影响 WebSphere 性能的更改,尤其是内存到内存 HTTP 会话复制。
如何查看或设置:
发出 uname -a 命令
如果您正在运行任何在 2.4.9-e.23 之前的内核,至少升级到此内核,最好升级到最近支持的内核。
缺省值:2.4.9-e.3
建议值:2.4.9-e.23
Linux 文件描述符(ulimit)
描述:指定允许的打开文件数。缺省设置通常足够用于大多数应用程序。如果将此参数的值设置得太小,则可能会显示文件打开错误、内存分配故障或连接建立错误。
如何查看或设置:检查关于 ulimit 命令的 UNIX 参考页面以获取不同 shell 的语法。对于 KornShell shell(ksh)程序,要将 ulimit 命令设置为 2000,则发出 ulimit -n 2000 命令。使用 ulimit -a 命令显示系统资源上所有限制的当前值。
缺省值:对于 Linux 系统,缺省设置为 1024。这是 SLES 9 的缺省值。
建议值:8000

jaesonchen 2006-10-31 11:09
Web 服务器调整参数
WebSphere Application Server 提供用于几个 Web 服务器品牌和版本的插件。每个 Web 服务器操作系统组合都有特定的调整参数,这些参数可影响应用程序性能。

IBM HTTP Server
IBM HTTP Server V6.0 是多进程、多线程的服务器。

访问日志
描述:收集所有入局 HTTP 请求。记录日志会降低性能,因为 IO 操作开销导致日志在短时间内显著增加。
如何查看或设置:
打开 IBM HTTP Server httpd.conf 文件,它位于目录 IBM_HTTP_Server_root_directory/conf 中。
搜索含有文本 CustomLog 的行。
通过在行首放置 # 来注释掉此行。
保存并关闭 httpd.conf 文件。
停止并重新启动 IBM HTTP Server。
缺省值:启用记录每个入局 HTTP 请求。
建议值:禁用访问日志。
MaxClients
描述:MaxClients 伪指令控制 Web 服务器在任何时候可以提供的最大同步连接数或用户数。使用处于峰值时,如果您的 Web 服务器需要立即支持 200 个活动用户,则应该把 MaxClients 设置为 220(200 加负载额外增长的 10%)。把 MaxClients 设置得太低会导致有些用户认为 Web 服务器不响应。您在您的 Web 服务器中应该有足够的 RAM 来支持每个已连接的客户机。对于 Unix 上的 IBM HTTP Server V6.0,您应该分配大约 1.5MB MaxClients RAM 供 IBM HTTP Server 使用。对于 Windows 上的 IBM HTTP Server V6.0,您应该分配大约 300KB MaxClients RAM 供 IBM HTTP Server 使用。有些第三方模块会显著地增加每台已连接客户机使用的 RAM 数。
如何查看或设置:编辑 IBM HTTP Server httpd.conf 文件中的 MaxClients 伪指令,该文件位于目录 IBM_HTTP_Server_root_directory/conf 中。
缺省值:150
建议值:通常同步连接到您的 Web 服务器的最大用户数,附加缓冲区另外的 10%。注:KeepAliveTimeout 设置会影响用户连接到 Web 服务器的时间长短。
MinSpareServers、MaxSpareServers 和 StartServers
描述:预分配和维护指定的进程数,以便当负载接近指定的进程数时创建和销毁不多的进程。指定相似的值会减少用于创建和销毁 HTTPD 进程的 CPU 使用情况。等待 IBM HTTP Server 启动更多服务器(以便它可处理 HTTP 请求)时调整此参数是不可接受的。
如何查看或设置:编辑 httpd.conf 文件中的 MinSpareServers、MaxSpareServers 和 StartServers 伪指令,此文件位于 IBM_HTTP_Server_root_directory/conf 目录中。
缺省值:MinSpareServers 5、MaxSpareServers 10、StartServers 5
建议值:要获得最佳性能,为 MinSpareServers 和 StartServers 参数指定相同的值。如果 MaxSpareServers 设置成小于 MinSpareServers,那么 IBM HTTP Server 复位 MaxSpareServer=MinSpareServer+1。把 StartServers 设置过高可导致内存不足时的交换,从而降低性能。
ListenBackLog
描述:设置暂挂连接队列的长度。当几个客户机请求连接到 IBM HTTP Server 并使用了所有线程时,有一个队列保留其他客户机请求。然而,如果您使用 Windows 上的 IBM HTTP Server V6.0 的缺省快速响应高速缓存加速器(FRCA)功能,则因为 FRCA 有其自己的内部队列而不使用 ListenBackLog 伪指令。
如何查看或设置:对于非 FRCA:编辑 IBM HTTP Server httpd.conf 文件。然后,添加或查看 ListenBackLog 伪指令。
缺省值:对于 HTTP Server V6.0:1024 启用了 FRCA,511 禁用了 FRCA
建议值:使用缺省值。
IBM HTTP Server - Linux
MaxRequestsPerChild
描述:设置单个子服务器进程处理的请求数的限制。在请求数达到为 MaxRequestsPerChild 参数设置的值后,子进程死亡。当销毁和创建子进程时调整此参数会降低您的 Web 服务器性能。
如何查看或设置:
编辑 IBM HTTP server httpd.conf 文件,它位于 IBM_HTTP_Server_root_directory/conf 目录中。
更改参数的值。
保存更改并重新启动 IBM HTTP server。
缺省值:500
建议值:通常应该设置为 0。如果观察到子内存使用情况随时间的过去稳定地增长,则非零设置会有用。有时在 IBM HTTP Server 使用的第三方模块和各种 OS 运行时库中会观察到内存泄漏。
IBM HTTP Server - Windows 2000 和 Windows 2003
ThreadsPerChild
描述:设置 IBM HTTP Server 中任何时刻运行的并发线程数。
如何查看或设置:编辑 IBM HTTP Server 文件(httpd.conf 文件),它位于目录 IBM_HTTP_Server_root_directory/conf 中。更改参数的值。保存更改并重新启动 IBM HTTP Server。
有两种在欠载状态下查找使用多少线程的方法:
使用 Windows 2000 和 Windows 2003 性能监视器,它位于桌面“开始”菜单下:
右键单击桌面上的状态栏。单击任务管理器。
选择进程选项卡。
单击查看 > 选择列。
选择线程计数。
单击确定。
进程选项卡在线程列名下显示每个进程的线程数(包括 Apache)。

使用 IBM HTTP Server 服务器状态(此选项可在所有平台上使用,并不仅限 Windows):
按如下所示编辑 IBM HTTP Server httpd.conf 文件:从以下各行除去注释字符 #:#LoadModule status_module、modules/ApacheModuleStatus.dll、#、#SetHandler server-status 和 #
保存更改并重新启动 IBM HTTP Server。
在 Web 浏览器中,转至 URL:。换句话说,
单击重新装入以更新状态。
(可选的)如果浏览器支持刷新,转至 以每五秒刷新一次。您将看到当前处理 45 个空闲服务器的五个请求。
缺省值:对于 IBM HTTP Server V6.0 为 250。
建议值:设置该值以避免瓶颈,它允许有恰好足够的流量通过应用程序服务器。
Web 服务器配置重新装入时间间隔
描述:跟踪有关 WebSphere Application Server 资源的配置信息的变化。Web 服务器需要了解一些此类信息,如指向 WebSphere Application Server 资源的统一资源标识(URI)。此配置数据是在由此参数指定的时间间隔中通过 WebSphere Application Server 插件推进到 Web 服务器中的。定期更新添加新的 servlet 定义,而无须重新启动任何 WebSphere Application Server 服务器。然而,动态重新生成此类配置信息在性能方面的代价很高。在稳定的生产环境中调整此参数。
如何查看或设置:使用“刷新配置时间间隔 Web 服务器插件”属性更改此参数的当前设置。在管理控制台中,单击服务器 > Web 服务器 > Web_server_name > 插件属性。
缺省值:缺省重新装入时间间隔为 60 秒。
建议值:增加值的重新装入间隔,该值表示一个在 servlet 更新和 Web 服务器更新间的可接受的等待时间。
要获取有关 plugin-cfg.xml 文件的更多信息,请参阅主题Web 服务器插件。

Sun Java System Web server,Enterprise Edition(从前的 Sun ONE)- Solaris operating environment
Sun ONE Web server,Enterprise Edition 的缺省配置提供了单进程、多线程服务器。

活动线程
描述:指定服务器中当前活动的线程数。在服务器到达此参数设置的限制后,服务器将停止对新连接的服务直至它完成旧连接。如果此设置过低,可压制服务器,从而导致降低响应时间。要知道 Web 服务器是否被压制,请考虑其 perfdump 统计信息。请查看以下各数据:
WaitingThreads 计数:如果 WaitingThreads 计数将接近零或为零,则服务器不接受新连接。
BusyThreads 计数:如果 WaitingThreads 计数接近零或为零,则 BusyThreads 很可能非常接近其限制。
ActiveThreads 计数:如果 ActiveThreads 计数接近其限制,服务器很可能限制了其本身。
如何查看或设置:使用“企业服务器管理器”接口中的最大同时请求数参数,以控制 Sun ONE Web server,Enterprise Edition 中的活动线程数。此设置与 magnus.conf 文件中的 RqThrottle 参数对应。
缺省值:512
建议值:增加线程计数直到活动线程参数显示最优的操作。
Microsoft Internet Information Server(IIS)- Windows NT 和 Windows 2000
IIS 许可权属性
描述:Web server 有几个属性,它们主要影响应用程序服务器的性能。通常,缺省设置都可接受。然而,因为其他产品可更改缺省设置而用户却不知道,所以确保检查 IIS 设置以获得 Web 服务器的主目录许可权。许可权应该设置成“脚本”而并非“执行”。如果许可权设置成“执行”,则不返回错误消息,而 WebSphere Application Server 的性能将降低。
如何查看或设置:要检查或更改这些许可权,在 Microsoft 管理控制台中执行以下过程:
选择 Web 站点(通常是缺省 Web 站点)。
右键单击并选择属性选项。
单击主目录选项卡。要设置主目录的许可权:
在应用程序设置中,选择许可权列表中的脚本复选框并清除执行复选框。
(可选的)检查 sePlugin 的许可权:
展开 Web 服务器。
右键单击 sePlugin 并选择属性。
确认执行许可权被设置为执行。
缺省值:Script
建议值:Script
每天期望的命中数
描述:控制 IIS 分配连接的内存。
如何查看或设置:使用性能窗口,把 Microsoft 管理控制台的 Web 站点属性面板中的参数设置成大于 100000。
缺省值:小于 100000
建议值:大于 100000
ListenBackLog 参数
描述:当在 Windows NT 和 Windows 2000 上使用 IIS 时,减轻重负载条件下的失败连接。故障通常发生在使用大于 100 台客户机时。ListenBackLog 会增加 IIS 保留在其队列中的请求数。如果在 Netscape 浏览器中间歇地看到无法找到服务器错误时,请考虑提高该值。
如何查看或设置:
使用命令提示符以发出 regedit 命令来访问操作系统注册表。
在注册表窗口中,找到 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ InetInfo\Parameters\ListenBackLog 目录中的参数。
右键击单该参数,以根据服务器负载调整设置。
缺省值:25(十进制)
建议值:您可将 ListenBackLog 参数设置成 200 那么高,它不会对性能产生负面影响且提高负载处理能力。
修改 WebSphere 插件,以改进性能

您可通过修改插件的 RetryInterval 配置改进 IBM HTTP Server V6.0(带有 WebSphere Web 服务器插件)的性能。RetryInterval 是尝试连接到已标记为临时不可用的服务器所等待时间的长度。进行此更改可帮助 IBM HTTP Server V6.0 调整为多于 400 个用户。

如果到服务器的连接失败,插件将服务器标记为临时不可用。尽管缺省值为 60 秒,建议您减小此值,以便在重负载条件下增加吞吐量。减小 RetryInterval 对于每个进程具有单个线程的 UNIX 操作系统上的 IBM HTTP Server V6.0 或对于配置为每个进程具有少于 10 个线程的 IBM HTTP Server 2.0 很重要。

减小 RetryInterval 如何影响吞吐量?如果当应用程序服务器线程忙于处理其他连接(其在重负载条件下发生)时,插件尝试连接到特殊应用程序服务器,则连接超时,而且插件将服务器标记为临时不可用。如果同一插件进程具有为同一服务器开放的其他连接,而且在这些连接之一上接收到响应,则再次标记服务器。然而,当您在 UNIX 操作系统上使用 IBM HTTP Server V6.0 时,不存在其他连接,因为每个插件进程仅存在一个线程和一个并发请求。因此,插件在尝试再次连接到服务器前,等待 RetryInterval。

因为应用程序服务器不是真的当机,而是很忙,则请求通常在很少的时间内完成。应用程序服务器线程变成可用于接受更多连接。大 RetryInterval 导致应用程序服务器标记为临时不可用,导致更多一致的应用程序服务器 CPU 利用率和更高的持续吞吐量。

注: 尽管减小 RetryInterval 可改进性能,但是如果所有应用程序服务器在运行中,则当某个应用程序服务器当机时,低值可具有方面影响。在这种情况下,每个 IBM HTTP Server V6.0 进程尝试连接并更频繁的失败,导致增加等待时间,并较少整个吞吐量。

阅读(4170) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~