Стратегия устранения неполадок для очень низкой производительности iSCSI / NFS

У нас есть новая Synology RS3412RPxs, которая предлагает целевые объекты iSCSI для трех блоков Windows 2008 R2 и NFS для одного блока OpenBSD 5.0.

Вход в RS3412 с помощью ssh и чтение / запись как небольших файлов, так и файлов объемом 6 ГБ с использованием dd и различных размеров блоков показывают отличную производительность дискового ввода-вывода.

Используя dd или iometer на клиентах iSCSI / NFS, мы достигаем скорости до 20 Мбит / с (это не опечатка. Двадцать Мбит / с). Мы надеялись лучше использовать несколько сетевых карт Gbit в Synology.

Я проверил коммутатор, и конфигурация порта NIC установлена ​​на гигабит, а не автосогласование. Мы пробовали с и без Jumboframes без разницы. С помощью ping я проверил, что MTU в настоящее время составляет 9000. Два обновления встроенного ПО были развернуты.

Я собираюсь попробовать прямую связь между целью iSCSI и инициатором, чтобы исключить проблемы с коммутатором, но каковы мои другие варианты?

Если я разорву wireshark / tcpdump, что мне искать?

Как кажется, это общая тема здесь, еще раз взгляните на настройки управления потоком на коммутаторе (ах). Если у коммутатора (ов) есть статистика счетчика Ethernet, посмотрите на них и посмотрите, есть ли большое количество кадров Ethernet PAUSE. Если так, то это, вероятно, ваша проблема. В общем, отключение QOS на коммутаторе (-ах) решает эту проблему.

Подобные потоки подсказывают мне, что различные методы управления потоками TCP работают неправильно. Я видел некоторые проблемы с ядрами Linux, разговаривающими с версиями Windows после Vista, и вы получаете такие результаты. Как правило, они хорошо видны в Wireshark, как только вы посмотрите.

Абсолютно худшая возможность состоит в том, что задержанное подтверждение TCP полностью сломано, и вы увидите структуру трафика, которая выглядит следующим образом:

packet
packet
[ack]
packet
packet
[ack]

Я решил эту проблему, применив обновления драйверов NIC к серверам Windows. Интеллектуальные сетевые адаптеры, которые поставляются с некоторыми (Broadcom) серверами, могут иногда интересным образом выходить из строя, и это один из них.

Обычная схема трафика - это большое количество пакетов, за которыми следует пакет Ack.

Другая вещь, чтобы искать, это длинные задержки. Подозрительные значения составляют 0,2 секунды и 1,0 секунды. Это говорит о том, что одна сторона не получает ожидаемого и ожидает истечения времени ожидания, прежде чем ответить. Объедините вышеупомянутый шаблон плохих пакетов с задержкой 200 мс для ACK, и вы получите пропускную способность колоссальных 1 МБ / с.

Это легко заметные плохие модели трафика.

Я не работал с такого рода устройствами NAS, поэтому не знаю, насколько это легко исправить, чтобы найти то, что найдено.