Estudo de Caso III – postgresql.conf

Continuamos nosso estudo de caso, falando sobre os parâmetros do postgresql.conf de forma a melhor o desempenho, sem alteração de hardware.

stats_temp_directory (string)

Dentro do arquivo postgresql, o parâmetro stats_temp_directory permite configurar um diretório específico para a gravação das estatística. Como as estatísticas são zeradas a cada reinício do PostgreSQL, um diretório em memória pode ser utilizado, para diminuir o consumo de I/O.

statement_timeout (integer)

Comandos SQL que durarem mais do que o tempo aqui definido serão abortados. Zero desligará esta opção. Não é recomendado utilizar um timeout pelo postgresql.conf, pois todas as sessões e usuários serão afetados.

commit_delay e commit_siblings

Em servidores com muitas transações concorrentes onde a carga de IO é muito alta, é possível aglomerar vários commits em um único “fsync” utilizando o recurso de “commit atrasado”, o qual consiste em esperar uma quantidade de tempo e ou transações antes de realizar o “fsync” e retornar os commits.Para habilitar este recurso deve-se alterar o valor padrão da opção commit_delay de 0(valor padrão) para a quantidade de milissegundos que esteja esperar por outras transações. Em paralelo deve-se ajustar também a opção commit_siblings na qual deve-se definir o mínimo de transações simultâneas para que o PostgreSQL aguarde o tempo definido em commit_delay por novos commits.

Este recurso pode reduzir a carga de IO no pg_xlog em servidores muito concorridos sem trazer risco de perda de dados. Porem, por outro lado, em servidores com pouca concorrência pode acrescentar uma atraso desnecessário e denegrir o desempenho.

wal_buffers

Antes de serem gravados fisicamente em disco, os dados dos logs de transação são armazenados em uma área de memoria compartilhada denominada wal_buffers, a qual tem seu conteúdo gravado em disco a cada commit. O tamanho desta área é definido na opção wal_buffers o que por padrão nas últimas versões do PostgreSQL utiliza o valor -1, o qual representa um espécie de “auto tuning” pois dessa forma seu tamanho é de aproximadamente 3% o valor dos shared buffers. Aumentar este valor pode ajudar em servidores onde existem muitas transações concorrentes, porem o aumento excessivo pode causar picos de IO devido a grande quantidade de dados sendo gravados de uma única vez. Na maioria dos casos o valor padrão é suficiente.

shared_buffers

Ao iniciar o PostgreSQL, este segmento de memória sera totalmente alocado. O sistema operacional deve estar configurado para aceitar a quantidade de memória compartilhada especificada aqui. O valor padrão típico é 1000(32MB), mas este valor pode ser menor devido a algumas configuração do ser sistema operacional. Esse valor também pode ser definido em unidades de memória (kB, MB ou GB).

Para bom desempenho em produção, este valor deve ser aumentado, pois o valor padrão vem definido somente para permitir a inicialização do banco, porem este assunto será abordado em capítulo futuro. De maneira geral recomenda-se que o tamanho dos shared buffers não ultrapassem 40% do tamanho da memoria RAM, e também não ultrapassem a faixa dos 4GB a 8GB.

Existem limitações em ambiente Windows que tornam o uso de grandes quantidades de shared buffer inviável. Em testes realizados, valores maiores que 256MB causaram degradação do desempenho.
Conclusão

Com estes parâmetros bem configurados, é possível observar um ganho de performance. No próximo post, falaremos um pouco mais sobre outros parâmetros para melhorar o desempenho.