分级 IBM Lotus Domino 邮件服务器

“我该如何结束？”

这是许多管理员在对其 DPAR 要求进行分级后或在两个月后遇到 CPU 资源问题时提出的问题。在涉及服务器合并和/或平台更改的情况下，通常假设新平台上的 Lotus Domino 不如在旧平台上执行得好。另一个假设趋向于 Lotus Domino 没有有效地扩展，因为与以前相比，现在运行的 DPAR 更少，但用户比率更高。

在回顾如何到达这一步的过程时，了解发生了什么事情的关键因素是您必须使用的数据。虽然客户通常将 CPU 资源利用率数字（比如 CPU 忙）收集在一起，但他们通常不收集和管理他们的 Domino 统计数字。DPAR 具有动态的工作量，该工作量不仅每天都会变化，而且每分钟都会变化。在任何给定时刻，您不知道哪些工作量是您的最终用户正在 DPAR 上处理的。

客户往往使用 Domino 事务处理计数 (server.trans.total) 作为测量通过其 DPAR 的工作量的一种方式。但是，Domino 事务处理计数（由 Domino 服务器提供）是对通过服务器的工作量的原子测量。确切地说，它是您的 DPAR 和 Lotus Notes 客户机或者其他 Domino DPAR 之间的 NRPC 流量的测量。升级 Notes/Domino 版本（在服务器端或客户端）可以更改事务处理计数，即使运行的是相同的工作量。

此外，正在运行的其他 Domino 任务中的更改（复制、AdminP、索引等等）将影响事务处理计数，即使您的用户正在执行相同的操作。最终，非 NRPC 协议客户机，比如 HTTP、IMAP 和 POP3，可以对资源利用率产生深远的影响，而对事务处理计数则产生很少的影响。事实上，DPAR 和 CPU 利用率上的事务处理计数之间没有直接的关联。有关该事实的详细分析，请参阅 developerWorks 文章 “IBM zSeries 上的 Lotus Domino 7” 中的 “Measuring a production DPAR” 一节，尽管向其中添加了三倍多的用户，但同一 DPAR 在几个月内的事务处理率是相同的！

您不仅需要知道 DPAR 上有多少用户（已注册、已连接和活动 15 分钟的用户），还要了解这些用户请求 DPAR 执行哪些工作量。出于分级目的，IBM 容量计划人员通常基于工作量特征将邮件用户分为四个种类：轻、中、重和强用户。因为每个种类具有不同的 CPU 使用配置文件，所以如果您不理解用户属于哪个种类或您具有哪些种类混合，就很容易算错支持用户社区所需的资源量。

回页首

影响分级的因素

有许多不同的因素可能影响 DPAR 的 CPU 分级，下面将讨论其中几个因素。

代理

允许用户编写的代理在您的 DPAR 上执行就像支持您的用户对服务器上任何数量的 CPU 资源进行空白检测（blank check）一样。因为您不知道这些代理可以做什么、它们打算隔多久运行一次或者多少用户在运行它，所以无法预测它们消耗哪些资源。代理往往由组织中的许多用户共享，而且传播迅速，尤其是当它们具有某些似乎有用的功能时；它们可以从一个人传到两个到四个到八个再到十六个，依此类推，非常快地传播下去。

即使 Notes 管理组编写的最好的代理也有可能无法如期执行。例如，在 IBM 内部查找我们的一个邮件 DPAR 的资源利用率时，我们发现，验证服务器是否可用的轮询代理所消耗的服务器资源比该服务器路由邮件所使用的资源还要多。重新编写代理之后，其 CPU 使用显著降低。

编写不好的代理可能会严重破坏您的 DPAR。在另一个示例中，我们找到一个计划每小时运行一次的代理。根据它的编写方式，它将顺序读取每个视图中的每个文档。这导致代理要用一个多小时来运行，但因为它被计划成每小时运行一次。所以该代理从来没有停止过，一周运行七天，一天运行 24 小时，单独一个 DPAR 中的单个代理几乎要消耗一个引擎的四路 CPU 箱上的 CPU 周期，或者几乎消耗总 CPU 容量的 25％。

如果允许您的服务器上拥有不限数量的代理，且允许在将它们放在生产 DPAR 上之前不对其进行测试，那么当这些代理随用户数变来变去时，请您准备好应付 CPU 利用率的巨大峰值吧。如果您必须允许个人代理在您的服务器上运行，建议您至少要有一个审查流程，以了解有哪些代理、代理的数量是多少以及它们涉及哪些用户，并建议您测量您的 DPAR 来考虑这些信息。

邮件大小/等级

邮件文件的平均大小影响 DPAR 支持用户数所需的资源数量。平均邮件越大，DPAR 处理任务所需的资源就越多。Router 任务使用更多的资源将这些消息发送给其他服务器，而且 Server/HTTP 任务要使用更多的资源来将这些消息发送给您的客户机。发送大邮件消息的用户或具有大附件的消息的用户所需的支持邮件的开销要比发送较小消息的相同用户所需的开销大。显然，用户社区发送的消息越多，所需的支持资源就越多。

收件箱和数据大小

用户邮件文件的大小还影响支持用户社区所需的资源量。developerWorks 文章 “对于大 Lotus Notes 邮件文件的最佳实践” 讨论了邮件文件大小、Inbox 视图中的文档数以及支持用户社区所需资源带来的影响。这篇文章清楚地说明了数据库大小和 Inbox 中管理的条目数是确定支持您的用户所需资源量的关键因素，而且在 Inbox 中具有较多文档比具有大邮件文件开销更大。

集群和复制

如果在 DPAR 之间设置集群和/或复制，这将影响支持您的用户所需的资源量。虽然集群具有可大体预测的开销（基于邮件量，因为它是事件驱动的活动），但复制可能对支持用户所需的资源要求产生不可预测的影响。使用集群，将只推入并复制那些发生更改的数据库。但是，如果使用计划复制，则会复制打算复制的所有数据库，而不管是否对其进行了更改（包括打开数据库和搜索任何差异）。而且，复制间隔越小，对 DPAR 的资源影响越大，因为会太频繁地使用 CPU 周期，就会发现没有什么要复制的。

不过还是推荐使用计划复制，即使您正在使用集群。计划复制允许 DPAR 不时同步集群每个端上的数据库，并确保它们是完全相同的。还可以使用 Program 文档，在 DPAR 启动时启动复制，这可以在 DPAR 重启时为您提供事件驱动的复制，而不是隔一个小时左右计划一次。这里的使用诀窍在于，使用集群可以每天只复制很少几次。

集群和复制的接收一端是 Server 任务，所以这些功能的大多数周期/成本都包括在该任务中，而非Cluster/Replication 任务中。在 Server 任务中不考虑集群/复制周期会导致低估这些功能的要求。

全文索引

如果允许在 DPAR 中使用全文索引，则不但必须考虑这些索引的管理，还要考虑在执行索引上执行的搜索。管理全文索引并不需要大量资源，但是实际的搜索需要大量资源。您需要知道索引上正在执行多少搜索。

事务处理日志

如果正在使用事务处理日志，则必须考虑运行它所需的额外周期。对于为您提供其他益处（改进的数据集成、加快的服务器重启和更大的 DPAR 可扩展性）的任何特性，必须对其 CPU 资源要求有所计划。

其他因素

还必须考虑可以影响资源要求的其他任何 Domino 特性、附件功能或第三方产品。例如，需要考虑的一些事项包括病毒扫描、备份和恢复、RIM/Blackberry 使用、单副本模板、消息跟踪、网络压缩以及客户编写的作为邮件接口的应用程序。所有这些活动将在不同程度上影响支持用户社区所需的 CPU 量。

回页首

如果管理服务器上的管理

虽然上述列表有意包括了具体的特性、功能或工作量特征，但配置和管理 DPAR 的方式也会影响您的 CPU 利用率和 DPAR 分级要求。例如，如果在进行主要班次（prime shift）期间在 DPAR 上执行 AdminP 或 Domino Directory 复制，除了工作量之外，您还必须计划支持这些功能所需的周期。虽然 Domino Directory 的复制可能永远不会在主要班次期间消除，但您可以控制它出现的频率。显然，将 Domino Directory 更改推向 DPAR 的频率越高，资源影响就越大。

在主要班次期间运行 AdminP 有点像运行代理，因为您永远也不知道 AdminP 更新到底需要多少资源。例如，如果更改一个名称或一个组，并且在数据库中启用了字段级别的安全性，则必须搜索每个数据库中的每个文档，以确定该名称是否必须存在于该字段中，这可能被当作一个 CPU 非常集中的过程来执行。同时，其他 AdminP 更改可能需要很少成本就可以运行并且非常快速。关键在于您永远也不知道下一个 AdminP 请求需要哪些资源。总而言之，建议您在主要班次用户窗口之外运行 AdminP，以消除 DPAR 中的 CPU 使用峰值。否则，您必须计划为其分配附加的资源。

此外，在主要班次期间运行 Compact、Updall、Fixup 或其他维护任务时要多加小心，因为这可能对资源产生极大影响。

回页首

客户机类型

用户运行的客户机类型会影响支持用户社区所需的 CPU 要求，但是因为客户机的成本随 Lotus Domino 的版本而变，因此在此无法提供准确的客户机成本值。

例如，假设在当前版本中，一个 NRPC 客户机需要 100 个 CPU 单位，客户机 X 需要 200 个单位，比例为 2:1。如果在下一版本中，NRPC 有 30％ 的提高，而客户机 X 有 15％ 的提高，则比例变为 2.45:1。这并不意味着客户机 X 在新版本中更糟糕（实际上好了 15％）。但是，与新版本中的 NRPC 的成本相比较，客户机 X 在比例上比以前需要更多的资源。如果我们倒转所得提高的百分比，则现在 NRPC 好了 15％，客户机 X 好了 30％，而新比率为 1.65:1。

此外，不仅与 NRPC 客户机有关的每个客户机的成本可以不同，而且每个平台也可能有不同之处。例如，在版本 7 中，Intel 上的 Linux 比版本 6.x 上的 NRPC 客户机有了显著的改进，而 System Z 上的 Linux 则没有。这是因为，Linux 中主要的扩展更改是第一次被开发并放置到版本 6.5 的 Linux for System Z 中，所以这些显著的更改没有反映在版本 7 系列中。开发增强时，这种情况发生在所有平台上。在可行的地方，它可以连接到核心代码和其他平台中。因此，必须考虑 Lotus Domino 的各种平台上支持的各种客户机改进的波动。

HTTP 用户在 DPAR 上比在 NRPC 客户机上估计可以多占用非常多的 CPU 周期。根据使用 Lotus Domino Web Access 还是 Web 邮件，该比率可能达到比 NRPC 用户多六倍，因为由 Notes 客户机执行的处理现在被推回给服务器执行。使用 Notes 客户机，服务器可以传输数据并允许 Notes 客户机格式化结果并将其表示出来。但是，使用 HTTP 客户机，服务器还必须完成数据格式化/表示的大部分工作。

POP3 用户比 NRPC 客户机大约少使用 20％ 的 CPU。默认情况下，POP3 是客户机为中心的协议。邮件从服务器向下推至客户机，从服务器删除，然后在客户机上进行管理和导航。但是，可以配置 POP3 将邮件保留在服务器上，并将邮件作为服务器为中心的协议来运行，从而更改在 DPAR 上运行 POP3 客户机的成本。

IMAP 用户可能比 NRPC 客户机要多占用大约 60％ 的 CPU。默认情况下，IMAP 是服务器为中心的协议。邮件保留在服务器上，当用户导航其邮件时，客户机必须不断地与服务器通信。虽然可以将一些 IMAP 客户机配置为从服务器下推邮件并在客户机上运行邮件，但您必须理解您启用了哪些特性/功能及其潜在影响。

回页首

用户做什么

只知道 DPAR 上的已注册用户数并不能为您提供所使用资源量的准备指示。即使条目具有相同的已注册用户数、相同的活动用户数和相同的客户机类型，两个 DPAR 也可能具有不同的资源利用率。已注册用户可以影响备份和轮询活动，而活动用户可以影响 CPU 利用率，已连接用户可以影响内存利用率。

如前所述，用户可以分为四个种类：轻、中、重、强。正如您所料，支持 1000 个轻用户所需的 CPU 量远远小于支持 1000 个重用户所需的 CPU 量。按照 Lotus Domino for zSeries 使用的分级，每种用户类型定义如下，另外还包括表 1 中的汇总。

轻用户

轻用户仅使用电子邮件，而不使用日历的计划功能。他们可能偶尔接收约会通知，但从不亲自计划会议。他们从不收/发电子邮件附件，消息大小为 10 KB 以下。他们收/发 10 个以下的消息/天（包括 Internet 邮件），均匀分布在一天中。轻用户的邮件文件小于 50 MB。当轻用户快速了解产品的更多信息后，用户就会发展成为中用户，所以为了更正分级，您不应该高估轻用户的数量。

中用户

中用户使用电子邮件以及轻量级日历和计划 (C&S) 功能（1 个以下的约会/天）。他们偶尔收/发带有小附件或图片的邮件。他们的平均消息大小是 25 KB，大部分邮件小于 100 KB，他们收发 10 到 25 个消息/天。他们的邮件大小范围为 50 到 200 MB。大多数用户属于这一种类。如果您不确定用户的工作习惯，那么可以选择这种用户活动。

重用户

重用户使用了比中用户更多的电子邮件和 C&S 功能（5 个以上的约会/星期）。他们的消息大小更大（平局 50 KB），最大的邮件消息小于 500 KB。重用户每天收/发 26 到 40 个消息，其邮件文件大小大于 200 MB。

强用户

强用户使用 Lotus Notes/Domino 进行核心工作功能。强用户可以是行政助理，管理多个日历并经常使用空闲时间搜索来安排会议，或者是技术专家，大量使用邮件、C&S 以及 Lotus Domino 的其他功能，比如全文索引/搜索、邮件代理和复杂规则。强用户的平均消息大小是 75 KB，但通常的邮件大小是 100 KB 以上。强用户具有 10 个以上的约会/周，发送 40 个以上的消息/天，其邮件文件大于 200 MB。总的说来，社区中相当少的用户会属于这个种类。

表 1. 用户种类定义汇总

Lotus Notes 和 Lotus Domino Web Access 用户	轻	中	重	强
消息数/天	小于等于 10	10 到 25	26 到 40	> 40
平均消息大小 (KB)	小于等于 10	25	50	> 75
最大消息小于	N/A	100 KB	500 KB	N/A
最大消息大于	N/A	N/A	N/A	100 KB
分发列表	无	有	有	有
附件	无	有，但小	有	有
日历功能	约会通知	有，但轻	有	有
计划功能	无	有，但轻	有	有
每周约会	1 个	5 个以下	5 个以上	10 以上
全文本索引、搜索	无	无	可能	有
邮件代理、复杂规则	无	无	无	有
邮件文件大小 (MB)	< 50 MB	50-200 MB	> 200 MB	> 200 MB

除了这些分类之外，还需要理解哪些工作量（包括本地邮件复制和目录编目的使用）可以卸载到 Notes 客户机。通过使用 Notes 客户机的本地邮件文件，客户机和 DPAR 之间的许多流量都能消除，因为客户机通过导航本地邮件文件来进行大多数客户机活动。通过使用客户机的目录编目，还可以卸载寻址邮件时发生的 Domino Directory 查询。无需通过网络提前输入到您的 DPAR 中，您可以将它们定向至 Notes 客户机上本地可用的目录编目中。

通过使用这些特性，可以将通常在服务器上执行的活动卸载到客户机上，从而降低 DPAR 的 CPU 资源成本。但是，将本地邮件复制间隔设置为低级别可能具有相反的效果，因为 Notes 客户机将每隔几分钟就轮询 DPAR 是否有新邮件，从而驱动 CPU 使用。不应该将客户机复制间隔设置为 15 分钟以下。如果需要复制间隔小于该间隔，则应该考虑不使用客户机复制，而使用 DPAR 上的用户邮件文件，以降低 CPU 成本。

将用户映射为上述四个种类可能并不简单；相反，按照工作描述（工厂、职员、IT、学生、来势、出纳员、股票经纪人等等）可能更容易。然后您可以将每个工作描述映射到一个用户种类，从而使您对用户分布和预期工作量有一个大体的了解。您可以随着了解的增加来细化该定义。

回页首

增长

如果不考虑用户社区的增长模式，随着用户复杂性增加或者邮件/邮件文件量增加，您今天执行的任何分级不久以后可能变得无法胜任。

在一个案例中，一个客户的 DPAR CPU 利用率的复合增长为每月 5％，可将其换算为服务器要求每年增长 80％。用户邮件大小没有配额或限制，个人代理没有限制，或全文索引或搜索没有限制。而且，没有对旧邮件的归档或管理策略，所以用户可以将所有东西保留在 Inbox 中。

虽然您的 DPAR 可能不会像这个例子这样极端，但没有在分级时考虑增长会影响预测硬件能够支持您的环境的时间长度。

最高负荷和平均负荷

分级 DPAR 时，必须确保分级 DPAR 处理的最高负荷，而非平均负荷。例如，在周末假日之后返回的第一天，DPAR 在主要班次期间重新启动或批量邮件传递可能导致比平常高许多的 CPU 高峰。如果您不允许足够的资源来处理这些情况，则 DPAR 可能带来 CPU 压力和恐慌，提供糟糕的用户响应时间，或者将故障转移到集群中的其他 DPAR。

一定要理解您的统计数字真正说明了什么。您是否查看了全天 24 小时的间隔，或是否查看了主要班次间隔？仅仅通过更改数据的示例视图，就可以显著更改报告中的值。例如，服务器可能以全天 60％ 的平均 CPU 利用率运行。但是，查看相同的数据并过滤主要班次期间的高峰负荷时，您可能看到平均 85％ 的利用率，而且单个 CPU 峰值达到 95 - 100%。虽然 60％ 这个数字对于全天 24 小时期间是有效的，但这不是实际高峰负荷的准确表示。如果使用该数字来计划新服务器，则当 95 - 100% 的峰值出现时，您将很快用完该箱上的容量。

在查看 Domino 统计数字时，还必须应用同样的理解；许多数字在本质上是累加的。您从显示统计命令中或通过查看 Statrep.nsf 数据库来接收该数据，这意味着从第一次启动服务器或最后一次重置该值时开始，该值一直在增加。如果不是定期收集该数据，而只是隔一段时间才查看它，那么您可能错过 DPAR 上发生的事，以及发生的时间和频率。

何时捕获数据

所有服务器在其工作量活动中都会经历几种周期。例如，在夏季的几个月里，通常休假的人要比一年中其他时间要多。如果基于 8 月的 DPAR 来分级服务器，则可能会低估您的要求。

特定业务周期可能会驱动 DPAR 上更高或更低级别的活动。例如，在新版本交付或季度/年度业务报告的几周前，预计会在 DPAR 中看到比新版本发行后更高的活动率。因为您想让您的 DPAR 支持高峰负荷，所以您需要了解您的业务周期是多少，以及哪些时间帧最好地表示了这些高峰负荷。

应用程序与邮件工作量

来自 IBM 的大多数分级和基准数字都涉及邮件工作量（因为它们是可重复的），从而允许我们在测试方法中保持一致。除邮件之外，Lotus Domino 还可以运行许多客户编写的应用程序工作量，但是因为这些工作量使用惟一组合中的各种 Domino 特性，因此几乎无法预测其分级。在这种情况下，通常需要一个基准来为您的定制应用程序生成准确的分级。还可以运行应用程序的试验版本，然后基于分级，提供该试验版本的实际利用率。但是，在您的应用程序、Lotus Domino 或服务器中，可能存在固有的限制，它们限制了单个 Domino 图像的垂直增长并要求您运行多个副本。

例如，新版本的 Lotus Domino 可能在 CPU 资源上有 25％ 的性能改进。这可能允许您将两个 DPAR 合并为您计划购买的新硬件上的一个 DPAR。但是，如果没有有效地编写应用程序，或者没有正确配置 Lotus Domino，导致一些原语锁定出现（或其他限制因素），那么在瓶颈发生之间，您可能在单个 DPAR 中永远达不到完全的 CPU 利用率。

回页首

监控服务器

您可能很快就被对服务器进行分级时所需的信息量吓倒，但是要注意，Lotus Domino 可以为您提供许多这种数据。至少，您应该始终收集 DPAR 上的监控数据，以了解其增长模式并确定新特性和功能对这些数据的影响。这有助于您了解当前使用情况以及为什么您要使用比预测要多的资源。

有关前面 “影响分级的因素” 一节中列出的项的信息，如果您已经启用了统计数字收集，那么可以在 Statrep.nsf 数据库中找到它们。默认情况下，该数据库只存储 Events；并不存储 DPAR 统计信息，除非您启用了 Collect 任务。还可以设置单个 DPAR，从多个 DPAR 中收集统计信息，这样就可以拥有单个合并的 Statrep.nsf 数据库，而不是多个。您不需要在所有 DPAR 上启用 Collect 任务，只需在将为您收集信息的那些 DPAR 上启用即可。

图 1 显示了 Lotus Domino 7 中具有统计数据的示例 Statrep.nsf 数据库。

图 1. 示例 Statrep.nsf 数据库视图

在图 2 中，打开了其中一个记录来显示该记录的某一区域的外观示例。

图 2. 示例统计记录

可以将该统计信息从 Lotus Domino 导出到可以加载到数据库或电子表格中的平面文件中。图 3 展示了已导出文件的一个示例。

图 3. 已导出文件示例

回页首

分析 Statrep.nsf 中的数据

现在基于从 IBM 的内部生产 DPAR 中的 Statrep.nsf 数据库中获得的数据来讨论几个图表。这些图表以几个不同的视图展示了该数据，如下所示：

• 间隔：基于 7x24 小时划分的所有值。
• 班次间隔：在主要班次内划分的所有值，定义为星期一至星期五的上午 8 点到下午 4 点。
• 每日：每天的一个点。每天的点表示这一天的完全 24 小时视图；但是，根据数据类型，可以对这些数据求和、取最小值、取最大值或取平均值。
• 班次每日：每天的一个点。每天的点表示这一天的主要班次视图。而且，根据数据类型，可以对数据求和、取最小值、取最大值或取平均值。

注意：一些图表也可以使用两个 Y 轴来显示数据，从而允许您在拥有完全不同的值的图表上查看多个项之间的关系。每个图表上的图例都清楚地显示了将使用哪个 Y 轴。

图 4 显示了该 DPAR 的 NRPC 已连接用户 (server.user) 的数目和 NRPC 活动 15 分钟用户 (server.users.active15) 的数目。

图 4. NRPC 已连接用户数和 NRPC 活动 15 分钟用户数

通过确定在高峰期间有多少 NRPC 活动 15 分钟用户，可以将该数与已注册社区总数关联，以确定 DPAR 中活动用户总数所占的百分比。

建议使用 NRPC 活动 15 分钟计数 (server.users.active15) 而非已连接用户计数 (server.user) 来获得百分比活动数。已连接用户计数受 DPAR 的服务器-会话-超时 Notes.ini 值的影响，这意味着根据 DPAR 的会话-超时值，相同的工作量可以产生两个不同的 NRPC 已连接用户计数。活动 15 分钟用户计数不变化，但与用户活动直接相关。

虽然可以在 Statrep.nsf 中获得一些统计数字，比如直接从每个文档中获得用户计数，但其他统计数字必须由两个间隔之间的差异比较派生而来。

虽然图 2 中的 2100 万个事务处理似乎太多了，但要注意，这是自 DPAR 启动以来或自该统计数字被显式重置以来的总数。如果该服务器启动了一两天，则这是一个较大的事务处理数；但是，如果服务器已经启动了一个月，那么该事务处理数可能就不是很多。通过比较 Statrep.nsf 中的各种文档，可以构建一个间隔历史，以记录在 DPAR 操作期间如何累计这些统计数字。

图 5 显示了该 DPAR 在三周期间内的 Domino 事务处理数的间隔视图。

图 5. 三周期间内 Domino 事务处理数的示例间隔视图

通过将其更改为每日主要班次视图（参见图 6），可以容易地看到在同一期间内主要班次期间的事务处理率。此外，通过允许累计该数据，可以构建 DPAR 的工作量和资源利用率以及任何变化的准确视图。

图 6. 同一期间的主要班次每日视图

如前所述，了解 DPAR 的工作量对于准确分级非常关键。除用户之外，您还可以查看 Statrep.nsf 数据库中的任何数据以了解 Lotus Domino 的各种特性正在发挥的作用。例如，图 7 显示了在主要班次的几周期间内按邮件大小在本地通过该 DPAR 发送的邮件消息数。

图 7. 按邮件大小在本地发送的邮件消息数

在图 7 中可以看到，在 1 到 10 KB（蓝色线）大小范围的邮寄数中有大的峰值，但更值得关注的是 100 KB 以上范围（黑色、粉色和蓝绿色线）中的所有峰值。在同一图标中可以看到较大消息的大小的详细信息，绘制在第二个 Y 轴上（参见图例）。虽然这些量远远低于绿色线，但消息大小实际可以导致该 DPAR 上出现更大的 CPU 资源峰值。如果您将该信息绘制在每日图表中（如图 6），就可以查看随着时间的推移，该 DPAR 本地发送的消息大小和数目是否在变化。如果确实在变化，则表明 DPAR 上的工作量正在增长，这种情况下，您需要为附加资源制定计划。

图 8 显示了一个 DPAR 中发生的集群活动量。

图 8. DPAR 集群活动

正如图 7 所示的邮件发送数据，这可以清楚展示集群活动随时间变化发生的所有变化。通过理解工作量在如何变化以及变化的速度，可以更好地对 DPAR 的服务器要求进行分级。

本文的 “影响分级的因素” 一节中提到的以上各项几乎都可以按这种方式从 Statrep.nsf 中捕获、分析和绘制。

除 Statrep.nsf 之外，可以查看本地平台的统计信息（不仅是 Domino 平台统计数字），这些统计信息提供了 Lotus Domino 视图无法提供的其他详细信息，即事件在您的服务器/DPAR 中如何运行。图 9 展示了当这些任务与 Server 任务关联时，DPAR 中前 12 个过程的 CPU 关系。在本例中选择 Server 任务是因为该 DPAR 支持的是 Notes 客户机，所有 NRPC 客户机请求都由 Server 任务处理。通过将这些任务与 Server 任务关联，可以理解 CPU 资源如何由组成该 DPAR 的各种任务消耗。

图 9. 前 12 个 DPAR 处理的 CPU 关系

理解该图的关键在于 CPU 资源的比例关系；换句话说，如果添加更多的用户来进行相同的工作量，则该图上的线将不会变化。但是，如果该 DPAR 上的活动速度变化，例如，执行更多的代理、索引搜索或复制，则该图上的线将变化，指示您查找不同工作负载应该查看的区域。

如果该图表显示 Agent Manager 任务占用的周期比 Server 任务多，那么您就会知道在分级中要考虑该附加 CPU 资源。（已经知道 Agent Manager、AdminP、Update、Replica 和其他 Domino 任务要出现高的 CPU 消耗量）。通过了解各种任务在做什么，可以更好地理解需要哪些资源来支持您的用户社区。

例如，在图 9 的下半部分中，可以看到 Compact 任务（蓝绿色）正在主要班次期间运行。虽然在这个示例中只出现了一次，但为了分级目的，您应该确定这些任务在主要班次期间的运行频率。这种图表允许您快速概括出 DPAR 使用状况并了解正在运行的任务之间的关系。Router 任务中的大峰值是大量邮件，这是必须计划的工作量峰值的另一个示例。

为了生成该图表，将每个任务使用的 CPU 划分为 Server 任务在每个间隔使用的 CPU。如果 HTTP、IMAP, 或 POP3 任务是您的主要客户机，则可以简单地将其选择作为您的基本任务。对于集线器 DPAR，使用 Router 任务作为基本任务。

回页首

案例分析：服务器合并分级

在该案例分析中，让我们来研究一下服务器合并机会，其中一组现有 Domino DPAR 即将消耗完一组硬件上的 CPU 容量。我们计划将用户社区合并到一组更大的新硬件服务器上。DPAR 的数目也要合并。我们设置了一个试验版本，将大约 10％ 的现有 Notes 用户社区迁移到新硬件上的新 DPAR 来验证分级。

在用户社区的目标 10％ 移动到新 DPAR 之后，发现这些用户使用了整个用户社区中将近 50％ 的总 CPU 资源。为了理解发生了什么，从所有现有的 DPAR 和新创建的 DPAR 中捕获数据，然后进行比较。

表 2 显示了该数据的分析结果。第二列显示对新合并的 DPAR 的分析，第三列显示对原始 DPAR 的分析，它们还有其余 90％ 的用户数。因为原始 DPAR 运行的是旧版本的 Lotus Domino，所以从中无法获得活动 15 分钟用户数。

表 2. 服务器合并研究分析

描述	新合并的 DPAR	所有旧 DPAR 的平均	新到旧	单个旧 DPAR	新到单个旧
总用户数的百分比	9.554	90.446	N/A	31.405	N/A
已连接用户与已注册用户的最高比例（百分比）	73.767	73.059	1.010	51.228	1.491
活动用户与已注册用户的最高比率	56.054%	?	?	?	?
每小时每个已注册用户的事务处理数	196.625	137.059	1.435	72.42	2.715
每小时每个已注册用户执行的代理数	.303	.173	1.751	.069	4.39
每小时每个已注册用户的日历约会数	.529	.147	3.598	.109	4.853
每小时每个已注册用户传送的平均邮件 (MB)	.835	.582	1.435	.390	2.141
每个已注册用户的平均数据库大小 (MB)	597.118	195.263	3.058	87.212	6.847

可以看到，新合并的 DPAR 上的用户活动比原来的 DPAR 上的用户活动更繁重。这两个 DPAR 上的工作量比较如列 4 所示。要理解工作量的差异，让我们来分析迁移到试验 DPAR 的用户。

首先，原来的 DPAR 在 CPU 和磁盘方面具有资源约束。Notes 管理员决定将使用最大数据库的用户移动到新合并的 DPAR，以减轻磁盘负担。但是，他们无意间将企业范围的每个功能和重用户也合并到新合并的 DPAR 中了。支持该组重/功能用户比支持其余用户社区所需的资源利用更多。

该现象的另一个迹象是将最新/最轻的用户放置到了原来的一个 DPAR 上了。对这个 DPAR 的分析见列 5。将该服务器与我们最新合并的 DPAR 相比较，可以看到结果中的差异（列 6）甚至更显著了。

如果试验用户已经从该 DPAR 迁移出来，那么在新 DPAR 上将会有一个非常不同的 CPU 使用曲线，这时我们会疑惑为什么我们分级了如此多的 CPU，因为该试验组用户使用了比预期少得多的 CPU 量。

此处的关键在于其中每个单独的用户组（重/强或轻）将提供对总用户社区的不准确预测。这就是为什么具有相同数量用户的 DPAR 之间可以具有不同的资源使用状况，即使它们在相同的客户机上具有相同的用户数。

此外，在旧 DPAR 中还有潜在的工作量。因为来自这些 DPAR 的响应时间变长，所以用户尽量不使用它们。但是，在用户移动到新 DPAR 中并体验了改进的响应时间后，他们增加了发送的邮件数量。而且，现有 DPAR 在其响应时间改进后看到了工作量增加，而且其他用户也增加了他们的活动。

在查看任何现有服务器时，需要确定它们当前是否具有一些资源约束，因为这些服务器上的潜在需求将在移除约束之后浮出水面。

分级示例练习

在本示例练习中，可以看到负载定义如何显著影响支持固定用户数所需的硬件资源量。虽然这是一个分级示例，但 IBM 分级工具不仅依赖于派生的基准数据，还依赖于来自客户和内部生产环境的分析和反馈。

注意：本例仅作演示目的。并没有影射该分级适用于特定平台上特定版本的 Lotus Domino。

假设有 10,000 个已注册用户全部使用 Lotus Notes 作为其客户机。20％ 的用户在 15 分钟间隔内活动（分类为中用户）。事务处理日志和病毒扫描已启用。并且没有其他插件任务或第三方产品运行在该初始分级中。如果给定该信息，预计将需要 97％ 的单引擎处理器来支持该用户社区。因为这没有为工作量峰值留出许多空间，所以您最好为双 CPU 箱分配第二个引擎，其预测使用率为 50％。

让我们将活动比率从已注册用户的 20% 增加到 30％。这个看起来很小的更改实际上会使总工作量要求增加 50％，从而导致预测 CPU 利用率变为 76％ 的两路箱或 52％ 的三路箱。

现在，如果您将所有用户从中改为重，则会导致预测 CPU 利用率变为四路箱的 77％ 或五路箱的 62％。接下来，让我们添加集群功能，则 100％ 的所有用户将以没有计划复制的方式被群集到一起。这会使预测 CPU 使用变为 81％ 的五路箱或 68％ 的六路箱。然后，将 25％ 的用户从 Lotus Notes 转移到 HTTP/Lotus Domino Web Access。这会使预测 CPU 利用率变为 82％ 的八路箱或 74％ 的九路箱。

这个简单的示例通过简单更改用户运行的客户机、工作量和附加特性，演示了对于同样的 10,000 个用户，资源利用率如何变化。通过一些 “简单” 的更改，您从一路转到九路箱来支持相同数目的用户。虽然这看起来很戏剧性，但这种蔓延在您的 DPAR 中是可能发生的。当用户执行的活动越来越复杂并对 Lotus Domino 的特性越来越有经验时，当他们更改为不同的协议/客户机时，或者当您更改 DPAR 的管理方式时，您的资源使用就会受到影响。

回页首

结束语

总之，您需要基于工作量而不是仅仅基于 DPAR 上的已注册/活动用户数来对 DPAR 进行分级。很少的几个强用户和重用户可以消耗服务器资源并导致性能问题，而同一服务器可以支持多得多的轻用户和中用户。

尝试预测 DPAR 资源和未来分级时，一定要选择有代表性的用户数示例。虽然每个 DPAR 可能与分级预测不同，但必须查看所有 DPAR 的总体使用状况，以理解您是否满足您对整个社区的预测分级。

您必须监控 DPAR，从而将实际工作量和资源使用与分级预测关联。通过理解工作量和资源使用如何与预测不同，可以更好地预测当前的服务器能够支持当前环境的时间长度。您可以更好地分级下一个服务器，因为您已经对用户的工作量和趋势有了更好的理解。