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

У нас є нова Synology RS3412RPx, яка пропонує цілі iSCSI до трьох вікон Windows 2008 R2 і NFS до одного вікна OpenBSD 5.0.

Вхід у RS3412 за допомогою ssh та читання / запису як невеликих файлів, так і 6 ГБ файлів за допомогою dd та різних блочних розмірів демонструє чудові показники вводу / виводу диска.

Використовуючи dd або іометр на клієнтах iSCSI / NFS, ми досягаємо до 20 Мбіт / с (це не помилка. Двадцять Мбіт / с). Ми якось сподівались краще використовувати декілька Gbit NIC в Synology.

Я перевірив перемикач і конфігурація порта NIC встановлена ​​на гігабіт, а не на автоматичне узгодження. Ми пробували без Jumboframes і без різниці. Я перевірив з допомогою ping, що MTU зараз 9000. Розгорнуто два оновлення мікропрограмного забезпечення.

Я спробую встановити прямий зв'язок між ціллю iSCSI та ініціатором, щоб виключити проблеми з комутацією, але які інші мої варіанти?

Якщо я вимикаю wireshark / tcpdump, що я шукаю?

Оскільки тут, як видається, є загальною темою, погляньте ще раз на налаштування регулювання потоку на комутаторах. Якщо комутатори мають статистику лічильників Ethernet, перегляньте їх і перевірте, чи існує велика кількість кадрів Ethernet PAUSE. Якщо так, то це, мабуть, ваша проблема. Загалом, вимкнення QOS на комутаторах вирішує цю проблему.

Такі потоки підказують мені, що різні методи управління потоками TCP не працюють належним чином. Я бачив деякі проблеми з Linux-ядрами, розмовляючи з версіями Windows після Vista, і ви отримуєте пропускну здатність так. Як правило, вони проявляються досить добре в Wireshark, як тільки ви подивитесь.

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

packet
packet
[ack]
packet
packet
[ack]

Я вирішив це, застосувавши оновлення драйверів NIC до серверів Windows. Розумні NIC, які постачаються з деякими (широкоформатними) серверами, іноді можуть виходити з ладу цікавими способами, і це один.

Нормальною схемою трафіку буде велика кількість пакетів, за якими слідує пакет Ack.

Інша річ, на яку слід звернути увагу - це великі затримки. Підозрілі значення - 2 секунди та 1,0 секунди. Це говорить про те, що одна сторона не отримує того, чого очікує, і чекає закінчення часу, перш ніж відповісти. Поєднайте вищезгадану погану схему пакету із затримкою 200 мс для ACK, і ви отримаєте пропускну здатність колосальних 1 МБ / с.

Це легко помітні погані схеми руху.

Я не працював з таким пристроєм NAS, тому не знаю, наскільки корисно це виправити все, що знайдено.