对于大 Lotus Notes 邮件文件的最佳实践

许多公司已经发现其员工的 Lotus Notes 邮件文件在持续增长，并正在寻找控制这些大邮件文件所引发的性能开销问题的方法。因此，IBM 对大量活动的邮件文件的特征进行了研究。这些邮件文件包含了大量文档以及附件。我们还研究了与搜索频率、全文索引以及邮件文档是否在收件箱中编辑或保存相关的影响因素。

为了解如何使 Lotus Domino 获得最高的效率，我们研究了在各种情况下 Domino 上运行大邮件文件时的特征。我们尝试了不同的硬件模型、不同的操作系统以及多个 Domino 版本（包括 Domino 5、Domino 6 以及 Domino 7 的 beta 版本）。本文讨论了所得到的结果。还展示了大邮件文件是如何影响服务器性能的，并提供了减小数据库、收件箱大小以及全文索引开销的技巧，以及其他为用户、管理员和设计人员提供的方法。

当在我们的测试环境中执行本文中的一些建议时，可以使 CPU 的效率提高 30% 以上。但是请记住，这些测试是以模拟的用户负载为基础的。在您自己的环境可能会看到不同的结果。尽管本文重点讲述邮件数据库，但是大多数建议同样适用于其他数据库。我们在各种 iSeries 服务器上进行了基准检验测试，但是在其他平台上多数结果都是相同的。

本文假定您熟悉 Notes 和 Domino。

测试方法

本文中描述的测试使用了各种 iSeries 服务器型号。这些服务器包括 830-2349（8 路 540 MHz）、840-2461（启用 8 个处理器）、840-2461（启用 24 个处理器）、i5 POWER5 520（2 路）和 550（4 路）。我们还测试了多种 Domino 版本，包括 Domino 5、6 和 7.0（beta）代码。本文结尾部分的建议适用于所有这些 Domino 版本。

负载是通过在多达 16 台 PC 客户机上运行 Server.Load 生成的。Domino Administrator 客户机包含这一免费工具。一些测试中还使用了 NotesBench 工具。选择内置的 R6 Mail Routing 脚本作为负载。这种脚本基于来自 Domino 客户中邮件用户的使用模式。每台 PC 将模拟 500 到 1000 名用户。Server.Load 报告模拟用户经历的平均响应时间。在所有的情况下，服务器端的负载都是这样的，响应时间从未超过一秒钟，通常会更短（用 2 GB 的邮件文件和收件箱中的所有邮件进行测试，负载最大的用户响应时间为 750 msec；负载最小的用户响应时间为 11 msce）。

对于大多数测试，在由 1000 个用户组成的组中每秒钟都会有一个新用户启动。1000 个用户都进行登录需要花费 17 分钟。然后在开始下一组之前，“中断” 13 分钟。实际的使用模式（例如，星期一早晨的峰值）负载可能会更大。经过了过渡时期，每一个工作负载都会保持在“稳定状态”至少两个小时以上。

在每次运行之前，创建全部邮件文件的新拷贝以使运行变动最小化。对于大多数测试，都是以大小为 25 KB 的文档来填充邮件文件。这是根据对 IBM 的内部用户以及各种客户的研究做出的决定。相比之下，带有少量大文档的同样大小的数据库需要较少的 CPU 资源（本文下面的部分将会详细论述）。

我们使用 Server.Load 和内置的 NRPC Mail Initialization 负载创建不同大小的邮件文件。正如所描述的，多数测试是使用由大小为 25 KB 的文档构建的邮件文件进行的，使用的文档数量从 100 到 50,000 不等。一些测试使用的总邮件文件大小都相同，如 700 MB，但是这些邮件文件是由收件箱中不同数量的文档构成的。其他的测试在保持邮件文件包含的文档数量不变的情况下，对不同大小的邮件文件进行了比较，如 400 MB 与 1 GB 的比较。

使用 Series Performance Tools（5722PT1）监控系统性能数据，监控包括 CPU、磁盘、内存和网络等系统资源的使用情况。

回页首

结果

本节讨论了我们的测试结果。在查看这些数据时，请一定要注意给出的邮件文件特征，包括文档大小、文档数量、邮件文件大小和位于收件箱中文档的百分比。

邮件文件大小

首先，看一下邮件文件的大小对性能产生的影响。通过增加文档的数量构建了依次增大的邮件文件。随着文档数量的增加，邮件文件的大小从 20 MB 增大到 2000 MB（参见图 1）。

图 1. 邮件文件大小

如图 1 所示，CPU 使用情况的增长与邮件文件大小的增长几乎为线性关系（CPU 在稳定状态和峰值时的使用百分比都是如此）。邮件文件都是使用大小为 25 KB 的文档构建的。

基于这个测试，我们得到了这样的结论，大邮件文件需要更多的内存，尤其是当用户会话开始时以及在故障转移期间。减小邮件文件的大小可以提高视图索引编制、压缩、备份还原和事务日志记录的性能。为了衡量这一影响，我们使用了范围从 15 MB 到 2 GB 的各种大小的邮件文件进行测试。随着文件增大（邮件文件至少增大到 2 GB），并没有观察到稳定状态的 CPU 使用情况的极剧增长。过渡状态的 CPU 峰值较之稳定状态增长的速度要快，但是同样没有看到极剧的增长或曲线上出现“弯头”。过渡状态模拟的是在短时间内很多用户进行登录的情况，例如星期一的早晨或故障转移期间。在图 1 中，例如，将平均邮件文件大小从 500 MB 增大到 1000 MB 将导致稳定状态 CPU 的使用率增加 12%，但是在过渡状态将增加 55%，比稳定状态要高。这些测试都是在所有的文档都存放在收件箱中的情况下进行的。

管理收件箱中的文档

在下一个测试中，我们在 80 分钟的时间段内启动 2000 个用户，接下来是一个 90 分钟的稳定状态。对于其中的一个测试，文档保留在收件箱中，同时在第二个测试中，我们限制收件箱中文档的数量是邮件文件文档总数的 25%。然后我们比较这两组同一时段的 CPU 使用情况（参见图 2）。

图 2. 对于保留在收件箱中文档的时间曲线

我们发现，当保留在收件箱中的文档限制为文档总数的 25% 时，与将所有的新文档都保存在收件箱中相比，峰值 CPU 使用率会降低 50%，稳定状态下 CPU 使用率降低 12%。

接着我们进行了类似的实验，在这个实验中比较了两组用户的 CPU 使用情况，其中一组每个用户的收件箱中有 1000 个文档，另一组每个用户的收件箱中有 5000 个文档。每组都由 5000 个用户组成；为所有用户都构建了索引和全部的文档视图。图 3 显示了测试的结果。

图 3. 收件箱中文档的数量

在图 3 中，两组用户使用 400 MB 的邮件文件，另外两组用户使用 1000 MB 的邮件文件。在每种情况下，通过管理收件箱减少了 CPU 开销 5% 以上。现在来比较一下相同两组的 CPU 峰值使用情况（参见图 4）。

图 4. CPU 峰值使用情况

如图 4 所示，对这两组中的每一对而言（邮件文件大小为 400 MB 时，CPU 的使用情况为 50% 和 72%，邮件文件大小为 1000 MB 时，CPU 的使用情况为 62% 和 75%），将收件箱中最大文档数量设置为 1000 都能够极大地减少 CPU 峰值资源消耗。通过减少收件箱文档的数量，CPU 峰值比 CPU 的稳定状态所获得的性能提升更大些。

最后，看一下管理收件箱中的文档数量对响应时间产生的影响（参见图 5）。

图 5. 响应时间

保持收件箱中的文档数为 1000 或者更少时，终端用户会获得极其快速的响应时间 —— 邮件文件大小为 400 MB 时为 23 msec 和 37 msec，邮件文件大小为 1000 MB 时为 24 msec 和 40 msec。

从这些测试中我们发现，减少收件箱中的文档数量能够改善用户的响应时间，还能够减少对服务器的资源需求（CPU、内存、磁盘 I/O 和服务器启动或故障转移的时间）。在“首次使用”时效果非常显著。减少收件箱中实际文档数量的 75%，将消除过渡状态的峰值。在图 2 中，例如 CPU 峰值下降了 50%，同时在稳定状态下 CPU 性能提升了 12% 到 30%。如图 3、4 和 5 所示，当收件箱中保留 1000 个或更少的文档时，邮件文件大小为 400 MB 的平均响应时间要减少两倍多。

固定大小和大小不同的邮件文件

我们还比较了大小不同的邮件文件的测试结果，以便模拟典型的用户数据，但是发现每个测试除了设置时困难些之外，测试结果没有显著的不同。对于大小不同的邮件文件，过渡状态的峰值更加明显，平稳状态的 CPU 使用情况几乎相同（参见图 6）。

图 6. 固定大小和大小不同的邮件文件

大小不同的邮件文件大小范围从 26 MB 到 2000 MB，平均大小为 700 MB。大小不同的邮件文件的过渡时期峰值稍微明显一些，但是稳定状态下是相同的。

索引和搜索

下面，我们来测量一下全文索引和搜索对 CPU 使用情况产生的影响。搜索负载由每个用户每隔 15 分钟对收件箱进行一次搜索产生。测试结果如图 7 所示。

图 7. 全文索引和搜索

可以看到，只需要很少的 CPU 资源来维护索引（在我们的测试用例中是 1%），但是却需要使用高达 20% 的 CPU 资源进行搜索。

基于这个测试我们得出：如果需要定期搜索数据库，创建全文索引通常是较好的做法。维护全文索引对性能影响甚微，并且通常有许多可用的选项使影响最小化。如果数据库没有进行索引，服务器在需要时就会创建一个“动态”的索引，这样做的开销非常大。可以通过在 Notes.ini 文件中设置 FT_FLY_INDEX_OFF=1 来禁用该功能。

文档的大小和数量

我们测试了邮件文档大小和数量对 CPU 使用情况的影响。在这个测试中，每个由 2000 个模拟用户组成的组中用户都有 700 MB 的邮件文件。不同之处在于，其中一组中的每个用户的邮件文件包含 28,000 个大小为 25 KB 的文档，而另外一组中的每个用户的邮件文件包含 7000 个大小为 100 KB 的文档。测试结果如图 8 所示。

图 8. 文档的大小和数量

我们发现相同大小的邮件文件使用的资源可能相差很大，这取决于文档的平均大小和数量。在我们的测试中，邮件文件中具有较少文档的一组消耗的 CPU 资源要比具有 28,000 个邮件文档的组少很多。

这个测试说明，与文件大小本身相比，邮件文件中的文档数量（尤其是收件箱中文档的数量）对性能会产生更大的影响。当然，这两个变量在实际情况下通常是相关的。无论如何，在给定邮件大小的情况下，我们观察到具有很多小文档的用户比那些使用几个大文档的用户使用更多的资源。

Domino 分区

最后，我们比较一下在用户数量固定的情况下，使用不同 Domino 分区数目对 CPU 使用情况产生的影响。下表概括了我们得到的结果：

上表中显示的性能信息是使用 Domino 7 的一个 beta 版本并通过更改测试内容收集的。Domino 7 中的性能提高，使单个 Domino 分区所支持的用户数量比 Domino 6 能够支持的要多。数据代表在五小时的稳定状态期间的平均使用情况以及响应时间。请注意在单个 Domino 分区的情况下，CPU 的使用情况明显低于两个或四个分区时的情况。内存和磁盘统计数据也显示出较少的 Domino 分区需要较少的内存资源。响应时间的差异只有 1 msec，可以无需考虑，而且可能是由于测量的误差引起的。实际情况是单个分区的响应时间并不比其他测试中的慢，而内存和磁盘统计数据显示了性能的提高，但是需要说明的是，单个磁盘上过多的用户会导致争用增加。

每台新服务器都需要附加的系统资源。邮件的传递可能需要更长的时间，因为很可能信息当前在其他服务器上。Domino 7 进一步改进了所有平台上的可伸缩性，允许每台 Domino 服务器都支持更多的用户。在我们的测试中，合并来自四台服务器的用户到单个服务器上，CPU 总体提升 10%，还减少了内存的使用。

回页首

建议

根据我们的测试结果，我们提供几条关于提高 Domino 邮件性能的建议。提高 Domino 性能最简单的方法是控制收件箱。我们的测试表明，减少收件箱的大小（将同一邮件文件的文档放入一个文件夹内）能够减少终端用户的响应时间、服务器上 CPU 稳定状态的使用率，特别是减少 CPU 的峰值。此处的 CPU 峰值与用户第一次打开他们的文件（接着会话超时）相关联。所以应该建议您的用户将收件箱中的文档存放到其他的文件夹中，以使收件箱尽可能小（最好少于 1000 个文档）。这样做将得到更快的响应速度，同时提高资源的利用率。还可以写一个代理来自动“整理”收件箱。例如，这个副文件 包含代理样例的代码，这个代理从收件箱中移除旧文档（但是这些文档在 All Documents 视图中仍然可用）。可以将这个代理设置为在工作时间以外自动运行，例如周末。

除了收件箱维护之外，我们为 Notes 用户、Domino 管理员和系统规划者提供了下列技巧。

Notes 邮件用户

下面这些建议适用于每一位 Notes 邮件用户：

• 归档。 Notes 和 Domino 包括基于客户机的和基于服务器的归档功能。可以设置自动运行或手动运行归档；接下来的工作由 Notes 和 Domino 完成。旧文件将会移动到归档数据库，所以重要的信息不会丢失。与您的管理员一起研究是否有其他可用的归档方案。
• 客户机当前版本。 升级到您的 Domino 服务器支持的最新可用 Notes 版本通常会获得性能的提高。一般在较新的 Domino 版本上进行的性能提高，只有对客户机代码也做了相应更改后才能完全发挥作用。
• 使用正确的工具。 考虑使用其他的文档管理解决方案（例如 QuickPlace 或 Domino Document Manager）是否有助于使相同信息的多个副本最小化，并方便更多的收件人访问此信息。

Domino 管理员

有很多可用的选项帮助管理员管理电子邮件系统：

• 邮件文件限额。 可以通过在数据库上设置限额来控制邮件文件的大小。限额是允许数据库增大到的最大值。可以为不同类别的用户建立不同的限额。例如，调查人员比销售人员需要更大的限额。从 Domino 管理客户机（选择 Tools - Database - Quotas）可以很方便地设置数据库限额。需要建立定期且紧凑的日程安排，以利用限额和其他的数据库管理技术所带来的好处。
• 内存调整。 大邮件文件使用更多的内存。内存的瓶颈可能会引起 CPU、磁盘 I/O 资源的浪费以及响应时间变慢。我们在 iSeries 服务器上的测试，通过确保设备池有足够大的空间来保证每秒钟少于 5 个页面失效，这显著改进了 Domino 响应时间。这是非常有意义的，因为以前 OS/400 自动调整器的默认阈值为设备池中每秒钟 10 个失效。在基本池中降低内存失效数量同样可以获得显著收益。使用其他适用于您的操作系统的内存调整机制。
• Domino 服务器当前版本。 坚持使用最新的 Domino 版本，因为在每个版本中通常都包括性能上的提高。还应该关注使用新功能所带来的附加开销。查看 Notes/Domino 产品页面，获得关于每个 Domino 版本的性能和其他好处的信息。
• 客户机当前版本。 如上所述，让用户使用最新的 Notes 客户机版本可以显著地提高性能。IBM Lotus Notes 智能升级功能使保持最新版本变得很容易。
• 全文索引。 在需要定期进行搜索的数据库上创建全文索引。维护索引的开销几乎总是比创建“动态”索引的开销小得多（参见图 7 中的示例）。
• 每台服务器上的用户数。 在 iSeries 服务器上，在单个操作系统或逻辑分区（Logical Partition, LPAR）上通常运行多个 Domino 分区（DPAR）。通常情况下，给定服务器上的用户数量取决于备份策略和其他的管理因素，例如用户的物理位置、存储需求、完成维护任务的时间和容错能力。考虑到性能和资源利用，通常应该尽可能地合并 DPAR，使 DPAR 个数越少效果会越好。
• 归档。 管理员可以通过运行带有归档选项（-a 或 -A）的压缩任务来对数据库进行归档。很多产品都为 Notes/Domino 数据提供了高级的归档功能。
• 端对端监控。 Domino 环境中有效的监控不仅仅包含单个系统和 Dominio 服务器的统计信息，还应该包括网络组件和存储子系统（例如，SAN 组件）的性能。

系统规划者

调整大规模 Domino 环境是一个复杂的过程。在这样的环境中，多种工作负载及工作负载之间的关系对性能的影响被放大了。基于我们的研究，我们对那些设计和调整具有如下一个或更多特性的 Domino iSeries 环境的用户给出建议：

• 5,000 名或更多的邮件用户
• 邮件文件大小为 500 MB 或更大
• 实施环境中包括 10 个或 10 个以上的 Domino 分区或服务器

在调整时，一定要考虑大型数据库的额外开销和进行全文搜索的频率。在调整时使用多种工具；例如 Tivoli Analyzer for Domino、NotesBench 数据、现有服务器的性能、IBM eServer Workload Estimator 以及用于可以在 iSeries Performance Capabilities Reference 中找到的所有 iSeries 服务器模型的 Domino Mail & Calendar User（MCU）等级标准。

回页首

结束语

我们希望您觉得本文提供的测试数据和建议是有用的。当然，邮件是 Notes 和 Domino 中最重要且使用最多的功能之一。确保您的邮件用户获得好的性能，保证您的 Notes 群体中所有人都能愉快地使用系统 —— 并能够使您的生活变得更加轻松！