09.01.2019 15:08
nAbdullin 0 7300 Источник

Ядро Linux предоставляет широкий спектр параметров конфигурации, которые могут повлиять на производительность. Главное — выбрать правильную конфигурацию для вашего приложения и рабочей нагрузки. Как и любой другой базе данных, PostgreSQL необходима оптимальная настройка ядра Linux. Неправильные настройки могут привести к снижению производительности. Важно проводить сравнительный анализ производительности базы данных после каждого сеанса настройки. В одном из своих предыдущих постов под названием "Tune Linux Kernel Parameters For PostgreSQL Optimization" я описал некоторые из наиболее полезных параметров ядра Linux и то, как они помогают повысить производительность базы данных. Теперь я поделюсь результатами сравнительного тестирования после настройки HugePages в Linux под различными нагрузками PostgreSQL. Я провел полный набор тестов под множеством различных нагрузок PostgreSQL с различным числом параллельных клиентов.


image


ПК, на котором выполнялось тестирование


  • Сервер Supermicro:
    1. Intel® Xeon® CPU E5-2683 v3 @ 2,00 ГГц
    2. 2 сокета / 28 ядер / 56 потоков
    3. Память: ОЗУ 256 ГБ
    4. Накопитель: SAMSUNG SM863 1,9 ТБ Enterprise SSD
    5. Файловая система: 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://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.


image


Из приведенного выше графика видно, что, от использования HugePages, выигрыш растет по мере того, как увеличивается число клиентов и размер базы данных — до тех пор, пока этот размер остается в рамках предварительно выделенного общего буфера.


В этом тесте сопоставлялись показатели TPS и количество клиентов. В данном случае размер базы данных — 48 ГБ. На оси Y показано TPS, а на оси X — количество подключенных клиентов. Размер базы данных достаточно мал, чтобы она могла поместиться в общий буфер с установленным размером 64 ГБ.


image


Когда размер HugePages равен 1 ГБ, сравнительный выигрыш в производительности растет с увеличением числа клиентов.


Следующий график такой же, как и предыдущий, но размер базы данных — 96 ГБ. Это больше установленного размера общего буфера, равного 64 ГБ.



Главное, что здесь необходимо отметить: производительность с HugePages размером 1 ГБ повышается по мере увеличения числа клиентов и в конечном итоге обеспечивает лучшие показатели, чем при использовании HugePages размером 2 МБ или стандартных страниц размером 4 КБ.


Этот тест показывает соотношение TPS и размера базы данных. В данном случае число подключенных клиентов равно 32. На оси Y показано TPS, а на оси X — размеры базы данных.


image


Как и ожидалось, когда размер базы данных превышает размер заранее выделенных HugePages, производительность значительно снижается.


Заключение


Одна из моих основных рекомендаций — отключать Transparent HugePages. Вы получите наибольший прирост производительности, если база данных помещается в общий буфер с включенными HugePages. Определение оптимального размера HugePages проводится методом проб и ошибок, но потенциально такой подход может привести к значительному выигрышу в TPS, когда размер базы данных достаточно велик, но при этом позволяет ей поместиться в общем буфере.

Комментарии (0)