Рабочий набор СУБД — это не вся база, а данные и служебные страницы, к которым нагрузка обращается в значимом периоде. Его состав меняется вместе с транзакциями, отчётами, прогревом и фоновыми операциями. Поэтому системе памяти приходится выбирать, какие страницы сохранять на быстром уровне.
LRU, или принцип «вытеснять давно не использовавшееся», опирается на недавнюю историю. Такой сигнал практичен: то, что требовалось недавно, часто потребуется снова. Прогноз решает соседнюю, но более направленную в будущее задачу — оценивает ближайшую ценность страницы до следующего обращения.
Различие становится важным при смене фазы. Новый рабочий набор ещё не накопил длинную историю, а цена промаха уже отражается в I/O, повторном возврате страницы и p99. Для CTO вопрос не в выборе модного алгоритма, а в том, какой критерий размещения удерживает SLO при разумной стоимости RAM и накопителей.
LRU превращает прошлые обращения в полезный сигнал
LRU расшифровывается как least recently used — «наименее недавно использованное». Механизм ранжирует данные по давности обращения и освобождает те, к которым не обращались дольше. Он не пытается понять таблицу или бизнес-событие; его сила в простой и часто верной связи между недавним прошлым и ближайшим будущим.
Современный Linux использует более развитые варианты этого принципа. Multi-Gen LRU группирует страницы по поколениям, отражающим возраст и историю доступа. Документация ядра связывает этот механизм с освобождением памяти, эффективностью RAM и оценкой рабочего набора за разные интервалы.
Это не устаревший компромисс, а важный системный инструмент. История доступна без знания приложения, быстро обновляется и помогает ядру принимать решения под давлением памяти. В стабильной фазе, где обращения повторяются похожим образом, недавность даёт сильный ориентир.
При этом LRU сообщает именно о том, что уже произошло. Когда отчёт сменяет транзакционную нагрузку, первые страницы нового набора появляются в истории только после обращения. Чем дороже их возврат, тем заметнее временной разрыв между началом фазы и обновлением ретроспективного порядка.
Прогноз оценивает ближайшую ценность страницы
Предиктивный подход использует наблюдаемое поведение не только для ранжирования прошлого, но и для оценки следующего периода. Его вопрос звучит иначе: насколько вероятно или срочно ближайшее обращение к странице и какой физический уровень должен обслуживать её сейчас.
В gigaRAM предиктивная математическая модель по реальным обращениям решает, что, куда и когда перемещать или возвращать между DRAM и NVMe. Решение работает на страничном уровне и не требует ручных правил для таблиц, ключей или файлов. Положение страницы меняется вместе с оценкой ближайшей ценности.
Публичное описание не раскрывает внутреннюю формулу, признаки или частоту пересчёта. Для архитектурного сравнения это и не требуется. Достаточно различать природу сигналов: LRU упорядочивает зафиксированную недавность, а прогноз использует картину обращений для оценки того, что понадобится дальше.
Прогноз не знает бизнес-смысла SQL-запроса. Он видит закономерности доступа к памяти, а не названия таблиц и причины отчёта. Именно поэтому физический слой может оставаться прозрачным для приложения и одновременно сопровождать меняющийся рабочий набор.
Цена промаха проявляется в p99
Промах означает, что нужная страница отсутствует на ожидаемом быстром уровне и её приходится возвращать через более длинный путь. Цена зависит от накопителя, конкурирующего I/O, размера операции и текущей нагрузки. Один и тот же счётчик промахов может иметь разное влияние на разные СУБД и фазы.
Повторные возвраты особенно важны. Если страница покидает DRAM и вскоре снова требуется, система тратит ввод-вывод и время процессора на движение, а полезная операция ждёт. Серия таких событий способна почти не изменить среднее время ответа, но поднять хвост задержки.
Материал о рабочем наборе, refault и границе p99 показывает, как связать повторное обращение после вытеснения с реальным поведением сервиса. Refault служит техническим сигналом, а p99 и SLO переводят его в язык пользовательской задержки и стоимости обслуженной нагрузки.
Для бизнеса дорогой промах — не абстрактная ошибка алгоритма. Он занимает ресурс NVMe, конкурирует с I/O СУБД и увеличивает время критичного запроса. Поэтому выбор страниц оценивают по тому, сколько полезных операций остаётся внутри SLO, а не только по доле DRAM или числу перемещений.
Подходы по-разному встречают смену фазы
Сравнение полезно держать компактным. Оно не ранжирует методы по принципу «хороший — плохой», а показывает, какую информацию каждый использует и какой управленческий вопрос помогает решить.
| Подход | Какой сигнал использует | Реакция на смену фазы | Управленческий смысл |
|---|---|---|---|
| LRU и его современные варианты | Давность и история обращений | Обновляет порядок по мере появления новых доступов | Надёжный базовый критерий освобождения памяти |
| Предиктивное размещение | Наблюдаемое поведение и оценка ближайшей ценности | Стремится подготовить физический уровень к следующему обращению | Связывает ёмкость DRAM+NVMe с меняющимся рабочим набором |
| Статическое ручное правило | Заранее выбранный класс объекта или периода | Требует пересмотра при изменении профиля | Подходит для известных границ, но создаёт операционную работу |
В транзакционной фазе история и прогноз могут указывать на близкий набор страниц. При переходе к отчёту разница становится заметнее: LRU регистрирует новые обращения и перестраивает порядок, а прогнозный слой оценивает последовательность и ближайшую ценность на основании наблюдаемого поведения.
Redis помогает увидеть ещё одну границу. Его политики LRU и LFU выбирают ключи для удаления при ограничении maxmemory. Физическая страница процесса может содержать части нескольких объектов, поэтому LRU Redis и страничное размещение памяти не являются одним механизмом и не управляют друг другом.
Решение принадлежит платформе и владельцу сервиса
Платформенная команда отвечает за DRAM, NVMe, ввод-вывод и наблюдаемость памяти. DBA знает периоды смены нагрузки, критичные запросы и фоновые операции. Владелец сервиса задаёт p99 и SLO. Только совместно они могут определить, действительно ли промах дорог для бизнеса.
Сигнал для инвестиции возникает, когда смена фаз повторяется, а вместе с ней повторяются refault, всплески I/O и рост p99. Если CPU и сеть сохраняют запас, а расширение DRAM становится постоянной реакцией на каждый новый набор данных, критерий выбора страниц превращается в отдельный архитектурный рычаг.
Статья о замкнутом контуре управления памятью объясняет, как измеренный результат возвращается в следующее решение. Здесь акцент уже: прежде чем строить такой контур, нужно понимать, по какому сигналу выбираются страницы и сколько стоит неверное ожидание ближайшего обращения.
Владельцы сравнивают варианты на одной нагрузке. Платформа измеряет движение страниц и I/O, DBA — время запросов и фазу, сервис — p99 и число операций внутри SLO. Такое разделение не требует от руководителя разбираться в деталях алгоритма, но сохраняет причинную связь между памятью и результатом.
Рабочий набор становится прогнозируемым ресурсом
DRAM остаётся быстрым уровнем, но её объём больше не обязан повторять весь логический размер базы. Если критерий выбора отражает ближайшую ценность страниц, память можно распределять по роли в текущей работе. NVMe добавляет ёмкость, а качество решения проверяется стоимостью промаха.
Для действующего сервера это означает возможность обслуживать больший рабочий набор без автоматического роста физической RAM. Для новой конфигурации — более точное разделение бюджета между быстрым уровнем, ёмкостью и допустимым I/O. Экономика строится вокруг полезной нагрузки при заданном SLO.
gigaRAM представляет этот подход как инфраструктурный слой, а не как замену политикам СУБД или ядра. LRU продолжает решать свои задачи, прогноз добавляет оценку ближайшей ценности, а DBA и платформа проверяют итог по p99. Сильная архитектура использует каждый сигнал в его области ответственности.
Для CTO вывод состоит в управляемой цене промаха. Когда рабочие фазы известны по поведению, но меняются быстрее ручной конфигурации, прогнозное размещение становится способом использовать DRAM точнее. Решение принимают не по обещанию алгоритма, а по повторяемой стоимости I/O, RAM и операций в пределах SLO.
Источники. Документация Linux Multi-Gen LRU описывает поколенческую историю обращений, оценку рабочего набора и освобождение страниц. Redis Key Eviction используется только для разграничения LRU по ключам и управления физическими страницами.
Документация Linux DAMON подтверждает класс наблюдения за доступами. Meta Engineering: Transparent Memory Offloading служит первичным отраслевым примером управления памятью с учётом поведения нагрузки; его реализация и результаты на другой продукт не переносились.
Технология gigaRAM — единственная коммерческая ссылка и источник описания предиктивного размещения страниц между DRAM и NVMe.