导致 Exchange 磁盘 I/O 的原因
上一次修改主题： 2006-05-16
每次从 Exchange 读取数据或将数据写入 Exchange 时，都将生成磁盘 I/O。了解 Exchange 磁盘 I/O 的来源，可以帮助您在规划和配置磁盘子系统时采用性能最佳的方式。考虑 Exchange 磁盘 I/O 来源时，请主要集中于访问日志文件和数据库文件期间所生成的 I/O 行为。
Exchange 数据组件
所有 Exchange 数据都存储在 Exchange 存储中，Exchange 存储由三个主要组件构成。下表列出了 Exchange 存储的三个主要组件以及它们对磁盘 I/O 的影响。
Exchange 存储组件及其对磁盘 I/O 的相应影响
| 组件 | 影响磁盘 I/O 的原因 |
|---|---|
Jet 数据库（.edb 文件） |
Jet 数据库用来存储从 MAPI 客户端提交的所有数据。由 MAPI 客户端生成的所有客户端活动都会导致 Jet 数据库的更新。 存储包含 MAPI 信息的传入 SMTP 邮件。 |
流式数据库（.stm 文件） |
存储从 IMAP4、NNTP、Microsoft Outlook® Web Access 或 SMTP 提交的附件和数据。指针将保存在 Jet 数据库中，以便可以根据请求将数据传递到 MAPI 客户端。 存储不包含 MAPI 信息的传入 SMTP 邮件。 所有 Internet 协议的客户端活动都会导致流式数据库的更新。 |
事务日志文件（.log 文件） |
对数据库进行的所有更改都将首先提交到事务日志文件。这意味着，任何时候只要用户发送或读取邮件，以及修改其邮箱中存储的数据，该更改就将写入事务日志文件。该更改将立即提交到位于 RAM 中的数据库缓存，然后在系统负载允许时将其复制回磁盘。装入数据库时也会读取事务。 |
因为写入每个 Exchange 存储组件的方式不同，所以，如果将一个存储组的 .edb 文件和相应的 .stm 文件放在一个卷上，并将事务日志文件放在独立的卷上，您将体验到更好的性能。下表列出了每个 Exchange 存储组件的磁盘读取/写入操作是如何执行的。
每个 Exchange 存储组件的磁盘读取/写入
| 组件 | I/O 模式 | ||
|---|---|---|---|
Jet 数据库（.edb 文件） |
|
||
流式数据库（.stm 文件） |
|
||
事务日志文件（.log 文件） |
|
.gif "note") 注意： |
|---|
| 如果公用文件夹驻留在服务器上，则会导致额外的 I/O 负载。但是，如果该服务器上不存在文件夹内容的副本，那么，相对于用户邮箱访问所生成的 I/O 来说，从公用文件夹数据库生成的 I/O 是非顺序的。 |
影响 I/O 的其他活动
除了数据库文件访问之外，还有一些其他活动会导致磁盘 I/O。下表列出了这些活动以及它们对磁盘 I/O 的影响。
影响磁盘 I/O 的其他活动
| 活动 | 影响磁盘 I/O 的原因 |
|---|---|
将已删除的数据库页清零 |
如果把服务器配置为将已删除的数据库页清零，则每次从数据库删除项目时，将会删除多个页。然后，Exchange 将用零覆盖已删除的页。此功能只在联机流式备份期间运行，并在备份期间会导致更多物理磁盘 I/O。 |
内容索引 |
扫描数据库是否有索引更新时，将发生额外的分页操作。这还会导致对内容索引文件执行过多的写入，因而在容纳内容索引文件的磁盘上生成的磁盘 I/O 达到高峰。 |
SMTP 邮件传输 |
在系统间传递时，入站和出站 SMTP 通信将写入磁盘。如果与用户数据库或日志文件共享该磁盘，则写入磁盘或从磁盘读取的 SMTP 邮件将与数据库和/或日志文件争用 I/O。 当 SMTP 邮件通过后台处理从队列移动到第一个 Exchange 数据库时，它们将从 MIME 转换为 IMail。这将导致在该数据库所使用的日志文件和数据库卷上生成附加的 I/O。 |
分页 |
当 Exchange 需要的内存超过可用物理内存时，Windows 将把信息分页到位于硬盘上的页面文件。过多的分页操作将导致过多的磁盘 I/O，这会降低 Exchange 服务器的性能。有关解决分页和内核内存损耗问题的信息，请参阅 Ruling out Memory-Bound Problems（英文）(https://go.microsoft.com/fwlink/?LinkId=62575)。 |
MTA 邮件处理 |
在 Exchange 2000 和 Exchange 2003 中，在移动邮箱操作期间所接收的邮件，或从 Exchange 5.5 服务器、基于 X.400 的服务器或跨 EDK 连接器接收的邮件，将写入事务日志文件。这将导致存储系统的磁盘 I/O 负载。 |
文件夹中的项目数 |
随着核心 Exchange 2003 文件夹内的项目数增加，联机模式下的 Outlook 用户在执行某些任务时所需的物理磁盘开销也将增加。在缓存模式下使用 Outlook 时，将在客户端上执行索引和搜索。第一次按大小对收件箱排序时，需要创建新索引，而这需要很多磁盘 I/O。以后按大小对收件箱排序的开销将非常小。您可以有静态的索引数，因此那些通常以很多不同方式对其文件夹排序的用户会超过此限制，并导致磁盘 I/O 有所增加。 |
邮箱数 |
在 Exchange 中，可以减少数据库缓存（这是一个固定数量的缓存）所进行的一部分数据库读取操作。在向 Exchange Server 添加更多邮箱时，将有更多邮箱竞争这个缓存。超过基线 1000 后，向 Exchange Server 每添加 1000 名用户，就将使数据库 IOPS 增加 25%。 |
Exchange 版本 |
从 Exchange 5.5 迁移到 Exchange 2000 SP3 时，如果其他所有因素保持不变，可以看到数据库 IOPS 增加 5%。 从 Exchange 5.5 迁移到 Exchange 2003 SP1 时，如果其他所有因素保持不变，可以看到数据库 IOPS 减少 20%。 |
单实例存储 |
在 Exchange 5.5 中，服务器上有一个数据库。发送到该服务器上多个邮箱的邮件只被存储一次，而将指针传递给每个收件人。在 Exchange 2000 和 Exchange 2003 中，最多可以有 20 个数据库，假如收件人应当驻留在每个数据库上，则每个数据库可以有一份邮件副本。每增加一个数据库就会使数据库 IOPS 增加 2%。Exchange 如何正确利用单实例存储，取决于将邮件发送到相同数据库上的收件人所用时间的百分比，以及平均邮件大小。邮件越大，就越能发挥单实例存储的优势。 |
BlackBerry |
在 Exchange 2000 和 Exchange 2003 中，有 BlackBerry 设备的用户会对服务器有额外的需求。在这里，很多客户都会看到数据库磁盘 I/O 增加两到四个级别。有关详细信息，请参阅 RIM whitepager（英文）。 BlackBerry 用户导致的额外开销会影响服务器的数据库 IOPS。RIM 用 BlackBerry Enterprise Server 4 测试 1000 名启用 BlackBerry 的 MMB2 用户，他们发现与没有 BlackBerry 的标准 MMB2 用户相比，数据库 IOPS 增加了 3.64 个系数。此系数可以非常小或非常大，具体取决于如何在环境中使用 BlackBerry 设备。BlackBerry 测试包括：10 个同步命令；两个 memo 添加，一个修改，一个删除；以及四个任务添加。实际的 BlackBerry 设备使用将与此不同，这将导致对实际 IOPS 带来更少或更大的影响。 对于由 2,000 个沉重使用的邮箱组成的邮件系统，如果其中有 500 个启用了 BlackBerry，则总计会对数据库卷带来 3820 IOPS。计算公式是： 用户类型对应的每个用户预计 BlackBerry IOPS × 用户数 在此示例中，1.0 IOPS × 2,000 邮箱=2,000 IOPS。如果这些用户中的 500 个用户有 BlackBerry 设备，则这 500 个用户将添加 500 邮箱 x 3.64 IOPS=1820 IOPS，即 3820 的总计 IOPS。 使用每次写入对应两次读取（66% 读取对应 33% 写入）的保守比率，可以计划数据库卷每秒发生 2,546 次读取 I/O 和 1,273 次写入 I/O 请求。每个写入请求首先被写入事务日志文件中，再写入数据库。在事务日志卷上可以看到在数据库卷上所看到的总计 3,820 IOPS 中的大约 10%（3,820 的 10% 是 382 IOPS）；1,273 次写入 I/O 请求将写入数据库。要深入了解正确计算服务器大小的策略，请参阅 Performance and Scalability（英文）指南。 |
优化 Exchange 磁盘 I/O 的最佳实践
熟悉生成磁盘 I/O 的 Exchange 活动之后，就应该以能够发挥最佳性能的方式组织存储系统。下表列出了放置每个数据文件的最佳实践。
优化磁盘 I/O 的最佳实践
| Exchange I/O 来源 | 发挥最佳性能的最佳实践 |
|---|---|
数据库文件 |
应该将存储组内的所有数据库文件（.edb 和 .stm）放在专供这些数据库使用的单个卷上。容纳数据库文件的磁盘应该具有快速的随机访问速度。 |
内容索引文件 |
绝对不要将内容索引文件放在页面文件所在的同一个磁盘上（尽管这是默认位置）。因为内容索引文件是随机访问文件，所以可以将其放在数据库所在的同一个卷上（只要磁盘子系统可以处理这些负载）。 |
单实例存储 |
若要最大程度利用单实例存储的优势，则应当在同一个数据库上驻留属于相同工作组和通讯组列表的邮箱。 |
事务日志文件 |
由于所有事务会首先写入事务日志，因此事务日志应该在可能的写入延迟最低的存储设备上。通常，可以通过对单一存储组的日志指定 RAID-1/RAID-1+0 集来获得最低写入延迟。这样可以避免数据流与其它 I/O 混淆，并保证完全按顺序写入 I/O，从而确保达到最高的磁盘吞吐量的同时保持最低的延迟。对于可有效镜像并由电池供电的回写缓存的存储阵列，以上方案可能不会对性能有明显的提高，这是因为所有写入 I/O 首先被写入缓存，接合起来，然后再写入磁盘（在写入存储缓存后，写入就会成功地返回到 OS，因此写入延迟较低）。可以使用 Jetstress 度量该类型的 I/O 隔离能否为给定的存储平台/配置提供更好的性能。 为获得最佳的可恢复性，建议将给定存储组的事务日志和数据库放置到不同的逻辑单元号 (LUN)，并配置为 RAID-1/RAID-1+0。此外，还建议驻留同一存储组的日志和数据库文件的各个 LUN 不要共享阵列内的物理磁盘。这样可以提高可恢复性的级别，以便在多个磁盘发生故障的情况下进行恢复，同时最大程度地减少数据丢失（或丢失备份日志的磁盘，或丢失备份数据库的磁盘，但不会同时丢失两者）。如果丢失日志 LUN，您仍有最新数据库最近的备份；如果丢失数据库 LUN，您可以从备份还原，然后前滚日志，直到拥有最新的数据库。如果将同一存储组的日志和数据库放置在相同的 LUN 或共享相同物理磁盘的不同 LUN 上，则在多个磁盘发生故障的情况下，可能会同时丢失日志和数据库。这将导致您丢失自上次成功备份以来所作的所有更改。在通过同步复制将 Exchange 数据库和日志复制到备用存储阵列的情况下，可以不考虑将给定存储组的日志和数据库分别放在不同的物理磁盘（在多个磁盘发生故障的情况下，可以从备用存储阵列中恢复数据库和日志）。 如果硬件 RAID 控制器具有镜像的、电池供电的回写缓存，并且它可调整读/写缓存比率，请将该比率设置为 75% 写入，25% 读取。 |
SMTP 队列 |
应对 SMTP 队列卷使用具有多个磁盘心轴的 RAID-1+0 阵列。磁盘心轴的数量和写入缓存的大小应该根据服务器的预计 SMTP 邮件吞吐量得出。 SMTP 队列绝对不要位于执行另一项功能（例如，事务日志、数据库文件、页面文件或系统文件）的任何心轴上。 无论邮件是发往同一台服务器上的邮箱还是远程服务器上的邮箱，几乎都不会影响与 SMTP 队列相关的磁盘 I/O。 |
页面文件 |
要获得最佳性能，应该将页面文件放在独立的心轴上，并且它至少应位于 RAID-1 设备上。如果丢失存放页面文件的磁盘，则服务器将遇到停止错误。 |
MTA 队列 |
邮件传输代理 (MTA) 队列绝对不要驻留在日志或数据库卷上。如果服务器需要处理大量的 SMTP 和/或 MTA 通信，则应为 SMTP 和 MTA 队列提供一组独立的心轴。 |
例如，如果运行 Exchange 2003 的计算机包含一个具有五个数据库的存储组，则应配置以下独立的物理 RAID 阵列：
- C:\ - 系统卷、操作系统、Exchange 系统文件 - RAID-1（直接附加存储，而不是 SAN）
- D:\ - 页面文件 - RAID-1（直接附加存储，而不是 SAN）
- E:\ - SMTP 和 MTA 队列 - RAID-1+0 (SAN)
- F:\ - 存储组 1 的日志文件 - RAID-1 (SAN)
- G:\ - 存储组 1 的数据库 - RAID-1+0 (SAN)