O kernel do Linux fornece uma ampla variedade de opções de configuração que podem afetar o desempenho. O principal é escolher a configuração correta para seu aplicativo e carga de trabalho. Como qualquer outro banco de dados, o PostgreSQL precisa de um ajuste ideal do kernel do Linux. Configurações incorretas podem resultar em desempenho ruim. É importante realizar uma análise comparativa do desempenho do banco de dados após cada sessão de ajuste. Em uma das minhas postagens anteriores, intitulada “Ajustar 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 ajudam a melhorar o desempenho do banco de dados. Agora, compartilharei os resultados dos testes comparativos após a configuração do HugePages no Linux, sob várias cargas do PostgreSQL. Conduzi um conjunto de testes completo sob muitas cargas de trabalho diferentes do PostgreSQL com um número diferente de clientes simultâneos.
PC no qual o teste foi realizado
- Servidor Supermicro:
- CPU Intel® Xeon® E5-2683 v3 a 2,00 GHz
- 2 tomadas / 28 núcleos / 56 fios
- Memória: 256 GB RAM
- Armazenamento: SSD SAMSUNG SM863 de 1,9 TB para empresas
- 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
Eu usei os parâmetros padrão do kernel sem qualquer otimização / aprimoramento, apenas desabilitei o Transparent HugePages. Essa tecnologia é ativada por padrão e aloca páginas de um tamanho não recomendado para uso com bancos de dados. Em geral, os bancos de dados precisam de HugePages de tamanho fixo, mas o Transparent HugePages não pode fornecê-los. Portanto, é sempre recomendável desativar esse recurso e, por padrão, instalar o HugePages clássico.
Configurações do PostgreSQL
Usei as mesmas configurações do PostgreSQL para todos os testes para registrar diferentes cargas de trabalho do PostgreSQL com diferentes configurações do Linux HugePages. Para todos os testes, as seguintes configurações do PostgreSQL foram aplicadas:
shared_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
O esquema de teste desempenha um papel importante. Todos os testes são realizados três vezes, a duração de cada execução é de 30 minutos. Com base nos resultados desses três testes, deduzi o valor médio. O teste foi realizado com a ferramenta pgench PostgreSQL, que funciona com um fator de escala em incrementos de aproximadamente 16 MB de carga.
Hugepages
Por padrão, o Linux usa páginas de memória 4K, além da tecnologia HugePages. O BSD usa a tecnologia Super Pages e o Windows usa páginas grandes. O PostgreSQL suporta apenas a tecnologia HugePages (Linux). Nos casos em que a quantidade de memória usada é grande, páginas menores reduzem o desempenho. Usando HugePages, você aumenta a memória alocada para o aplicativo e, portanto, reduz a "sobrecarga" que ocorre durante o processo de alocação / troca. Assim, o HugePages aumenta a produtividade.
Aqui estão as configurações do HugePages com 1 GB de tamanho. Esta informação está disponível a qualquer momento usando / proc.
AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 100 HugePages_Free: 97 HugePages_Rsvd: 63 HugePages_Surp: 0 Hugepagesize: 1048576 kB
Eu escrevi mais sobre HugePages em um post anterior.
https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/
Em geral, o HugePages tem 2 MB e 1 GB de tamanho, portanto, faz sentido usar 1 GB.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhuge
https://kerneltalks.com/services/what-is-huge-pages-in-linux/
Resultados do teste
Este teste mostra o efeito geral do uso de HugePages de vários tamanhos. O primeiro conjunto de testes foi criado com um tamanho de página de 4K - usado por padrão no Linux - e sem a ativação do HugePages. Deixe-me lembrá-lo: desabilitei a opção Transparent HugePages durante toda a duração dos testes.
Em seguida, um segundo conjunto de testes foi realizado para HugePages com um tamanho de 2 MB. Por fim, um terceiro conjunto de testes foi executado para o HugeGB de 1 GB.
Para todos os testes comparativos, foi utilizado o PostgreSQL DBMS 11. Os kits incluem combinações de vários tamanhos de banco de dados e vários clientes. O gráfico abaixo mostra os resultados de uma comparação de desempenho usando estes testes: TPS (número de transações por segundo) - ao longo do eixo Y, e o tamanho do banco de dados e o número de clientes para um banco de dados de um determinado tamanho - ao longo do eixo X.
É possível observar no gráfico acima que, com o uso de HugePages, o ganho aumenta à medida que o número de clientes e o tamanho do banco de dados aumentam, desde que esse tamanho permaneça no buffer compartilhado pré-alocado.
Este teste comparou o TPS e o número de clientes. Nesse caso, o tamanho do banco de dados é 48 GB. O eixo Y mostra o TPS e o eixo X mostra o número de clientes conectados. O tamanho do banco de dados é pequeno o suficiente para caber em um buffer compartilhado com um tamanho fixo de 64 GB.
Quando o HugePages tem 1 GB, o ganho comparativo de desempenho aumenta com o número de clientes.
O próximo gráfico é o mesmo que o anterior, mas o tamanho do banco de dados é de 96 GB. É maior que o tamanho total fixo do buffer de 64 GB.
O principal a ser observado aqui: o desempenho com o HugePages de 1 GB aumenta à medida que o número de clientes aumenta e, em última análise, fornece melhor desempenho do que o uso de HugePages de 2 MB ou páginas padrão de 4 KB.
Este teste mostra a proporção de TPS para o tamanho do banco de dados. Nesse caso, o número de clientes conectados é 32. No eixo Y, TPS é mostrado e, no eixo X, tamanhos de banco de dados.
Como esperado, quando o tamanho do banco de dados excede o tamanho das HugePages pré-alocadas, o desempenho é reduzido significativamente.
Conclusão
Uma das minhas principais recomendações é desativar o Transparent HugePages. Você obterá o maior aumento de desempenho se o banco de dados for colocado em um buffer compartilhado com o HugePages ativado. O tamanho ideal do HugePages é determinado por tentativa e erro, mas potencialmente essa abordagem pode levar a um ganho significativo no TPS, quando o tamanho do banco de dados é grande o suficiente, mas ao mesmo tempo permite que ele se encaixe em um buffer comum.