-----Mensagem original----- De: pgbr-geral [mailto:[email protected]] Em nome de Euler Taveira Enviada em: sexta-feira, 22 de novembro de 2013 17:46 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] BGwriter process - consumo de memória
On 22-11-2013 12:21, Monica Ferrari Villarino wrote: > Estou com problema de desempenho numa aplicação (zabbix), desde que recuperei > o banco, após ter estourado um dos discos que suportam o banco de dados > postgresql ( versão: "PostgreSQL 9.0.4 on x86_64-unknown-linux-gnu, compiled > by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48), 64-bit"). > Atualize sua versão. Já existe a 9.0.14 com inúmeras correções. Sim. Já está na minha lista "To do", mas estamos aguardando uma janela de manutenção disponível. Como esse banco é exclusivo da aplicação que monitora todo nosso ambiente de produção, temos que aguardar o melhor momento para fazer melhorias. > A aplicação está a todo momento caindo ou travando, sempre com muitos > processos enfileirados. > E qual é a causa? Todo mundo quer culpar o banco de dados (é bem mais fácil) mas na maioria das vezes o problema está a algumas camadas acima. Calma Euler, estou do seu lado, trabalho exclusivamente na administração de BD, esse discurso costuma ser dos desenvolvedores, mas justamente por trabalhar como administradora, sabemos que as vezes alguns ajustes no ambiente, pode auxiliar no desempenho da aplicação, principalmente quando se trata de uma aplicação de terceiros, em que não é possível alterar as instruções. E neste caso, descobrimos que alterando o parâmetro "enable_nestloop" para "off" nossas consultas ficaram muito mais rápidas, e o gargalo das filas foi eliminado. Ainda assim agradeço pelos comentários e textos sugeridos. > Estive verificando os parâmetros de banco, mais precisamente os de memória e > também os processos existentes, e vi que o processo "writer" do postgresql é > o processo que mais consome memória atualmente, pelo coluna RES do comando > TOP, verifico que são 6,1B. Achei esse valor muito elevado, já que o meu > shared_buffers está em 8GB. > Se você observar SHR também é 6.1g. Isso quer dizer que (quase) toda a memória listada ali é por conta da memória compartilhada. Sugiro ler [1] e [2]. > Alguns parâmetros do meu banco são: > > max_connections = 500 > shared_buffers = 8GB > work_mem = 32MB > maintenance_work_mem = 2GB > > Sendo que o servidor tem 24GB de memória. > Como você forneceu pouca informação não dá para dizer muita coisa mas talvez o shared_buffers esteja muito alto. Esse número de conexões também me parece alto (se sua aplicação for web, você está utilizando um pool? Deveria). Infelizmente não usamos pool para conexões, mas assim que tiver uma oportunidade (puder fazer um restart do banco) vou reduzir o parâmetro " max_connections". Atualmente vejo que muitas conexões abertas em estado "idle" > Também li num post antigo aqui na lista que o parâmetro effective_cache_size > deveria ser 50% do total de RAM da máquina e no meu banco esse parâmetro > ainda está com o valor default da instalação, ou seja 1GB. Devo aumentar para > 50% da memória RAM? > Essa memória não é alocada. O valor é somente para fins de planejamento de consultas. [1] http://lwn.net/Articles/230975/ [2] http://rhaas.blogspot.com.br/2012/01/linux-memory-reporting.html Agradeço a todos que me responderam, sugerindo algum caminho. _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
