Linux HugePages: зачем нужны и как настраивать для баз данных

При работе с высоконагруженными базами данных узким местом часто становится не диск и даже не CPU, а работа с памятью. Один из механизмов оптимизации — HugePages. Они позволяют снизить накладные расходы на управление памятью и повысить предсказуемость производительности.

Разберёмся, что это такое, зачем они нужны и когда их действительно стоит включать.

Что такое HugePages

В Linux память разбита на страницы (pages).

Стандартный размер страницы: 4 KB

HugePages — это страницы увеличенного размера:

2 MB (наиболее распространённый вариант)
1 GB (на некоторых системах)

Идея простая: вместо тысяч маленьких страниц использовать меньшее количество крупных.

Зачем это нужно

Когда приложение (например, PostgreSQL или MySQL) использует десятки гигабайт RAM, система создаёт миллионы 4KB-страниц.

Это приводит к:

росту таблиц страниц (page tables);
нагрузке на TLB (Translation Lookaside Buffer);
увеличению числа TLB miss;
дополнительной работе CPU.

HugePages уменьшают количество записей в page tables и снижают TLB pressure.

Результат:

меньше накладных расходов на управление памятью;
более стабильная latency;
лучшее использование CPU.

Transparent HugePages (THP) vs статические HugePages

В Linux есть два механизма:

1. Transparent HugePages (THP)

Автоматический режим.

Плюсы:

ничего не нужно настраивать;
система сама объединяет страницы.

Минусы:

возможны непредсказуемые паузы;
defragmentation может вызывать latency spikes;
не всегда подходит для БД.

2. Static HugePages

Выделяются заранее при старте системы.

Плюсы:

стабильность;
отсутствие динамической фрагментации;
лучший вариант для production.

Минусы:

требуется ручная настройка.

Для баз данных обычно рекомендуют отключить THP и использовать статические HugePages.

Почему это важно для баз данных

Базы данных активно используют память:

PostgreSQL — shared_buffers;
MySQL / InnoDB — buffer pool;
Oracle — SGA.

Если буфер занимает 16–128 GB, выигрыш от HugePages становится заметным:

меньше CPU overhead;
более ровный throughput;
снижение контекстных переключений.

Особенно полезно на серверах с большим количеством ядер.

Проверка текущего состояния

Посмотреть HugePages:

grep Huge /proc/meminfo

Проверить THP:

cat /sys/kernel/mm/transparent_hugepage/enabled

Если видите always, значит THP включён.

Отключение Transparent HugePages

Временно:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Для постоянного отключения — через параметры ядра (grub).

Настройка статических HugePages

Рассчитать объём памяти.

Например, если buffer pool = 32 GB и используется 2 MB HugePages:

32 GB / 2 MB = 16384 страниц

Добавить в sysctl:

vm.nr_hugepages = 16384

Применить:

sysctl -p

Проверить, что страницы выделились:

grep Huge /proc/meminfo

NUMA и HugePages

На NUMA-серверах HugePages распределяются по узлам.

Важно:

следить, чтобы память и процесс были на одном NUMA node;
использовать numactl при запуске БД;
тестировать конфигурацию под нагрузкой.

Неправильное распределение может свести пользу к нулю.

Когда HugePages не нужны

маленькая база (< 2–4 GB);
dev-серверы;
системы с частым изменением объёма памяти;
если нет CPU bottleneck.

В таких случаях усложнение конфигурации не оправдано.

Типичные ошибки

включить HugePages, но забыть отключить THP;
выделить слишком мало страниц;
не учитывать NUMA;
не перезапустить сервис после изменения настроек.

Итог

HugePages — это способ уменьшить накладные расходы на управление памятью и сделать работу баз данных более предсказуемой.

На production-серверах с большими объёмами RAM они часто дают:

стабильный прирост производительности;
снижение CPU overhead;
более ровную latency.

Но это не «магическая кнопка». Перед включением нужно понимать архитектуру сервера, объём памяти и характер нагрузки.

Правильно настроенные HugePages — это ещё один шаг к взрослой, оптимизированной инфраструктуре.