了解数据库和日志性能因素
适用于： Exchange Server 2010 SP2, Exchange Server 2010 SP3
上一次修改主题： 2016-11-28
本主题讨论 Microsoft Exchange Server 2010 中的数据库和日志 I/O 性能因素。了解这些因素对于邮箱服务器存储设计解决方案十分重要。有关设计过程的其他重要方面的详细信息，请参阅邮箱服务器存储设计。
目录
事务性 I/O
了解 IOPS
非事务性 I/O
事务性 I/O
事务性 I/O 通常定义为用户活动生成的 I/O。用户活动的示例包括接收、发送和删除项目；同步 Windows 移动客户端；通过 Microsoft Office Outlook Web App 登录。
事务性 I/O 是 Exchange 2010 存储设计的重要部分，因为 I/O 延迟（执行 I/O 操作花费的时间）可能会直接影响联机客户端（如 Microsoft Outlook 联机模式和 Outlook Web App）的用户体验。当 Outlook 中的缓存 Exchange 模式用于诸如委派访问和配置规则这类任务时，也可能会受到高 I/O 延迟的影响。所有客户端都可能会受到由高延迟 I/O 导致的电子邮件传递延迟的影响。事务性 I/O 可以分为数据库卷 I/O 和日志卷 I/O。
Exchange 2010 中的事务性 I/O 要求与 Exchange Server 2007 中的要求相比已有所减少。并非针对邮箱数据库和日志卷进行的所有 I/O 都会被视为事务性的。有关详细信息，请参阅了解 Exchange 2010 存储。
返回顶部
了解 IOPS
对于所有版本的 Exchange，了解每个用户每秒占用的数据库 I/O 量 (IOPS) 十分重要，因为这是充分确定存储大小所需的重要事务性 I/O 指标之一。以下各节讨论在设计邮箱服务器角色存储时影响 IOPS 的因素。
数据库缓存
运行 64 位版本 Exchange 2010 的 64 位版本 Windows Server 操作系统将显著增加虚拟地址空间，并允许 Exchange 增加其数据库缓存、减少数据库读取 I/O，以及每个服务器最多支持 100 个数据库。
数据库读取减少取决于服务器的可用数据库缓存量和用户邮件配置文件。有关内存和数据库的指导，请参阅了解邮箱数据库缓存。与 Exchange Server 2003 相比，按照该主题中的指导最多可减少 90％ 的事务性 I/O。每个用户的数据库缓存量是实际 I/O 减少的主要因素。
下表说明对于使用 100 封邮件/天配置文件的用户群，Exchange 2003 中每个邮箱的默认 900 MB 数据库缓存与 Exchange 2010 中每个邮箱的 6 MB 数据库缓存相比，每个邮箱的实际数据库缓存增加情况。正是 Exchange 2010 中的此额外数据库缓存提高了在缓存中的读取命中率，从而减少了磁盘级别的数据库读取数。
基于邮箱数的数据库缓存大小
| 邮箱数 | 每个邮箱的 Exchange 2003 数据库缓存 (MB) | 每个邮箱的 Exchange 2010 数据库缓存 (MB) | 与 Exchange 2003 相比数据库缓存增长的倍数 |
|---|---|---|---|
4000 |
0.225 |
6 |
27 倍 |
2000 |
0.45 |
6 |
13 倍 |
1000 |
0.9 |
6 |
7 倍 |
500 |
1.8 |
6 |
5 倍 |
返回顶部
确定 Exchange 2010 邮箱 IOPS 配置文件
可用于预测 Exchange 2010 数据库 IOPS 的两个最主要因素是每个用户的数据库缓存量和每个用户每天发送和接收的邮件数。下表基于以缓存 Exchange 模式使用 Outlook 2010 的标准工作人员。这些信息已经过测试，其准确性在正负 20% 范围内。其他客户端类型和使用方案可能产生不准确的结果。该预测仅对介于 3 MB 和 30 MB 之间的用户数据库缓存大小有效。这些信息尚未在用户每天发送和接收的邮件超过 500 封的场景中经过验证。虽然用于验证的平均邮件大小为 75 KB，但邮件大小并非 IOPS 的主要因素。
该表提供每个用户的 IOPS 估计值（可以用于预测基线 Exchange 2010 IOPS 要求），并包括所有数据库 I/O（数据库、内容索引和 NTFS 元数据）。它不包括日志卷 I/O。
基于邮件活动的每个邮箱的数据库缓存和估计 IOPS
| 每天每个邮箱发送/接收的邮件数 | 每个邮箱的数据库缓存 (MB) | 单个数据库副本（独立）：每个邮箱的估计 IOPS | 多个数据库副本（邮箱恢复）：每个邮箱的估计 IOPS |
|---|---|---|---|
50 |
3 |
0.06 |
0.05 |
100 |
6 |
0.120 |
0.100 |
150 |
9 |
0.18 |
0.150 |
200 |
12 |
0.240 |
0.200 |
250 |
15 |
0.300 |
0.250 |
300 |
18 |
0.360 |
0.300 |
350 |
21 |
0.420 |
0.350 |
400 |
24 |
0.480 |
0.400 |
450 |
27 |
0.540 |
0.450 |
500 |
30 |
0.600 |
0.500 |
邮箱恢复指 Exchange 2010 中统一的高可用性和站点恢复解决方案。有关详细信息，请参阅了解高可用性和站点恢复。
返回顶部
数据库卷 I/O
数据库卷 I/O 是与数据库文件 (.edb) 读取/写入活动、内容索引读取/写入活动以及 NTFS 元数据读取/写入活动关联的 I/O。
在 Exchange 2003 中，数据库读取/写入比率通常为 2:1 或 66％ 的读取。借助 Exchange 2010，较大的数据库缓存将减少磁盘上数据库的读取数，从而导致读取以在总体 I/O 中所占的百分比缩小。
如果遵守建议的内存指南，则主动数据库副本应具有以下 I/O 比率。有关内存指南的详细信息，请参阅了解内存配置和 Exchange 性能。此测量包括所有数据库卷 I/O（数据库、内容索引和 NTFS 元数据）；不包括日志卷 I/O。
邮箱数据库 I/O 读取/写入比率
| 每天每个邮箱发送/接收的邮件数 | 独立数据库 | 参与邮箱恢复的数据库 |
|---|---|---|
50 |
1:1 |
3:2 |
100 |
1:1 |
3:2 |
150 |
1:1 |
3:2 |
200 |
1:1 |
3:2 |
250 |
1:1 |
3:2 |
300 |
2:3 |
1:1 |
350 |
2:3 |
1:1 |
400 |
2:3 |
1:1 |
450 |
2:3 |
1:1 |
500 |
2:3 |
1:1 |
例如，如果您在维护三个数据库副本的数据库可用性组 (DAG) 中的邮件服务器间部署 24,000 个邮箱，则每个数据库的数据库读取/写入比率都为 3:2。换句话说，针对承载数据库的逻辑单元号 (LUN) 的所有 I/O 中有 60％ 为读取 I/O。
在选择与写入具有重要成本关联的独立磁盘冗余阵列 (RAID) 类型（如 RAID5 或 RAID6）时，使写入在总体 I/O 中占据更大的百分比具有特殊意义。有关为服务器选择适当的 RAID 解决方案的详细信息，请参阅了解存储配置。
计算每个邮箱服务器的 IOPS
由于存在以下原因，因此在 Exchange 2010 中计算每个邮箱服务器的 IOPS 需要的步骤要多于在以前版本的 Exchange 中需要的步骤：
现在可以在相同卷上组合数据库和日志，
可以在同一台服务器上承载主动和被动的数据库副本，
增加了顺序 I/O 后台任务（例如，后台数据库维护）。
在每个邮箱服务器的 IOPS 计算中不考虑纯顺序 I/O 操作，因为存储子系统处理顺序 I/O 比处理随机 I/O 要高效得多。这些操作包括后台数据库维护、日志事务性 I/O 和日志复制 I/O。
根据存储的设计方式，每个邮箱服务器的 IOPS 的计算方式稍有不同：
数据库文件和日志文件共享单个卷。
数据库文件存储在与事务日志文件不同的磁盘卷上。
对于这两种存储设计，都可使用性能监视器 (perfmon.exe) 测量两小时时间段的峰值（采用 5 秒采样间隔）。这是一天中系统处于客户端活动所生成的最大负载下的时间（例如，上午 10 点至中午 12 点）。此时间段通常是每天 10 小时平均负载的两倍（峰值:平均值比率 = 2:1）。
每个邮箱服务器的 IOPS：数据库文件和日志文件共享单个卷
在此配置中，数据库文件和日志文件存储在相同的磁盘卷上。此示例假设每个数据库位于由专用磁盘提供的不同卷上。请通过收集的性能监视器日志（在上节中进行了介绍）为所有数据库填写下表。
| 数据库名称 | 逻辑磁盘 -> 磁盘读取次数/秒 | 逻辑磁盘 -> 磁盘写入次数/秒 | MSExchange DatabaseInstances ->数据库维护 IO 读取次数/秒 | MSExchange DatabaseInstances ->I/O 数据库读取（恢复）次数/秒 | MSExchange DatabaseInstances ->I/O 数据库写入（恢复）次数/秒 | MSExchange DatabaseInstances ->IO 日志写入次数/秒 |
|---|---|---|---|---|---|---|
数据库 1 |
||||||
数据库 2 |
||||||
数据库 3 |
||||||
数据库 4 |
||||||
任何其他数据库 |
||||||
总计 |
将每列的总计相加，然后执行以下计算以确定每个邮箱服务器的 IOPS。
计算汇总：(逻辑磁盘 IO 的总和 - (数据库维护 IO 的总和 + 恢复（日志重播）IO + 日志 IO))/性能监视器日志测量过程中每个服务器承载的邮箱数。
计算详细信息：((逻辑磁盘 -> 磁盘读取次数/秒 + 逻辑磁盘 ->磁盘写入次数/秒) - (MSExchange 数据库 ==> 实例 -> 数据库维护 IO 读取次数/秒 + MSExchange 数据库 ==> 实例 -> I/O 数据库读取（恢复）次数/秒 + MSExchange 数据库 ==> 实例 -> I/O 数据库写入（恢复）次数/秒 + MSExchange 数据库 ==> 实例 -> IO 日志写入次数/秒))/性能监视器日志测量过程中每个服务器承载的邮箱数 = 每个邮箱服务器的 IOPS。
返回顶部
IOPS/邮箱：专用数据库文件卷
在此配置中，数据库文件存储在与事务日志文件不同的磁盘卷上。此示例假设每个数据库位于由专用磁盘提供的不同卷上。请按照收集的性能日志（在上节中进行了介绍）为所有数据库填写下表。
| 数据库名称 | 逻辑磁盘 -> 磁盘读取次数/秒 | 逻辑磁盘 -> 磁盘写入次数/秒 | MSExchange 数据库 ==> 实例 ->数据库维护 IO 读取次数/秒 | MSExchange 数据库 ==> 实例 ->I/O 数据库读取（恢复）次数/秒 | MSExchange 数据库 ==> 实例 ->I/O 数据库写入（恢复）次数/秒 |
|---|---|---|---|---|---|
数据库 1 |
|||||
数据库 2 |
|||||
数据库 3 |
|||||
数据库 4 |
|||||
任何其他数据库 |
|||||
总计 |
.gif "注释") 注意： |
|---|
| 默认情况下，MSExchange 数据库 ==> 实例 ->数据库维护 IO 读数/秒性能计数器在 Exchange 2010 中不可见。您必须启用此计数器才能查看它。有关如何启用该性能计数器的详细信息，请参阅如何启用扩展的 ESE 性能计数器 |
要确定每个邮箱服务器的 IOPS，将每列的总计相加，然后执行以下计算。
**计算汇总：**逻辑磁盘 IO 之和减去数据库维护 IO 与恢复（日志重播）IO 之和，再除以性能日志测量过程中每个服务器承载的邮箱数。
计算详细信息：((逻辑磁盘 -> 磁盘读取次数/秒 + 逻辑磁盘 ->磁盘写入次数/秒) - (MSExchange 数据库 ==> 实例 -> 数据库维护 IO 读取次数/秒 + MSExchange 数据库 ==> 实例 -> I/O 数据库读取（恢复）次数/秒 + MSExchange 数据库 ==> 实例 -> I/O 数据库写入（恢复）次数/秒))/性能监视器日志测量过程中每个服务器承载的邮箱数 = 每个邮箱服务器的 IOPS。
衡量基线 IOPS
如果使用的是早期版本的 Exchange，且已计算出基线 IOPS，请记住 Exchange 2010 将从以下方面影响基线：
服务器上的用户数会影响每个用户的总数据库缓存。
RAM 的量会影响您的数据库缓存的增长规模，更大型的数据库高速缓存会导致更多缓存读取命中。这将减少您数据库的读取 I/O。
该流程的关键是特定服务器上的 IOPS 对于计划整个企业信息并不够用。这是因为每个服务器上的 RAM 数量、用户数量和数据库数目将会不同。获得实际的 IOPS 数之后，应始终对计算值增加 20％ 的 I/O 开销因素以获得一些保留容量。否则，活动重于正常情况就会降低用户体验。
桌面搜索引擎和 Outlook 联机模式客户端
与缓存的 Exchange 模式客户端不同，所有联机模式客户端操作都针对数据库。由于存储架构和可扩展存储引擎 (ESE) 中发生了更改，Outlook 联机模式客户端现在生成的 I/O 配置文件与 Outlook 缓存 Exchange 模式客户端生成的配置文件相同。
就邮箱搜索功能而言，最终用户有两种选项：
他们可以使用在邮箱服务器上提供的内置内容索引。
他们可以安装桌面搜索引擎客户端，并在该客户端上生成邮箱数据的本地索引，然后执行本地搜索。
将桌面搜索引擎客户端与 Outlook 联机模式一起使用的最终用户可能会给数据库带来额外的读取 I/O 操作。当前，已知不会带来额外读取 I/O 的唯一桌面搜索引擎为 Windows Desktop Search 4.0。Windows Desktop Search 4.0 使用同步协议，方式类似于 Outlook 缓存 Exchange 模式同步协议对邮箱内容建立索引的方式。
因此，如果您旨在将 Outlook 联机模式客户端与 Windows Desktop Search 4.0 之外的桌面搜索引擎一起部署，请遵循以下指南：
与缓存的 Exchange 模式客户端相比，256 MB 联机模式客户端将使数据库读取操作增加 1.5 倍。低于 256 MB，影响可以忽略不计。
随着邮箱大小加倍，数据库读取 IOPS 也将加倍（假设主要文件夹之间相同项目的分发仍然相同）。
由于存在此数据，我们有两个建议：
需要时部署缓存 Exchange 模式客户端。有关详细信息，请参阅本主题后面的“每个文件夹的邮件计数”部分。否则，将桌面搜索引擎替换为 Windows Desktop Search 4.0。
设计数据库存储时，请考虑 I/O 要求。
有关其他 IOPS 因素，如第三方客户端，请参阅优化 Exchange Server 2003 的存储。
返回顶部
日志卷 I/O
日志卷 I/O 是与数据库日志记录读取/写入活动和 NTFS 元数据读取/写入活动相关联的 I/O。日志卷 I/O 在本质上是顺序的，在使用电池供电的写入缓存阵列控制器时，日志卷 I/O 的 I/O 开销最小，不是确定 Exchange 存储大小的重要因素。
由于 Exchange 2010 中减少了数据库读取，以及减小了日志文件大小和能够拥有更多数据库，因此日志到数据库的写入为独立数据库的 40%，参与邮箱恢复的数据库的 50%。例如，如果参与邮箱恢复的数据库使用 12 个写入 I/O，则日志 LUN 大约使用 6 个写入 I/O。
在承载参与邮箱恢复的数据库的邮箱服务器上，存在与使用连续复制关联的开销。必须读取关闭的事务日志并将这些日志发送到目标数据库副本。对于邮箱服务器上承载的每个主动数据库副本，此开销额外占用日志读取的 10％。例如，如果邮箱服务器承载 10 个主动数据库副本，并且每个事务日志流生成 6 个写入 I/O，则可以预计，对于这 10 个主动数据库副本中的每个副本，会额外占用 0.6 个读取 I/O（或总共 6 个读取 I/O）。
测量或预测事务日志 I/O 后，请考虑增加 20％ 的 I/O 开销因素以确保在比正常状态繁忙时有充足的富余空间。
每个文件夹的邮件计数
减少服务器 I/O 的一种方式是在缓存 Exchange 模式下使用 Outlook。初始邮箱同步是非常占用磁盘空间的操作，但随着时间的推移，邮箱大小不断增长，磁盘子系统的负担会从 Exchange 服务器转换到 Outlook 客户端。通过使用缓存 Exchange 模式，即使用户的收件箱中有大量邮件或用户对邮箱进行搜索，对服务器产生的影响也是微乎其微的。此方法也意味着使用大型邮箱的缓存 Exchange 模式用户可能需要比使用小型邮箱的用户更快的计算机（取决于单个用户可接受性能的阈值）。
当您部署以缓存 Exchange 模式运行 Outlook 2007 的客户端计算机时，请考虑以下与邮箱/.ost 文件大小相关的指南：
不超过 5 GB 此大小应在大多数硬件上提供良好的用户体验。
5 GB 至 10 GB 之间 此大小通常取决于硬件。因此如果您的硬盘驱动器足够快并且 RAM 足够大，您将获得更好的体验。但是，较慢的硬盘驱动器，如便携式计算机上通常所带的硬盘或早期的固态驱动器 (SSD)，可能会在驱动器响应时发生应用程序暂停的情况。
大于 10 GB 使用此大小，大多数硬盘会出现短时暂停的情况。
非常大，如 25 GB 或更大 此大小会增加短时暂停的频率，尤其是在您下载新的电子邮件时。您还可以使用“发送/接收”组来手动同步邮件。
此指南基于 Outlook 2007 Service Pack 1 或更高版本的积累更新程序的安装，如 Microsoft 知识库文章 961752，Outlook 2007 修补程序包说明 (Outlook.msp)：2009 年 2 月 24 日（英文网页）中所述。
如果 Outlook 2007 在缓存 Exchange 模式部署中出现性能问题，请参阅知识库文章 940226，如何解决 Outlook 2007 中的性能问题（英文）。有关可用的改进的详细信息，请参阅知识库文章 968009，Outlook 2007 在 2009 年 2 月累积更新中的改进（英文网页）。
如果用户已超出 Exchange 将存储的索引数，则将出现较困难的情况。这是 Exchange 2010 中的 11 个索引。如果用户选择以新方式排序，并因此创建第十二个索引，这将导致额外的磁盘 I/O 活动。因为未存储该索引，因此每次执行此排序时都会发生这种额外的磁盘活动开销。由于此解决方案中可生成高 I/O 活动，所以强烈建议在核心文件夹（如“收件箱”和“已发送邮件”文件夹）中存储的项目不要超过 100,000 个，在“日历”和“联系人”文件夹中的项目不要超过 10,000 个。在“收件箱”和“已发送邮件”文件夹下创建更多顶级文件或或创建子文件，可以极大地降低与此索引创建操作关联的开销。只要任何文件夹下的项目数量不超过 100,000 个，就会存在这种情况。
返回顶部
内容索引 I/O
在 Exchange 2010 中，会在接收到邮件时对邮件建立索引，因而产生的数据库磁盘 I/O 开销非常低（因为在检索邮件以建立索引时，邮件仍处于数据库缓存中）。但是，写入 I/O 与更新搜索目录存储区相关联。由于 Exchange 2010 中减少了总体数据库 I/O，因此搜索目录 I/O 的百分比现在为数据库文件 I/O 的 10% 至 15%（具体取决于配置文件）。当客户端发出搜索查询时会执行搜索目录读取 I/O，这种情况很少发生，因此与 Exchange 2010 存储设计无关。
返回顶部
非事务性 I/O
事务性 I/O 的发生是对直接用户操作的响应，通常具有最高优先级，因此主要用于存储设计。非事务性 I/O 在后台发生并进行调整以产生最小的性能影响，也可在定义的维护时段期间发生。
以下各节讨论在后台发生的某些非事务性 I/O。虽然非事务性 I/O 不是存储设计的重点，但是仍会影响存储设计。有关详细信息，请参阅新增的 Exchange 核心存储功能。
后台数据库维护（计算校验和）
后台数据库维护 I/O 是与对主动和被动数据库副本计算校验和相关联的顺序数据库文件 I/O。后台数据库维护具有以下特征：
在主动数据库上，它可以配置为 7 天 24 小时全天候运行，或在联机维护时段期间运行。后台数据库维护（校验和）针对被动数据库副本 7 天 24 小时全天候运行。有关详细信息，请参阅新增的 Exchange 核心存储功能主题中的“联机数据库扫描”。
对于每个主动扫描的数据库（主动和被动副本），每秒大约读取 5 MB。该 I/O 是 100% 顺序的，因此存储子系统可以高效地处理 I/O。
如果在少于 24 小时的时间内完成校验和验证，则停止扫描数据库。
如果扫描未在三天内完成，则发出警告事件（不可配置）。
邮件记录管理
“邮件记录管理”(MRM) 是 Exchange 2010 中的记录管理技术，可帮助组织降低与电子邮件关联的法律风险。通过 MRM，可以更方便地保留为遵守公司策略、政府法规或法律要求所必需的邮件，并可更方便地删除没有法律或商业价值的内容。
这些操作可通过使用保留策略或托管文件夹完成。托管文件夹助理是一个 Microsoft Exchange 邮箱助理，它应用在保留策略或托管文件夹邮箱策略中配置的邮件保留设置。该助理所需的磁盘 I/O 取决于所处理的邮箱邮件数。建议您不要在进行备份或联机维护的同时运行该助理。有关详细信息，请参阅安排托管文件夹助理。
联机维护
可以使用 Exchange 管理工具设置数据库的维护日程安排，或允许进行 7 天 24 小时的全天候数据库维护。联机碎片整理在 Exchange 2010 中的工作方式不再与以前版本 Exchange 中的工作方式相同。在对数据库进行读取和写入期间，会连续执行联机碎片整理。有关详细信息，请参阅新增的 Exchange 核心存储功能中的“联机数据库扫描”。
返回顶部
© 2010 Microsoft Corporation。保留所有权利。