Postgres DISK IO muito alto. O que posso fazer para reduzi-lo imediatamente?

Question

Estou ciente de que os discos mais rápidos do que os que estou usando ajudarão, mas isso levará mais tempo para colocar e estou tentando usar algumas medidas de emergência para diminuir o IO do disco. no topo está relatando o uso de DSK no vermelho quase constantemente. Isto é para postgres 8.3.

Minha configuração shared_buffers está em 24MB, embora o servidor tenha 16GB de memória RAM, que não são totalmente utilizados. Meu primeiro pensamento foi dar ao banco de dados o máximo de memória RAM possível, mas não tenho certeza de como fazer isso (esse é um servidor de banco de dados dedicado).

Qualquer solução que não requeira uma reinicialização é preferível, mas aceitarei o que posso obter neste ponto.

Obrigado!

    

Answer 1

A configuração shared_buffers de 24MB é o padrão conservador, eu diria que ela precisa ser bem maior para um banco de dados dedicado com 16GB de RAM disponível. Mas sim, você terá que reiniciar o servidor para redimensioná-lo. O link é um bom ponto de partida para diretrizes de configuração de desempenho. Definir os shared_buffers como 4GB ou 6GB parece mais razoável.

Note que no linux você precisa ajustar a configuração do sysctl kernel.shmmax (em /etc/sysctl.conf ou apenas escrevendo / proc / sys / kernel / shmmax) para alocar um bloco dessa quantidade de memória compartilhada. Se você não fizer, você receberá um erro especificando o quanto foi solicitado, você tem que definir o kernel.shmmax maior que isso.

Como você tem muita memória, você também pode considerar a configuração do padrão work_mem mais alto, o que fará coisas como classificações e hashes (grupo / ordem / distintas, etc.) tenderem a funcionar na memória em vez de usar arquivos temporários. Você não precisa reiniciar o servidor para fazer isso, basta atualizar o arquivo de configuração, recarregar o serviço e as sessões new receberão a nova configuração. A memória de trabalho padrão para uma sessão é de 1 MB, você pode calcular o máximo que pode ser usado em uma única vez como work_mem * max_client_connections e estimar o impacto que terá.

Você também deve aumentar effective_cache_size para indicar ao planejador que a camada FS do kernel provavelmente armazenará muitas páginas na memória fora dos buffers compartilhados do postgresql.

Espero que isso te faça um bom começo.

    

Answer 2

Remontar os discos com noatime

    

Answer 3

Além das sugestões dadas aqui, você também pode querer analisar suas configurações de auto-vácuo. Por padrão, ele será acionado após cerca de 50 atualizações e, se o seu banco de dados estiver fazendo muitas atualizações / inserções, isso pode acionar uma quantidade desnecessária de declarações de vácuo que gerarão muitas IOs.

    

Answer 4

On a system that's very close to maximum I/O throughput during normal operation, you might want to increase checkpoint_completion_target to reduce the I/O load from checkpoints. The disadvantage of this is that prolonging checkpoints affects recovery time, because more WAL segments will need to be kept around for possible use in recovery

Veja mais aqui .

    

Answer 5

Se o diskio do postgresql for muito alto, você deve verificar as instruções em execução, especialmente para instruções, fazer uma "ordenação no disco" e definir índices apropriados.

Basta pesquisar no Google por "Ajuste de desempenho do Postgresql", onde você encontrará hinds suficientes por onde começar.