Способны ли 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.
Методику теста и полученные результаты давайте обсудим в комментариях.
