Когда страницы памяти часто перемещаются между DRAM и NVMe, накопитель выполняет работу, которой не видно в числе запросов СУБД. Страница уходит на SSD, вскоре возвращается, а затем снова записывается. Такой оборот принято называть churn: данные движутся между уровнями, занимают канал ввода-вывода и увеличивают запись со стороны хоста, хотя обслуженная нагрузка от самого движения не растёт.

Проблема возникает не из-за NVMe как такового. Она появляется, когда решение о размещении слишком быстро теряет актуальность относительно фазы нагрузки. Транзакционный пик, отчёт, фоновая обработка и прогрев обращаются к разным областям памяти. Если инфраструктура догоняет каждую перемену постфактум, цена ошибки проявляется одновременно в I/O, p99 и расходовании ресурса конкретного SSD.

Лишние перемещения занимают тот же I/O

СУБД уже использует накопители для собственных операций. PostgreSQL читает и записывает страницы данных, ведёт журнал, выполняет контрольные точки и фоновое обслуживание. Другие системы создают свои потоки чтения, записи и уплотнения. Страничный уровень памяти добавляет к ним ещё один поток, поэтому качество решений размещения влияет на общую очередь устройства.

Один перенос на NVMe может быть осмысленным: он освобождает быстрый уровень для страниц, которые нужны приложению раньше. Лишним становится повторный круг, когда страница быстро возвращается и вскоре снова уходит без заметного изменения полезной нагрузки. Чем чаще такие циклы совпадают с пиками СУБД, тем сильнее конкуренция за I/O и тем вероятнее рост хвоста задержки.

Архитектурную роль SSD в вычислительном контуре подробнее раскрывает материал о том, как enterprise SSD становится уровнем памяти для СУБД. Здесь фокус уже: не само наличие второго уровня, а то, насколько точно система управляет движением страниц и сколько записи создаёт для обслуживания заданного рабочего набора.

Host writes не равны записи в NAND

Спецификация NVM Express определяет в журнале SMART/Health показатель Data Units Written. Он отражает пользовательские данные, которые хост передал контроллеру на запись. Изменение этого счётчика за сопоставимый интервал показывает host write path — поток на границе операционной системы и устройства. Для страничной памяти это ближайшая стандартная точка наблюдения за тем, сколько записи дошло до SSD.

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

Предиктор памяти способен влиять на host writes, сокращая ненужные перемещения страниц со стороны системы. Но по одному Data Units Written нельзя приписать ему управление внутренним усилением записи NAND. Для такого вывода нужны отдельные счётчики устройства или подтверждённая телеметрия производителя, измеренные на той же нагрузке. Эта граница делает отчёт точнее: программный контур отвечает за свои решения, контроллер SSD — за внутреннее размещение.

Второй стандартный показатель, Percentage Used, даёт оценку доли расчётного ресурса, использованной по модели производителя. Это не дата будущего отказа и не универсальный процент физического износа. Его динамика полезна вместе с Data Units Written, временем работы и паспортными условиями конкретной модели, а не вместо них.

Прогноз удерживает страницу на подходящем уровне

Страница памяти не получает пожизненную метку «горячая» или «холодная». Её ближайшая ценность меняется вместе с фазой сервиса. Устойчивое управление должно замечать эту динамику и не превращать каждое колебание обращений в немедленный круг между уровнями.

В gigaRAM предиктивная математическая модель по реальным обращениям решает, что, куда и когда перемещать или возвращать между DRAM и NVMe. Это не ручная раскладка таблиц и не случайная выгрузка страниц. Прогноз ближайшей ценности позволяет удерживать страницу на подходящем уровне дольше, когда её немедленный перенос лишь создаст обратное движение.

Так модель воздействует на причину host writes: на количество и своевременность решений о перемещении. Если размещение лучше соответствует следующей фазе, меньше страниц совершают короткий круг DRAM–NVMe–DRAM. Освободившийся I/O остаётся для СУБД, а ресурс SSD расходуется на поддержание полезной ёмкости, а не на постоянную отмену недавних решений.

Ресурс SSD измеряется вместе с p99

Паспортные TBW и DWPD описывают ресурс определённой модели SSD в заданных производителем условиях. TBW задаёт суммарный объём записи, а DWPD выражает допустимую интенсивность через число полных объёмов устройства в день за оговорённый срок. Одинаковые интерфейс и ёмкость не делают ресурс разных накопителей одинаковым.

Эксплуатации нужен не разовый снимок SMART, а динамика на повторяемых фазах. Приращение Data Units Written связывают с количеством запросов или транзакций, долей времени внутри SLO и p99. Тогда рост записи при росте бизнеса отделяется от churn: SSD может записывать больше потому, что сервер обслуживает больше полезной работы, а не потому, что страницы движутся менее точно.

Linux PSI показывает время, которое задачи теряют из-за давления CPU, памяти или I/O. Так страничный поток связывается с ростом очереди и выходом p99 за целевую границу. Страницы памяти оказываются на NVMe, поэтому политики доступа, шифрования и обращения с носителем входят в архитектуру; отдельный разбор объясняет безопасность страниц СУБД и ключей на NVMe.

Решение опирается на четыре связанных сигнала

Платформенная команда видит память, CPU, NVMe и системное давление. Команда хранения отвечает за модель SSD, прошивку, телеметрию и условия ресурса. DBA понимает фазы работы базы, а владелец сервиса задаёт SLO и цену простоя. Решение о предиктивной ёмкости принадлежит этому общему контуру, потому что оптимизация одного счётчика способна перенести нагрузку на соседний ресурс.

Компактная проверка удерживает обсуждение на уровне решения, а не превращает его в каталог телеметрии:

  • Повторные переносы растут при стабильной полезной нагрузке → проверить host writes, возвраты страниц и фазу СУБД → инвестировать в более устойчивое автоматическое размещение.
  • Пики Data Units Written совпадают с ростом p99 → проверить общую очередь NVMe и PSI I/O → разделить полезный поток базы и цену страничного churn.
  • Percentage Used меняется быстрее эксплуатационного плана → сверить host writes, паспорт конкретного SSD и профиль нагрузки → заложить ресурс и замену в архитектуру, а не только в складской запас.
  • Рабочий набор растёт, а линейное добавление DRAM повышает стоимость узла → проверить объём обслуженной нагрузки внутри SLO → оценить управляемую DRAM+NVMe-ёмкость как отдельный инвестиционный вариант.

Стоимость включает замену и простой

Цена SSD — только начало расчёта. В стоимость входят запас по I/O, ресурс устройства, плановая замена, окно обслуживания и риск простоя. С другой стороны, более точное размещение способно уменьшить потребность в пропорциональном росте DRAM и дать серверу больше доступной памяти для СУБД. Эти части нужно сравнивать на одном горизонте.

Инвестиционный сигнал возникает, когда churn повторяется в сопоставимых фазах, заметно занимает host write path и связан с p99 или ускоренным расходованием расчётного ресурса. Тогда задача уже не сводится к покупке накопителя с большим TBW. Нужен контур, который уменьшает сам источник ненужного движения и сохраняет целевой объём полезной работы.

Для бизнеса итоговой единицей становится стоимость обслуженной нагрузки внутри SLO. gigaRAM в этой модели координат оценивается по тому, насколько предиктивное размещение меняет host writes, p99 и требуемую конфигурацию DRAM+NVMe на конкретном сервисе. Такой расчёт не смешивает внешний поток записи с внутренней работой NAND и не превращает паспорт SSD в обещание результата.

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

Источники. NVM Express Base Specification 2.0a определяет Data Units Written и Percentage Used в журнале SMART/Health. Официальный репозиторий NVMe CLI используется как первичный источник о стандартном инструменте чтения журналов и управления NVMe-устройствами.

Документация Linux PSI объясняет измерение потерянного времени из-за давления CPU, памяти и I/O. Meta Engineering: Transparent Memory Offloading служит отраслевым примером обратной связи и стремления уменьшать совокупный страничный I/O; его архитектура и результаты не переносятся на другой продукт.

Технология gigaRAM — единственная коммерческая ссылка и источник описания предиктивного размещения страниц между DRAM и NVMe ниже приложения.