在 WebSphere Service Registry and Repository 中提升性能

将 Web 服务元数据提升到不同的测试环境和生产环境,这是 Service Registry and Repository(以下简称 WSRR)的一个重要特性。对于大型服务集或非常大的服务,由 WSRR 在内部执行的流程可能非常广泛,而且可能会导致提升时间较慢。本文提供的指南可帮助您尽可能快速高效地完成此过程。这些指南涵盖 WSRR 的配置、与之关联的数据库服务器(本文使用 DB2),以及它们之间的网络。

Jerry Stevens, 软件开发人员,Service Registry 团队, IBM

Jerry Stevens 是位于英国 Hursley 市的 IBM 软件实验室的软件开发人员,他在 Service Registry 团队工作。他于 1997 作为 IBM AIX 顾问加入 IBM UK Global Services,并于 2001 年调动到 Hursley 实验室从事 WebSphere MQ 的性能分析和软件开发,在 2009 年又调动到 Service Registry 团队。在加入 IBM 之前 Jerry 是壳牌石油公司的高级系统工程师,职务是技术顾问和软件开发,经常和各种开放系统平台和架构打交道。它毕业于 Exeter University 并取得数学学位。



2012 年 12 月 24 日

简介

IBM® WebSphere® Service Registry and Repository(以下简称 WSRR)让您可以区分组织内不同的运行时环境,并为这些不同的目标运行时环境保持适当的 Web 服务和元数据。例如,构建和开发 Web 服务时可以使用一个注册表,而在内部测试这些 Web 服务时可以使用另一个注册表,当将服务部署到生产中并由客户使用时,则可以使用第三个注册表。服务在其中被首次发现、开发和治理的注册表称为治理 注册表。最终生产版本的服务被部署到的注册表称为运行时 注册表,而用于测试的任何临时注册表均称为 staging(临时)注册表。

为了从本文中有所收获,您应该具备 WSRR 的应用知识。如果您想在继续之前了解有关 WSRR 的更多信息,请参阅 WSRR 信息门户WebSphere Service Registry and Repository 开发人员资源页面

WSRR 针对将服务数据和元数据从治理注册表传播到不同的目标运行时注册表所提供的这个机制,称为提升,这是 WSRR 的一个完善的特性。数据始终从治理注册表被提升到每个运行时注册表,而不是从运行时注册表到运行时注册表,如下图所示:

图 1. 提升概述
提升概述

治理、临时和生产注册表的拓扑结构是完全可以在 WSRR 配置的配置文件中进行配置的。什么是最合适的样式,这将取决于您的特定环境。Governance Enablement Profile (GEP) 提供了一个参考配置文件,您可以根据需要对其进行调整。有关目标注册表环境的更多信息,请参阅 IBM developerWorks 文章 WebSphere Service Registry and Repository 拓扑结构简介

同步和手动提升

异步提升 是 WSRR 历来都提供的第三个提升选项。它使您能够使用预定任务来进行设置,让提升发生在一个特定的日期和时间。本文没有介绍异步提升,因为它已被手动提升淘汰。

针对将提升的数据交付​​到目标注册表,WSRR 提供了两种不同的选择:

同步提升 是指 WSRR 自动填充目标运行时注册表。在这种情况下,一旦触发目标对象的提升,该对象以及与之相关的所有其他对象都会被填充到运行时。在提升过程中如果有任何错误,那么,目标对象将不会转换到提升的状态。

手动提升 包括触发目标对象的提升,这会导致在托管治理注册表的系统上创建一个 zip 文件。该文件包含了提升对象和与之相关的所有其他对象的详细信息。在提升属性中可以配置这个 zip 文件的位置和名称。只要创建了这个 zip 文件,治理注册表上的目标对象就会转换到提升的状态。然而,只有当 zip 文件已被手动复制到运行时注册表,然后通过 WSRR UI 导入时,目标运行时上的提升才能完成。

有关如何使用 GEP 提升简单服务的更多信息,请参阅 WSRR 信息中心的 GEP 教程

准备 WSRR 提升

将 WSDL 和 XML 模式加载到 WSRR 时,将会从这些模式中获取多个逻辑对象,包括 Port Types(端口类型)、Service Bindings(服务绑定)和 Service Interfaces(服务接口)。在这个过程中也创建了许多其他相关的对象,并用来组织各种逻辑对象。例如,ServicePort 相关对象将 WSDLPort 连接到派生出该端口的服务的名称、命名空间和版本。

您可以看到,决定其提升的复杂程度的并不是被加载的 WSDL 文件的大小,而是有多少对象依赖于被提升的对象。例如,当一个简单的 WSDL 被加载时,它可能会产生 60 个依赖对象,然而一个非常复杂的 WSDL 则可能会产生超过 40,000 个依赖对象。

为了提升 WSDL,您应该用 Service Version(服务版本)对象管理它,如 WSRR 信息中心的 为服务注册 WSDL 所述。Service Version 在一个受管的集合中封装了与服务相关的所有信息,该集合表示服务的一个已定义版本。与 Service Version 关联的集合包括 Service Level Definition(服务水平定义)以及任何 Service Level Agreements(服务水平协议)等信息。

触发提升

可以通过在您的配置文件中定义不同的生命周期状态来对 Service Version 对象进行管理。将 Service Version 转换到在 WSRR 提升属性配置中定义的某个特定生命周期状态,可以触发提升。例如,此提升点可能是 ApproveForStagingDeployment 转换。

提升属性配置 指定了提升的详细信息,例如,它是手动还是同步的,如果是同步的,数据将会提升到哪个系统。当提升完成时,由 Service Version 管理的多个对象将被填充到目标运行时注册表,如下图所示:

图 2. 提升过程
提升过程

提升的性能考虑因素

与迁移一样,提升也是资源最密集的 WSRR 操作之一,可能会对以下组件产生大量负载:

  • WSRR 治理和运行时服务器
  • WSRR 治理和运行时数据库
  • WSRR 及其数据库服务器之间的网络

如果您希望经常提升或重新提升数据,那么这些方面都应尽可能高效。从提升的角度来优化它们也将提高整体的 WSRR 性能。本文的其余部分将涵盖这三个方面。

WSRR 治理和运行时服务器

有许多因素可以提高 WSRR 治理和运行时服务器上的提升性能。有些因素适用于治理注册表,有些适用于运行时注册表,还有一些两种注册表都适用。下面的章节介绍了这些因素。

优化的同步和手动提升(治理服务器)

在 WSRR V8.0 之前,同步和手动提升在提升的导出和导入阶段使用的都是临时数据库。从 WSRR V8.0 起,同步提升过程中已删除了此临时数据库,效率提高了不少。从 WSRR V8.0.0.1 开始,这种效率提高也被提供为手动提升的一个选项。

这项新技术极大地改善了提升时间。例如,一个测试表明了同步提升时间有 85% 的改善。实际性能提高会有所不同,具体取决于 WSRR 数据的性质。从 WSRR V8.0 开始,这个经过优化的新同步提升取代了临时数据库传输。另一方面,优化的手动提升继 V8.0 之后通过 Fix Packs 提供,因此,在手动提升过程中不会取代临时数据库的默认使用,而是将它作为一个可用选项。

在早期版本的 WSRR 上,优化的同步和手动提升通过产品更新提供。这些早期版本的转出摘要如下面的图 4 所示。对于这些早期版本,优化的提升不会在产品升级后成为默认配置,但可以在提升属性配置中用一个新的提升类型选项指定。对于同步提升,其选项是 sync-optimized,对于手动提升,其选项是 manual-optimized。下面是一个如何在提升属性配置中指定同步优化提升的示例:

在提升属性配置中指定同步优化提升
<environments>
   <environment name=
    "http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Staging">
   <promotion>                                                 
      <type>sync-optimized</type>
   </promotion>
  <servers>
      <server name="fred.bloggs.com" port="2809"/>
   </servers>
   <security enabled="true">
      <wsrrUser>aWsrrUser</wsrrUser>
      <wsrrPassword>(DES)xxxxxxx==</wsrrPassword>
   </security>
   </environment>
. . . 
</environments>

若要在这些更新版本的 V6.3 到 V7.5 中恢复到原来的提升方法,只需将提升类型修改回 sync 即可。需要注意的是:

  • 在 V8 中,无论是将提升类型指定为 sync 还是 sync-optimized,同步提升都是经过优化的。
  • 在 V8.0.0.1 中,手动提升默认为基于 Derby 数据库的提升,但您可以在提升属性中将提升类型指定为 manual-optimized,从而将它更改为优化的提升。
  • 在 WSRR V6.2 或更早的版本中没有提供 sync-optimized 选项,并且目前也没有计划要提供它。
  • 在 WSRR V6.3 或更早的版本中没有提供 manual-optimized 选项,并且目前也没有计划要提供它。

最小的同步和手动提升(治理服务器)

除了优化的提升,在 WSRR V8.0.0.1 中引入了被称为最小提升的另一种新提升类型。当被提升的治理集合中包含支持对象 时,最小提升可能会更有效,支持对象是与被提升的集合中某个对象关联的对象,但它实际上并不是该集合中的成员。在最小提升的过程中,支持对象被标记为属于一个治理集合,因此它的治理状态不能更改,也不会被纳入在运行时系统上与其相关的其他治理集合。图 3 显示了 xsd 支持对象已被提升,但它所属的治理集合的其余成员没有被提升:

图 3. 最小提升
最小提升

如果支持对象的原始治理集合刚好在稍后的日期被提升,在运行时上的现有对象就将被自动重新纳入其治理集合。当提升其治理集合时,标记的对象就会被传入的版本替换,并且只是重新变成一个普通的接受治理的对象。

在使用 WSRR V8.0.0.1 时,如果指定了最小提升,提升也会被优化,这是因为从 WSRR V8.0 开始,使用临时数据库的旧提升样式已被删除。对于 V8.0.0.1,以下是手动和同步提升的选项:

  • sync -- 没有临时数据库的优化提升。在 V8 中,它也可以被指定为 sync-optimized
  • sync-minimal 或 sync-optimized minimal -- 已被最小化的优化提升
  • manual -- 使用临时数据库的手动提升
  • manual-minimal -- 使用临时数据库并且被最小化的手动提升
  • manual-optimized -- 优化的手动提升
  • manual-optimized-minimal -- 已被最小化的优化手动提升

在早期版本的 WSRR 上,通过产品更新也提供最小同步和手动提升。这些早期版本的转出的详细摘要如图 4 所示。

对于应用了相关补丁包的 WSRR V7.0 和 V7.5,上述同步提升类型略有不同,这是因为它们仍然保留了使用临时数据库的原始提升选项:

  • sync -- 使用临时数据库的同步提升
  • sync-minimal -- 使用临时数据库并且被最小化的同步提升
  • sync-optimized -- 没有临时数据库的同步提升(比 sync 快得多)
  • sync-optimized-minimal -- 没有临时数据库并且被最小化的同步提升

最小提升的收益取决于对独立治理的集合的依赖关系的性质。

优化和最小提升的转出

下表总结了优化和最小提升的转出,以及在哪个版本的 WSRR 中提供了哪些选项:

图 4. 优化和最小提升的转出
优化和最小提升的转出

优化和最小提升的选项建议

优化提升将提高所有提升的性能,因此,强烈建议您尽可能使用它。因此,针对 WSRR V8 所建议的提升类型是 sync 和 manual-optimized。您也可以选择最小化这些提升,只需将提升类型指定为 sync-minimal 或 manual-optimized-minimal 即可。

对于 WSRR V7.0 和 V7.5,建议的提升类型是 sync-optimized 和 manual-optimized。您也可以选择最小化这些提升,只需将提升类型指定为 sync-optimized-minimal 或 manual-optimized-minimal 即可。

由最小提升提供的增强取决于被提升数据内的依赖关系,以及进行治理集合的数据的组织。如果提升需要很长的时间,或者您看到的对象比预期要提升的更多,那么最小提升可能会减少被提升的数据量。在运行的时候启用最小提升是没有问题的,但只有当被提升的对象涉及在其他治理集合中的支持对象时才可以体现所带来的好处,而这可能又依赖于更多治理集合。

使用 64 位 WebSphere Application Server(治理和运行时服务器)

强烈建议在非测试环境中使用 64 位应用程序服务器,这是因为应用程序服务器的可用内存可以增加至超过 32 位服务器的 1560 MB 限制。对于较小的注册表,您可能不需要超过此限制,但是若从一开始就采用 64 位的服务器,将来有需要时对 WebSphere Application Server JVM 配置更多内存就会更容易。

增加 WebSphere Application Server JVM 的限制(治理和运行时服务器)

在安装 WSRR 时,WebSphere Application Server JVM 的内存限制被设置为 1024 MB。对于大型服务的提升,这个限制可能过低,并会影响性能。因此,建议检查此内存有多少被 WebSphere Application Server 使用。例如,在 AIX 机器上,您可以使用下面的命令:

在 AIX 上检查 WebSphere Application Server 正在使用的内存量
# svmon -P <pid> -O summary=basic,unit=MB
Unit: MB
-------------------------------------------------------------------------------
     Pid Command          Inuse      Pin     Pgsp  Virtual
  598240 java           2445.38     32.3        0  2207.06
#

其中 pid 是 WebSphere Application Server 进程的进程 ID。在这个示例中,该进程使用了 2445 MB 的内存。

如果所使用的内存接近或大于 JVM 的限制,则应增加 JVM 的上限(这需要重新启动服务器)。有关更多信息,请参阅 WebSphere Application Server 信息中心的 Tuning the IBM virtual machine for Java。当更改 JVM 的上限时,有一条很好的规则,就是同时更改初始 JVM 限制,让它等于新上限的 25%。虽然从提升的角度来看,在治理计算机上对内存的要求通常会更高,但是您也应该检查治理和运行时注册表的设置。

超时设置(治理服务器)

大量数据的提升有时会失败,这是因为超出了默认的超时限制。为了使提升过程尽可能顺利,建议在尝试提升之前先检查以下超时值,并在有需要时增大它们:

  • Transaction Service 事务生存期总超时(默认为 120 秒)
  • Transaction Service 事务的最大超时(默认为 300 秒)
  • ORB service Request 超时(默认为 180 秒)

WSRR 信息中心建议将事务生存期的总超时增加至 1200 秒,而事务最大超时增加至 3000 秒。对于大型提升,这些值可能仍然不够,并且可能需要再进一步增大。在 WSRR 和 WebSphere Application Server 信息中心提供了有关避免超时的更多信息:

如果通过 Web 服务客户端应用程序使用提升,那么也应该检查 WebSphere Application Server 客户端超时。在客户端命令行将 Java 属性 com.ibm.websphere.webservices.http.SocketTimeout 设置为所需的超时值(以秒为单位)。以下是一个示例,在运行 Java 应用程序 MyTester 时此超时值设置为 60 分钟:

在 Web 服务客户端应用程序上设置超时
java -Dcom.ibm.websphere.webservices.http.SocketTimeout=3600 MyTester.Main

计划任务(治理和运行时服务器)

如果 WSRR 计划任务碰巧与提升同时运行,那么它们可能对提升性能产生影响。尤其是以下任务有可能产生影响:

  • Text search Scheduler
  • CleanseDatabase Scheduler
  • Subscription Notifier Plug-in Scheduler
  • AnalyticsDatabase Scheduler

如果您认为提升可能是资源密集型的,那么请确保它不会与这些计划任务同时发生。要做到这一点,请确保:WSRR 管理员使用 cron 日历格式(而不是时间间隔的格式)来计划任务的运行。cron 格式指定任务将运行的精确时间,而时间间隔格式将一个任务配置为在最后一次任务调用后的指定时间(或当重置时间间隔参数)时运行。cron 格式可以更容易说明计划任务的运行时间。

禁用修饰符和验证程序(运行时服务器)

在运行时服务器上,没有必要运行验证,这是因为数据在治理服务器上已经过验证。因此,您可以在运行时注册表上禁用所有验证程序,或至少在提升之前禁用它们,之后再重新启用它们。

同样,也不需要使用修饰符,这是因为已经在治理服务器上创建了关联的对象。所以,您也可以在提升过程中禁用这些修饰符。如果提升是由最终用户触发的,那么更改这两个设置将需要 WSRR 管理员的协助。

禁用活动日志记录(运行时服务器)

在运行时服务器上禁用活动日志记录(至少在提升过程中禁用)将提高提升性能。但是,不要在治理服务器上禁用活动日志记录。

提高提升性能的其他技巧(治理和运行时服务器)

  • 确保 WebSphere Application Server 消息传送引擎在运行。如果已经跨数据库移动了 WSRR 数据,WSRR 消息传送引擎则有可能不能正常启动,这会影响性能,尤其是在使用 JMS 通知的时候。
  • 如果您在使用 IBM Java SDK V6 SR6 或更早的版本,将 JVM 的页面大小更改为 64K 可能会有好处。要做到这一点,从 WebSphere Administrative Console 中指定 JVM 泛型参数中的选项 Xlp64k
  • 禁用跟踪 - 跟踪的开销可能非常大,所以在不需要时应该始终关闭跟踪。

将垃圾回收算法更改为使用换代版本 (gencon) 对于提升没有多大的好处,所以建议保留此设置的默认值。

WSRR 治理和运行时服务器

数据库组织和调优的完整处理已超出本文的范围,但是有几个因素可以大幅提高 WSRR 提升性能。

检查数据库的补丁包级别

重要的是要确保您有最新的 DB2 补丁包,因为在 V9.7.0.5 之前的 DB2 版本上加载较大的 WSDL 文件时会出现问题。要检查自己是否在使用最新的 DB2 补丁包,请参阅 Table of DB2 fix packs

检查 JDBC 驱动程序是否最新

确保在 WSRR 服务器上的数据库 JDBC 驱动程序是最新的。可以从数据库服务器上的 DB2 产品安装 root 目录下的 java 目录将驱动程序复制到 WSRR 服务器的配置目录。

建议的 WSRR 数据库设置

很容易被忽略的一个步骤是设置 WSRR 信息中心建议的数据库选项。例如,对于 DB2,确保设置了 DB2_SKIPINSERTED 和 DB2_SKIPDELETED。您可以使用 db2set 命令检查这些设置。例如,对于 DB2 V9.7,DB2_SKIPINSERTED 和 DB2_SKIPDELETED 都应该是 OFF:

db2set 命令的输出
db2set
DB2_CREATE_DB_ON_PATH=YES
DB2_SKIPINSERTED=OFF
DB2_INLIST_TO_NLJN=YES
DB2_SKIPDELETED=OFF
DB2PROCESSORS=0,1
DB2INSTOWNER=SRPERFC
DB2PORTRANGE=60000:60003
DB2INSTPROF=C:\PROGRAMDATA\IBM\DB2\DB2COPY1
DB2COMM=TCPIP

对于 DB2 V9.7,检查当前提交的配置参数是否设置为 ON,这也很重要。使用下面的命令:

启用 cur_commit
db2 update db cfg using cur_commit ON

在 Windows 上检查该参数的设置:

在 Windows 上验证 cur_commit 设置
db2 get db cfg for WSRR80 | find /I "cur_commit"
 Currently Committed                        (CUR_COMMIT) = ON

在 Linux 和 Unix 上,使用 grep 命令而不是 find:

在 Linux 和 Unix 上验证 cur_commit 设置
$ db2 get db cfg for WSRRTEST | grep -i cur_commit
 Currently Committed                        (CUR_COMMIT) = ON

在 Windows 上确保 DB2PROCESSORS 注册表变量的设置正确

在 Windows 数据库平台上,请检查您是否配置了正确数量的系统处理器供 DB2 使用。安装 DB2 之后,可能每个系统只有两个核心可供 DB2 使用。举例来说,如果您有一个 8 核系统,DB2 将只使用 25% 的可用处理能力。使用 db2set 命令设置 DB2PROCESSORS。例如,在一个专用于 DB2 数据库的 8 核系统上,您可能会决定在所有 8 个核心上都允许 DB2 进行处理:

设置 DB2PROCESSORS 注册表变量(仅适用于 Windows)
db2set DB2PROCESSORS=8

重启 DB2 让更改生效。在增大 DB2PROCESSORS 的值之前应确保您的 DB2 许可覆盖您想专用于 DB2 的处理器数量。

在 Linux 和 Unix 上的 Ulimit 设置

如果您正在 Linux 或 Unix 服务器上运行数据库,请检查是否已适当设置数据库用户的默认 ulimit 设置。数据库所有者的默认 ulimit 设置可能会严重影响数据库的性能。如果服务器专用于单一数据库实例,那么将数据、堆栈和内存设置值尽可能调高。例如:

在 Linux 和 Unix 上检查 ulimit 设置
$ ulimit -a
time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         unlimited
stack(kbytes)        4194304
memory(kbytes)       unlimited
coredump(blocks)     unlimited
nofiles(descriptors) 2000
$

使用 DB2 RUNSTATS

在加载、更改或删除适量数据后定期执行 RUNSTATS 命令。第一次创建数据库时,在加载配置文件后立即使用 RUNSTATS。如果您不这样做,DB2 一般不使用索引来访问数据库中的数据,这很可能会降低性能。有关更多信息,请参阅 WSRR 信息中心的 RUNSTATS 命令

以固定间隔重新执行 RUNSTATS,特别是在向数据库添加或从数据库中删除中到大量的数据之后。这样做有助于确保该数据访问继续得到优化。您可以从 DB2 命令行或通过 API 调用来调用 RUNSTATS。如果您以编程方式调用 RUNSTATS,请不要操作得太频繁。例如,如果您在加载一系列 WSDL 文件时反复执行,就会减慢性能。调用 RUNSTATS 的最佳时间是在加载或删除一批数据之后。对于提升,重要的是,无论是治理数据库还是运行时数据库都要定期执行 RUNSTATS,如果运行时数据库是新的,它也应该在加载配置文件后立即执行 RUNSTATS。

针对不同的 WSRR 版本推荐使用不同的 RUNSTATS 命令。在 WSRR 信息中心查看这些命令,在从一个版本迁移到另一个版本时尤其应该这样做:

使用 DB2 REORG

建议您经常在表和索引上运行 DB2 REORG 命令,这样可以帮助减少碎片。不需要像 RUNSTATS 那样频繁运行该命令,但最好在大量数据被添加到数据库或从数据库中删除时运行它。否则数据库插入将在可用的地方使用空的空间,这可能与表中的相关数据在物理上并不接近。

DB2 REORGCHK 命令也可以帮助您确定 REORG 命令是否可能带来好处。在关键的 WSRR V6.3、V7.0、V7.5 和 V8.0 数据库表上执行 REORG 的命令如下所示。使用您的实际 WSRR 模式名称替换 <schema>:

WSRR V6.3 DB2 数据库的 Reorg 命令
db2 connect to <database>
db2 reorg table <schema>.w_statement 
db2 reorg table <schema>.w_uri 
db2 reorg table <schema>.w_obj_lit_plain 

db2 reorg indexes all for table <schema>.w_statement
db2 reorg indexes all for table <schema>.w_uri
db2 reorg indexes all for table <schema>.w_obj_lit_plain 
db2 terminate
WSRR V7.0 DB2 数据库的 Reorg 命令
db2 connect to <database>
db2 reorg table <schema>.w_dbversion
db2 reorg table <schema>.w_artifact_blob
db2 reorg table <schema>.w_statement
db2 reorg table <schema>.w_uri
db2 reorg table <schema>.w_obj_lit_plain
db2 reorg table <schema>.w_mod_lock
db2 reorg table <schema>.w_schema_rev
db2 reorg table <schema>.w_obj_lit_any
db2 reorg table <schema>.w_lit_float
db2 reorg table <schema>.w_lit_double

db2 reorg indexes all for table <schema>.w_dbversion
db2 reorg indexes all for table <schema>.w_artifact_blob
db2 reorg indexes all for table <schema>.w_statement
db2 reorg indexes all for table <schema>.w_uri
db2 reorg indexes all for table <schema>.w_obj_lit_plain
db2 reorg indexes all for table <schema>.w_mod_lock
db2 reorg indexes all for table <schema>.w_schema_rev
db2 reorg indexes all for table <schema>.w_obj_lit_any
db2 reorg indexes all for table <schema>.w_lit_float
db2 reorg indexes all for table <schema>.w_lit_double
db2 terminate
WSRR V7.5 和 V8.0 DB2 数据库的 Reorg 命令
db2 connect to <database>
db2 reorg table <schema>.statement
db2 reorg table <schema>.subject
db2 reorg table <schema>.predicate
db2 reorg table <schema>.object
db2 reorg table <schema>.graph
db2 reorg table <schema>.blobdata

db2 reorg indexes all for table <schema>.statement
db2 reorg indexes all for table <schema>.subject
db2 reorg indexes all for table <schema>.predicate
db2 reorg indexes all for table <schema>.object
db2 reorg indexes all for table <schema>.graph
db2 reorg indexes all for table <schema>.blobdata
db2 terminate

对于提升,如果自上次 REORG 或在数据库创建时,治理数据库和运行时数据库有大量数据被添加或删除,那么建议您在这两个数据库上运行 REORG。有关详细信息,请参阅 DB2 信息中心的 确定何时重组表和索引

解耦数据库、事务日志和操作系统(治理和运行时数据库)

建议:

  • 将生产 WSRR 数据库托管在操作系统的不同磁盘上。
  • 将数据库事务日志托管在操作系统和数据库的不同磁盘上。

以这种方式分离数据库和事务日志,可以显著提高提升性能。

WSRR 配置文件的创建机制不允许在创建数据库脚本之前对事务日志和数据库的位置进行自定义。但是,可以编辑由配置文件管理工具所构建的数据库脚本,在运行这些脚本创建数据库之前自定义事务日志和数据库的位置。

另外,在创建数据库之后,DB2 数据库可以移动其自己的数据库和事务日志的路径。必须重新启动 WebSphere Application Server,而且将数据库移动到不同的驱动器上需要从备份中重建数据库。要移动数据库和事务日志:

  • 关闭 WebSphere Application Server。
  • 关闭 WSRR 数据库。
  • 备份数据库。例如:db2 backup database to <backup-directory>
  • 删除数据库。
  • 将数据库还原到另一个驱动器。例如:db2 restore database <database> from <backup-directory> TO <new-database-path>
  • 将事务日志移动到另一个驱动器。例如:db2 update db cfg for WSRR using NEWLOGPATH <new-log-path>
  • 重新启动 WSRR 数据库。
  • 重新启动 WebSphere Application Server。

使用 RAID 磁盘阵列

除了将操作系统、数据库和事务日志放在不同的磁盘上之外,使用 RAID 0 磁盘阵列也可以提高数据库的性能。建议将事务日志和数据库都托管在独立的 RAID 磁盘阵列上。使用 RAID 0 意味着可以同时对驱动器执行物理的 I/O。

为了优化 DB2 性能,重要的是要知道 RAID 阵列的条带大小。条带大小是 RAID 阵列上的最小分配,等于段大小乘以 RAID 阵列中的磁盘数量,其中段大小是在处理条带集的下一个磁盘之前写入到一个磁盘上的数据大小。例如,如果段大小是 128 KB,并且在 RAID 阵列中有三个磁盘,则条带大小为 384 KB。您的系统管理员应该能够告诉您 RAID 阵列的条带大小。

在确定条带大小之后,您然后应该考虑 WSRR 表空间的扩展块大小。扩展块是 DB2 表空间容器中的存储块,扩展块大小是在页面数据被写入数据库中的下一个容器之前将写入容器的页面数据量。

建议您设置的 WSRR 表空间的扩展块大小与 RAID 阵列的条带大小相匹配,该大小被表示为表空间页面的数量。例如,如果 RAID 阵列的段大小为 384 KB,该阵列托管的表空间的页面大小为 32768 字节,则表空间的扩展块大小应设置为 12。只有在创建表空间时才可以设置扩展块大小。对于现有的 WSRR 数据库,重新配置扩展块大小需要创建一个具有正确扩展块大小的新数据库,然后使用 db2move 命令或 WSRR 迁移 特性来填充新数据库。

对于 WSRR V7.5 和 V8.0,应考虑四个表空间的扩展块大小:ATHSTMTTS、ATHDATATS、WSRRTS 和 WSRRTEMP。默认情况下,数据库创建脚本创建所有这些表空间,如下所示:

图 5. 默认的 WSRR 页面大小和扩展块大小设置
默认的 WSRR 页面大小和扩展块大小设置

您可以看到,所有表空间都使用相同的扩展块大小,但页面大小却各不相同。为了优化 DB2 扩展块,以便与 RAID 阵列相匹配,请设置 EXTENTSIZE,如下所示:

EXTENTSIZE 的公式
EXTENTSIZE = stripe-size / page-size

对于新的 WSRR 数据库,要为这些表空间设置扩展块大小,最简单的方法是编辑脚本 CREATEWSRRTABLESPACE.SQL,然后再运行该脚本。下面是提取的已修改过的脚本,用来修改 ATHSTMTTS 表空间的扩展块大小,以便与我们的示例 RAID 阵列匹配:

在 CREATEWSRRTABLESPACE.SQL 中修改 EXTENTSIZE
CREATE LARGE TABLESPACE ATHSTMTTS
    PAGESIZE 4K
    MANAGED BY AUTOMATIC STORAGE
    AUTORESIZE YES
    INITIALSIZE 100M
    INCREASESIZE 10 PERCENT
    MAXSIZE NONE
    EXTENTSIZE 96
    BUFFERPOOL ATHSTMTBP
    FILE SYSTEM CACHING;

上述设置只是说明性的,不同的 RAID 阵列可能会导致不同的最佳扩展块大小设置。

当 DB2 对数据执行顺序访问时,使用单一 I/O 操作将多个连续页面提取到内存中可以提高性能。PREFETCHSIZE 参数指定在这样的条件下可以读取多少数据。建议您在使用 RAID 设备时优化每个表空间的 PREFETCHSIZE。根据下面的公式设置此参数:

PREFETCHSIZE 的建议公式
PREFETCHSIZE = 
(stripe size * the number of RAID devices * number of DB2 containers) / page-size

您可以看到,PREFETCHSIZE 值是 EXTENTSIZE 的建议设置的倍数。使用下面的 DB2 命令可以轻松地更改 PREFETCHSIZE:

设置 PREFETCHSIZE
ALTER TABLESPACE <tablespace-name> PREFETCHSIZE n

其中 n 是 PREFETCHSIZE 的新页面数量。在更改此参数时,不必重新启动 WSRR 或数据库。

对 WSRR 进行数据库调优

数据库调优的一般处理已超出本文范围。本节介绍可以提高 WSRR 提升性能的一些基本数据库调整。在对您的数据库环境进行任何更改之前,请咨询您的本地 DBA。

为每个 WSRR 数据库确定最大内存

要确立的第一件事情是,数据库服务器将给 WSRR 分配多少专用资源,以及系统要为多少个 WSRR 数据库提供服务。例如,您可能会决定一个完整的数据库服务器专用于一个 WSRR 治理数据库和一个运行时数据库。理想情况下,服务器将专用于 WSRR,但这大概是不可能的,且服务器可能承载了其他数据库和应用程序。无论采用哪种方式,重要的是要确定每个 WSRR 数据库有多少专用的系统内存。

考虑服务器专用于治理和运行时数据库的情况。在这种情况下,您可能会决定允许治理注册表消耗高达 60% 的系统内存,并允许运行时数据库消耗高达 30% 的系统内存。

确定在单负载事务中的语句数量

重要的是要确立您的数据的复杂性,即确定在单个事务中的 SQL 语句的数量上限。要做到这一点,首先高亮显示一个 WSDL,这是您可能用于填充注册表的更复杂的 WSDL 之一。然后通过将服务加载到测试系统并使用以下技术之一,估计在一个事务中的语句数量:

  • 使用 WebSphere Application Server trace,并使用跟踪字符串 com.ibm.athene.query*=all。
  • 使用 db2diag。
  • 分析加载典型 WSRR 工件前后的 DB2 快照。

利用 trace 和 db2diag 不容易算出语句总数,而且您会发现使用 DB2 快照更容易。使用快照进行这项计算,首先要在加载 WSDL 之前创建一个快照,然后加载 WSDL,之后再创建另一个快照,如下所示:

使用 DB2 快照
db2 get snapshot for database on WSRR75L > db2_wsrr75l_snapshot_pre_load.txt
. . . 
. Load WSDL
. . . 
db2 get snapshot for database on WSRR75L > db2_wsrr75l_snapshot_post_load.txt

然后,您可以扫描两个文件,查找 rows inserted,并将双方的相应值相减,例如:

确定插入的行数
find "Rows inserted" db2_wsrr75l_snapshot_pre.txt

---------- DB2_WSRR75L_SNAPSHOT_PRE.TXT
Rows inserted                              = 1

find "Rows inserted" db2_wsrr75l_snapshot_post.txt

---------- DB2_WSRR75L_SNAPSHOT_POST.TXT
Rows inserted                              = 395700

在本例中,有 395699 行被插入。这个数字仅仅是一个示例,您应该检查自己的数据,看看在您的环境中是什么值。当您进行此计算时,确保尽量没有其他数据库活动。

在数据库上运行 AUTOCONFIGURE 实用程序

xxx 在确定了每个 WSRR 数据库的最大内存并估算了写事务中的典型语句数量后,调优数据库性能的下一步是使用 DB2 AUTOCONFIGURE 命令,将您选择的最大系统内存和事务内的语句数量赋给该命令。首先在报告模式下运行该命令,它会告诉您它建议的设置,但不作任何更改。如果您同意建议,那么重新运行该命令并应用更改。

再看看前面的示例,最多有 60% 的系统内存专用于治理注册表,30% 的内存专用于运行时注册表。要在报告模式下运行 AUTOCONFIGURE,您应先连接到数据库,然后发出如下命令:

运行 DB2 AUTOCONFIGURE 命令
db2 autoconfigure using mem_percent 60 workload_type simple num_stmts 500000 
  admin_priority performance is_populated no apply none > db2_changes.txt

APPLY NONE 子句告诉 AUTOCONFIGURE 不作出任何实际更改。来自实用程序的建议被保存到一个文件中,您可以检查一下,并看看在应用配置时,DB2 将改变什么。在本例中,假定数据库是空的。如果您的数据库被填充,那么使用 is_populated yes。审查完更改后,保存当前数据库配置的副本,例如:

保存 DB2 数据库配置的副本
db2 get db cfg for WSRR0 > WSRR80_config.txt

然后,在以应用模式重新运行之前,您应该保存一个 DB2 数据库备份,供您以后决定恢复到原始设置时使用。现在,您可以发出命令重新运行 AUTOCONFIGURE 以应用更改,如:

运行 DB2 AUTOCONFIGURE 命令
db2 autoconfigure using mem_percent 60 workload_type simple num_stmts 500000 
  admin_priority performance is_populated no apply db and dbm

执行此命令后,重新启动数据库,并检查 INSTANCE_MEMORY 变量,看看 AUTOCONFIGURE 如何修改可用的最大内存。例如:

验证新实例的内存
db2 get db manager config | grep INSTANCE_MEMORY

通过比较该变量的设置与系统内存,您可以确认已经应用了正确的比例。

进一步调优

在使用 DB2 AUTOCONFIGURE 之后,您可以考虑进一步调优,若这样做,您的个性化选择不会被重置。请考虑以下调优参数:

  • DBHEAP
  • LOGBUFSZ
  • LOGFILSIZ
  • LOGPRIMARY
  • LOGSECOND
  • AUTO_MAINT

DBHEAP 的设置是最大数量的 DB2 堆内存,在由 WSRR 产生的脚本所构建的新数据库中可能会受到限制。建议将其设置为 AUTOMATIC:

将 DBHEAP 设置为 AUTOMATIC
db2 update db cfg for WSRR80 using DBHEAP AUTOMATIC

在复杂的事务(如提升)正在进行的时候,增加 LOGBUFSZ 可以显著减少写出到事务日志的数据。如果您期望复杂的提升操作会产生在单一事务中执行的大量数据库语句,请增大该参数。例如:

设置 LOGBUFSZ
db2 update db cfg for WSRR80 using LOGBUFSZ 32000

LOGFILSIZ 决定页面中的主事务日志文件和次事务日志文件的大小。默认情况下,它可能是相当小(如​​每个文件为 8 MB),这可能会导致大量事务日志被同时写入,造成一个 I/O 瓶颈。您可以增大该参数,如下所示:

设置 LOGFILSZ
db2 update db cfg for WSRR80 using LOGFILSIZ 32000

若页面大小为 4 KB,则每个事务日志将是 125 MB。

您也应该看看配置的主日志文件和次日志文件的数量,这是使用 DB2 LOGPRIMARY 和 LOGSECOND 参数指定的。主日志文件是在文件系统上预先分配的,而次日志文件是在有需要是创建的。因此,若事务日志文件较大,不分配过多次日志文件可能是明智的处理。 另一方面,新分配次日志文件时会有性能损失,所以您不需要减少太多主日志的数量。理想的情况是有足够的主日志空间供日常运行,同时次日志空间也足够大,可以在有需要时支持使用高峰。您可以更改主日志和次日志数量的设置,如下所示:

设置主日志和次日志的数量
db2 update db cfg for WSRR80 using LOGPRIMARY 20
db2 update db cfg for WSRR80 using LOGSECOND 230

您可能还需要考虑另外一个领域,即禁用自动的 DB2 维护任务,这样可以帮助防止在不方便的时候对性能造成影响,如下所示。如果您禁用自动维护,请确保您有自己的进程,以保证定期运行 RUNSTAT 和偶尔运行 REORG 命令。

禁用自动维护
db2 update db cfg for WSRR80 using AUTO_MAINT OFF

禁用文件系统缓存

您可以通过在 DB2 WSRR 表空间上禁用文件系统缓存而获得适度的性能增强,但前提条件是允许 DB2 缓冲池自动增长。这将不是一个问题,除非已经更改了缓冲池调优,这是因为配置文件管理工具和数据库脚本会自动启用自动的缓冲池大小调整。下面的命令可以在 WSRR V7.5 和 V8.0 的表空间上禁用文件系统缓存:

禁用文件系统缓存的命令
 db2 connect to <database>
 db2 alter tablespace ATHSTMTTS no file system caching
 db2 alter tablespace ATHDATATS no file system caching
 db2 alter tablespace ATHTEMPTS no file system caching
 db2 alter tablespace WSRRTS no file system caching
 db2 alter tablespace WSRRTEMP no file system caching
 db2 terminate

WSRR 及其数据库服务器之间的网络

中等规模的服务提升可能很容易导致在治理和服务注册表及其关联数据库之间要传输总共 100 MB 的数据。虽然按照今天的标准来看,这并不是非常大的数据量,但网络性能中的瓶颈可能会影响提升时间。带宽、延迟和拥塞都是网络性能的重要因素,对所有这三个因素都应进行调查,特别是在对网络状态不十分了解的情况下更应进行调查。在理想的情况下,数据库应该通过高速、低延迟的网络连接到 WSRR 服务器。但是,现实并不总是这样,数据库可能需要放在远程位置,或托管在有限带宽的共享网络上。

带宽、延迟和拥塞

带宽 是网络容量 - 在其中推送数据的速度。其测量单位通常是百万比特每秒 (Mbs),并且可以被认为是网络管道的宽度。

延迟 是一块数据穿过网络所花费的时间。其测量单位通常是毫秒 (ms),并且可以被认为是网络管道的长度。

带宽和延迟之间的差异如图 6 所示:

图 6. 带宽、延迟和网络管道
带宽、延迟和网络管道

拥塞 是繁重的网络使用情况的后果,并可能造成传输数据延迟、数据包丢失从而导致须重新传输数据包,以及导致无法建立连接。数据包丢失通常按百分比衡量。TCP 通常可以处理最多 0.1% 的丢失,且几乎没有直接影响,但丢失超过 0.1% 时,后果可能更严重。

要实现健康的 WSRR 提升性能,网络应具有高带宽、低延时和最少量的数据包丢失。

测量网络带宽

测量 WSRR 和数据库之间通过网络连接可实现的带宽,这是一个不错的想法。虽然连接可以提供理论上的最大速度(如 1 Gbs 或 10 Gbs),但实际带宽可能会由于拥塞、网络损耗和硬件问题而低得多。

测量带宽的其中一种方法是在网络上复制一个较大的文件,然后根据文件大小和传输时间计算带宽。但是,这种方法有可能大幅低估了吞吐量,原因包括两端的磁盘 I/O 开销、协议开销、造成数据包丢失和重新传输的网络拥塞,这些原因在应用程序层(如在文件副本中)均看不到。使用 FTP 对没有文件系统的设备(如 /dev/zero 和 /dev/null)执行读写操作可以减轻磁盘 I/O 开销。

测量带宽有更好的方法,就是使用 Test TCP (TTCP) 等工具,这些工具测量两个系统之间的数据传输,两个系统分别被配置为接收器和发送器。数据复制是在系统之间从内存到内存的执行,因而避免了磁盘 I/O 的影响。TTCP 由 Terry Slattery 和 Mike Muuss 在 TCP/ IP 的早期编写,现在,原始的源代码可以在公共域免费获取。要使用 TTCP,使用 -r 和 -s 选项在目标上启动该 TTCP:

在目标上运行 TTCP
ttcp -r -s -f m

-f m 选项表示吞吐量测量结果将以 Mbs 为单位显示。接下来,在发送主机上运行 TTCP,并使用 -t 和 -s 选项:

在发送机上运行 TTCP
ttcp -t -s -n 50000 fred.bloggs.com

在这里,该命令使用了 -n 50000,表示将给接收器发送 50000 个数据包。当接收器接收到数据时,就会显示一个摘要,如下所示:

TTCP 接收器输出
ttcp  -r -s -f m
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from ww.xx.yy.zz
ttcp-r: 409600000 bytes in 0.50 real seconds = 6252.60 Mbit/sec +++
ttcp-r: 50001 I/O calls, msec/call = 0.01, calls/sec = 100043.62
ttcp-r: 0.0user 0.3sys 0:00real 77%

因此,本测试是在 10 Gbs 的链接上执行,您可以从中看到 409 MB 数据(50000 * 8192 字节数据包)在两个系统之间的传输时间超过 0.50 秒,而且有效带宽为 6252 Mbs。如果您的有效带宽较低或明显小于总网络带宽,请咨询您的网络管理员。

测量网络延迟

大部分 WSRR 实例及其关联数据库服务器被网络紧密连接在一起,从而导致了低延迟(通常小于 1 毫秒)。建议系统彼此靠近,但相邻性并不总是能够实现,有些 WSRR 服务器与其数据库服务器处于不同的位置。在这种情况下,网络延迟甚至更重要。您可以使用 ping 命令测量两个系统之间的网络延迟,该命令测量在网络中发送一个小数据包并收到回复所花费的时间。Ping 使用 ICMP 协议,并且不会产生 TCP 协议开销。举个例子:

使用 ping 测量网络延迟
ping news.bbc.co.uk

Pinging newswww.bbc.net.uk [212.58.246.81] with 32 bytes of data:
Reply from 212.58.246.81: bytes=32 time=36ms TTL=56
Reply from 212.58.246.81: bytes=32 time=19ms TTL=56
Reply from 212.58.246.81: bytes=32 time=20ms TTL=56
Reply from 212.58.246.81: bytes=32 time=21ms TTL=56

Ping statistics for 212.58.246.81:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milliseconds:
    Minimum = 19ms, Maximum = 36ms, Average = 24ms

在本例中,您可以看到,平均往返时间为 24 毫秒,这表示网络延迟为 12 毫秒。本例是在家庭宽带连接上进行测量的。在同一子网内的计算机之间的延迟时间应在 1 毫秒以内。在某些系统上,ping 只能将往返时间解析到最接近的毫秒,无法精确测量低于 1 毫秒的往返时间。在这种情况下,使用一个高分辨率的开放源码 Ping 实用程序。如果您在本地网络上不断看到延迟超过 1 毫秒,请咨询您的网络管理员。

丢包

Ping 实用程序显示通过网络发送的 ICMP 数据包的丢包。您可以在上述示例的末尾处看到丢包统计 (Lost = 0)。然而,这种测量仅基于从 Ping 实用程序发出和传输到 Ping 实用程序的这些数据包,并不测量穿过网络的任何其他数据包。在某些系统上,ping 也支持将 ICMP 数据包尽可能快地写到网络上的一个选项,并将同样在末尾处为您提供丢包统计 -- 即所谓的 flood ping。请慎用该选项,因为它可能影响到一般的网络性能。应仅在测试条件下只运行该选项几秒钟,

您还可以使用 NETSTAT 实用程序查看有多少包被丢弃在网络上。例如,下面是 netstat -D 在 AIX 上的输出:

使用 netstat 报告丢包 (AIX)
# netstat -D

Source                         Ipkts                Opkts     Idrops     Odrops
-------------------------------------------------------------------------------
ent_dev0                    26820670             16079610          0          0
                ---------------------------------------------------------------
Devices Total               26820670             16079610          0          0
-------------------------------------------------------------------------------
ent_dd0                     26820670             16079610          0          0
                ---------------------------------------------------------------
Drivers Total               26820670             16079610          0          0
-------------------------------------------------------------------------------
ent_dmx0                    26820664                  N/A          6        N/A
                ---------------------------------------------------------------
Demuxer Total               26820664                  N/A          6        N/A
-------------------------------------------------------------------------------
IP                          50335154             44013816    1110616     147099
IPv6                            1473                 1473          0          0
TCP                         43110957             40986657       6235          0
UDP                          6105902              2045877    5022268          0
                ---------------------------------------------------------------
Protocols Total             99552013             87046350    6139119     147099
-------------------------------------------------------------------------------
en_if0                      26820664             16079528          0          0
lo_if0                      27970975             27975366       4652          0
                ---------------------------------------------------------------
Net IF Total                54791639             44054894       4652          0
-------------------------------------------------------------------------------
NFS/RPC Client                    23                  N/A          0        N/A
NFS/RPC Server                     0                  N/A          0        N/A
NFS Client                     14949                  N/A          8        N/A
NFS Server                         0                  N/A          0        N/A
                ---------------------------------------------------------------
NFS/RPC Total                    N/A                14977          8          0
-------------------------------------------------------------------------------
(Note:  N/A -> Not Applicable)
#

在 Windows 上,可改为使用 netstat -s 命令。

在 AIX 上,可以使用 netstat -Zs -p tcp 命令在执行提升活动之前重置协议统计。

如果丢包率一直超过 0.1%,请与您的网络管理员讨论此问题。

网络带宽和延迟

高带宽但高延迟的网络可能会导致许多数据包同时在网络上传输。在这种情况下,重要的是操作系统需要在连接的两端上充分缓冲数据,从而在管道中最大化数据包的数量。您可能需要更改 TCP Send 和 Receive 缓冲区的大小。有关更多信息,请参阅您的操作系统文档。在 AIX 上有关此主题的信息,请参阅 AIX 信息中心的 TCP 和 UDP 性能调整

结束语

本文提供的指南可以帮助您最大化 WSRR 提升过程的速度和效率,并提高 WSRR 的整体性能。本文向您介绍了如何根据需要检查和提高 WSRR、DB2 数据库和网络性能。


下载

描述名字大小
代码样例promotion_rollout.zip124 KB

参考资料

学习

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=854256
ArticleTitle=在 WebSphere Service Registry and Repository 中提升性能
publish-date=12242012