2013/6/16 Cibelle Daniele <[email protected]> > Olá, > > Olá. Tudo bem?
> Estou trabalhando em uma aplicação atualmente que é basicamente um sistema > que recebe carga de dados ocasionalmente, e no restante do período faz > basicamente consultas aos dados das tabelas do sistema (aproximadamente 50 > tabelas), somente esses dados. Nessa consulta de dados, e atualiza > praticamente uma única tabela durante essas consultas, nessas consultas > também consulta constantemente essa tabela. Estamos usando o postgresql > 9.2, a máquina possui 16 GB de RAM, e a aplicação utiliza o hibernate para > acesso ao BD. > > E com relação à quantidade de usuários nesse sistema? E a CPU do servidor (núcleos e frequência)? E os discos? > A máquina onde está o banco de dados, fica com picos constantes da > utilização da cpu em 99% e pelo que analisei pelo vmstat a espera dos > processos nos momentos de pico é basicamente por I/O. > Defina "basicamente"! Seria melhor colocar o resultado de algumas dessas coletas pra gente analisar melhor. É possível? > Fiz alterações no postgresql.conf para para ter checkpoints a cada 15 > minutos. Segue alguns parâmetros do postgresql: > shared_buffers=4GB > Parece suficiente, mas é bom monitorar (blks_hit e blks_read na pg_stat_database ou usando pg_buffercache). > checkpoint_segments=90 > checkpoint_timeout=15min > Algum motivo específico para colocar o checkpoint_segments tão alto? Quanto ao checkpoint_timeout, eu também diria para deixar o padrão (5min) e monitorar pra ver se realmente precisa aumentar. > work_mem=4MB > Tão pouquinho! > wal_buffers=16MB > maintenance_work_mem=128mb > checkpoint_completion_target=0.9 > > Esses parecem o suficiente (numa "olhada por cima"). > Eu acho que se conseguir trabalhar com essa tabela em memória eu teria > menos problemas de I/O. Vocês sabem se tem algum jeito de eu fazer isso? > Tem alguma configuração do postgresql que eu possa fazer para acabar com > esse meu problema de acesso a essa tabela? > > Sou nova no uso do Postgresql, esse é o primeiro projeto que trabalho com > esse SGBD, > > Sinceramente, me parece que você está atacando o problema pelo "lado errado". O ideal seria você analisar as consultas (um EXPLAIN ANALYZE) mais lentas e tentar otimizá-las, antes de tudo. Em 97,37453% dos casos, um simples índice resolve o problema (e 83,924% das pesquisas são inventadas, =P ). Eu recomendaria você a usar o pgBadger e/ou pg_stat_statements e coletar as consultas mais lentas. Em seguida, tente otimizá-las ou poste aqui o EXPLAIN delas, usando [3]. Qualquer ajuda será bem-vinda. > > Obrigada. > Cibelle > > > Disponha. [1] http://dalibo.github.io/pgbadger/ [2] http://www.postgresql.org/docs/current/static/pgstatstatements.html [3] http://explain.depesz.com/ Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
