关于 Remote Management Agent 和 Tivoli Enterprise Console 的性能分析报告

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

Ryan Brown (ryanab@us.ibm.com), 软件工程师, IBM

2006 年 6 月 22 日

本文是 IBM® Remote Management Agent Version 1.0 Build 543（随 IBM WebSphere® Remote Server 5.1.2.1 提供）和 IBM Tivoli® Enterprise Console Version 3.9（带有 Fixpak 3）的性能分析报告。

引言

IBM Remote Management Agent 是 IBM Store Integration Framework 的组件，后者可简化商店中面向客户的新设备的交付，以支持服务的交付。Remote Management Agent 将监视和管理多个店内 IT 设备，以通过帮助提高客户满意度、员工效率和收益，从而提供系统可用性。IBM Tivoli Enterprise Console 提供了自动问题诊断和解决，以提高系统性能和减少支持成本。Tivoli Enterprise Console 还提供事件管理和问题根源分析与解决。

本性能分析报告的目标是：

• 了解 Remote Management Agent 在高压的模拟商店环境中的性能和极限。
• 了解 Tivoli Enterprise Console 的性能和极限，并提供有关如何提高性能的建议。

回页首

策略场景

为了测试 Remote Management Agent 服务器性能，开发了一个自定义工具，来创建其数量可配置的普通代理（General Agent，GA）。GA 随后在指定的时间内生成事件和方法调用。提出的问题有：

• 主代理是否可以处理大量的普通代理（100 个或更多）？
• 主代理是否可以处理大量的虚拟 MBean （5000 个或更多）？
• 主代理可以处理的最大事件频率是多少？

对于 Tivoli Enterprise Console 性能测试，使用了相同自定义工具来生成事件。事件将随后转发到 Tivoli Enterprise Console，以便度量性能极限。我们希望了解以下问题：

• Tivoli Enterprise Console 能有效处理的事件的数量？
• 可以进行哪些工作来提高 Tivoli Enterprise Console 的性能？

回页首

硬件和软件细节

下面列出此测试工作所使用的硬件和软件。

Tivoli Enterprise Console 3.9 服务器

• Dual Intel® Xeon® 2.4 GHz 处理器
• 2 GB RAM
• Novell® SuSE® SLES 8，内核版本 SMP - 2.4.21-295 操作系统
• 100 Mbit LAN
• IBM DB2® v8.1，FixPak 4
• Tivoli Configuration Manager v4.2.3
• Tivoli Enterprise Console v3.9，FixPak 3

Remote Management Agent 服务器

• Intel Xeon 2.4 GHz 处理器
• 2 GB RAM
• SuSE SLES 9，内核版本 2.6.8-24.14 操作系统
• 100 Mbit LAN
• Remote Management Agent v1.0，Build 543

度量工具

使用了以下 Unix® 系统工具：

• top
• vmstat
• netstat
• ntop

top 命令提供持续的实时处理器活动信息。它将显示系统上 CPU 使用最密集的任务的列表。可以按照 CPU 使用量、内存使用量和运行时进行排序。

vmstat 命令度量和记录测试期间 CUP 和虚拟内存使用量。它将计算用户指定的采样时间内的内存、分页和 CPU 活动的统计平均值。vmstat 命令通常在前台的独立 xterm 窗口中运行，其输出将发送到终端。也可以在后台运行该命令，并将输出重定向到文件。主要参数是采样间隔（以秒为单位）。以下命令将以 5 秒的采样间隔运行 vmstat，并将输出重定向到文件：

vmstat 5 > vmstat.log

此命令会创建名为 vmstat.log 的文件。vmstat 输出的重要字段如下所示。

内存：

• swpd：虚拟内存的使用量。
• free：空闲内存量。
• buff：作为缓冲区使用的内存量。
• cached：作为高速缓存使用的内存量。

CPU：

• us：用于运行非内核代码的时间。
• sy：用于运行内核代码的时间。
• id：空闲时间。

netstat 命令提供了很多选项，可显示关于系统上的网络接口的各种信息。相关的输出包括网络连接、路由表、接口统计数据。

ntop 命令显示其他网络信息。可以在浏览器（如 Mozilla™ FireFox®）中通过访问 http://localhost:3000 对其进行查看。ntop 命令显示当前使用网络的主机列表，并报告关于每个主机生成和接收的通信流量的信息。

回页首

计算机配置

为了测试 Remote Management Agent 的功能和极限，所用的服务器是 SLES 9 计算机，具有 2 GB RAM，使用 2.4 GHz 处理器。服务器通过私有百兆网连接到另外多台基于 Intel 技术的计算机上，这些计算机均运行自定义 Remote Management Agent 负载测试工具。这些 Intel 计算机均可运行很多 (50-100个)个普通代理。

为了测试 Tivoli Enterprise Console 的功能和极限，使用的设置与此类似。在 Remote Management Agent 服务器上启动了 SNMP 捕获映射器，以便将事件转发到 Tivoli Enterprise Console。各个计算机仍然都连接到私有百兆网。

回页首

优化建议

本部分提供了提高 Remote Management Agent 和 Tivoli Enterprise Console 服务器性能的建议。

回页首

Remote Management Agent 服务器

Remote Management Agent 服务器是 CPU 受限的，即 CPU 的速度或数量直接影响服务器的吞吐量。如果预期 Remote Management Agent 服务器将接收每分钟超过 1000 个事件或 6000 个调用，则最佳解决方案是添加更多的 CPU。否则，请尝试在 Remote Management Agent 服务器上限制事件和调用的数量。本文的目的不是提供深入的优化指南，有多本包含提高整体系统性能的其他建议的 IBM 红皮书，如《Highly Available Architectures and Capacity Planning with WebSphere Remote Server V5.1.2.1》。

我们也对 Remote Management Agent 服务器的内存使用进行了监视，发现其影响并不大。具有 2 GB 的 RAM 的计算机完全足以从容处理这个事件速率。同样，每分钟 1400 个事件的网络流量看起来对 LAN 环境也很合适。测试的详细信息请参阅Remote Management Agent 测试结果。

回页首

Tivoli Enterprise Console 服务器

此测试的目的是为了验证 Tivoli Enterprise Console 服务器的事件处理能力和极限。与 Remote Management Agent 服务器一样，Tivoli Enterprise Console 服务器也是 CPU 受限的，增加 CPU 的数量或质量能极大地提高吞吐量。在计算所需的硬件时，服务器上每秒的事件总量是要主要考虑的内容。节省处理能力的最佳办法是在传入的事件到达服务器前限制其数量。

以下提示基于 Tivoli Enterprise Console 3.9 性能报告：

• Tivoli Enterprise Console 服务器是 CPU 受限的，即 CPU 的速度直接影响服务器的吞吐量。
• Tivoli Enterprise Console 可以利用多处理器技术。决定要部署一台 4 处理器的计算机，还是部署两台 2 处理器的计算机（Tivoli Enterprise Console 服务器和 RIM_host/RDBMS 分别安装在这两台计算机上）时，请注意双计算机环境中会存在由于网络延迟而导致的吞吐量损失。对于简单或中等复杂程度的规则库，请选择较慢的双处理器计算机，而不要选择较快的单处理器计算机。使用复杂规则库时，请考虑使用较快的单处理器计算机，因为规则引擎将成为此种环境中的瓶颈。
• 在服务器和 RDBMS 间使用 100 Mbit 或更好的网络连接。
• 将 Maximum number of event messages buffered in memory 设置为高于预期连续事件峰值的值。这可防止在缓冲区溢出时服务器进行额外的 CPU 和磁盘工作。
• 优化数据库缓冲池，并检查日志空间的大小是否足够。数据库溢出可能导致事件处理的延迟。有关如何进行此操作的详细信息在Tivoli Enterprise Console 的示例 DB2 配置更新中进行讨论。
• 为规则库执行的程序计划额外的 CPU 容量。
• 为过多的 Java™ 控制台或 Web 控制台计划额外的 CPU 容量。Java™和 Web 控制台都直接访问 RDBMS 并运行额外的 RIM 进程。
• Tivoli Enterprise Console 服务器并不是内存密集型的服务器。即使 RIM 和 RDBMS 位于相同的计算机上，2 Gb 的内存也足够了。对于复杂规则库和规则库执行的额外程序，可能会需要更多内存。
• 事件吞吐量受服务器的速度限制。网关和端点的数量几乎没有任何影响。因此，每秒钟的事件总量是一个主要的设计标准。

回页首

Remote Management Agent 测试结果

在 Remote Management Agent 服务器的测试期间，使用了两个独立的负载测试工具。这两个工具的基本设计完全相同，但实现方法不同。第一个工具有几个缺点，例如为普通代理使用的是交叉启动时间。第二个负载测试工具经过改进来处理这些问题。不过，从最初的测试中也得到了一些有用的测试结果。具体来说，进行了长达 2 个小时的高事件率长时间运行，记录了一些测试的网络使用情况。另外，使用第一个工具进行的测试是尝试模拟更为真实的客户环境，计算机的配置是针对小型和中型商店。使用第二个测试工具完成的测试重点是在于达到服务器处理事件和方法调用的能力的极限。

创建这两个 Remote Management Agent 负载测试工具都是为来运行压力测试，以了解 Remote Management Agent 服务器可以处理多少普通代理、Mbean、JMX 事件和方法调用。为了测试此内容，创建了三个组件：

1. 一个普通代理模拟器，可创建能发送事件的 Mbean。
2. 一个事件侦听器，对来自每个普通代理事件进行计数。
3. 一个用于 Remote Management Agent 的工具，用于调用从General Agents代理的 MBean 的各个方法。

组件 1 在“普通代理计算机”（可为任何计算机）上运行，而组件 2 和 3 则在“主代理计算机”（任何安装了 Remote Management Agent 的计算机）上运行。

用于此测试的计算机硬件和软件配置在硬件和软件细节中进行了说明。

测试结果：负载测试工具 #1

Remote Management Agent 测试中使用的计算机配置如下：

• 初始测试：1 个普通代理，1 个 Mbean，每分钟是 10 个事件。
• 小型商店：2 个普通代理，每个普通代理 30 个 Mbean，每个普通代理每分钟 60 个事件，每个普通代理每分钟 10 个方法调用。
• 中型商店：25 个普通代理，每个普通代理 30 个 Mbean，每个普通代理每分钟 60 个事件，每个普通代理每分钟 10 个方法调用。

使用了自定义 Remote Management Agent 负载测试工具来使用一台或四台 Intel 计算机生成普通代理、Mbean、事件和调用，所使用的计算机数量取决于所需的负载。初始测试包括在小型商店和中型商店环境上测试 5 分钟、30 分钟和 2 小时内运行预先确定的事件数量。负载测试将对每个设置重复两次，得到的结果记录在下表中。

表中包含以下列：

• 时间：负载测试运行的总时间。
• CPU 使用率：平均 CPU 使用率。此信息是通过检查 top 和 vmstat 日志得到的。
• 网络使用率：Remote Management Agent 服务器上的网络通信流量的描述。
• 其他说明：有关特定负载测试运行的任何其他说明。

尽管在“中型商店”配置的 30 分钟和 2 小时的测试中并未监视网络使用率，但可以从 5 分钟的测试（实际完成用了 15 分钟）中计算出一个粗略的近似值。总共 8250 个事件和 14 分钟可换算为约每分钟 590 个事件。假定所测试的 Remote Management Agent 服务器可以处理大约 1400 个事件/分钟，则可预计网络通信流量能达到 171.4 Kpbs 或 342 Kbps 的 2.3 倍。在 LAN 环境中 (100 Mbit)，这个值并不没有太大的影响。

在“中型商店”环境配置上进行的 2 小时测试中的确丢失了一些事件。这是由于自定义负载测试工具创建的方式所导致的。事件要排队；但是，当普通代理在处理事件前断开时，事件就会丢失。请注意，尽管对 Remote Management Agent 服务器进行了 2 个小时的压力测试，但并没有导致其崩溃，仍然在继续处理事件。如果事件的数量如果稍微低一些，或 CPU 的速度稍微快一些，将会 100% 地完成所有事件处理。

测试结果：负载测试工具 #2

此部分描述 Remote Management Agent 负载测试工具的改进版本。

首先，它会对发现的所有普通代理进行计数，然后告知它们创建各自的 Mbean（使用作为创建 GA 脚本的输入指定的数量）。当每个普通代理完成了其 Mbean 的创建后，将等待所有经过代理的 MBean 创建完成。在完成指定数量的经过代理的 Mbean 的创建前，测试并不会继续。如果未检测到指定数量的 Mbean，工具将会无限期等待。

检测到所有经过代理的 Mbean，主代理工具将告知普通代理开始发送事件。普通代理 MBean 将启动发送事件的新线程。为了确保在发送事件前已启动所有线程，将强制线程等待 30 秒。这并不会影响运行时间。所有线程已启动后，将等待 30 秒再启动计时器。此时，如果指定的方法调用数量大于 0，将启动方法调用。

在指定的时间后，主代理计算接收到的事件总数和每个普通代理接收到的事件。随后，主代理向普通代理发送信号，使其脱机。

以下是使用第二个 Remote Management Agent 负载测试工具所得到的结果。所有的运行时间都是 3 分钟。下面的表中包含以下列：

• # GA：普通代理的总数。
• MBean/GA：为每个普通代理创建的 MBean 的数量。
• 事件/MBean/分钟：每个 MBean 每分钟的时间数量。
• MBean 总数：测试中的 MBean 总数。
• 事件/分钟：每分钟的事件数量。
• 事件/分钟/GA：每个普通代理每分钟的事件数量。
• CPU 平均值：测试期间的平均 CPU 使用率。
• CPU 最大值：测试期间的 CPU 使用率峰值。

将此数据制作成平均 CPU 使用率与每分钟事件的关系图，会发现这个关系是线性的（请参阅图 1）。这进一步表明 Remote Management Agent 是 CPU 受限的。另外还要注意，事件分布情况（即生成事件的普通代理的数量）并不影响 CPU 使用率。事件速率对 Remote Management Agent 服务器很重要。

其他测试结果

下表提供了各种配置的 Remote Management Agent 测试结果。

通过此测试，发现了采用前述硬件和软件配置的 Remote Management Agent 服务器的以下极限：

• 每分钟 1400 个事件或每分钟 6000 个方法调用。
• 79000 个 Mbean。
• 400 个普通代理（这个没有明显限制，但 400 是经过测试的最高数字，这个极限可能比较真实）。
• 混合速率：每分钟 1000 个事件和 4500 个方法调用。

请注意，这些是 Remote Management Agent 服务器将大部分处理能力都用于处理事件和调用时的极限。显然，服务器将会有其他需要处理的任务。应仔细进行规划，确定计算机的硬件是否足以用于此用途。

回页首

Tivoli Enterprise Console 测试结果

Tivoli Enterprise Console 测试相当简单，因为已经有一些文档和 IBM 红皮书对其性能和优化建议进行了讨论。这些建议已在前一部分优化建议中有所提及。此项目的测试包括使用一台 Remote Management Agent 服务器将事件转发到 Tivoli Enterprise Console，从而发现事件处理极限。恰当地对数据库进行了优化并建立了经过简化的规则库后，成功完成了以下测试：

• 4 分钟处理 800 个事件
• 4 分钟处理 1600 个事件
• 4 分 11 秒处理 3159 个事件
• 1 分钟处理 1200 个事件

如前面所述，此测试是在采用双 Intel Xeon 2.4 GHz 处理器的计算机上进行的，其主要处理能力都用在了事件处理上。如果预期输出更高，将需要添加额外的硬件。一个更好的解决方案是通过仅将关键事件转发到 Tivoli Enterprise Console 来限制传入事件。可连接的设备（Remote Management Agent 服务器）数量上没有限制。唯一实际的限制就是事件速率。

回页首

Tivoli Enterprise Console 的示例 DB2 配置更新

可以从 DB2 命令提示符运行以下命令来提高 Tivoli Enterprise Console 的性能：

-- buffer pool for small tables and indexes
CREATE BUFFERPOOL BP_4K_small SIZE 40960 PAGESIZE 4K
-- buffer pool for large tables
CREATE BUFFERPOOL BP_16K_data SIZE 10240 PAGESIZE 16K
-- buffer pool for long column tables
CREATE BUFFERPOOL BP_32K_long SIZE 2560 PAGESIZE 32K
-- (seqdetect is an important parameter but defaults to the correct value of 'yes' 
for Tivoli Enterprise Console)
-- maxlocks is the percentage of locks held in the locklist before lock escalation occurs.
update db cfg for tec using maxlocks 70
-- locklist is the number of 4K pages to maintain the list of locks held
update db cfg for tec using locklist 200
-- locktimeout is the # of seconds to wait to obtain a lock
update db cfg for tec using locktimeout 60
-- the number of threads available to write changed pages in the buffer to disk
update db cfg for tec using num_iocleaners 16
-- the number of threads available to prefetch pages into the buffer pool
update db cfg for tec using num_ioservers 12
-- specifies how many frequency values to collect for columns for runstats processing
update db cfg for tec using num_freqvalues 40
-- space in 4K pages to save table descriptor settings for triggers/procedures
update db cfg for tec using catalogcache_sz 50
-- size in 4K pages to set aside for static and dyname SQL compilations
update db cfg for tec using pckcachesz 75
-- space in 4K pages to buffer before writing changes to the transaction log
update db cfg for tec using logbufsz 20
-- size in 4K pages to make the private/shared sort areas
update db cfg for tec using sortheap 350
-- the number of commit requests to bundle if requests occur in less than 1 second
update db cfg for tec using mincommit 10

还可以进行其他数据库管理，如在对表进行了大量更改时对 Tivoli Enterprise Console 表执行 reorg 命令。表中信息的添加、删除和更新将导致数据变得杂乱，检索杂乱的数据更为费时。reorg 命令通过重新构造行来消除碎片数据，从而对表进行重新组织。还可以对信息进行压缩来提高性能。

回页首

结束语

本文提供了在零售环境中运行 Remote Management Agent 和 Tivoli Enterprise Console 软件可能看到的性能结果的示例。其中一个主要概念是，Remote Management Agent 和 Tivoli Enterprise Console 通常都是 CPU 受限的，通常可以通过限制转发到企业的事件数量或提高处理能力来获得最佳结果。本文还通过配置建议和 DB2 优化技巧提供了有关提高性能的建议。

参考资料

• 您可以参阅本文在developerWorks全球站点上的英文原文。
  
  
• Highly Available Architectures and Capacity Planning with WebSphere Remote Server V5.1.2.1
  
  
• Tivoli Enterprise Performance Tuning Guide
  
  
• Event Management and Best Practices
  
  
• Enable the On Demand Store with IBM Store Integration Framework

关于作者

		Ryan Brown 是北卡罗来纳州 IBM Raleigh Lab 的一名软件工程师。他在 IBM 进行过各种零售解决方案和在线商务方面服务的工作。他还做过系统验证测试和可伸缩性及性能测试。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首