Главная » Хабрахабр » [Перевод] Тестирование PostgreSQL с HugePages в Linux

[Перевод] Тестирование PostgreSQL с HugePages в Linux

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

Настройки PostgreSQL

Для всех тестов применялись следующие настройки PostgreSQL: Я использовал одинаковые настройки PostgreSQL для всех тестов, чтобы записывать различные рабочие нагрузки PostgreSQL с различными настройками Linux HugePages.

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 минут. Схема тестирования играет важную роль. Тестирование проводились с помощью инструмента PostgreSQL pgbench, он работает с коэффициентом масштабирования с шагом в примерно 16 МБ нагрузки. По итогам этих 3-х тестов я вывел среднее значение.

HugePages

В BSD применяется технология Super Pages, а в Windows — Large Pages. По умолчанию в Linux используются страницы памяти размером 4K, а также технология HugePages. В случаях, когда объем используемой памяти велик, страницы меньшего размера снижают производительность. PostgreSQL поддерживает только технологию HugePages (Linux). Таким образом, HugePages повышают производительность. Используя HugePages, вы увеличиваете выделенную память для приложения и, следовательно, уменьшаете «накладные расходы», которые возникают в процессе выделения/подкачки.

Эта информация доступна в любой момент, с помощью /proc. Здесь представлены настройки для HugePages размером 1 ГБ.

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

What is huge pages in Linux?

Результаты тестирования

Первый набор тестов был создан с размером страницы 4K — используется в Linux по умолчанию — и без активации HugePages. Этот тест показывает общий эффект от использования HugePages различного размера. Напомню: опцию Transparent HugePages я отключил на все время тестов.

Наконец, третий набор тестов выполнялся для HugePages размером 1 ГБ. Затем второй набор тестов был выполнен для HugePages размером 2 МБ.

Наборы включают комбинации различных размеров баз данных и различных клиентов. Для всех сравнительных тестов использовалась СУБД PostgreSQL версии 11. На графике ниже показаны результаты сравнения производительности с помощью этих тестов: TPS (число транзакций в секунду) — по оси Y, а размер базы данных и количество клиентов для базы данных определенного размера — по оси X.

image

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

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

image

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

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

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

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

image

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

Заключение

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] CSTroN — самодельный монитор на винтажной CSTN-матрице с VGA-входом и платой управления на ПЛИС

ЖК-монитор с CSTN-матрицей Что если бы TFT никогда не изобрели? Когда ЭЛТ-мониторы преобладали, в их пользу выдвигали следующий аргумент: несмотря на все усовершенствования, ЖК-дисплеи никогда не превзойдут по качеству изображения трубочные. Они, как и прежде, будут находить применение лишь там, ...

Многомировая интерпретация квантовой механики

Наверняка большинство из вас нет-нет да и встречало в научно-популярной литературе упоминания о «многомировой интерпретации» квантовой механики (ММИ). Ее любят помянуть и в комментариях на Хабре, однако зачастую в неверном ключе или с серьезными неточностями. Попробуем разобраться, что же к ...