Я отвечу в двух частях: во-первых, «почему традиционный ответ о разделении последовательного и случайного часто не применяется».
Затем я расскажу о потенциальных преимуществах разделения файлов на физическом диске Windows, а также добавления дополнительных vHBA и распределения физических дисков между ними.
Ожидаемая выгода от разделения случайного и последовательного дискового ввода-вывода на уровне физического диска Windows обычно предполагает использование жестких дисков для хранения данных. Также обычно предполагается, что отдельные физические диски Windows означают отдельные устройства на жестких дисках. Идея состоит в том, что некоторый набор жестких дисков обрабатывает в основном последовательный дисковый ввод-вывод и имеет очень ограниченное перемещение головки диска (например, жесткие диски, на которых размещен один занятый txlog *), в то время как отдельный набор жестких дисков обрабатывает случайный дисковый ввод-вывод.
Эти предположения сегодня редко бывают верны - особенно в ВМ. Прежде всего, если физические диски Windows виртуальных машин не являются RDM, несколько из них могут находиться в одном хранилище данных или, возможно, несколько хранилищ данных находятся на одном LUN хоста ESXi. То, что разделено в гостевой системе, может быть объединено на уровне хоста ESXi.
Но допустим, что используются RDM, или что каждый гостевой физический диск находится в собственном хранилище данных, в своем собственном ESXi LUN. Даже в этом случае отдельные последовательные от случайных io в гостевой системе часто смешиваются в массиве, поскольку LUN, представленные хосту ESXi, могут быть из одного и того же пула дисковых устройств. Почти каждый массив хранения делает это сейчас - либо исключительно, либо в качестве опции, чтобы упростить управление и повысить эффективность массива / использование ресурсов.
Наконец, сегодня так много памяти - это либо флэш-память, либо гибридная флэш-память + жесткий диск. Без движения головы, о котором можно беспокоиться, Flash не заботится о разделении последовательного на случайное ... даже не заботится о переплетении ввода-вывода.
Итак ... все эти причины, отделяющие последовательное от случайного, могут быть не такими уж полезными. Далее, почему распространение файлов по физическим дискам и распространение физических дисков по vHBA все равно может повысить производительность.
* В этом примере с жестким диском я специально упомянул один журнал транзакций. Когда несколько отдельных последовательных дисковых потоков ввода-вывода (например, 8 журналов занятых транзакций) выполняются на одних и тех же жестких дисках - если только каким-то образом почти вся активность не находится в кэше SAN - постоянное перемещение заголовка между последовательными дорожками ввода-вывода приводит к переплетению ввода-вывода. Это особый вид перебивания головки диска, который приводит к задержке диска, которая «хуже случайной». Бывает на RAID5 и RAID10, хотя RAID10 может допустить чуть больше вариаций в этом отношении, чем RAID5 до значительной деградации.
Теперь, учитывая давнишний разговор о том, что отделение последовательных от случайных может не помочь, как может помочь распределение файлов по физическим дискам? Как может помочь распространение физических дисков среди vHBA?
Все дело в очередях дискового ввода-вывода.
Любой физический диск Windows или LogicalDisk может иметь до 255 ожидающих дисковых операций ввода-вывода за раз в том, что сообщает perfmon как «Текущая очередь диска». От ожидающих дисковых операций ввода-вывода в очереди физического диска Storport может передавать до 254 минидрайверу. Но минидрайвер может также иметь очередь обслуживания (переданную на следующий более низкий уровень) и очередь ожидания. И Сторпорт может сказать, чтобы уменьшить число, которое он передает с 254.
В гостевой системе VMware Windows драйвер pvscsi имеет глубину очереди «устройство» по умолчанию, равную 64, где устройство является физическим диском. Таким образом, хотя perfmon может отображать до 255 дисковых операций ввода-вывода в «текущей длине очереди диска» для одного физического диска, только до 64 из них будут одновременно передаваться на следующий уровень (если не изменены значения по умолчанию).
Сколько дисковых операций ввода-вывода может быть выдающимся для одногожурнал транзакций занят? Ну, записи журнала транзакций могут быть размером до 60 КБ. Во время крупномасштабного ETL я часто вижу каждую запись в txlog на 60 КБ. Записывающее устройство txlog может иметь до 32 записей по 60 КБ, ожидающих одного txlog одновременно. Так что, если у меня есть занятый промежуточный txlog и занятый dw txlog на одном физическом диске с настройками VMware по умолчанию? Если оба txlogs имеют максимальные значения для 32 ожидающих записей по 60 КБ каждая, этот физический диск находится на глубине своей очереди 64. Теперь ... что, если на физическом диске также есть плоские файлы в качестве источника ETL? Ну что ж ... между чтениями в flatfiles и txlog-записями им придется использовать очередь ожидания, потому что только 64 могут выйти одновременно. Для баз данных с такими занятыми txlogs, будь то физический сервер или виртуальный, я рекомендую txlog на его собственном физическом диске, больше ничего на физическом диске. Это предотвращает постановку в очередь на этом уровне, а также устраняет любые проблемы с чередованием содержимого нескольких файлов (что в наши дни вызывает гораздо меньше проблем).
Сколько дисковых операций ввода-вывода может быть выдающимся для файла строк одновременно (с точки зрения SQL Server, необязательно переданных на более низкие уровни)? На самом деле нет никаких ограничений в самом SQL Server (который я нашел в любом случае). Но предполагается , что файл находится на одном PhysicalDisk Windows (я не рекомендую использовать полосатые динамические диски для SQL Server, это тема для другого времени), то есть предел. Это те 255, о которых я упоминал ранее.
Благодаря магии чтения SQL Server и асинхронного ввода-вывода я видел 4 одновременных запроса, каждый из которых выполняется на последовательном диске, общая «текущая длина очереди диска» более 1200! Из-за ограничения 255 это невозможно даже для всего содержимого файла строки на одном физическом диске. Это было против основной файловой группы с 8 файлами, каждый на своем физическом диске.
Таким образом, чтение в ожидании может быть очень агрессивным и может вызывать проблемы с очередями ввода-вывода. Они могут быть настолько агрессивными, что другие файлы чтения и записи строк в конечном итоге ждут. Если журналы транзакций находятся на том же физическом диске, что и файлы строк, во время одновременных операций чтения в режиме чтения и записи в txlog очень легко ожидать выполнения. Даже если это ожидание не на уровне «текущей длины очереди диска», оно может ожидать в очереди устройства (64 по умолчанию с pvscsi).
Чтение резервных копий по файлам строк также может быть агрессивным, особенно если количество буферов настроено для максимизации пропускной способности резервного копирования.
Существует еще один тип SQL Server io, о котором следует помнить при рассмотрении вопроса об изоляции 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 слота в глубине очереди адаптера. По умолчанию значение requestringpages равно 8 для глубины очереди адаптера 256. Его можно установить равным 32 для 1024 слотов глубины очереди адаптера.
Допустим, все по умолчанию. У меня есть 8 физических дисков с файлами строк, и SQL Server слегка занят. В среднем по 8 «текущая длина очереди диска» равна 8, и ни одна не превышает 64 (все вписывается в различные очереди обслуживания устройств). Прекрасно - это дает 256 OIO. Он помещается в очереди обслуживания устройства, он помещается в очередь обслуживания адаптера, поэтому все 256 выводят его из гостевой очереди в очередь на уровне хоста ESX.
Но ... если ситуация становится немного более загруженной, то в среднем 64 с очередью некоторых физических дисков достигает 128. Для устройств с более чем 64 ожидающими превышение находится в очереди ожидания. Если в очереди обслуживания устройств на всех 8 физических дисках находится более 256, значит, избыток существует в очереди ожидания, пока не откроются слоты в очереди обслуживания адаптера.
В этом случае добавление еще одного vHBA pvscsi и распространение между ними физических дисков удваивает общую глубину очереди адаптера до 512. В то же время от гостя к хосту можно передавать больше io.
Нечто похожее можно достичь, если остановиться на одном адаптере pvscsi и увеличить количество страниц запросов. Переход к 16 даст 512 слотов, а 32 даст 1024 слота.
Когда это возможно, я рекомендую идти широко (добавляя адаптеры), прежде чем углубляться (увеличивая глубину очереди адаптеров). Но… на многих самых загруженных системах нужно сделать и то и другое: поставить 4 гостевых виртуальных хоста на гостевую и увеличить количество страниц запроса до 32.
Есть также много других соображений. Такие вещи, как sioc и адаптивное регулирование глубины очереди при использовании vmdks, конфигурация многолучевого распространения, конфигурация адаптера ESXi за пределами глубины очереди LUN и т. Д.
Но я не хочу задерживать мой прием :-)
Лонни Нидерштадт @sqL_handLe