在 Windows SQL Server 2005 上优化磁盘 I/O 和 RAID

Question

我已经监控我们的 SQL 服务器一段时间了，并且注意到使用任务管理器和 Perfmon 时常会出现 I/O 达到 100% 的情况。

当我执行“exec sp_who2”时，我通常能够将此峰值与 SQL Server 管理中的 SUSPENDED 进程关联起来。

RAID 控制器由 LSI MegaRAID Storage Manager 控制。我们的设置如下：

1. 系统驱动器 (Windows) 采用 RAID 1，带有两个 280GB 驱动器
2. SQL 位于 RAID 10 上（两个不同跨度中的 2 个 280GB 镜像驱动器）

该服务器是一台 64 位机器，拥有超过 50GB 的 RAM。SQL 2005 64 位运行在 Windows 2003 64 位上。不幸的是，该应用程序运行在 jBoss 之上，而 jBoss 目前是 32 位版本（但我们正在敦促软件提供商为我们提供 64 位版本的 jBoss）。

这是一个白天繁忙但晚上却很不活跃的数据库。数据库大小目前约为 13GB，每天有大约 200 名（且还在增长）用户使用。

我有几个正在考虑的想法：

1. 检查索引并重新索引一些表
2. 添加额外的 RAID 1（带有 2 个新的、较小的 HD）并将 SQL 的日志数据文件 (LDF) 移动到新的 RAID 上。

对于 #2，我的问题是：将数据从 RAID 10 移到 RAID 1 真的能提高磁盘性能 (IO) 吗？RAID 10 显然比 RAID 1 具有更好的性能。此外，SQL 必须在写入数据库之前写入事务日志。

但另一方面，我们将减少磁盘的大小以及写入 RAID 10 的数据量，这是所有“实质”所在 - 从而提高该 RAID 的读取请求性能。

有没有办法找出我们当前的限制因素是什么？（驱动器与 RAID 控制器）？如果限制因素是驱动器，那么添加额外的 RAID 1 可能是合理的。但如果限制因素是控制器本身，那么我认为我们的方法不对。

最后，我们只是在浪费时间吗？我们是否应该将精力集中在第 1 点（重新索引表、尽可能减少网络延迟等）？

Answer 1

我认为将数据库文件和日志文件分离到单独的 RAID 阵列上总是有好处的。数据库文件 I/O 始终是随机的，而日志文件 I/O 始终是连续的。在同一个 RAID 阵列上混合这些 I/O 类型始终会导致性能下降（尽管如果阵列上的 I/O 负载很少，则可能不明显）。我认为您的第 2 点是明智的，尽管正如 mrdenny 所说，如果您看到磁盘 I/O 和数据库大小以及 200 个用户一样高，则您可能存在数据库问题（索引等）。

我运行的是单个 SQL Server（2005 Standard），平均有 2000 个连接到 125 个数据库，没有您看到的性能问题。我们有一个用于数据库的 RAID1 阵列，另一个用于日志文件的 RAID1 阵列。

此外，不要忽视分区（卷）对齐，因为它可能是导致性能问题的一个原因。

另外，请看一下这些文章：

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=21949

http://technet.microsoft.com/en-us/library/cc966540.aspx

http://technet.microsoft.com/en-us/library/cc966534.aspx

http://technet.microsoft.com/en-us/library/cc966412.aspx#EEAA

Answer 2

您可能需要修复 SQL Server 的一些索引问题。一个拥有 200 个用户的 13 Gig 数据库不应该对磁盘造成太大的压力，除非用户正在运行一些非常复杂的查询并且系统没有任何 RAM。

我不会费心添加任何硬件（也许除了更多 RAM），这取决于您是 x32 还是 x64 以及您使用的 SQL 和 Windows 的版本。

Answer 3

对于日志文件，它们应该位于不同的主轴上，这意味着不同的磁盘驱动器、RAID 阵列和卷。这样做的原因是日志写入是连续的，并且应该在大型分配单元中尽快执行，而不必与其他数据库访问（写入数据库或查询）竞争。

您的卷应为 64k 分配单元大小，并且正如 joqwerty 所提到的，您很可能还遭受分区未对齐的困扰，因为 Windows 分区在 Windows 2003 中默认未对齐。在某些情况下，性能损失可能很大，高达 30% 到 40%。以下文章介绍了如何重新创建正确对齐的分区：

SQL Server 的磁盘分区对齐最佳实践
http://msdn.microsoft.com/en-us/library/dd758814%28v=sql.100%29.aspx

我不确定你说的“重新索引”是什么意思。如果是重建或重组，那无论如何都应该是日常维护计划的一部分。如果你不知道你的索引有多分散，那么在采取任何行动之前，你需要收集一些基本的信息。我不会太急于创建新的索引，除非你有经验数据来支持这一点。特别是，经常更新的数据库 (OLTP) 应该有尽可能少的索引，因为每个索引都会降低更新性能。我见过有人用索引“地毯轰炸”数据库，结果弊大于利。

最后，您可能需要验证您的 RAID 控制器是否启用了写入缓存。我发现太多人都忽略了这一点。有时，由于需要更换电池，或者因为他们不知道需要电池才能启用缓存，因此写入缓存可能会被禁用。