Я відповім у двох частинах: спочатку "чому традиційна відповідь про поділ послідовних та випадкових часто не застосовується".
Тоді я обговорюю потенційні переваги розділення файлів на фізичному диску Windows та додавання додаткових vHBA та розповсюдження фізичних дисків серед них.
Очікуючи вигоди від розділення IO випадкових та послідовних дисків на рівні фізичного диска Windows, зазвичай передбачаються пристрої жорсткого диска для зберігання даних. Також зазвичай передбачається, що окремі фізичні диски Windows означають окремі пристрої жорсткого диска. Ідея полягає в тому, що деякий набір жорстких дисків обробляє в основному послідовний диск IO і має дуже обмежений рух головки диска (наприклад, жорсткі диски, що розміщують один зайнятий txlog *), тоді як окремий набір жорстких дисків обробляє IO випадкових дисків.
Ці припущення рідко дотримуються сьогодні - особливо у ВМ. Перш за все, якщо фізичні диски віртуальних машин Windows не є RDM, декілька значень можуть бути в одному сховищі даних, або, можливо, кілька сховищ даних є на одному хості LUN ESXi. Тож те, що відокремлено в гості, може бути замінено на рівні хостів ESXi.
Але скажімо, що використовуються RDM або кожен фізичний диск гостя знаходиться у власному сховищі даних, у власному ESXi LUN. Вже тоді окремий послідовний від випадкового io в гості часто переміщується в масиві, оскільки LUN, представлені хосту ESXi, можуть бути з одного і того ж пулу дискових пристроїв. Практично кожен масив пам’яті робить це зараз - виключно або як варіант для полегшення управління та підвищення ефективності масиву / використання ресурсів.
Нарешті, стільки пам’яті сьогодні - це або весь флеш, або гібридний спалах + жорсткий диск. Не турбуючись про рух голови, спалах не хвилює поділ послідовних випадкових випадків ... навіть не хвилює плетіння вводу-виводу.
Отже ... це все причини, що відокремлюють послідовне від випадкового, може бути не настільки корисним. Далі, чому розповсюдження файлів у фізичних дисках та розповсюдження фізичних дисків по vHBA все ще може підвищити продуктивність.
* Я цілеспрямовано згадував один журнал транзакцій у цьому прикладі жорсткого диска. Коли декілька окремих послідовних потоків вводу-виводу диска (наприклад, 8 журналів транзакцій) відбуваються на одних і тих же жорстких дисках - якщо якимось чином майже вся активність не знаходиться в кеш-пам'яті SAN - постійний рух голови серед послідовних треків вводу-виводу призводить до плетіння IO. Це специфічний вид молотання головки диска, який призводить до затримки диска, яка "гірша, ніж випадкова". Відбувається у RAID5 та RAID10, хоча RAID10 може переносити лише трохи більше змін у цьому відношенні, ніж RAID5 до значної деградації.
Тепер - з огляду на те, що розмовляння довгими думками про те, як відокремлення послідовного від випадкового може не допомогти - як ще може допомогти розповсюдження файлів через фізичні диски? Як можна допомогти поширенню фізичних дисків серед vHBA?
Вся справа в черзі дискового вводу.
Будь-який фізичний диск Windows або LogicalDisk може мати до 255 відкритих дискових входів одночасно, про що повідомляється perfmon як "Поточна черга диска". Із видатних дискових входів у черзі фізичного диска, storport може передавати до 254 міні-диверсору. Але мінідрівер також може мати чергу обслуговування (переходити на наступний нижчий рівень) і чергу очікування. І шторпорту можна сказати знизити число, яке воно передає, з 254.
У гості VMware Windows драйвер pvscsi має за замовчуванням «пристрою» чергу глибиною 64, де пристрій - фізичний диск. Отже, хоча perfmon може відображати до 255 дискових вводу в "поточну довжину дискової черги" для одного фізичногодиска, лише до 64 з них буде переведено на наступний рівень за один раз (якщо не буде змінено параметри за замовчуванням).
Скільки дискових IO можуть бути видатними для одногозайнятий журнал транзакцій за раз? Ну а запис журналу транзакцій може бути розміром до 60 Кб. Під час високої шкали ETL я часто бачу кожне записування до txlog зі швидкістю 60 кбіт. Письменник txlog може мати до 32 записів, що мають 60 кбіт, до одного txlog одночасно. Так що робити, якщо у мене на тій же фізичній дисках зайнято txlog інсценізації та зайнятий twlog dw з типовими налаштуваннями VMware? Якщо обидва txlogs максимумують на 32 видатних 60kb записує кожен, що PhysicalDisk знаходиться на своїй глибині черги 64. Тепер ... що робити, якщо також є фізичні файли як джерело ETL на physdisk? Ну ... між читаннями на плоскі файли та txlog write, їм доведеться використовувати чергу очікування, тому що лише 64 можуть вийти за один раз. Для таких баз даних із зайнятими txlogs, як це, будь то фізичний сервер чи віртуальний, я рекомендую txlog у власному фізичному диску, ні з чим іншим на фізичномудиску. Це запобігає встановленню черг на цьому рівні, а також усуває будь-які занепокоєння щодо вмісту декількох файлів, що переплітаються (що набагато турбує набагато менше).
Скільки дискових входів можуть бути видатними для файлу рядків одночасно (з точки зору SQL Server, не обов'язково подається на нижчі рівні)? Насправді немає обмеження в самому SQL Server (який я все-таки знайшов). Але передбачається , що файл знаходиться на одному PhysicalDisk Windows (я не рекомендую використовувати смугасті динамічні диски для SQL Server, це тема для іншого часу), то є межа. Це 255 я згадував раніше.
Завдяки магії SQL Server на читачах та асинхронному IO, я бачив 4 паралельних запити, кожен з яких виконує послідовний диск загальною «поточною довжиною черги диска» понад 1200! Через обмеження 255 це неможливо навіть із усім вмістом файлів рядків на одному фізичному диску. Це було проти первинної групи файлів з 8 файлів, кожен з яких має власний фізичний диск.
Таким чином, читання на головах може бути дуже агресивним і може підкреслювати черги введення-виведення. Вони можуть бути настільки агресивними, що інші файли рядків читають і записують в кінці очікування. Якщо журнали транзакцій знаходяться на тому ж фізичному диску, що і файли рядків, під час одночасного читання головою та txlog пише, що чекати його буде дуже просто. Навіть якщо це очікування не на рівні "поточної довжини дискової черги", воно може чекати на черзі пристроїв (64 за замовчуванням з pvscsi).
Зчитування резервного копіювання проти файлів рядків також може бути агресивним, особливо якщо налаштування буфера було налаштовано з метою максимальної пропускної здатності.
Існує ще один тип io io SQL Server, про який слід пам’ятати, розглядаючи питання про виділення txlogs: розсилка запитів на tempdb. Коли відбувається розлив запитів, кожен робочий розсип записує до tempdb. Чи багато паралельних робітників, які все розливаються одночасно? Це може бути великим навантаженням для запису. Тримання зайнятого txlog та важливих файлів файлів неподалік від цього може бути дуже корисним :-)
Тепер можна змінити глибину черги пристроїв за замовчуванням для драйвера pvscsi. Він за замовчуванням до 64, і його можна встановити до 254, що є найбільшим портом. Але будьте обережні, змінивши це. Я завжди рекомендую вирівняти глибину черги гостьового пристрою з базовою глибиною черги LUN хоста ESXi. І встановлення глибини черги LUN хоста ESXi на кращий досвід. Використовуєте EMC VNX? Глибина черги хосту LUN повинна бути 32. Гість використовує RDM? Чудово. Встановіть глибину черги гостьових пристроїв pvscsi на 32, щоб вона відповідала глибині черги LUN хоста ESXi. EMC VMAX? Зазвичай 64 на рівні хостів ESXi, 64 у гостях. Чиста / Xtremio / IBM FlashSystem? Іноді глибина черги хостів LUN встановлюється на рівні 256! Вперед та встановіть глибину черги пристроїв pvscsi на 254 (можливо максимально).
Ось посилання з інструкціями.
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
Посилання також розповідає про сторінку про запит - WhatAreThose ?? Вони визначають глибину черги для самого адаптера pvscsi. Кожна сторінка містить 32 слоти в глибині черги адаптера. За замовчуванням сторінка замовника вимагає 8 для глибини черги адаптера 256. Її можна встановити як 32 для 1024 слотів глибини черги адаптера.
Скажімо, все за замовчуванням. У мене 8 фізичних дисків з файлами рядків на них, і SQL Server трохи зайнятий. В середньому 32 "поточної довжини дискової черги" на 8, і жоден не перевищує 64 (все вписується в різні черги обслуговування пристроїв). Чудово - що дає 256 OIO. Він вписується в черги обслуговування пристрою, він вписується в чергу обслуговування служб адаптера, тому всі 256 роблять його з гостя в черги на рівні хостів ESX.
Але ... якщо все стає дещо зайнятішим, тож у середньому 64 з чергою фізичних дисків досягають 128. Для тих пристроїв, у яких понад 64 непогашених, надмірне значення знаходиться у черзі очікування. Якщо більше 8 службових службових черг пристроїв на 8 фізичних дисках, то надмірна кількість є в черзі очікування, поки не відкриються прорізи в черзі служби адаптера.
У такому випадку додавання ще одного pvscsi vHBA та поширення фізичнихдисків між ними подвоює загальну глибину черги адаптера до 512. Більше io може бути передано одночасно від гостя до хоста.
Щось подібного можна досягти, залишившись на одному адаптері pvscsi та збільшивши кількість запитів на сторінки. Перехід до 16 дасть 512 слотів, а 32 - 1024 слота.
Коли це можливо, я рекомендую пройти широко (додавання адаптерів) перед тим, як заглибитись (збільшити глибину черги адаптера). Але ... у багатьох найпотужніших системах треба зробити і те, і інше: покласти 4 vHBA на гостя та збільшити кількість запитів на 32 сторінки.
Є й багато інших міркувань. Такі речі, як sioc та адаптивне зменшення глибини черги, якщо використовуються vmdks, конфігурація багатошляху, конфігурація адаптера ESXi понад глибину черги LUN тощо.
Але я не хочу перебільшувати привітання :-)
Лонні Нідерштадт @sqL_handLe