☰

从 SQL Server 角度

tag-icon • tag-icon storage storage-area-network benchmark iometer
从 SQL Server 角度

从某种程度上来说，我猜这是一个字符串问题，但是即使有一个“这适合大多数情况”的答案，我也不知道它是什么，所以......

我有一个正在评估的 SAN，HP P4000。我想使用 IOMeter 进行一些基准测试，看看它的功能。

但是，我不知道块大小、读/写分割和随机/顺序分割的哪种组合适用于不同的用途。

例如，如何模拟一些 Exchange 活动、一些 SQL 活动、一些常规 VM 活动等等。

我知道如何添加工人并通过不同的设置让他们自由活动，但我应该使用什么设置呢？

谢谢。

答案1

Exchange 和 SQL 活动往往是频繁的、较小的 IO/Ops 端。在写入/提取附件时，Exchange 有相当多的较大 I/O 突发。备份间隔和长时间运行的查询也确实会造成影响，并且可能是您的峰值 I/O 实例。Exchange Online Defrag 是我们的 Exchange 的 IO 峰值，而 SQL Backups 是我们的 SQL 服务器的 I/O 峰值。

Exchange Online Defrag 涉及大量 I/O 操作，但吞吐量不大，因此平均传输大小较小，512b 较小，而且数量很多。读/写比率差异很大，但对于维护良好的 Exchange DB 来说，它应该主要是读取。这将是相当随机的，但有足够的顺序访问来保持它的趣味性（不，我没有确切的比率）。

SQL 备份涉及各种大小，但与在线碎片整理不同的是，吞吐量实际上也很高。计划混合使用 512b 到 4kb 的传输大小。读/写比率取决于数据的最终位置！写入速度可能非常快，但（取决于备份脚本）几乎完全是连续的。读取将是 100% 随机的。

一般虚拟机活动取决于虚拟机中的内容。如果您在其中安装了 Exchange 或 SQL，则请对其进行监控。如果您所说的一般是指“一般文件服务”，例如 Web 或 CIFS 共享，那么这取决于他们在做什么；CAD 工程师的访问模式与满是采购办公室职员的办公室非常不同。对于“一般虚拟机活动”，没有通用的 I/O 模式。您必须针对虚拟机中实际拥有的内容进行规划。

答案2

使用 Iometer 进行存储系统性能分析：http://communities.vmware.com/docs/DOC-3961

答案3

从 SQL Server 角度

在 SQL Server 框中，您最好使用以下参数测试磁盘，具体取决于您将存储 MDF、NDF、LDF 和 TEMPDB 文件的位置：

所有磁盘（MDF、NDF、LDF、TEMPDB）

  • 8 KiB 传输请求大小
  • 80% 阅读率
  • 95% 随机读取
  • 启动时间 10（绕过存储缓存）
  • 最大磁盘大小（4'000'000 个扇区 = 2 GiB）

串行写入磁盘（LDF、TEMPDB）

  • 8 KiB 传输请求大小
  • 20% 读取率（日志和 TEMPDB 是写入密集型的）
  • 0% 随机读取
  • 启动时间 10（绕过存储缓存）
  • 最大磁盘大小（4'000'000 个扇区 = 2 GiB）

串行读取磁盘（MDF、NDF）

64 KiB 范围读取

  • 64 KiB 传输请求大小
  • 80% 读取率（主要读取 MDF 和 LDF 文件）
  • 0% 随机读取
  • 启动时间 10（绕过存储缓存）
  • 最大磁盘大小（4'000'000 个扇区 = 2 GiB）

128 KiB 预读

  • 128 KiB 传输请求大小
  • 80% 读取率（主要读取 MDF 和 LDF 文件）
  • 0% 随机读取
  • 启动时间 10（绕过存储缓存）
  • 最大磁盘大小（4'000'000 个扇区 = 2 GiB）

256 KiB 预读

  • 256 KiB 传输请求大小
  • 80% 读取率（主要读取 MDF 和 LDF 文件）
  • 0% 随机读取
  • 启动时间 10（绕过存储缓存）
  • 最大磁盘大小（4'000'000 个扇区 = 2 GiB）

512 KiB 预读

  • 512 KiB 传输请求大小
  • 80% 读取率（主要读取 MDF 和 LDF 文件）
  • 0% 随机读取
  • 启动时间 10（绕过存储缓存）
  • 最大磁盘大小（4'000'000 个扇区 = 2 GiB）

1024 KiB 预读（企业版）

  • 1024 KiB 传输请求大小
  • 80% 读取率（主要读取 MDF 和 LDF 文件）
  • 0% 随机读取
  • 启动时间 10（绕过存储缓存）
  • 最大磁盘大小（4'000'000 个扇区 = 2 GiB）

您可以改变随机读取的百分比来查看结果是否变化，但我发现上述值是一个很好的起点。

SQL Server 最佳实践文章 (MSDN)

测试读/写和顺序/随机的 I/O 大小组合。对于以 SQL 为中心的部署，请确保顺序 I/O 包含 8 KB、64 KB、128 KB、256 KB 和 1024 的 I/O 大小。（运行 SQL Server Enterprise Edition 时，预读最大可达 1024 KB）。对于随机 I/O，通常只关注 8 KB I/O 是安全的。

解决 SQL Server 中磁盘 I/O 速度缓慢的问题（博客 MSDN）

如果您怀疑磁盘性能不佳，则可以结合使用内部 DMV 和性能监视器集合来全面了解磁盘 I/O 子系统的运行状况以及 SQL Server 因其性能不佳而遇到的任何延迟。

SQL Server Perfmon（性能监视器）最佳实践（Brent Ozar）

在“性能”对象下拉列表中，选择“物理磁盘”，然后选择“% 磁盘时间”计数器。请注意，在右侧窗口中，我们再次获得多个实例；这次，我们为每个物理磁盘获得一个实例。在性能方面，物理磁盘是指计算机管理的磁盘管理工具中显示的一个磁盘。一个物理磁盘可能有多个分区，每个分区都有自己的驱动器号，但对于性能调整，我们想知道一个物理磁盘的工作强度。

这个“物理磁盘”可能有许多实际的物理驱动器，就像在 RAID 系统中一样。但是，Windows 还不够智能，无法准确知道 RAID 阵列中有多少个驱动器，因此“物理磁盘”一词在这里有点误导。

如何从 SQL Server 内部检查 IO 子系统延迟（SQLSkills）

当今大多数 SQL Server 都受 I/O 限制 - 这是 DBA 和该领域的顾问普遍认同的说法。这意味着服务器性能的主要因素是其快速执行 I/O 操作的能力。如果 I/O 子系统无法满足对其的需求，那么 SQL Server 工作负载将遭遇性能问题。

现在，说到这里，许多人陷入的一个陷阱是将增加的 I/O 子系统延迟等同于糟糕的 I/O 子系统性能。通常情况并非如此。通常情况下，当设计为 I/O 的工作负载发生时，I/O 子系统表现良好，但当 I/O 工作负载超过 I/O 子系统设计点时，它就会成为性能瓶颈。I/O 工作负载的增加才是问题的原因，而不是 I/O 子系统——如果您设计的 I/O 子系统支持 1000 IOPS（每秒 I/O 操作数 - 并确保使用正确的 I/O 大小，并且工作负载特性应该以随机 IOPS 的数量来定义），而 SQL Server 试图推动 2000 IOPS，性能就会受到影响。

相关内容