Euler, meu problema foi solucionado através de alterações na aplicação.
Aumentei o desempenho do tratamento dos SQLs com alteração de lógica,
estruturas de dados e redução da frequência com que alguns dados eram
atualizados no BD.
O estranho é que antes de alterar o tablespace de disco, esta perda de
desempenho não existia.
Respondendo o email anterior:
2009/5/27 Euler Taveira de Oliveira <[email protected]>
> Leandro Cavalari Soares escreveu:
> > (Ambiente: Suse EL 10, PostgreSQL 8.3, 2 Opteron, 8GB de RAM e 2 discos
> > SCSI 15K de 146GB em RAID 1)
> >
> Qual a versão do kernel? 2.6.16? É muito antigo; recomendo atualizá-lo.
A versão do kernel é a 2.6.16 mesmo.
> > O problema é que ao avançar das horas, ao invés de ganhar desempenho por
> > ter dividido as bases em 2 discos, o fluxo de tratamento dos SQLs caiu
> > drasticamente. Minha aplicação chegou a acumular 500.000 SQLs. Não há
> > erro nos logs. Já reindexei as bases. O SGBD está executando o vacuum
> > normalmente. Não há conexão travada em pg_stat_activity. A máquina está
> > com baixo processamento e baixo uso de disco ... =/
> >
> Como você mediu que o desempenho caiu? O que quis dizer com 'acumular 500k
> sql'? Você disse que está executando o VACUUM normalmente? Mas e o ANALYZE?
> O
> autovacuum está ligado?
Minha aplicação é 90% insert / update e 10% select. Tenho uma estrutura
onde enfileiro essas instruções. O fluxo médio de execução é de 200 SQLs por
segundo. Com essa queda de desempenho, acumularam-se 500.000 instruções na
fila de execução.
Quanto ao autovacuum, ele está habilitado. E eu observei a execução de
VACUUM ANALYZE através da view pg_stat_activity.
>
> Além disso, você colocou os discos na mesma controladora já existente? Se
> sim,
> verificou a taxa de transferência que ela suporta? Se foi em outra
> controladora, você verificou se não há bugs no driver da controladora?
>
Os discos estão na mesma controladora. Não encontrei a taxa de
transferência dela nas especificações da Dell, mas o fluxo entrante de dados
no disco é pequeno (2000 Blk/s =1MB). Antes da alteração no tablespace,
minha aplicação tinha o mesmo fluxo de dados e não havia esse acúmulo.
>
>
> --
> Euler Taveira de Oliveira
> http://www.timbira.com/
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
--
Leandro Cavalari Soares
Analista de Sistemas / DBA
Veltrac - Tecnologia em Logística
(43) 2105-5614 / (43) 9922-8095 - Londrina / PR
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
