导致 Exchange 磁盘 I/O 的原因

 

上一次修改主题: 2006-05-16

每次从 Exchange 读取数据或将数据写入 Exchange 时,都将生成磁盘 I/O。了解 Exchange 磁盘 I/O 的来源,可以帮助您在规划和配置磁盘子系统时采用性能最佳的方式。考虑 Exchange 磁盘 I/O 来源时,请主要集中于访问日志文件和数据库文件期间所生成的 I/O 行为。

所有 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 文件)

  • 随机读取和写入
  • 4 KB 页大小

流式数据库(.stm 文件)

  • 按顺序正常读取和写入
  • 在生产环境中平均 8 KB 的可变页大小
note注意:
由于有大量的寻道操作,因此,该 I/O 模式既不是完全随机的,也不是完全有序的。

事务日志文件(.log 文件)

  • 正常操作期间,100% 按顺序写入
  • 恢复操作期间,100% 按顺序读取
  • 写入的大小各不相同 - 从 512 字节到日志缓冲区大小
note注意:
如果公用文件夹驻留在服务器上,则会导致额外的 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(英文)(http://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(英文)指南。

熟悉生成磁盘 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)
 
显示: