假设我们有一个 SQL Server 2000 盒，其中装有我们的主要数据库引擎。
我们添加了一个 iSCSI SAN，现在该服务器有一张卡连接到常规网络，还有一张卡连接到 iSCSI 网络。
数据是通过另一台服务器请求的，该服务器是我们的应用服务器，它不在 iSCSI 网络上。
我们在数据服务器上的 iSCSI 连接上将巨型数据包启用到 9000（以及 iSCSI 网络上的其他项目）。
在读完文章作者：乔纳森·凯哈亚斯 我不知道我们所做的事情是否正确。
在我的 OLTP 系统上测试这一点的最佳方法是什么？操作系统是 Windows Server 2003 R2 Enterprise x64 SP2，SQL Server 是 Enterprise 2000 x86。
答案1
测试它的最简单方法可能是使用 SQLIO。我在这里有一个教程：
http://sqlserverpedia.com/wiki/SAN_Performance_Tuning_with_SQLIO
您可以前后测试一下，看看巨型帧是否有帮助。
答案2
您链接的文章中的建议非常好，它解释了为什么巨型帧在通用 LAN 环境中不一定是个好主意，但他并没有真正讨论 iSCSI 网络流量本身的性质，而这通常会受益于巨型帧，因为磁盘 IO 流量将以相对较大的块形式出现 - 如果您没有修改它，则为 8kb。一些 SQL 专家可能想纠正我这一点，但我认为所有数据库 IO 都将以 8kb 的块形式出现。如果读\写块大小为 8k，那么单个 IO 可以放入单个巨型帧中（协议开销相对较低 - 通常小于 100 字节），而不必分成六个标准大小的帧。
您可能不会看到任何显著的吞吐量变化（可能只有几个百分点），但我期望看到的是网络接口驱动程序的 CPU 负载和中断率会显著降低，因为您的 NIC 通常只处理 1/6 的数据包来承载相同数量的数据。这对您来说可能不是什么大问题，但如果您有多个 NIC 承载 iSCSI 流量，则可能会占用大量 CPU 资源或导致服务器繁忙。如果您有带 iSCSI\TCP 卸载功能的智能 NIC，那么好处显然会更低，但总体而言，增加的帧大小仍使 iSCSI 网络结构上的所有内容都更容易，因此仍然值得推荐。
话虽如此 - 我赞同 Brent Ozar 的建议，如果可能的话，您应该进行一些性能测试。
答案3
如果它除了帮助之外还有什么的话我会很惊讶。当然，我是一个 Unix SA，而不是 DBA/网络/Windows 专家，但我希望它能带来好处（当然，假设它得到端到端的支持）。
我期望数据库一次至少读取和写入一个页面，通常数据库页面的大小与操作系统页面相同（大多数 RISC 系统 32 位为 4K，64 位为 8K，但我怀疑 64 位 AMD64 系统仍然是 4K）。当然，理论上，您可以读取和写入单个磁盘块（512 字节），但我敢打赌他们做不到。因此，使用 4K 与 1.5K（普通以太网），您可以用 1/3 的数据包数量满足大多数请求，这应该是一个胜利，甚至可能是一个明显的胜利。
答案4
这篇文章与您的问题完全无关。它谈论的是您的 SQL Server 看到的应用程序流量。另一方面，您对存储连接性有疑问 - 您的服务器的 iSCSI 启动器看到的流量。
所以，首先，忘记这篇文章。
其次，我还没有看到存储供应商提供的最佳实践、白皮书或手册不建议“启用巨型帧”。
应用程序无所谓。平台无所谓。iSCSI 喜欢巨型帧，就是这样。