Опыт тестирования PostgreSQL 13 на ARM-серверах HUAWEI TaiShan 200

Цели тестирования

Перед началом тестирования популярного сервера баз данных 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 / 1шт. 3.2TB 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) для каждого продукта с официального сайта https://www.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)

-bash-4.2$

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

После проведения серии тестовых запусков с количеством одновременных соединений 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 оказалась выше производительности аналогичной конфигурации на платформе x86 на уровне 10-15%.

Заключение

Производительность системы зависит от используемого оборудования, операционной системы и базового программного обеспечения. На это также влияет общий дизайн каждой подсистемы, используемые алгоритмы и настройки компилятора.

Основываясь на результатах текущего тестирования с синтетическими данными, мы можем сделать вывод, что серверы могут использоваться в качестве высоконагруженных узлов PostgreSQL и способны выдать производительность не ниже, чем аналогичные платформы x86. В среднем производительность сервера на платформе ARM выше аналогичной конфигурации на платформе x86 на уровне 10-15%.