Huge Pages для PostgreSQL и 1С: как рассчитать память и не сорвать запуск

Вы включили huge_pages = on, перезапустили PostgreSQL — и пользователи лишились доступа к 1С. База при этом могла не пострадать. PostgreSQL не запустится, если Linux не зарезервировал нужное количество больших страниц памяти.

С режимом try риск ниже. PostgreSQL сначала пытается занять Huge Pages. Если страниц не хватает, СУБД использует стандартные страницы по 4 КБ. Поэтому начните с try, проверьте резерв и только потом переходите на on.

Здесь нельзя брать значение vm.nr_hugepages с соседнего сервера. Его нужно рассчитать для вашего экземпляра PostgreSQL, затем сверить с shared_memory_size_in_huge_pages. До расчёта проверьте THP.

Huge Pages работают только с разделяемой памятью PostgreSQL

Стандартная страница памяти Linux занимает 4 КБ. Чтобы отобразить 1 ГБ, системе нужно больше 260 000 таких страниц. При размере Huge Page 2 МБ хватит 512 страниц.

Процессор хранит последние преобразования виртуальных адресов в физические в TLB — кэше адресов. Чем крупнее страницы, тем меньше записей нужно для того же объёма памяти. Механику разбирает руководство Sudo Academy по настройке Huge Pages в Linux.

PostgreSQL использует Huge Pages только для разделяемой памяти. Эксперимент Softpoint на Debian 13 и PostgreSQL 17.9 показывает связь этого механизма с shared_buffers. Память под work_mem и хеш-таблицы соединений по-прежнему работает со страницами по 4 КБ.

Граница здесь жёсткая. Huge Pages могут уменьшить расходы на адресацию shared_buffers. Они не ускорят запись WAL, не уберут сброс временных файлов на диск и не исправят неудачный план запроса.

За резерв приходится платить оперативной памятью. Явные Huge Pages закрепляются в RAM, не уходят в swap и не достаются другим процессам. Если завысить vm.nr_hugepages, памяти станет меньше у сервера 1С, операций PostgreSQL и файлового кэша Linux.

Явные Huge Pages и THP решают разные задачи

Transparent Huge Pages, или THP, ядро Linux собирает само из страниц по 4 КБ. Явные Huge Pages администратор резервирует заранее через vm.nr_hugepages.

Одна настройка не заменяет другую. Отключение THP не создаёт резерв для PostgreSQL. После него всё равно придётся рассчитать количество явных Huge Pages.

PostgreSQL нужен заранее заданный резерв явных Huge Pages. THP лучше отключить отдельно: фоновое уплотнение памяти мешает оценить результат и может вызвать задержки.

Sudo Academy связывает задержки THP с фоновым уплотнением и дефрагментацией памяти. Руководство Гилёва по Huge Pages для PostgreSQL тоже советует проверить enabled и defrag перед настройкой явного резерва.

Текущее состояние покажут две команды:

cat /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/kernel/mm/transparent_hugepage/defrag

После отключения THP в первой строке активным должно остаться значение [never]. Для постоянной настройки Sudo Academy указывает параметр ядра:

transparent_hugepage=never

На Debian и Ubuntu после изменения параметров GRUB обновите конфигурацию:

sudo update-grub

Затем перезагрузите сервер и ещё раз прочитайте файл enabled. Порядок изменения GRUB зависит от дистрибутива. Перед работой сверьтесь с его штатной документацией.

Расчёт для сервера со 128 ГБ RAM

Методический материал ИТС 1С советует отдавать под shared_buffers четверть оперативной памяти сервера PostgreSQL. Посчитаем резерв для сервера со 128 ГБ RAM и страницами по 2 МБ.

Исходные данные:

• RAM — 128 ГБ;
• shared_buffers — четверть RAM;
• размер одной Huge Page — 2 МБ;
• в расчёт входит только память под shared_buffers.

Сначала определяем shared_buffers:

128 ГБ / 4 = 32 ГБ

Теперь переводим 32 ГБ в мегабайты и делим результат на размер страницы:

32 × 1024 / 2 = 16 384 Huge Pages

Число 16 384 — нижняя оценка, а не значение для слепого копирования в конфигурацию. PostgreSQL резервирует разделяемую память не только под shared_buffers. Точную потребность при запуске вычисляет shared_memory_size_in_huge_pages.

Эту формулу можно применить к серверу с другим объёмом RAM:

При размере страницы 2 МБ каждые дополнительные 2 ГБ целевой памяти требуют ещё 1024 страницы. Изменили shared_buffers — пересчитайте резерв до перезапуска PostgreSQL.

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

Если Linux использует страницы другого размера, замените делитель в формуле:

Количество страниц = целевая память в МБ / размер Huge Page в МБ

Не переносите 16 384 на другой сервер без проверки. Там могут отличаться размер страницы, объём shared_buffers и служебная память экземпляра.

Сначала сохраните возможность отката

После изменения параметров памяти PostgreSQL придётся перезапустить. До начала работ создайте копию и убедитесь, что сможете развернуть её отдельно. Выбор между pg_dump, pg_basebackup и архивированием WAL разобран в руководстве по копиям кластера PostgreSQL.

Не проверяйте копию восстановлением поверх рабочего кластера. Разверните её в другом каталоге или на отдельной машине. Тогда проверка не затронет текущие данные 1С.

Сохраните исходные значения:

sysctl vm.nr_hugepages
grep -i '^Huge' /proc/meminfo

В /proc/meminfo Linux показывает размер Huge Page, общий резерв и число свободных страниц. После запуска PostgreSQL вы сравните эти значения с исходными.

Теперь проверьте параметры СУБД:

SHOW shared_buffers;
SHOW huge_pages;
SHOW shared_memory_size_in_huge_pages;

Последний запрос показывает расчёт для текущего экземпляра. Если установленная версия PostgreSQL не знает этот параметр, не берите число с другого сервера. Сначала откройте документацию своей сборки.

Настройка с режимом try сохраняет рабочий запуск

Первую проверку проводите с huge_pages = try в postgresql.conf:

huge_pages = try

При нехватке Huge Pages PostgreSQL всё равно запустится. Он перейдёт на страницы по 4 КБ, а вы увидите, что резерв не сработал.

После этого задайте рассчитанное число страниц через sysctl. Для сервера со 128 ГБ RAM начальная оценка выглядит так:

vm.nr_hugepages = 16384

Не применяйте это число, пока не сверите его с shared_memory_size_in_huge_pages. Если PostgreSQL запросил больше страниц, используйте его расчёт.

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

sysctl vm.nr_hugepages
grep -i '^Huge' /proc/meminfo

Резерв лучше создавать во время загрузки системы. Sudo Academy предупреждает: на работающем сервере фрагментация RAM может помешать ядру найти непрерывные блоки по 2 МБ.

После запуска PostgreSQL снова прочитайте строки Huge в /proc/meminfo. Свободных страниц должно стать меньше, чем до запуска. Сравните разницу с потребностью экземпляра.

Успешного ручного запуска недостаточно. Штатно перезагрузите сервер и повторите проверку. Иначе настройка может пережить текущую сессию, но пропасть при следующем обслуживании.

Если вы собираете новый контур, сначала закончите развёртывание PostgreSQL и ролей 1С в Linux. К Huge Pages переходите после выбора объёма RAM и значения shared_buffers.

В on переходят после штатной перезагрузки

Режим on не даёт PostgreSQL скрыто вернуться к страницам по 4 КБ. Он контролирует конфигурацию, но сам по себе не обещает ускорения.

Переходите на on, когда выполнены четыре условия:

• THP остаётся отключённым после загрузки;
• vm.nr_hugepages применяется при старте Linux;
• зарезервированных страниц хватает PostgreSQL;
• после запуска остаётся память для процессов 1С и операций СУБД.

После проверки измените параметр:

huge_pages = on

Перезапустите PostgreSQL. Проверьте службу, журнал запуска и /proc/meminfo. Если СУБД не поднялась, верните try, восстановите доступ к 1С и найдите причину нехватки резерва.

Не наращивайте vm.nr_hugepages наугад. Ядру могла помешать фрагментация памяти. Ещё одна возможная причина — настройка не применилась при загрузке. Лишний резерв здесь лишь отнимет RAM у системы.

Как понять, где сломалась настройка

Сбой после перезапуска ещё не доказывает, что виноваты Huge Pages. Отделите нехватку резерва от THP, дисковых задержек и параметров памяти PostgreSQL.

Если PostgreSQL занял страницы, а задержки остались, Huge Pages настроены. Дальше ищите ограничение в другом слое. Увеличивать резерв больше не нужно.

Методический материал ИТС 1С разделяет память по назначению. work_mem задаёт лимит для операций, temp_buffers обслуживает временные таблицы, shared_buffers хранит общий буферный кэш PostgreSQL. Huge Pages работают только с последним параметром.

Запись WAL тоже требует своей диагностики. Huge Pages не меняют скорость накопителя и не сокращают задержку fsync. Не отключайте fsync ради эксперимента: ИТС 1С советует держать его включённым для сохранения целостности данных.

После перезапуска пройдите всю цепочку: память Linux, сеансы, WAL, autovacuum и процессы 1С. Порядок проверок собран в схеме контроля Linux, PostgreSQL и процессов 1С.

Рабочая последовательность для сервера со 128 ГБ RAM

При 128 ГБ RAM и shared_buffers = 32 ГБ начальная оценка — 16 384 страницы по 2 МБ. Сравните её с shared_memory_size_in_huge_pages. Если числа расходятся, ориентируйтесь на расчёт PostgreSQL.

Порядок работы:

1. Создайте проверяемую копию кластера.
2. Проверьте состояние THP и размер Huge Page.
3. Отключите THP через параметры загрузки Linux.
4. Получите shared_memory_size_in_huge_pages.
5. Задайте vm.nr_hugepages не ниже потребности PostgreSQL.
6. Запустите СУБД с huge_pages = try.
7. Проверьте использование страниц после штатной перезагрузки.
8. Перейдите на on, если хотите запретить скрытый откат к страницам по 4 КБ.

Работа закончена, если PostgreSQL использует Huge Pages после обычной загрузки, а процессам 1С хватает оставшейся памяти. Изменение скорости подтвердит только сравнение вашей нагрузки до и после настройки.