Назад | Перейти на главную страницу

Производительность ввода-вывода Azure

У нас есть несколько виртуальных машин Windows Server, которые мы используем для разработки .NET и Java и обеспечения качества. Я считаю Azure привлекательной по очевидным причинам, но в основном из-за возможности сократить непроизводительные часы, затрачиваемые на обслуживание окружающей среды.

Функционально, после устранения проблем с системным идентификатором в некоторых приложениях (лицензирование и др.), Все в порядке, но производительность несколько невысока:
Нашей системе требуется около 2 минут для построения решения при работе на Hyper-V или ESXi, но машина Azure A3 требует до 12 минут на выполнение той же сборки.
Монитор ресурсов показывает, что большую часть времени машина находится в режиме ожидания ввода-вывода при чтении диска.

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

Размер виртуальных машин Azure зависит от их ОЗУ и ядер ЦП, но всем размерам явно не хватает производительности хранилища, что всегда становится главным виновником, независимо от того, сколько ядер и памяти вы используете для виртуальной машины.

Два решения:

  • Для нормального использования просто подключите к виртуальной машине как можно больше дисков с данными и настройте их в RAID 0 в гостевой системе; Ввод-вывод ограничен на уровне диска, поэтому больше дисков = больше операций ввода-вывода. Используйте эти диски для реальной работы, не кладите ничего, кроме O.S. на системном диске (что в любом случае рекомендуется). Эта стратегия не требует дополнительных затрат, потому что за хранилище Azure взимается плата на основе фактически используемого пространства: количество виртуальных дисков и их кажущийся размер не имеют значения. (*)
  • если ты действительно нужна производительность диска, используйте премиум-хранилище.

(*) Если вас беспокоит использование RAID 0, не беспокойтесь. Это виртуальные диски, и их целостность уже гарантируется нижележащим уровнем хранения. RAID 0 используется только для группировки их в один логический том с лучшей производительностью.

Вы не должны использовать диск c для приложений:

http://blogs.msdn.com/b/igorpag/archive/2014/10/23/azure-storage-secrets-and-linux-i-o-optimizations.aspx

Диск C оптимизирован для времени загрузки, а не для большого количества операций ввода-вывода.

Поскольку каждый диск регулируется по количеству операций ввода-вывода в секунду (обычно 500 операций на диск), вы можете использовать их много (до 8 на A3) или использовать машину серии d с SSD (D3: 12000IOPS). Обратите внимание, что вы должны использовать d-привод что не гарантирует сохранение данных чтобы иметь скорость SSD:

http://azure.microsoft.com/blog/2014/10/06/d-series-performance-expectations

Или вы можете заплатить $ $ $ и использовать большой двоичный объект хранилища премиум-класса (~ 100 $ / месяц за 5000 IOPS), чтобы иметь постоянное хранилище.

Azure - это общая служба. Вы должны ожидать случайных изменений производительности в зависимости от нагрузки на гипервизор, на котором вы работаете (который вы не можете контролировать), и буквально бесконечного множества других факторов (которые вы также не можете контролировать).

Если производительность (и согласованность) имеет решающее значение, разместите свою собственную среду на собственном оборудовании.

Мы переместили всю нашу производственную среду в Azure около 6 месяцев назад. У нас есть сервер сборки, который запускает несколько сборок ежедневно, и в зависимости от продолжительности отдельных задач сборки от сборки до сборки я могу сказать вам, что «производительность» довольно стабильна. Я также могу подтвердить ваши выводы о том, что процессы, в которых не используется несколько ядер (например, выполнение модульных тестов), выполняются на виртуальной машине Azure примерно в 6 раз медленнее, чем на локальном ПК для разработки.

Короче говоря, когда вы запускаете процессы на одном ядре, ваш локальный компьютер всегда будет превосходить виртуальную машину Azure. Я думаю, что Azure лучше подходит для обработки задач, в которых задействовано несколько ядер (например, база данных или веб-сервер), потому что вы можете легко масштабировать количество ядер по мере необходимости.