内容


IBM InfoSphere DataStage Operations Console 配置和调优指南

Comments

Operations Console 概述

  • 价值
  • InfoSphere Information Server 环境中的组件
  • 性能特征
  • 影响性能的因素
  • 最大程度地减小性能影响的调优指南
  • 监视数据库健康状态
  • 容量规划
  • 结束语
  • 致谢

价值

Operations Console 提供了一个详细的历史视图以及对 InfoSphere Information Server 操作环境的完整系统健康检查。Operations Console 提供了:

  • 一个可配置的时间段的作业运行时活动的高级视图
  • 对比作业之间的运行时信息的能力
  • 一个可配置的操作系统资源视图
  • 一个项目视图过滤机制
  • 作业和作业运行的摘要和详细视图
  • 作业运行故障的可视警告
  • 可配置的警告阈值
  • 分析作业运行活动的能力
  • 整个引擎的资源使用视图
  • 性能和日志对比的作业运行分析

Operations Console 使用一个记录来自 InfoSphere DataStage 的所有操作信息的关系数据库,使用户能够成功监视和了解 InfoSphere DataStage 环境的性能。在 参考资料 中可以找到一个 Operations Console 演示。

InfoSphere Information Server 环境中的组件

在开始探讨调优 Operations Console 之前,让我们看看它的工作原理。图 1 显示了 Information Server 环境中存在的主要的 Operations Console 组件(用蓝色突出显示)。

图 1. Information Server 环境中的 Operations Console 组件
该图显示了 Information Server 环境中的 Operations Console 组件
该图显示了 Information Server 环境中的 Operations Console 组件

如图所示,Operations Console 在架构上包含 Operations Database、一个基于 Web 的客户端,以及内置于 InfoSphere Information Server 的引擎层和服务层中的组件。Operations Database 会存储操作数据,从而允许更新和查询该数据。引擎层中的 Operations Console 组件包括:

  • 服务状态检查器,用于监视监视流程的状态和健康情况
  • 作业事件监视器,用于收集和聚合作业统计信息和运行时事件日志,更新 Operations Database
  • 系统资源监视器,用于监视系统资源(CPU、内存和磁盘等)利用率,更新 Operations Database
  • 查询 Operations Database 的服务

服务层中的 Operations Console 组件包括查询 Operations Database 的服务。客户端层中的 Operations Console 组件包含 Operations Console 的基于 Web 的客户端。

主要的 Operations Console 操作可分配为加载和查询操作。对于加载操作,当启用了 Operations Console 时,系统收集和聚合作业执行详细信息(参数、状态、统计信息和日志等)和系统资源利用率(CPU、内存和磁盘等)信息,将以较短的间隔定期将它们插入 Operations Database 中。对于查询操作,当使用基于 Web 的客户端监视作业执行或查看作业运行历史时,会提交针对 Operations Database 的查询,信息会使用服务层中的服务检索。为了支持这些操作,Operations Console 需要使用引擎层、服务层和 Operations Database 服务器中更多的系统资源(CPU、内存和 I/O)。但是,系统资源要求并不是同等地应用于这些层(请参阅本文后面的 “Operations Console 容量规划” 一节,了解有关的详细信息)。

性能

图 2 显示了 Operations Console 对具有默认配置设置的 InfoSphere DataStage 的性能影响。该图显示了拥有和没有 Operations Console 时的作业吞吐量的开销比率。

图 2. Operations Console 的性能影响与系统 CPU 利用率对比
该图显示了 Operations Console 的性能影响与系统 CPU 利用率对比
该图显示了 Operations Console 的性能影响与系统 CPU 利用率对比

性能测试是在包含 4 个节点(计算机)的 InfoSphere DataStage 集群环境中执行的,每个节点拥有 4 个 CPU。测试结果基于默认 Operations Console 设置,运行了 10 个 Web 会话。InfoSphere Information Server 引擎的扩展设计允许作业跨多个计算机运行。其中一个计算机指定为主要节点或 “头节点”。这个主要节点是 Information Server 客户端对其验证引擎凭据的节点。它也是执行引擎层中的 Operations Console 代码的地方。

如图 2 所示,当主要节点的 CPU 利用率低于 90% 时,Operations Console 对 InfoSphere DataStage 性能的影响无足轻重。即使 Operations Console 利用了一些 CPU 资源,利用率也在 10% 以下,因此在主要节点上存在空余 CPU 资源时不会影响到作业性能。但是,当工作负载将主要节点的 CPU 利用率提高到超过 90% 时,Operations Console 的开销将导致对作业的性能产生一定的影响。作业的吞吐量会平稳地降低,在 CPU 被全部利用时可能降到 10% 以下。请注意,在不同服务器模型或 InfoSphere Information Server 引擎配置下(在单一计算机、一个集群或一个网格中运行),在您看到 Operations Console 带来影响之前,CPU 的利用率可能是不同的。但是,此阈值通常很高,而且 Operations Console 的开销在一些测试场景中可忽略不计。

影响性能的因素

如图 2 中所示,Operations Console 的默认配置会导致可忽略的性能开销,除非在超出主要节点上的 CPU 利用率阈值时。有一些因素可能影响 Operations Console 对 InfoSphere Information Server 运行时性能的影响程度:

  • Operations Console web 会话的数量和它们的刷新间隔
  • 收集监视数据的频率
  • 收集的监视数据量
  • 更新 Operations Database 的时间间隔

Web 会话的数量无法进行配置,但其他性能因素可能受配置参数控制。您可以配置的参数的完整列表可在 <Installation_Directory>/Server/DSODB/DSODBConfig.cfg 配置文件中找到。表 1 显示了配置参数列表。

表 1. DSODBConfig.cfg 中的参数
参数描述默认值
MaxWarnings在每次作业运行中可发送到 Operations Database 的警告消息的最大数量。10
UpdateIntSecs更新总体运行统计信息的连续事件之间的间隔(以秒为单位)。10 秒
TraceMax在启用跟踪时要写入跟踪文件的最大行数。禁用
JobRunCheckInterval自动验证目前运行的作业的间隔(以分钟为单位)。60 分钟。
JobRunUsage定义是否收集作业运行资源使用数据。启用
JobRunAggSnaps在开始新行之前,包含在一行中的快照值数量。15
ResourceMonitor定义是否收集系统资源数据。启用
ResourcePollPeriod制作资源快照的频率(以秒为单位)。10 秒
ResourceSampleSize在存储这些值的聚合记录之前制作的快照数量。6
ResourceAllAggregatedUsage定义是始终存储资源使用数据(启用)还是仅在有一个作业活动时存储资源使用数据(禁用)。启用
ResourceAggRunPollPeriod在禁用 ResourceAllAggregatedUsage 时,在检测到任何作业活动之前和之后自动存储的聚合快照数量。10
ResourceAggNonRunPollPeriod在禁用 ResourceAllAggregatedUsage 时,检查是否存在作业活动的频率(以分钟为单位)。1 分钟

如果系统配置或其中一些参数更改,图 2 中的性能影响阈值可能左移或右移。例如,如果系统配置由于添加了更多 CPU 而发生更改,Operations Console 服务的 CPU 使用百分比将相对较小,Operations Console 的性能影响会更小,因此图 2 中的阈值会右移。甚至可以通过更改一些配置参数,进一步最小化 Operations Console 的资源使用。影响 Operations Console 性能的两个重要因素是更新间隔和 Operations Console 用户 Web 会话数量。

图 3 描述了主要节点上的 Operations Console 服务在收集信息和加载 Operations Database 的更新间隔(UpdateIntSecs 参数)中的 CPU 利用率。该图显示了 3 个更新间隔:2 秒、5 秒和 10 秒。

图 3. 不同更新间隔的 Operations Console CPU 使用
该图显示了主要节点上的 Operations Console 服务在收集信息和加载 Operations Database 的更新间隔中的 CPU 利用率
该图显示了主要节点上的 Operations Console 服务在收集信息和加载 Operations Database 的更新间隔中的 CPU 利用率

如图所示,有了在特定计算机上运行的特定工作负载(每天运行大约 40,000 个作业,服务于 10 个 Operations Console web 会话),当更新间隔为 2 秒时,Operations Console 服务会使用大约 16% 的 CPU 资源。但是,如果更新间隔延长,这些进程会使用更少的 CPU 资源:在使用 5 秒的间隔时,大约使用 12% 的 CPU 资源,在使用 10 秒的间隔时,大约使用 9% 的 CPU 资源。

图 4 显示了不同 Operations Console Web 会话数量的性能影响。会话数量从 10 减少到 1,一个额外的数据点显示了 Operations Console 关闭时的性能。

图 4. 对于不同的 Operations Console Web 会话数量,Operations Console 对吞吐量的影响
该图显示了在具有不同的 Operations Console Web 会话数量时,Operations Console 对吞吐量的影响
该图显示了在具有不同的 Operations Console Web 会话数量时,Operations Console 对吞吐量的影响

如图所示,对于特定的工作负载(CPU 利用率达到主要节点中总 CPU 容量的 97%),Operations Console Web 会话越少,Operations Console 的性能影响就会越不明显,从 10 个 Operations Console Web 会话产生大约 7% 的吞吐量影响,到 1 个 Operations Console Web 会话仅产生 1% 的影响。

如果有足够的容量留给 Operations Console 在 InfoSphere Information Server 引擎中运行,那么 Operations Console 对 InfoSphere Information Server 不会产生任何性能影响。但 Operations Console 的影响可能在服务器受限和达到阈值时显现出来。根据 Operations Console 的配置,Operations Console 对性能的影响可能有所不同。如果将 Operations Console 配置为收集较少量的监视数据,较少地插入或更新 Operations Database,或者支持更少的 Operations Console web 会话,那么影响就会相对不明显。

最大程度地减少性能影响的调优指南

正如前面所讨论的,Operations Console 可能在 InfoSphere Information Server 引擎变得受限时影响作业的性能。当发生此性能影响时,您需要更大程度地调优 Operations Console。作为一个高性能信息集成平台,InfoSphere Information Server 包含一个有效且可扩展的引擎,该引擎被设计为在需要时积极地利用可用的系统资源(例如 CPU 和内容)。在运行某些工作负载时,常常会看到 InfoSphere DataStage 使 CPU 利用率涨到非常高的水平(超过 90%)。在这些场景中,Operations Console 可能会影响作业的性能。您可以配置一些调优参数来让性能影响不那么明显。

可对查询操作和加载操作执行调优。对于查询操作,要使 Operations Console 的影响不那么明显,可以将 Operations Console Web 客户端的刷新间隔更改为一个更高的值,或者关闭甚至在用户为主动与客户端交互时也会定期查询 Operations Database 的不必要的 Operations Console 会话。对于加载操作,尽管 DSODBConfig.cfg 文件中的参数的默认设置被视为最佳设置,但您仍然可以利用一个或多个参数的设置,减少要收集的监视数据量或降低更新 Operations Database 的频率。表 2 列出了这些可调节的参数。

表 2. DSODBConfig.cfg 文件中的可调节参数
参数操作和结果
MaxWarnings减少该数量会导致收集更少的数据。
UpdateIntSecs增加该数量会得到更低的更新频率。
TraceMax如果启用此参数,降低该数量会减少向跟踪文件写入数据的成本。
JobRunCheckInterval降低该数量会减少用户验证运行的作业的时间比例。
JobRunUsage禁用此选项会导致收集更少的数据。
JobRunAggSnaps增加此数字会导致收集更少的数据。
ResourceMonitor禁用此选项会导致收集更少的数据。
ResourcePollPeriod增加此数字会导致收集更少的数据。
ResourceSampleSize增加此数字会导致收集更少的数据。
ResourceAllAggregatedUsage禁用此选项会导致收集更少的数据。
ResourceAggRunPollPeriod如果禁用了 ResourceAllAggregatedUsage,减小此数字会导致收集更少的数据。
ResourceAggNonRunPollPeriod如果禁用了 ResourceAllAggregatedUsage,那么增加此数字会导致收集更少的数据。

监视 Operations Database 的健康状况

除了谨慎设置 Operations Console 的配置参数,还应该监视 Operations Database,确保它们具有足够的系统资源来支持数据库服务,并且数据库是健康的。

您应该运行系统监视工具(比如 nmon、iostat、vmstat 和 mpstat)来确保运行 Operations Database 的服务器中的 I/O 和内存中不存在瓶颈,并且未超过 CPU 上限。请密切注意动态查询执行时间和 Operations Database 中的表空间使用。Operations Database 中的动态查询执行的性能对 Operations Console 的 Web 客户端的响应时间具有直接和显著的影响。监视 Operations Database 中的动态查询执行是诊断缓慢的操作的第一步。

要获得 Operations Database 中的动态查询执行的快照,您可以使用 DB2® 快照实用程序,比如发出命令 db2 get snapshot for dynamic sql on dsodbdb,其中 dsodbdb 是 Operations Database。或者您可以使用 db2top 监视工具来动态显示 Operations Database 中的动态查询的性能,例如发出命令 db2top —d dsodbdb,其中 dsodbdb 是 Operations Database,然后选择选项 D 来显示动态查询。图 5 显示了 Operations Database 中的动态查询的输出。(对查询调优的讨论不属于本文的范畴。但是,如果有必要,您可依照特定数据库产品供应商提供的查询调优指南来执行性能调优。)

图 5. Operations Database 中的动态查询
该图显示了 db2top 输出,该输出中显示了动态查询
该图显示了 db2top 输出,该输出中显示了动态查询

另一个有趣的区域是 Operations Database 的表空间的使用模式。它将使您能够很好地了解您的 InfoSphere DataStage 工作负载和 Operations Console 设置将需要多少磁盘空间。表空间的使用模式可通过两个相隔一天、一周或其他间隔的连续快照来计算。您可以基于两个连续快照的差别来计算使用率,预测将需要多少磁盘存储空间。一种获得表空间使用率快照的简单方法就是连接 Operations Database,运行命令 db2 list tablespaces show detail。图 6 显示了该命令的输出。

图 6. DSODB Operations Database 的表空间输出
该图显示了 DSODB Operations Database 的表空间输出
该图显示了 DSODB Operations Database 的表空间输出

容量规划

如上所述,启用 Operations Console 需要额外的系统资源。为 Operations Console 分配足够的硬件资源是最小化可能产生的系统性能影响的一个重要举措。表 3 显示了每层的最低硬件要求。

表 3. Operations Console 的硬件要求
InfoSphere Information Server 引擎服务层托管 Operations Database 的数据库服务器
CPU(基于一个 IBM x3650 M3 7945/82Y X5690 或等效机器的一个 CPU 核心)0.250.251
内存 (GB)0.40.42
磁盘 (GB)0.2不适用每 10,000 个作业执行 5 + 0.5
备注内存是 Operations Console 的默认设置(即 384 MB 的最大 Java™ 堆大小)。磁盘存储需求供 DataStage 存储将在以后删除的一些短期的临时文件。内存需求用于增加 WebSphere® Application Server 的最大 Java 堆大小,以处理 Operations Console 服务带来的额外的负载。系统需求包含 DB2 for Linux®, UNIX®, and Windows® 的安装。

Operations Database 可放在一个专门的计算机上。或者如果元数据存储库层中有足够的系统资源,Operations Database 可放在与元数据存储库相同的数据库实例。但是,在将引擎层安装在自己的计算机上以保证性能时,不建议将 Operations Database 放在引擎层中。

结束语

本文演示了 IBM InfoSphere DataStage Operations Console 的工作原理,探讨了影响 Operations Console 的资源影响的性能因素。如果 InfoSphere Information Server 引擎拥有足够的空余 CPU 资源来运行 Operations Console,Operations Console 的性能影响可以忽略不计。但是,如果服务器资源受限,性能影响可能变得很明显。本文提供了最大程度减少此类性能影响的指南。而且,本文探讨了如何监视 Operations Database,以及需要多少磁盘存储空间来存储工作负载的监视信息。最后,本文提供了有关 Operations Console 的容量规划的信息。总之,有了分配了足够的系统资源并进行了合适的调优,在需要时,您可运行 Operations Console 来以极小或可忽略的开销利用它的许多有用功能。

致谢

非常感谢为本文提供了宝贵的输入、编辑和审核的贡献者们:

  • Sriram Padmanabhan,杰出工程师和首席架构师,InfoSphere Servers
  • Len Greenwood,DataStage 和相关组件的 Information Server 架构师
  • Tony Curcio,InfoSphere 产品管理
  • Kiran Surapaneni,InfoSphere 产品管理
  • Mi Wan Shum,经理,InfoSphere Information Server Performance

相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=835364
ArticleTitle=IBM InfoSphere DataStage Operations Console 配置和调优指南
publish-date=09172012