Должен ли я отключить Jumbo Packets в сети iSCSI?

Вероятно, самый простой способ проверить это - использовать SQLIO. У меня есть учебник по этому вопросу здесь:

http://sqlserverpedia.com/wiki/SAN_Performance_Tuning_with_SQLIO

Вы можете проверить это до и после, чтобы увидеть, помогли ли гигантские кадры или нет.

Совет в статье, на которую вы ссылаетесь, очень хорош, и в нем объясняются причины, по которым Jumbo-кадры не обязательно являются хорошей идеей в средах LAN общего назначения, но он на самом деле не обсуждает природу самого сетевого трафика iSCSI, и это обычно приносит пользу из Jumbo-фреймов, поскольку дисковый ввод-вывод будет в относительно больших блоках - 8 КБ, если вы его не модифицировали. Некоторые эксперты по SQL, возможно, захотят меня поправить, но я думаю, что все операции ввода-вывода в базе данных будут происходить в виде фрагментов по 8 КБ. Если размер блока чтения \ записи равен 8 КБ, то один ввод-вывод может уместиться в одном Jumbo-кадре (издержки протокола относительно невелики - в целом < 100 байт), вместо того, чтобы разделять его на шесть стандартных размеров.

Вы, вероятно, не увидите значительного изменения пропускной способности (возможно, на несколько%), но я ожидаю увидеть значительно более низкую нагрузку на процессор и частоту прерываний от драйвера сетевого интерфейса, поскольку ваша сетевая плата обычно обрабатывает только 1/6 числа пакетов для переноса одинакового количества данных. Это может быть не так уж сложно для вас, но если у вас есть несколько сетевых адаптеров, несущих трафик iSCSI, это может добавить значительную часть ресурсов ЦП или занятого сервера. Если у вас есть интеллектуальная сетевая карта с разгрузкой iSCSI\TCP, преимущества, очевидно, будут ниже, но в целом увеличенный размер кадра по-прежнему упрощает все в сетевой структуре iSCSI, поэтому его все равно рекомендуется.

Тем не менее, я бы повторил рекомендацию Брента Озара о том, чтобы вы провели несколько тестов производительности, если это вообще возможно.

Я был бы удивлен, если бы было что-то кроме помощи. Конечно, я Unix SA, а не администратор баз данных / сетей /Windows, но я ожидаю, что это ничего не даст, кроме хорошего (при условии, что это поддерживается от начала до конца, конечно).

Я ожидаю, что БД будет читать и записывать по крайней мере страницу за раз, обычно страница БД имеет тот же размер, что и страница ОС (большинство систем RISC имели 4 КБ для 32-разрядных и 8 КБ для 64-разрядных, но Я подозреваю, что это все еще 4K для 64-битных систем AMD64). Конечно, это теория, вы можете читать и записывать однодисковые блоки (512 байт), но я уверен, что они этого не делают. So with 4K vs 1.5K (normal ethernet), you can fulfill most requests with 1/3 the number of packets, which ought to be a win, possibly even a noticeable one.

Статья совершенно не имеет отношения к вашей проблеме. Он говорит о трафике приложений, который видит ваш SQL Server. С другой стороны, у вас есть вопрос о подключении хранилища - трафик, который видит инициатор iSCSI вашего сервера.

Итак, сначала забудьте статью.

Во-вторых, мне еще предстоит ознакомиться с рекомендациями или техническим документом или руководством от поставщика систем хранения, в котором НЕ рекомендовалось бы "включать гигантские кадры".

Приложение не имеет значения. Платформа не имеет значения. iSCSI любит большие кадры, точка.