Эксперты в подборе IT-оборудования
Одно-сокетный сервер с 1,2 ТБ оперативной памяти звучит как опечатка в спецификации. Но если перед вами ASUS RS520QA-E13-RS8U с процессором AMD EPYC 9755 и четырьмя контроллерами CXL Type 3, это ровно то, что покажет free -mh. Двенадцать штатных DIMM-слотов плюс восемь через CXL-контроллеры - двадцать планок DDR5 на одном сокете. О том, чем серверная память вообще отличается от десктопной и какие типы модулей применяются в серверах, у нас есть отдельный разбор.
Ниже - что такое CXL и зачем он нужен, когда он оправдан, а когда нет, и как диагностировать такую память от BIOS до продакшн-мониторинга.
CXL (Compute Express Link) - открытый стандарт связи процессора с памятью и ускорителями поверх физического уровня PCI Express. Ключевое слово здесь - когерентность: процессор работает с CXL-памятью как с обычной оперативной, а не как с диском или сетевым хранилищем. Никаких специальных вызовов из приложения, никакой ручной подкачки. Адресное пространство, обычные обращения к памяти.
Зачем это понадобилось. Число процессорных ядер росло быстрее, чем количество каналов памяти, и на плотных серверах упёрлось в физику: в половину ширины юнита просто не помещается 24 DIMM-слота. Добавить память было некуда - слоты кончились. CXL обходит ограничение архитектурно: ёмкость приходит по линиям PCIe, которых на серверном процессоре много.
Практическая разница между «добавить планок» и «добавить CXL» такая:
| Штатные DIMM | CXL Type 3 | |
|---|---|---|
| Подключение | Каналы памяти процессора | Линии PCIe |
| Ограничение | Число слотов на плате | Число линий и слотов PCIe |
| Задержка | Базовая | Выше на десятки наносекунд |
| Видимость для ОС | Обычная память | Отдельный узел NUMA без ядер |
| Частота в этой машине | До DDR5-6400 (1DPC) | DDR5-4400 (2DPC) |
Последняя строка важнее, чем кажется, и к ней мы вернёмся в разделе про замеры.
Честный ответ: CXL Type 3 расширяет ёмкость, но не ускоряет работу. Он закрывает задачу «данные не помещаются». Задачу «данные обрабатываются медленно» он не закрывает.
Оправдан, когда объём важнее задержки. Аналитика по большим наборам, in-memory базы, где рабочий набор перерос штатные слоты, инференс крупных моделей (тут стоит посмотреть и на то, как собрать сервер под ИИ целиком), EDA-симуляции. Общий признак - вы упираетесь в нехватку памяти и вынуждены либо резать задачу на части, либо разносить её по нескольким узлам с обменом по сети. Обмен по сети между узлами дороже по задержкам, чем обращение к CXL внутри одной машины, поэтому здесь размен выгоден.
Не оправдан для нагрузок, чувствительных к задержке в каждом обращении: горячий кэш, торговые системы, всё, где счёт идёт на микросекунды и профиль доступа случайный. Дополнительные десятки наносекунд на каждое обращение там дадут о себе знать.
Не оправдан и тогда, когда штатных слотов ещё хватает. CXL добавляет в систему контроллеры, прошивки и отдельную ветку диагностики - если задачу закрывает докупка обычных модулей, стоит закрыть её обычными модулями. Отдельно оцените, сколько оперативной памяти реально нужно серверу: нередко выясняется, что до потолка платформы ещё далеко.
Прежде чем Linux увидит CXL-устройства, их нужно корректно активировать в UEFI. В серверах ASUS на платформе AMD EPYC 9004 (Genoa) и 9005 (Turin) настройки CXL спрятаны в разделе AMD CBS (Common BIOS Settings). Путь выглядит примерно так: Advanced → AMD CBS → DF Configuration → Memory Addressing.
Здесь нас интересуют три вещи. Первая - включение CXL SPM (System Physical Memory). Этот параметр определяет, будет ли CXL-память отображаться как системная RAM или останется в режиме DAX-устройства. Вторая - настройка bifurcation для PCIe-слотов. CXL-контроллеры подключаются x8-линками, поэтому для четырёх контроллеров нужно разделить x16-слоты в режим x8/x8. Третья - обход ограничений 2DPC: двенадцать штатных слотов остаются в режиме 1DPC с полной скоростью, а дополнительная ёмкость приходит по PCIe. Почему один модуль на канал выгоднее двух - разбирали отдельно на платформе EPYC.
Отдельный нюанс - порядок инициализации. AMD EPYC 9005 поддерживает CXL 2.0, и устройства обнаруживаются на этапе POST. Если в BMC (ASUS ASMB12-iKVM на базе ASPEED AST2600) отображается корректное количество памяти, включая CXL-модули, BIOS отработал штатно. Когда что-то пошло не так, BMC покажет POST-код ошибки прямо на дисплее материнской платы - ASUS предусмотрительно не убрали его даже в сверхплотном 2U4N дизайне. EPYC 9005 работает с CXL 2.0, а что изменилось в стандарте CXL 3.0 и что из этого появится в следующих платформах, мы разбирали отдельно.
Ещё один момент, который часто упускают: версия AGESA (AMD Generic Encapsulated Software Architecture) в прошивке. Если CXL-модули не определяются после корректной настройки bifurcation, обновите BIOS до последней версии с сайта ASUS. Разница между версиями прошивки бывает критичной.
После загрузки ОС первая проверка - убедиться, что ядро видит CXL-устройства. Поддержка CXL появилась в ядре Linux начиная с версии 5.12, но для полноценной работы с Type 3 рекомендуется 6.1+. Проверка начинается с lspci: фильтруем по ключевому слову CXL и смотрим, сколько устройств обнаружено. На системе с четырьмя контроллерами вы увидите четыре строки. Если передать lspci флаг расширенной детализации (-vv) и адрес конкретного устройства, утилита покажет тип устройства, поддерживаемые протоколы (CXL.mem для Type 3), а также ширину и скорость PCIe-линка.
Дальше - NUMA-топология. CXL-память отображается как отдельный узел NUMA без привязанных ядер, и это фундаментальное отличие от штатной DRAM. Утилита numactl --hardware выведет полную картину: количество узлов, объём памяти в каждом, привязку ядер и матрицу расстояний между узлами.
На одно-сокетной системе с CXL вы увидите два узла: node 0 со всеми ядрами и 768 ГБ (12 × 64 ГБ), и node 1 без ядер с 512 ГБ (8 × 64 ГБ CXL). Числа в матрице расстояний отражают относительную задержку между узлами. Типичное значение для CXL-узла - в 1,7-2 раза выше, чем для локальной DRAM: матрица с node distances 10 для локального узла и 17-20 для CXL говорит о корректной настройке.
Для визуализации топологии пригодится lstopo из пакета hwloc - она генерирует графическую карту системы, где видны ядра, кэши, каналы DRAM и CXL-устройства с их связью через PCIe.
Ещё один полезный инструмент - cxl-cli, который ставится вместе с пакетом ndctl. Команда cxl list с флагами для отображения memdev-устройств и human-readable формата покажет размер каждого CXL-устройства, его адресное пространство и режим работы (ram или devdax). Это быстрый способ проверить, что все модули определились корректно и доступны ядру.
CXL Type 3 - расширение DRAM, а не её замена. Между контроллером CXL и процессором стоит PCIe-линк, и он добавляет задержку. Разница в латентности между локальной DDR5 и CXL-памятью составляет порядка 70 наносекунд - это цена за прохождение через контроллер и мост.
Вторая составляющая разрыва, о которой забывают: частота самих модулей. По спецификации ASUS штатные каналы этой машины работают на скорости до DDR5-6400 в режиме 1DPC, а восемь CXL-планок - на 4400 MT/s в режиме 2DPC. Это уже полуторакратный разрыв по частоте, ещё до всякого PCIe. Если вы прогоните STREAM и увидите разрыв больше ожидаемого, не спешите винить PCIe: часть разницы даёт именно частота.
Инструменты для измерения на своей системе:
| Инструмент | Что измеряет | Привязка к NUMA |
|---|---|---|
| STREAM | Пропускная способность (Copy, Scale, Add, Triad) | numactl --membind= |
| Intel MLC | Латентность и bandwidth под нагрузкой | Встроенная привязка к узлам |
| stressapptest | Стресс-тест памяти с проверкой паттернов | --memory_channel |
| multichase | Латентность при pointer-chasing | Привязка через taskset |
Для сравнения CXL-памяти с локальной DRAM бенчмарки запускаются через numactl с привязкой аллокаций к конкретному узлу. STREAM, к примеру, запускается с указанием выделять память на CXL-узле (node 1), а потоки исполнения - на ядрах основного узла (node 0). Разница в результатах Triad между двумя узлами покажет реальный штраф CXL на вашем конкретном железе.
stressapptest - отдельная история. Он не просто гоняет паттерны, а целенаправленно ищет битовые ошибки, проблемы с таймингами и некорректное поведение контроллера под нагрузкой. Запускается с привязкой к CXL-узлу, с указанием объёма памяти и длительности. Часовой прогон на полном объёме - разумный минимум перед вводом в эксплуатацию.
Micron CXL Memory Resource Kit включает модифицированные версии STREAM и multichase с CXL-специфичными опциями. Репозиторий на GitHub - cxl-micron-reskit - содержит готовые скрипты для автоматизации тестов.
Reliability, Availability, Serviceability - три буквы, без которых CXL-память не выйдет в продакшн. Диагностика здесь строится на трёх уровнях: мониторинг ошибок, инжекция для валидации и firmware-тесты.
Мониторинг ошибок памяти в Linux строится вокруг демона rasdaemon. После установки и запуска он работает в фоне, собирает Hardware Events через kernel tracing и складывает их в базу SQLite. Просмотр накопленных ошибок - через утилиту ras-mc-ctl. Для CXL-устройств rasdaemon отлавливает как корректируемые (CE), так и некорректируемые (UE) ошибки с привязкой к конкретному устройству и адресу. Накопление CE в одном адресном диапазоне - сигнал к замене модуля ещё до того, как ошибка станет фатальной.
Инжекция ошибок - обязательный этап валидации перед продакшном. Два основных инструмента:
AMD RAS Tool с Linux EINJ (Error Injection Interface) инжектирует ошибки на уровне CXL.io и CXL.mem. Ядро должно быть собрано с CONFIG_ACPI_APEI_EINJ=y. Через sysfs-интерфейс /sys/kernel/debug/apei/einj/ задаётся тип ошибки и адрес в CXL-пространстве.
Micron MXCLI - утилита командной строки для CXL mailbox-команд. Через vendor-specific команды она инжектирует ошибки непосредственно в контроллер модуля. Помимо инжекции, MXCLI читает health-информацию, логи событий, обновляет прошивку и мониторит счётчики производительности. Запускается с правами суперпользователя в двух режимах: интерактивный (с автообнаружением устройств, меню и автодополнением) и командная строка с JSON-ответами для интеграции со скриптами и системами мониторинга вроде Zabbix или Prometheus. Micron также выпустила GUI-приложение mxdiagnostic - оно подключается к серверу локально или удалённо, визуализирует NUMA-топологию и показывает PCIe eye diagram.
Для изоляции неисправной CXL-памяти ядро Linux поддерживает механизм memory poisoning: отмеченные страницы исключаются из аллокации. В сочетании с firmware-first error handling (AMD передаёт обработку первичных ошибок прошивке AGESA) цепочка выглядит так: контроллер CXL → прошивка AGESA → APEI/GHES → ядро Linux → rasdaemon → алерт администратору.
CXL-память в Linux работает в двух режимах, и выбор между ними зависит от задачи.
System RAM - память добавляется в общий пул, ядро использует её для любых аллокаций. С включённым memory tiering (ядро 6.1+) горячие страницы мигрируют в локальную DRAM, холодные - в CXL. Режим подходит для задач с большим объёмом данных и неравномерным доступом: in-memory базы, EDA-симуляции, виртуализация.
DAX (devdax) - память доступна как устройство /dev/dax0.0, приложение работает с ней напрямую через mmap(). Подходит для приложений, которые сами управляют размещением данных: Redis с модулем CXL, SAP HANA, собственные аллокаторы.
Переключение между режимами выполняется утилитой daxctl: команда reconfigure-device с указанием целевого режима (system-ram или devdax) и идентификатора устройства. Операция требует, чтобы память не использовалась, а для обратного перевода из system-ram в devdax узел нужно предварительно перевести в offline. В BIOS ASUS параметр CXL SPM с опцией offline настраивает автоматический режим для сценариев высокой доступности: если CXL-модуль деградирует, система продолжает работать на локальной DRAM.
Текущий режим каждого устройства проверяется через daxctl list. Переключённая в system-ram память появится в стандартных утилитах мониторинга (free, numactl) как обычный узел NUMA. При возврате в devdax она исчезнет из системной статистики, но останется доступной через файл устройства.
Ядро 6.1+ с включённым автоматическим tiering (NUMA balancing) мигрирует страницы между DRAM и CXL прозрачно для приложений. Статистику миграций отслеживают через sysctl-параметры NUMA и счётчики в /proc/vmstat - по ним видно, сколько страниц мигрировало между узлами и в каком направлении.
Мониторинг памяти в системах с CXL - постоянный процесс, а не разовая проверка после установки. Привязка критичных процессов к DRAM, а фоновых - к CXL настраивается через numactl или cgroups v2.
У numactl два режима привязки. Жёсткая (--membind) запрещает аллокацию за пределами указанного узла: если память закончится, процесс получит OOM. Мягкая (--preferred) действует как рекомендация - ядро постарается разместить данные на выбранном узле, но при нехватке откатится на другой. Для latency-critical приложений берут жёсткую привязку к DRAM, для пакетной обработки - мягкую к CXL.
Телеметрия через BMC дополняет картину: температуры CXL-модулей, статусы линков, счётчики ошибок - всё это доступно по IPMI и через веб-интерфейс BMC, без захода в операционную систему.
Раньше довод в пользу CXL звучал просто: набрать объём модулями средней ёмкости дешевле, чем ставить редкие крупные. К 2026 году аргумент нужно переписать.
Рынок памяти перевернулся. Производители перенаправили мощности на HBM для ИИ-ускорителей, и серверные модули подорожали в разы: 64 ГБ DDR5 RDIMM, стоивший в сентябре 2025 около трёхсот с небольшим долларов, к середине 2026 года на открытом рынке уходил за две с половиной - три тысячи. За 128 ГБ DDR5-5600 просили порядка четырёх с половиной тысяч. Подробнее о причинах - в разборе глобального дефицита памяти.
CXL-модули собраны из тех же планок DDR5 и дорожают вместе с рынком, так что «через CXL дешевле за гигабайт» больше не работает. Что осталось - вопрос доступности. Дефицит бьёт по модулям высокой ёмкости сильнее: их и делают меньше, и разбирают быстрее. CXL набирает нужный объём из ходовых планок вместо того, чтобы ждать поставки редких крупных, а в условиях, когда сервер приезжает недоукомплектованным по памяти, это уже не про экономию, а про сроки запуска.
Второй уцелевший довод - консолидация. Один сервер с большим объёмом заменяет несколько узлов для memory-bound задач: меньше лицензий, меньше сетевого обмена, меньше задержек на межузловое взаимодействие. Этот расчёт от цен на модули не зависит.
Сегодняшняя настройка - конфигурация на уровне узла: каждый сокет видит свои CXL-устройства. Спецификации CXL 3.0 и 3.1 описывают следующий шаг - shared memory и dynamic capacity devices, где пул памяти разделяется между несколькими хостами через CXL-свитчи.
Для оркестраторов CXL-память пока выглядит обычным узлом NUMA, никаких специальных плагинов не требуется. Привязка подов к CXL-памяти через topology manager в Kubernetes работает стандартным образом, а в Proxmox настройки NUMA у виртуальных машин задают доступные узлы и изолируют CXL-память под некритичные задачи.
Спецификация CXL 4.0 вышла в ноябре 2025 года: скорость линка удвоена до 128 GT/s вслед за PCIe 7.0, добавлены bundled ports и расширены функции RAS при сохранении обратной совместимости. Инструменты диагностики, описанные выше, останутся теми же - меняется скорость, а не подход.
CXL-память уже не экспериментальная технология. Это серийные модули в серийных серверах с ядром Linux, которое знает, что с ними делать. Вопрос не в том, стоит ли её брать, а в том, под какие задачи - и ответ зависит от вашего профиля задержек.
Чем CXL-память отличается от обычной оперативной?
Логически - почти ничем: процессор адресует её как обычную память, приложение не переписывают. Физически она подключена по линиям PCIe, а не к каналам памяти, поэтому обращения идут дольше, а операционная система показывает её отдельным узлом NUMA без процессорных ядер.
Нужен ли особый процессор?
Да, поддержка нужна на уровне платформы. AMD EPYC 9004 и 9005 поддерживают CXL 2.0. Материнская плата должна уметь разделять PCIe-слоты (bifurcation) под контроллеры.
Видит ли CXL-память Windows?
Инструментарий, описанный выше, - cxl-cli, rasdaemon, daxctl, EINJ - это Linux. Практика работы с CXL Type 3 сегодня строится вокруг ядра Linux 6.1 и новее.
Можно ли смешивать CXL и штатные модули?
Именно так это и работает: штатные слоты остаются заполненными и обслуживают горячие данные, CXL добавляет ёмкость сверху. При включённом memory tiering ядро само перемещает горячие страницы в локальную DRAM, а холодные - в CXL.
Подбираете сервер под задачу, которой не хватает памяти?
Инженеры ITTELO посчитают, хватит ли штатных слотов и где начинается смысл в CXL, подберут конфигурацию под ваш профиль нагрузки, соберут и протестируют её перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
