Хранилище Azure уровня "Премиум": проектирование для повышения производительности
Применимо к: ✔️ Виртуальные машины Linux ✔️ Виртуальные машины Windows ✔️ Универсальные масштабируемые наборы
В этой статье приведены рекомендации по созданию высокопроизводительных приложений с помощью хранилища Azure класса Premium. Указания в этом документе можно использовать вместе с рекомендациями по производительности, применимыми к технологиям, которые используются приложением. Чтобы проиллюстрировать рекомендации, мы используем SQL Server, работающий в хранилище класса Premium, в качестве примера в этом документе.
Хотя мы рассмотрим сценарии производительности для уровня хранилища в этой статье, необходимо оптимизировать уровень приложения. Например, если вы размещаете ферму SharePoint в хранилище класса Premium, можно использовать примеры SQL Server из этой статьи для оптимизации сервера базы данных. Вы также можете оптимизировать веб-сервер и сервер приложений фермы SharePoint, чтобы получить большую производительность.
Эта статья поможет ответить на следующие распространенные вопросы о оптимизации производительности приложений в хранилище класса Premium:
- Как оценить производительность приложения?
- Почему вы не видите ожидаемую высокую производительность?
- Какие факторы влияют на производительность приложения в хранилище класса Premium?
- Как эти факторы влияют на производительность приложения в хранилище класса Premium?
- Как оптимизировать операции ввода-вывода в секунду (IOPS), пропускную способность и задержку?
Мы предоставляем эти рекомендации специально для хранилища класса Premium, так как рабочие нагрузки, работающие в хранилище класса Premium, чувствительны к высокой производительности. В этом случае мы предоставляем примеры. Вы также можете применить некоторые из этих рекомендаций к приложениям, работающим на виртуальных машинах инфраструктуры как услуга (IaaS) с дисками хранилища уровня "Стандартный".
Примечание.
Иногда проблема с производительностью диска на самом деле является узким местом сети. В таких ситуациях следует улучшить производительность сети.
Если вы хотите проверить производительность диска, ознакомьтесь со следующими статьями:
- Для Linux: Тестирование производительности приложения в Хранилище дисков Azure.
- Для Windows: проверка производительности диска
Если виртуальная машина поддерживает ускорение сети, убедитесь, что она включена. Если он не включен, его можно включить на уже развернутых виртуальных машинах как в Windows, так и в Linux.
Прежде чем приступить к работе, если вы не знакомы с хранилищем уровня "Премиум", сначала ознакомьтесь с разделом "Выбор типа диска Azure для виртуальных машин IaaS" и целевых показателей масштабируемости для учетных записей хранения BLOB-объектов категории "Премиум".
Показатели производительности приложения
Мы оцениваем, работает ли приложение хорошо или не использует такие показатели производительности, как:
- Как быстро приложение обрабатывает запрос пользователя.
- Сколько данных приложение обрабатывает по запросу.
- Сколько запросов приложение обрабатывает в определенный период времени.
- Сколько времени пользователю нужно ждать, чтобы получить ответ после отправки запроса.
Технические термины для этих показателей производительности — это операции ввода-вывода в секунду, пропускная способность или пропускная способность и задержка.
В этом разделе мы обсудим общие показатели производительности в контексте хранилища класса Premium. В разделе "Список проверка производительности приложений для дисков" вы узнаете, как измерять эти показатели производительности для приложения. Далее в разделе "Оптимизация производительности приложений" вы узнаете о факторах, влияющих на эти показатели производительности и рекомендации по их оптимизации.
ОПЕРАЦИЙ ВВОДА-ВЫВОДА
Операций ввода-вывода в секунду — это количество запросов, отправляемых приложением на диски хранилища в одну секунду. Различают следующие типы операций ввода-вывода: чтения или записи, последовательные или случайные. Приложения для обработки транзакций в Сети (OLTP), такие как веб-сайт онлайн розничной торговли, должны немедленно обрабатывать множество одновременных запросов пользователей. Запросы пользователей — это транзакции базы данных с интенсивным обновлением, которые приложение должно быстро обрабатывать. По этой причине приложения OLTP требуют очень высокого уровня операций ввода-вывода в секунду.
Приложения OLTP обрабатывают миллионы небольших и случайных запросов ввода-вывода. Для такого приложения следует разрабатывать инфраструктуру с учетом оптимизации операций ввода-вывода. Дополнительные сведения обо всех факторах, которые следует учитывать при получении высокого уровня операций ввода-вывода в секунду, см. в статье "Оптимизация производительности приложения".
При подключении диска хранилища класса Premium к масштабируемой виртуальной машине Azure подготавливает для вас гарантированное количество операций ввода-вывода в секунду в соответствии со спецификацией диска. Например, диск P50 подготавливает 7500 операций ввода-вывода в секунду. Каждый масштабируемый размер виртуальной машины также имеет определенное ограничение операций ввода-вывода в секунду, которое может поддерживаться. Например, для виртуальной машины серии GS5 класса "Стандартный" установлено ограничение в 80 000 операций ввода-вывода в секунду.
Пропускная способность
Пропускная способность или пропускная способность — это объем данных, которые приложение отправляет на диски хранилища в указанный интервал. Если приложение выполняет операции ввода-вывода с большими размерами единиц ввода-вывода, требуется высокая пропускная способность. Приложения хранилища данных, как правило, выполняют операции с интенсивным сканированием, которые обращаются к большим частям данных одновременно и обычно выполняют массовые операции. Поэтому таким приложениям требуется более высокая пропускная способность. Для такого приложения необходимо разрабатывать инфраструктуру с учетом оптимизации пропускной способности. В следующем разделе мы обсудим факторы, которые необходимо настроить для достижения этой оптимизации.
При подключении диска хранилища класса Premium к масштабируемой виртуальной машине Azure подготавливает пропускную способность в соответствии с этой спецификацией диска. Например, диск P50 подготавливает пропускную способность диска 250 МБ/с. Каждый масштабируемый размер виртуальной машины также имеет определенное ограничение пропускной способности, которое может поддерживаться. Например, виртуальная машина GS5 уровня "Стандартный" имеет максимальную пропускную способность в 2000 МБ/с.
Существует связь между пропускной способностью и операцией ввода-вывода в секунду, как показано в следующей формуле.
Важно определить оптимальную пропускную способность и значения операций ввода-вывода в секунду, необходимые приложению. По мере того как вы пытаетесь оптимизировать один, другой также затрагивается. Дополнительные сведения об оптимизации операций ввода-вывода в секунду и пропускной способности см. в статье "Оптимизация производительности приложения".
Задержка
Задержка — это время, которое требуется приложению для получения одного запроса, отправки его на диски хранилища и отправки ответа клиенту. Задержка является критической мерой производительности приложения в дополнение к операций ввода-вывода в секунду и пропускной способности. Задержка диска хранилища уровня "Премиум" — это время, необходимое для получения сведений о запросе и обратного обмена данными с приложением. Хранилище класса Premium обеспечивает стабильно низкую задержку. Диски уровня "Премиум" предназначены для обеспечения однозначных миллисекунда задержки для большинства операций ввода-вывода. Если включить кэширование узла ReadOnly на дисках хранилища класса Premium, можно получить гораздо меньшую задержку чтения. Дополнительные сведения о кэшировании дисков см. в разделе "Кэширование дисков".
При оптимизации приложения для повышения скорости ввода-вывода в секунду и пропускной способности это влияет на задержку приложения. После настройки производительности приложения всегда оцените задержку приложения, чтобы избежать непредвиденного поведения высокой задержки.
Следующие операции плоскости управления на управляемых дисках могут включать перемещение диска из одного расположения в другое. Это перемещение управляется с помощью фоновой копии данных, которая может занять несколько часов. Как правило, время меньше 24 часов в зависимости от объема данных на дисках. В течение этого времени приложение может столкнуться с более высокой задержкой чтения, так как некоторые операции чтения могут перенаправиться в исходное расположение и занять больше времени.
В течение этого периода не влияет на задержку записи. Для дисков SSD уровня "Премиум" версии 2 и "Ультра", если на диске имеется размер сектора 4K, это может повысить задержку чтения. Если на диске имеется 512e размер сектора, он испытывает как более высокую задержку чтения, так и записи.
Операции плоскости управления используются для:
- Измените тип хранилища.
- Отсоедините диск от одной виртуальной машины и присоедините его к другой.
- Создайте управляемый диск на основе VHD.
- Создайте управляемый диск на основе моментального снимка.
- Преобразуйте неуправляемые диски в управляемые.
Список проверка производительности приложений для дисков
Первым шагом в разработке высокопроизводительных приложений, работающих в хранилище класса Premium, является понимание требований к производительности приложения. После сбора этих требований на их основе можно оптимизировать приложение для достижения наиболее оптимальной производительности.
В предыдущем разделе описаны общие показатели производительности: операции ввода-вывода в секунду, пропускная способность и задержка. Чтобы предоставить необходимые возможности для пользователя, нужно определить, какие из этих показателей производительности критически важны для приложения. Например, высокая скорость выполнения операций ввода-вывода наиболее важна для приложений OLTP, обрабатывающих миллионы транзакций в секунду. Высокая пропускная способность важна для приложений хранилища данных, обрабатывающих большие объемы данных в секунду. Крайне низкая задержка важна для приложений в режиме реального времени, таких как веб-сайты потоковой передачи видео.
Затем нужно определить максимальные требования к производительности приложения в течение его времени существования. В качестве начала используйте следующий пример проверка list. Запишите максимальные требования к производительности во время обычных, пиковых и внечасовых рабочих нагрузок. Определив требования ко всем уровням рабочей нагрузки, вы можете определить общее требование к производительности приложения.
Например, обычная рабочая нагрузка веб-сайта электронной коммерции — это транзакции, которые она обслуживает в течение большинства дней в год. Пиковая рабочая нагрузка веб-сайта — это транзакции, которые он обслуживает в праздничные сезоны или специальные события продажи. Пиковая рабочая нагрузка обычно испытывается в течение ограниченного периода, но может потребовать от приложения масштабирования в два или более раз его нормальной работы. Узнайте требования для 50-го, 90-го и 99-го процентилей. Эта информация помогает отфильтровать все вылитые в требованиях к производительности, и вы можете сосредоточить усилия на оптимизации правильных значений.
Контрольный список требований к производительности приложений
| Требования к производительности | 50 процентиль | 90 процентиль | 99 процентиль |
|---|---|---|---|
| Максимальное количество транзакций в секунду | |||
| Операции чтения, % | |||
| Операции записи, % | |||
| Случайные операции, % | |||
| Последовательные операции, % | |||
| Размер запроса ввода-вывода | |||
| Средняя пропускная способность | |||
| Максимальная пропускная способность | |||
| Минимальная задержка | |||
| Средняя задержка | |||
| Максимальное количество ЦП | |||
| Средняя загрузка ЦП | |||
| Максимальный объем памяти | |||
| Средняя память | |||
| Длина очереди |
Примечание.
Рассмотрите возможность масштабирования этих чисел на основе ожидаемого будущего роста приложения. Рекомендуется заранее планировать рост, так как может быть труднее изменить инфраструктуру для повышения производительности позже.
Если у вас есть существующее приложение и хотите перейти в хранилище класса Premium, сначала создайте предыдущий список проверка для существующего приложения. Затем создайте прототип приложения в хранилище класса Premium и создайте приложение на основе рекомендаций, описанных в статье "Оптимизация производительности приложения". В следующей статье описываются инструменты для сбора информации о показателях производительности.
Счетчики для оценки требований к производительности приложения
Лучший способ измерения требований к производительности приложения — использовать PerfMonсредства мониторинга, предоставляемые операционной системой сервера. Вы можете использовать PerfMon для Windows и iostat Linux. Эти средства фиксируют счетчики, соответствующие каждой мере, описанной в предыдущем разделе. Необходимо записать значения этих счетчиков, когда приложение выполняет свои обычные, пиковые и нерабочие рабочие нагрузки.
Счетчики PerfMon доступны для процессора, памяти и каждого логического диска и физического диска сервера. При использовании дисков хранилища класса «Премиум» в виртуальной машине счетчики физических дисков собирают данные с каждого диска хранилища, а счетчики логических дисков — с каждого тома, созданного на диске хранилища. Необходимо записывать значения для дисков, на которых выполняется рабочая нагрузка приложения. Если между логическими и физическими дисками имеется одно сопоставление, можно ссылаться на счетчики физических дисков. В противном случае обратитесь к счетчикам логических дисков.
В iostat Linux команда создает отчет об использовании ЦП и диска. В отчете об использовании дискового пространства содержатся статистические данные для каждого физического устройства или раздела. Если данные и журнал сервера базы данных расположены на разных дисках, нужно собрать данные для обоих дисков. В следующей таблице описываются счетчики дисков, процессоров и памяти.
| Счетчик | Description | PerfMon | iostat |
|---|---|---|---|
| Операции ввода-вывода в секунду или транзакции в секунду | Количество запросов ввода-вывода, выданных диску хранилища в секунду | Операции чтения на диске/с Операции записи на диск/с |
Tps r/s w/s |
| Чтения и записи диска | % операций чтения и записи, выполняемых на диске | % время чтения диска % времени записи диска |
r/s w/s |
| Пропускная способность | Объем данных, считываемых из диска или записи в секунду | Диск считывает байт/с байт записи на диск/с |
kB_read/с КБ/с записано |
| Задержка | Общее время завершения запроса ввода-вывода диска | Среднее количество дисков в секунду на чтение Среднее количество дисков в секунду/запись |
Ждут svctm |
| Объем ввода-вывода | Размер запросов ввода-вывода на диски хранилища | Среднее число байтов диска и чтения Среднее число байтов диска и записи |
avgrq-sz |
| Длина очереди | Число невыполненных запросов ввода-вывода, ожидающих считывания или записи на диск хранилища | Текущая длина очереди диска | avgqu-sz |
| Максимальный объем памяти | Объем памяти, необходимый для плавного запуска приложения | % Зафиксированные байты в использовании | Использование vmstat |
| Максимальное количество ЦП | Объем ЦП, необходимый для плавного запуска приложения | Загруженность процессора, % | %util |
См. дополнительные сведения об iostat и PerfMon.
Оптимизация производительности приложения
Основными факторами, влияющими на производительность приложения, работающего в хранилище класса Premium, являются характер запросов ввода-вывода, размер виртуальной машины, размер диска, количество дисков, кэширование дисков, многопоточность и глубина очереди. Некоторыми из этих факторов можно управлять с помощью средств, предоставляемых системой.
Большинство приложений могут не предоставлять возможность напрямую изменять размер ввода-вывода и глубину очереди. Например, если вы используете SQL Server, вы не можете выбрать размер ввода-вывода и глубину очереди. SQL Server выбирает оптимальный размер ввода-вывода и значения глубины очереди, чтобы получить большую производительность. Важно понимать влияние обоих типов факторов на производительность приложения, чтобы подготовить соответствующие ресурсы для удовлетворения потребностей в производительности.
В этом разделе описаны требования приложения, проверка список, созданный для определения того, сколько необходимо оптимизировать производительность приложения. На основе списка проверка можно определить, какие факторы из этого раздела необходимо настроить.
Чтобы убедиться во влиянии каждого из показателей на производительность приложения, запустите инструменты тестирования производительности на установленном приложении. Инструкции по выполнению общих средств тестирования на виртуальных машинах Windows и Linux см. в статьях по тестированию в конце этого документа.
Краткий обзор оптимизации операций ввода-вывода, пропускной способности и задержки
В следующей таблице перечислены факторы производительности и шаги, необходимые для оптимизации операций ввода-вывода в секунду, пропускной способности и задержки. В разделах, приведенных в этом сводке, описываются все факторы более подробно.
Дополнительные сведения о размерах виртуальных машин, операциях ввода-вывода в секунду, пропускной способности и задержке, доступных для каждого типа виртуальной машины, см. в статье Размеры виртуальных машин в Azure.
| Факторы производительности | ОПЕРАЦИЙ ВВОДА-ВЫВОДА | Пропускная способность | Задержка |
|---|---|---|---|
| Пример сценария | Корпоративное приложение OLTP, которому требуется высокая скорость выполнения транзакций в секунду. | Корпоративное приложение хранилища данных, обрабатывающее большие объемы данных. | Приложения, которые выполняются практически в реальном времени и требуют мгновенных ответов на запросы пользователей, например игры в сети. |
| Факторы производительности | |||
| Объем ввода-вывода | Меньший размер ввода-вывода дает больше операций ввода-вывода. | Размер ввода-вывода большего размера обеспечивает более высокую пропускную способность. | |
| Размер виртуальной машины | Используйте размер виртуальной машины, который обеспечивает более высокую скорость выполнения операций ввода-вывода, чем указано в требованиях приложения. | Используйте размер виртуальной машины с ограничением пропускной способности, превышающим требование приложения. | Используйте размер виртуальной машины с более широкими пределами масштабируемости, чем требует приложение. |
| Размер диска | Используйте размер диска, который обеспечивает более высокую скорость выполнения операций ввода-вывода, чем требует приложение. | Используйте размер диска с ограничением пропускной способности, превышающим требование приложения. | Используйте размер диска с более широкими пределами масштабируемости, чем требует приложение. |
| Ограничения масштабирования виртуальных машин и дисков | Ограничение операций ввода-вывода в секунду выбранного размера виртуальной машины должно превышать общее число операций ввода-вывода в секунду, направляемое дисками хранилища, подключенными к нему. | Ограничение пропускной способности выбранного размера виртуальной машины должно превышать общую пропускную способность, определяемую дисками хранилища класса Premium, подключенными к ней. | Ограничения масштаба выбранного размера виртуальной машины должны превышать общие ограничения масштаба подключенных дисков хранилища класса Premium. |
| Кэширование диска | Включите кэш ReadOnly на дисках хранилища уровня "Премиум" с операциями с большим количеством операций чтения, чтобы получить более высокий объем операций ввода-вывода в секунду. | Включите кэш ReadOnly на дисках хранилища класса Premium с большим количеством операций чтения, чтобы получить очень низкую задержку чтения. | |
| Чередование дисков | Используйте несколько дисков и чередуйте их вместе, чтобы получить объединенный более высокий объем операций ввода-вывода в секунду и ограничение пропускной способности. Общее ограничение для каждой виртуальной машины должно быть выше, чем сумма ограничений для подключенных дисков категории "Премиум". | ||
| Размер полосы | Меньший размер полосы для случайного небольшого шаблона ввода-вывода, наблюдаемого в приложениях OLTP. Например, используйте 64-КБ размер полосы для приложения OLTP SQL Server. | Более крупный размер полосы для последовательного ввода-вывода, наблюдаемого в приложениях хранилища данных. Например, используйте размер 256-КБ полосы для приложения хранилища данных SQL Server. | |
| Многопоточность | Используйте многопоточность для отправки большего количества запросов в хранилище класса Premium, чтобы привести к повышению операций ввода-вывода в секунду и пропускной способности. Например, в SQL Server задайте высокое значение MAXDOP, чтобы выделить больше ЦП в SQL Server. | ||
| Длина очереди | Более большая глубина очереди обеспечивает более высокую производительности операций ввода-вывода в секунду. | Большая глубина очереди обеспечивает более высокую пропускную способность. | Меньшая глубина очереди дает более низкую задержку. |
Характер запросов ввода-вывода
Запрос ввода-вывода — это единица операций ввода-вывода, выполняемой приложением. Определение характера запросов ввода-вывода, случайного или последовательного ввода-вывода, чтения или записи, малого или большого размера помогает определить требования к производительности приложения. Важно понимать характер запросов ввода-вывода для принятия правильных решений при разработке инфраструктуры приложений. Для достижения максимальной производительности необходимо равномерно распределить i/Os.
Размер ввода-вывода является одним из самых важных факторов. Размер ввода-вывода — это размер запроса операции ввода-вывода, созданной приложением. Размер ввода-вывода значительно влияет на производительность, особенно на пропускную способность операций ввода-вывода и пропускную способность, которую может достичь приложение. В следующей формуле показана связь между объемом операций ввода-вывода, размером ввода-вывода и пропускной способностью и пропускной способностью.
Некоторые приложения позволяют изменять размер ввода-вывода, а некоторые приложения не выполняются. Например, SQL Server определяет оптимальный размер ввода-вывода и не предоставляет пользователям никаких ножей для изменения. С другой стороны, Oracle предоставляет параметр с именем DB_BLOCK_SIZE, который можно использовать для настройки размера запроса ввода-вывода базы данных.
Если вы используете приложение, которое не позволяет изменять размер ввода-вывода, используйте рекомендации в этой статье для оптимизации ключевых показателей эффективности производительности, наиболее релевантных для приложения. Например:
- Приложение OLTP создает миллионы небольших и случайных запросов ввода-вывода. Чтобы обрабатывать эти типы запросов ввода-вывода, необходимо разработать инфраструктуру приложений, чтобы получить более высокий объем операций ввода-вывода.
- Приложение для хранения данных создает большие и последовательные запросы ввода-вывода. Чтобы обрабатывать эти типы запросов ввода-вывода, необходимо разработать инфраструктуру приложений, чтобы получить более высокую пропускную способность или пропускную способность.
Если вы используете приложение, позволяющее изменить размер ввода-вывода, используйте это правило для размера ввода-вывода в дополнение к другим рекомендациям по производительности:
- Меньший размер ввода-вывода для получения большего количества операций ввода-вывода. Например, 8 КБ для приложения OLTP.
- Более крупный размер ввода-вывода для получения более высокой пропускной способности и пропускной способности. Например, 1024 КБ для приложения хранилища данных.
Ниже приведен пример вычисления операций ввода-вывода в секунду и пропускной способности для приложения.
Рассмотрим приложение, использующее диск P30. Максимальное количество операций ввода-вывода в секунду и пропускная способность диска P30 составляет 5000 операций ввода-вывода в секунду и 200 МБ/с соответственно. Если приложению требуется максимальное количество операций ввода-вывода с диска P30 и используется меньший размер ввода-вывода, например 8 КБ, полученная пропускная способность составляет 40 МБ/с. Если приложению требуется максимальная пропускная способность и пропускная способность диска P30, и вы используете больший размер ввода-вывода, например 1024 КБ, результирующий объем операций ввода-вывода меньше, например 200 операций ввода-вывода.
Настройте размер ввода-вывода таким образом, чтобы оно соответствовало требованиям операций ввода-вывода в секунду и пропускной способности приложения. В следующей таблице перечислены различные размеры операций ввода-вывода и соответствующие операции ввода-вывода и пропускная способность для диска P30.
| Требование приложения | Объем ввода-вывода | ОПЕРАЦИЙ ВВОДА-ВЫВОДА | Пропускная способность |
|---|---|---|---|
| Максимальное значение IOPS | 8 КБ | 5,000 | 40 МБ/с |
| Максимальная пропускная способность | 1024 КБ | 200 | 200 МБ/с |
| Максимальная пропускная способность + высокая скорость ввода-вывода в секунду | 64 КБ | 3200 | 200 МБ/с |
| Максимальное число операций ввода-вывода в секунду + высокая пропускная способность | 32 КБ | 5,000 | 160 Мбит/с |
Чтобы получить число операций ввода-вывода в секунду и пропускную способность выше максимального значения одного диска хранилища класса Premium, используйте несколько дисков класса Premium, чередуемых вместе. Например, чередуйте два диска P30, чтобы получить объединенную пропускную способность в секунду 10 000 операций ввода-вывода в секунду или объединенную пропускную способность 400 МБ/с. Как описано в следующем разделе, необходимо использовать размер виртуальной машины, поддерживающий объединенные операции ввода-вывода в секунду и пропускную способность диска.
Примечание.
При увеличении операций ввода-вывода в секунду или пропускной способности другой также увеличивается. Убедитесь, что при увеличении числа операций ввода-вывода в секунду не достигнута пропускная способность или ограничения операций ввода-вывода в секунду диска или виртуальной машины.
Чтобы увидеть влияние размера ввода-вывода на производительность приложения, можно запустить средства тестирования на виртуальной машине и дисках. Создайте несколько тестов и используйте для каждого запуска разные размеры операций ввода-вывода для просмотра эффекта. Дополнительные сведения см. в статьях по тестированию в конце этого документа.
Масштабируемые размеры виртуальных машин
При запуске разработки приложения одним из первых действий является выбор виртуальной машины для размещения приложения. Хранилище класса Premium поставляется с масштабируемыми размерами виртуальных машин, которые могут запускать приложения, требующие более высокой вычислительной мощности и высокой производительности операций ввода-вывода локального диска. Эти виртуальные машины обеспечивают более быстрые процессоры, более высокое соотношение памяти к ядру и твердотельный диск (SSD) для локального диска. Примерами высокомасштабируемых виртуальных машин, поддерживающих хранилище класса Premium, являются виртуальные машины серии DS и GS.
Высокомасштабируемые виртуальные машины доступны в разных размерах с различным количеством ядер ЦП, памяти, ОС и временного размера диска. Каждый размер виртуальной машины также имеет максимальное количество дисков данных, которые можно подключить к виртуальной машине. Выбранный размер виртуальной машины влияет на объем обработки, памяти и емкости хранилища для приложения. Это также влияет на затраты на вычислительные ресурсы и хранилище. Например, следующие спецификации предназначены для наибольшего размера виртуальной машины в серии DS и серии GS.
| Размер виртуальной машины | Ядра ЦП | Память | Размеры диска виртуальной машины | Максимальное количество дисков данных | Размер кэша | ОПЕРАЦИЙ ВВОДА-ВЫВОДА | Ограничения ввода-вывода кэша пропускной способности |
|---|---|---|---|---|---|---|---|
| Standard_DS14 | 16 | 112 ГБ | ОС = 1 023 ГБ Локальный SSD = 224 ГБ |
32 | 576 ГБ | 50 000 операций ввода-вывода в секунду 512 Мбит/с |
4000 операций ввода-вывода в секунду и 33 МБ/с |
| Standard_GS5 | 32 | 448 ГБ | ОС = 1 023 ГБ Локальный SSD = 896 ГБ |
64 | 4224 ГБ | 80 000 операций ввода-вывода в секунду 2000 МБ/с |
5000 операций ввода-вывода в секунду и 50 МБ/с |
Полный список всех доступных размеров виртуальных машин Azure см. в статье "Размеры виртуальных машин" в Azure. Выберите размер виртуальной машины, который позволяет выполнять масштабирование в соответствии с требованиями к производительности приложения. При выборе размеров виртуальной машины следует учитывать следующие важные аспекты.
Ограничения масштабирования
Максимальные ограничения операций ввода-вывода в секунду на виртуальную машину и на диск различаются и не зависят друг от друга. Убедитесь, что приложение управляет операцией ввода-вывода в секунду в пределах виртуальной машины и дисков класса Premium, подключенных к нему. В противном случае производительность приложения регулируется.
В качестве примера предположим, что максимальное количество операций ввода-вывода в секунду для приложения составляет 4000. Для этого уровня необходимо подготовить диск P30 на виртуальной машине DS1. Диск P30 может выполнять до 5000 операций ввода-вывода в секунду. Но виртуальная машина DS1 может выполнять не более 3200 операций ввода-вывода в секунду. Таким образом, производительность приложения ограничивается ограничением виртуальной машины на 3200 операций ввода-вывода в секунду и производительность снижается. Чтобы предотвратить эту ситуацию, выберите виртуальную машину и размер диска, соответствующие требованиям приложения.
Стоимость операции
Во многих случаях общая стоимость операций с использованием хранилища класса Premium ниже, чем использование стандартного хранилища.
В качестве примера рассмотрим приложение, требующее выполнения 16 000 операций ввода-вывода в секунду. Для достижения этой производительности требуется Standard_D14 виртуальной машины IaaS Azure, которая может предоставить максимальное количество операций ввода-вывода в секунду 16 000 с помощью 32 дисков хранилища уровня "Стандартный" 1-ТБ. Каждый диск стандартного хранилища емкостью 1 ТБ может выполнять до 500 операций ввода-вывода в секунду.
- Оценочная стоимость этой виртуальной машины в месяц составляет $1570.
- Ежемесячная стоимость 32 дисков хранилища уровня "Стандартный" составляет 1638 долл. США.
- По оценкам, общая ежемесячная стоимость составляет $ 3208.
Если вы размещали то же приложение в хранилище класса Premium, вам потребуется меньший размер виртуальной машины и меньше дисков хранилища класса Premium, что снижает общую стоимость. Виртуальная машина Standard_DS13 может соответствовать требованию 16 000 операций ввода-вывода в секунду с помощью четырех дисков P30. Виртуальная машина DS13 имеет максимум операций ввода-вывода в секунду 25600, а каждый диск P30 имеет максимальное количество операций ввода-вывода в секунду 5 000. В целом, при такой конфигурации можно добиться 20 000 операций ввода-вывода в секунду (5000 x 4).
- Оценочная стоимость этой виртуальной машины в месяц составляет $1003.
- Ежемесячная стоимость четырех дисков хранилища P30 класса Premium составляет $544,34.
- По оценкам, общая ежемесячная стоимость составляет $ 1544.
В следующей таблице приведены сведения о разбивке затрат на этот сценарий для хранилища уровня "Стандартный" и "Премиум".
| Ежемесячные расходы | Standard | Premium |
|---|---|---|
| Стоимость виртуальной машины в месяц | 1570,58 долл. США (Standard_D14) | 1003,66 долл. США (Standard_DS13) |
| Стоимость дисков в месяц | 1638,40 долл. США (32 диска емкостью по 1 ТБ) | 544,34 долл. США (4 диска P30) |
| Общая стоимость в месяц | 3208,98 долл. США | 1544,34 долл. США |
Дистрибутивы Linux
Благодаря хранилищу класса Premium вы получаете тот же уровень производительности для виртуальных машин под управлением Windows и Linux. Поддерживаются различные дистрибутивы Linux. Дополнительные сведения см. в статье Linux в Azure — рекомендованные дистрибутивы.
Различные дистрибутивы лучше подходят для различных типов рабочих нагрузок. Вы видите различные уровни производительности в зависимости от дистрибутива, на котором выполняется рабочая нагрузка. Протестируйте дистрибутивы Linux для приложения и выберите наиболее подходящий вариант.
При запуске Linux с хранилищем класса Premium проверка последние обновления о необходимых драйверах, чтобы обеспечить высокую производительность.
Размеры дисков хранилища класса "Премиум"
Хранилище класса "Премиум" предлагает различные размеры, чтобы выбрать наиболее подходящий для ваших потребностей. Для диска каждого размера установлены разные ограничения масштабирования для операций ввода-вывода в секунду, пропускной способности и хранилища. Выберите нужный размер диска хранилища класса 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 | 8,192 | 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 мин | Без ограничений | Без ограничений | Без ограничений | Без ограничений | Без ограничений | Без ограничений |
| Подходит для резервирования | No | Нет | Нет | Нет | Нет | Нет | Нет | No | Да, до одного года | Да, до одного года | Да, до одного года | Да, до одного года | Да, до одного года | Да, до одного года |
* Применяется только к дискам с включенным ускорением по запросу.
** Применяется только к дискам с включенной производительностью и (предварительная версия).
Выбор количества дисков зависит от выбранного размера диска. Для удовлетворения требований приложения можно использовать один диск P50 или несколько дисков P10. Учитывайте рекомендации, перечисленные здесь при выборе.
Ограничения масштабирования (операции ввода-вывода в секунду и пропускная способность)
Ограничения операций ввода-вывода в секунду и пропускной способности каждого размера диска уровня "Премиум" отличаются и не зависят от ограничений масштабирования виртуальной машины. Убедитесь, что общий объем операций ввода-вывода в секунду и пропускная способность дисков находятся в пределах масштаба выбранного размера виртуальной машины.
Например, если требование к приложению составляет не более 250 МБ/с и используете виртуальную машину DS4 с одним диском P30, виртуальная машина DS4 может дать до 256 МБ/с. Однако один диск P30 имеет ограничение пропускной способности в 200 МБ/с. Таким образом, приложение ограничено на 200 МБ/с из-за ограничения диска. Чтобы преодолеть это ограничение, подготовьте несколько дисков данных к виртуальной машине или измените размер дисков на P40 или P50.
Примечание.
Операции чтения, обслуживаемые кэшем, не включаются в число операций ввода-вывода в секунду и пропускную способность диска, поэтому они не подвергаются ограничениям на диск. Кэш имеет отдельное ограничение операций ввода-вывода в секунду и пропускную способность для каждой виртуальной машины.
Например, изначально операции чтения и записи — 60 МБ/с и 40 МБ/с соответственно. Со временем кэш подготавливает и выполняет все больше операций чтения. Затем можно получить более высокую пропускную способность записи с диска.
Число дисков
Определите количество дисков, необходимых для оценки требований приложения. Для каждого размера виртуальной машины также установлено ограничение на количество дисков, которые можно подключить. Как правило, это количество в два раза больше ядер. Убедитесь, что выбранный размер виртуальной машины поддерживает необходимое количество дисков.
Помните, что диски хранилища класса Premium имеют более высокую производительность по сравнению с дисками хранилища уровня "Стандартный". Если вы переносите приложение из виртуальной машины IaaS Azure с помощью хранилища уровня "Стандартный" в хранилище уровня "Премиум", скорее всего, вам потребуется меньше дисков уровня "Премиум", чтобы обеспечить ту же или более высокую производительность для приложения.
Кэширование диска
Высокомасштабируемые виртуальные машины, использующие хранилище класса Premium, имеют многоуровневую технологию кэширования под названием BlobCache. BlobCache использует сочетание ОЗУ узла и локального SSD для кэширования. Этот кэш доступен для постоянных дисков хранилища класса Premium и локальных дисков виртуальной машины. По умолчанию этот параметр кэша имеет значение ReadWrite для дисков ОС и ReadOnly для дисков данных, размещенных в хранилище класса Premium. При включенном кэшировании дисков на дисках хранилища класса Premium масштабируемые виртуальные машины могут достичь чрезвычайно высокого уровня производительности, превышающей производительность базового диска.
Предупреждение
Кэширование не поддерживается для дисков размером 4 ТиБ и выше. Если к виртуальной машине подключено несколько дисков, каждый диск меньше 4 ТиБ поддерживает кэширование.
При изменении параметра кэша диска Azure целевой диск отключается, а затем вновь подключается к виртуальной машине. Если это диск операционной системы, то виртуальная машина перезагрузится. Остановите все приложения и службы, которые могут повлиять на это нарушение перед изменением параметра кэша диска. Несоблюдение этих рекомендаций может привести к повреждению данных.
Дополнительные сведения о том, как работает BLOBCache, см. в записи блога о хранилище Класса Premium в Azure.
Важно включить кэширование в правильном наборе дисков. Следует ли включить кэширование дисков на диске уровня "Премиум" или не зависит от шаблона рабочей нагрузки, которую обрабатывает диск. В следующей таблице показаны параметры кэша по умолчанию для дисков ОС и данных.
| Тип диска | Параметр кэширования по умолчанию |
|---|---|
| Диск ОС | Чтение и запись |
| Диск данных | ReadOnly |
Мы рекомендуем использовать следующие параметры кэша дисков для дисков данных.
| Параметр кэширования диска | Рекомендации по использованию этого параметра |
|---|---|
| нет | Настройте кэш узла как None для дисков, доступных только для записи и записи. |
| ReadOnly | Настройте кэш узла как ReadOnly для дисков только для чтения и записи. |
| Чтение и запись | Настройте кэш узла как ReadWrite , только если приложение правильно обрабатывает запись кэшированных данных на постоянные диски при необходимости. |
ReadOnly
Настроив кэширование ReadOnly на дисках данных хранилища уровня "Премиум", вы можете достичь низкой задержки чтения и получить очень высокую пропускную способность операций ввода-вывода в секунду и пропускную способность для приложения по двум причинам:
- Операции чтения, выполняемые из кэша, который находится в памяти виртуальной машины и локальном SSD, быстрее, чем считывается с диска данных, который находится на Хранилище BLOB-объектов Azure.
- Хранилище класса Premium не подсчитывает операции чтения из кэша в сторону операций ввода-вывода в секунду на диск и пропускную способность. По этой причине приложение может достичь более высокого общего количества операций ввода-вывода в секунду и пропускной способности.
Чтение и запись
По умолчанию диски ОС включают кэширование ReadWrite . Недавно добавлена поддержка кэширования ReadWrite на дисках данных. Если вы используете кэширование ReadWrite , необходимо иметь правильный способ записи данных из кэша на постоянные диски. Например, SQL Server обрабатывает операции записи кэшированных данных на постоянные диски хранилища самостоятельно. Использование кэша ReadWrite с приложением, которое не обрабатывает сохранение необходимых данных, может привести к потере данных, если виртуальная машина завершает работу.
нет
В настоящее время вариант None (Нет) поддерживается только для дисков данных. Он не поддерживается на дисках ОС. Если вы задали None на диске ОС, он переопределяет этот параметр внутренне и задает для него значение ReadOnly.
Например, эти рекомендации можно применить к SQL Server, работающему в хранилище класса Premium, выполнив следующие действия.
- Настройте кэш ReadOnly на дисках хранилища класса Premium, где размещаются файлы данных.
- Быстрое чтение из кэша снижает время запроса SQL Server, так как страницы данных извлекаются быстрее из кэша по сравнению с дисками данных напрямую.
- Обслуживание операций чтения из кэша означает, что на дисках данных уровня "Премиум" доступно больше пропускной способности. SQL Server может использовать эту дополнительную пропускную способность для получения дополнительных страниц данных и других операций, таких как резервное копирование и восстановление, пакетная загрузка и перестроение индексов.
- Настройте кэш None на дисках хранилища класса Premium, в котором размещаются файлы журнала.
- Файлы журналов имеют в основном операции записи, поэтому они не используют кэш ReadOnly .
Оптимизация производительности на виртуальных машинах под управлением Linux
Для всех дисков ценовой категории "Премиум" или "Ультра" можно отключить барьеры для файловых систем на диске, чтобы повысить производительность, если известно, что кэши, которые могут потерять данные, отсутствуют. Если для кэширования дисков Azure задано значение ReadOnly или None, можно отключить барьеры. Но если для кэширования задано значение ReadWrite, барьеры должны оставаться включено для обеспечения устойчивости записи. Барьеры обычно включены по умолчанию, но вы можете отключить барьеры с помощью одного из следующих методов в зависимости от типа файловой системы:
- reiserFS: используйте параметр "Барьер=нет " для отключения барьеров. Чтобы явно включить барьеры, используйте barrier=flush.
- ext3/ext4: используйте параметр подключения барьера=0 , чтобы отключить барьеры. Чтобы явно включить барьеры, используйте барьер=1.
- XFS: используйте параметр подключения nobarrier для отключения барьеров. Чтобы явно включить барьеры, используйте барьер. По состоянию на версию 4.10 основного ядра Linux дизайн файловой системы XFS всегда обеспечивает устойчивость. Отключение барьеров не влияет, и параметр nobarrier не рекомендуется. Однако некоторые дистрибутивы Linux, возможно, поддержали изменения в выпуске дистрибутива с более ранней версией ядра. Обратитесь к поставщику распространителя для получения состояния в дистрибутиве и версии, которую вы используете.
Чередование дисков
При подключении высокомасштабируемой виртуальной машины с несколькими постоянными дисками хранилища класса Premium диски можно разделять для объединения операций ввода-вывода в секунду, пропускной способности и емкости хранилища.
Для чередования дисков в операционной системе Windows можно использовать дисковое пространство. Для каждого диска в пуле необходимо настроить один столбец. В противном случае общая производительность полосатого тома может быть ниже ожидаемой из-за неравномерного распределения трафика по дискам.
С помощью пользовательского интерфейса диспетчер сервера можно задать общее количество столбцов 8 для полосатого тома. При подключении более восьми дисков используйте PowerShell для создания тома. С помощью PowerShell можно задать количество столбцов, равное количеству дисков. Например, если в одном наборе полос есть 16 дисков, укажите 16 столбцы в NumberOfColumns параметре командлета New-VirtualDisk PowerShell.
В операционной системе Linux для чередования дисков используйте программу MDADM. Инструкции по чередовке дисков в Linux см. в статье "Настройка RAID программного обеспечения в Linux".
Размер полосы
При чередовании дисков размер блока чередования имеет большое значение. Размер полосы или размер блока является наименьшим фрагментом данных, которые приложение может адресовать на полосатый том. Настраиваемый размер блока чередования зависит от типа приложения и шаблона запроса. Если выбрать неправильный размер полосы, это может привести к неправильному перемещению ввода-вывода, что приводит к снижению производительности приложения.
Например, если объем запроса ввода-вывода, созданного приложением, превышает размер полосы диска, система хранения записывает его через границы единиц полосы на нескольких дисках. Когда пришло время получить доступ к этим данным, он должен искать в нескольких единицах полосы, чтобы завершить запрос. В результате производительность может существенно снизиться. С другой стороны, если размер запроса ввода-вывода меньше размера полосы, и если он случайный в природе, запросы ввода-вывода могут добавиться на одном диске, что приводит к снижению производительности ввода-вывода.
Выберите подходящий размер блока чередования в зависимости от типа рабочей нагрузки приложения. Для случайных запросов ввода-вывода используйте меньший размер полосы. Для больших последовательных запросов ввода-вывода используйте больший размер полосы. Узнайте рекомендации по размеру полосы для приложения, которое вы будете работать в хранилище класса Premium. В SQL Server настройте размер полосы 64 КБ для рабочих нагрузок OLTP или 256 КБ для рабочих нагрузок хранилища данных. Дополнительные сведения см. в рекомендациях по производительности SQL Server на виртуальных машинах Azure.
Примечание.
На виртуальной машине серии DS можно чередовать до 32 дисков хранилища класса «Премиум», а на виртуальной машине серии GS — до 64 дисков хранилища класса «Премиум».
Многопоточность
Azure разработала платформу хранилища класса Premium для массового параллелизма. По этой причине многопоточное приложение обеспечивает более высокую производительность, чем однопоточное приложение. Многопоточное приложение разделяет свои задачи по нескольким потокам и повышает эффективность его выполнения, используя ресурсы виртуальной машины и диска до максимального значения.
Например, если приложение запущено на одноядерной виртуальной машине с использованием двух потоков, для увеличения эффективности ЦП может переключаться между двумя потоками. Хотя один поток ожидает завершения ввода-вывода на диске, ЦП может переключиться на другой поток. Таким образом, используя два потока, можно выполнить намного больше задач, чем с использованием одного. Если виртуальная машина имеет несколько ядер, это еще больше сокращает время выполнения, так как каждое ядро может выполнять задачи параллельно.
Возможно, вы не сможете изменить способ реализации однопотокового или многопоточного приложения. Например, SQL Server может обрабатывать многопроцессорные и многоядерные процессоры. Однако SQL Server решает, в каких условиях используется один или несколько потоков для обработки запроса. Он может выполнять запросы и создавать индексы с помощью многопоточных операций. Для запроса, включающего присоединение больших таблиц и сортировку данных перед возвратом пользователю, SQL Server, скорее всего, использует несколько потоков. Пользователь не может контролировать, выполняется ли SQL Server запрос с помощью одного потока или нескольких потоков.
Существуют параметры конфигурации, которые можно изменить, чтобы повлиять на многопоточность или параллельную обработку приложения. Например, для SQL Server это max degree of parallelism конфигурация. Этот параметр с именем MAXDOP позволяет настроить максимальное количество процессоров SQL Server, которые могут использоваться при параллельной обработке. Этот параметр можно настроить для отдельных запросов и операций с индексами. Эта возможность полезна, если вы хотите сбалансировать ресурсы системы для критически важного для производительности приложения.
Например, предположим, что приложение, использующее SQL Server, выполняет большой запрос и операцию индексирования одновременно. Предположим, что требуется, чтобы операция индекса была более производительной по сравнению с большим запросом. В таком случае можно задать значение MAXDOP операции индекса выше, чем значение MAXDOP для запроса. Таким образом, SQL Server имеет больше процессоров, чем он может использовать для операции индекса по сравнению с количеством процессоров, которые он может выделить для большого запроса. Помните, что вы не контролируете количество потоков, которые SQL Server использует для каждой операции. Можно контролировать максимальное количество процессоров, выделенных для многопоточности.
Дополнительные сведения о степени параллелизма в SQL Server. Узнайте, как такие параметры влияют на многопоточность в приложении и их конфигурации для оптимизации производительности.
Длина очереди
Длина очереди или длина очереди или размер очереди — это количество ожидающих запросов ввода-вывода в системе. Значение глубины очереди определяет, сколько операций ввода-вывода может выстраивать приложение, которое обрабатывает диски хранилища. Это влияет на все три индикатора производительности приложения, рассмотренные в этой статье: операции ввода-вывода в секунду, пропускная способность и задержка.
Глубина очереди и многопоточность тесно связаны. Значение глубины очереди указывает, сколько многопоточности можно достичь приложением. Если глубина очереди велика, приложение может одновременно выполнять больше операций, другими словами, более многопоточность. Если глубина очереди невелика, несмотря на то, что приложение многопоточное, оно не будет содержать достаточно запросов для параллельного выполнения.
Как правило, приложения вне полки не позволяют изменять глубину очереди, так как если она задана неправильно, это делает больше вреда, чем хорошо. Приложения задают правильное значение глубины очереди, чтобы получить оптимальную производительность. Важно понимать эту концепцию, чтобы устранить неполадки с производительностью приложения. Кроме того, можно убедиться во влиянии длины очереди, запустив инструменты тестирования производительности в своей системе.
Некоторые приложения предоставляют параметры для влияния на глубину очереди. Например, параметр MAXDOP в SQL Server описан в предыдущем разделе. MAXDOP — это способ влияния на глубину очереди и многопоточность, хотя он не изменяет значение глубины очереди SQL Server напрямую.
Высокое значение длины очереди
Благодаря высокому значению длины в очередь на диске помещается больше операций. Диску заранее известен следующий запрос очереди. Таким образом, диск может запланировать операции заранее и обработать их в оптимальной последовательности. Так как приложение отправляет больше запросов на диск, диск может обрабатывать более параллельные операции ввода-вывода. В конечном счете приложение может достичь большего количества операций ввода-вывода в секунду. Так как приложение обрабатывает больше запросов, общая пропускная способность приложения также увеличивается.
Как правило, приложение может достичь максимальной пропускной способности с 8 до 16 и более невыполненных операций ввода-вывода на подключенный диск. Если глубина очереди является одной, приложение не отправляет достаточно операций ввода-вывода в систему, и он обрабатывает меньшее количество в данный период. Другими словами, меньше пропускной способности.
Например, в SQL Server задание значения MAXDOP для запроса, чтобы 4 сообщить SQL Server, что может использовать до четырех ядер для выполнения запроса. SQL Server определяет лучшее значение глубины очереди и количество ядер для выполнения запроса.
Оптимальная длина очереди
Очень высокое значение глубины очереди также имеет свои недостатки. Если значение глубины очереди слишком велико, приложение пытается выполнить очень высокий объем операций ввода-вывода в секунду. Если приложение не имеет постоянных дисков с достаточным объемом подготовленных операций ввода-вывода в секунду, то очень высокое значение глубины очереди может отрицательно повлиять на задержку приложения. В следующей формуле показана связь между операцией ввода-вывода в секунду, задержкой и глубиной очереди.
Не следует настраивать глубину очереди на любое большое значение, но оптимальное значение, которое может обеспечить достаточно операций ввода-вывода в секунду для приложения, не влияя на задержки. Например, если задержка приложения должна составлять 1 миллисекунда, глубина очереди, требуемая для достижения 5000 операций ввода-вывода в секунду, составляет QD = 5000 x 0,001 = 5.
Глубина очереди для полосатого тома
Для полосатого тома необходимо поддерживать достаточно высокую глубину очереди, чтобы каждый диск имеет пиковую глубину очереди по отдельности. Например, рассмотрим приложение, которое отправляет глубину 2 очереди и есть четыре диска в полосе. Два запроса ввода-вывода отправляются на два диска, а остальные два диска неактивны. Поэтому настройте глубину очереди, чтобы все диски могли быть заняты. В следующей формуле показано, как определить глубину очереди полосатых томов.
Регулирование
Хранилище класса Premium подготавливает указанное количество операций ввода-вывода в секунду и пропускную способность в зависимости от размеров виртуальных машин и размеров дисков, которые вы выбрали. В любой момент, когда приложение пытается управлять операцией ввода-вывода в секунду или пропускной способностью выше этих ограничений, чем может обрабатывать виртуальная машина или диск, хранилище класса Premium регулирует его. Результатом является снижение производительности в приложении, что может означать более высокую задержку, более низкую пропускную способность или меньше операций ввода-вывода в секунду.
Если хранилище класса "Премиум" не удается, приложение может полностью завершиться ошибкой, превысив возможности его ресурсов. Чтобы избежать проблем с производительностью из-за регулирования, всегда подготавливайте достаточные ресурсы для приложения. Учитывайте, что мы обсуждали в предыдущих разделах размеров виртуальных машин и размеров дисков. Тестирование — это лучший способ выяснить, какие ресурсы необходимо разместить в приложении.
Следующие шаги
Если вы хотите проверить производительность диска, ознакомьтесь со следующими статьями:
- Для Linux: Тестирование производительности приложения в Хранилище дисков Azure.
- Для Windows: проверка производительности диска
См. дополнительные сведения о доступных типах дисков:
- Для Linux: Выбор типа диска
- Для Windows: Выбор типа диска
Для пользователей SQL Server см. статьи о рекомендациях по производительности SQL Server: