Ядро Linux предоставляет широкий спектр параметров конфигурации, которые могут повлиять на производительность. Главное — выбрать правильную конфигурацию для вашего приложения и рабочей нагрузки. Как и любой другой базе данных, PostgreSQL необходима оптимальная настройка ядра Linux. Неправильные настройки могут привести к снижению производительности. Важно проводить сравнительный анализ производительности базы данных после каждого сеанса настройки. В одном из своих предыдущих постов под названием "Tune Linux Kernel Parameters For PostgreSQL Optimization" я описал некоторые из наиболее полезных параметров ядра Linux и то, как они помогают повысить производительность базы данных. Теперь я поделюсь результатами сравнительного тестирования после настройки HugePages в Linux под различными нагрузками PostgreSQL. Я провел полный набор тестов под множеством различных нагрузок PostgreSQL с различным числом параллельных клиентов.  Я использовал параметры ядра по умолчанию без какой-либо оптимизации/настройки, только отключил Transparent HugePages. Эта технология включена по умолчанию и выделяет страницы такого размера, который не рекомендуется использовать для баз данных. В общем случае базам данных нужны HugePages фиксированного размера, но Transparent HugePages не могут их предоставить. Поэтому всегда рекомендуется отключать эту функцию и по умолчанию устанавливать классические HugePages. Я использовал одинаковые настройки PostgreSQL для всех тестов, чтобы записывать различные рабочие нагрузки PostgreSQL с различными настройками Linux HugePages. Для всех тестов применялись следующие настройки PostgreSQL: Схема тестирования играет важную роль. Все тесты выполняются три раза, продолжительность каждого запуска — 30 минут. По итогам этих 3-х тестов я вывел среднее значение. Тестирование проводились с помощью инструмента PostgreSQL pgbench, он работает с коэффициентом масштабирования с шагом в примерно 16 МБ нагрузки. По умолчанию в Linux используются страницы памяти размером 4K, а также технология HugePages. В BSD применяется технология Super Pages, а в Windows — Large Pages. PostgreSQL поддерживает только технологию HugePages (Linux). В случаях, когда объем используемой памяти велик, страницы меньшего размера снижают производительность. Используя HugePages, вы увеличиваете выделенную память для приложения и, следовательно, уменьшаете «накладные расходы», которые возникают в процессе выделения/подкачки. Таким образом, HugePages повышают производительность. Здесь представлены настройки для HugePages размером 1 ГБ. Эта информация доступна в любой момент, с помощью /proc. Подробнее о HugePages я писал в предыдущем посте. https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/ В общем случае HugePages имеют размеры 2 МБ и 1 ГБ, поэтому имеет смысл использовать 1 ГБ. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhuge https://kerneltalks.com/services/what-is-huge-pages-in-linux/ Этот тест показывает общий эффект от использования HugePages различного размера. Первый набор тестов был создан с размером страницы 4K — используется в Linux по умолчанию — и без активации HugePages. Напомню: опцию Transparent HugePages я отключил на все время тестов. Затем второй набор тестов был выполнен для HugePages размером 2 МБ. Наконец, третий набор тестов выполнялся для HugePages размером 1 ГБ. Для всех сравнительных тестов использовалась СУБД PostgreSQL версии 11. Наборы включают комбинации различных размеров баз данных и различных клиентов. На графике ниже показаны результаты сравнения производительности с помощью этих тестов: TPS (число транзакций в секунду) — по оси Y, а размер базы данных и количество клиентов для базы данных определенного размера — по оси X.  Из приведенного выше графика видно, что, от использования HugePages, выигрыш растет по мере того, как увеличивается число клиентов и размер базы данных — до тех пор, пока этот размер остается в рамках предварительно выделенного общего буфера. В этом тесте сопоставлялись показатели TPS и количество клиентов. В данном случае размер базы данных — 48 ГБ. На оси Y показано TPS, а на оси X — количество подключенных клиентов. Размер базы данных достаточно мал, чтобы она могла поместиться в общий буфер с установленным размером 64 ГБ.  Когда размер HugePages равен 1 ГБ, сравнительный выигрыш в производительности растет с увеличением числа клиентов. Следующий график такой же, как и предыдущий, но размер базы данных — 96 ГБ. Это больше установленного размера общего буфера, равного 64 ГБ.  Главное, что здесь необходимо отметить: производительность с HugePages размером 1 ГБ повышается по мере увеличения числа клиентов и в конечном итоге обеспечивает лучшие показатели, чем при использовании HugePages размером 2 МБ или стандартных страниц размером 4 КБ. Этот тест показывает соотношение TPS и размера базы данных. В данном случае число подключенных клиентов равно 32. На оси Y показано TPS, а на оси X — размеры базы данных.  Как и ожидалось, когда размер базы данных превышает размер заранее выделенных HugePages, производительность значительно снижается. Одна из моих основных рекомендаций — отключать Transparent HugePages. Вы получите наибольший прирост производительности, если база данных помещается в общий буфер с включенными HugePages. Определение оптимального размера HugePages проводится методом проб и ошибок, но потенциально такой подход может привести к значительному выигрышу в TPS, когда размер базы данных достаточно велик, но при этом позволяет ей поместиться в общем буфере.