IBM Systems Director 6.2.1 性能优化策略

5Seven

概述

基于行业标准，IBM Systems Director (ISD) 在 IBM 和非 IBM 平台上支持多种操作系统和虚拟化技术。它通过单一用户界面为管理的系统提供一致视图，并且包含了一组常用任务，例如系统发现、清单、配置、状态、监视，事件等。一般情况下，Systems Director 默认的安装和配置提供了系统管理所需的核心功能，但是在大规模的硬件环境下，例如有超过 5000 台需要管理的硬件设备时，用户可以遵循一定的策略对 Systems Director 进行性能优化，从而最大程度实现商业价值。

本文基于 Systems Director 6.2.1 版本，给出了影响 Systems Director 性能的相关参数和运行环境的介绍及相应的调优建议。

Systems Director 安装的硬件配置

Systems Director 是基于多线程的服务器应用程序，因此可以运行多核处理器和相应的内存设置来提高性能。IBM Systems Director InfoCenter 对 Systems Director 安装的标准硬件需求给出了一些指导，具体可以参考：

http://publib.boulder.ibm.com/infocenter/director/v6r2x/topic/com.ibm.director.plan.helps.doc/fqm0_r_hardware_requirements_for_running_ibm_systems_director_server.html

在大规模硬件环境下（5000 个以上管理设备），Systems Director 需要更高的硬件和操作系统配置，例如 64 位的 CPU 和操作系统。具体需求参见下表：

表 1. 大规模环境下 Systems Director 硬件需求

系统平台	推荐硬件配置
	处理器	内存	存储器
x86（Windows/Linux）	4 核，64 位处理器及操作系统	12 GB	16 GB
Power（AIX/Linux）	4 处理器 , POWER5, POWER6 or POWER7 支持的分区系统 : Entitlement=4 Uncapped Virtual processors=8 Weight=Default	12 GB	16 GB
System z（Linux）	4 处理器 , IBM Systems z9 及以上	12 GB	16 GB

基本优化：Systems Director 运行参数

资源连接和属性验证的时间间隔

Systems Director 定时地与所管理的资源进行通信，来跟踪它们的连接状态和重要属性的变化。每一次通信只消耗很少的系统资源，但是当管理数量庞大的资源时，需要对 Systems Director 默认的通信时间间隔进行调整，降低查询的频率，从而减少 Systems Director 在稳定状态下的资源消耗。

这些设置可以在 Systems Director 控制台的 设置 -> 服务器首选项页面进行更改。

图 1. Systems Director 服务器首选项

默认情况下，“查询重要属性时间间隔”为 6 个小时，但是在大规模硬件环境下，设置为“每隔两天”更加合适。在 Systems Director 需要对大量新的资源执行任务，比如系统发现时，可以临时把服务器、操作系统、BladeCenter 机架等资源类型的“验证连接时间间隔”设置为“每隔 24 小时”，把“重要属性时间间隔”设置为“每隔两天”，并且在任务完成后恢复原值。

LED 状态开关

IBM System x 服务器和 BladeCenter 产品提供了光通路诊断 LED 的硬件特性。位于光通路诊断面板上的 LED 指示灯跟服务器的 CPU、内存、电源、风扇等设备进行关联，从而标识这些设备的运行状态。Systems Director 6.2.1 对这个特性提供了支持，按照一定的间隔监控 LED 的最新状态，从而获悉相应设备的运行状况。

对 LED 的监控会消耗系统资源，因此当环境中没有支持光通路诊断的硬件时，或者管理员确认该特性是非必需时，可以选择在 Systems Director 中关闭这一功能。编辑文件

install_root\lwi\runtime\director\eclipse\plugins\com.IBM.sysmgt.lightpath.service_6.2.0\config

在文件中找到该行

led.polling.interval.default = 15

默认情况下，Systems Director 监控 LED 状态的周期为 15 分钟。把该值改为 0 并重启 Systems Director 后，LED 监控功能即被关闭。

服务器审计

在 IBM Systems Director 6.2.1 中，共有 4 种审计选项：安全性、任务、系统配置、系统触发器。安全性审计是默认开启的，这意味着每一次用户登陆、注销、角色创建、权限设置都会被记录到日志中。如果任务审计开启，所有 smcli 命令操作也会被记录；当运行一个包含很多 smcli 命令的外部脚本文件时，将会大大增加 Systems Director 服务器的磁盘 I/O 数量，从而影响运行效率。

出于性能优化的考虑，可以在 Systems Director 控制台中选择 安全性 -> 服务器审计，关闭不必要的审计选项。

图 2. Systems Director 服务器审计

最佳实践：Systems Director 资源管理的高效途径

针对大规模硬件环境，可以遵循 Systems Director 提供的一些优化方法提高任务的执行效率。

应用概要文件发现系统

输入 IP 地址或 IP 范围，是 Systems Director 发现资源的最简单方式。在处理大量资源时，可以应用概要文件来缩短系统发现的时间。在大规模的处理中，网络拥堵会造成处理过程超时，导致一些资源不被发现。应用概要文件，您可以指定资源类型 ( 如操作系统、服务器、交换机 ) 和发现协议（如 SSH、CIM、CAS），这样 Systems Director 只会对特定类型的资源和协议进行操作，从而降低发现时间，也避免了网络拥堵和超时造成的问题。

在 系统发现页面中选择 管理发现概要文件，可以看到 Systems Director 已经包含了一系列默认的概要文件。用户也可以定制新的概要文件，比如需要对一批操作系统进行 CIM 协议的发现，可以依据如下步骤：

• 选择 清单 -> 系统发现，点击 创建新的概要文件。
• 在“概要文件属性”页中，选择“操作系统”作为资源类型，在资源子类型选项中，选择“具有平台代理程序的系统”。
• 在“选择协议”页中，选中“IBM Systems Director 平台代理程序和 CIM 发现”
• 在“CIM”配置页中，配置待发现的资源的 IP 地址或 IP 范围。Director 会启动多条线程发现资源，因此一次性发现多个资源比执行多次发现效率更高。在处理大量资源时，应该指定 IP 范围进行发现。
• 用户需配置是否在发现结束后自动进行请求访问和清单收集。
  

图 3. 创建发现概要文件

定制后的发现概要文件，只会通过 CIM 协议对类型为“操作系统”的资源进行发现，因此可以将系统发现时间降至最低。

收集清单的高效策略

清单收集要求被管理系统的访问状态是正常的。当试图对无法访问的系统进行清单收集时，Systems Director 会进行多次重试，降低运行效率。同时清单收集的运行时间较长，因此每次收集的目标系统数量应限制在 255 个以下，即同一个 C 类网段，从而缩短收集响应时间，节省系统资源。一种有效的途径是创建动态资源组，设置两个过滤条件：系统的访问状态为正常；IP 地址以特定 C 类网络地址开头。对动态组进行清单收集是一种高效的方式。

创建清单收集的动态资源组，可以依据以下步骤：

• 打开 浏览资源，点击 创建组，打开“组编辑器向导”。
• 输入动态组的名称，如“subnet_10.110.21.x”，点击下一步。
• 在“类型和位置”页中，选择组类型为“动态”，成员类型为“受管系统”并指定组的保存位置，如“root”。
• 在“定义”页中，添加两个动态过滤条件：“操作系统访问状态等于 Unlocked”和“操作系统 IPv4 地址开始自 10.110.21”，如图 4 所示。
• 在“摘要”页中，点击 完成。
  

图 4. 创建动态资源组

在该动态组中选中全部资源，执行清单收集，可以极大提高运行效率。

在执行清单收集时可以指定库存概要文件，来决定对哪一类型的清单进行收集，如基本系统信息、软件库存、硬件库存。默认情况下，“所有库存”会收集全部可用的清单信息。多数情况下，只有部分清单数据是实际有用的，因此可以选择一种概要文件对清单进行部分收集，节省运行时间和系统资源。

图 5. 选择收集清单概要文件

深度优化一：Systems Director 数据库配置

选择所需的数据库安装类型

IBM Systems Director 使用数据库来集中存储详细的清单。需要哪种数据库要在安装 Systems Director 以前做好决定。以下几个方面可以帮助你决定需要安装的数据库的类型。

首先要理解选择的 DBMS 的优缺点，表 3 对常用的 DBMS 的特性进行了比对和分析。

表 2. DBMS 安装类型的优缺点

DBMS 安装类型	优点	缺点
嵌入式 DBMS DBMS 作为 Systems Director 的一部分被安装在管理服务器上，共享 Java 虚拟机	配置简单 不需要额外的许可证 与本地 DBMS 相比，所需的资源更少 不需要为 DBMS 准备额外的服务器	Apache Derby 数据库限制： 可管理的对象数目有限
本地 DBMS DBMS 安装在 Systems Director 同一管理服务器上	不需要为 DBMS 准备额外的服务器	在所有的 DBMS 安装类型中是所需资源最多的
远程 DBMS DBMS 安装在不同于管理服务的另外一台服务器上，Systems Director 远程接入 DBMS.	对于管理服务的资源要求是最低的 可以使用已有的 DBMS，不需要支付额外的 DBMS 许可证	需要为 DBMS 准备额外的服务器 与数据库服务器的连接问题会影响 IBM Systems Director. 例如，如果数据库服务器没有联网或者不能接入，Systems Director 将会没有应答

检查管理服务器支持的数据库，以及希望的安装类型。根据 Systems Director 的安装地点，数据库可能有多个选择。进一步的信息请查看“支持的数据库应用程序”

http://publib.boulder.ibm.com/infocenter/director/v6r2x/index.jsp?topic=/com.ibm.director.plan.helps.doc/fqm0_r_supported_database_applications.html

检查下表提供的信息选择最符合要求的数据库。某些数据库（包括 Apache Derby）不能支持多于 500 个管理对象的大型网络。

表 3. 数据库的大型网络的管理

数据库	可以处理大型网络的管理对象
Aparche Derby	否
IBM DB2	是
Microsoft SQL Server	是
Microsoft SQL Server Express	否
Oracle Database	是

数据库调优

数据库配置

当使用外部数据库时，要确认正确的配置了数据库。尤其需要注意的是，保证数据库将数据存储在正确的磁盘序列。同时，要注意任何在信息中心里面相关数据库配置的建议。例如，这些建议包括设置 DB2_WORKLOAD=TPM 和使用 IBM DB2 的时候打开自动重组。

http://publib.boulder.ibm.com/infocenter/director/v6r2x/index.jsp?topic=/com.ibm.director.install.helps.doc/fqm0_t_preparing_ibm_db2.html

数据库访问速度

引起 Systems Director 响应速度的数据库相关原因可能在以下两方面：

• 性能不好的数据库服务器
• Systems Director 和数据库之间的网络连接比较慢
  

IBM Systems Director 6.2.1 包括了可以得到数据库访问时间的 CLI 命令 -diagsystem。diagsystem 命令会发送几个数据库查询请求，并且返回响应的时间。语法如下：

smcli diagsystem

使用此命令来诊断数据库服务器的响应时间是否可以接受的步骤如下：

• 在 Systems Director 服务器上运行“smcli diagsystem”；
• 在输出内容中查找“DB Read RCS Sequence”, 查看“avg=”所包括的数值；
  

数值越小，代表反应时间越短。建议在性能调试的同时，将这个数据记录下来，作为比较的依据。

深度优化二：Java 运行环境优化

JRE 内存以及垃圾收集优化

IBM Systems Director 是基于 IBM JDK1.6 开发的 Java 应用软件，而众所周知 JVM 的堆栈内存配置以及垃圾收集算法的选择对于 JVM 的性能至关重要，不同的硬件配置，不同的使用场景，Systems Director 也提供这样的配置接口，可以灵活的通过修改配置文件调整 JVM 运行参数来满足响应的软件性能需求。

JVM 堆栈最大值和最小值的调整

默认情况下，Systems Director 在安装过程中会根据安装机器的硬件配置信息设置响应与通常情况最优的 JVM 堆栈区大小，但是 JVM 堆栈最大值的调整在许多的应用场景下会非常有用。特别是在两种情况下需要注意堆栈大小的设置，一种情况是 Systems Director 安装在 Power 系统上；另一种情况是额外的内存在 Systems Director 安装后被添加到安装的机器上。这时 Systems Director 不会自动调整其堆栈最大值，必须手动调整 JVM 堆栈最大值才能更好的达到增加内存以提升性能的目的。如表 4 所示，Systems Director 性能优化小组提供了在 64 位机器上推荐的堆栈内存配置供参考。

表 4. 推荐的堆栈内存配置

64 位机器运行 Systems Director	推荐配置
10Gb 以上	-Xmx8192m
5Gb – 10Gb	-Xmx4096m
3.75Gb – 5Gb	-Xmx3072m
小于 3.75Gb	-Xmx2048m

Systems Director JVM 堆栈配置文件所在安装目录的位置如表 5 所示，堆栈最大值与最小值的配置文件分别命名为 maxheap.javaopt 和 minheap.javaopt，用户可以通过修改这两个文件中的内容来达到修改 JVM 堆栈配置的目的，这样的修改会在 Systems Director 重启后生效。

表 5. JVM 配置文件在 Systems Director 安装目录中的路径

操作系统类型	配置文件路径
Windows	C:\Program Files\IBM\Director\lwi\conf\overrides\
Linux	/opt/IBM/director/lwi/conf/overrides/
AIX	/opt/IBM/director/lwi/conf/overrides/

JVM 垃圾收集算法的调整

Systems Director 同样也支持对于 JVM 垃圾收集算法的调整，多种不同的垃圾收集算法来应对不同场景下的性能需求，Systems Director JVM 垃圾收集算法的配置文件位置如表 5 所示，文件名称为 director.javaopt。

Systems Director 性能优化小组通过测试，针对大多数用户应用场景设置了垃圾收集的默认算法为 gencon，该垃圾收集算法适用于 Java 应用中有较多的短生命周期对象，可以更有效的处理生命周期的较短对象，并且保证有较好的吞吐量。但是在一些的特殊情况下，可以调整垃圾收集算法以实现不同的 JVM 性能。

Director Java dump 文件分析诊断当前 Systems Director 运行时状态

在 Systems Director 的运行性能产生异常，特别是 1) 界面响应速度慢，2) CPU 使用率过高， 3) 过多的 IO 读写操作，当类似的问题发生时往往可以通过分析 Java Dump 文件来找到问题所在。Systems Director 提供这样的接口可以方便的得到 Systems Director 运行时 Java Dump 文件，在安装 Systems Director 的机器上，从命令行窗口输入“smcli dumpjava”，这时 Systems Director 会将当前运行实时状态生成 Java Dump 文件，并保存于安装目录的“%Director%/lwi/runtime/core”路径下，文件命名格式为“javacore*.txt”。

通过查看 Java Dump 文件，便可以获得 JVM 运行时详细的状态信息，例如，堆栈内存大小以及使用率、Native 内存使用状态、JVM 线程运行状态等。 如图 5 所示，可以通过 Java Core Analyzer（JCA）来查看得到的 Dump 文件，这些信息可以有效的诊断当前 JVM 运行发生的性能问题，为下一步的性能调优处理提供依据。

图 6. JCA 查看 Dump 文件示例

结束语

本文结合 Systems Director 的工作原理，从硬件环境、参数配置、最佳实践、数据库优化和 Java 优化等方面，给出了 Systems Director 性能调优的常用方法和性能瓶颈的分析方式。希望您在分析性能问题时有一个清晰的脉络，从而由浅入深地去解决相关的性能问题。也希望本文能够帮助系统管理员在部署大规模硬件环境时，更大程度的发挥 Systems Director 的功能和性能优势。

感谢张谦对本文的大力支持与特别贡献。张谦，CSTL 软件工程师，目前从事 IBM Systems Director 配置管理功能的开发。

作者简介

王帆，2010 年加入 IBM CSTL 从事 Systems Director 产品的开发，目前从事 Systems Director 产品的性能测试和调优。

杨阳，IBM CSTL 软件工程师，有多年企业级软件的性能测试经验。目前从事 IBM Systems Director 的性能测试工作。

马慧珺，IBM CSTL 软件工程师，从事 IBM Systems Director 相关产品的功能测试工作。

http://www.ibm.com/developerworks/cn/aix/library/1112_wangfan_isdoptimization/index.html