Несколько PVSCSI с SQL Server

Что касается виртуализации SQL Server, он пытается найти информацию, если есть положительное влияние производительности на разделение устройств данных из устройств журнала на различные Paravirtual SCSI (PVSCSI) адаптеры, аналогичные тем, что сделано here .

На клиенте был сценарий, в который добавлен дополнительный PVSCSI, и устройства регистрации были разделены на новый PVSCSI, что демонстрирует значительный прирост производительности. Тем не менее, сомнение сохраняется, если это связано с этим разделением или просто из-за того, что теперь присутствует еще PVSCSI.

Как известно, лог-диски обычно записываются последовательным образом, а диски данных следуют более случайному шаблону в их r /w, и есть преимущества производительности при размещении этих двух разных типов файлов на отдельных дисках.

Но как насчет контроллеров? Есть ли также преимущество в сохранении этих разных шаблонов в отдельных контроллерах PVSCSI?

Кто-нибудь знает об этом?

Заранее спасибо

12 голосов | спросил JoseTeixeira 1 J0000006Europe/Moscow 2016, 18:27:09

1 ответ


14

Я отвечу в двух частях: сначала «почему традиционный ответ о разделении последовательных и случайных часто не применяется».

Затем я расскажу о потенциальных преимуществах разделения файлов на физическом диске Windows и добавлении дополнительных vHBA и распределении физическихdisks среди них.

Ожидая выгоды от разделения случайного и последовательного дискового ввода-вывода на уровне физического диска Windows, обычно предполагается наличие устройств жесткого диска для хранения данных. Также обычно предполагается, что отдельные физические физические окна Windows означают отдельные жесткие диски. Идея состоит в том, что некоторые комплекты жестких дисков обрабатывают в основном последовательный диск IO и имеют очень ограниченное движение головки диска (например, жесткие диски, на которых размещается один занятый txlog *), в то время как отдельный набор жестких дисков обрабатывает случайный диск IO.

Эти предположения редко сохраняются сегодня - особенно в виртуальной машине. Прежде всего, если физические диски виртуальных машин Windows не являются RDM, несколько из них могут находиться в одном хранилище данных - или, может быть, несколько хранилищ данных находятся на одном LUN-хосте ESXi. Итак, что разделено в гостевой среде, можно объединить на уровне хоста ESXi.

Но скажем, что используются RDM или что каждый гостевой физический диск находится в своем собственном хранилище данных, на собственном ESXi LUN. Даже тогда отдельная последовательность из случайного io в гостевой часто объединяется в массив, поскольку LUN, представленные на хост ESXi, могут быть из одного и того же пула дисковых устройств. Почти каждый массив хранилищ делает это сейчас - либо исключительно, либо как возможность упростить управление и повысить эффективность массива /использование ресурсов.

Наконец, сегодня так много хранилищ - это вся вспышка или гибридная вспышка + жесткий диск. Без движения головы, о котором нужно беспокоиться, вспышка не заботится о разделении последовательных случайных ... даже не заботится о ткачестве IO.

Итак ... это все причины, отделяющие последовательные от случайных, возможно, не все, что полезно. Далее, почему распространение файлов по физическим дискам и расширение физических параметров через vHBA могут все равно повышают производительность.

* Я специально упомянул об одном журнале транзакций в этом примере жесткого диска. Когда на одних и тех же жестких дисках происходит несколько отдельных потоков ввода-вывода последовательного диска (например, 8 журналов транзакций занятости), если только почти все действия не находятся в кэше SAN - постоянное перемещение головки между последовательными дорожками ввода-вывода приводит к IO-переплетению. Это особый тип разгона диска, который приводит к задержке на диске, которая «хуже, чем случайная». Случается на RAID5 и RAID10, хотя RAID10 может переносить только немного больше вариаций в этом отношении, чем RAID5 до значительного ухудшения.


Теперь - учитывая, что длинный разговор о том, как разделение последовательных от случайных может не помочь - как можно распространять файлы по физическим дискам? Как можно распространять физические диски среди vHBA?

Это все о очередях ввода-вывода.

Любой физический диск Windows или LogicalDisk может иметь до 255 выдающихся дисковых модулей одновременно в том, что сообщается perfmon как «Текущая очередь диска». От выдающихся дисковых IO в очереди физического диска, storport может передать до 254 минидиреру. Но мини-ресивер может также иметь как служебную очередь (переданную до следующего нижнего уровня), так и очередь ожидания. И storport можно сказать, чтобы снизить число, которое оно передает с 254.

В гостевой системе VMware Windows драйвер pvscsi имеет глубину очереди «устройство» по умолчанию, равную 64, где устройство является физическим диском. Таким образом, хотя perfmon может отображать до 255 дисковых МО в «текущей длине очереди диска» для одного физического диска, только до 64 из них будут передаваться на следующий уровень за раз (если значения по умолчанию не изменяются).

Сколько дисковых IO может быть выдающимся в журнале транзакций занятости one за раз? Ну, запись в журнале транзакций может достигать 60 КБ. Во время широкомасштабного ETL я часто вижу каждую запись в txlog на 60kb. Писатель txlog может иметь до 32 записей объемом 60 кбайт в один txlog за раз. Так что, если у меня есть занятый этап txlog и занятый dw txlog на том жеphysicaldisk, с настройками VMware по умолчанию? Если оба txlogs максимизируются на 32 выдающихся 60kb-файлах, каждый из них имеет физический диск, который находится на глубине очереди 64. Теперь ... что, если в физическом диске есть также файлы в формате RTF? Ну ... между чтениями с файлами flatfiles и txlog, они должны будут использовать очередь ожидания, потому что только 64 может выходить за один раз. Для баз данных с занятыми txlogs, таких как физический сервер или виртуальный, я рекомендую txlog на своем собственном физическом диске, и ничего больше на физическом диске. Это предотвращает очередность на этом уровне, а также устраняет любую проблему с содержимым чередования нескольких файлов (что в наши дни вызывает гораздо меньшую озабоченность).

Сколько дисковых IO может быть выдающимся для файла строк одновременно (с точки зрения SQL Server, не обязательно представленного на более низкие уровни)? В самом SQL Server не существует предела (я все равно нашел). Но предположим, что файл находится на одном физическом диске Windows (я не рекомендую использовать полосатые динамические диски для SQL Server, это тема для другого времени), там есть лимит. Это 255, о которых я упоминал раньше.

С магией SQL Server readahead и асинхронного ввода-вывода, я видел 4 параллельных запроса, каждый из которых работает в серийном диске общей «текущей длины очереди на диске» более 1200! Из-за ограничения 255, это даже не возможно при всех файлах rowfile на одном физическом диске. Это было против первичной файловой группы с 8 файлами, каждая из которых на собственном физическом диске.

Таким образом, чтение readahead может быть очень агрессивным и может подчеркивать очереди IO. Они могут быть настолько агрессивными, что другие rowfile читает и пишет в ожидании. Если журналы транзакций находятся на одном физическом диске, таком как rowfiles, во время одновременного чтения readahead и записи txlog очень легко ждать. Даже если это ожидание не находится на уровне «текущей длины очереди на диске», оно может ждать в очереди устройства (по умолчанию 64 по умолчанию с помощью pvscsi).

Чтение резервных копий в файлах строк также может быть агрессивным, особенно если настройка буферизации была настроена для максимальной производительности резервного копирования.

Существует еще один тип сервера 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 гостя. Pure /Xtremio /IBM FlashSystem? Иногда глубина очереди узла LUN будет установлена ​​до 256! Идем дальше и устанавливаем глубину очереди устройства pvscsi на значение 254 (Макс.).

Вот ссылка с инструкциями. https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145

В ссылке также говорится о requestringpages - WhatAreThose ?? Они определяют глубину очереди для самого адаптера pvscsi. Каждая страница дает 32 слота в глубине очереди адаптера. По умолчанию requestringpages составляет 8 для глубины очереди адаптера 256. Ее можно установить как 32 для 1024 слотов глубины очереди адаптера.

Предположим, что все по умолчанию. У меня есть 8 физических дисков с файлами строк, и SQL Server занят. В среднем 32 "текущей очереди очереди диска"через 8, и ни один из них не превышает 64 (все вписывается в очереди обслуживания различных устройств). Отлично - это дает 256 OIO. Он подходит в очереди сервисов устройства, он вписывается в очередь обслуживания адаптера, поэтому все 256 выходят из гостевой системы на очереди на уровне хоста ESX.

Но ... если ситуация становится немного более занятой, поэтому в среднем 64 с очередью физических дисков достигает 128. Для тех устройств с более чем 64-разрядной памятью избыток находится в очереди ожидания. Если в служебной очереди устройств на 8 физических дисках больше 256, избыточная сумма находится в очереди ожидания до тех пор, пока не откроются слоты в очереди служб адаптера.

В этом случае добавление другого pvscsi vHBA и расширение физических дисков между ними удваивают общую глубину очереди адаптера до 512. Больше io может быть передано от гостя к хосту одновременно.

Нечто подобное может быть достигнуто путем пребывания в одном адаптере pvscsi и увеличения количества запросов. Переход на 16 приведет к 512 слотам, а 32 - к 1024 слотам.

Когда это возможно, я рекомендую перейти (добавление адаптеров) перед тем, как углубиться (увеличение глубины очереди адаптера). Но ... на многих из самых загруженных систем, вы должны сделать так: поставить 4 vHBA на гостя и увеличить requestringpages до 32.

Есть много других соображений. Такие вещи, как sioc и адаптивная глубина очереди, если используются vmdks, конфигурация многолучевости, конфигурация адаптера ESXi за пределами глубины очереди LUN и т. Д.

Но я не хочу преувеличивать свой прием: -)

Лонни Нидерстадт @sqL_handLe

ответил user96082 3 J0000006Europe/Moscow 2016, 15:33:17

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132