Obrigado pelas informações.
- Atualmente o sistema gera muitas transações de gravação (necessárias),
como também consultas diversas consideradas pesadas e leves;
- Monitoro a memória através do TOP, Free e felizmente esse não tem sido o
problema pois está dentro da normalidade, e não chega a utilizar swap;
- O Sharebuffers em 1024MB optei em função do grande número de consultas que
são realizadas (algumas bem grandes);
- O autovaccum está desabilitado em função de rodar diariamente (a noite) o
vacuum -z -f -v d que através de consultas aqui no fórum poderia
substituir o automático, está correto essa afirmação?;
- Vou pesquisar um pouco mais como configurar o arquivo SYSCTL.CONF, pois
estou perdido nesses parâmetros!
- O parâmetro Wormem coloquei alto por relatos de utilização de ordenação,
agrupadores.. e como alguns relatórios utilizam muito recurso de ordenação,
agrupadores, união, subselects, dump imaginei como importante, mas não sei
afirmar ao certo o ganho!
- Na verdade tenho operações pesadas de gravação inclusive com transação
quando leitura, por isso optei por setar o commit_delay
- As chaves estrangeiras e campos de seleções muito usados contém índices, e
vou seguir o seu conselho para habilitar stats_block_level e consultar as
tabelas internas do banco de modo a visualizar algumas informações como
recomenda.
- Pelo que entendi o effective_cache_size é extramente útil para a gestão da
gravação e utilização de cachê visando desafogar o banco em leituras
constantes ao disco pois informações constantemente usadas ficarão em cachê,
vou aumentar um pouco mais esse parâmetro para pelo menos 4GB.
- Algo que não tenho feito é consultas as tabelas do banco e passarei a
fazer isso com freqüência.
Uma curiosidade, executei a view pg_stat_user_indexes e consta as colunas
idx_scan, idx_tup_read, idx_tup_fetch, a exemplo da tabela de produto ele
traz as informações abaixo, o campo que se refere e a chave primária e o
primeira estatística 370911787 referente a coluna idx_scan, isso que dizer
que mesmo sendo chave primária está sendo realizado uma pesquisa seqüencial?
"produto";"produto_pkey";370911787;387804600;353876496
Obrigado!
De: JotaComm [mailto:jota.c...@gmail.com]
Enviada em: sábado, 15 de agosto de 2009 12:18
Para: gutembergsco...@hotmail.com; Comunidade PostgreSQL Brasileira
Assunto: Re: [pgbr-geral] Postgresql 8.2.4 melhorá configuração - Lentidão
exporádicas
Olá, Gutemberg
2009/8/13 Gutemberg Sarlo - Hotmail
Pessoal, bom dia!
Estou com alguns problemas e dificuldade em identificar causas momentanias
de lentidão do banco, penso que talvez seja alguma coisa ligada as
configurações do banco e semafaros do Linux, gostaria da experiência de
vocês para orientação para tentar chegar numa configuração mais equalizada a
demanda e equipamento.
Você está monitorando o banco e o SO utilizando ferramentas como o sar,
iostat, vmstat e top. Através destas ferramentas é possível analisar como
está a memória, se ocorre um uso excessivo de memória virtual, como está a
cpu e o acesso ao disco.
Ao mesmo tempo que você monitora isso você está fazendo uso das views
pg_stat_activity para ver que operações estão sendo executados no momento
que você identifica que o sistema está apresentendo sinais de lentidão? Você
também pode usar a view pg_locks para observar quais os locks existentes em
seu banco.
Demanda pesada de consultas e transações de manutenção, aplicação web (30%)
e client Server (70%). O Vacuum é executado toda madrugada automaticamente
via script: su root -c "vacuumdb -U $vU -h $vH -z -f -v -d $vB" >>
/home/postgresql/logs/vacuumdb2.txt
Você comentou aqui do Vacuum. O Vacuum full você executa com uma certa
periodicidade? Se você tiver uma boa configuraçãode max_fsm_pages o vacuum
tem um periodicidade de execução menor. Você tem o autovacuum habilitado?
Dell PowerEdge 1800 Xeon 8GB - HD scsi (dedicado)
OpenSuse 10.3
Postgresql 8.2.4
==
Sysctl.conf
==
kernel.shmall = 2147483648
kernel.shmmax = 2147483648
kernel.shmmni = 309329920
kernel.sem = 250 32000 100 128
#kernel.disable_cap_mlock = 1
fs.file-max = 65536
#net.ipv4.ip_local_port_range = 1024 65000
#net.core.rmem_default = 16777216 #1048576
#net.core.rmem_max = 16777216 #1048576
#net.core.wmem_default = 16777216 #262144
net.core.wmem_max = 16777216 #262144
vm.overcommit_memory = 2
vm.overcommit_ratio = 70
==
Postgresql.conf
==
max_connections = 220 # (change requires restart)
shared_buffers = 1024MB # min 128kB or max_connections*16kB
max_prepared_transactions = 3 # can be 0 or more
work_mem = 512
