O kernel do Linux fornece uma ampla variedade de opções de configuração que podem afetar o desempenho. O objetivo é obter a configuração correta para seu aplicativo e carga de trabalho. Como qualquer outro banco de dados, o PostgreSQL usa o kernel do Linux para uma configuração ideal. Configurações mal ajustadas podem resultar em desempenho ruim. Portanto, é importante que você avalie o desempenho do banco de dados após cada sessão de ajuste para evitar a degradação do desempenho. Em uma das minhas publicações anteriores, “Ajustando os parâmetros do kernel do Linux para otimização do PostgreSQL”, descrevi alguns dos parâmetros mais úteis do kernel do Linux e como eles podem ajudá-lo a melhorar o desempenho do banco de dados. Agora vou compartilhar meus resultados de teste depois de configurar páginas grandes do Linux com uma carga de trabalho diferente do PostgreSQL. Realizei um conjunto exaustivo de testes para diferentes tamanhos de carga do PostgreSQL e o número simultâneo de clientes.
Máquina de teste
- Servidor Supermicro:
- CPU Intel® Xeon® E5-2683 v3 a 2.00GHz
- 2 tomadas / 28 núcleos / 56 fios
- Memória: 256 GB de RAM
- Armazenamento: SSD SAMSUNG SM863 1.9TB Enterprise
- Sistema de arquivos: ext4 / xfs
- SO: Ubuntu 16.04.4, kernel 4.13.0-36-genérico
- PostgreSQL: versão 11
Configurações do kernel do Linux
Usei as configurações padrão do kernel sem qualquer otimização / ajuste além de desativar páginas grandes e transparentes (Transparent HugePages). As páginas grandes transparentes são ativadas por padrão e realçam o tamanho da página, o que pode não ser recomendado para uso pelo banco de dados. Os bancos de dados normalmente exigem páginas grandes e de tamanho fixo que não são cobertas por páginas grandes transparentes. Portanto, é sempre recomendável desabilitar esse recurso e usar páginas grandes clássicas por padrão.
Configurações do PostgreSQL
Usei as configurações uniformes do PostgreSQL para todos os testes para registrar diferentes cargas de trabalho do PostgreSQL com configurações diferentes para grandes páginas do Linux. Aqui está a configuração do PostgreSQL usada para todos os testes:
postgresql.confshared_buffers = '64GB' work_mem = '1GB' random_page_cost = '1' maintenance_work_mem = '2GB' synchronous_commit = 'on' seq_page_cost = '1' max_wal_size = '100GB' checkpoint_timeout = '10min' synchronous_commit = 'on' checkpoint_completion_target = '0.9' autovacuum_vacuum_scale_factor = '0.4' effective_cache_size = '200GB' min_wal_size = '1GB' wal_compression = 'ON'
Esquema de teste
Nos testes, o esquema de testes desempenha um papel importante. Todos os testes são realizados três vezes por 30 minutos para cada execução. Avaliei a média desses três indicadores. Os testes foram conduzidos usando a ferramenta de teste de desempenho PostgreSQL
pgbench . O pgbench trabalha com um fator de escala, com um fator de escala de aproximadamente 16 MB de carga de trabalho.
Páginas grandes (HugePages)
O Linux, por padrão, usa páginas 4K de memória junto com páginas grandes. O BSD possui super páginas, enquanto o Windows possui páginas grandes. O PostgreSQL suporta apenas páginas grandes (Linux). Em casos de alto uso de memória, páginas pequenas reduzem o desempenho. Ao instalar páginas grandes, você aumenta a memória alocada para o aplicativo e, consequentemente, reduz os custos operacionais que surgem durante a alocação / troca; isto é, você aumenta a produtividade usando páginas grandes.
Aqui está a configuração para páginas grandes ao usar um tamanho de página grande de 1 GB. Você sempre pode obter essas informações em / proc.
$ cat / proc / meminfo | grep -i enorme AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 100 HugePages_Free: 97 HugePages_Rsvd: 63 HugePages_Surp: 0 Hugepagesize: 1048576 kB
Para mais informações sobre páginas grandes, leia meu post anterior.
https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/Normalmente, as páginas grandes têm 2 MB e 1 GB, portanto, faz sentido usar 1 GB em vez dos 2 MB muito menores.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhugehttps://kerneltalks.com/services/what-is-huge-pages-in-linux/Resultados do teste
Este teste mostra o efeito geral de vários tamanhos de páginas grandes. O primeiro conjunto de testes foi criado com o tamanho de página padrão no Linux 4K sem incluir páginas grandes. Observe que páginas grandes e transparentes também foram desabilitadas e permaneceram desabilitadas durante todos esses testes.
Em seguida, o segundo conjunto de testes foi realizado em páginas grandes de 2 MB. Finalmente, o terceiro conjunto de testes é executado com páginas grandes de 1 GB.
Todos esses testes foram realizados no PostgreSQL versão 11. Os conjuntos incluem uma combinação de diferentes tamanhos de banco de dados e clientes. O gráfico abaixo mostra os resultados comparativos de desempenho desses testes com TPS (transações por segundo) no eixo Y, tamanho do banco de dados e número de clientes por tamanho de banco de dados no eixo X.
Pode ser visto no gráfico acima que o ganho de desempenho com páginas grandes aumenta com o número de clientes e o tamanho do banco de dados, se o tamanho permanecer no buffer alocado anteriormente na memória compartilhada.
Este teste mostra o TPS comparado ao número de clientes. Nesse caso, o tamanho do banco de dados é 48 GB. No eixo Y, temos TPS, e no eixo X, temos o número de clientes conectados. O tamanho do banco de dados é pequeno o suficiente para caber em um buffer compartilhado configurado para 64 GB.
Se páginas grandes estiverem definidas para 1 GB, quanto mais clientes, maior o ganho de desempenho relativo.
O gráfico a seguir é o mesmo que o acima, exceto pelo tamanho do banco de dados de 96 GB. Isso excede o tamanho do buffer compartilhado, definido como 64 GB.
A principal observação aqui é que o desempenho com páginas grandes de 1 GB aumenta à medida que o número de clientes aumenta e, por fim, oferece mais desempenho do que páginas grandes de 2 MB ou o tamanho de página padrão de 4 KB.
Este teste mostra o TPS, dependendo do tamanho do banco de dados. Nesse caso, o número de clientes conectados é 32. No eixo Y, temos o TPS e no eixo X - tamanhos do banco de dados.
Como esperado, quando o banco de dados ultrapassa as páginas grandes pré-alocadas, o desempenho é reduzido significativamente.
Sumário
Uma das minhas principais recomendações é que devemos desativar o Transparent HugePages. Você verá o maior ganho de desempenho quando o banco de dados for colocado em um buffer compartilhado com páginas grandes ativadas. A escolha do tamanho de páginas grandes requer uma pequena quantidade de tentativa e erro, mas isso pode levar a um aumento significativo no TPS quando o tamanho do banco de dados é grande, mas permanece pequeno o suficiente para caber em um buffer compartilhado.