Допустим, у нас есть сервер SQL Server 2000, в котором находится наш основной механизм базы данных.
Мы добавили iSCSI SAN, и теперь на этом сервере одна карта подключена к обычной сети, а одна карта подключена к сети iSCSI.
Данные запрашиваются через другой сервер, который является нашим сервером приложений и не находится в сети iSCSI.
Мы включили Jumbo Packets до 9000 для iSCSI-соединения на сервере данных (а также для других элементов в сети iSCSI.
После прочтения статья Джонатан Кехайас. Мне интересно, правильно ли мы поступили.
Как лучше всего проверить это в моей системе OLTP? Операционная система - Windows Server 2003 R2 Enterprise x64 SP2, а SQL Server - Enterprise 2000 x86.
Совет в статье, на которую вы ссылаетесь, очень хорош, и он объясняет причины, по которым Jumbo-кадры не обязательно являются хорошей идеей в средах LAN общего назначения, но он на самом деле не обсуждает природу самого сетевого трафика iSCSI, и это обычно приносит пользу из Jumbo-кадров, так как трафик ввода-вывода диска будет в относительно больших блоках - 8 КБ, если вы его не изменили. Некоторые эксперты по SQL, возможно, захотят меня поправить, но я думаю, что все операции ввода-вывода базы данных будут фрагментами по 8 КБ. Если размер блока чтения / записи равен 8 КБ, то один ввод-вывод может уместиться в одном кадре Jumbo (служебные данные протокола относительно низкие - обычно <100 байт), а не на шесть блоков стандартного размера.
Вы, вероятно, не увидите каких-либо значительных изменений пропускной способности (возможно, на несколько%), но я ожидал увидеть значительно более низкую загрузку процессора и частоту прерываний от драйвера сетевого интерфейса, поскольку ваш сетевой адаптер обычно будет обрабатывать только 1/6 числа. пакетов для передачи того же количества данных. Для вас это может не иметь большого значения, но если у вас есть несколько сетевых адаптеров, несущих трафик iSCSI, это может привести к значительной части ресурсов ЦП или загруженному серверу. Если у вас есть интеллектуальные сетевые адаптеры с разгрузкой iSCSI \ TCP, очевидно, что преимущества будут меньше, но в целом увеличенный размер кадра по-прежнему упрощает выполнение всего в сетевой структуре iSCSI, поэтому все равно рекомендуется.
Тем не менее - я бы повторил рекомендацию Брента Озара, чтобы вы провели некоторые тесты производительности, если это вообще возможно.
Вероятно, самый простой способ проверить это - использовать SQLIO. У меня есть руководство по этому поводу:
http://sqlserverpedia.com/wiki/SAN_Performance_Tuning_with_SQLIO
Вы можете протестировать это до и после, чтобы увидеть, помогли ли большие кадры или нет.
Я был бы удивлен, если бы это помогло. Конечно, я являюсь Unix SA, а не администратором баз данных / сетями / Windows, но я ожидаю, что от этого ничего не будет, кроме пользы (при условии, что он поддерживается от начала до конца).
Я ожидал, что БД будет читать и писать по крайней мере страницу за раз, как правило, страница БД имеет тот же размер, что и страница ОС (в большинстве систем RISC было 4K для 32-битной версии и 8K для 64-битной, но Подозреваю, что это все еще 4К для 64-битных систем AMD64). Конечно, теоретически вы можете читать и записывать отдельные блоки диска (512 байт), но держу пари, что они этого не делают. Таким образом, с 4K против 1.5K (обычный Ethernet) вы можете выполнить большинство запросов с 1/3 количества пакетов, что должно быть выигрышем, возможно, даже заметным.
Статья совершенно не имеет отношения к вашему беспокойству. Он говорит о трафике приложений, который видит ваш SQL Server. С другой стороны, у вас есть вопрос о подключении к хранилищу - трафике, который видит инициатор iSCSI вашего сервера.
Итак, во-первых, забудьте статью.
Во-вторых, мне еще не приходилось видеть передовой опыт, технический документ или руководство от поставщика хранилища, которые НЕ рекомендовали бы «включать jumbo-кадры».
Приложение не имеет значения. Платформа не имеет значения. iSCSI любит jumbo-кадры, точка.