Якої пропускної здатності мені очікувати при MPIO?

Dell PowerEdge 2950 з двома 1 Gbps NIC збирається до двох портів 1 Gbps на комутаторі, який потім переходить до NetApp з чотирма 1 Gbps NIC, які представлені як один віртуальний інтерфейс. 24 накопичувачі, 7200k SATA, NetApp RAID-DP. Я зіставив кожен хост NIC в NetApp за допомогою MPIO в ініціаторі Microsoft iSCSI. Тестування за допомогою SQLIO пропускна здатність мого запису виявляється розумною приблизно в 200 МБ, але мої показання ближче до 100 МБ.

Чи не слід моїм читанням бути ближче до 200 Мб так само, як пише моє? Це проблема з конфігурацією чи є принципова проблема зберігання, яку я не розумію?

введіть тут опис зображення

Оновлення: Ось IOPS для випадкового навантаження. Читання має сенс, хоча я не впевнений, що робити з 20000 для записів. Кеш SAN - 3,2 ГБ. Тести SQLIO відповідають файлу розміром 25 Гб.

введіть тут опис зображення

sql-server

— Генрі Лі
джерело

Який кеш на пристрої NetApp? Чи є у вас адміністратор SAN, який може витягнути деякі показники для вас? Ми маємо NetApp і змогли визначити декілька проблем із комбінацією звітів та журналів попереджень. Зрештою, наша ситуація була поганою карткою волокон, але підтримка NetApp була дуже корисною для того, щоб допомогти нам у першопричині.

— swasheck

Можливо, варто вивчити конфігурацію ваших агрегатів та томів, щоб переконатися, що ваші диски правильно використовуються (сміливо розміщуйте конфігурацію, хоча я не впевнений, скільки з нас є фахівцями NetApp). Це нормально, щоб записи були швидшими, ніж читання, тому що записи можна кешувати на файловому файлі до того, як вони будуть натиснуті на диск, але зчитування повинні потрапляти на диск, якщо вони вже не знаходяться в кеші.

— Натан Джоллі

@mrdenny Звідки випливає це поняття "99% IO в 64k блоках"? Боб Дорр вказує інакше , як і Уес Браун . Навіть якби ми ігнорували ці дві вичерпні статті, напевно здоровий глузд наказує, що ви збираєтеся бачити 8K IO на платформі, яка використовує розмір сторінки 8K.

— Марк Сторі-Сміт

@mrdenny Шахт повинен бути зламаний, тоді я повинен викликати підтримку? Я сидів тут, дивлячись на активність вводу-виводу файлів даних з монітором процесів, і хоча очікується 64K читання в достатку, є багато інших чисел з 8K читанням і, звичайно, багато 8k запису. Активність журналу, як очікується, 512 байтових кратних, починаючи з одного 512 байтових записів до 60k.

— Марк Сторі-Сміт

@ MarkStorey-Smith На моєму досвіді читання в 8k трапляються, як правило, в залежності від фрагментації. Також може вказати втрата пам’яті, низький термін служби сторінки через сканування виселення сторінок (тобто більша частина міри все ще зберігається в пам'яті). Добре налаштована система повинна показувати 64 кб. Пишемо, звичайно, залежить від того, що насправді є брудним.

— Рем Русану

Відповіді:

Запис на диску насправді збирається в пам'ять (NVRAM) на файловому диску, який буде видалено на диск пізніше - на холостому файлі, вони будуть неймовірно швидкими, а іопси в 20 000 - цілком правдоподібні (ви побачите схожі швидкості з більшості SSD) .

З іншого боку, читачі повинні надходити з диска, якщо вони вже не знаходяться в кеш-пам'яті зчитування файлів (які, на відміну від записів, знаходяться в енергонезалежній пам'яті).

Важко зафіксувати постачальників пам’яті на iops для прядіння дисків, але для 7200RPM накопичувача 80-120 іопів цілком правдоподібно. Зважаючи на те, що ви, ймовірно, втратили пару дисків на RAID-DP та / або запасних частинах NetApp, 2200 іоп близько до того, що можна було очікувати від 22 дисків, що виконують близько 100 іопів кожен.

Це може не пояснити вашу швидкість читання (ваші диски можуть не робити повних 2200 іопів, коли ви виконуєте послідовне читання), але це може принаймні допомогти пояснити вашу ефективність запису.

— Натан Джоллі
джерело

Спасибі Натан. Чи слід очікувати подвійної пропускної здатності з двома NIC та MPIO?

— Генрі Лі

Чи можете ви перевірити використання на своєму файлі, коли ви виконуєте послідовні тести читання? Якщо вона досягає 100%, ваше вузьке вузьке місце, швидше за все, знаходиться у файлі (або через обмеження конфігурації чи iops на кожному диску), і MPIO / додаткові MPIO-з'єднання нічого не додадуть. Пропускна здатність запису може зрости ще більше.

— Натан Джоллі

Для нащадків, після багатьох спроб та помилок, ми розібралися, як отримати очікувану пропускну спроможність.

Як вже було сказано вище, NetApp мав один віртуальний інтерфейс, підтримуваний чотирма фізичними NIC. У хості є два NIC, і я налаштував MPIO через ініціатор MS iSCSI так, щоб був шлях від кожного NIC до одного віртуального інтерфейсу. Результати були вище пропускною здатністю - запис мав сенс наближеним до 200 МБ або швидкості двох НІК, але показання були вдвічі меншими, ніж швидкість одного NIC.

При ближчому огляді наш хлопець SAN помітив, що трафік протікає лише через один з фізичних НІК для зчитування. Я не впевнений, чи була помилка конфігурації на нашому кінці, але ми намагалися дві речі, і обидві отримали нам нашу пропускну здатність. Одне полягало у переході від одного віртуального інтерфейсу, підкріпленого чотирма NIC, на два віртуальних інтерфейсу, кожен із яких підтримувався двома NIC. Потім перенесіть один хост NIC в один віртуальний інтерфейс. Інша річ, яку ми намагалися, - це використовувати "псевдонім" на боці SAN, щоб представити кілька віртуальних інтерфейсів. (Я не хлопець в SAN, тому, сподіваюся, я це правильно сказав).

Мій винос полягає в тому, що нам просто знадобився SAN, щоб представити більше одного інтерфейсу, щоб Ініціатор справді бачив декілька шляхів. Ось наша пропускна спроможність зараз:

введіть тут опис зображення

— Генрі Лі
джерело

чому менші записи зараз повільніше?

— Джек каже, спробуйте topanswers.xyz

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

— Генрі Лі