使用 SQL Server 的多个 PVSCSI

我将分两部分回答：首先“为什么关于分离顺序和随机的传统答案通常不适用。”

然后我将讨论在 Windows 物理磁盘上分离文件的潜在好处，以及添加额外的 vHBA 并在它们之间分配物理磁盘。

期望在 Windows 物理磁盘级别分离随机和顺序磁盘 IO 的好处通常假设 HDD 设备用于数据存储。它通常还假设单独的 Windows 物理磁盘意味着单独的 HDD 设备。这个想法是，一些 HDD 主要处理顺序磁盘 IO，并且磁盘磁头移动非常有限（例如，承载单个繁忙 txlog* 的 HDD），而一组单独的 HDD 处理随机磁盘 IO。

这些假设在今天很少成立——尤其是在虚拟机中。首先，除非 VM 的 Windows 物理磁盘是 RDM，否则其中的多个可能位于单个数据存储中 - 或者多个数据存储可能位于单个 ESXi 主机 LUN 上。因此，来宾中分离的内容可以在 ESXi 主机级别混合。

但是，假设使用了 RDM，或者每个客户物理磁盘都在自己的数据存储上，在自己的 ESXi LUN 上。即使这样，来宾中单独的顺序和随机 io 也经常在阵列中混合，因为提供给 ESXi 主机的 LUN 可能来自同一个磁盘设备池。现在几乎每个存储阵列都这样做 - 要么是专门的，要么是作为简化管理和提高阵列效率/资源利用率的选项。

最后，今天如此多的存储要么是全闪存，要么是混合闪存+HDD。无需担心头部移动，flash 不关心随机顺序的分离……甚至不关心 IO 编织。

所以……这些都是将顺序与随机分开的原因可能并不是那么有益。接下来，为什么在物理磁盘之间传播文件和在 vHBA 之间传播物理磁盘仍然可以提高性能。

*我在此 HDD 示例中特意提到了单个事务日志。当几个单独的顺序磁盘 IO 流（例如 8 个繁忙的事务日志）发生在同一个 HDD 上时——除非几乎所有活动都在 SAN 缓存中——顺序 IO 轨道之间的持续磁头移动会导致 IO 编织。这是一种特定类型的磁盘磁头抖动，会导致“比随机更糟糕”的磁盘延迟。发生在 RAID5 和 RAID10 上，尽管 RAID10 在这方面只能容忍比 RAID5 在显着退化之前稍微多一点的变化。

现在 - 考虑到关于如何将顺序与随机分开可能无济于事的冗长讨论 - 如何在物理磁盘上传播文件仍然有帮助？在 vHBA 之间传播物理磁盘有何帮助？

这都是关于磁盘 IO 队列的。

在 perfmon 报告的“当前磁盘队列”中，任何 Windows 物理磁盘或逻辑磁盘一次最多可以有 255 个未完成的磁盘 IO。从物理磁盘队列中未完成的磁盘 IO 中，storport 最多可以将 254 个传递给微型驱动程序。但微型驱动程序也可能同时具有服务队列（向下传递到下一个较低级别）和等待队列。可以告诉 storport 将其传递的数字从 254 降低。

在 VMware Windows 客户机中，pvscsi 驱动程序的默认“设备”队列深度为 64，其中设备是物理磁盘。因此，尽管 perfmon 可以在单个物理磁盘的“当前磁盘队列长度”中显示多达 255 个磁盘 IO，但一次最多只能将其中的 64 个传递到下一个级别（除非更改默认值）。

有多少磁盘 IO 可以未完成一次繁忙的事务日志？好吧，事务日志写入的大小可以达到 60kb。在大规模 ETL 期间，我经常会看到每次写入 txlog 的大小为 60kb。txlog 写入器一次最多可以有 32 个 60kb 的未完成写入到一个 txlog。那么，如果我在同一个物理磁盘上使用默认的 VMware 设置有一个繁忙的暂存 txlog 和一个繁忙的 dw txlog 怎么办？如果两个 txlog 都达到 32 个未完成的 60kb 写入的最大值，则该物理磁盘的队列深度为 64。现在……如果物理磁盘上还有平面文件作为 ETL 源怎么办？嗯……在读取平面文件和写入 txlog 之间，他们必须使用等待队列，因为一次只能输出 64 个。对于具有繁忙 txlog 的数据库，无论是物理服务器还是虚拟服务器，我建议将 txlog 放在其自己的物理磁盘上，物理磁盘上没有其他内容。这可以防止在该级别排队，并且还消除了对多个文件交错内容的任何担忧（如今这是一个非常非常少的问题）。

一次可以有多少磁盘 IO 未完成到行文件（从 SQL Server 的角度来看，不一定要提交到较低级别）？SQL Server 本身并没有真正的限制（无论如何我已经找到了）。但是假设文件位于单个 Windows 物理磁盘上（我不建议为 SQL Server 使用条带化动态磁盘，这是另一个话题），这是有限制的。这是我之前提到的255。

凭借 SQL Server 预读和异步 IO 的魔力，我看到 4 个并发查询，每个查询都在串行驱动器中运行，总“当前磁盘队列长度”超过 1200！由于 255 的限制，这甚至不可能将所有行文件内容都放在一个物理磁盘上。它针对一个有 8 个文件的主文件组，每个文件都在自己的物理磁盘上。

所以预读可能非常激进，并且会给 IO 队列带来压力。它们可能非常激进，以至于其他行文件读取和写入最终都在等待。如果事务日志与行文件位于同一物理磁盘上，则在同时预读读取和 txlog 写入期间，很容易等待发生。即使该等待不在“当前磁盘队列长度”级别，它也可能在设备队列中等待（pvscsi 默认为 64）。

对行文件的备份读取也可能非常激进，尤其是在调整缓冲区计数以最大化备份吞吐量的情况下。

在考虑隔离 txlog 时，还需要注意另一种 SQL Server io 类型：查询溢出到 tempdb。当查询溢出发生时，每个溢出的工作写入 tempdb。有很多并行工作人员同时溢出？这可能是一个相当大的写入负载。让繁忙的 txlog 和重要的行文件远离它真的很有帮助:-)

现在，可以更改 pvscsi 驱动程序的默认设备队列深度。它默认为 64，并且可以设置为 254，这是 storport 将传递的最高值。但要小心改变这一点。我始终建议将客户机设备队列深度与底层 ESXi 主机 LUN 队列深度对齐。并设置每个阵列最佳实践的 ESXi 主机 LUN 队列深度。使用 EMC VNX？主机 LUN 队列深度应为 32。来宾使用 RDM？伟大的。将客户机 pvscsi 设备队列深度设置为 32，使其与 ESXi 主机 LUN 队列深度对齐。EMC VMAX？通常在 ESXi 主机级别为 64，在客户机中为 64。Pure/Xtremio/IBM FlashSystem？有时主机 LUN 队列深度会设置为高达 256！然后将 pvscsi 设备队列深度设置为 254（最大可能）。

这是一个带有说明的链接。 https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145

该链接还谈到 requestringpages - WhatAreThose?? 它们确定 pvscsi 适配器本身的队列深度。每个页面在适配器队列深度中提供 32 个插槽。默认情况下，对于 256 的适配器队列深度，requestringpages 为 8。对于 1024 个适配器队列深度插槽，它可以设置为高达 32。

假设一切都是默认的。我有 8 个物理磁盘，上面有行文件，SQL Server 有点忙。8 个中平均有 32 个“当前磁盘队列长度”，没有一个高于 64（所有内容都适合各种设备服务队列）。太棒了 - 这给了 256 OIO。它适合设备服务队列，适合适配器服务队列，因此所有 256 个都可以从来宾进入 ESX 主机级别的队列。

但是……如果事情变得有点忙，那么平均为 64 个，其中一些物理磁盘的队列高达 128 个。对于那些超过 64 个未完成的设备，超额处于等待队列中。如果超过 256 个在 8 个物理磁盘上的设备服务队列中，则在适配器服务队列中的插槽打开之前，等待队列中的超额。

在这种情况下，添加另一个 pvscsi vHBA 并在它们之间分布物理磁盘会使适配器队列的总深度翻倍，达到 512。更多的 io 可以同时从客户机传递到主机。

通过保持一个 pvscsi 适配器并增加 requestringpages 可以实现类似的效果。去 16 会产生 512 个插槽，而 32 会产生 1024 个插槽。

如果可能，我建议在深入（增加适配器队列深度）之前先扩展（添加适配器）。但是……在许多最繁忙的系统上，必须同时做到：在客户机上放置 4 个 vHBA，并将 requestringpages 增加到 32。

还有很多其他的考虑。诸如 sioc 和自适应队列深度限制（如果使用 vmdks）、多路径配置、超出 LUN 队列深度的 ESXi 适配器配置等。

但我不想过分欢迎:-)

朗尼·尼德施塔特@sqL_handLe