大型数据库如何提升IBM Lotus Domino服务器的性能

描述总体性能的文档已经非常多，但它们都建立在这样的假设之上：Lotus Domino 的性能仅受事务数量的影响。实践经验表明，与性能相关的挑战已经扩展到使用类型，而不仅仅受限于事务的数量。

一个重要的问题就是，传输和存储的邮件的大小和数量都比以前要大。在许多环境中，除了处理传统的消息发送之外，Lotus Domino 还成为分发、文档管理和存储的中心。从本质上讲，Lotus Domino 环境为了满足客户需求而变得更加复杂了。所以现在的邮件文件比以前要大，并且还会一直增长。

一些客户正在忙着对付不断增长的邮件文件，从而确定如何处理数据并了解这些增长对性能的影响。受到业务需求的驱动，可能一个用户（或一组用户）就有多达 10 GB 的邮件文件，或者出现许多大型的邮件文件。有关这些增长对系统性能的影响的信息比较有限，因此如果管理员没有很好地理解性能如何受到影响的话，就难以采取补救措施。

一些常见的问题包括：

• 对目前的最佳调优配置而言，邮件文件变大意味着什么？
• 几个大型邮件文件真的会严重影响其他用户获得的性能吗？
• 邮件文件大小增加如何影响系统资源？

本文测试各种配置并检查它们如何影响总体性能，从而对这些问题进行研究。

方法和背景

我们对许多处理性能问题的标准方法进行了测试，以演示这些配置可能带来的益处。尽管测试能解决许多场景中碰到的问题，但是要注意每个环境的参数都是不能改变的并且在大多数情况下是统一的。当将参数直接转移到特定环境或实际的生产负载时，必须多加注意。

注意：您不能期望通过不同的调优方式来实现性能的大幅提升。性能调优的本质就是获得更高的资源效率。调优是一个反复的过程，并且这样的调优的好处很明显；越难越复杂的调优可能其价值就越低。最重要的是，任何性能的提升都受到基础资源能力的限制。本文的目标不是提供一个明确的指导方针，而是为更常见的场景提供一个新的视角。

 

硬件和软件

测试在运行 AIX® 5.3 系统的 pSeries® 630 机器上完成，该机器有 4 个 PowerPC®_POWER4™ 处理器，总主频为 1453 MHz。该系统的 RAM 为 8 GB，它的数据和 Domino 目录使用 IBM SSA® 160 SerialRAID 适配器 (4109100) 在 20 个 SSA160 物理磁盘驱动器上进行测试，每个磁盘大小为 18 GB（见表 1）。

表 1. 硬件规格

表 2 列出了测试的软件细节。

表 2. 软件规格

测试的目标是在服务器上执行高强度并发行为时，度量各种配置更改对性能的影响。

通过运行一些基础的测试负载来了解典型负载对服务器的影响，与之形成对比的是运行具有大型数据库的负载。在运行基础负载后，将实现各种不同的调优更改，看看这些更改是否对性能产生影响。 #p#page_title#e#

除了输入/输出（I/O）发生改变之外，还可能对以下事物产生一些有趣的影响：

• 文档的数量
• 事务日志
• 多个 Lotus Domino 服务器处理同一个负载
• 文档的大小
• 改变物理内存的配置和使用

通过实现 Server.Load 向服务器生成负载。使用基于内置 Notes® Remote Procedure Call (NRPC) 例程的定制脚本来模拟用户行为，这些行为包括：

• 打开数据库
• 打开并更新一个视图或文件夹
• 打开、创建、删除和发送邮件和日程表条目
• 安排日程活动

注意：随 Server.Load 附带的测试负载被设计为类似 “正常的” 使用模式。我们使用了专门用来耗费系统资源的脚本来完成测试。这个测试中的值并不代表正常情况下的使用；相反，它们反映所有用户试图最大限度地影响服务器时的使用情况。

表 3 给出了使用 dd 命令进行测试时的 I/O 子系统的持续性能度量。dd 命令是一个 UNIX® 命令，它允许您使用文件副本类型的操作控制 I/O 流。这个命令没有反映 Lotus Domino 服务器上的实际使用，因为 Lotus Domino 数据库的 I/O 模式一直都是多线程和随机的。不过，它确实反映了底层硬件的基础性能。此外，使用 RAM 磁盘文件系统再次运行了这个测试，以显示速度方面的差异。

表 3. I/O 子系统测试结果

我们关心的两个方面是响应时间和资源使用；因此，我们的最终目标是最大限度地提供资源，同时缩短对用户的响应时间。

结果

在我们的测试中，几乎耗尽事务时间的两个操作是 UPDATE_NOTE 和 Notes Indexing Facility (NIF) 操作（OPEN_COLLECTION 和 UPDATE_COLLECTION 等等）。在所有测试中，这些操作占用的事务时间占据了总事务时间的大部分。

因此，事务时间随着用户的增多而增加，而每分钟处理的事务数量则不断下降。从本质上讲，用户越多操作就越多，这就导致性能下降（见图 1）。

图 1. 事务时间和用户的数量

 

目前的资料和经验表明，邮件的性能取决于影响收件箱操作的因素。这是有一定道理的，因为这是最常用的 NIF 结构（即视图/文件夹）。当 NIF 结构变大时，对资源使用和操作时间的影响尤为明显。

图 2 显示了对 250 位使用不同数量的文档的用户的性能影响。这些结果和以前得出的结果一致。尽管这不足为奇，但在这里关键是了解数据库（甚至是视图）的大小会增加处理一个事务所需的资源。

图 2. 性能和文档数量

 

您可以将该结果与事务或用户的实际数量不断增加的场景相比较。有趣的是，当我们仅关注每分钟的事务数量时，如果将文档的数量增加 10 倍，这比将用户数量增加 10 倍产生的负面影响还大。

这是一个宽泛的比较，但它反映了文档的数量与用户的数量一样，都会影响性能。它们都对时间和资源产生负面影响。

下面这些因素对性能的影响不是很大：

• 收件箱之外的文档的数量（例如，在其他文件夹或 All Documents 视图中）
• 存储的文档的大小
• 使用的文档的大小

注意：用于测试的文档的大小不会对平均响应时间产生很大的影响，但得出的结果有很大差别。这种影响不是很明显，主要是测试中没有出现并发的情况。根据这个结果，通过测试并发性而不是数据库的大小，可以更精确地度量大型文档对性能的影响。

在数据库中包含 500,000 个以上的文档（每个文档不超过 250 KB）的情况下，重新运行这些测试。这些结果将添加到之前的测试使用的数据库的 All Documents 视图，但不添加到 Inbox 视图。这些测试结果表明，性能的差别不是很大。根据该结果，如果用户操作是 “正常的”（即测试脚本中的操作），数据库中的文档的大小和数量对性能的影响不是很明显，前提是 NIF 结构的大小保持不变。 #p#page_title#e#
 

配置测试

采用下面的配置，看看它们对大型收件箱的影响有多大：

• 大小不同的收件箱。我们使用这个配置作为基准，看看在架构能承受的范围内，收件箱的大小对性能的影响如何。
  
  

  结果显示影响是呈指数级增长的；即当文档的数量达到 80,000 时，响应时间会呈指数级增长。

• 64 位 Domino。人们通常认为 64 位架构的性能远远优于 32 位架构。但是，由于 AIX 操作系统已经运行 64 位的内核，因此这个配置用于测试将 Lotus Domino 代码改为 64 位时是否会对性能产生影响。
  
  

  我们的结果表明，尽管总体响应时间增加并且 OPEN_COLLECTION 性能下降了，但 UPDATE_NOTE 时间有略微的改进。

• 多个 Lotus Domino 服务器。Lotus Domino 不仅伸缩性很强，并且对系统资源的利用也很出色，尤其是内存。使用两个 Lotus Domino 服务器的目的是：当减少每个 Lotus Domino 服务器的负载时，使用相同硬件资源的性能是否会改变。从技术上讲，这个配置将测试使用额外的 Lotus Domino 服务器时，是否能更高效地使用系统资源。
  
  

  事实上，效率确实得到了提升，即 OPEN_COLLECTION 时间减少，而 UPDATE_NOTE 时间基本保持不变。

• j2_nBufferPerPagerDevice。这个配置是 AIX 文件系统级别的设置，它调节用于文件系统缓冲的内存量。如果 I/O 超过了设置的缓冲值，可以调整这个配置。尽管在这个测试中没有多大的必要去调整该设置，但我们将从默认的 512 K 开始增加该值，看看当将它设置得很高时是否会有负面影响。
  
  

  这个配置有细微的性能提升；不过，将该值设置为默认值的 4 倍时，尚未发现有任何负面影响。

• j2_minPageReadAhead。这个配置是另一个 AIX 文件系统设置。它控制系统对于任何读操作所能预先读取的页数。该配置的目标是合并系统必须执行的读操作的数量。如果这个设置能够明显改善性能，那么它将表明当同时读取更多数据时，O/I 将会更加高效。这个结果通常表示一个更有序的 I/O 读取模式。
  
  

  结果表明 OPEN_COLLECTION 性能得到显著提升，并且预读取值越高性能改善越大，尽管这可能会增加 UPDATE_NOTE 时间。UPDATE_NOTE 操作确实因此而延迟一些，但有趣的是，这个模式不会随着预读取值的增加而延迟得更多。

• 事务日志。事务日志将所有事务写出到一组不同的文件中。这个配置对数据库的完整性和停机后服务器重启十分有用。有了事务日志之后，服务器对存储数据库的磁盘的依赖性减弱，因为事务可以随时刷新，而不管停机何时发生。这个测试度量该特性如何处理由大型数据库引起的负载。
  
  

  总体影响基本上是好的，但要注意，该测试条件不适用于并发事务很多的情况。低并发性的测试场景能够获得一定的性能提升，这是由事务日志的本质决定的。

• 两名用户使用 All Documents 视图。每个生产环境都存在以极端或有害的方式使用系统的人员。在这个测试中，有两名用户的数据库都存储了 500,000 个文档，并且他们同时使用 All Documents 视图。这个配置的目的是度量这种用法的影响。
  
  

  有趣的是，3 次独立运行的结果表明，只有 NIF 操作时间有细微的提升（低于 5 %）。因此，Lotus Domino 能够处理少量异常使用，同时不给其他用户造成明显的影响。

• 缓冲池操作。缓冲池通常占了共享内存的大部分，因此通常可以调整这个配置。这些测试度量了从默认值 512 MB 开始，不断增加该值所造成的影响。
  
  

  结果表明性能得到有限的提升，可能是因为测试中并发事务不多。在测试运行期间，实际使用的缓冲池不超过 1 GB，尽管服务器可以使用的大小远远超过这个数值。测试结果证明了缓冲池在这里影响不大，但对于存在大量并发事务的环境是有影响的。

配置测试结论

图 3 演示了各个配置测试的结果。 #p#page_title#e#

图 3. 配置测试的结果

 

这些数据表明，可以从以下方面获得巨大的性能提升：

• 将负载分布到多个服务器。由于物理资源是相同的，使用两个服务器就能提高资源的效率。这是因为多个服务器能够更好地利用物理内存，这又使 Lotus Domino 数据库结构缓存远远优于文件系统缓存。
   
• 通过增加最小预读取值来增加 I/O 使用的有序性。这可以通过提高 j2_minPageAhead 值来实现。这个测试表明 OPEN_COLLECTION 获得了更好的性能，而 UPDATE_NOTE 事务的性能受到损害。不过总体影响是好的。
  
  

  这是一个有趣的结果，将它与通过调节 j2_nPagesPerWriteBehindCluster 增加 I/O 随机性进行比较时，尤其如此。我们发现 UPDATE_NOTE 事务的性能有细微的改进，但 UPDATE_COLLECTION 操作的性能更差。

  得出的明显结论就是，与正常的系统相比，具有更大视图和文件夹的系统具有不同的 I/O 性能，因此通过调优实现更加序列化的 I/O 可以大大提高性能。另一方面，对于文档、视图和文件夹比较小的系统，可以通过调优实现更随机的 I/O 来提升性能。（注意，这个系统的页大小为 4 K，因此一个 8 页的预读取为 32 K）。

• 使用 64 位 Lotus Domino 进行的测试中，UPDATE_NOTE 事务的性能有所提升，但总体性能大大下降。尽管测试大型数据库时性能小幅下降，但是总体测试表明并发行为很多的负载表现不错，如果不是更好的话。
   
• 我们的测试用例中的缓冲池测试受到收件箱变大的影响。由于每位用户都使用大型的收件箱，所以可用的磁盘空间限制了我们可以测试的并发事务的数量。因此并发事务比较少，这又进一步限制了更大的缓冲池的实际影响。
  
  

  尽管如此，增加缓冲池还是有一些好处的。1024 MB 的缓冲池和 1536 MB 的缓冲池产生的性能区别不是很大，因为并发事务少，所以增加的缓冲池没有派上用场。

  根据以前的文档和测试，我们了解到当缓冲池超过 1024 MB 时性能就会下降。（参见附录更多地了解具有更大并发性的缓冲池测试）。

• 事务日志对总体性能和两个主要事务类型的影响比较小但非常重要。结果表明启用事务日志能够提升性能。存在的问题是：如果日志记录对性能的影响是正面的，那么可以通过调优来实现更好的性能吗？
  
  

  以前的文档表明事务日志需要一些开销，因此使用它会影响性能。但对于数据库大小比并发事务的数量更重要的压力测试，事务日志则对性能有正面的影响。

这些结论更加证实了大型文档对性能的影响与大量事务对性能的影响是非常不同的。因此，任何调优和针对每种情况的配置都必须是合适的。

RAM 磁盘

一个不常用并且较新的特性是 RAM 磁盘，它允许使用物理 RAM 存储文件系统。当然，它不是持久化的，但它为任何临时的行为提供快速的 I/O。

我们测试的其他方面包括 Lotus Domino Directory 的存储（实验性很强）、事务日志存储和 view_rebuild_directory Notes.ini 参数的使用。

在测试时，这些方面都不能显著改善性能。其中的一些原因包括：

• 并发性程度不够高。
• Lotus Domino 能够为需要快速 I/O 的操作提供出色的物理内存。
• 测试很严格，并且限制很多；不存在影响性能的其他事件。

例如，在压力测试期间，需要有限制地重新构建视图。尽管这在生产环境中很常见，但对于一般的测试，重构视图则是不常见的。

当 view_rebuild_dir 参数指向 RAM 磁盘时，对重构时间的测试表明性能得到了显著改善。图 4 比较了大小为 4 GB 的数据库的重构时间。

图 4. 比较重构时间

 

至此，我们得出的惟一结论就是 RAM 磁盘对视图重构的影响非常大。需要人为地创建视图重构条件，以进行观察。尽管常规生产环境中需要重构视图，但一般的测试负载不需要它。

文档数量上限

限制因素主要是文件夹的结构本身会限制收件箱的大小。由于这个原因，测试所用的收件箱最多只能包含 80,000 个文档。

但是，在常规的生产环境中，有些用户可能会使用服务器上的视图或应用程序。我们知道 Lotus Domino 能够很好地处理这种类型的负载，但不同的配置会造成性能区别吗？图 5 显示了不同功能的响应时间的差别，其中服务器带有在视图中包含 400,000 个文档的数据库。

图 5. 不同配置的响应时间

 

奇怪的是，性能最好的结果来自于在 RAM 中使用事务记录（见图 5 中的黄线）。这个结果在预料之外，因为在使用 80,000 个文档的测试中，使用事务日志只产生很小的影响；再者，对于已测试的大型数据库和视图，使用事务日志产生的影响是负面的。

然而，通过在快速的独立设备（在本例中是一个基于 RAM 的文件系统）中使用日志，我们看到了显著的性能改善。您甚至会怀疑即使事务数量很少，使用大型视图时事务日志设备也将成为性能的瓶颈。

过去的文档表明需要使用最快的日志磁盘，所以我们使用 RAM 文件系统重新运行测试，看看结果是否有差别。结果表明性能的差别不大，很可能是因为并发性水平很低，日志磁盘没有成为瓶颈。

还需要注意的是，对 view_rebuild_dir Notes.ini 参数使用 RAM 磁盘，总体性能得到提升。

从这组结果可以得出的结论是：

• 使用大型视图可以在日志设备和视图重构目录中引起很大的资源问题。配置和容量的变化对性能有巨大的影响。
• 事务日志设备的速度在视图或文件夹活动频繁时显得更加重要。换句话说，带有大型文件夹和视图的数据库增加了事务日志磁盘对性能的影响。
• 使用大型视图的数据库可从对其 view_rebuild_dir 文件系统使用最快的 I/O 获得益处。

对于网络压缩统计数据，我们使用 FTP 运行该测试以进行控制，确定数据传输如何影响网络。在样例测试中，我们发现最大速度可以达到 10 MB/秒。由于 Lotus Domino 活动是非线性的、间断的，我们获得的总吞吐量很可能比实际小。

不过，我们最关心的是平均读取时间。在我们的基础测试中平均读取时间为 6.3 MB/秒，而读操作的速度为 4.3 MB/秒左右。这些数据表明网络成为了测试的瓶颈。

上面的测试似乎表明压缩虽然在一定程度上改变了行为，但它对响应时间的影响不是很明显。所以，我们认为网络带宽不是测试的主要影响因素。

此外，这些测试的并发性比前面拥有 80,000 个文档的测试的并发性小。为了测试文档数量很大时产生的影响，我们需要在数据库大小不变的情况下进一步牺牲并发性。对于任何可调优的、没有产生预期性能影响的配置，一定要考虑该限制。

结束语

为了进一步研究该领域，可以考虑测试其他配置。例如，进一步研究写 I/O 模式和网络限制，并且采用更大的数据库并提高并发性，这些只是相关想法的其中一小部分。尽管本文得出的结果并不权威，但关键要意识到大型数据库的问题非常复杂。它们的行为与传统的数据库性能设想不一样，因此也要以不同的方式处理大型数据库服务器的管理和症状。

总结一下我们的测试结果：

• 与用户数量相比，数据库的大小对性能的影响更大；不过，数据库大小不是惟一的影响。在事务类型和数量保持不变的情况下，对性能影响最大的是所使用的视图或文件夹的大小，尤其是视图或文件夹中包含的文档的数量。
• 在正常的测试负载中，还不能证明数据库中的文档的大小和数量会对性能产生确切的影响。数据表明，当收件箱的文档增长时，UPDATE_NOTE 和 NIF 操作时间呈指数级增长。
  
  

  不过需要注意的是，正常的测试负载不包含需要耗费大量资源的数据库活动，并且不考虑特定视图的大小。例如，视图重构和维护操作需要使用额外的资源来完成相同的任务。尽管数据库的总大小不是影响性能的最重要指标，但它仍具有一定的影响。

• 测试证明，并发用户对性能的影响在本质上与大型数据库对性能的影响存在很大的差异。我们发现，I/O 特性表现出一种序列模式，因此采取不同的调试方式有利于将类似的用户分组，从而利用配置方面的差异。 #p#page_title#e#
• 物理内存的使用方式能够显著地影响性能。改变缓冲池、使用多个服务器，甚至使用 RAM 磁盘，这都表明改变内存的配置能够提升总体性能。这样做也会损害性能，但是我们发现，如果有其他方法能够利用物理内存减少 I/O 操作的话，在我们的测试中使用文件系统缓存一般作用不大。
• 并发性和数据库大小之间的关系一直很难准确界定。在某种程度上，在资源使用和对性能的总体影响方面，并发性和数据库大小是互补的。例如，管理员可能将大型数据库与小型数据库结合使用，从而隐藏性能影响。另一方面，因为大型数据库使用服务器资源更频繁，方式也更多样，因此将它与其他数据库隔离开来是有好处的。
• 因为大型数据库的行为方式差别很大，所以它对调优和配置的反应也非常不同。这就需要考虑一个问题，是否应该独立存放大型数据库，以利用这些调优和配置。有比较充分的证据表明这样做是有价值的。我们希望通过清晰地定义大型数据库的特征，增强对如何管理性能的理解。

附录

下图演示当小型数据库的并发性上升时，缓冲池的大小产生的影响。注意，1000 位用户并不意味着并发性更多，它仅表示队列请求更多。下面的测试中，包含 500 位用户的测试实现了更多的并发事务。

图 A1. update_note 时间


图 A2. open_collections 时间和缓冲池大小

 

从这些图可以看到，当并发性程度很高时，管理缓冲池的大小能够获得显著的性能提升。将这个结果与使用大型数据库的测试进行比较，后者获得的性能提升很细微。事实上，在大型数据库测试期间，实际分配的缓冲池从来不超过 1 GB。这个结果演示了并发事务对缓冲池的影响，以及缓冲池的大小如何影响服务器的性能。

尽管在大型数据库测试中缓冲池从不超过 1 GB，但在并发性程度很高的小型数据库中，缓冲池的容量得到了充分的利用。因此在这种情况中，测试结果得出的性能提升比较显著。不过需要注意，当缓冲池的大小超过 1024 MB 时，就会对性能产生负面影响。

过去的测试和总体经验表明，缓冲池存在一个最佳的大小；如果超过这个大小，缓冲池占用的开销将大于它带来的好处。但不存在一个确凿通用的数据，因为缓冲池的最佳大小随不同的负载类型变化，但根据经验，当缓冲池大于 1 GB 时往往不是什么好事。

最后，OPEN_COLLECTION 时间的改善在比例方面要远远高于用户数量的减少。由这个结果可知，当磁盘的负载较小时，缓冲池的效率就越高。原因之一就是缓冲池管理指向磁盘的吞吐量；不过，当磁盘成为瓶颈时，通过配置缓冲池获得的额外收益就被抵消了。