Leandro,

   Os 2 RAIDs que tem são via hard ou soft?
   Tinha algum parâmetro de kernel na memória e não em arquivo (ex: sysctl)?
   Realmente não vejo como iria "perder" desempenho.
   Você possui algum aplicativo de monitoramento do servidor (SAR[1])?

Abraços,
Aldrey Galindo

[1]- http://pagesperso-orange.fr/sebastien.godard/

2009/5/29 Leandro Cavalari Soares <[email protected]>

>      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
>
>
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a