Huge Pages для PostgreSQL и 1С: когда настройка ускорит сервер

На сервере со 128 ГБ RAM под shared_buffers часто отдают 32 ГБ. PostgreSQL может разместить этот объём в 16 384 страницах по 2 МБ. Со стандартными страницами по 4 КБ ему потребуются 8 388 608 страниц.

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

До изменения настройки ответьте на три вопроса. Где запрос теряет время? Сколько памяти зарезервирует Linux? Хватит ли остатка PostgreSQL, серверу 1С и операционной системе?

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

Linux обычно делит оперативную память на страницы по 4 КБ. На архитектуре x86_64 фиксированные Huge Pages чаще занимают 2 МБ или 1 ГБ.

Процессор хранит соответствия виртуальных и физических адресов в TLB — буфере трансляции адресов. Чем мельче страницы, тем больше записей приходится обслуживать.

В исследовании Softpoint «Записки оптимизатора 1С» приведён наглядный расчёт. Для 1 ГБ нужны более 260 тысяч страниц по 4 КБ. При размере страницы 2 МБ достаточно 512 записей. Таблицы страниц сокращаются, нагрузка на TLB падает.

PostgreSQL размещает в Huge Pages не всю занятую память. Механизм охватывает разделяемую область, основную часть которой занимает shared_buffers.

Вывод: Huge Pages меняют работу shared_buffers, а не всей памяти PostgreSQL. Если запрос ждёт сортировку, блокировку или чтение с диска, причина никуда не исчезнет.

Есть и косвенный результат. В тестах Command Prompt крупные страницы снижали общий расход памяти PostgreSQL. Освободившийся объём можно передать work_mem или файловому кэшу. Насколько это поможет, зависит от нагрузки.

Сначала найдите ограничение под рабочей нагрузкой

Проверять Huge Pages имеет смысл при высокой загрузке процессора или давлении на память. Ещё один подходящий сценарий — много одновременных процессов, которые часто обращаются к данным внутри shared_buffers.

Percona проверяла Huge Pages на PostgreSQL 11 при shared_buffers = 64 ГБ. Польза росла вместе с числом клиентов и объёмом базы, пока рабочие данные помещались в общем буфере. Когда данные выходили за его границы, результат ухудшался.

Это не тест 1С и не обещание конкретного прироста. Бенчмарк показывает другое: крупные страницы помогают, когда PostgreSQL активно обрабатывает данные в памяти.

Вывод: не включайте Huge Pages наугад. Сначала выясните, чего ждёт PostgreSQL: процессора, памяти или накопителя.

PSI показывает, сколько времени процессы ждут CPU, память или ввод-вывод. Command Prompt предлагает снимать этот показатель в периоды высокой нагрузки. Одного PSI мало, чтобы доказать пользу Huge Pages. Зато он подскажет, что проверять дальше.

Если растут дисковые ожидания, начните с системы хранения. Типы накопителей и признаки такого ограничения описаны в материале про подбор накопителя для сервера 1С.

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

Возьмём сервер со 128 ГБ RAM и выделим четверть памяти под shared_buffers — 32 ГБ. Такое соотношение приводит Softpoint. Четверть RAM указана и в рекомендациях MoscowSoft по настройке PostgreSQL для 1С.

При странице размером 2 МБ стартовый расчёт выглядит так:

128 ГБ × 25% = 32 ГБ
32 ГБ × 1024 = 32 768 МБ
32 768 МБ ÷ 2 МБ = 16 384 страницы

Начальная оценка для vm.nr_hugepages — 16 384. Это расчёт под названные исходные данные, а не универсальное значение для любого сервера.

Если поднять shared_buffers до половины RAM, потребуется другой резерв:

128 ГБ × 50% = 64 ГБ
64 ГБ × 1024 = 65 536 МБ
65 536 МБ ÷ 2 МБ = 32 768 страниц

Linux зарезервирует под эти страницы 64 ГБ физической памяти. Ядро уже не передаст их серверу 1С, файловому кэшу или другим процессам.

Вывод: число страниц растёт вместе с shared_buffers. Каждые дополнительные 2 ГБ общей памяти требуют ещё 1024 страницы по 2 МБ.

Для другого сервера используйте ту же формулу:

vm.nr_hugepages =
объём разделяемой памяти в мегабайтах ÷ размер Huge Page в мегабайтах

Формула даёт стартовую точку. Точную потребность PostgreSQL показывает вычисляемый параметр shared_memory_size_in_huge_pages. Он учитывает общую память, которая нужна экземпляру при запуске.

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

Резерв нельзя считать из всей свободной RAM

Физический резерв Huge Pages нужно отделять от обычной занятой памяти. Если Linux выделил под него 32 ГБ, другие процессы не заберут этот объём даже при нехватке RAM.

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

Формула «128 ГБ минус 32 ГБ — осталось 96 ГБ» показывает лишь верхнюю границу. Она не учитывает пиковый расход процессов и число активных сеансов.

Перед резервированием снимите потребление памяти в обычный рабочий пик. Проверяйте весь состав: PostgreSQL, процессы 1С, файловый кэш и память ядра.

Если запас исчезает уже без Huge Pages, дополнительный резерв усилит давление на память. Сначала пересчитайте shared_buffers, work_mem и распределение компонентов по узлам.

Начните с huge_pages = try

По данным исследования Softpoint, PostgreSQL по умолчанию работает с huge_pages = try. Если зарезервированных страниц хватает, сервер использует Huge Pages. Если не хватает, PostgreSQL сможет запуститься на стандартных страницах.

Режим huge_pages = on работает строже. При нехватке подготовленных страниц PostgreSQL не запустится. Не включайте его до проверки резерва.

Действуйте по порядку:

1. Рассчитайте стартовый vm.nr_hugepages из объёма shared_buffers.
2. Сверьте результат с shared_memory_size_in_huge_pages.
3. Проверьте запас для PostgreSQL, сервера 1С, ОС и файлового кэша.
4. Оставьте huge_pages = try для первого запуска.
5. После перезапуска проверьте, сколько страниц выделено фактически.
6. Переключайтесь на huge_pages = on лишь после успешной проверки.

Руководство Алексея Гилёва предлагает проверить поддержку механизма в ядре Linux такой командой:

grep HUGETLB /boot/config-$(uname -r)

Состояние страниц видно в /proc/meminfo:

grep ^HugePages /proc/meminfo

После запуска PostgreSQL проверьте HugePages_Total, HugePages_Free и HugePages_Rsvd. Записи vm.nr_hugepages в sysctl недостаточно: она показывает настройку, но не подтверждает фактическое использование страниц.

Transparent HugePages не заменяют фиксированный резерв

Transparent HugePages, или THP, ядро Linux автоматически включает во многих установках. Механизм пытается объединять стандартные страницы без статического резерва.

Percona рекомендует для СУБД фиксированные Huge Pages. THP может добавлять непредсказуемые задержки при выделении и объединении памяти.

Включённый THP не доказывает, что PostgreSQL разместил shared_buffers в подготовленном резерве. Это разные механизмы. Фиксированные страницы проверяйте по строкам HugePages в /proc/meminfo.

Способ отключения THP зависит от дистрибутива и загрузки ядра. В руководстве Алексея Гилёва приведена настройка через /sys/kernel/mm/transparent_hugepage/ и загрузчик GRUB для CentOS. Перед изменением проверьте документацию своего дистрибутива.

Сравнивайте одинаковую нагрузку до и после

Перезапуск PostgreSQL очищает кэш. Первый прогон может оказаться медленнее даже при верной настройке: данные ещё не вернулись в память.

До и после изменения воспроизведите один рабочий сценарий. Сохраните те же операции 1С, число сеансов и набор данных. Утренний простой нельзя сравнивать с закрытием месяца.

Зафиксируйте четыре группы показателей:

Вывод: один быстрый запрос после перезапуска ничего не доказывает. Нужны повторяемый сценарий и подтверждение, что PostgreSQL получил крупные страницы.

Решение перед перезапуском

Проверяйте Huge Pages, когда PostgreSQL упирается в CPU или память, держит много одновременных процессов, а активные данные часто попадают в shared_buffers.

Если запросы в основном ждут накопитель, прямого ускорения не будет. Сначала устраните дисковое ограничение. Затем повторите замер.

Для сервера со 128 ГБ RAM и shared_buffers = 32 ГБ стартовая оценка составляет 16 384 страницы по 2 МБ. Сверьте её с shared_memory_size_in_huge_pages и оставьте память другим процессам.

Перед рабочим перезапуском проверьте пять пунктов:

• стартовый резерв рассчитан из shared_buffers, а не из всей RAM;
• PostgreSQL сообщает требуемое число страниц;
• оставшейся памяти хватает серверу 1С, ОС и рабочим процессам PostgreSQL;
• первый запуск проходит с huge_pages = try;
• после запуска /proc/meminfo подтверждает выделение страниц.

Переключайте huge_pages в режим on после этой проверки. Иначе ошибка в расчёте остановит PostgreSQL, хотя вы хотели ускорить базу.