Производительность Memory Tiering в VMware Cloud Foundation 9.x 11/08/2026 Поддержите VM Guru! USDT / TRC20, адрес: TCDP7d9hBM4dhU2mBt5oX2x5REPtq9QdU1 Пост:

Механизм Memory Tiering в VMware Cloud Foundation 9 использует два типа устройств памяти, чтобы нарастить её объём при существенно меньшей стоимости. Технология незаметно для виртуальных машин отслеживает активность обращений к памяти и удерживает часто используемые данные в быстрой и дорогой DRAM, вытесняя редко запрашиваемые страницы на второй, более медленный и дешёвый уровень на NVMe-накопителе.

Такой подход оптимизирует совокупную стоимость владения (TCO), сохраняя производительность на уровне систем исключительно на DRAM. Тестирование инженеров Broadcom с помощью отраслевых бенчмарков VMmark, Login Enterprise, DVD Store и HammerDB показало, что потери на разнообразных корпоративных нагрузках не превышают 10%. При этом плотность виртуальных машин удваивается, а экономия TCO достигает 40%.

Зачем понадобилось разделение памяти на уровни

Память нередко оказывается самой дорогой составляющей в стоимости сервера, а современные приложения потребляют её всё больше: растут объёмы данных, усложняются вычисления, добавляются требования к работе в реальном времени. При этом в продуктивных средах администраторы обычно избегают переподписки памяти из-за непредсказуемой деградации при срабатывании механизмов её возврата — ballooning, сжатия или свопинга. Эти техники не обладают интеллектом Memory Tiering и не умеют грамотно распоряжаться активной памятью, поэтому виртуальным машинам выделяют полный требуемый объём. Решение рабочее, но неэффективное: одновременно используется далеко не вся выделенная память, и дорогой ресурс простаивает.

В VCF 9.0 Memory Tiering предоставляет виртуальным машинам единое логическое пространство памяти, а под капотом управляет двумя её типами в зависимости от активности обращений:

• Tier 0 — высокоскоростная DRAM: дорогая и очень быстрая системная память, где остаётся активная, «горячая» память.
• Tier 1 — устройства NVMe: производительные SSD, более медленные и заметно более дешёвые, куда переносится неактивная, «холодная» память.

После включения тиринга информация о нём доступна в интерфейсе VMware vCenter: вкладка Configure > Hardware > Overview > Memory. Там отображается суммарный объём памяти и его распределение по уровням — например, 1 022,93 ГБ всего, из которых 511,46 ГБ приходится на Tier 0 и столько же на Tier 1. Настройка описана в документации vSphere, а бизнес-обоснование технологии разобрано в блоге VMware Cloud Foundation.

Архитектура

В систему добавлен модуль классификации и размещения страниц памяти. Он периодически обходит всю гостевую память, динамически вычисляя активность гостя, пропускную способность каждого уровня, квоты уровней для виртуальных машин и пороги активности страниц. Планировщик памяти опирается на эти показатели вместе с историей активности каждой гостевой страницы и размещает страницы на подходящем уровне.

Работа идёт в фоне. Механизм наблюдает за обращениями к памяти и определяет, какие страницы горячие, а какие холодные в заданном временном окне: например, горячими считаются те, к которым чаще всего обращались в течение последней минуты, — они остаются в DRAM, остальные уходят на NVMe. Классификация постоянно пересматривается: когда нагрузки проходят через смену фаз и активными становятся другие участки памяти, тиринг перераспределяет страницы, поддерживая эффективную загрузку DRAM.

Методика тестирования

Для оценки была смоделирована продуктивная среда на VCF 9.0 с включённым тирингом, на которой запускались популярные корпоративные бенчмарки, нагружающие процессор, память, хранилище и сеть.

Все цифры относятся к двукратной плотности виртуальных машин; при меньшей плотности влияние на производительность будет ниже или вовсе незаметным. Соотношение DRAM к NVMe по умолчанию в VCF 9.0 составляет 1:1 — при 1 ТБ DRAM можно получить ещё около 1 ТБ памяти на NVMe. Во всех тестах применялось именно оно.

Результаты представлены через три группы метрик: прирост плотности виртуальных машин, разница в производительности относительно системы только на DRAM и загрузка процессора — как в части дополнительно утилизируемых ресурсов, так и в части накладных расходов тиринга. Чтобы точнее отразить последние, большие страницы (large pages) на хосте везде оставались отключёнными — это настройка по умолчанию для ESX с тирингом.

Метрика активной памяти в разных инструментах называется по-разному: в esxtop это TCHD (touched memory), причём общехостового счётчика нет и значения всех машин приходится суммировать; в vCenter — счётчик Active в разделе Monitor > Performance > Overview > Memory; в VCF Operations — Metrics > Memory > Guest Active.

VDI: тестирование с Login Enterprise

Login Enterprise от Login VSI — отраслевой стандарт для оценки ёмкости и производительности VDI: виртуальные пользователи имитируют реальных сотрудников и замеряют время отклика на каждое взаимодействие. Инфраструктурой рабочих столов служила Omnissa Horizon. Из двух преднастроенных профилей выбран knowledge worker как самый тяжёлый и распространённый: он включает девять приложений, среди которых Word, PowerPoint, Excel, Outlook, браузер Edge и потоковое видео. Главная метрика — оценка пользовательского опыта EUX, складывающаяся из таймеров типичных действий: отзывчивости приложений, обработки клавиатурного ввода, ресурсоёмких вычислений и задержек дисковых операций.

Тесты шли в двух вариантах провижининга: с отключённым межмашинным Pshare (ModeB) и с включённым (ModeA). В ModeA мгновенные клоны при создании клонируются от родительской ВМ и разделяют её память; в ModeB — от выключенной ВМ-реплики, без разделения. Режимы различаются не только поведением разделения страниц, но и работой алгоритма тиринга, поэтому в исследование вошли оба. Одиночный узел — Dell PowerEdge R760 с двумя Intel Xeon 8480 (56 ядер на сокет) и 1 или 2 ТБ DRAM, устройство тиринга Dell Ent NVMe P5620 MU на 1,6 ТБ, рабочие столы Windows 11 на 2 vCPU.

В режиме ModeB машинам выделялось 8 ГБ RAM: при 1 ТБ DRAM это давало около 120 VDI-сессий, а добавление 1 ТБ на NVMe позволило довести их число до 240. Потери составили менее 6% относительно варианта только на DRAM (1 ТБ). Оценка EUX снизилась с 8,6 до 8,3 при сравнении дорогой системы с 2 ТБ DRAM и заметно более дешёвой с 1 ТБ DRAM плюс 1 ТБ тиринга — падение всего около 3,5%. Загрузка процессора выросла с 63,5% до 74%: перемещение данных между уровнями имеет свою цену.

Время отклика приложений изменилось незначительно: Outlook открывался за 1,10 секунды против 0,94 на чистой DRAM, запуск Excel и PowerPoint замедлился примерно на 0,002 секунды. Активная память хоста держалась в диапазоне 420–450 ГБ — около 50% от ёмкости DRAM. Динамика EUX по мере роста числа сессий тесно коррелирует с показателями NVMe: когда задержка поднималась выше 200 микросекунд, метрики CPU score и Generic application score проседали, а при стабилизации около 200 микросекунд снова росли вместе с общей оценкой.

В режиме ModeA машинам выделялось 6 ГБ: выигрыш от разделения страниц оставляет алгоритму больше пространства для масштабирования. Число сессий выросло с 160 до 320. Оценка EUX снизилась с 8,7 до 7,9, но причина не в тиринге: в первом случае процессор работал с турбо-ускорением в 1,5 раза, а при 320 машинах из-за высокой загрузки его частота была близка к номинальной. С включёнными большими страницами EUX составила 8,3 при загрузке CPU 84,5%, с отключёнными — 7,9 при загрузке 90%. Сравнение 8,3 и 7,8 даёт потерю 6%, а если брать только малые страницы, падение с 7,9 до 7,8 — порядка 1%. Столь низкие потери согласуются с задержкой NVMe всего в 100 микросекунд при пропускной способности чтения заметно ниже 100 МБ/с.

Многоузловые тесты шли на трёхузловом кластере vSAN архитектуры ESA с RAID 5 на серверах Dell PowerEdge R660 с двумя Intel Xeon 6430 (32 ядра на сокет) и 512 ГБ DRAM: четыре NVMe в каждом хосте отданы под vSAN, пятое — под тиринг. В режиме ModeB тиринг позволил удвоить плотность машин за счёт добавления 512 ГБ NVMe, при этом оценка EUX относительно 1 ТБ DRAM снизилась лишь на 8%. Пропускная способность чтения NVMe составляла около 200 МБ/с, задержки стартовали со 100 микросекунд, поднимались до 400 по мере добавления сессий и опускались до 200 в установившемся режиме.

Во втором наборе тестов число рабочих столов увеличили до 200 на хост, то есть до 600 на кластер, с мгновенными клонами по 5 ГБ и провижинингом ModeA. Оценки EUX для DRAM (1 ТБ) и Memory Tiering (1 ТБ) составили 6,9 и 7,0 при загрузке процессора выше 90% в обоих случаях — то есть удвоение плотности прошло вовсе без потерь производительности. Задержки устройства тиринга достигали 150 микросекунд, пропускная способность держалась около 200 МБ/с, активная память доходила до 320 ГБ — 62,5% от доступной DRAM.

Корпоративные приложения: VMmark

VMmark оценивает производительность и масштабируемость виртуализованных ЦОД. Бенчмарк объединяет типовые приложения (standby, DVD Store и Weathervane) в блоки-«тайлы»; один тайл состоит из 19 Linux-машин с нагрузками от 1 до 8 vCPU и от 4 до 250 ГБ памяти. Использовалась конфигурация с большим объёмом памяти: размер ВМ с базой увеличен с 32 до 250 ГБ, размер базы — со 100 до 300 ГБ, время раздумий — с 1 до 1,5 секунды, чтобы сделать тест в большей степени memory-intensive, чем compute-intensive. Тестовая система — два Intel Xeon 8592 по 64 ядра с 1 или 2 ТБ DRAM, устройство тиринга Samsung PM9A3 на 3,84 ТБ, на тайл приходилось 376 ГБ памяти и 31 vCPU.

Итоговая оценка агрегирует метрики пропускной способности приложений с нормализацией по весу каждого, а тайлы добавлялись до появления сбоев качества обслуживания. Конфигурация только на DRAM (1 ТБ) выдержала 57 виртуальных машин в трёх тайлах, конфигурация с тирингом (2 ТБ) — 114 машин в шести тайлах.

Сравнение трёх конфигураций показывает накладные расходы технологии по производительности и по процессору. В базовом варианте загрузка CPU была ограничена нехваткой памяти, тогда как при большем её объёме сервер утилизировался значительно плотнее. Производительность тиринговой конфигурации оказалась менее чем на 5% ниже варианта с 2 ТБ DRAM — притом что хост располагал лишь 1 ТБ реальной DRAM. Пропускная способность чтения NVMe была чуть выше рекомендованной, но задержка оставалась около 100 микросекунд, и производительность не пострадала.

Базы данных: SQL Server, Oracle и MySQL

Нагрузки баз данных требовательны к процессору, дискам и памяти одновременно, что делает их хорошим полигоном для проверки тиринга. Тестировались СУБД, типичные для развёртываний VCF: Microsoft SQL Server 2022, Oracle Database 21c и MySQL 8.0.

SQL Server измерялся с помощью HammerDB 5.0 (профиль TPC-C, 1000 складов, 125 виртуальных пользователей) на Dell PowerEdge R760 с 512 ГБ или 1 ТБ DRAM и виртуальными машинами на 8 vCPU и 80 ГБ. На хосте с 512 ГБ DRAM удавалось запустить не более 6 машин — при попытке добавить больше транзакции завершались по таймауту. Расширение памяти до 1 ТБ с помощью тиринга позволило удвоить их число. Прирост производительности при переходе от 512 ГБ к 1 ТБ DRAM составил 1,6 раза (нелинейность объясняется факторами, не связанными с тирингом), а падение при сравнении DRAM (1 ТБ) и тиринга (1 ТБ) не превысило 10%.

Активная память в установившемся режиме составляла около 256 ГБ, а процессорная нагрузка снизилась, поскольку машины ожидали обслуживания промахов DRAM накопителем. Задержка чтения NVMe на фазе разогрева держалась в районе 300–400 микросекунд и стабилизировалась примерно на 200 в измерительной фазе. Показательна корреляция: пока активная память на разогреве превышала 50% от DRAM, число транзакций в минуту проседало; когда она устоялась на уровне около 50%, показатель TPM вырос и стабилизировался.

Oracle Database 21c тестировалась на Oracle Enterprise Linux 8.8 с нагрузкой DVD Store 3.5: 600 пользователей на машину, время раздумий 5 секунд, база около 200 ГБ. Система — односокетный AMD EPYC 9755 на 128 ядер с 768 ГБ DRAM, виртуальные машины на 16 vCPU и 192 ГБ. Проверялись три сценария: 768 ГБ DRAM, 1,5 ТБ DRAM и тиринговый вариант из 768 ГБ DRAM плюс 768 ГБ NVMe. Число машин подбиралось так, чтобы полностью законтрактовать память: 4 машины на 768 ГБ и 8 машин на 1,5 ТБ. Результат — рост с 4 до 8 машин при потере менее 5% относительно 1,5 ТБ чистой DRAM.

Особенно показательна динамика процессора: в базовом сценарии его загрузка была ограничена 43%, а с тирингом достигла 85%. Это наглядно демонстрирует способность технологии раскрывать ёмкость хоста там, где система упирается в память, а процессорные циклы простаивают. Активная память по счётчику touched memory в esxtop в среднем составляла около 400 ГБ — чуть больше 50% от DRAM, а средняя задержка чтения NVMe — 86 микросекунд при пропускной способности около 35 МБ/с.

MySQL 8.0 на RHEL 9.4 тестировался тем же HammerDB на машинах с 14 vCPU и 60 ГБ; плотность также удалось удвоить при потере менее 5%. Параметром keyingandthinktime здесь регулировались нагрузка на процессор и объём активной памяти. При времени раздумий 10 миллисекунд загрузка CPU в базовом сценарии на 512 ГБ была высокой — 70%, активная память достигала 286 ГБ (около 55% ёмкости DRAM); при удвоении числа машин в работу вовлекались 224 vCPU и процессор доходил почти до насыщения, что объясняет нелинейное масштабирование. Когда время раздумий подняли до 45 миллисекунд, активная память выросла до 410 ГБ (около 80% DRAM), а загрузка CPU снизилась до 45% — благодаря запасу по процессору удвоение плотности дало двукратный рост пропускной способности. Примечательно, что даже при активной памяти на уровне 80% потери оказались минимальными: вероятно, большое время раздумий поглощало задержки NVMe.

Влияние на vMotion

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

Тестировался Dell PowerEdge R750 с двумя Intel Xeon 8380 и адаптерами Mellanox 100GbE. Четыре машины на 12 vCPU и 48 ГБ работали под RHEL 8.1 с Oracle 21c и SGA 43 ГБ, нагрузка создавалась HammerDB; чтобы активировать тиринг, память хоста искусственно уменьшили до 164 ГБ. В сценарии эвакуации хоста с одновременной миграцией всех четырёх машин пропускная способность Oracle оставалась практически неизменной: наблюдался единственный провал в фазе переключения, но простой не превышал секунды.

Тиринг увеличивает длительность vMotion, но на производительности машин это не сказывается: замедление приходится на фазу предварительного копирования, когда холодные страницы читаются с более медленного NVMe.

Эксплуатация и мониторинг

Чтобы Memory Tiering обеспечивал хорошую производительность, важны три вещи: следить за активной памятью, следить за задержкой чтения NVMe и правильно выбрать сам накопитель.

Активную память рекомендуется удерживать не выше 50% от ёмкости DRAM хоста; для некоторых нагрузок она может быть выше без каких-либо проблем. В диапазоне от 50% до 75% необходимы тестирование и наблюдение за конкретной нагрузкой. Выше 75% в большинстве случаев следует ожидать существенных потерь.

Пока задержка чтения накопителя остаётся ниже 200 микросекунд, производительность тиринга ожидаемо хорошая. В диапазоне 200–400 микросекунд возможны проблемы, а выше 400 влияние на нагрузки становится заметным.

При выборе накопителя стоит ориентироваться на высокий класс износостойкости D и высокий класс производительности — более 100 000 операций записи в секунду при DWPD = 3 — а также на больший объём.

Нужные метрики доступны в vCenter на странице Advanced Performance через Chart Options. Пропускная способность записи показывает перенос холодных страниц на NVMe, чтения — извлечение страницы, которая снова стала активной, но отсутствует в DRAM; если чтение превышает 200 МБ/с, стоит присмотреться к задержкам. На качественном накопителе они остаются заметно ниже 200 микросекунд даже при 400 МБ/с, тогда как некоторые другие модели на схожем трафике показывают около 300. Чтобы понять, почему конкретная машина работает медленно, стоит посмотреть пропускную способность чтения в её разрезе: всплывающее окно графика позволяет вывести несколько машин сразу. Активная память хоста доступна там же, а также в VCF Operations.

Дополнительно рекомендуется обеспечить достаточный запас по процессору под накладные расходы тиринга; следить, чтобы загрузка CPU на нетиринговых хостах кластера не превышала 75%, иначе эффективность технологии может снизиться; и не использовать с Memory Tiering «монструозные» виртуальные машины — крупнее 32 vCPU и 512 ГБ DRAM.

Выводы

Memory Tiering — важное усовершенствование VCF 9, позволяющее за счёт добавления NVMe SSD получить значительно больший объём памяти при существенно меньшей стоимости по сравнению с использованием только DRAM. Технология решает проблему растущей стоимости памяти в ЦОД, оптимизируя совокупную стоимость владения серверами и нагрузками, ограниченными объёмом памяти.

Измерения на нескольких бенчмарках дали стабильно хорошие результаты: двукратный рост плотности виртуальных машин и экономия TCO до 40%. Тиринг также высвобождает процессорные ресурсы хоста, которые при дефиците памяти иначе остались бы неиспользованными, а простой машин при vMotion неизменно остаётся ниже одной секунды. Оптимальную производительность обеспечивает мониторинг двух показателей: активную память в идеале следует удерживать ниже 50% от объёма DRAM, а задержку устройства нижнего уровня — ниже 200 микросекунд.

Больше подробностей - в документе "Memory Tiering Performance VMware Cloud Foundation 9.0".