Способны ли 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 такой имеется: заходим → 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.

Методику теста и полученные результаты давайте обсудим в комментариях.