关于SQL Server虚拟化，一直在尝试查找有关将数据设备从日志设备分离到不同的准虚拟SCSI（PVSCSI）适配器方面是否对性能产生正面影响的信息，类似于此处所做的。
在客户端上有一种方案，其中添加了附加的PVSCSI，并且日志设备与新的PVSCSI分离，从而显示出可观的性能提升。然而，仍然怀疑是由于这种分离还是仅由于现在存在附加的PVSCSI而引起的。
众所周知，日志磁盘通常以顺序方式写入，而数据磁盘的读/写遵循更随机的模式，将这两种不同类型的文件放在单独的磁盘上会带来性能上的好处。
但是控制器呢？将这些不同的模式保存在单独的PVSCSI控制器中是否也有好处？
有人对此有见识吗？
提前致谢
Answers:
我将分两部分进行回答：第一部分“为什么传统的关于顺序和随机分离的答案通常不适用”。
然后，我将讨论在Windows物理磁盘上分离文件以及添加其他vHBA并在其中分配物理磁盘的潜在好处。
从Windows物理磁盘级别分离随机磁盘磁盘和顺序磁盘IO获得的预期收益通常假定将HDD设备用于数据存储。通常还假定单独的Windows物理磁盘意味着单独的HDD设备。这个想法是，某些HDD集主要处理顺序磁盘IO，并且磁盘磁头移动非常有限（例如，托管单个繁忙txlog *的HDD），而另一组HDD处理随机磁盘IO。
这些假设在今天很少成立-特别是在VM中。首先，除非VM Windows物理磁盘是RDM，否则多个虚拟磁盘可能位于单个数据存储中-或多个数据存储可能位于单个ESXi主机LUN上。因此，来宾中分离的内容可以在ESXi主机级别混合。
但是，可以说使用了RDM，或者每个来宾物理磁盘位于其自己的ESXi LUN上的自己的数据存储中。即使那样，客户机中的顺序io与随机io也会经常混合在阵列中，因为提供给ESXi主机的LUN可能来自同一磁盘设备池。现在几乎每个存储阵列都可以做到这一点-专门或作为简化管理和提高阵列效率/资源利用率的选择。
最后，今天的大量存储是全闪存或混合闪存+ HDD。无需担心头部移动，闪存不关心随机顺序序列的分离……甚至不关心IO编织。
因此，...所有这些都是将顺序与随机分开的原因可能并不是那么有益。下一步，为什么跨物理磁盘分布文件和跨vHBA分布物理磁盘仍然可以提高性能。
*在此HDD示例中，我故意提到了单个事务日志。当在同一HDD上发生几个单独的顺序磁盘IO流（例如8个繁忙的事务日志）时-除非几乎所有活动都在SAN缓存内，否则，顺序IO磁道之间不断的磁头移动会导致IO编织。这是一种特殊的磁盘磁头抖动，导致磁盘延迟“比随机磁盘更糟糕”。在RAID5和RAID10上会发生这种情况，尽管RAID10在这方面的容忍性要比RAID5稍大一些，然后才能大幅降低。
现在-鉴于冗长的讨论如何将顺序与随机分开可能无济于事-在物理磁盘上分散文件仍然有帮助吗？在vHBA之间扩展物理磁盘有何帮助？
全部与磁盘IO队列有关。
每个Windows物理磁盘或LogicalDisk一次最多可以有255个未完成的磁盘IO，perfmon将其报告为“当前磁盘队列”。通过物理磁盘队列中未完成的磁盘IO，storport最多可以将254传递给微型驱动程序。但是微型驱动程序可能同时具有服务队列（传递到下一个较低的级别）和等待队列。可以告诉storport从254降低传递的数字。
在VMware Windows guest虚拟机中，pvscsi驱动程序的默认“设备”队列深度为64，其中设备是物理磁盘。因此，尽管perfmon可以在单个物理磁盘的“当前磁盘队列长度”中显示多达255个磁盘IO，但是一次最多只能将其中的64个传递到下一级（除非更改了默认值）。
一个磁盘可以处理多少个磁盘IO一次繁忙的交易日志？好吧，事务日志的写操作最大可以达到60kb。在大规模ETL中，我经常会看到每次以60kb的速率写入txlog。txlog编写器一次最多可以有32个60kb的未完成写操作。那么，如果使用默认的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）。
对行文件的备份读取也可能非常激进，尤其是在已调整缓冲区计数以最大化备份吞吐量的情况下。
当考虑隔离txlogs时，还需要注意另一种SQL Server io类型：查询溢出到tempdb。当查询溢出发生时，每个溢出工作都会写入tempdb。有很多并行工作的人都在同一时间溢出吗？那可能是相当大的写负载。远离繁忙的txlog和重要的行文件可能会很有帮助:-)
现在，可以更改pvscsi驱动程序的默认设备队列深度。它的默认值为64，可以设置为最高254，这是最大传输速率。但是请小心更改。我始终建议将来宾设备队列深度与基础ESXi主机LUN队列深度对齐。并根据阵列设置ESXi主机LUN队列深度的最佳做法。使用EMC VNX？主机LUN队列深度应为32。来宾使用RDM？大。将guest虚拟机pvscsi设备队列深度设置为32，以使其与ESXi主机LUN队列深度对齐。EMC VMAX？通常在ESXi主机级别为64，在来宾系统为64。Pure / Xtremio / IBM FlashSystem？有时主机LUN队列深度将设置为256！继续，然后将pvscsi设备队列深度设置为254（最大可能）。
该链接还讨论了requestringpages-WhatAreThose？它们确定pvscsi适配器本身的队列深度。每个页面在适配器队列深度中提供32个插槽。默认情况下，适配器队列深度为256时，requestringpages为8。对于1024个适配器队列深度插槽，可以将它设置为32。
假设所有内容均为默认设置。我有8个带有行文件的物理磁盘，而SQL Server则很忙。在这8个中，平均有32个“当前磁盘队列长度”，并且没有一个大于64（一切都适合各种设备服务队列）。太好了-可提供256个OIO。它适合设备服务队列，适合适配器服务队列，因此所有256个都使其脱离来宾系统以进入ESX主机级别的队列。
但是……如果事情变得有点忙，那么平均一些物理磁盘的队列会达到64个，最高可达128个。对于那些有64个以上未完成的设备，超额等待队列中。如果跨8个物理磁盘的设备服务队列中的256个以上，则等待适配器队列中的剩余空间将满，直到适配器服务队列中的插槽打开为止。
在这种情况下，添加另一个pvscsi vHBA并在它们之间散布物理磁盘会使适配器队列的总深度加倍，达到512。可以同时从guest虚拟机向主机传递更多的io。
通过停留在一个pvscsi适配器上并增加requestringpages，可以实现类似的效果。转到16将产生512个插槽，而转到32将产生1024个插槽。
如果可能，我建议先变宽（添加适配器），然后再变深（增加适配器队列深度）。但是……在许多最繁忙的系统上，必须同时做这两个事情：在客户机上放置4个vHBA，并将requestringpages增加到32。
还有许多其他考虑因素。sioc和自适应队列深度限制（如果使用了vmdks的话），多路径配置，超出LUN队列深度的ESXi适配器的配置等。
但是我不想逾越我的欢迎:-)
朗尼·尼德斯塔特@sqL_handLe