Ядро Linux предоставляет широкий спектр параметров конфигурации, которые могут повлиять на производительность. Это все о получении правильной конфигурации для вашего приложения и рабочей нагрузки. Как и любая другая база данных, PostgreSQL использует ядро Linux для оптимальной конфигурации. Плохо настроенные параметры могут привести к снижению производительности. Поэтому важно, чтобы вы измеряли производительность базы данных после каждого сеанса настройки, чтобы избежать снижения производительности. В одной из моих предыдущих публикаций, «Настройка параметров ядра Linux для оптимизации PostgreSQL», я описал некоторые наиболее полезные параметры ядра Linux и то, как они могут помочь вам повысить производительность базы данных. Теперь я собираюсь поделиться своими результатами тестов после настройки больших страниц Linux с другой рабочей нагрузкой PostgreSQL. Я выполнил исчерпывающий набор тестов для разных размеров загрузки PostgreSQL и одновременного количества клиентов.
Машина для тестирования
- Supermicro server:
- Intel® Xeon® CPU E5-2683 v3 @ 2.00GHz
- 2 sockets / 28 cores / 56 threads
- Memory: 256GB of RAM
- Storage: SAMSUNG SM863 1.9TB Enterprise SSD
- Filesystem: ext4/xfs
- OS: Ubuntu 16.04.4, kernel 4.13.0-36-generic
- PostgreSQL: version 11
Настройки ядра Linux
Я использовал настройки ядра по умолчанию без какой-либо оптимизации/настройки, кроме отключения прозрачных больших страниц (Transparent HugePages). Прозрачные большие страницы по умолчанию включены и выделяют размер страницы, который может быть не рекомендован для использования базой данных. Как правило, для баз данных требуются большие страницы фиксированного размера, которые не предусматриваются прозрачными большими страницами. Следовательно, всегда рекомендуется отключать эту функцию и использовать по умолчанию классические большие страницы.
Настройки PostgreSQL
Я использовал единые настройки PostgreSQL для всех тестов, чтобы записывать разные рабочие нагрузки PostgreSQL с разными настройками больших страниц Linux. Вот настройка PostgreSQL, используемая для всех тестов:
postgresql.conf
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. pgbench работает с масштабным коэффициентом, при этом один масштабный коэффициент составляет приблизительно 16 МБ рабочей нагрузки.
Большие страницы (HugePages)
Linux по умолчанию использует страницы памяти 4 КБ вместе с большими страницами. У BSD есть Super Pages, тогда как у Windows есть Large Pages. PostgreSQL поддерживает только большие страницы (Linux). В случаях большого использования памяти маленькие страницы снижают производительность. Установив большие страницы, вы увеличиваете выделенную память для приложения и, следовательно, уменьшаете операционные издержки, которые возникают во время выделения/подкачки; то есть вы повышаете производительность, используя большие страницы.
Вот настройка больших страниц при использовании размера большой страницы 1 ГБ. Вы всегда можете получить эту информацию из /proc.
$ cat /proc/meminfo | grep -i huge
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
HugePages_Total: 100
HugePages_Free: 97
HugePages_Rsvd: 63
HugePages_Surp: 0
Hugepagesize: 1048576 kBДля более подробной информации о больших страницах, пожалуйста, прочитайте мой предыдущий пост в блоге.
https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/
Обычно размеры больших страницы составляют 2 МБ и 1 ГБ, поэтому имеет смысл использовать размер 1 ГБ вместо гораздо меньшего размера 2 МБ.
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/
Результаты тестов</h2
Этот тест показывает общее влияние различных размеров больших страниц. Первый набор тестов был создан с размером страницы по умолчанию в Linux 4 КБ без включения больших страниц. Обратите внимание, что прозрачные огромные страницы также были отключены и оставались отключенными на протяжении всех этих тестов.
Затем второй набор тестов был выполнен размером больших страниц в 2 MБ. Наконец, третий набор тестов выполняется с размером больших страниц 1 ГБ.
Все эти тесты были выполнены в PostgreSQL версии 11. Наборы включают в себя комбинацию разных размеров базы данных и клиентов. На приведенном ниже графике показаны сравнительные результаты производительности для этих тестов с TPS (транзакций в секунду) по оси Y, размером базы данных и количеством клиентов на размер базы данных по оси X.
Из приведенного выше графика видно, что прирост производительности с большими страницами увеличивается с увеличением количества клиентов и размера базы данных, если размер остается в предварительно выделенном буфере в разделяемой памяти (shared buffer).
Этот тест показывает TPS в сравнении с количеством клиентов. В этом случае размер базы данных составляет 48 ГБ. На оси Y у нас есть TPS, а на оси X у нас есть количество подключенных клиентов. Размер базы данных достаточно мал, чтобы поместиться в shared buffer, который установлен на 64 ГБ.
Если для больших страниц установлено значение 1 ГБ, то чем больше клиентов, тем выше сравнительный прирост производительности.
Следующий график такой же, как приведенный выше, за исключением размера базы данных 96 ГБ. Это превышает размер shared buffer, который установлен на 64 ГБ.
Ключевое наблюдение здесь заключается в том, что производительность с большими страницами, равными 1 ГБ, увеличивается по мере увеличения числа клиентов, и в конечном итоге она дает большую производительность, чем большие страницы в 2 МБ или стандартный размер страницы в 4 КБ.
Этот тест показывает TPS в зависимости от размера базы данных. В этом случае количество подключенных клиентов составляет 32. На оси Y у нас TPS, а на оси X — размеры базы данных.
Как и ожидалось, когда база данных выходит за пределы предварительно выделенных больших страниц, производительность значительно снижается.
Резюме
Одна из моих ключевых рекомендаций заключается в том, что мы должны отключить прозрачные большие страницы (Transparent HugePages). Вы увидите наибольший прирост производительности, когда база данных помещается в общий буфер с включенным большими страницами. Выбор размера больших страниц требует небольшого количества проб и ошибок, но это может потенциально привести к значительному увеличению TPS, когда размер базы данных велик, но остается достаточно маленьким, чтобы поместиться в shared buffer.
Автор: puyol_dev2
