级别： 中级 Reinhold Engelbrecht (r_engelbrecht@at.ibm.com), 世界范围的内容管理技术支持和销售支持, IBM
2007 年 6 月 29 日 DB2® CommonStore for Lotus® Domino®（CSLD）是归档电子邮件和其他 Notes® 文档的一种出色工具。它带有很多配置选项，这些选项可影响整体吞吐量和性能。如果您处于中型或大型环境中，那么本文提供了为优化归档性能而进行调优所需的知识。本文解释了不同的设置，并就如何提高归档吞吐量提供了一些建议。文中讨论的话题包括单个和多个 CSLD 任务数据库、单线程和多线程 CSLD 任务、单个和多个 archpro 实例以及每个 archpro 实例的 CM 代理数量。本文还对在一些测试案例中得到的典型的性能数字作了概述。在调整系统规模和选择架构时，这些数字可以作为参考。
简介
DB2 CommonStore for Lotus Domino 对于归档电子邮件或其他 Notes 文档来说是个很棒的工具。在较小型的客户环境中，使用缺省设置就可以取得令人满意的吞吐量，但是在中型和大型环境中，则应该有计划地对 CommonStore 进行调优。
在本文中，我们将看到当使用 DB2 CommonStore for Lotus Domino v8.3 (CSLD) 并以 Content Manager v8.3（CM）作为后端储存库时，归档吞吐量优化的不同方面。文中给出的数字是在 Windows® 和 UNIX® 环境中得到的，如果平台不同，或者不是使用 Content Manager 作为储存库，那么得到的数字可能有所差异。
归档过程中的数据流
归档 Lotus Domino 中的电子邮件（或任何其他 Notes 文档），实际上意味着将一个数据对象及其附加的属性信息从 Lotus Domino 转移到 IBM Content Manager (CM) 中。从技术角度来看，这牵涉到如图 1 中所示的一些组件和步骤。
图 1. 归档过程中的数据流
数据流的发生顺序如下：
- 一个 CSLD 任务线程通过 Notes API 访问 Domino 服务器，并读取数据。每个 CSLD 任务可以有一个或多个线程。
- 该 CSLD 任务将数据存储在 CommonStore 服务器上的一个临时文件中，并通过一个 TCP/IP 端口连接到 archpro 服务器（CommonStore 的一个子组件）。
- archpro 服务器充当一个或多个 CM 代理的调度器，这些 CM 代理是到 CM 的连接器。CM 代理提取临时数据文件中的数据，并通过使用 CM Java API 将其存储在储存库中。
- 数据作为一个 CM 文档或某种 CM 项目类型的资源项目存储在 CM 中。
- 归档后，返回码沿着反方向返回，以便让 CSLD 任务线程清除 Domino 中的报文。
- CM 系统还可以创建和维护被归档对象的一个全文本索引（可选设置）。这是一个异步过程，其作用是从被归档对象中提取文本信息来更新全文本索引。为此需要检索被归档对象。
- CM 配置决定如何存储电子邮件。通常，电子邮件首先被存储在一个硬盘驱动器上，然后被迁移到诸如磁带之类的其他存储上。CM 使用 Tivoli® Storage Manager（TSM）来将被归档对象存储在硬盘驱动器以外的设备上。它通过 TSM API 集连接到 TSM。这种存储迁移是一个异步的过程，通常是在每天夜间运行一次。
- TSM 服务器将数据转移到一个特定的硬件设备上。每个设备有它自己的写/读特征。
对于 CSLD，步骤 1-5 是同步的。这意味着 CSLD 任务在完成前一个任务之前，不能开始处理新的归档请求（一个 CSLD 任务由一个或多个归档请求组成）。
通过以上数据流可以看出，归档总吞吐量实际上取决于各项不同的子吞吐量（或者说总吞吐量由这些子吞吐量组成）：
- 从 Domino 到 CM（步骤 1-5）的吞吐量。我们可以称之为 CommonStore 吞吐量。
- CM 中创建全文本索引（步骤 6）的速度。
- 从 CM 迁移到 TSM（步骤 7）的吞吐量。
- 写到物理存储设备（步骤 8）的写吞吐量。
不一定所有的子吞吐量都一样。假设每天要归档一定量（以 GB 计）的邮件。可能从 Domino 归档到 CM 需要 8 个小时，创建全文本索引需要 3 个小时，而迁移到 TSM 和磁带上存储只需要 30 分钟。所以优化归档吞吐量的第一步是确定这四个子吞吐量中最可能成为瓶颈的那个子吞吐量。
例 1: 在某个客户环境中，创建全文本索引所需的时间远远多于将被归档对象从 Domino 传输到 CM 所需的时间。分析表明，很多要建索引的对象已经被存储在磁带上。由于创建全文本索引需要提取文本信息，因而需要从磁带上检索很多对象，这个过程是十分缓慢的，大大影响了创建全文本索引的速度。通过更改从 CM 到 TSM 的迁移策略，在硬盘上为对象建索引，这个问题得以解决。
例 2: 在某个客户环境中，Domino 服务器分布在数个站点上，而 CSLD、CM 和 TSM 则集中在一起。与其他子吞吐量相比，CommonStore 归档吞吐量显得相当缓慢。其原因是到 Domino 服务器的 WAN 连接的带宽不够。
本文重点谈从 Domino 到 CM 的吞吐量的优化，这一吞吐量主要由 CommonStore 决定。CM、底层 DB2、TSM 或硬件设备中的优化不属于本文的讨论范围。
单个归档事务的持续时间
当优化 CommonStore 中的归档吞吐量时，在将归档事务并行化以增加整体吞吐量之前，首先应该考虑单个归档事务。
那么归档一封 Notes 电子邮件要花多少时间呢？对这个问题有没有一个简单的答案？如果 Domino、CommonStore 和 CM 服务器集中在一个位置（连接有 LAN，100 Mbits Fast Ethernet 或者更好的网络连接），那么每封 Notes 邮件的归档时间为 0.6-1[秒]。这个数字是在电子邮件平均大小为 70-100 KB 的情况下测到的，这个电子邮件平均大小是这些天我们在我们的项目中观察到的。由于每个事务都有一个基本的开销，如果报文的平均大小较小（例如 10 KB），那么事务持续时间不会显著减少。但是，当邮件大小达到 2MB 甚至更大时，事务持续时间可达到几秒。
根据前面提到的单个事务的通常持续时间，单线程 CommonStore 的吞吐量通常为每小时 3,600-6,000 封邮件。如果您想看看在自己的系统中情况如何，那么应该对同一个邮箱中 100 封以上的邮件进行归档，并检查 CSLD 任务，查看持续时间字段。注意，当创建 CSLD 任务时，需要选择属性 Leave Request in Job database，这样在归档之后成功的任务不会自动被删除。
如果激活了 CommonStore 单实例存储（single-instance-storage，SIS）算法，那么应确保所有邮件各不相同，并且没有存储在储存库中。否则，得到的数字会令人产生误解，因为重复的邮件是不归档的。对 CSLD 任务和 archpro 的跟踪应该不激活。图 2 显示了本文使用的 demo 系统上的结果。100 个文档耗时 58 秒，对应的 CommonStore 吞吐量为每小时 6,200 封邮件。
图 2. CommonStore for Lotus Domino 任务文档
0.6-1[秒]的总时间被用在从 Domino 提取信息、内部处理和将邮件真正存储到 CM 这三个方面。后者可以通过查看由 archpro 进程（在激活日志记录的情况下）生成的 ai*.log 文件来进行分析。对于每个事务（归档、检索 …），该文件中都添加一行。可以很容易地将这个日志装载到一个电子表中，以便做进一步的分析。图 3 展示了一个被装载到 MS Excel 中（某些列被隐藏）的 ai*.log 文件。
图 3. archpro 生成的 ai*.log
列 T_ag 显示 CM 代理将邮件存储在 CM 中所花的时间，单位为秒。对于大小为 70-100 KB 的邮件，这个时间为 0.2-0.6 [秒]。最右边的列记录对象的大小，单位为字节。
如果在系统中碰到 T_ag 值明显较高的情况，则可能有以下原因：
-
数据库索引缺失或被破坏: 如果激活了 CommonStore SIS 算法，则 CM 代理会检查新文档的散列码（hash code）是否已经在储存库中，以避免重复。这种检查要求在 CM 中配置 CSCDISIS 属性的一个数据库索引。如果没有配置该数据库索引，那么随着储存库中的文档越来越多，检查的速度就会越来越慢。注意，通常情况下，CSCDISIS 属性并不是惟一有数据库索引的属性。如果用户被允许搜索已归档的邮件，那么也应该为字段 CSLDOrigDB 和主要的搜索标准（如 Subject 属性）配置数据库索引。
-
WAN: CommonStore 和 CM 服务器之间的连接可能比较慢。
-
常见 CM 服务器性能问题: 其他装载问题或系统性能不佳可能导致性能问题。
ai*.log 文件还显示较慢的归档操作是否限于一天中的某些时段。在某些情况下，Content Manager 上的某些周期性维护过程（例如备份、数据库重组、病毒扫描等）可能导致性能暂时下降。
优化 CommonStore 归档吞吐量
根据前面的分析，前面描述的单线程归档方式每小时可归档 0.3 到 0.6 GB（或者按每天 20 小时算，可归档 6 到 12 GB），然而，这种方式不足以为较多的用户提供邮件归档。
为了增加 CommonStore 归档吞吐量，建议将归档线程并行化。可以将 图 1 中的所有子组件配置为并行运行：可以有多个 CSLD 任务（每个 CSLD 任务有数个并行的内部线程），而且还可以有多个 archpro 实例（每个 archpro 实例有数个并行的 CM 代理）。
可以直接在 archpro 配置文件 archint.ini 中，通过将关键字 CMAGENTS 设置为所需的并行代理数，来添加更多的 CM 代理。
再添加一个 archpro 实例也很简单。只需复制并粘贴 instance01 目录，然后将所得副本命名为 instance02。
另外还要修改 instance02 的 archint.ini 文件，以便所有对该实例目录的引用反映 instance02 的位置。
而且，有必要指定一个不同的端口号，以供新的 archpro 实例侦听请求。这个端口号由 archint.ini 中的关键字 ARCHPRO_PORT 定义。
注意，为了利用第二个 archpro 实例，至少需要两个 CSLD 任务，因为一个 CSLD 任务一次不能连接到一个以上的 archpro 实例。
然而，增加并行 CSLD 任务的数量，特别是增加它们内部的线程数，并不是件容易的事情。这不是仅仅通过设置某种配置文档中的一个参数就可以完成的，而是需要对环境进行分析，设计设置，使并行 CSLD 任务线程成为可能。让我们更仔细地看看两个典型的例子。
例 A （邮箱管理）： 客户在一个 Domino R7 服务器上有 1,000 封邮件。邮件数据库分布在四个数据目录中，每个数据目录存放 250 个 NSF 文件。CSLD 的缺省配置由一个 CSLD 任务数据库组成，该数据库有一个单线程的 CSLD 任务（连接到一个 archpro 服务器）为其服务。一个 CSLD 任务线程按顺序为所有任务服务，并且逐个地连接到各个用户邮箱，以便提取邮件。
例 B （遵从性和发现）： 客户有一个 Domino 服务器。由于遵从性方面的原因，所有电子邮件都存有日志，也就是说，每个邮件在到达用户收件箱之前，都要做一个副本，存储在一个日志邮箱（NSF 文件）中。这里只有一个 CSLD 任务数据库。一个 CSLD 任务线程处理对日志数据库的所有归档请求。
在以上场景中，如果性能偏低，那么采取的第一个步骤通常是像前面解释的那样增加 CM 代理的数量。但是这样做根本不能提高性能，因为 CSLD 任务是按顺序的方式进行处理的！只要只有一个 CSLD 任务线程是活动的，那么就只有一个 CM 代理在忙。正因为如此，我们需要理解如何增加并行 CSLD 任务的数量，以便 archpro 可以使用更多的 CM 代理。
如前所述，CSLD 任务为 CSLD 任务数据库中的所有任务服务。假设在例子 A 中有 1,000 个任务要处理，每个任务来自一个不同的用户数据库。那么，一个单线程的 CSLD 任务将看到所有这 1,000 个任务，并按顺序逐个处理它们。如果我们想采用四个 CSLD 任务线程（在同一个 CSLD 任务中），那么就需要确保每个线程处理 1,000 个任务中的一部分。另一方面，为了避免数据的不一致，两个不同的线程决不能处理同一个任务。CommonStore for Lotus Domino 为每个线程提供所有任务的一个不同的视图，使每个线程有它自己的一份待处理任务列表，从而满足了这一需求。图 4 显示了如何在一个 CSLD 任务中设置多个线程。
图 4. 配置多线程 CSLD 任务
第一个选项 All databases 对应于单线程配置。如果使用第二个选项 Selected Domino servers，则可以单独为每个 Domino 服务器配置线程。假设有两个 Domino 服务器。线程 1 看到并处理与 Domino 服务器 1 上的邮箱相关的所有任务，而线程 2 则处理与服务器 2 相关的所有请求。但是，对于前面的例子场景，这种设置并不会带来任何改善，因为那些场景中只有一个 Domino 服务器。而且，最佳实践是在每个 Domino 服务器上本地创建一个 CSLD 任务数据库，每个任务数据库由一个单独的 CSLD 任务来服务。对于前面提到的双服务器配置，则有两个单线程 CSLD 任务，每个任务为它们相关的 CSLD 任务数据库服务。所以在实际的系统实现中，第二个选项很少使用。
第三个选项 Selected databases or data directories 常常是最可取的。它允许单独为各个数据库或整个目录配置线程。在图 4 中，有 4 个线程：线程 1 处理与 test1.nsf 数据库相关的所有请求，线程 2 处理与 test2.nsf 相关的所有请求，依此类推。这些线程是由 CSLD 任务自动启动的，并且并行地运行。如果在一个命令窗口中开始任务，则可以看到各个线程，如图 5 所示。注意，每个 CSLD 任务线程也有它自己的跟踪和日志文件。
图 5. 运行一个多线程 CSLD 任务
如果一个任务请求从数据库 test5.nsf 归档邮件，会发生什么情况呢？哪个线程将处理该任务？回答是：没有线程会看到这个任务。这个任务在 Waiting to be processed 状态下盲目地等待。
让我们回顾前面提到的例子场景 A。一种（理论上的）方法是单独为每个邮箱配置一个线程。然而，无论是从可维护性的角度看，还是考虑到 Windows 多线程的限制和内存约束，使用 1,000 个线程都是不实际的。可取的方法是为每个邮箱目录指定一个线程。这样一来，在例子场景 A 中就有 4 个并行线程：线程 1 为邮箱目录 mail1 服务，线程 2 为邮箱目录 mail2 服务，依此类推。
这个 4 线程任务连接到一个 archpro 实例。如果只配置了一个 CM 代理，那么 archpro 可能成为一个瓶颈，因为这一个代理需要串行地处理由 4 个并行的 CSLD 任务线程请求的归档操作。由于这个原因，建议配置 4 个 CM 代理，确保从 Domino 到 Content Manager 有 4 个并行的 "管道"。（如果预计归档过程中会出现多个并行的检索请求，那么还应该进一步增加 CM 代理的数量。）
在那样一个配置中，如果两个用户的邮箱分别位于他们各自的邮箱目录中，那么可以并行地处理他们的归档请求。但是如果他们的邮箱在相同的邮箱目录中，那么他们的请求就是由同一个线程按顺序处理。这种配置选项还可以为一个邮箱添加一个特殊的线程，使之具有优先处理权，从而可以进行特殊的 "VIP" 处理。但是要注意，这些特殊的邮箱要放在一个单独的目录中。否则，标准的 CSLD 任务线程（运行在数据目录上）与这种特殊的 CSLD 任务线程将在归档上产生竞争，从而可能导致数据出现不一致。
这种配置选项在例子场景 B 中有没有帮助呢？在那样一个环境中，所有邮件都是从一个 Notes 数据库（journal）中提取的。图 4 中的三种线程配置选项都没有帮助，因为邮件总是从同一个 Domino 服务器上的同一个数据库中归档的。结果总是一个单线程的 CSLD 任务。假设每天开 20 小时的处理窗口，拥有每小时 3,600 封邮件的低端吞吐量，那么归档量为每天为 1,000 名用户归档 72,000 封邮件（或者说每天每个用户 72 封邮件），在大多数情况下这已经远远足够了。
如果有更多的邮件需要归档，或者每天用于归档的时间窗口少于前面假设的 20 小时，那么下面的变通办法可以帮助将归档并行化。假设一个（定制的） Notes 代理随机或轮流地在 4 个（而不是一个） CSLD 任务数据库中创建归档任务。那么可以设置 4 个单独的（单线程） CSLD 任务，每个任务为它相关的任务数据库服务。这 4 个单线程 CSLD 任务通过 4 个 CM 代理连接到同一个 archpro 实例。和场景 A 相似，这种设置从 Domino 到 Content Manager 有 4 个并行的 "管道"。
并行归档操作
验证并行设置的一个好方法是看 CSLD 任务数据库。处于并行状态的多个任务明显表明存在并行处理。在图 6 中，有 5 个任务处于暂挂（pending）状态。这意味着有 5 个并行的 CSLD 任务线程。
图 6. CSLD 任务数据库中的并行处理
如果有多个任务数据库，那么需要对每个 CSLD 任务数据库进行相同的分析，然后总计出并行线程数。
如果想验证 archpro 的 CM 代理是否真正并行地连接并归档到 CM 储存库，ai*.log 不会显示这样的信息。虽然有一个名为 PID 的列，如图 3 所示，但是这个列的值总是为 0，并不反映代理数量。发现这种信息的惟一方法是激活 archpro 跟踪。在跟踪中，需要搜索 CM-AGENT WORKER -POOL: notified CM-AGENT WORKER，看看哪个 CM 代理被用于归档。如果 worker 2 或 3 被激活，那么显然归档是并行进行的，因为这表明 1 正忙。清单 1 显示了 archpro 跟踪的一个摘录。
清单 1.
并行 CM 代理
[16:37:09.568 20-09] CM-AGENT WORKER -POOL: notified CM-AGENT WORKER #1
[com.ibm.esd.commonstore.task.CSThreadPool]
[16:37:09.568 20-09] Job (ID: : SERVER-JOB QUEUE : added response server-job
(new job count: 1)
[com.ibm.esd.commonstore.job.CSServerJobQueue]
[16:37:09.568 20-09] SERVERJOB QUEUE: In getNextJob: got a job
[com.ibm.esd.commonstore.job.CSServerJobQueue]
[16:37:09.568 20-09] CM-AGENT WORKER #1: Job <3> start job processing
[com.ibm.esd.commonstore.agent.worker.CSAgentWorkerThread]
[16:37:09.568 20-09] processJob() is starting.
[com.ibm.esd.commonstore.agent.worker.CSAgentWorkerThread]
|
表 1 显示了一些 CommonStore 吞吐量数字，这些数字是在一个使用低端的、相当陈旧的 PC 服务器的测试环境中测到的。每一列表示一个测试案例。
|
CommonStore 吞吐量案例
|
案例 1
|
案例 2
|
案例 3
|
案例 4
|
案例 5
|
案例 6
| |
报文大小 [KB]
| 102 | 102 | 102 | 102 | 102 | 517 | |
CSLD 任务数量
| 1 | 1 | 1 | 1 | 2 | 1 | |
每个任务的 CSLD 任务线程数量
| 1 | 2 | 4 | 8 | 4 | 4 | |
CSLD 任务线程总数
| 1 | 2 | 4 | 8 | 8 | 4 | |
archpro 实例数量
| 1 | 1 | 1 | 1 | 2 | 1 | |
每个 archpro 实例的 CM 代理数量
| 1 | 2 | 4 | 8 | 4 | 4 | |
CM 代理总数
| 1 | 2 | 4 | 8 | 8 | 4 | |
文档数量
| 100 | 200 | 400 | 800 | 800 | 400 | |
持续时间，单位为秒
| 58 | 71 | 81 | 175 | 107 | 105 | |
吞吐量，单位为文档/秒
| 1.72 | 2.81 | 4.93 | 4.57 | 7.47 | 3.81 | |
吞吐量，单位为文档/小时
| 6,207 | 10,141 | 17,778 | 16,457 | 26,916 | 13,714 | |
吞吐量，单位为 GB/小时
| 0.63 | 1.03 | 1.81 | 1.68 | 2.75 | 7.09 |
案例 1 到 4 展示如何通过多线程 CSLD 任务增加 CommonStore 吞吐量。虽然当有多达 4 个 CSLD 任务线程连接到一个 archpro 实例时，性能有显著的提升，但是案例 4 清楚地表明，当有 8 个 CSDL 任务线程时，archpro 成为了一个瓶颈。
从案例 5 可以看出，通过增加一个 archpro 实例，可以避免这个瓶颈。因此，每当有 4 个以上并行的"管道"通往 CM 储存库时，建议增加 archpro 实例（同时也增加任务）。
实际上，增加并行 CSLD 任务线程数量的方法有两种。在案例 1 到 4 中，我们只配置了一个 CSLD 任务，该任务有多个（内部）CSLD 任务线程。另一种方法也可以取得相同的性能特征，那就是配置附加的（单线程）CSLD 任务，每个任务为一个特定的目录或 Notes 数据库服务。四个单线程的 CSLD 任务可以提供与一个具有四个内部线程的 CSLD 任务相同的归档吞吐量。然而，由于操作上的原因，第二个配置选项通常更为可取，因为这个选项允许仅通过一个命令（或一个 Windows 服务）来停止和启动归档过程，而不必关心各个内部线程。但是，第一个选项也有其优点，它可以安排不同的归档时间段，因为可以为每个 CSLD 任务配置时间片。
案例 6 证明，当归档 5 倍大的报文时，其速度只是稍慢一点。由此也可下结论，在调整系统规模时，以 GB 衡量吞吐量可能得到不正确的结果。比较案例 3 和 6 可发现，取决于报文的大小，相同的设置可能导致从 1.8 到 7 GB 的不同吞吐量。对于电子邮件归档，除非发现明显更大的平均邮件大小，否则建议根据 100 KB 的平均邮件大小进行调整，并且以 ~15,000 文档每小时或 1.5G 每小时每 archpro 实例的 CommonStore for Lotus Domino 归档吞吐量进行计算。
增加 archpro 实例的数量可以获得更高的吞吐量，单同时也需要更多的硬件（CPU 和内存）。目前有一些已知的配置，它们在一个多处理器的机器上有多达 4 个 archpro 实例，每小时可归档 ~90,000 封邮件。在那样一个配置中，建议将 CSLD 任务与 archpro 之间的传输目录（每个任务一个单独的目录）也并行化，将其放在具有快速 I/O 的硬盘上（还可以将它们划分到不同的分区上），以避免读/写瓶颈。注意，为了进一步提高 CommonStore 吞吐量，可以再增加一个或两个 CommonStore 服务器。
通常，并行 CM 代理的数量至少要与并行 CSLD 任务线程的数量相匹配，以便立即归档 CSLD 任务线程提取的每个文档，而不必由 archpro 对文档进行排队。如果期望同时处理检索请求，那么最好由 CSLD 检索任务启动附加的 CM 代理，并处于活动状态。如果期望同时处理检索请求，那么最好启动附加的 CM 代理，并由 CSLD 检索任务使之保持活动状态。此外，还建议将 Domino 调度器的数量设为 CM 代理的数量，因为它们是 CSLD 任务线程到 archpro 的主要进入点。这可以通过修改 archpro 配置文件 archint.ini 中关键字为 DOMINODSP 的条目来实现。注意，CommonStore 产品文档提到，由于 Windows 线程方面的限制，Windows平台上最大的并行 Domino 调度器的数量为 30。
其他影响因素
CommonStore for Lotus Domino 还附带了这样一个选项：在归档一封邮件之前和/或之后，CSLD 触发邮箱中的一个 Notes 代理（用 Lotus 脚本编写），后者在 Domino 服务器上执行。这些代理通常被称作归档前代理和归档后代理。取决于 Notes 代理中动作的复杂度，它们的处理过程会在不同程度上增加事务的持续时间。此外，一个 Domino 服务器通常只能并行地执行一定数量的代理，因此对于吞吐量而言，这可能成为一个限制性的因素。
另外一个（可选的）CommonStore 特性就是所谓的 智能抽象（intelligent abstracting），在该特性中，CSLD 任务创建邮件内容的一个摘要，并在归档后将其放入邮件的主体中。这也将增加单个归档事务的持续时间。
如果打开单事务存储特性（可选），那么必须生成一个附加的散列码（根据邮件内容和其他字段）。而且，在 CM 代理存储对象之前，它在储存库中执行一个查询，看储存库中是否已经存储了相同的散列码。这两个任务将降慢归档事务。另一方面，如果发现已经归档了一个相同的报文，那么 CM 代理就不必将整个报文传输到 CM 服务器，而只需更新储存库，以反映报文的另一个实例。
而且据观察，从 CM v8.3 fix pack 1 开始，archpro 中的 CM 代理所需的时间已经有所减少，因而整体性能得以提高。因此，建议将 Content Manager 至少升级到 fix pack 1 级别。
比较 CommonStore for Exchange 归档吞吐量
前面的很多概念同样适用于 CommonStore to Exchange (CSX)。因此本节只关注不同之处。CSX 还支持带内部线程的 CSX 任务，从而允许并行地从 Exchange 提取数据。然而，这里使用 MS Extended MAPI 作为编程接口，这种编程接口只有 MS Windows 上才有。因此，虽然 AIX 上也可以使用 CSLD，CSX 仍然必须在 MS Windows 2000、XP 或 2003 上运行。
CSX 的数据流与 图 1 中描述的一样。但是要注意，在成功归档之后对 Outlook 项目的清除是异步进行的（而在 CSLD 中是同步的）。归档由一个 CSX worker 线程进行，而清除则由一个 CSX committer 线程来处理。这种架构被选来优化归档吞吐量。图 7 显示了 CSX 的管理界面（可以嵌入到 Microsoft Management Console 中），在该界面中很容易配置并行 CSX worker 线程和 committer 线程的数量。
图 7. 在 CommonStore for Exchange 中配置并行线程（worker）
这是与 CSLD 有重大不同的一个地方，在这里，并行线程的数量是间接地由任务数据库、不同的数据库或数据目录的数量决定的，如图 4 所示。与 CSLD 类似，这里也是以 crawler 组件选择要归档的电子邮件。然而，在 CSX 中，这些任务不是在任务数据库或者 Exchange 中的任务公共文件夹中存储和处理的，而是在 CSX 任务中内部地进行管理。这种架构还允许为并行处理多个归档请求而进行内部调度，从而避免系统管理员需要额外负责为此设置专门的配置。当在一个命令窗口中开始 CSX 任务时，并行 CSX worker 线程和 committer 线程将被列出来，如图 8 所示。
图 8. 在 CommonStore for Exchange 中运行并行线程（worker）
每个 CSX 任务只连接到一个 archpro 实例。如果在 archpro 中激活了 4 个 CM 代理，那么应该配置至少 4 个 CSX worker 线程和 4 个 CSX committer 线程，以便有 4 个到储存库的并行 "管道"。记住，配置 10 以上的 CSX 线程不一定能提供更好的归档吞吐量，因为 archpro 将成为瓶颈。
为了进一步提高归档性能，建议配置多个 CSX 任务，每个任务连接到一个单独的 archpro 实例。如果只有一个 Exchange 服务器，那么可以采用两个并行 CSX 任务：任务 1（有多个内部 worker 线程和 committer 线程）可以为所有用户邮箱服务，而任务 2（也是多线程的）可以专用于同一个 Exchange 服务器上的一个或多个日志邮箱。由于日志邮箱包含所有收发邮件的副本，因此与用户邮箱相比，要归档的邮件量非常大。正是由于这个原因，为日志邮件设置一个单独的 CSX 任务（和一个单独的 archpro 实例）很有用。
如果有多个 Exchange 服务器，那么可以用同一个 CSX 任务为多个 Exchange 服务器服务。但是若从性能和操作性方面考虑，最好是为每个 Exchange 服务器使用专用的（多线程）任务。例如，在某些环境中，不同 Exchange 服务器的维护时间窗口是不同的。如果设置不同的 CSX 任务，那么就可以在 CSX 任务定义面板中配置不同的活动时间段。
由于在决定并行 CSX 任务、线程或 archpro 实例的数量方面 CSX 非常灵活，因此建议预先分析每个 Exchange 服务器的邮件用户数量和预期的归档量。对于有 100 名用户的 Exchange 服务器，用一个任务来为日志邮箱和所有用户邮箱服务肯定足够了。这个任务甚至还可以用于为另一个 Exchange 服务器服务。如果是在一个大型环境中，假设其中有一个有 4,000 名用户的 Exchange 服务器，那么为了在要求的时间范围内处理完归档量，可能需要将日志和邮箱任务分离开，并使用两个并行的 archpro 实例。
与使用 CLSD 相比，使用 CSX 情况下的整体归档性能要低一些。这主要是因为它们使用不同的 API 来从通信系统中提取邮件。例如，我们已经看到，提取（和归档）单独一封邮件所需的时间很大程度上取决于邮件接收者的数量。一封发送给 1,000 名雇员的邮件，如果在接收者字段中不使用分发列表（组），而是使用一个个的名称，那么归档起来就要花费超过 120 秒的时间，而一封标准的邮件归档起来只需要一秒。
对于单线程的归档，预计每小时可归档大约 3,000 封邮件。而在多线程环境中（有一个具有 4-8 个 worker 线程和 4-8 个 committer 线程的任务，还有一个有 4-8 个 CM 代理的 archpro），归档吞吐量大约为每小时 12,000 封邮件。假设每天开一个 20 小时的处理窗口，那么每个 Exchange 服务器每天可归档多达 240,000 封邮件。为了进一步提高归档性能，还需要再添加一个 CSX 任务和 archpro 实例。但是，如果使用相同的物理机器，不要期望通过再增加第二个或第三个实例来取得两倍于或三倍于每小时 12,000 封邮件的吞吐量。
结束语
归档吞吐量实际上是很多方面共同起作用的结果。本文解释了影响整体吞吐量的一些主要因素，其中就包括 CommonStore 吞吐量。为了优化 CommonStore 吞吐量，需要配置 CommonStore 任务，使之以并行的线程运行。另外还建议通过设置不同的 archpro 实例来进一步提高吞吐量。幸亏有强大的 IBM Content Manager 作为后端储存库，又有 CommonStore 灵活的配置选项为辅助，才得以解决遵从性问题，并发现项目中常常会遇到的大量电子邮件归档需求。
免责声明
本文是在本人的知识范围内写成的。如果您发现有异议的地方，请与我联系。
参考资料
关于作者  | | | Reinhold Engelbrecht 博士是电子邮件和 SAP 存档领域的技术销售专家和顾问。他于 1993 年加入 IBM，并从 1997 年以来一直从事内容管理领域的工作。目前，他为 IBM 的 Enterprise Content Management 产品组合提供世界范围的销售支持和技术支持，特别关注 CommonStore、CM for Message Monitoring and Retention（MMR）解决方案和 DB2 Records Manager。他拥有奥地利维也纳技术大学的机械工程（Diplom-Ingenieur）学士学位和博士学位以及美国普度大学的硕士学位。 |
对本文的评价
| 
