Olá Habr! Apresento a você a tradução do artigo original
“Benchmark PostgreSQL no FreeBSD, CentOS, Ubuntu Debian e openSUSE” de Martin Kováčik. Ele examina os testes do PostgreSQL 10.1 DBMS em ambientes próximos às condições reais em vários sistemas unix.
Tradução
Neste post, mostrarei os resultados dos testes do PostgreSQL 10.1 lançado recentemente. Eu verifiquei o banco de dados nesses sistemas operacionais (todos de 64 bits):
- Ubuntu 16.04 , kernel 4.10.0-38-genérico
- openSUSE 42.3, kernel 4.4.87-25-padrão
- CentOS 7.4 , kernel 3.10.0-693.2.2.el7.x86_64
- Debian 9.2 , kernel 4.9.0-4-amd64
- FreeBSD 11.1
Metodologia de teste
O objetivo do teste era medir o desempenho do PostgreSQL em condições semelhantes às implantações de produção (típicas):
- os clientes se conectam por meio do pool de conexões para garantir que não haja reconexão permanente com o banco de dados (não usei o pool de conexão, não usei o sinalizador -C pgbench)
- clientes se conectam através de uma rede, não através de um soquete unix
- Diretório de dados do PostgreSQL localizado no espelho RAID 1
Para cada um dos sistemas operacionais testados, um banco de dados de controle de ~ 74 GB foi criado:
pgbench -i -s 5000 pgbench
A infraestrutura de teste consistia em dois servidores dedicados conectados a uma rede de 1 Gbps:
- EX41-SSD: Intel i7-6700, 4 núcleos, 8 threads, 32 GB de RAM DDR4, usado para gerar consultas SQL usando o pgbench
- PX121-SSD: Intel Xeon E5-1650 v3, 6 núcleos, 12 threads, ECC DDR4 de 256 GB RAM, 2 x 480 GB SATA 6 Gb / s, data center da série SSD, foi usado como servidor PostgreSQL
Eu estava interessado nessas combinações de teste:
- Somente leitura de 32 GB : teste somente leitura (apenas amostras sem alterar dados), o conjunto de dados não se encaixa no cache do PostgreSQL
- 200 GB somente leitura: teste somente leitura, o conjunto de dados é armazenado em cache no PostgreSQL
- TCP-B de 32 GB : leitura e gravação, o conjunto de dados não cabe no cache do PostgreSQL
- TCP-B 200 GB : leitura, gravação, conjunto de dados é armazenado em cache no PostgreSQL
configuração pgbench
O programa pgbench versão 10.1, rodando em um computador FreeBSD 11.1 separado, foi usado para gerar a carga. O script de teste consistia em três partes: vácuo + aquecimento, teste somente leitura e teste de leitura e gravação. Antes de cada teste de leitura e gravação, as tabelas pgbench foram limpas (o sinalizador -v foi usado). Durante o teste, aumentei gradualmente o número de clientes acessando o banco de dados.
Configurações do servidor PostgreSQL
Para distribuições Linux, o PostgreSQL foi instalado no sistema de arquivos ext4 na configuração RAID1 (software RAID usando mdraid) em dois SSDs com o
atime desativado. No caso do FreeBSD, o sistema de arquivos OpenZFS foi usado em dois SSDs ao configurar o RAID1. Um conjunto de dados do ZFS com dados do PostgreSQL foi criado com os seguintes parâmetros:
zfs get recordsize,logbias,primarycache,atime,compression zroot/var/db/postgres NAME PROPERTY VALUE SOURCE zroot/var/db/postgres recordsize 8K local zroot/var/db/postgres logbias throughput local zroot/var/db/postgres primarycache all default zroot/var/db/postgres atime off inherited from zroot zroot/var/db/postgres compression lz4 local
A configuração do servidor PostgreSQL era a mesma em todos os sistemas operacionais, exceto nos caminhos de arquivo (cada sistema operacional usa sua própria estrutura de diretórios). O conteúdo do arquivo
postgresql.conf (configurações básicas) para uma instância de 32 GB:
autovacuum = off default_statistics_target = 100 maintenance_work_mem = 1GB checkpoint_completion_target = 0.9 effective_cache_size = 24GB work_mem = 104MB wal_buffers = 16MB shared_buffers = 8GB max_connections = 300
O conteúdo do arquivo
postgresql.conf para a instância de 200 GB:
autovacuum = off default_statistics_target = 100 maintenance_work_mem = 2GB checkpoint_completion_target = 0.9 effective_cache_size = 144GB work_mem = 640MB wal_buffers = 16MB shared_buffers = 48GB max_connections = 300
Benchmarking
Testei o PostgreSQL em cinco sistemas operacionais diferentes em dois modos - somente leitura e TCP-B (leitura e gravação) com dois perfis de memória diferentes. O teste de cada sistema operacional levou cerca de 30 horas (sem contar o tempo necessário para configurar o sistema operacional). Os resultados de cada execução do pgbench foram salvos para avaliação posterior.
Resultados - Somente leitura
Resultados - TCP-B
Sumário
O teste mostrou que a diferença entre as várias distribuições GNU / Linux não é muito significativa. O OpenSUSE 42.3 foi o melhor sistema operacional no teste somente leitura, enquanto o FreeBSD ficou cerca de 40% mais lento. Infelizmente, não descobri o que causou esse desempenho medíocre do FreeBSD.
Uma imagem mais realista do desempenho do PostgreSQL foi obtida no teste de leitura e gravação (TCP-B). Entre as distribuições GNU / Linux, o Centos 7.4 foi o mais rápido e o Debian 9.2 o mais lento. Fiquei agradavelmente surpreendido com o FreeBSD 11.1, que rodava duas vezes mais rápido que o melhor Linux, apesar do FreeBSD usar o ZFS, que é um sistema de arquivos de cópia em gravação. Supus que essa diferença fosse causada pelo custo do software RAID no Linux, então fiz mais três testes TCP-B para 100 clientes simultâneos, desta vez sem o software RAID:
- FreeBSD 11.1 + UFS : 5623.86 TPS
- FreeBSD 11.1 + ZFS : 8331.85 TPS
- CentOS 7.4 + ext4 : 8987.65 TPS
Os resultados mostram a ineficiência do Linux SW RAID (ou a eficiência do ZFS RAID). O desempenho do CentOS 7.4 sem SW RAID é apenas ligeiramente superior ao do FreeBSD 11.1 com ZFS RAID (para TCP-B e 100 clientes simultâneos).