WebLogic Server 性能及调优调优 WebLogic Server.docx

1、WebLogic Server 性能及调优调优 WebLogic ServerWebLogic Server 性能及调整 -调整 WebLogic Server以下部分描述如何调整 WebLogic Server 以满足应用程序需要。 设置启动 WebLogic Server 的 Java 参数 开发与生产模式的默认调整值 线程管理 调整网络 I/O 设置编译器选项 使用 WebLogic Server 群集提高性能 监视 WebLogic Server 域 设置启动 WebLogic Server 的 Java 参数无论何时启动 WebLogic Server，都必须指定 Java 参数。为

2、了便于调用，可以使用 weblogic.Server 命令从命令行完成这一操作。但是，因为从命令行启动 WebLogic Server 所需的参数可能非常冗长并且易于出错，所以 BEA 建议将此命令组合到脚本中。为简化这一过程，可以在启动 WebLogic Server 时 WebLogic 分发附带的示例脚步中修改默认值，如为 WebLogic Server 实例指定 Java 选项中所述。如果已使用配置向导创建域，则 WebLogic 启动脚本位于您指定域的 domain-name 目录中。默认情况下，此目录是 BEA_HOMEuser_projectsdomaindomain-name，

3、其中 BEA_HOME 是包含产品安装的目录，domain-name 是由选定配置模板定义的域目录的名称。有关使用 Configuration Wizard 创建域的详细信息，请参阅使用 Configuration Wizard 创建域。需要在这些脚本中修改某些默认 Java 值才能满足您的环境和应用程序的需要。这些文件中重要的性能调整参数是 JAVA_HOME 参数和 Java 堆大小参数： 将变量 JAVA_HOME 的值更改为 JDK 的位置。例如： set JAVA_HOME=C:beajdk150_03 为得到更高性能的吞吐量，可将最小 Java 堆大小设置成等于最大堆大小。例如：

4、%JAVA_HOME%binjava -server -Xms512m -Xmx512m -classpath %CLASSPATH% -有关设置堆大小选项的详细信息，请参阅指定堆大小值。 开发与生产模式的默认调整值可以指定在开发环境还是在生产环境中使用域。WebLogic Server 为各种服务使用不同的默认值，这取决于指定的环境类型。如下表所示，指定域的启动模式。表 6-1 启动模式选择此模式适用情况.开发模式适用于创建应用程序之时。在此模式中，安全性配置相对宽松，允许自动部署应用程序。生产模式适用于应用程序以最终形式运行之时。在此模式中，全面配置安全性。表 6-2 列出了从开发启动模式

5、切换为生产启动模式时与性能相关的不同配置参数。表 6-2 开发模式与生产模式之间的区别调整参数开发模式.生产模式.SSL可以使用 WebLogic Server 安全服务提供的示范数字证书和示范密钥库。利用这些证书，可设计出在由 SSL 担保的环境中工作的应用程序。有关管理安全的详细信息，请参阅“确保 WebLogic Server 安全”中的配置 SSL。不应使用示范数字证书和示范密钥库。如果这样做，将会显示警告消息。部署应用程序WebLogic Server 实例可以自动部署和更新驻留在 domain_name/autodeploy 目录中的应用程序（其中 domain_name 为域名）

6、。建议只在单服务器开发环境中使用此方法。有关详细信息，请参阅“将应用程序部署到 Weblogic Server”中的在开发域中自动部署应用程序。由于自动部署功能已禁用，因此必须使用 WebLogic Server 管理控制台、weblogic.Deployer 工具或 WebLogic 脚本工具 (WLST)。有关详细信息，请参阅将应用程序部署到 WebLogic Server。有关从开发到生产启动模式切换的信息，请参阅“管理控制台联机帮助”中的更改至生产模式。 线程管理WebLogic Server 提供下列机制管理执行工作的线程。 调整工作管理器 调整执行队列 了解工作管理器与执行队列之间

7、的区别 调整阻塞线程检测行为调整工作管理器在本版本中，WebLogic Server 允许配置应用程序优先执行其工作的方式。基于您定义的规则并通过监视实际的运行时性能，WebLogic Server 可以优化应用程序的性能并维护服务级协议 (SLA)。您可以调整服务器实例的线程利用率，方法是：通过定义工作管理器并将其全局应用到 WebLogic Server 域，或应用到特定的应用程序组件来定义应用程序规则和约束。主要调整注意事项： 需要多少个工作管理器？ 每个工作管理器的 SLA 要求是什么？请参阅“配置 WebLogic Server 环境”中的使用工作管理器优化调度的工作。需要多少个工作

8、管理器？每个不同的 SLA 要求都需要唯一的工作管理器。每个工作管理器的 SLA 要求是什么？服务级协议 (SLA) 要求是由请求类的实例定义的。请求类表达服务器实例用来分配线程的调度准则。请参阅“配置 WebLogic Server 环境”中的了解工作管理器。调整执行队列注意：在本版本的 WebLogic Server 中不赞成使用执行队列。BEA 建议迁移应用程序以使用工作管理器。在 WebLogic Server 的以前版本中，执行处理是在多个执行队列中进行的。根据优先级和顺序要求，不同类别的工作在不同的队列中执行以避免死锁。请参阅使用 WebLogic 8.1 线程缓冲池模型。了解工作

9、管理器与执行队列之间的区别从概念上直观区分以前版本的执行队列与工作管理器的最简单方法是，将执行队列（准确地说是执行队列管理器）与工作管理器关联，并消除执行队列和线程缓冲池之间的一一对应关系。对于 WebLogic Server 9.0 之前的版本，传入请求都放在默认执行队列或用户定义的执行队列中。每个执行队列都有一个相关联的执行队列管理器，该管理器控制着一个专有独占的线程缓冲池，其中包含固定数量的线程。基于先请求先服务原则向队列添加请求。然后，执行队列管理器从此队列中选取第一个请求，从相关联的线程缓冲池中选取可用的线程，并调度请求由该线程执行。对于 WebLogic Server 9.0 及更

10、高版本，在服务器中存在一个基于优先级的执行队列。根据管理由应用程序执行的工作而创建的工作管理器的配置，将分配给传入请求一个内部优先级。服务器将根据各种工作管理器的要求增加或减少执行队列可用的线程。请求在执行队列中的位置由其内部优先级确定： 优先级越高，位置越靠近执行队列的头。 越靠近队列的头，调度线程使用的请求也越快速。与使用执行队列相比，使用工作管理器能够更好的控制线程利用率（服务器性能），主要原因是可以为基于优先级的线程缓冲池指定调度准则的方法非常多。这些调度准则既可以根据数字值设置，也可以根据服务器管理的资源（如 JDBC 连接缓冲池）容量设置。从以前的版本迁移如果从包含执行队列的以前版

11、本升级应用程序域，则会使生成的 9.x 域包含执行队列。 从以前的版本将应用程序域迁移到 WebLogic Server 9.x 不会自动将执行队列转换为工作管理器。 如果在已升级的应用程序配置中存在执行队列，则服务器实例将把工作请求相应地分配给在 dispatch-policy 中指定的执行队列。 不带 dispatch-policy 的请求将使用自调整线程缓冲池。有关迁移域的详细信息，请参阅升级 WebLogic 应用程序域。调整阻塞线程检测行为WebLogic Server 自动检测执行队列中的线程发生“阻塞”的时间。因为阻塞的线程无法完成其当前工作或接受新工作，所以，服务器每次诊断阻塞

12、的线程时均会记录一条消息。如果线程在某一设定的时间段内连续工作（非空闲），WebLogic Server 会将其诊断为阻塞线程。通过更改线程被诊断为阻塞线程之前经过的时间长度，以及更改服务器检查阻塞线程的频率，可以调整服务器的线程检测行为。尽管可以更改 WebLogic Server 用来确定线程是否阻塞的条件，但是当在特定执行队列中的所有线程都阻塞时，就无法更改设置“警告”和“严重”运行状况的默认行为。有关详细信息，请参阅“配置 WebLogic Server 环境”中的配置 WebLogic Server 以避免超载情况。要配置阻塞线程检测行为，请参阅“管理控制台联机帮助”中的调整执行线程

13、检测行为。 调整网络 I/O以下部分提供了有关在客户端与服务器（包括 T3 和 IIOP 协议以及它们的安全版本）之间进行网络通信的信息： 调整 Muxer 哪个平台具有性能包？ 启用性能包 更改可用套接口读取器的数量 网络通道 调整消息大小 调整块参数 调整连接预备连接缓冲调整 MuxerWebLogic Server 使用称为 muxer 的软件模块读取服务器上的传入请求和客户端上的传入响应。这些 muxer 有两种主要类型：Java muxer 或本地 muxer。Java muxer 具有下列特征： 使用纯 Java 从套接口读取数据。 它也是 RMI 客户端唯一可用的 muxer。

14、在从套接口读取数据之前一直阻塞读取。当存在大量的套接口和/或极少有数据到达套接口时，此行为不能很好地调整。通常，这不是客户端的问题，但这种行为会给服务器造成巨大的瓶颈。本地 muxer 使用平台特定的本地二进制从套接口读取数据。绝大多数的平台都提供某些轮询套接口数据的机制。例如，Unix 系统使用轮询系统，而 Windows 体系结构则使用完成端口。本地提供超级可伸缩性，因为它们实现了无阻塞线程模型。使用本地 muxer 时，服务器将创建固定数量、专用于读取传入请求的线程。BEA 建议使用为 Enable Native IO 参数选定的默认设置，该参数允许服务器自动选择适用于该服务器使用的 m

15、uxer。如果未选定 Enable Native IO 参数，服务器实例将只使用 Java muxer。如果客户端较少并且请求达到服务器的频率相当高，则可以接受这种情况。在这些条件下，Java muxer 与本地 muxer 执行得一样好，并且消除了 Java 本地接口 (JNI) 的开销。与本地 muxer 不同，Java muxer 用来读取请求的线程数不固定，并且通过配置管理控制台中的 Percent Socket Readers 参数设置，还可以调整线程数。请参阅更改可用套接口读取器的数量。理想情况下，应该配置这一参数，以使线程数近似等于远程并发连接的客户端数（最多为线程缓冲池总大小的

16、 50%）。每个线程都等待一段固定的时间以便数据在套接口变得可用。如果没有数据到达，则线程移动到下一个套接口。哪个平台具有性能包？在承载 WebLogic Server 实例的计算机上使用本地性能包时，基准点可显示主要的性能改进。性能包使用平台优化的本地套接口多路传输器提高服务器性能。例如，本地的套接口读取器多路传输器线程有其自己的执行队列，不用从默认执行队列借用线程，这样可释放默认执行线程以执行应用程序工作。要查看当前哪些平台具有性能包，请执行下列操作：1 转至 Certifications Pages。1 从已认证平台列表中选择您的平台。1 使用浏览器的“编辑”“查找”查找所有的“性能包”

17、实例，以验证此平台中是否包含性能包。启用性能包默认情况下，在分发附带的配置中，本地性能包的使用处于启用状态。可以使用管理控制台验证性能包是否已启用。请参阅“管理控制台联机帮助”中的启用本地 IO。更改可用套接口读取器的数量如果主机必须使用纯 Java 套接口读取器实现，则可以通过为每个服务器实例和客户端计算机配置正确的套接口读取器线程数，提高套接口通信的性能。请参阅“管理控制台联机帮助”中的调整可用套接口读取器的数目。网络通道网络通道也称为网络访问点，使用它可以为网络通信指定不同的服务质量 (QOS) 参数。每个网络通道都与其自己的使用唯一 IP 地址和端口的专用套接口关联。默认情况下，通过同

18、一个远程连接多路传输来自多线程客户端的请求，并且服务器实例一次只能从套接口读取一个请求。如果请求大小太大，这将成为一个瓶颈。尽管网络通道的主要角色是控制服务器实例的网络流量，但是可以利用这种能力创建多个自定义通道，以允许多线程客户端通过多个连接与服务器实例通信，从而减少潜在的瓶颈。要配置自定义多通道通信，请执行下列操作：1 使用不同的 IP 和端口设置配置多个网络通道。请参阅“管理控制台联机帮助”中的配置自定义网络通道。1 在客户端代码中，使用 JNDI URL 模式，该模式类似于群集环境中所用的那种模式。下面是一个使用两个网络通道的客户端示例： t3:/:,:请参阅“配置 WebLogic

19、Server 环境”中的了解网络通道。调整消息大小WebLogic Server 允许指定最大传入请求大小，这样可阻止服务器免遭一系列较大请求的轰炸，从而降低了潜在的拒绝服务 (DoS) 攻击。可以设置全局值，或者为不同协议和网络通道设置特定值。尽管这不直接影响性能，但 JMS 应用程序在发送到目标之前会聚合消息，如果聚合的消息大于指定值，则可能会拒绝该应用程序。请参阅“管理控制台联机帮助”中的服务器: 协议: 常规和使用顺序单元调整应用程序。调整块参数块是客户端和服务器端上的 WebLogic Server 网络层用来从中读取数据并将数据写入套接口的内存单元。为降低内存分配成本，服务器实例会

20、为这些块维护一个缓冲池。对于处理每个请求含有大量数据的应用程序，在客户端和服务器上增大该值可以提高性能。默认块大小约为 4K。使用下列属性可调整块大小和块缓冲池大小： weblogic.Chunksize- 设置块的大小（字节）。该属性可能需要增加的主要情形是在请求大小较大时。该属性应设置成网络最大传输单元 (MTU) 减去任何 Ethernet 或 TCP 头值大小所得结果的倍数。在客户端和服务器上将些参数设置成相同的值。 weblogic.utils.io.chunkpoolsize- 设置块缓冲池的最大大小。默认值是 2048。如果服务器在稳定状态下开始分配和放弃块，则此值可能需要增大。

21、要确定是否需要增加此值，可监视 CPU 配置文件或使用调用构造方法 weblogic.utils.io.Chunk 的调用堆栈的内存/堆配置文件。 weblogic.PartitionSize- 设置使用的缓冲池分区数目（默认值是 4）。块缓冲池可以是重要锁定争用的来源，因为每个访问缓冲池的请求必须同步。分区线程缓冲池与一个分区相比，扩大了潜在的争用。调整连接预备连接缓冲可以调整 WebLogic Server 实例在拒绝其他请求之前可以接受的连接请求数。Accept Backlog 参数指定在等待队列中可以缓冲的传输控制协议 (TCP) 连接。此固定大小的队列由 TCP 堆站已接收到而应用程

22、序尚未接收到的连接请求进行填充。有关 TCP 调整的详细信息，请参阅基本 OS 调整概念。可以调整 WebLogic Server 实例在拒绝其他请求之前可以接收的连接请求数，请参阅“管理控制台联机帮助”中的调整预备连接缓冲。 设置编译器选项可以通过调整服务器编译器的选项来提高性能。编译 EJB 类使用 weblogic.appc 实用工具编译 EJB 容器类。如果编译要部署到 EJB 容器的 Jar 文件，则必须使用 weblogic.appc 来生成容器类。默认情况下，ejbc 使用 javac 编译器。通过使用 -compiler 标志或使用管理控制台来指定另一个编译器（比如 IBM J

23、ikes），可以提高性能。有关详细信息，请参阅： “WebLogic EJB 编程”中的实现 Enterprise Java Bean。 “管理控制台联机帮助”中的配置编译器选项。设置 JSP 编译器选项WebLogic Server 使用 Javelin 来编译 JSP。在 weblogic.xml 文件中，jsp-descriptor 元素定义 servlet JSP 的参数名和值。使用 precompile 参数来配置 WebLogic Server，以便在 WebLogic Server 启动时预编译 JSP。请参阅 jsp-descriptor 元素。如果在 UNIX 计算机上编译

24、JSP 文件时收到下列错误消息：failed: java.io.IOException: Not enough space请尝试下列任何一个或全部解决方案： 添加更多的 RAM（如果仅有 256 MB）。 提高文件描述符限制，例如： set rlim_fd_max = 4096set rlim_fd_cur = 1024 使用 WebLogic Server 群集提高性能WebLogic Server 群集是一组 WebLogic Server 实例，这组实例共同提供故障转移和复制服务，以支持域中客户端的可伸缩、高可用性操作。从客户端看来，群集好像是一个服务器，但实现上是一组服务器充当一个服务

25、器以提供增强的可伸缩性和可靠性。一个域可以包含多个 WebLogic Server 群集和非群集的 WebLogic Server 实例。域中群集的 WebLogic Server 实例除提供故障转移和负载平衡外，其他行为与非群集的实例相同。无论群集还是非群集实例，其配置参数都是由域的管理服务器管理的。有关群集的详细信息，请参阅了解 WebLogic Server 群集。可伸缩性和高可用性可伸缩性是指随着更多的资源添加到系统，系统在一个维度或多个维度进一步扩展的能力。通常，这些维度包括（但不限于）可支持的并发用户数和可在给定时间单元内处理的事务数。对于设计良好的应用程序，完全可以通过简单添加更

26、多的资源来提高性能。为了提高 WebLogic Server 的负载处理能力，可将其他 WebLogic Server 实例添加到群集中 - 无需更改您的应用程序。群集可提供一个服务器无法提供的两个关键优势是：可伸缩性和可用性。WebLogic Server 群集以一种对应用程序开发人员透明的方法为 Java EE 应用程序带来了可伸缩性和高可用性。可伸缩性扩展了中层的容量，这是一个 WebLogic Server 或一台计算机无法做到的。群集成员资格的唯一限制是所有 WebLogic Server 都必须能够通过 IP 多播进行通信。可以动态地向群集添加新的 WebLogic Server

27、以增加其容量。WebLogic Server 群集通过使用多台服务器冗余消除客户端故障保证了高可用性。同一个服务可由群集中多个服务器提供。当一个服务器出现故障时，另一个服务器便可以接管其工作。让功能正常的服务器接管出现故障的服务器能够提高应用程序对客户端的可用性。警告：若您已解决所有应用程序和环境瓶颈问题，向群集添加其他服务器应提供线性可伸缩性。执行基准点或初始配置测试时，要先将问题隔离到单个服务器环境，然后才移动到群集环境中。消息传递服务中的群集由分布式目标、连接集中器、连接负载平衡（由连接工厂目标决定）和群集存储转发 (SAF) 提供。与分布式目标有关的客户端负载平衡可在连接工厂进行调整。

28、定位到同一群集（承载分布式目标）的分布式目标消息驱动 Bean（MDB）只能自动部署在承载分布式目标成员的群集服务器上，并且只能从其本地目标处理消息。定位到不同服务器或群集（承载分布式目标）的分布式队列 MDB 为每一个分布式目标成员自动创建使用者。例如，每个运行的 MDB 都有一个针对每个分布式目标队列成员的使用者。如何确保 WebLogic 群集的可伸缩性通常，任何要求在群集中的服务器之间进行通信的操作都是潜在的可伸缩性障碍。以下部分提供了有关影响线性调整群集 WebLogic 服务器能力问题的信息： 数据库瓶颈 会话复制 实体 EJB 的失效 HTTP 会话的失效 JNDI 绑定、取消绑

29、定和重新绑定数据库瓶颈在 WebLogic 服务器的群集无法扩展的许多情况下，数据库是一个瓶颈。在这种情况下，唯一的解决方案是调整数据库，或者利用其他选项降低数据库的负载。请参阅数据库调整和调整 JDBC 应用程序。会话复制可以通过两种标准方法在 Java EE 应用程序中存储用户会话数据：有状态的会话 EJB 或 HTTP 会话。这些会话本身极少影响群集的可伸缩性。但是，当与提供高可用性所需的会话复制机制联系在一起时，就会引入瓶颈。如果 Java EE 应用程序具有 Web 和 EJB 组件，您应当使用 HTTP 会话存储用户会话数据： HTTP 会话管理为处理故障转移提供了更多的选项，如复

30、制、共享数据库或文件。 超级可伸缩性。 HTTP 会话状态的复制出现在任何事务的外部。有状态会话 Bean 复制出现在更多资源密集的事务中。 与有状态会话 Bean 复制相比，HTTP 会话复制机制更加复杂，并且提供了对范围更广的各种情形的优化。请参阅会话管理。实体 EJB 的失效这应用到使用 Optimistic 并发战略的，或具有读写模式的 ReadOnly 的并发策略的实体 EJB。Optimistic - 当更新 Optimistic 并发 Bean 时，EJB 容器将向其他群集成员发送多播消息，以使其 Bean 本地副本失效。这样做可避免由其他服务器引发的优化并发异常和重试事务的需要

31、。如果经常更新 EJB，则由服务器完成以便使每个其他本地缓冲失效的这一工作将成为一个严重的瓶颈。称为 cluster-invalidation-disabled（默认值为 false）的标志用于关闭这种失效。这在 rdbms 描述符文件中进行设置。具有读写模式的 ReadOnly - 在这种模式中，通过一个 EJB 表示的持久性数据实际上由两个 EJB 表示：一个只读的和一个可更新的 EJB。当可更新 Bean 的状态更改时，容器自动使相应的只读 EJB 实例失效。如果经常更新 EJB，则由服务器完成以便使只读 EJB 失效这一工作将成为一个严重的瓶颈。HTTP 会话的失效与实体 EJB 的失效类似，HTTP 会话也可以失效。与实体 EJB 失效相比，此会话失效成本不大，因为只有存储在次级服务器上的会话数据需要失效。BEA 建议用户仅当绝对必要时才让会话失效。JNDI 绑定、取消绑定和重新绑定通常，JNDI 绑定、取消绑定和重新绑定都是成本很高的操作。但是，这些操作在群集环境中成了一个更大的瓶颈，因为 JNDI 树更改必须传播到群集中的所有成员。如果这些操作执行太频繁，则它们会大大降低群集的可伸缩性。在多 CPU 计算机上运行多个服务