Когда приложение перестает справляться с растущей нагрузкой, появляется желание «залить» ресурсами виртуальную машину. Однако производительность не всегда упирается в количество vCPU или объем памяти, поэтому в этом случае увеличение конфигурации приведет лишь к росту затрат. Давайте разберемся, почему увеличение ресурсов виртуальной машины не помогает и всегда ли «соседи по виртуалке» влияют на работающее приложение.
Эта статья не ультимативный гайд на все случаи жизни, а обзор возможностей облака Selectel, которые помогут решить специализированные задачи, когда речь идет о высоких нагрузках.
Материал подготовлен по следам вебинара «Как получить максимум производительности из облака».
Как устроены облачные серверы с выделенными ядрами
«Обычные» ядра
По умолчанию в облаках используется стандартная политика, при которой каждая виртуальная машина (ВМ) занимает определенное количество процессорного времени и оперативной памяти. Но при этом не регламентируется, какие именно логические ядра гипервизора используются и в какой области оперативной памяти хранится оперативная память виртуальной машины.
Иными словами, гипервизор выделяет ядро по требованию виртуальной машины. Из-за этого ВМ может мигрировать между вычислительными ядрами гипервизора. Эта политика универсальна и подходит для большинства слабонагруженных задач, в том числе:
- API-, веб- и микросервисов с низкой нагрузкой;
- тестовых и разработческих сред;
- и других сервисов, для которых незначительны задержки.
Отсутствие детерминированности и постоянная миграция между вычислительными ядрами негативно влияет только на высоконагруженные сервисы (HighLoad) и на задачи реального времени (RealTime), поскольку им важна не абсолютная производительность, а стабильность и предсказуемость производительности ядра.
Давайте рассмотрим, почему обычные ядра не подходят для Highload и Realtime. На это есть три причины.
Кэши процессора. При миграции потока виртуальной машины между ядрами гипервизора содержимое кэша процессора не мигрирует. Следовательно, при каждой миграции нужно потратить дополнительное процессорное время на кэширование контекста виртуальной машины.
NUMA-локальность. В мультипроцессорных системах каждый физический процессор имеет прямой доступ только к части оперативной памяти, называемой локальной памятью. Доступ к локальной памяти другого процессора — только через общение по межпроцессорной шине. Такая архитектура называется NUMA (англ. Non-Uniform Memory Access — неоднородный доступ к памяти), а связка «процессор и локальная память» — NUMA-узлом.
Очевидно, что коммуникация с другим процессором и запросом чужой локальной памяти медленнее, чем обращение к собственной локальной памяти. Хотя коммуникация между процессорами очень быстрая, в высоконагруженных приложениях даже такие задержки могут быть критичными.
Потоки ввода-вывода. Все операции ввода-вывода выполняются на тех же ядрах, что и потоки виртуальных машин.
В большинстве повседневных задач влияние описанных факторов минимально, но когда речь идет о высоких нагрузках, обычные ядра могут перестать удовлетворять требованиям. Вот тут на помощь приходят выделенные ядра.
Выделенные ядра
Выделенные ядра подходят клиентам с высокими требованиями к задержкам и стабильности производительности, например, в высоконагруженных базах данных. Они позволяют устранить негативное влияние особенностей обычных ядер.
- Никаких миграций между ядрами гипервизора, следовательно, меньше промахов в процессорных кэшах.
- Можно настроить NUMA-топологию, чтобы ядра виртуальной машины были в одном NUMA-узле.
- На выделенные ядра не попадают I/O-потоки других виртуальных машин.
Ниже рассмотрим каждый пункт подробнее.
Кэши процессора. Как мы выяснили, в обычных ядрах кэши процессора могут использоваться несколькими виртуальными машинами, размещенными на одном физическом ядре. Выделенные ядра, напротив, закреплены за конкретной виртуальной машиной, поэтому ее вычислительные потоки не конкурируют с потоками других ВМ. Это снижает влияние соседних нагрузок и обеспечивает более стабильную производительность.
NUMA-локальность. В этом случае вычислительные ресурсы — vCPU и RAM — будут размещены локально в пределах одной NUMA-ноды. Исключение составляют конфигурации, которые физически невозможно разместить на одной NUMA-ноде.
В ситуациях, когда виртуальная машина занимает больше ресурсов, чем доступно в рамках одного NUMA-узла, применяется равномерное разделение между несколькими NUMA-узлами.
Закрепление ядра за виртуальной машиной позволяет снизить шум от постоянных переключений контекстов, сохранить кэши и исключить влияние соседей на критичные к задержкам задачи.
Потоки I/O. Как и vCPU, I/O-потоки виртуальных машин выполняются на ядрах гипервизора вместе с потоками виртуальных машин. При высокой нагрузке на CPU и интенсивных операциях ввода-вывода может возникнуть эффект «шумного соседа». Гипервизор будет тратить ресурсы на обработку I/O-потоков, а это негативно сказывается на производительности других виртуальных машин.
Выделенные ядра помогают решить и эту проблему. На ядрах, предназначенных для виртуальной машины, выполняются только vCPU и I/O-потоки ВМ, для которой они выделены. Это обеспечивает предсказуемость нагрузки и устраняет эффект «шумного соседа».
Сравнение обычных и выделенных ядер в бенчмарках
Чтобы не быть голословными, мы протестировали наши облачные серверы на обычных и выделенных ядрах. Для этого мы выбрали четыре инструмента.
- sysbench,
- Geekbench 6,
- pgbench,
- redis-benchmark.
В тестировании разных типов участвовали одинаковые конфигурации виртуальных серверов: 2 vCPU, 2 ГБ RAM. Единственное отличие серверов — вид ядер.
sysbench
Sysbench — популярный модульный кроссплатформенный бенчмарк для Linux. Он позволяет быстро оценить производительность вашего сервера в многопоточном режиме, проверяя отдельно производительность процессора и памяти.
Для тестирования процессора использовалась следующая команда:
sysbench cpu run –cpu-max-prime=20000 –threads=2 –time 60
На изображении представлены результаты множественных запусков теста. Легко заметить, что выделенные ядра показывают стабильно одинаковый результат между всеми запусками, в то время как на обычных ядрах замедление составляет до 10%.
Для тестирования процессора использовалась команда:
sysbench memory --threads=4 --time=10 --memory-block-size=1K --memory-total-size=100G run
На гистограмме легко заметить, что обычные ядра виртуальных не всегда получают логические ядра гипервизора в том же NUMA-узле, из-за чего пропускная способность ниже, чем у выделенных ядер. Она составляет до 70% от ожидаемой в 10% худших тестов.
Geekbench 6
Geekbench 6 — это популярная кроссплатформенная программа для тестирования производительности процессора. Она оценивает мощность в одноядерном и многоядерном режимах, используя реалистичные сценарии: обработку фото, видеомонтаж и веб-серфинг.
Как и в случае с sysbench, в тесте Geekbench выделенные ядра показывают стабильность при множественных запусках, причем как в однопоточном тестировании, так и в многопоточном. Обычные ядра показывают 90% от ожидаемой производительности в однопоточном тестировании и 95% — в многопоточном.
pgbench
pgbench — это стандартная утилита для проведения нагрузочного тестирования баз данных PostgreSQL. Она многократно выполняет заданную последовательность SQL-запросов в несколько параллельных потоков и клиентов, после чего вычисляет итоговую производительность в транзакциях в секунду (TPS). Тест запускался следующей командой.
pgbench -c 20 -L 400 -j 2 -T 60 -P 5 -b select-only -M prepared -d db
Разница между девяностым и десятым перцентилем для производительности базы данных у обычных ядер составляет 16%, в то время как у выделенных ядер — всего процент.
Что касается задержек, то при интенсивной CPU- и I/O-загрузке гипервизора средняя задержка на обычных ядрах возросла почти в два раза. В то время как у выделенных ядер изменения составили всего несколько процентов.
redis-benchmark
redis-benchmark — это встроенная утилита командной строки для оценки производительности серверов Redis. Она имитирует одновременную работу множества клиентов, отправляющих тысячи типовых запросов (чтение, запись, проверка ключей), и выдает отчет о количестве выполненных операций в секунду (IOPS) и задержках.
Так как Redis — in-memory база данных, тестирование проводилось в двух состояниях гипервизора: при малой нагрузке соседями (LD) и при высокой нагрузке (HD).
Как и ожидалось, выделенные ядра полностью не зависят от активности соседей и показывают одинаковые результаты как при высокой нагрузке гипервизора, так и при низкой. А вот обычные ядра в этом тесте потеряли почти треть вычислительной мощности.
С задержками ситуация чуть более интересна. Даже выделенные ядра чувствуют нагрузку гипервизора и 1% худших запросов отличается от среднего на 12%. Однако обычные ядра больше подвержены влиянию соседей, разница между худшими и средними запросами составляет почти 50%.
Сравнение с другими облачными провайдерами
Мы сравнили свои результаты с результатами других облачных провайдеров и выяснили, что инфраструктура Selectel — одна из самых производительных на рынке.
Арендовать сервер с выделенными ядрами так же легко, как и сервер с обычными ядрами. Зайдите в панель управления Selectel и перейдите в продукт Облачная платформа. Нажмите кнопку Создать сервер.
Конфигурации с выделенными ядрами доступны на вкладке Standard и High Freq.
Выделенный облачный сервер
В случае если вам нужна максимальная производительность, у вас особые требования по изоляции от соседей или запрос на уникальную конфигурацию, можно выбрать ультимативный вариант — выделенный облачный сервер (Dedicated Cloud Server, DCS). Это виртуальная машина размером с гипервизор, на котором она развернута.
Выделенный облачный сервер обладает достоинствами виртуальных машин, но не требует физического обслуживания, как выделенный сервер. При этом он совсем не имеет соседей как обычная виртуальная машина.
При изучении выделенного облачного сервера может возникнуть опасение, что гипервизор вносит существенные накладные расходы. Мы сравнили DCS и выделенный сервер одинаковой конфигурации на трех описанных ранее тестах производительности.
Результаты тестов показали, что облачные технологии вносят накладные расходы порядка одного-двух процентов. Соответственно, выделенные облачные серверы практически не уступают по производительности Bare Metal. При этом они сохраняют все преимущества облака: быстрое масштабирование, оплату по потреблению, использование прерываемых серверов и делегирование обслуживания провайдеру.
Выделенный облачный сервер сочетает производительность выделенного физического сервера с гибкостью облачной инфраструктуры. Вы получаете ресурсы без эффекта «шумного соседа», сохраняя возможность масштабирования, оплаты по потреблению и использования прерываемых ВМ.
Заключение
Облачные серверы Selectel позволяют решать задачи любого уровня сложности — от стандартных нагрузок до требовательных приложений, которым важна максимальная производительность, стабильность и изоляция ресурсов.
Выделенные ядра обеспечивают предсказуемую и стабильную производительность. Их использование оправдано для высоконагруженных приложений и задач реального времени. В остальных случаях разница с обычными ядрами будет менее заметной.
Выделенный облачный сервер даст возможность заказать выделенный сервер с удобствами облачного сервера, но без необходимости обслуживания «железа». Этот вариант подходит для нестандартных конфигураций или при необходимости соблюдения требований по изоляции в облачных средах.
