建立 Exchange 内容索引重建基准 – 第 3 部分
原文发布于 2012 年 7 月 2 日（星期一）
在此系列的第 1 部分，我解释了 E2K7_IndexRebuildAnalyzer.ps1 脚本（该链接可能指向英文页面），并且在第 2 部分讨论了 Anatoly Girko 和我开发的搜索重建框架。在总结此系列之前，我要提供一些图形和一张“观察到的平均值”表，来说明自框架起始之日观察到的重建特征。希望这能让您拥有更好的概念化认识，并且使得您在计算自己的重建速率时估计更加准确。
截止目前在 Microsoft 内观察到的平均值
Anatoly 和我针对如何才能最好地呈现此内容反复斟酌。可以想象，可能的表现形式不计其数。我们决定将图形和表格限定在大多数 Exchange 存储架构师设计的邮件大小范围内： 每个邮件项 150 KB。随后我们对“邮箱计数”执行了二次筛选，并在数据集合中仅考虑具有 100 个或更多活动邮箱的邮箱数据库，以便生成下面的平均值。在完成操作后，我们从集合中移除了 10% 执行得最好的重建操作和 10% 执行得最差的重建操作，以此获得用于生成图形和表格的平均值。
注意 ：在随后的各个图形和表格中，明显缺少使用若干范围增量的“平均邮箱大小”。但并非忽略了此数据，也不是故意省略它。缺少这些范围的统计数据的原因是，我们的历史数据集合中没有有效数据。换句话说，我们从未对最终用户邮箱的平均邮箱大小处于以下范围内的数据库执行过内容索引重建操作，并且/或者从未对其收集过重建后指标：
- 1700-1,799 MB
- 1800-1,899 MB
- 2000-2,099 MB
- 2100-2199 MB
图
我们将呈现四个 Excel 数据透视图 ，这些图将反映我们目前基于上面所述的筛选集合观察到的吞吐量特征。这些数据透视图用于举例说明出现在邮箱存储中以及与其相关的不同属性（例如，邮箱计数、项目计数和 EDB 文件大小）之间的关系，并根据邮箱存储完成 完全爬网 所需的历史吞吐量时间将这些特征与相似特征进行比较。
图 1
图 1 内包含的视图清楚描绘了 每个数据库邮箱计数 、邮箱数据库相对大小（以 GB 为单位）和此数据对完成邮箱存储内容索引重建的总时间的影响之间的关系。
此图清楚表明，随着 Exchange 邮箱数据库上活动邮箱总数的增长，存储子系统上 EDB 文件大小的增长也呈现与其平行增长的趋势。此关系随后会影响完成内容索引 完全爬网 的总时间。实际上等于说：邮箱越活跃，通常邮件项越多；邮件项越多，磁盘上的 EDB 文件大小越大；磁盘上的 EDB 文件大小越大，重建内容索引需要的时间“通常”越长。此假设不成立的唯一情况是文件中存在大量空白的邮箱数据库。在此情况下，完成内容索引重建的总时间将明显快于预期时间。虽然此异常情况在我们支持的环境内出现过，但我们已使用上面讨论的筛选方法从我们的集合中移除随后的统计数据。
图 2
图 2 描绘了 平均邮箱大小 （同一筛选示例集内包含的数据库上的邮箱）及其对邮箱数据库级内容索引重建吞吐量（以 秒/邮箱 为单位）的影响之间的关系。
此图实际重申了 图 1 中提出的观点，尽管后者是在活动邮箱级别。具体而言，随着活动邮箱平均大小的增长，这些邮箱内的平均邮件项数也在增长。通常，邮箱内的邮件项越多， 搜索索引器 针对给定邮箱完成爬网需要的时间越长，进而影响数据库内所有邮箱完成 完全爬网 需要的时间。
图 3
图 3 描绘了 平均邮箱大小 （同一筛选示例集内包含的数据库上的邮箱）及其对内容索引重建吞吐量（以 MB/秒 为单位）的影响之间的关系。
图 3 基于 图 2 中提出的初始假设而建立。具体而言，其中显示，当 邮箱数据库 内 平均邮箱大小 和 平均项目计数 增长时，搜索索引器吞吐量随之下降。 图 3 以 MB/秒为单位显示此关系。
图 4
图 4 描绘了 平均邮箱大小 （同一筛选示例集内包含的数据库上的邮箱）及其对内容索引重建吞吐量（以 项/秒 为单位）的影响之间的关系（基于平均邮件大小 150 KB） ：
与 图 3 一样， 图 4 显示了吞吐量（以 项/秒 为单位）的负面性能影响。
观察到的平均值表格
为呈现此表格，我们使用相同的筛选集（如上所述，且如图所示 ），但我们选择根据平均邮箱大小创建中心平均值。我们随后将各行描绘为以 99 MB 为增量的独立行。每行的吞吐量特征表示在我们的集合中完成重建操作的所有相似大小的数据库的合计平均值。具体而言，如果“平均邮件大小”是 150 KB，则这些数据库上所有活动邮箱的“平均邮箱大小”都在列 A 定义的范围内。
此表呈现的历史数据平均值（至少对我而言）提供了三种估计内容索引重建时间的可能方式:
- 如果这些邮箱内的项目的“平均邮件大小”是 150KB，则可以根据“平均邮箱大小”实现“历史数据平均值”。由于我们的集合中有大量历史重建数据，因此我们选择使用平均值。我们通过“重建前”指标确定“平均邮箱大小”值来生成估计值，并比较该值和历史数据平均值。然后获取“重建：秒/邮箱”的综合平均值，并将该值乘以需要爬网的数据库上的邮箱数，以此确定完成爬网需要的总时间。
- 不管组织内邮箱项目数和平均大小是多少，也可以根据“平均邮件大小”构建“组织数据平均值”（上面“平均值”行中已提供组织数据平均值）。
- 历史数据平均值和组织数据平均值之间的综合平均值。
例如，如果其用户具有 500-599 MB 范围的合计“平均邮箱大小”的数据库需要重建内容索引，且假定“平均邮件大小”为 150 KB，在该数据库具有 200 个用户的情况下，我可以使用以下三种可能的方法之一生成估计值：
历史数据平均值表 ：
200 个邮箱 * 63 秒 = 12,600 秒（总时间）。相当于 210 分钟或大约 3.5 小时才能完成 完全爬网 。
“ 组织数据平均值 ”：
200 个邮箱 * 108 秒 = 21,600 秒（总时间）。相当于 360 分钟或大约 6.0 小时才能完成 完全爬网 。
综合平均值（“历史数据平均值”与“组织数据平均值”之和的平均值） ：
3.5 + 6.0 = 9.5 小时
9.5 / 2 = 4.75 小时
结束语
重建内容索引需要的总时间始终是可变的，因为此处的邮件填充量和项目数也始终是可变的。在重建内容索引时，始终使用历史数据平均值获取最准确最全面的估计。我还要提到的是，在我/我们决定在 MSFT 内部重建内容索引时，我们尽力在“对用户影响最少”的时间间隔内安排内容索引重建。但是，由于我们的实施工作是全局性工作，因此或多或少无法完全消除对最终用户的影响。您最多只能期望最大程度地降低对外围应用的影响。此外，在我们收集的数据中，我们没有包括“搜索索引器限制延迟”。如果操作呈现任何“搜索索引器重建限制延迟”，则此时需处理并了解它们，它们在各个支持请求中具有代表性。通过使用本文使用的筛选方法，您可以将您的数字与负平均值隔离开（对“极高吞吐量”的重建操作同样有效），从而使总体估计更准确。
如果您倾向于以平均值为基础，我完全支持使用我们的表格。如果需要更准确的科学知识，我建议实施框架，例如本系列文章介绍的框架。
我们希望您能够发现本系列文章中对您有用的内容，如果能够顺便学习新知识就更好了！
祝阅读愉快！
Eric Norberg
服务工程师
Office 365 专业服务
这是一篇本地化的博客文章。请访问 Establishing Exchange Content Index Rebuild Baselines – Part 3 以查看原文