假设我们有一个容纳我们的主数据库引擎的SQL Server 2000框。
我们添加了一个iSCSI SAN，现在该服务器的一个卡连接到常规networking，一个卡连接到iSCSInetworking。
该数据是通过另一台服务器，这是我们的应用程序服务器，而不是在iSCSInetworking上请求。
我们在数据服务器上的iSCSI连接（以及iSCSInetworking上的其他项目）上启用了Jumbo Packets（9000）。
在阅读Jonathan Kehayias的文章之后 ，我想知道我们做的是对的。
在我的OLTP系统上testing这个最好的方法是什么？ 操作系统是Windows Server 2003 R2 Enterprise x64 SP2，SQL Server是Enterprise 2000 x86。
testing它最简单的方法可能是使用SQLIO。 我在这里有一个教程：
http://sqlserverpedia.com/wiki/SAN_Performance_Tuning_with_SQLIO
你可以在之前和之后testing它，看巨型框架是否有帮助。
您链接的文章中的build议非常好，它解释了为什么巨型帧在通用LAN环境中不一定是个好主意，但是他没有真正讨论iSCSInetworkingstream量本身的性质，从巨型帧作为磁盘IOstream量将在相对较大的块 – 8kb，如果你还没有修改它。 有些SQL专家可能想纠正我，但我认为所有的数据库IO将在8kb块。 如果读/写块大小为8k，那么单个IO就可以放入单个巨型帧（协议开销相对较低 – 一般小于100字节），而不必在六个标准大小之间分割。
你可能不会看到任何显着的吞吐量变化（可能是几个百分点），但是我期望看到的是来自networking接口驱动程序的CPU负载和中断率显着降低，因为你的网卡通常只能处理1/6的数量的数据包携带相同数量的数据。 这对你来说可能不是什么大问题，但是如果你有多个网卡承载iSCSIstream量，那么它可能会占用大量的CPU资源或繁忙的服务器。 如果您拥有带iSCSI \ TCP卸载function的智能网卡，显然其优势将会显着降低，但总体而言，增加的帧大小仍然可以使iSCSInetworking结构上的所有内容更加轻松，因此仍将推荐使用。
这就是说 – 我会回应布伦特·奥扎尔（Brent Ozar）的build议，即尽可能地进行一些性能testing。
如果除了帮助之外，我会感到惊讶。 当然，我是Unix SA，不是DBA / Networking / Windows的人，但是我希望它没有什么好处（假设它是当然支持的）。
我希望数据库一次至less可以读写一个页面，通常DB页面的大小与操作系统页面大小相同（大多数RISC系统的32位为4K，而64位为8K，但是，我怀疑它对于64位AMD64系统仍然是4K）。 当然，它的理论，你可以读写单个磁盘块（512字节），但我敢打赌，他们没有。 所以在4K与1.5K（普通以太网）的情况下，你可以用1/3数据包完成大多数请求，这应该是一个胜利，甚至可能是一个明显的例子。
这篇文章与你的担心完全无关。 它讨论了你的SQL Server看到的应用程序stream量。 另一方面，您有一个关于存储连接的问题 – 服务器的iSCSI启动器看到的stream量。
所以，首先，忘记文章。
其次，我还没有看到来自存储厂商的最佳实践或白皮书或手册，不build议“启用巨型帧”。
应用程序并不重要。 平台并不重要。 iSCSI喜欢巨型帧，时期。