Alguns dias atrás, lançamos o pglogical, uma solução de replicação lógica totalmente de código aberto para PostgreSQL, que esperamos ser incluída na árvore do PostgreSQL em um futuro não muito distante. Não vou discutir sobre todas as coisas habilitadas pela replicação lógica – o anúncio de lançamento do pglogical apresenta uma visão geral muito boa, e Simon também explicou brevemente as vantagens da replicação lógica em outro post alguns dias atrás.
Em vez disso, gostaria de falar sobre um aspecto específico mencionado no anúncio – comparação de desempenho com soluções existentes. A página pglogical menciona
Referência
Esta postagem explica os detalhes dos benchmarks que realizamos para encontrar a taxa de transferência máxima “sustentável” (transações por segundo) que cada uma das soluções pode lidar sem atrasos. Para fazer isso, executei vários testes do pgbench em um par de instâncias da AWS i2.4xlarge com número variável de clientes e medindo a taxa de transferência no mestre e quanto tempo o standby levou para recuperar (se estava atrasado) . Os resultados foram então usados para calcular uma estimativa da taxa de transferência máxima no nó de espera.
Por exemplo, digamos que estamos executando o pgbench com 16 clientes por 30 minutos e medimos 10.000 tps no mestre, mas o modo de espera estava atrasado e levou mais 15 minutos para recuperar o atraso. Então, a estimativa de rendimento máximo sustentável é
tps =(transações executadas) / (tempo de execução total até que o standby seja alcançado)
ou seja
tps =(30 60 10.000) / (45 * 60) =18.000.000 / 2.700 =6.666
Portanto, nesse caso, a taxa de transferência máxima sustentável no modo de espera é de 6,666 tps, ou seja, apenas ~66% da taxa de transação medida no mestre.
Sistema
O benchmark foi realizado em um par de instâncias da AWS i2.4xlarge, configuradas no mesmo grupo de posicionamento (portanto, com conexão de rede de ~ 2 Gbit entre elas) e 4 unidades SSD configuradas em RAID-0 (portanto, é improvável que a E/S seja um problema aqui). As instâncias têm ~ 122 GB de RAM, portanto, o conjunto de dados (pgbench com escala 5000) cabe na RAM. Todos os testes foram realizados no PostgreSQL 9.5.0 com exatamente a mesma configuração:
checkpoint_timeout = 15min
effective_io_concurrency = 32
maintenance_work_mem = 1GB
max_wal_size = 8GB
min_wal_size = 2GB
shared_buffers = 16GB Para todos os sistemas de replicação, foi utilizada a versão mais recente disponível, principalmente
- slony1 2.2.4
- skytools 3.2
e uma replicação simples foi configurada conforme descrito nos tutoriais (ambos usam o exemplo pgbench usado para o benchmark).
Resultados
Os resultados apresentados a seguir também incluem a replicação de streaming (modo assíncrono) para fornecer uma ideia melhor da sobrecarga associada à replicação lógica. As taxas de transação não são os números "brutos" medidos pelo pgbench, mas as taxas "sustentáveis" calculadas usando a fórmula apresentada no início deste post.
| clientes | transmissão | pglógico | desleixado | londrino |
|---|---|---|---|---|
| 1 | 1075 | 1052 | 949 | 861 |
| 2 | 2118 | 2048 | 1806 | 1657 |
| 4 | 3894 | 3820 | 3456 | 1643 |
| 8 | 6506 | 6442 | 2040 | 1645 |
| 16 | 9570 | 8251 | 1535 | 1635 |
| 24 | 11388 | 7728 | 1548 | 1622 |
| 32 | 12384 | 7818 | 1358 | 1623 |
