Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Способны ли ARM-серверы эффективно работать в качестве высоконагруженного решения для PostgreSQL 13? Мы провели синтетические тесты, сравнивая TaiShan 200 с аналогичным оборудованием на платформе x86, и пришли к интересным результатам. Конфигурации, описание методики и выводы – под катом.
Цели тестирования
Перед началом тестирования популярного сервера баз данных PostgreSQL 13 ставилась задача проверить, возможно ли использовать ARM-серверы производства HUAWEI продуктовой линейки TaiShan 200 на базе разработанных дочерней компанией HiSilicon процессоров Kunpeng 920 в качестве высоконагруженных узлов для серверов БД. Попутно предложить вариант оптимизации настроек и получения максимальной производительности сервера, а также сравнить полученные результаты с x86-платформой.
Тестовый сервер и подготовка к тестированию
Практически любому серверу БД для получения максимальной производительности критически важно иметь быстрое и производительное хранилище. В самом простом случае это могут быть размещенные в сервере локальные накопители SSD или NVMe. В расположенной в Москве лаборатории OpenLab подобные ARM-серверы имеются, и для теста была взята модель TaiShan 2280.
Универсальный сервер TaiShan 2280 представляет собой платформу шасси высотой 2U, 2-socket, работающий на 64-разрядном процессоре Huawei Kunpeng 920. Сервер обеспечивает в общей сложности 128 ядер ARMv8.2, работающих на частоте 2,6 ГГц с возможностью установки до 28 твердотельных накопителей NVMe.
Конфигурация тестового сервера и версии ПО
Hardware:
HUAWEI TaiShan 200 (Model 2280) с 2шт. SoC HUAWEI Kunpeng 920 6426 (в каждом CPU по 64 ядра @ 2.60 ГГц)
512 ГБ RAM DDR4 2933 МГц. Установлено 8 модулей 64 ГБ DDR4 DIMM, (минимальная рекомендуемая конфигурация), использовалось 4 канала памяти из 8 доступных
8 HDD 2.5" 1.2TB SAS 10k RPM
3.2 TB HUAWEI ES3000 V5 PCIe NVMe SSD
4 сетевых порта 1GbE
4 сетевых порта 25GbE
Операционная система:
CentOS 7.9 (ядро Linux 4.18.0-193.28.1.el7.aarch64)
СУБД:
PostgreSQL 13.2 on aarch64-linux-gnu, compiled by gcc (GCC) 10.2.0, 64-bit
Средство тестирования (benchmark):
pgbench (PostgreSQL) 13.2
Основной рекомендацией для получения максимальной производительности на ARM-серверах TaiShan является установка последних версий ПО (это также относится и к версии ОС, например, совместимых версий CentOS, Ubuntu и т.д.) с помощью собранного из исходных кодов с оптимизацией под SoC Kunpeng 920 последних версий компилятора gcc.
Результаты собранного с помощью этого компилятора прикладного ПО оказываются выше, т.к. при компиляции идёт оптимизация под CPU. Это дает выигрыш в производительности на том же оборудовании, относительно стандартных пакетов, полученных из публичных репозиториев ОС. Таким образом производится и сборка также чувствительного к производительности прикладного ПО, например, СУБД PostgreSQL.
Повышения производительности можно добиться, применив рекомендации из tuning guide (можно найти в одном из 8 рекомендованных BoostKit) для каждого продукта с официального сайта hikunpeng.com. Для PostgreSQL такой имеется: https://www.hikunpeng.com/en/developer/boostkit/database -> References -> PostgreSQL -> Tuning Guide.
Оптимизация настроек сервера и ядра ОС, конфигурация компилятора и СУБД
В ходе тестирования были выполнены следующие настройки:
Настройки BIOS:
Advanced -> MISC Config -> Support Smmu -> Disable
Advanced -> MISC Config -> CPU Prefetching Configuration -> Disable
Настройки параметров ядра ОС:
sysctl -w vm.swappiness=1
sysctl -w vm.max_map_count=3112960
sysctl -w net.core.somaxconn=1024
Пример конфигурации компилятора gcc 10.2.0:
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/aarch64-linux-gnu/10/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../gcc-10.2.0/configure --enable-languages=c,c++ --with-gcc-major-version-only --enable-shared --disable-multilib --with-arch=armv8.2-a --with-cpu=tsv110 -build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
Пример конфигурации сервера БД PostgreSQL (postgresql.conf):
max_connections = 1024
shared_buffers = 390GB
max_prepared_transactions = 2048
huge_pages = try
work_mem = 1GB
maintenance_work_mem = 2GB
dynamic_shared_memory_type = posix
max_files_per_process = 100000
vacuum_cost_limit = 10000
bgwriter_delay = 10ms
bgwriter_lru_maxpages = 1000
bgwriter_lru_multiplier = 10.0
bgwriter_flush_after = 0
effective_io_concurrency = 200
max_worker_processes = 128
max_parallel_maintenance_workers = 4
max_parallel_workers_per_gather = 4
max_parallel_workers = 128
wal_level = minimal
fsync = on
synchronous_commit = on
wal_sync_method = fsync
full_page_writes = off
wal_compression = on
wal_buffers = 1GB
checkpoint_timeout = 10min
max_wal_size = 20GB
min_wal_size = 1GB
checkpoint_completion_target = 0.9
max_wal_senders = 0
random_page_cost = 1.1
effective_cache_size = 384GB
default_statistics_target = 100
log_checkpoints = on
log_autovacuum_min_duration = 0
autovacuum_max_workers = 5
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.002
autovacuum_analyze_scale_factor = 0.001
Методика тестирования и примеры запуска pgbench
Тестирование производилось стандартным инструментом для PostgreSQL pgbench.
Методика:
1) Создаем тестовую БД следующей командой (размер около 370 ГБ):
pgbench -i -s 25000
2) Выполняем несколько SQL-запросов для разогрева кэша БД:
CREATE EXTENSION pg_prewarm;
select pg_prewarm('pgbench_accounts'::regclass);
select pg_prewarm('pgbench_accounts_pkey'::regclass);
select pg_prewarm('pgbench_tellers'::regclass);
select pg_prewarm('pgbench_history'::regclass);
select pg_prewarm('pgbench_branches'::regclass);
3) Пример команд для запуска теста с помощью pgbench для TPC-B like смешанных запросов (чтение, изменение, запись) и select-only запросов (только чтение):
pgbench -j 128 -c 300 -T 60
pgbench -j 128 -c 300 -T 60 -S
4) Примеры запуска команд:
-bash-4.2$ pgbench -j 128 -c 400 -T 60
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 25000
query mode: simple
number of clients: 400
number of threads: 128
duration: 60 s
number of transactions actually processed: 4252809
latency average = 5.651 ms
tps = 70779.466059 (including connections establishing)
tps = 70859.923988 (excluding connections establishing)
-bash-4.2$ pgbench -j 128 -c 300 -T 60 -S
starting vacuum...end.
transaction type: <builtin: select only>
scaling factor: 25000
query mode: simple
number of clients: 300
number of threads: 128
duration: 60 s
number of transactions actually processed: 59593685
latency average = 0.302 ms
tps = 992318.982321 (including connections establishing)
tps = 1318347.345721 (excluding connections establishing)
Результаты тестирования
После проведения серии тестовых запусков с количеством одновременных соединений 50, 100, 200, 300, 400, 500, 600, 700, 800, 900, 1000шт. были получены следующие результаты:
Сравнение результатов с x86-платформой
Аналогичное тестирование было проведено для сравнения с x86-платформой. Были взяты 64шт. CPU ядер с частотой 2,6 ГГц, выделенных на сервере ARM (SoC HUAWEI Kunpeng 920), и 28шт. CPU ядер с частотой 3,0 ГГц, выделенных на сервере x86 (процессор Intel Xeon Scalable). В среднем производительность сервера на платформе ARM оказалась на 10-15% выше, чем у аналогичной конфигурации на платформе x86.
Заключение
Производительность системы зависит от используемого оборудования, операционной системы (ОС) и базового программного обеспечения. На это также влияет общий дизайн каждой подсистемы, используемые алгоритмы и настройки компилятора.
Результаты текущего тестирования с синтетическими данными показывают, что серверы могут использоваться в качестве высоконагруженных узлов PostgreSQL и способны демонстрировать производительность не ниже, чем аналогичные платформы x86.
Методику теста и полученные результаты давайте обсудим в комментариях.