Ядро Linux предоставляет широкий спектр параметров конфигурации, которые могут повлиять на производительность. Главное — выбрать правильную конфигурацию для вашего приложения и рабочей нагрузки. Как и любой другой базе данных, PostgreSQL необходима оптимальная настройка ядра Linux. Неправильные настройки могут привести к снижению производительности. Важно проводить сравнительный анализ производительности базы данных после каждого сеанса настройки. В одном из своих предыдущих постов под названием "Tune Linux Kernel Parameters For PostgreSQL Optimization" я описал некоторые из наиболее полезных параметров ядра Linux и то, как они помогают повысить производительность базы данных. Теперь я поделюсь результатами сравнительного тестирования после настройки HugePages в Linux под различными нагрузками PostgreSQL. Я провел полный набор тестов под множеством различных нагрузок PostgreSQL с различным числом параллельных клиентов.
ПК, на котором выполнялось тестирование
- Сервер Supermicro:
- Intel® Xeon® CPU E5-2683 v3 @ 2,00 ГГц
- 2 сокета / 28 ядер / 56 потоков
- Память: ОЗУ 256 ГБ
- Накопитель: SAMSUNG SM863 1,9 ТБ Enterprise SSD
- Файловая система: ext4/xfs
- ОС: Ubuntu 16.04.4, ядро 4.13.0-36-generic
- PostgreSQL: версия 11
Настройки ядра Linux
Я использовал параметры ядра по умолчанию без какой-либо оптимизации/настройки, только отключил Transparent HugePages. Эта технология включена по умолчанию и выделяет страницы такого размера, который не рекомендуется использовать для баз данных. В общем случае базам данных нужны HugePages фиксированного размера, но Transparent HugePages не могут их предоставить. Поэтому всегда рекомендуется отключать эту функцию и по умолчанию устанавливать классические HugePages.
Настройки PostgreSQL
Я использовал одинаковые настройки PostgreSQL для всех тестов, чтобы записывать различные рабочие нагрузки PostgreSQL с различными настройками Linux HugePages. Для всех тестов применялись следующие настройки PostgreSQL:
shared_buffers = '64GB'
work_mem = '1GB'
random_page_cost = '1'
maintenance_work_mem = '2GB'
synchronous_commit = 'on'
seq_page_cost = '1'
max_wal_size = '100GB'
checkpoint_timeout = '10min'
synchronous_commit = 'on'
checkpoint_completion_target = '0.9'
autovacuum_vacuum_scale_factor = '0.4'
effective_cache_size = '200GB'
min_wal_size = '1GB'
wal_compression = 'ON'Схема тестирования
Схема тестирования играет важную роль. Все тесты выполняются три раза, продолжительность каждого запуска — 30 минут. По итогам этих 3-х тестов я вывел среднее значение. Тестирование проводились с помощью инструмента PostgreSQL pgbench, он работает с коэффициентом масштабирования с шагом в примерно 16 МБ нагрузки.
HugePages
По умолчанию в Linux используются страницы памяти размером 4K, а также технология HugePages. В BSD применяется технология Super Pages, а в Windows — Large Pages. PostgreSQL поддерживает только технологию HugePages (Linux). В случаях, когда объем используемой памяти велик, страницы меньшего размера снижают производительность. Используя HugePages, вы увеличиваете выделенную память для приложения и, следовательно, уменьшаете «накладные расходы», которые возникают в процессе выделения/подкачки. Таким образом, HugePages повышают производительность.
Здесь представлены настройки для HugePages размером 1 ГБ. Эта информация доступна в любой момент, с помощью /proc.
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
HugePages_Total: 100
HugePages_Free: 97
HugePages_Rsvd: 63
HugePages_Surp: 0
Hugepagesize: 1048576 kBПодробнее о HugePages я писал в предыдущем посте.
https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/
В общем случае HugePages имеют размеры 2 МБ и 1 ГБ, поэтому имеет смысл использовать 1 ГБ.
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, когда размер базы данных достаточно велик, но при этом позволяет ей поместиться в общем буфере.