Хранилище Azure класса "Премиум": разработка, обеспечивающая повышенную производительность
Применимо к: ✔️ Виртуальные машины Linux ✔️ Виртуальные машины Windows ✔️ Универсальные масштабируемые наборы
В этой статье приведены рекомендации по разработке высокопроизводительных приложений с использованием хранилища Azure класса «Премиум». Указания в этом документе можно использовать вместе с рекомендациями по производительности, применимыми к технологиям, которые используются приложением. Чтобы продемонстрировать упомянутые рекомендации, в этом документе в качестве примера использован SQL Server, запущенный в хранилище класса «Премиум».
Хотя в этой статье приведены сценарии повышения производительности для уровня хранилища, вам нужно будет оптимизировать уровень приложения. Например, при размещении фермы SharePoint в хранилище Azure класса «Премиум» для оптимизации работы сервера базы данных можно использовать примеры для SQL Server из этой статьи. Кроме того, для получения лучшей производительности можно также оптимизировать веб-сервер и сервер приложений фермы SharePoint.
В этой статье содержатся ответы на следующие распространенные вопросы об оптимизации производительности приложений в хранилище Azure класса «Премиум».
- Как измерить производительность приложения?
- Почему не наблюдается ожидаемая высокая производительность?
- Какие факторы влияют на производительность приложения в хранилище класса «Премиум»?
- Как эти факторы влияют на производительность приложения в хранилище класса «Премиум»?
- Как можно оптимизировать операции ввода-вывода, пропускную способность и задержку?
Рекомендации в этой статье предназначены специально для хранилища класса «Премиум», так как рабочие нагрузки в этом хранилище очень чувствительны к уровню производительности. В соответствующих случаях приведены наглядные примеры. Некоторые из этих рекомендаций можно также применять к приложениям, выполняющимся в виртуальных машинах IaaS с использованием дисков хранилища класса «Стандартный».
Примечание
Иногда проблема, которая выглядит как недостаточная производительность дисков, на самом деле вызвана узким местом в сети. В таких ситуациях следует улучшить производительность сети.
Если вы хотите протестировать производительность диска, воспользуйтесь следующими статьями на эту тему.
- Для Linux: Тестирование производительности приложения в Хранилище дисков Azure.
- Для Windows: Тестирование производительности диска.
Если виртуальная машина поддерживает ускоренную сеть, необходимо включить эту функцию. Если она не включена, ее можно включить на уже развернутых виртуальных машинах под управлением Windows и Linux.
Если вы не знакомы с хранилищем класса Premium, перед началом работы ознакомьтесь со статьями Какие типы дисков доступны в Azure? и Целевые показатели масштабируемости и производительности для учетных записей хранилища BLOB-объектов класса Premium.
Показатели производительности приложения
Оценка производительности приложения выполняется на основе определенных показателей, например скорость обработки запросов пользователя приложением, объем данных, обрабатываемых приложением для каждого запроса, количество запросов, обрабатываемых приложением в определенный период времени, а также период времени от отправки запроса и до получения ответа. Технически эти показатели производительности называются так: количество операций ввода-вывода в секунду, пропускная способность и задержка.
В этом разделе рассматриваются общие показатели производительности в контексте хранилища класса «Премиум». В следующем разделе («Сбор требований к производительности приложения») описывается, как измерить эти показатели производительности для приложения. Далее в разделе Оптимизация производительности приложения рассказывается о факторах, влияющих на эти показатели производительности, и рекомендациях по их оптимизации.
ОПЕРАЦИЙ ВВОДА-ВЫВОДА
Количество операций ввода-вывода в секунду (IOPS) — это количество запросов, которые приложение отправляет на диски хранилища за одну секунду. Различают следующие типы операций ввода-вывода: чтения или записи, последовательные или случайные. Приложениям оперативной обработки транзакций (OLTP), таким как веб-сайты розничной торговли, необходимо сразу обрабатывать множество одновременных запросов пользователей. Запросы пользователя представляют собой ресурсоемкие транзакции вставки и обновления в базе данных, требующие быстрой обработки. Поэтому приложениям OLTP необходима очень высокая скорость выполнения операций ввода-вывода. Такие приложения обрабатывают миллионы небольших случайных запросов ввода-вывода. Для такого приложения следует разрабатывать инфраструктуру с учетом оптимизации операций ввода-вывода. В разделе Оптимизация производительности приложенияподробно рассматриваются все факторы, которые необходимо учитывать для получения высокой скорости выполнения операций ввода-вывода.
При подключении диска хранилища класса «Премиум» к высокомасштабируемой виртуальной машине Azure выполняет подготовку гарантированного количества операций ввода-вывода в секунду в соответствии со спецификацией диска. Например, диск P50 позволяет подготовить 7500 операций ввода-вывода в секунду. Для каждого размера высокомасштабируемой виртуальной машины также установлено ограничение на количество выполняемых операций ввода-вывода в секунду. Например, для виртуальной машины серии GS5 класса «Стандартный» установлено ограничение в 80 000 операций ввода-вывода в секунду.
Пропускная способность
Пропускная способность — это объем данных, которые приложение отправляет на диски хранилища в течение заданного интервала. Если приложение выполняет операции ввода-вывода большого объема, ему требуется высокая пропускная способность. Приложения хранилища данных зачастую выдают операции с активным сканированием, которые получают доступ к данным большого объема за раз, и часто выполняют массовые операции. Поэтому таким приложениям требуется более высокая пропускная способность. Для такого приложения необходимо разрабатывать инфраструктуру с учетом оптимизации пропускной способности. В следующем разделе подробно рассмотрены показатели, которые необходимо настроить, чтобы достичь этой цели.
При подключении диска хранилища класса "Премиум" к высокомасштабируемой виртуальной машине Azure подготавливает пропускную способность согласно спецификации диска. Например, диск P50 позволяет подготовить пропускную способность 250 МБ в секунду. Каждая высокомасштабируемая виртуальная машина также имеет установленное ограничение по пропускной способности. Например, максимальная пропускная способность виртуальной машины серии GS5 класса «Стандартный» составляет 2000 МБ в секунду.
Между пропускной способностью и количеством операций ввода-вывода в секунду существует связь, показанная в следующей формуле.
Поэтому для приложения очень важно определить оптимальное значение пропускной способности и количество операций ввода-вывода в секунду. Оптимизация одного из показателей обязательно повлияет на другой. В разделе Оптимизация производительности приложенияболее подробно рассмотрена оптимизация операций ввода-вывода и пропускной способности.
Задержка
Задержка — это время, необходимое приложению, чтобы получить один запрос, отправить его дискам хранилища, а затем отправить ответ клиенту. Наряду с количеством операций ввода-вывода в секунду и пропускной способностью этот показатель является критически важным для производительности приложения. Задержка на диске хранилища класса «Премиум» — это время, необходимое, чтобы извлечь информацию о запросе и передать ее приложению. Хранилище класса «Премиум» обеспечивает постоянно низкую задержку. Диски категории "Премиум" обеспечивают задержку в менее чем 10 миллисекунд для большинства операций ввода-вывода. Если включить кэширование узлов со значением ReadOnly на дисках хранилища класса «Премиум», это позволит сократить время задержки чтения. Более подробно кэширование дисков рассмотрено в разделе Кэширование диска.
При оптимизации приложения для повышения скорости выполнения операций ввода-вывода и увеличения пропускной способности время задержки приложения также меняется. После настройки производительности приложения во избежание значительных задержек необходимо всегда оценивать время задержки.
Для выполнения следующих операций уровня управления для Управляемых дисков может потребоваться перемещение диска из одного места хранения в другое. Это осуществляется путем копирования данных в фоновом режиме, что может занять несколько часов в зависимости от объема данных на дисках (обычно не более 24 часов). В течение этого времени ваше приложение может испытывать большую, чем обычно, задержку чтения, так как некоторые операции чтения могут быть перенаправлены в исходное местоположение, что потребует больше времени на их выполнение. В этот период нет влияния на задержку записи.
- Измените тип хранилища.
- Отсоедините диск от одной виртуальной машины и присоедините его к другой.
- Создайте управляемый диск на основе VHD.
- Создайте управляемый диск на основе моментального снимка.
- Преобразуйте неуправляемые диски в управляемые.
Контрольный список требований к производительности дисков
Во время разработки высокопроизводительных приложений, выполняющихся в хранилище Azure класса "Премиум", прежде всего необходимо понять, какие требования предъявляются к производительности приложения. Затем приложение можно оптимизировать исходя из этих требований, чтобы получить оптимальную производительность.
В предыдущем разделе описываются общие показатели производительности: количество операций ввода-вывода в секунду, пропускная способность и задержка. Чтобы предоставить необходимые возможности для пользователя, нужно определить, какие из этих показателей производительности критически важны для приложения. Например, высокая скорость выполнения операций ввода-вывода наиболее важна для приложений OLTP, обрабатывающих миллионы транзакций в секунду. Высокая пропускная способность, в свою очередь, критически важна для приложений хранилища данных, обрабатывающих большие объемы данных в секунду. Очень низкая задержка имеет решающее значение для приложений, выполняющихся в реальном времени, например веб-сайтов потоковой передачи видео.
Затем нужно определить максимальные требования к производительности приложения в течение его времени существования. В качестве начальной точки используйте пример контрольного списка ниже. Запишите максимальные требования к производительности при стандартной и пиковой рабочей нагрузке, а также рабочей нагрузке в нерабочее время. После определения требований для всех уровней рабочих нагрузок можно задать общее требование к производительности приложения. Например, стандартная рабочая нагрузка веб-сайта электронной коммерции — это объем транзакций, обрабатываемых на протяжении большинства дней в году. Пиковая рабочая нагрузка веб-сайта — это объем транзакций, обрабатываемых во время праздников или специальных периодов продаж. Пиковая рабочая нагрузка обычно наблюдается в течение ограниченного периода. Однако приложению при этом может потребоваться выполнять в несколько раз больше операций, чем в обычном режиме. Узнайте требования для 50-го, 90-го и 99-го процентилей. Таким образом можно отфильтровать все выбросы в требованиях к производительности и сосредоточиться на оптимизации на основе правильных значений.
Контрольный список требований к производительности приложений
| Требования к производительности | 50-й процентиль | 90-й процентиль | 99-й процентиль |
|---|---|---|---|
| Макс. Транзакций в секунду | |||
| Операции чтения, % | |||
| Операции записи, % | |||
| Случайные операции, % | |||
| Последовательные операции, % | |||
| Размер запроса ввода-вывода | |||
| Средняя пропускная способность | |||
| Макс. Пропускная способность | |||
| Мин. Задержка | |||
| Среднее время задержки | |||
| Макс. ЦП | |||
| Средняя загрузка ЦП | |||
| Макс. Память | |||
| Среднее использование памяти | |||
| Длина очереди |
Примечание
Эти показатели следует регулировать в зависимости от ожидаемого в будущем роста приложения. Рекомендуем подготовиться к росту приложения заранее, так как изменить инфраструктуру для повышения производительности позже будет сложнее.
Если требуется перейти от существующего приложения к хранилищу класса «Премиум», сначала заполните контрольный список выше для существующего приложения. Затем создайте прототип приложения в хранилище класса Premium и разработайте приложение в соответствии с рекомендациями, приведенными в разделе Оптимизация производительности приложения. В следующей статье описываются инструменты для сбора информации о показателях производительности.
Счетчики для оценки требований к производительности приложения
Оптимальным способом оценки требований к производительности приложения являются инструменты мониторинга производительности, содержащиеся в операционной системе сервера. Можно использовать PerfMon для Windows и iostat для Linux. Эти инструменты собирают данные со счетчиков по каждому показателю, описанному в предыдущем разделе. Следует записывать значения этих счетчиков для рабочих нагрузок приложения при стандартной, пиковой нагрузке и в нерабочее время.
Доступны счетчики PerfMon для процессора, памяти и каждого логического и физического диска сервера. При использовании дисков хранилища класса «Премиум» в виртуальной машине счетчики физических дисков собирают данные с каждого диска хранилища, а счетчики логических дисков — с каждого тома, созданного на диске хранилища. Необходимо записывать значения для дисков, на которых выполняется рабочая нагрузка приложения. Если логические и физические диски сопоставляются по типу «один к одному», нужно рассматривать значения счетчиков физических дисков. В противном случае следует обращать внимание на значения счетчиков логических дисков. В Linux при выполнении команды iostat создается отчет об использовании ЦП и дискового пространства. В отчете об использовании дискового пространства содержатся статистические данные для каждого физического устройства или раздела. Если данные и журнал сервера базы данных расположены на разных дисках, нужно собрать данные для обоих дисков. В таблице ниже описаны счетчики для дисков, процессоров и памяти.
| Счетчик | Описание | PerfMon | iostat |
|---|---|---|---|
| Количество операций ввода-вывода или транзакций в секунду | Количество запросов ввода-вывода, выдаваемых диску хранилища в секунду. | Операций чтения с диска в секунду Операций записи на диск в секунду |
tps r/s w/s |
| Количество операций чтения и записи на диске | Процент операций чтения и записи, выполняемых на диске. | Процент активности диска при чтении Процент активности диска при записи |
r/s w/s |
| Пропускная способность | Объем данных, считываемых с диска или записываемых на диск в секунду. | Скорость чтения с диска (байт/с) Скорость записи на диск (байт/с) |
КБ/с прочитано КБ/с записано |
| Задержка | Общее время завершения запроса ввода-вывода на диске. | Средняя скорость чтения с диска в секунду Средняя скорость записи на диск в секунду |
await svctm |
| Объем ввода-вывода | Объем запросов ввода-вывода, выданных дискам хранилища. | Средняя скорость чтения с диска (байт/с) Средняя скорость записи на диск (байт/с) |
avgrq-sz |
| Длина очереди | Количество необработанных запросов ввода-вывода, ожидающих чтения с диска хранилища или записи на диск хранилища. | Текущая длина очереди диска | avgqu-sz |
| Макс. Память | Объем памяти, необходимый для стабильной работы приложения | Использование выделенной памяти (в байтах), % | Использование vmstat |
| Макс. ЦП | Объем ЦП, необходимый для стабильной работы приложения | Загруженность процессора, % | %util |
См. дополнительные сведения об iostat и PerfMon.
Оптимизация производительности приложения
Основные факторы, влияющие на производительность приложения, которое работает с хранилищем класса Premium, — характер запросов ввода-вывода, размер виртуальной машины, размер диска, количество дисков, кэширование диска, многопоточность и длина очереди. Некоторыми из этих факторов можно управлять с помощью средств, предоставляемых системой. В большинстве приложений не предусмотрена возможность изменения объема операций ввода-вывода и длины очереди напрямую. Например, при использовании SQL Server нельзя выбрать значения этих показателей. SQL Server выбирает оптимальные значения объема операций ввода-вывода и длины очереди для получения лучшей производительности. Важно понимать, какое влияние оба показателя оказывают на производительность приложения, чтобы выделить объем ресурсов в соответствии с потребностями в производительности.
Определить нужный уровень оптимизации производительности приложения можно с помощью созданного ранее контрольного списка требований приложения. Исходя из этого, можно определить, какие показатели из этого раздела необходимо настроить. Чтобы убедиться во влиянии каждого из показателей на производительность приложения, запустите инструменты тестирования производительности на установленном приложении. Шаги, необходимые для запуска общих инструментов тестирования производительности в виртуальных машинах Windows и Linux, см. в статье "Измерение производительности", ссылка на которую приведена в конце этой статьи.
Краткий обзор оптимизации операций ввода-вывода, пропускной способности и задержки
В таблице ниже приведена сводка факторов, влияющих на производительность, и шагов по оптимизации операций ввода-вывода, пропускной способности и задержки. В разделах, приведенных после этой сводки, каждый из них описывается гораздо более подробно.
Дополнительные сведения о размерах виртуальных машин, операциях ввода-вывода в секунду, пропускной способности и задержке, доступных для каждого типа виртуальной машины, см. в статье Размеры виртуальных машин в Azure.
| ОПЕРАЦИЙ ВВОДА-ВЫВОДА | Пропускная способность | Задержка | |
|---|---|---|---|
| Пример сценария | Корпоративное приложение OLTP, которому требуется высокая скорость выполнения транзакций в секунду. | Корпоративное приложение хранилища данных, обрабатывающее большие объемы данных. | Приложения, которые выполняются практически в реальном времени и требуют мгновенных ответов на запросы пользователей, например игры в сети. |
| Факторы производительности | |||
| Объем ввода-вывода | Меньший объем ввода-вывода обеспечивает более высокую скорость выполнения операций ввода-вывода. | Больший объем ввода-вывода обеспечивает более высокую пропускную способность. | |
| Размер виртуальной машины | Используйте размер виртуальной машины, который обеспечивает более высокую скорость выполнения операций ввода-вывода, чем указано в требованиях приложения. | Используйте размер виртуальной машины с большей пропускной способностью, чем требует приложение. | Используйте размер виртуальной машины с более широкими пределами масштабируемости, чем требует приложение. |
| Размер диска | Используйте размер диска, который обеспечивает более высокую скорость выполнения операций ввода-вывода, чем требует приложение. | Используйте размер диска с более высокой пропускной способностью, чем требует приложение. | Используйте размер диска с более широкими пределами масштабируемости, чем требует приложение. |
| Ограничения масштабируемости виртуальной машины и диска | Ограничение количества операций ввода-вывода в секунду для выбранного размера виртуальной машины должно быть больше общего количества операций ввода-вывода в секунду, выполняемых на дисках хранилища, подключенных к виртуальной машине. | Ограничение пропускной способности для выбранного размера виртуальной машины должно быть больше общей пропускной способности дисков хранилища класса «Премиум», подключенных к виртуальной машине. | Ограничение масштабируемости для выбранного размера виртуальной машины должно быть больше общего ограничения масштабируемости подключенных дисков хранилища класса «Премиум». |
| Кэширование диска | Включите кэш со значением ReadOnly на дисках хранилища класса «Премиум» с большим объемом операций чтения, чтобы повысить скорость выполнения операций ввода-вывода при чтении. | Включите кэш со значением ReadOnly на дисках хранилища класса «Премиум» с большим объемом операций чтения, чтобы сократить время задержки при чтении до минимума. | |
| Чередование дисков | Используйте несколько дисков и чередуйте их, чтобы повысить общее ограничение количества операций ввода-вывода и пропускной способности. Общее ограничение для каждой виртуальной машины должно быть выше, чем сумма ограничений для подключенных дисков категории "Премиум". | ||
| Размер блока чередования | Меньший размер блока чередования для случайных небольших запросов ввода-вывода в приложениях OLTP. Например, для приложения OLTP SQL Server можно использовать размер блока чередования 64 КБ. | Больший размер блока чередования для последовательных объемных запросов ввода-вывода в приложениях хранилища данных. Например, для приложения хранилища данных SQL Server можно использовать размер блока чередования 256 КБ. | |
| Многопоточность | Используйте многопоточность для передачи большего количества запросов хранилищу класса «Премиум». Это позволит увеличить скорость выполнения операций ввода-вывода и повысить пропускную способность. Например, укажите наибольшее значение для параметра MAXDOP на сервере SQL Server, чтобы выделить дополнительные ЦП для SQL Server. | ||
| Длина очереди | Более длинная очередь обеспечивает более высокую скорость выполнения операций ввода-вывода. | Более длинная очередь обеспечивает более высокую пропускную способность. | Более короткая очередь сокращает время задержки. |
Характер запросов ввода-вывода
Запрос ввода-вывода — это единица операции ввода-вывода, которую будет выполнять приложение. Определив характер запроса ввода-вывода (случайный или последовательный, чтение или запись, большого или небольшого размера), можно определить требования к производительности приложения. Важно понимать характер запросов ввода-вывода, чтобы правильно принимать решения при разработке инфраструктуры приложения. Для достижения наилучшей производительности операции ввода-вывода должны быть распределены равномерно.
Один из наиболее важных факторов — объем ввода-вывода. Это объем запроса на операцию ввода-вывода, созданного приложением. Объем ввода-вывода оказывает существенное влияние на производительность, особенно на показатели количества операций ввода-вывода и пропускной способности, которых может достигнуть приложение. Следующая формула демонстрирует взаимосвязь между количеством операций ввода-вывода в секунду, объемом ввода-вывода и пропускной способностью.
В одних приложениях можно изменять объем ввода-вывода, а в других — нет. Например, SQL Server определяет оптимальный объем ввода-вывода и не предоставляет пользователям никаких средств для его изменения. Oracle, в свою очередь, предоставляет параметр DB_BLOCK_SIZE, с помощью которого можно настроить размер запроса ввода-вывода базы данных.
При использовании приложения, в котором нельзя изменять объем ввода-вывода, следуйте приведенным здесь рекомендациям для оптимизации ключевых показателей эффективности для производительности, необходимых приложению. Например,
- Приложения OLTP генерируют миллионы небольших случайных запросов ввода-вывода. Для обработки таких запросов необходимо разработать инфраструктуру приложения таким образом, чтобы обеспечить высокую скорость выполнения операций ввода-вывода.
- Приложения хранилища данных генерируют крупные последовательные запросы ввода-вывода. Для обработки таких запросов необходимо разработать инфраструктуру приложения таким образом, чтобы обеспечить высокую пропускную способность.
При использовании приложения, в котором можно изменять объем ввода-вывода, помимо других указаний для производительности, рекомендуем применять следующие принципы в отношении объема ввода-вывода.
- Меньший объем ввода-вывода обеспечивает более высокую скорость выполнения операций ввода-вывода. Например, 8 КБ для приложения OLTP.
- Больший объем ввода-вывода обеспечивает более высокую пропускную способность. Например, 1024 КБ для приложения хранилища данных.
Приведенный ниже пример поможет рассчитать количество операций ввода-вывода в секунду и пропускную способность для приложения. Рассмотрим приложение, использующее диск P30. Максимальное количество операций ввода-вывода в секунду и максимальная пропускная способность диска P30 — 5000 операций ввода-вывода и 200 МБ в секунду соответственно. Если с приложением, которому требуется максимальное количество операций ввода-вывода диска P30, использовать меньший объем ввода-вывода, например 8 КБ, пропускная способность, которой можно будет добиться, составит 40 МБ в секунду. Однако, если с приложением, которому требуется максимальная пропускная способность диска P30, использовать больший объем операций ввода-вывода, например 1024 КБ, количество операций ввода-вывода в секунду, которого можно будет добиться, сократится до 200. Таким образом, объем ввода-вывода следует настраивать в соответствии с требованиями приложения к количеству операций ввода-вывода в секунду и пропускной способности. В следующей таблице приведены разные объемы ввода-вывода и соответствующее количество операций ввода-вывода в секунду, а также показатели пропускной способности для диска P30.
| Требование к приложению | Объем ввода-вывода | ОПЕРАЦИЙ ВВОДА-ВЫВОДА | Пропускная способность |
|---|---|---|---|
| Maкс. количество операций ввода-вывода в секунду | 8 КБ | 5 000 | 40 МБ в секунду |
| Макс. пропускная способность | 1024 КБ | 200 | 200 МБ в секунду |
| Макс. пропускная способность и высокая скорость выполнения операций ввода-вывода | 64 КБ | 3200 | 200 МБ в секунду |
| Макс. скорость выполнения операций ввода-вывода и высокая пропускная способность | 32 КБ | 5 000 | 160 МБ в секунду |
Для получения более высокой скорости выполнения операций ввода-вывода и пропускной способности, чем максимальное значение для одного диска хранилища класса «Премиум», чередуйте несколько дисков класса «Премиум». Например, чередуйте два диска P30, чтобы получить объединенную скорость выполнения операций ввода-вывода (10 000 операций ввода-вывода в секунду) или объединенную пропускную способность (400 МБ в секунду). Необходимо использовать размер виртуальной машины, который поддерживает объединенную скорость выполнения операций ввода-вывода и пропускную способность дисков, как описано в следующем разделе.
Примечание
При увеличении скорости выполнения операций ввода-вывода или пропускной способности другой показатель также увеличивается. Поэтому, увеличивая один из показателей, убедитесь, что не достигнуто ограничение пропускной способности или скорости выполнения операций ввода-вывода диска или виртуальной машины.
Чтобы убедиться во влиянии объема ввода-вывода на производительность приложения, можно запустить инструменты тестирования производительности на виртуальной машине и дисках. Выполните несколько тестовых запусков и используйте для каждого из них разный объем ввода-вывода, чтобы увидеть влияние. Дополнительные сведения см. в статье "Измерение производительности", ссылка на которую приведена в конце этой статьи.
Размеры высокомасштабируемых виртуальных машин
При разработке приложения нужно в первую очередь выбрать виртуальную машину для размещения приложения. Хранилище класса «Премиум» предусматривает использование высокомасштабируемых виртуальных машин, на которых могут выполняться приложения, требующие высокой вычислительной мощности и повышенной производительности операций ввода-вывода локального диска. Эти виртуальные машины отличаются более быстрыми процессорами, более высоким соотношением «память — ядро» и использованием твердотельного накопителя (SSD) в качестве локального диска. Примерами высокомасштабируемых виртуальных машин с поддержкой хранилища класса Premium являются виртуальные машины серий DS и GS.
Доступны высокомасштабируемые виртуальные машины различных размеров с разным количеством ядер ЦП, объемом памяти, операционными системами и размером временного диска. Для каждого размера виртуальной машины также установлено максимальное количество дисков данных, которые можно подключить к виртуальной машине. Таким образом, выбранный размер виртуальной машины влияет на мощность обработки, объем памяти и хранилища, которые доступны для приложения. Он также влияет на затраты на вычисление и хранение. Например, ниже представлены спецификации виртуальной машины максимального размера серий DS и GS:
| Размер виртуальной машины | Ядра ЦП | Память | Размеры диска виртуальной машины | Макс. количество дисков данных | Объем кэша | ОПЕРАЦИЙ ВВОДА-ВЫВОДА | Ограничения количества операций ввода-вывода в секунду и пропускной способности кэша |
|---|---|---|---|---|---|---|---|
| Standard_DS14 | 16 | 112 ГБ | ОС = 1023 ГБ Локальный SSD = 224 ГБ |
32 | 576 ГБ | 50 000 операций ввода-вывода в секунду 512 МБ в секунду |
4000 операций ввода-вывода в секунду и 33 МБ в секунду |
| Standard_GS5 | 32 | 448 ГБ | ОС = 1023 ГБ Локальный SSD = 896 ГБ |
64 | 4224 ГБ | 80 000 операций ввода-вывода в секунду 2000 МБ в секунду |
5000 операций ввода-вывода в секунду и 50 МБ в секунду |
Полный список всех доступных размеров виртуальных машин Azure см. в статье Размеры виртуальных машин в Azure. Выберите размер виртуальной машины, который позволяет выполнять масштабирование в соответствии с требованиями к производительности приложения. Помимо этого, при выборе размеров виртуальной машины необходимо учитывать следующие важные аспекты.
Ограничения масштабирования
Максимальные ограничения операций ввода-вывода в секунду на виртуальную машину и на диск различаются и не зависят друг от друга. Убедитесь, что количество операций ввода-вывода в секунду, выполняемое приложением и подключенными к нему дисками класса «Премиум», находится в пределах ограничений виртуальной машины. В противном случае производительность приложения нужно будет отрегулировать.
В качестве примера предположим, что максимальное количество операций ввода-вывода в секунду для приложения составляет 4000. Для достижения этого показателя на виртуальной машине DS1 необходимо подготовить диск P30. Диск P30 может выполнять до 5000 операций ввода-вывода в секунду. Но виртуальная машина DS1 может выполнять не более 3200 операций ввода-вывода в секунду. Следовательно, приложение также ограничивается 3200 операциями ввода-вывода в секунду и демонстрирует сниженную производительность. Во избежание этого выберите размеры диска и виртуальной машины, соответствующие требованиям приложения.
Стоимость выполнения операций
Во многих случаях общая стоимость выполнения операций с использованием хранилища класса «Премиум» может быть меньше, чем при использовании хранилища класса «Стандартный».
В качестве примера рассмотрим приложение, требующее выполнения 16 000 операций ввода-вывода в секунду. Для достижения такой производительности потребуется виртуальная машина IaaS Azure Standard_D14, которая выполняет до 16 000 операций ввода-вывода в секунду, используя 32 диска стандартного хранилища емкостью 1 ТБ. Каждый диск стандартного хранилища емкостью 1 ТБ может выполнять до 500 операций ввода-вывода в секунду. Оценочная стоимость этой виртуальной машины в месяц составляет 1570 долл. США. Ежемесячная стоимость 32 дисков хранилища класса «Стандартный» составляет 1638 долл. США. Оценочная общая ежемесячная стоимость составляет 3208 долл. США.
Однако если разместить то же самое приложение в хранилище класса «Премиум», понадобится меньший размер виртуальной машины и меньшее количество дисков хранилища класса «Премиум», что уменьшит общую стоимость. Виртуальная машина Standard_DS13 может выполнять 16 000 операций ввода-вывода в секунду, используя четыре диска P30. Виртуальная машина DS13 выполняет до 25 600 операций ввода-вывода в секунду, а каждый диск P30 — до 5000. В целом, при такой конфигурации можно добиться 20 000 операций ввода-вывода в секунду (5000 x 4). Оценочная стоимость этой виртуальной машины в месяц составляет 1003 долл. США. Ежемесячная стоимость четырех дисков хранилища класса «Премиум» P30 составляет 544,34 долл. США. Оценочная общая ежемесячная стоимость составляет 1544 долл. США.
В следующей таблице представлены затраты по этому сценарию при использовании хранилища класса «Стандартный» и «Премиум».
| Standard Edition | Премиальный | |
|---|---|---|
| Стоимость виртуальной машины в месяц | 1570,58 долл. США (Standard_D14) | 1003,66 долл. США (Standard_DS13) |
| Стоимость дисков в месяц | 1638,40 долл. США (32 диска емкостью по 1 ТБ) | 544,34 долл. США (4 диска P30) |
| Общая стоимость в месяц | 3208,98 долл. США | 1544,34 долл. США |
Дистрибутивы Linux
Используя службу хранилища Azure категории "Премиум", можно добиться одинакового уровня производительности виртуальных машин под управлением Windows и Linux. Поддерживаются различные дистрибутивы Linux. Дополнительные сведения см. в статье Linux в Azure — рекомендованные дистрибутивы. Следует отметить, что для различных типов рабочих нагрузок подходят различные дистрибутивы. Каждый дистрибутив, используемый для рабочей нагрузки, обеспечивает разный уровень производительности. Протестируйте дистрибутивы Linux для приложения и выберите наиболее подходящий вариант.
При использовании хранилища класса «Премиум» под управлением Linux следует проверить последние обновления драйверов, необходимых для обеспечения высокой производительности.
Размеры дисков хранилища класса "Премиум"
Хранилище Azure класса Premium предоставляет разные размеры, из которых можно выбрать оптимальный для ваших нужд. Для диска каждого размера установлены разные ограничения масштабирования для операций ввода-вывода в секунду, пропускной способности и хранилища. Выберите диск хранилища класса «Премиум» правильного размера в соответствии с требованиями приложения и размером высокомасштабируемой виртуальной машины. В следующей таблице представлены размеры и возможности дисков. Размеры P4, P6, P15, P60, P70 и P80 сейчас поддерживаются только на управляемых дисках.
| Размеры дисков SSD (цен. категория "Премиум") | P1 | P2 | P3 | P4 | P6 | P10 | P15 | P20 | P30 | P40 | P50 | P60 | P70 | P80 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Размер диска (ГиБ) | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1024 | 2048 | 4096 | 8192 | 16 384 | 32 767 |
| Базовое подготовленное число операций ввода-вывода в секунду на диск | 120 | 120 | 120 | 120 | 240 | 500 | 1100 | 2300 | 5 000 | 7500 | 7500 | 16 000 | 18 000 | 20 000 |
| **Расширенные подготовленные операции ввода-вывода в секунду на диск | Н/Д | Н/Д | Н/Д | Н/Д | Н/Д | Н/Д | Н/Д | Н/Д | 8000 | 16 000 | 20 000 | 20 000 | 20 000 | 20 000 |
| Базовая подготовленная пропускная способность на диск | 25 МБ/с | 25 МБ/с | 25 МБ/с | 25 МБ/с | 50 МБ/с | 100 МБ/с | 125 МБ/с | 150 МБ/с | 200 МБ/с | 250 МБ/с | 250 МБ/с | 500 МБ/с | 750 МБ/с | 900 МБ/с |
| **Расширенная подготовленная пропускная способность на диск | Н/Д | Н/Д | Н/Д | Н/Д | Н/Д | Н/Д | Н/Д | Н/Д | 300 МБ/с | 600 МБ/с | 900 МБ/с | 900 МБ/с | 900 МБ/с | 900 МБ/с |
| Максимальное пиковое число операций ввода-вывода в секунду на диск | 3500 | 3500 | 3500 | 3500 | 3500 | 3500 | 3500 | 3500 | 30 000 * | 30 000 * | 30 000 * | 30 000 * | 30 000 * | 30 000 * |
| Максимальная пиковая пропускная способность на диск | 170 МБ/с | 170 МБ/с | 170 МБ/с | 170 МБ/с | 170 МБ/с | 170 МБ/с | 170 МБ/с | 170 МБ/с | 1000 МБ/с* | 1000 МБ/с* | 1000 МБ/с* | 1000 МБ/с* | 1000 МБ/с* | 1000 МБ/с* |
| Максимальная длительность пика | 30 мин | 30 мин | 30 мин | 30 мин | 30 мин | 30 мин | 30 мин | 30 мин | Без ограничений | Без ограничений | Без ограничений | Без ограничений | Без ограничений | Без ограничений |
| Подходит для резервирования | Нет | Нет | Нет | Нет | Нет | Нет | Нет | Нет | Да, до одного года | Да, до одного года | Да, до одного года | Да, до одного года | Да, до одного года | Да, до одного года |
* Применяется только к дискам с включенным ускорением по запросу.
** Применяется только к дискам с включенной производительностью плюс (предварительная версия).
Выбор количества дисков зависит от выбранного размера диска. Для удовлетворения требований приложения можно использовать один диск P50 или несколько дисков P10. Выбирая размер диска, учитывайте приведенные ниже рекомендации.
Ограничения масштабирования (на количество операций ввода-вывода в секунду и пропускную способность)
Ограничения на количество операций ввода-вывода в секунду и пропускную способность для каждого размера диска класса "Премиум" различаются и не зависят от ограничений масштабирования виртуальной машины. Убедитесь, что общее количество операций ввода-вывода в секунду и пропускная способность дисков не превышают установленные ограничения масштабирования выбранного размера виртуальной машины.
Например, рассмотрим, как следует поступить, если используется виртуальная машина DS4 с одним диском P30, а максимальная пропускная способность приложения составляет не более 250 МБ/с. Максимальная пропускная способность виртуальной машины DS4 — 256 МБ/с. У одного диска P30 установлено ограничение пропускной способности на уровне 200 МБ/с. Следовательно, из-за ограничений диска пропускная способность приложения будет равна 200 МБ/с. Чтобы устранить эту проблему, для виртуальной машины необходимо подготовить несколько дисков данных либо изменить размер дисков на P40 или P50.
Примечание
Операции чтения, обрабатываемые с помощью кэша, не относятся к операциям ввода-вывода и пропускной способности диска, поэтому ограничения диска на них не распространяются. Для кэша существует отдельное ограничение на количество операций ввода-вывода в секунду и пропускную способность для каждой виртуальной машины.
Например, изначально пропускная способность операций чтения и записи составляет 60 МБ/с и 40 МБ/с соответственно. Со временем кэш подготавливает и выполняет все больше операций чтения. В дальнейшем можно добиться более высокой пропускной способности операций записи с диска.
Количество дисков
Определите необходимое количество дисков на основе оценки требований приложения. Для каждого размера виртуальной машины также установлено ограничение на количество дисков, которые можно подключить. Как правило, это количество в два раза превышает количество ядер. Убедитесь, что выбранный размер виртуальной машины поддерживает необходимое количество дисков.
Помните, что диски хранилища класса «Премиум» обеспечивают более высокую производительность по сравнению с дисками хранилища класса «Стандартный». Таким образом, при переходе с использования для приложения виртуальной машины IaaS Azure хранилища класса «Стандартный» на хранилище класса «Премиум», скорее всего, для достижения того же или более высокого уровня производительности приложения потребуется меньшее количество дисков класса «Премиум».
Кэширование диска
В высокомасштабируемых виртуальных машинах, которые используют хранилище Azure класса «Премиум», применяется технология многоуровневого кэширования под названием BlobCache. BlobCache использует для кэширования сочетание ОЗУ виртуальной машины и локального SSD. Это кэширование доступно для постоянных дисков хранилища класса «Премиум» и локальных дисков виртуальной машины. По умолчанию для параметра кэширования задано значение Read/Write для дисков операционной системы и ReadOnly для дисков данных, размещенных в хранилище класса «Премиум». Если активировать функцию кэширования диска для дисков хранилища класса «Премиум», можно добиться чрезвычайно высокого уровня производительности высокомасштабируемых виртуальных машин, который превысит базовый уровень производительности диска.
Предупреждение
Кэширование диска не поддерживается для дисков размером 4 ТиБ и более. Если к виртуальной машине подключено несколько дисков, то кэширование применяется ко всем дискам, размер которых меньше 4 ТиБ.
При изменении параметра кэша диска Azure целевой диск отключается, а затем вновь подключается к виртуальной машине. Если это диск операционной системы, то виртуальная машина перезагрузится. Остановите все приложения и службы, работу которых может нарушить это событие, прежде чем изменять параметр кэша диска. Несоблюдение этих рекомендаций может привести к повреждению данных.
Дополнительные сведения о работе BlobCache см. в записи блога Хранилища Azure класса "Премиум".
Очень важно включить кэширование для правильного набора дисков. Необходимость включения функции кэширования диска для диска класса «Премиум» зависит от шаблона рабочей нагрузки, которую будет обрабатывать этот диск. В следующей таблице приведены параметры кэширования по умолчанию для дисков операционной системы и дисков данных.
| Тип диска | Параметр кэширования по умолчанию |
|---|---|
| Диск ОС | ReadWrite |
| Диск данных | ReadOnly |
Ниже приведены рекомендуемые параметры кэширования диска для дисков данных
| Параметр кэширования диска | Рекомендации по использованию этого параметра |
|---|---|
| None | Задайте для кэша узла значение None для дисков с высокой интенсивностью операций записи и дисков только для записи. |
| ReadOnly | Задайте для кэша узла значение ReadOnly для дисков, которые используются для чтения и записи или только для чтения. |
| ReadWrite | Задайте для кэша узла значение ReadWrite, только если приложение правильно обрабатывает операции записи кэшированных данных на постоянные диски. |
ReadOnly
Задав для кэширования значение ReadOnly для дисков данных хранилища класса «Премиум», можно достичь низкой задержки операций чтения и очень высокой скорости выполнения операций ввода-вывода и пропускной способности при чтении для приложения. Это происходит по двум причинам.
- Выполнение операций чтения из кэша, который находится в памяти виртуальной машины и локального SSD, происходит намного быстрее, чем выполнение операций чтения с диска данных, который находится в хранилище BLOB-объектов Azure.
- В хранилище класса «Премиум» операции чтения, выполненные из кэша, не относятся к операциям ввода-вывода и пропускной способности диска. Таким образом, приложение может выполнять больше операций ввода-вывода и достичь высокой пропускной способности.
ReadWrite
На дисках операционной системы по умолчанию задано значение кэширования ReadWrite. Более того, с недавнего времени значение кэширования ReadWrite можно задать и для дисков данных. При использовании значения кэширования ReadWrite необходимо использовать правильный способ записи данных из кэша на постоянные диски. Например, SQL Server обрабатывает операции записи кэшированных данных на постоянные диски хранилища самостоятельно. Использование значения кэширования ReadWrite для приложения, которое не обеспечивает сохранение необходимых данных, может привести к потере данных в случае сбоя виртуальной машины.
None
В настоящее время вариант None (Нет) поддерживается только для дисков данных. Этот вариант не поддерживается для дисков ОС. Если вы укажете None для диска ОС, система переопределит это значение и будет использовать вариант ReadOnly (Только для чтения).
Эти рекомендации можно применить для запуска SQL Server в хранилище класса «Премиум». Для этого нужно сделать следующее.
- Задайте для кэша значение ReadOnly для дисков хранилища уровня "Премиум", на которых размещены файлы данных.
а. Благодаря быстрому выполнению операций чтения из кэша уменьшается время обработки запроса SQL Server, так как страницы данных извлекаются из кэша гораздо быстрее, чем непосредственно с дисков данных.
b. Если операции чтения выполняются из кэша, это означает, что диски с данными класса «Премиум» дают дополнительную пропускную способность. Ее можно использовать на SQL Server для извлечения большего количества страниц данных и выполнения других операций, таких как резервное копирование и восстановление, пакетные загрузки и перестройки индекса. - Задайте для кэша значение None для дисков хранилища уровня "Премиум", на которых размещены файлы журнала.
а. В файлах журнала преимущественно содержатся данные операций с высокой интенсивностью записи. Поэтому на них никак не влияет использование кэша со значением ReadOnly.
Оптимизация производительности на виртуальных машинах под управлением Linux
Для всех дисков SSD категорий "Премиум" и "Ультра" вы можете отключать "барьеры" файловых систем, что позволяет повысить производительность в тех случаях, когда гарантированно не выполняется кэширование, которое может привести к потере данных. Если для кэширования дисков Azure задано значение "Только для чтения" или "Нет", барьеры можно отключить. Но если для кэширования задано значение "Чтение и запись", то барьеры должны оставаться включенными для устойчивости записи. Обычно барьеры по умолчанию включены, но вы можете их отключить одним из следующих методов в зависимости от типа файловой системы.
- Для reiserFS укажите параметр подключения barrier=none. Чтобы явно включить барьеры, укажите barrier=flush.
- Для ext3/ext4 укажите параметр подключения barrier=0. Чтобы явно включить барьеры, укажите barrier=1.
- Для XFS укажите параметр подключения nobarrier. Чтобы явно включить барьеры, укажите barrier. Начиная с версии 4.10 ядра Linux, структура файловой системы XFS всегда гарантирует устойчивость. Отключение барьеров не оказывает никакого влияния, и параметр "nobarrier" является нерекомендуемым. Но некоторые дистрибутивы Linux могли перенести изменения в выпуск дистрибутива с более ранней версией ядра, уточните у поставщика вашего дистрибутива состояние дистрибутива и версию, которую вы используете.
Чередование дисков
Если к высокомасштабируемой виртуальной машине подключены несколько постоянных дисков хранилища класса «Премиум», диски можно чередовать для объединения операций ввода-вывода, пропускной способности и объема хранилища.
Для чередования дисков в операционной системе Windows можно использовать дисковое пространство. Для каждого диска в пуле необходимо настроить один столбец. В противном случае общая производительность чередующегося тома может быть ниже ожидаемой из-за неравномерного распределения трафика между дисками.
Важно! С помощью пользовательского интерфейса диспетчера сервера для чередующегося тома можно задать 8 столбцов. При подключении более восьми дисков используйте PowerShell для создания тома. С помощью PowerShell можно задать такое же количество столбцов, как и количество дисков. Например, если в одном чередующемся наборе 16 дисков, укажите 16 столбцов для параметра NumberOfColumns командлета PowerShell New-VirtualDisk.
В операционной системе Linux для чередования дисков используйте программу MDADM. Подробные инструкции по чередованию дисков в Linux см. в статье Настройка программного RAID-массива в Linux.
Размер блока чередования
При чередовании дисков размер блока чередования имеет большое значение. Размер блока чередования или размер блока — это наименьший фрагмент данных, к которым может обратиться приложение в чередующемся томе. Настраиваемый размер блока чередования зависит от типа приложения и шаблона запроса. Выбор неправильного размера блока чередования может привести к рассогласованию ввода-вывода, что, в свою очередь, влечет снижение производительности приложения.
Например, если размер созданного приложением запроса ввода-вывода больше размера блока чередования диска, система хранения запишет его на несколько дисков, выходя за пределы границ чередующейся единицы. При доступе к этим данным для выполнения запроса поиск будет осуществляться в нескольких чередующихся единицах. В результате производительность может существенно снизиться. Если же размер запроса ввода-вывода меньше размера блока чередования и сам запрос является случайным, запросы ввода-вывода будут добавляться на один и тот же диск. Как следствие, диск переполнится, что в конечном счете приведет к снижению производительности ввода-вывода.
Выберите подходящий размер блока чередования в зависимости от типа рабочей нагрузки приложения. Для случайных небольших запросов ввода-вывода следует использовать меньший размер блока чередования, а для больших последовательных запросов ввода-вывода — более крупный размер блока чередования. Узнайте больше о рекомендациях по размеру блока чередования для приложения, которое будет запущено в хранилище класса «Премиум». Для SQL Server настройте следующий размер блока чередования: 64 КБ для рабочих нагрузок OLTP или 256 КБ для рабочих нагрузок хранилища данных. в статье Рекомендации по оптимизации производительности SQL Server на виртуальных машинах Azure .
Примечание
На виртуальной машине серии DS можно чередовать до 32 дисков хранилища класса «Премиум», а на виртуальной машине серии GS — до 64 дисков хранилища класса «Премиум».
Многопоточность
Платформа хранилища класса «Премиум» предназначена для массовой параллельной обработки. Так, многопоточное приложение обеспечивает более высокую производительность по сравнению с однопоточным приложением. Многопоточное приложение распределяет задачи между несколькими потоками, увеличивая эффективность их выполнения за счет максимального использования ресурсов виртуальной машины и диска.
Например, если приложение запущено на одноядерной виртуальной машине с использованием двух потоков, для увеличения эффективности ЦП может переключаться между двумя потоками. В то время как один поток ожидает завершения дисковой операции ввода-вывода, ЦП может переключиться на другой поток. Таким образом, используя два потока, можно выполнить намного больше задач, чем с использованием одного. Если у виртуальной машины несколько ядер, для выполнения задач требуется меньше времени, так как каждое ядро может выполнять задачи одновременно.
Способ осуществления однопоточной или многопоточной обработки в готовом приложении изменить невозможно. Например, SQL Server может выполнять задачи, используя несколько процессоров и ядер. Однако способ обработки запроса SQL Server (с использованием одного или нескольких потоков) зависит от определенных условий. С использованием многопоточности на этом сервере можно выполнять запросы и создавать индексы. Для обработки запроса, который включает в себя объединение таблиц с большим объемом информации и сортировку данных перед возвращением пользователю, SQL Server, скорее всего, воспользуется несколькими потоками. Пользователь не может управлять тем, каким образом SQL Server будет обрабатывать запрос — с использованием одного потока или нескольких.
Чтобы повлиять на многопоточность или параллельную обработку приложения, можно изменить некоторые параметры конфигурации. Например, в случае с SQL Server используется конфигурация максимальной степени параллелизма. С помощью параметра MAXDOP возможна настройка максимального количества процессоров, которые может использовать SQL Server при параллельной обработке. Этот параметр можно настроить для отдельных запросов и операций с индексами. Такая настройка полезна, если необходимо сбалансировать ресурсы системы для приложений, в работе которых производительность играет критически важную роль.
Например, допустим, приложение, которое использует SQL Server, одновременно выполняет запрос большого размера и индексирование. Предположим также, что необходимо, чтобы индексирование выполнялось с более высоким уровнем производительности, чем запрос большого размера. В таком случае для индексирования можно задать более высокое значение MAXDOP, чем для запроса. Тогда SQL Server сможет использовать больше процессоров для индексирования, чем он может выделить для запроса большого размера. Помните, что количество потоков, которые SQL Server будет использовать для каждой операции, не подлежит управлению. Но можно управлять максимальным количеством процессоров, выделяемых для нескольких потоков.
Дополнительные сведения см. в статье Степень параллелизма в документации по SQL Server. Узнайте, какие параметры влияют на многопоточность в приложении и какие значения этих параметров являются оптимальными для обеспечения производительности.
Длина очереди
Длина, глубина или размер очереди — это количество ожидающих запросов ввода-вывода в системе. Значение длины очереди позволяет определить, сколько операций ввода-вывода приложение может поместить в очередь для их обработки дисками хранилища. Это значение влияет на все три показателя производительности приложения, которые рассматриваются в этой статье, а именно на операции ввода-вывода, пропускную способность и задержку.
Длина очереди и многопоточность тесно связаны. Значение длины очереди указывает, насколько многопоточным может быть приложение. Чем длиннее очередь, тем больше одновременных операций может выполнять приложение. Другими словами, оно может выполнять больше потоков. Если длина очереди небольшая, даже многопоточное приложение не поместити в очередь достаточно запросов для параллельного выполнения.
Обычно в готовых приложениях нельзя менять длину очереди, ведь если задать неправильное значение, это принесет больше вреда, чем пользы. В приложениях задается правильное значение длины очереди для достижения оптимальной производительности. Тем не менее важно понимать, как это происходит, чтобы иметь возможность устранять проблемы с производительностью. Кроме того, можно убедиться во влиянии длины очереди, запустив инструменты тестирования производительности в своей системе.
В некоторых приложениях доступны параметры, с помощью которых можно повлиять на длину очереди. Например, MAXDOP (параметр максимальной степени параллелизма) в SQL Server, описанный в предыдущем разделе. MAXDOP позволяет повлиять на длину очереди и многопоточность, но не меняет значение длины очереди SQL Server напрямую.
Высокое значение длины очереди
Благодаря высокому значению длины в очередь на диске помещается больше операций. Диску заранее известен следующий запрос очереди. Следовательно, операции на диске могут планироваться заранее и он может обрабатывать их в оптимальной последовательности. Так как приложение отправляет на диск больше запросов, диск может обрабатывать больше параллельных операций ввода-вывода. В результате приложение сможет выполнять больше операций ввода-вывода в секунду. Обработка большего количества запросов также приводит к увеличению общей пропускной способности приложения.
Как правило, приложение может достигать максимальной пропускной способности при наличии 8–16 и более ожидающих выполнения операций ввода-вывода на подключенный диск. Если задать для длины очереди значение "1", приложение не будет отправлять достаточно операций ввода-вывода в систему и, следовательно, будет обрабатывать меньше операций за указанный период. Другими словами, пропускная способность будет меньше.
Например, значение "4" для параметра MAXDOP запроса в SQL Server указывает на то, что для выполнения запроса можно использовать до четырех ядер. SQL Server определит оптимальное значение длины очереди и количество ядер для выполнения запроса.
Оптимальная длина очереди
Использование очень высокого значения длины очереди также имеет свои недостатки. При таком значении приложение будет пытаться выполнить очень много операций ввода-вывода в секунду. Если приложение использует непостоянные диски с недостаточным количеством подготовленных операций ввода-вывода в секунду, это может отрицательно повлиять на задержку. Следующая формула демонстрирует взаимосвязь между количеством операций ввода-вывода в секунду, значением задержки и длиной очереди.
Для длины очереди не следует задавать высокое значение. Ее значение должно быть оптимальным и обеспечивать выполнение достаточного количества операций ввода-вывода в секунду для приложения, не влияя на задержку. Например, если задержка приложения должна составлять 1 миллисекунду, у длины очереди, необходимой для выполнения 5000 операций ввода-вывода в секунду, должно быть значение «5» (5000 x 0,001 = 5).
Длина очереди чередующегося тома
Для чередующегося тома следует использовать достаточно высокое значение длины очереди, чтобы у каждого диска было отдельное значение максимальной длины очереди. Например, рассмотрим приложение, которое отправляет запросы в очередь со значением длины "2", при этом в блоке чередования находится четыре диска. В таком случае два запроса ввода-вывода будут отправляться на два диска, а остальные два диска будут простаивать. Поэтому настройте длину очереди так, чтобы диски не простаивали. С помощью формулы ниже показано, как определить длину очереди для чередующихся томов.
Регулирование
Хранилище Azure класса «Премиум» позволяет подготовить указанное количество операций ввода-вывода в секунду и задать пропускную способность в зависимости от выбранного размера виртуальных машин и дисков. При каждой попытке приложения выполнить операции ввода-вывода или использовать пропускную способность за пределами ограничения обработки виртуальной машины или диска хранилище класса «Премиум» урегулирует эту проблему. Это ухудшает производительность приложения, что выражается в повышенной задержке, низкой пропускной способности или меньшем количестве операций ввода-вывода в секунду. Если хранилище класса «Премиум» не выполнит регулировку, может произойти сбой всего приложения, так как оно превысит максимальные значения, которых могут достичь его ресурсы. Таким образом, чтобы избежать проблем с производительностью, связанных с регулированием, всегда следует подготавливать для приложения достаточно ресурсов. Примите во внимание информацию о размерах виртуальных машин и дисков, приведенную в разделах выше. Лучший способ выяснить, какие ресурсы необходимы для размещения приложения, — протестировать производительность.
Дальнейшие действия
Если вы хотите протестировать производительность диска, воспользуйтесь следующими статьями на эту тему.
- Для Linux: Тестирование производительности приложения в Хранилище дисков Azure.
- Для Windows: Тестирование производительности диска.
См. дополнительные сведения о доступных типах дисков:
- Для Linux: Выбор типа диска
- Для Windows: Выбор типа диска
Если вы пользователь SQL Server, см. статьи с рекомендациями по оптимизации производительности SQL Server: