Estudo de Caso III – postgresql.conf

Arquivo postgresql.conf

Este arquivo armazena todas as configurações necessárias para configurar o postgres. Dentro dele encontra-se configuração para backup, replicação além das configurações básicas de checkpoint e mensagens no log. Algumas configurações requerem restart, outras apenas reload. Então, lembre-se que nem sempre será necessário parar o banco de dados.

Connections and Authentication

Na seção de conexões e autenticação, temos diversas configurações, mas as mais importantes são:

  • listen_addresses – Local de onde o postgres, escutará conexão. Normalmente, se usa o * para qualquer ip, mas em um ambiente controlado e com segurança, o ideal é usar um ip para escutar outro servidor.
  • port – Porta onde o postgres escutará, por padrão a porta é a 5432 ou 5433.
  • max_connections – Defini o número máximo de conexões que o postgres permite. O postgres trabalha com processos, ou seja, cada conexão criada é um processo, e fica na fila do escalonador do sistema operacional.
  • tcp_keepalives_idle – Tempo em segundos para procurar conexões em idle.
  • tcp_keepalives_interval – Intervalo para verificar a conexão novamente.
  • tcp_keepalives_count – Quantidade de vezes que acontece a verificação, no intervalo de tcp_keepalive_interval
listen_addresses

Endereço TCP/IP em que o servidor deve escutar por conexões. É uma lista separada por vírgula. Pode ser utilizada uma entrada * que representa todos os IPs disponíveis no servidor. Se a lista estiver vazia, apenas conexões baseadas em sockets locais serão aceitas. Este parâmetro só pode ser alterado com o reinício do cluster.

port

Porta TCP em que o cluster está escutando por conexões, sendo 5432 a default. A mesma porta será usada para todos os IPs em que o cluster estiver escutando. Este parâmetro só pode ser alterado com o reinício do cluster..

max_connections

Ao aumentar o número máximo de conexões, o PostgreSQL vai exigir duas coisas: um valor mais alto em shared_buffers e a alocação de mais semáforos do sistema operacional

Ao aumentar o valor de shared_buffers, podem ocorrer erros no log do PostgreSQL dizendo que não conseguiu alocar memória (shmget) compartilhada. Todo sistema operacional Unix tem parâmetros chamados de System V IPC – Interprocess Communication. O parâmetro para tamanho máximo de memória compartilhada permitida pelo kernel de um sistema operacional deste tipo é SHMMAX. O valor de SHMMAX é bastante conservador nas distribuições Linux.

O número máximo de conexões que o PostgreSQL pode aceitar é definida na opção “max_connections”. Ao aumentar este número significa aumentar o uso de memória compartilhada em aproximadamente 400 bytes por conexão. O ideal é que se evite ao máximo um número grande de conexões no PostgreSQL. Números maiores que 200 já podem ser considerados grandes, lembre-se que normalmente é a aplicação quem conecta no banco é não os usuários por isso poucas conexões bastam.

tcp_keepalives_idle

Disponível apenas em sistemas que suportem a opção de socket TCP_KEEPIDLE. É o número de segundos entre o envio de sinais keepalive em conexões dormentes (idle). Zero utilizará o default do sistema operacional. Se não suportado pelo S.O., deve ser utilizado zero ou erros aparecerão no arquivo de log

tcp_keepalives_interval

É o número de segundos a esperar por uma resposta antes de solicitar um próximo sinal keepalive em conexões dormentes (idle). Zero utilizará o default do sistema operacional. Se não suportado pelo S.O., deve ser utilizado zero ou erros aparecerão no arquivo de log.

tcp_keepalives_count

Disponível apenas em sistemas que suportem a opção de socket TCP_KEEPCNT. É o número de sinais keepalive a enviar em conexões dormentes (idle) antes de considerá-la morta. Zero utilizará o default do sistema operacional. Se não suportado pelo S.O., deve ser utilizado zero ou erros aparecerão no arquivo de log.

Conclusão

Os parâmetros acima, não trazem grandes performances, eles apenas são configurações iniciais que devem ser feitas no momento da instalação do postgres, lembre-se de sempre testar cada configuração. No próximo post, continuamos a falar sobre o postgresql.conf.