我是一名开发人员，对存储系统知之甚少。在工作中，我注意到其中一个 SQL Server 上的大型查询性能很慢。有人告诉我，数据库位于带有 14 个 COMPAQ BF3008B26C 驱动器的光纤通道 SAN MSA1500（HP？）上。当服务器几乎没有负载时，我进行了快速 HD 调优基准测试。平均读取速度约为 60MB/s。我对 SAN 了解不多，但在我看来，读取速度确实很低。本地 HD 读取基准更高。在我向我的 IT 人员报告我认为存在巨大潜在配置错误之前，我只是想听听你们的意见。
答案1
按照 SAN 标准，MSA1500 的速度并不快，但配置错误的 SAN 通常在数据仓库等负载下表现不佳。很可能是 SAN 配置错误（可能是阵列上的条带大小太小）。也可能是 SAN 本身就很慢 - 并非所有 SAN 都是一样的。
对于数据仓库等高容量（而非高寻道）负载，直接连接磁盘阵列的性能可能会好得多。在事务性应用程序等随机访问负载中，控制器的限制往往会被机械磁盘寻道活动所掩盖。性能问题更有可能在流式负载（如对大型事实表的表扫描）上显现出来。
不良的磁盘布局（例如将日志卷与繁忙的随机访问工作负载放在相同的磁盘组上）也可能对 SAN 上的磁盘性能产生不成比例的影响。
要了解是否存在磁盘限制，请查看页面 IO 闩锁等待的统计数据。如果这些统计数据异常高，则 SAN 可能是瓶颈。
答案2
我有一台 MSA1500CS，它的表现一直不佳，大概就是你遇到的情况。我的磁盘是 SATA 驱动器。当我将它们置于奇偶校验 RAID 配置（RAID5 或 6）中时，吞吐量约为 60MB/s。那里的控制器确实动力不足。后来我改用 RAID10，吞吐量增加了不少，主要是因为我没有为奇偶校验计算消耗那么多控制器 CPU 资源。
此外，该设备还有一个非常讨厌的习惯，即在执行某些阵列功能时禁用写入缓存。例如，向磁盘阵列添加驱动器、更改 LUN 上的条带大小或从故障磁盘中恢复。当它执行这些操作时，上面的任何奇偶校验 RAID LUN 都会变得非常敏感。如果写入 I/O 过多，它会开始大幅降低向磁盘提交写入的速度。更快的驱动器可能会有所帮助，但大多数情况下是控制器 CPU 资源问题。
也就是说，您使用的是 SCSI 驱动器，而不是 SATA。这应该会大大提高性能，尽管奇偶校验 RAID 可能不会有太大改善。提高性能的方法是使用 Active/Active 固件，并利用 MPIO 循环在两个控制器之间分散 I/O 负载。上次我检查时，这只能在同构主机操作系统环境中完成（即所有 Windows 或所有 Linux）。
这是这样一种设备：延迟敏感型工作负载（HP 术语中的“在线”工作负载）旨在在镜像集中运行，而归档工作负载（“近线”工作负载）则用于奇偶校验 RAID。只要您的应用程序能够接受可能非常严重的延迟，就可以尝试以在线角色使用奇偶校验 RAID。我的应用程序不能接受，这导致了重大问题。
据报道，MSA2000 系列在这方面做得更好。
答案3
常见的违法者：
Windows 磁盘分区与 SAN 不一致。这是因为 2008 之前的 Windows Server 版本从第 64 个扇区开始分区。
NTFS 分配单元大小应为 64k（最佳实践）。
SAN 条带大小不理想
您可以使用以下命令检查磁盘对齐：
wmic 分区获取块大小、起始偏移量、名称、索引
如果起始偏移量为 32256，则分区未对齐。
更多信息：
SQL Server 的磁盘分区对齐最佳实践