内容


监控和调优 InfoSphere Master Data Management Server,第 1 部分

设置目标和调优基础架构的每一层

调优 MDM Server 环境实现高性能访问主数据

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 监控和调优 InfoSphere Master Data Management Server,第 1 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:监控和调优 InfoSphere Master Data Management Server,第 1 部分

敬请期待该系列的后续内容。

简介

IBM InfoSphere™ Master Data Management Server (MDM Server) 的应用程序性能受一系列因素的影响,包括解决方案设计、实现和基础架构。本系列的两篇文章主要介绍影响性能的实现和基础架构因素,以及监控 MDM Server 应用程序的方法。您需要密切监控并高效调优完整 MDM Server 实现堆栈以获得最佳性能。本系列文章通过提供高效监控和调优完整 MDM Server 软件堆栈的实践说明和建议,帮助 IT 专业人员和客户最大化性能。

MDM Server 支持您管理和维护完整且准确的客户主数据视图,从而帮助您的组织控制业务信息。MDM Server 通过集中多个数据域(包括参与方、帐户和产品)并提供一组完整的预建业务服务(支持整套主数据管理功能),支持您的组织从主数据获得最大价值。 IBM 是第一个为多个域提供 MDM 服务器的企业。IBM 还提供了行业领先的集成功能,降低了客户端风险和成本,从而提高了收益并支持客户端快速满足合规要求。

MDM Server 支持多种操作系统、中间件和数据库。与在任何软件应用程序中一样,单个硬件子系统的瓶颈、错误配置的操作系统或调整不良的应用程序和环境都可能导致性能不佳。恰当的工具可帮助您诊断这些瓶颈。

本文介绍 MDM Server 的主要组件以及组件之间如何进行交互。您将了解到一种服务的不同软件层,以及调用服务时 MDM Server 如何响应。本文可为您监控、确定和调优 MDM Server 的不同层以获得最佳性能做好准备。

本文提供了性能调优的最佳实践,包括下列 MDM Server 主题:

  • MDM Server 监控和调优
  • WebSphere 监控和调优
  • 数据库监控和调优

尽管您可能会发现一些部分可直接用作参考,但还是建议您按顺序阅读本文。

先决条件

为了获得最佳性能,在大多数情况下,组件(包括 MDM 服务器、数据库服务器和 WebSphere MQ 服务器)应位于独立的系统中。具有此类配置的主要好处是避免位于一个服务器上的多个组件之间的资源争用。例如,在一台计算机上运行 MDM Server 组件,从技术可行性角度来说,根据您的工作负载不同,这会影响可实现的吞吐量。

本文的性能测试配置中使用的 IBM InfoSphere MDM Version 8 的组件如下所示:

  • 一台运行 WebSphere Application Server V6.1 的应用程序服务器计算机
  • 一台运行 DB2 V9.5.4 的数据库服务器计算机

了解整体概况

当讨论到多层环境中应用程序的性能问题时,过程能力、产品知识和富有环境经验的团队的健全组合是绝对必需的。性能调优清单、最佳实践和丰富的产品经验都是很好的资产,但是也仅限于此。应首先设置符合您业务目标的性能目标,然后使用兼顾长期可扩展性和低成本的方法(在时间和资源上达到平衡)实现这些目标。

本部分列出了成功规划、分析和调优 MDM Server 实现所需的能力和流程。

设置性能目标

当开始任何性能调优或测试项目时,最好设置具体的目标,以提供工作的重点和结束状态。尽管这似乎是显而易见的,但是许多调优工作都变得极为昂贵,因为将重点放在了错误的组件上,或者是因为没有设置具体目标而导致调优过多。明确地设置此类目标需要了解具体的业务需求。

您的目标应是具体的且根植于业务语言。例如,不会声明增量负荷批处理运行的目标为 30 TPS,而通常是最好指定批处理窗口的目标时间,包括所有启动和后续工作,以及被拒绝记录的容差级别。这会使您的解决方案调优变得灵活且经济高效,并同时解决实际业务问题而不是抽象的数字。

目标的语言和术语对其涉及的所有人来说都应是明确的。即使是像事务 这样的常用术语在不同类型的服务工作负载中意思都很不明确。

下面是一个具体目标的示例列表:

  • 按 Name 和 Postal Code 进行搜索不应超过 1500ms,并且 95% 的执行应小于 1000ms
  • 在每秒有 45 次持续并发 getParty 调用的情况下,95% 的在线 getParty 调用执行不应超过 500ms
  • 假设最大的批处理工作负载为 65,000 次更新,则增量更新-维护事务应在 3 小时内完成

了解环境

您需要深入了解 MDM Server 解决方案的组件,以帮助您简化任何性能测试或调优流程。MDM 只能以基础架构允许的最快速度运行。任何 CPU、I/O 或网络瓶颈都可能对吞吐量产生负面影响。将基础架构基准测试与基本监控相关联可为性能测试结果提供足够的上下文,帮助您确定瓶颈。

一个多层企业解决方案有很多相关运动部件,MDM 服务器也是这样。了解环境中每个节点的并发性、响应时间和资源使用情况,可更快速地分离系统和应用程序瓶颈。图 1 显示了 MDM Server 解决方案中常用组件的逻辑架构。

图 1. MDM Server 逻辑架构
图在顶部显示了提供商,底部显示了服务,而操作将两者连接在一起
图在顶部显示了提供商,底部显示了服务,而操作将两者连接在一起

(查看图 1 的 大图

了解工作负载

了解和量化 MDM Server 解决方案中的工作负载,支持您确定测试方法和问题分析。在任意给定的 MDM Server 解决方案中,有不同的工作负载可强调环境的不同方面。下面是一些常见的工作负载:

初始负载
首次将源系统的数据放入 MDM Server 中
增量负载
在初始负载之后将更新与源系统分离开来
应用程序特定工作负载
特定于每个客户端系统的业务场景的实时服务混合
分析或导出工作负载
ETL 或自定义导出
可疑副本处理
对于那些带有异步/长期流程的 SDP 调用

除了隔离工作负载,了解每个工作负载中调用的不同 MDM 服务类型混合很重要。由于每种工作负载的性质,强调了 MDM Server 基础架构的不同部分。对于具有大量更新的增量负载,在数据库服务器上可能有 I/O 限制。对于具有大量查询和高并发性的应用程序特定工作负载,可能需要更改 WebSphere 线程池和数据库连接池。您可以通过采用本文列出的工具分解现有工作负载。

建立性能调优流程

无论您的目的是将 MDM Server 调优到所需的服务级别协议 (SLA),还是仅对自定义代码更改执行测试,建立存档的可重复性流程是必需的。在执行 MDM Server 性能测试时考虑以下内容:

  • 每个性能测试都需要一个一致性基准,用来比较变更。对性能测试使用单个重复的数据集,并确保总是将您的 MDM Server 数据库还原到建立基准的位置。
  • 每次进行一次更改,并在您确定更改将变为永久性的时候重新建立基准。
  • 确保应用程序和数据库层都还原到最新的基准状态,这是除了任何已接受调优更改之外的最佳实践起点。
  • MDM Server 解决方案可以有很多并发工作负载,这些工作负载使用不同服务器的入口点。如果您组合使用 JMS/MQ 和 EJB/RMI 工作负载,最好首先隔离它们,并进行调优,然后再组合起来以进行最终测试。同样,首先应隔离完全不同的工作负载(比如操作查询和增量负荷更新),并单独测试它们。

监控和调优 MDM Server

MDM Server 有一个以不同的粒度级别监控响应时间的全面解决方案。可以根据需要启用或禁用性能跟踪,并且还可以针对低影响的生产环境监控进行配置,以进行更深入的分析研究。尽管此功能与 ARM 4.0 兼容(参见 参考资料),本文重点介绍 log4j 输出(performancemonitor.log),因为它存在于所有 MDM Server 实现中,无需其他软件。

从 MDM Version 8.0 开始,MDM 性能跟踪已得到了很大改进,监控响应时间的易用性和精度都提高了。所记录的响应时间指标现在以毫微秒而不是早期版本的微秒衡量。此外,日志文件输出现在很明确地将 MDM 子组件调用归纳到其父控制器 中,这样就可以更轻松地理解和分析日志。此功能具有了解和管理 MDM 的开销,支持它在生产中使用以解决问题,不会严重影响系统的吞吐量。

要了解有关 MDM Server 性能跟踪的更多信息,请查阅 MDM Server 产品文档包含的 MDM 开发人员指南(参见 参考资料)。

启用 MDM Server 性能跟踪

要利用 MDM Server 性能跟踪,您必须明确地启用它。与 MDM Server 中的大多数产品功能一样,可以通过修改配置和管理表(具体地讲是 CONFIGELEMENT 表)来启用该功能。以建议的级别启用 MDM 性能跟踪,以进行问题诊断和调优。清单 1 显示了级别 2 的命令。

清单 1. 启用性能监控的数据库命令
UPDATE CONFIGELEMENT SET VALUE = 'true', LAST_UPDATE_DT = CURRENT_TIMESTAMP WHERE 
NAME = '/IBM/DWLCommonServices/PerformanceTracking/enabled';
UPDATE CONFIGELEMENT SET VALUE = '2', LAST_UPDATE_DT = CURRENT_TIMESTAMP WHERE 
NAME = '/IBM/DWLCommonServices/PerformanceTracking/level';
COMMIT;

建议将 log4j 输出作为进行问题研究的起点,这有助于最好地配置 log4j,以获得正确大小的 performancemonitor.log 和滚动窗口。要确保正确捕获难懂的问题或者仅获得大型统计示例,请为不断增加的 performancemonitor.log 提供大约 2 GB 的空间。这通常足够捕获复杂的大容量实现中 MDM Server 一个小时的工作负载。从 MDM Server 上 properties.jar 存档的 log4j.properties 文件的清单 2 中查找条目。

清单 2. 配置 Log4J 属性以确保循环 PM 日志
...
log4j.appender.performanceLog=org.apache.log4j.RollingFileAppender
log4j.appender.performanceLog.Encoding=UTF-8
log4j.appender.performanceLog.Threshold=ALL
log4j.appender.performanceLog.layout.ConversionPattern=%d : %m%n
log4j.appender.performanceLog.layout=org.apache.log4j.PatternLayout
log4j.appender.performanceLog.File=/opt/IBM/MDM85/MDMlogs/perflogs/performancemonitor.log
log4j.logger.com.dwl.base.performance.internal.PerformanceMonitorLog=ALL,performanceLog
log4j.appender.performanceLog.MaxBackupIndex=20
log4j.appender.performanceLog.MaxFileSize=100MB
...

在更改了 CONFIGELEMENT 和 log4j 后,需要针对 MDM Server 实例重新启动 WebSphere Application Server,使更改生效。一旦您再循环服务器后,MDM Server 性能跟踪会记录 MDM Server 进行的所有事务。还值得一提的是,您可以更改性能日志记录的级别。例如,您可以使用 CM 控制台自动关闭或打开它,无需再循环 MDM Server 实例。

清单 3 中的 performancemonitor.log 代码显示了一个相对简单的自定义复合事务的示例。清单 3 有一个父事务:maintainParty,但它会调用多个 MDM Server 子组件。从 CONTROLLER 的最后一个数字,您可以看到此事务持续了 667095210 毫微秒(突出显示)或大约 667 毫秒。此事务的大部分内容已被省略,因为每个事务可能有几十到几百行。

清单 3. 性能监控日志中的示例条目
2009-02-12 21:02:45,028 : 
706000020 maintainABCParty : addPerson_CONTROLLER @ CONTROLLER :  : 
  147123449056435909 : 667095210 :  : SUCCESS
706000020  maintainABCParty : externalValidation(int, Object, String) @ DWLControl : 
  147123449056435909 : 241234490564359621 : 75237 : Completed : SUCCESS
706000020  maintainABCParty : externalValidation(int, Object, String) @ TCRMPersonBObj : 
  147123449056435909 : 518123449056436088 : 64034 : Completed : SUCCESS
706000020  maintainABCParty : internalValidation(int, Object, String) @ TCRMPersonBObj : 
  147123449056435909 : 371234490564360022 : 1457512 : Completed : SUCCESS
706000020  maintainABCParty : searchSuspectDuplicateParties_COMPONENT @ COMPONENT : 
  147123449056435909 : 320123449056436177 : 341390435 :  : SUCCESS
706000020   maintainABCParty : searchPersonByName_COMPONENT @ COMPONENT : 
  320123449056436177 : 602123449056436296 : 339744666 :  : SUCCESS
706000020  maintainABCParty : addParty_COMPONENT @ COMPONENT : 
  147123449056435909 : 587123449056470310 : 322874434 :  : SUCCESS
...
706000020    maintainABCParty : addPartyAdminSysKey_COMPONENT @ COMPONENT : 
  746123449056470366 : 950123449056501339 : 11416919 :  : SUCCESS
706000020     maintainABCParty : internalValidation(int, Object, String) @ 
  TCRMAdminContEquivBObj : 950123449056501339 : 706123449056501410 : 60410 : 
  Completed : SUCCESS
706000020  maintainABCParty : execute(ExtensionParameters) @ FeedInitiator : 
  147123449056435909 : 324123449056502600 : 32071 :  : SUCCESS

分析和解决问题

尽管 MDM Server 性能跟踪有很多用途,但是其最重要的作用是分析 MDM Server 工作负载或单个事务。它提供两条重要信息:粒度响应时间和 MDM Server 组件调用的顺序分解。此信息使性能跟踪成为一个有价值的一站式诊断工具,用于诊断性能问题。因此,IBM Support 将它看作任意支持服务必须收集 的一个关键项。IBM MDM Performance Team 还在其内部使用 MDM 性能跟踪来衡量并评估 MDM Server 性能。

MDM Server 性能跟踪的一个常用场景是研究复杂的自定义 MDM Server 事务的慢响应。在测试环境中捕获感兴趣的事务揭示了子组件的下列属性:

  • 它们的名称
  • 它们执行的频率
  • 它们的顺序
  • 它们的响应时间

有了此类信息,您可以看到实现中正在进行的大型复杂事务,并且还可能发现有待改进的地方。如果在开发流程的早期使用此信息,您可以发现低效的 MDM 服务器查询级别,其中恢复了比事务实际需要更多的信息,或者是发现自定义复合事务(可导致冗余 MDM Server 组件调用)的低效逻辑。事务分解也可定位花费了特别长时间的子组件,这有助于精确地找到 SQL 需要进一步研究的位置或者是代码减速的位置。

MDM Server 性能跟踪的另一个常用场景是,基于调优和事务优化目的分析整体工作负载。一个简单的 shell 或 PERL 脚本可帮助生成有帮助的汇总数据,说明在操作 MDM 工作负载中占用时间最多的 MDM 组件。

清单 4 中的图来自 MDM 实现中的一个早期性能测试。该图提供了一个关于被监控的 MDM 服务器中事务混合和响应时间的高级视图。实现正面临性能问题,即调整不良的可疑副本处理原则。通过划分成性能日志中的 updateParty、addPerson 和 addOrganization 事务示例,可轻松确定它们共有的子组件 searchSuspectDuplicateParties 在前面提到的所有控制器级别事务中占用的时间最多。修改并重新测试了自定义的搜索可疑原则,这使事务的响应时间缩短了一半。

清单 4. 事务响应时间 (ms)
Transaction Name	    Txn Count	 AvgRespTime	     CumRespTime     %Workload
updateParty		17911		3186		57072557	37.22%
addPerson		4850		7077		34331324	22.39%
addOrganization		3353		8856		29702874	19.37%
getPerson		9629		1105		10637676	6.94%
updateContractPartyRole	20746		447		9280139		6.05%
getOrganization		8291		889		737984		4.81%
getPartyRelationship	12299		108		1323786		0.86%

配置日志级别

MDM Server 日志配置是优化应用程序性能最显著且最简单的方式之一。通常在开发过程中,将 MDM Server 的 Customer.log 设置为 log4j 的 DEBUG 级别以进行跟踪。尽管这适用于大多数测试环境,但是 MDM Server 的日志输出很重要,并且这种级别不适用于生产工作负载或性能测试。因此,中央记录器应设置为 ERROR,如清单 5 所示。

清单 5. 设置日志级别
...
log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.Encoding=UTF-8
log4j.appender.file.Threshold=ERROR
log4j.appender.file.layout.ConversionPattern=%d %-5p %3x - %m%n
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.File=/appl/spool/tssi/BP/logs/Customer.log
# optional settings
log4j.appender.file.MaxBackupIndex=10
log4j.appender.file.MaxFileSize=10MB

# The next line controls the level of output for the root logger
# [ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF]
log4j.rootLogger=ERROR, file, stdout
...

还有必要审查由于自定义事务或扩展的原因而添加的其他额外诊断日志。最佳做法是将此额外诊断信息记录到 Customer.log 中的 DEBUG 级别,而不是任何其他日志或日志记录级别。通常,Java® 开发人员会将大型数据(比如 XML)写入 System.out 中,这通常是不可见的,除非将其部署到生产中,并且应用程序服务器日志中充满了调试信息。在日志中填写过量信息,不仅会损害性能,还会妨碍解决问题。

使用 TAIL

事务审计信息日志(TAIL)记录有关 MDM Server 中执行的事务的信息。为了使服务根据需要提供此信息,在启用 TAIL 时,任何添加或修改数据的 MDM 服务都将有额外的开销。尽管此功能有助于坚持会计实务和规范,但它应严格评估容量规划和性能测试。在启用 TAIL 时,请考虑下列有关性能的要点:

  • 您可以配置必须审计的事务和必须审计的每个事务中的操作(或内部事务)。因此,仅配置您需要的事务和操作。在 MDM Server Version 9.0 之前,至少每个事务必须配置一个操作,但是从 MDM Server Version 9.0 开始,您能够仅配置没有任何操作的事务。
  • 通常在事务性工作负载中从 TAIL 表检索数据的 MDM 服务的百分比很低,并且这些服务通常不是性能隐患。惟一的隐患是修改或添加数据的任何 MSM 事务,因为它们将触发 TAIL。
  • TAIL 在下列 MDM Server 数据库表中增加了:TRANSACTIONLOG、INTERNALLOG、INTERNALLOGTXNKEY、INTERNALTXNKEY、EXTERNALLOGTXNKEY (version 9.0) 和 EXTERNALTXNKEY (Version 9.0)。
  • 如果您使用 TAIL 的主要目的是记录系统使用情况(基于报告目的),请考虑使用服务活动监视器。

使用查询级别

支持查询级别的主要查询服务包括 GetParty、GetContract、GetPartyWithContracts 和 GetProductInstance。查询级别表示在响应中返回的业务对象类型,并且它支持您让响应适合客户的需要,或者通过仅检索客户需求使其变为性能敏感的。开箱即用地提供了不同业务对象的很多查询级别。通过配置元数据为您提供了定义自己的自定义查询级别的机制。

从 MDM Server 9.0.1 开始,您能够定义与查询级别相关的自己的 SELECT 语句。这样做时,查询服务使用它而不是开箱即用的内部方法。数据库提取数据的往返次数可大大减少。创建新查询级别的管理服务提供了生成相关 SELECT 语句的选项,该语句在元数据中进行管理。可根据您的需要自定义 SELECT 语句,例如:

  • 默认情况下,SELECT 语句包括选择所有必需表的所有列。可从语句中删除未用作实现一部分的列或者是具体查询级别不需要的列。
  • 可根据您的用户配置文件自定义 WHERE 子句。例如,如果您的实现有严格的规定,仅管理每个人的一个名称,则可以自定义默认的 WHERE 子句,以更高效地加入 PERSONNAME 表。
  • SELECT 语句可以更详细地仅检索您需要的数据。例如,如果客户仅需要 Home Addresses 作为查询的一部分,则特定查询级别的 WHERE 子句可包含仅选择家庭地址的地址使用类型的鉴别器。

使用智能查询

智能查询是一项 MDM Server 功能,支持实施者关闭未使用的 MDM 数据模型查询的特定集合。此简单更改避免了执行无关的查询,显著缩短了事务响应时间并提高了几乎所有事务工作负载场景中工作负载的 TPS。由于此功能可以修改产品的功能,并且随着时间的推移您所使用的 MDM Server 数据模型可能改变,因此在实施此功能时要慎重考虑。使用智能查询时请考虑以下几点:

  • 由于大多数 MDM 服务都包含嵌入查询,因此在许多 MDM 服务中此功能通常都具有好处。
  • 性能受益取决于有多少事务正在查询未用的 MDM Server 数据模型,它们查询的频率,以及您关闭的未用部分的数量。
  • 此功能缩短了响应时间并提高了那些受影响的事务的吞吐量。
  • 优化通常会导致应用程序和数据库层的 CPU 使用率明显降低,以及 MDM 数据库服务器的总体负荷降低,这与通过启用此功能来从事务中删除的查询数量成正比。
  • 当可插入的 SELECT 语句与自定义查询级别功能结合使用时,智能查询设置不起作用。

使用历史记录

MDM Server 可以使用历史记录功能跟踪数据修改。此功能使用数据库触发器修改 MDM Server 的历史记录表,该表从本质上讲是用于存储相关历史记录事件的主 MDM 数据表的映像。当查询服务(比如 GetParty)与 DWLControl 标头中的截止日期一起使用时,会查询历史记录表(称为时间点查询)。对于大多数 MDM Server 操作工作负载,对历史记录表的查询构成了整体工作负载的一小部分,并且应稍加考虑性能。

在 MDM Server 中修改数据的每个事务将相关触发器作为添加或更新工作的一部分运行。因此,在繁重的插入和更新工作负载中,还应考虑历史记录表以及数据库调优和 I/O 规划中的核心操作表。如果可能,考虑放弃审计不需要的历史记录表的数据库触发器。如果您这样做,就不支持删除了数据库触发器的历史记录表的时间点查询,因为这些表中没有数据可供查询服务检索。

注意,在进行初始容量规划时就应考虑历史记录表的增长。使用 DB2 on z/OS 时可采用的一个策略是根据日期(范围)对历史记录表进行分区。根据审计需求,当分区已达到其预定年限时,可删除该分区。当使用 DB2 for Linux®、UNIX® 和 Windows® 数据库软件时,还可使用按范围分区。使用按范围分区支持快速删除数据区域(称为迁出)。例如,如果您需要按月迁出数据,根据月进行按范围分区就是一个很好的策略。

数据扩展的类型

有两种方法可扩展具有其他属性的开箱即用表。第一种方法是创建副表扩展,托管扩展的属性,并且与扩展表为一对一的关系。第二种方法是行内扩展,方法是更改开箱即用表。如果您有大量添加或更新处理(也称为增量处理),考虑使用行内扩展。MDM 工作台组件提供了创建可插入持久例程的工具,因此仅有对这些表进行的单个插入和更新才会插入或更新业务对象。参见 MDM Server 开发人员指南(参见 参考资料)获得有关此方法的更多信息。

使用带有可插入持久化的行内扩展是一个基本的性能考虑因素,因为它对其他活动有积极影响,比如当使用与查询级别相关的可插入式 SELECT 语句时,减少到历史记录表的触发活动,并且仅有少量表加入数据查询。

MaintainParty 复合服务

通常采用 MaintainParty 复合服务来将数据同步到 MDM Server(也称为增量处理)。在此类复合服务中有 3 个主要步骤:

  1. 查找参与方并查询其详细信息。
  2. 处理比较传入更新详细信息与从数据库检索的参与方的业务规则,并确定如何应用更新。
  3. 更新参与方(通过调用 UpdateParty 服务)。

下面是从性能角度需要考虑的一些注意事项:

  • 在第一步中,仅查询您需要的数据。例如,如果复合服务仅处理了一个地址更改,则通常无需检索整个参与方。在这里可以使用查询级别。
  • 在第三步中,仅更新需要的数据。如果提供给已知 UpdatePartyupdate 的其他数据是多余的,并且不需要更新,则强制 UpdateParty 重新发现这一点(通过查询和处理数据)。
  • 在集成层,尝试将对单个参与方的所有更改看作单个 MaintainParty 服务调用的一部分进行处理。例如,如果参与方已更改了地址并且有了新的联系方法,则将它作为单个 MaintainParty 服务调用(而不是作为两个独立的调用)处理更高效。此外,在 MaintainParty 执行中,将两者作为单个 UpdateParty 调用处理是最高效的,尤其是如果启用了可疑副本处理时。因为那时仅在事务范围内执行一次该处理。

使用通知

为了促进与企业中其他应用程序的集成,MDM Server 支持您创建通知。尽管通知系统的功能具有弹性,但通知的最常见形式是在 MDM Server 安装中配置的 JMS 主题。尽管实现通知的最佳实践建议超出了本文的讨论范围,但值得注意的是,MDM Server 实现应规划容量以支持使用 JMS 系统队列来避免关键瓶颈的主题。通常,在使用通知时应考虑以下内容:

系统队列深度或最大大小
根据您的消息管理系统(比如 WebSphere MQ 或 WebSphere System Integration Bus)和配置,完整队列可能导致丢弃通知,或者阻止正等待将消息加入队列的事务。
您的通知负载的大小
根据您的消息管理系统配置,大型消息可能被完全拒绝或者可能导致系统性能降低,因为队列试图管理成千上万的大型消息。对于写入文件系统或数据库的高可用性队列来说,这尤为重要。如果通知消息总是很大(负载超过 1MB),请检查负载并考虑将主键发送到外部系统,以便他们直接从 MDM Server 查询所需的信息。非常大的消息也可能导致高内存使用率,并使 MDM Server JVM 中的垃圾收集延迟。
架构并发性
如果您的通知处理落后,考虑调优 WebSphere 服务器,以支持到您的队列系统的更多线程和连接,方法是为 Topic Connection Factory 及其相关的会话池设置一个合适的连接池。还要考虑使用通知消息的应用程序的处理功能,并确保它们不会成为瓶颈。调整并发性的具体信息取决于您的邮件系统,所以请查阅相应的产品文档。

使用可疑副本处理

可疑副本处理(SDP)是任意 MDM Server 解决方案必不可少的一部分。当规划此特性的功能隐患时,应慎重考虑,以了解您的实施选项对性能的影响。在您的 MDM Server 解决方案中使用 SDP 的最佳做法超出了本文的讨论范围。相反,本文概述了逻辑流程并列出了与应用程序性能相关的主要考虑因素。

尽管对于 MDM Server 中的 SDP 有很多选项和功能,但是目标通常是确定潜在的副本参与方,并且将它们变为一个参与方,或者记录后一操作的匹配和延迟。一旦调用 MDM Server 中的 SDP,它将继续进行以下操作:

  • 根据可用的关键数据搜索潜在候选人
  • 检索与所有候选参与方的匹配相关的参与方信息
  • 根据原则和条件匹配原始参与方与候选人
  • 记录可疑副本和/或瓦解参与方

此流程变得更复杂了,带有数据标准化、概率匹配或自定义搜索和匹配规则。但是,在所有情况下,请考虑以下几点:

  • 根据具体实现,SDP 的成本和开销可能大不相同。但是,它通常比调用它的实际添加或更新服务所花费的时间更长。尽管 MDM 服务很快,但是有必要了解 SDP 是整体工作负载的一个重要部分,因此在 MDM Server 实现的数据分析、开发和性能测试阶段,应相应地考虑这一点。
  • SDP 的响应时间主要取决于候选方搜索的效率,以及搜索返回的候选人最终数量。如果返回的参与方与相关的可疑副本完全匹配,则候选人搜索就是高效的(从功能和性能角度来说)。低效搜索返回包含太多或不相似的无关内容的候选参与方。例如,如果很多参与方包含关键数据项(比如社会安全标识符的 0000000)的虚拟 数据,则得到的搜索可能返回很多潜在候选人(可能不是相关的可疑副本)。由于所有返回的候选人都需要查询其参与方信息,因此许多低效的搜索可能会大大增加 MDM Server 工作负载的开销。这将影响总体响应时间和实现的数据质量。
  • 每当处理连续的更新负荷时,比如增量 工作负载,请使用 MDM Server 长期流程异步执行 SDP 或者在具体的批处理窗口中执行 SDP。使用此方法对数据质量和性能都有很多好处。通过将 SDP 工作与常规的 MDM 添加和更新服务分开,每个事务都有少量锁,这将降低繁忙的数据库的并发开销,从而使添加/更新工作负载和 SDP 工作负载能够更快地完成。因此,您数据库中的锁争用将明显降低,并且您的应用程序服务器具有更短且更分散的工作单元,这将降低 CPU 和 JVM 的内存开销。

针对 MDM Server 调优和监控 WebSphere

根据您的实现和工作负载,最佳 WebSphere Application Server 软件设置各不相同。这些设置来自当应用程序和用户行为更改时的主动性监控和持续调优。考虑每个 MDM WebSphere Application Server 实例的下列基本调优参数:

  • 从 MDM 应用程序服务器实例的最小堆大小 512 MB 和最大堆大小 1024 MB 开始。如果您使用的是 64 位 WebSphere Application Server 实例,可以增加它的大小。通常大多数 MDM 实现的堆大小都不超过 2 GB,因此在这种情况下堆大小不应是使用 64 位的原因。此外注意,与使用 32 位相比,使用 64 位 WebSphere Application Server 实例在事务吞吐量方面的开销为 5% 至 15%,具体取决于您的工作负载。报告的开销是对比了运行 WebSphere Versions 7.0 和 6.1 的 MDM Server 的工作负载。WebSphere Version 7 中的开销比 WebSphere Version 6 的开销少。
  • 确保对象请求代理(ORB)线程池与每个 MDM Server 实例的 MDM ServiceController 无状态会话 bean(RMI 事务)的并发直接调用的最大数量相同。最大的线程池限制是并发用户的最大理论数量。
  • 确保 Web 容器线程池调优到一个足够高的级别以适应 Web 服务请求(如果适用于您的应用程序)。在大多数情况下,无需调整此线程池,因为 Web 容器线程是无阻塞的,并且可以同时处理多个 MDM 服务请求。
  • Enterprise JavaBeans (EJB) 缓存大小从 3500 开始。根据需要调整 MDM Server 以达到最佳设置。
  • 在用于 MDM Server 的 Java Database Connectivity (JDBC) 数据源上,从预定义缓存大小为 300 开始,这可以将事务响应时间缩短 5% 至 15%。
  • 通过使用 WebSphere 设置的默认日志级别(或更低)减少输入/输出活动。

参见 参考资料 获取参考信息。

生成 JVM 堆转储

使用下列方法之一手动生成 JVM 堆转储:

IBM_HEAPDUMP=true;
为新型内存工具生成堆转储文件,格式为 .phd
IBM_JAVA_HEAPDUMP_TEXT=true
为旧工具生成经典的堆转储格式
SIGQUIT (kill -3 on UNIX; Ctrl+Break on Windows)

您还可以设置 WebSphere Version 6 来自动化堆转储生成。这支持最好的方法来分析 AIX、Linux 和 Windows 操作系统上的内存泄露问题。在合适的时间手动生成堆转储可能很困难。要帮助您在内存泄露检测发生时分析内存泄露问题,可使用一些自动化堆转储生成支持。此功能仅可供 AIX、Linux 和 Windows 操作系统上的 IBM Software Development Kit 使用。

大多数内存泄露分析工具在两个堆转储上执行某种形式的差异评估。在检测可疑内存的情况下,会在恰当的时间自动生成两个堆转储。一般理念是在出现问题检测时采取初始堆转储。监控内存使用情况并在确定有足够的内存泄露时使用另一个堆转储,以便您可以比较堆转储来找到泄露的源。针对 WebSphere Version 6 完成下列步骤:

  1. 单击管理控制台导航树中的 Servers > Applications 服务器。
  2. 单击 server_name >Performance and Diagnostic Advisor Configuration
  3. 单击 Runtime 选项卡。
  4. 选中 Enable automatic heap dump collection 复选框。
  5. 单击 OK

然后您可以使用 HeapRoots、HeapAnalyzer 或 IBM Rational Application Developer 分析生成的堆转储(参阅 参考资料 了解有关这些工具的更多细节)。

生成详细的 GC

详细的 GC 输出有助于调优和调试许多性能问题,包括以下内容:

  • 查找最佳堆大小
  • 查找最佳 gc 策略
  • 确定潜在的内存耗尽和泄露原因

您可以使用 IBM Pattern Modeling and Analysis Tool (PMAT) for Java Garbage Collector(参阅 参考资料)查看详细的输出。要启用 WebSphere Version 6 上的 verbosegc,请完成下列步骤:

  1. 在 Administrative Console 中,展开 Servers,然后单击 Application Servers
  2. 单击遇到 OutOfMemory 情况的服务器。
  3. 在 Server Infrastructure 下的 Configuration 选项卡中,展开 Java and Process Management,并单击 Process Definition
  4. 在 Additional Properties 部分,单击 Java Virtual Machine
  5. 单击 Verbose garbage collection 复选框。
  6. 单击 Apply
  7. 在 Administrative Client 顶部,单击 Save 应用堆主配置的更改。
  8. 停止并重新启动 Application Server。
  9. 详细的垃圾收集输出被写入 Application Server 的 native_stderr.log 或者 native_stdout.log,这取决于 SDK 操作系统。对于 AIX、Microsoft Windows 或 Linux,输出位于 native_stderr.log 中。对于 Solaris® 或 HP-UX®,输出位于 native_stdout.log 中。

使用 PMI 指标

下列信息为 WebSphere - PMI(性能度量基础架构)数据类型和它支持的 WebSphere Version 6 Application Servers 提供指标。这些表为下列模块提供信息:

  • 数据库连接池
  • Enterprise Java beans
  • JCA 连接池
  • JTA 事务
  • JVM/系统
  • ORB detail/interceptor
  • JCA 连接池
  • Web 应用程序
  • 会话管理器
  • 线程池

不是所有模块都需要监控,也不是所有模块都在 MDM Server 中实现。表 1 至表 4 显示了重要的关键 PMI 指标,您应该监控它们以进行调优,以及如何使用它们解决 MDM Server 性能问题。

表 1. 数据库连接池指标
属性描述
Avg. waiting threads 等待连接到数据库的线程。此数字应接近于 0 以获得最佳性能。
Avg. wait time 与上述数字相关。如果没有线程正在等待,则此数字应为 0。
Avg. pool size 启用溢出时实际使用的连接池大小。此数字应接近实际最小的连接数量。
表 2. JVM 指标
属性描述
Free memory (JVM)空闲堆。如果数字接近 0,考虑增加堆大小。
Total memory最大堆大小
Free memory (system)从操作系统角度来看可用的内容。这是衡量操作系统是否需要更多 RAM 的一个重要指标。
Avg. CPU usage系统中的总体 CPU 使用率。理想情况下,CPU 应是第一个瓶颈,并且如果您无法提供 CPU 使用率,则可能存在其他瓶颈,比如磁盘输入/输出、网络输入/输出或内存等问题。
表 3. Web 应用程序指标
属性描述
Response time事务完成所需的时间,以毫秒为单位。根据事务的不同,它可能被接受也可能不被接受。
# of errors失败的事务可以建议连接超时、应用程序错误/异常,或其他环境问题。
Total requestsWebSphere 接收的请求,这是通信是否如预期一样进入的很好体现。
Concurrent requests任意给定时间的并行请求,这体现了一次在线用户数。
表 4. 会话管理器指标
属性描述
Created sessions活动 JVM 中的历史会话计数。
Invalidated sessions已过期或超时的历史会话计数。
Live sessions目前尚未过期的会话。
Session lifetime会话的平均生存期。这是设置为会话超时值的一个最优数字。
Active sessions携带事务的会话。
表 5. 线程池指标
属性描述
Thread creates在不同线程池中创建的新线程数量:web container、default 和 ORB。
Thread destroys损坏的线程数量。
Active threads目前执行任务的活动线程。
Pool size支持在不同 WebSphere 线程池中重用线程的线程池大小。
% time max in use低 % 意味着线程快速完成任务,但在回收它们之前必须结束不活跃状态。您应该缩短不活跃状态超时值,以很快地将线程放回池中。

故障排除

本部分介绍了一个实际案例研究,描述了如何使用本文中的 WebSphere 监控工具来解决堆耗尽问题。

原始声明和标准是:在此生产系统上,有大约 170 MB 到 180 MB 的对象请求,这会使堆大小快速增加并导致系统故障。一旦问题真正被确定为堆耗尽,下列步骤可帮助确定原因。

  1. 验证发生堆转储的 WebSphere 应用程序日志。清单 6 显示了一个 native.log 文件示例。
清单 6. 样例 native.log 条目表明发生了堆转储
[Thu Jul 23 04:08:47 2009] JVMDG217: Dump Handler is Processing Signal 11
- Please Wait. Explanation: A signal has been raised and is being processed 
by the dump handler. System action: At this point, depending upon the 
options that have been set, Javadump, core dump, and CEEDUMP (z/OS only) 
can be taken. This message is for information only and does not indicate 
a further failure. User response: None.

[Thu Jul 23 04:08:47 2009] JVMDBG001: malloc failed to allocate 2621440 
bytes, time: Thu Jul 23 04:08:48 2009 Explanation: The system malloc 
function has returned NULL System action: None for this message. The 
JVM might issue a further message. User response: Increase the available 
native storage.  [Thu Jul 23 04:08:47 2009] JVMDBG001: malloc failed 
to allocate 2097152 bytes, time: Thu Jul 23 04:08:48 2009 Explanation: 
The system malloc function has returned NULL System action: None for 
this message. The JVM might issue a further message.

User response: Increase the available native storage.
  1. 以固定间隔收集 verbosegc 和堆转储。要识别堆增长,进行几个堆转储,包括从测试开始(不会发生堆溢出)到出现堆溢出时。可以使用 PMAT 工具查看 verbosegc 输出,并且它显示了随时间变化的堆使用率。图 2 基于案例研究的目的显示了测试期间出现的堆使用率峰值。
图 2. 样例 verbosegc 分析输出
屏幕图:详细的 GC 分析程序图显示了具有 6 个使用率峰值的 GC 活动
屏幕图:详细的 GC 分析程序图显示了具有 6 个使用率峰值的 GC 活动

在非高峰时间进行的类似堆转储分析显示了没有 JVM 使用率峰值,并且它们仍然为最大 400 MB。但是,当堆使用率很高时,HeapAnalyzer 显示使用的 TCRMContractBObj 接近于 1GB 的堆,如图 3 所示。

图 3. 样例堆转储分析
屏幕图:堆转储显示了 TCRMContractBObj 的超过 40,000 个数组
屏幕图:堆转储显示了 TCRMContractBObj 的超过 40,000 个数组

在图 2 的堆的树视图中,有 40,252 个名为 TCRMContractBObj 的对象,每个在堆中都占用接近 30 KB 的内存。累计影响是 909 MB 的堆使用率。您可以推测到这是堆溢出的根本原因。

  1. 检查事务以查看业务代理中的单个 getFSParty 调用实际查询超过 40,000 个联系对象的特定参与方。建议为具有大量联系人的精英客户端实现更复杂的检索逻辑。这将永久性地解决问题。

调优 JVM

MDM Server 没有最佳 设置。对于 WebSphere Version 6.1(用于 MDM 8.0 和更新版本),表 6 给出了 AIX 的建议起始值。您应相应地调整它们。

表 6. 调优 JVM 的起始值
调优参数AIX 的建议值
JVM initial heap size (MB)512
JVM maximum heap size (MB)1024
GC policy recommendations如果使用 SMP 系统则为 -Xgcpolicy:gencon(与在大多数情况下一样)
Minimum active threads (in pool)70 个线程
Maximum active threads (in pool)70 个线程
Allow threads allocated beyond maximum不支持
Thread inactivity timeout100 秒
Maximum in-memory session count1000
Session timeout10 分钟
JDBC connection pool connection timeout10000 秒
JDBC connection pool min connections30:需要相应地调整数据库服务器设置
JDBC connection pool max connections100:需要相应地调整数据库服务器设置
JDBC connection pool connection timeout10000 秒
RC4 and MD5 encryption如果在安全环境中部署 WebSphere Application Servers 则禁用

下面是关于一些起始值的注意事项:

设置大于 512MB 的 JVM 堆大小
为了获得最佳和最一致的吞吐量,将(-Xms)起始最小值和(-Xmx)最大值设置为相同大小。此外,记住,JVM 堆大小的值与系统上的物理内存数量直接相关。不要将 JVM 堆大小设置为大于系统上物理内存的值,以避免由于交换而导致的磁盘输入/输出。
会话超时 10 分钟
会话超时的默认值为 30 分钟。将此值降低为一个较小的数字可帮助降低内存消耗,支持更高的用户负荷持续较长的时间。将此值降低太多可能会影响用户体验。您需要根据最终用户的需求确定恰当的级别:如果用户通常要完成快速任务,将此值设置为低值;如果用户要完成长任务,将此值设置为高值。
类垃圾收集
Xgcpolicy:gencon 处理短期对象和长期对象的方式不同。许多 MDM 工作负载生成许多短期对象,并且暂停时间较短。对许多 MDM 工作负载来说,此参数可支持大约 10% 的吞吐量增加。
Servlet 引擎线程池大小 70
对于用例,最小和最大设置都是 70。理想情况下,使用 PMI 设置此值并监控结果。如果大多数时间所有 servlet 线程都很忙,则增加此值。
JDBC 连接池最大数
根据预期的并发用户数量和用作 MDM 应用程序服务器的 JVM 数量,使用数据源连接池来缓存用户负荷并高效建立查询的数据库连接。JVM 的所有最大连接的总和不应超过该数据库引擎,这由 DB2 UDB 中的 MAXAPPLS 指定。
禁用加密
EJB 之间的通信可配置为使用 SSL,但是如果 MDM 应用程序服务器已位于安全环境(大多都为安全环境)中,则不需要它们。不使用加密和解密可节省大约 15% 的 CPU 处理能力。

结束语

本文强调了下列内容的重要性:

  • 了解整体概况
  • 设置明确的性能目标
  • 了解您的环境
  • 建立可重复的一致的性能测试流程。

重要指南介绍了如何高效地监控、调优和优化 MDM Server 和 WebSphere Application 层以获得最佳性能,还讨论了在这两个层中影响性能的关键领域和功能列表的最佳实践。本系列文章的 第 2 部分 介绍堆栈的底层部分,包含了有关如何高效地监控和调优 DB 2 层的指南和建议。第 2 部分 还展示了监控操作系统级别的资源常用的工具。

致谢

我们要感谢 David Borean、Lena Woolf、Bill Xu、Steve Reese 和 Berni Schiefer 为本系列文章提供的内容和建议。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management, WebSphere
ArticleID=676757
ArticleTitle=监控和调优 InfoSphere Master Data Management Server,第 1 部分: 设置目标和调优基础架构的每一层
publish-date=06022011