Re: [pgbr-geral] Melhorar performance
Sergio Santi escreveu: OK, lá vai. Postgres.conf Parâmetro Padrão ServLentoServRápido max_connections 10070 100 shared_buffers 32MB1000MB 32MB work_mem1MB 64MB 1MB maintenance_work_mem 16MB 256MB 16MB max_fsm_pages 204800 100204800 max_fsm_relations1000 2000 2000 checkpoint_segments 3 310 enable_seqscan on off off enable_tidscan on off off effective_cache_size 128MB 256MB 128MB Consulta usada tanto no ServLento quanto no ServRapido A causa da lentidão é que os planos estão pegando índices diferentes. O índice NotaFiscal_Impressora_Intervencao_Cupom_I escolhido para consulta lenta está com uma estimativa totalmente errada. Os índices NotaFiscal_Impressora_Intervencao_Cupom_I, NotaFiscal_CodigoOperacaoEstoque_I e NotaFiscal_DataEmissao_I estão com estimativas fora da realidade. Você fez um REINDEX neles? Você tentou aumentar o default_statistics_target das colunas que participam do índice para ver se as estimativas melhoram? Além disso, eu *não* aconselharia desabilitar _seqscan_ nem _tidscan_. Mas aconselharia aumentar o effective_cache_size e checkpoint_segments. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar performance
Euler Taveira de Oliveira escreveu: Sergio Santi escreveu: OK, lá vai. Postgres.conf Parâmetro Padrão ServLentoServRápido max_connections 10070 100 shared_buffers 32MB1000MB 32MB work_mem1MB 64MB 1MB maintenance_work_mem 16MB 256MB 16MB max_fsm_pages 204800 100204800 max_fsm_relations1000 2000 2000 checkpoint_segments 3 310 enable_seqscan on off off enable_tidscan on off off effective_cache_size 128MB 256MB 128MB Consulta usada tanto no ServLento quanto no ServRapido A causa da lentidão é que os planos estão pegando índices diferentes. O índice NotaFiscal_Impressora_Intervencao_Cupom_I escolhido para consulta lenta está com uma estimativa totalmente errada. Os índices NotaFiscal_Impressora_Intervencao_Cupom_I, NotaFiscal_CodigoOperacaoEstoque_I e NotaFiscal_DataEmissao_I estão com estimativas fora da realidade. Você fez um REINDEX neles? Você tentou aumentar o default_statistics_target das colunas que participam do índice para ver se as estimativas melhoram? Além disso, eu *não* aconselharia desabilitar _seqscan_ nem _tidscan_. Mas aconselharia aumentar o effective_cache_size e checkpoint_segments. Isso implica que nem sempre um servidor com hardware melhor e mais rápido e configurações maiores de PostgreSQL vai oferecer uma resposta mais rápida? Isto é, sob condições mais apertadas o PostgreSQL faz estimativas melhores e mais eficientes? -- Benedito A. Cruz Centro de Referência em Informação Ambiental - CRIA email b...@cria.org.br fone 55 19 3288 0466 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar performance
Isso implica que nem sempre um servidor com hardware melhor e mais rápido e configurações maiores de PostgreSQL vai oferecer uma resposta mais rápida? Isto é, sob condições mais apertadas o PostgreSQL faz estimativas melhores e mais eficientes? Isto significa que tuning é algo mais complexo do que se imagina e que fazer inferências sem todas as informações necessárias faz com que nós incorramos em erros graves. O Euler pediu mais informações, no e-mail anterior. Sem elas, fica difícil saber realmente o que está ocorrendo. São muitas variáveis interagindo ao mesmo tempo para se afirmar qualquer coisa. []s -- Benedito A. Cruz Centro de Referência em Informação Ambiental - CRIA email b...@cria.org.br fone 55 19 3288 0466 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar performance
Pessoal: Eu imaginava ter enviado as informaes solicitadas. Inclusive estava estranhando a demora de uma resposta, mas queria ficar incomodando. Se houver mais alguma informao que eu possa fornecer no exitem em dizer? Abraos, Fbio Telles Rodriguez escreveu: Isso implica que nem sempre um servidor com hardware melhor e mais rpido e configuraes maiores de PostgreSQL vai oferecer uma resposta mais rpida? Isto , sob condies mais "apertadas" o PostgreSQL faz estimativas melhores e mais eficientes? Isto significa que tuning algo mais complexo do que se imagina e que fazer inferncias sem todas as informaes necessrias faz com que ns incorramos em erros graves. O Euler pediu mais informaes, no e-mail anterior. Sem elas, fica difcil saber realmente o que est ocorrendo. So muitas variveis interagindo ao mesmo tempo para se afirmar qualquer coisa. []s -- Benedito A. Cruz Centro de Referncia em Informao Ambiental - CRIA email b...@cria.org.br fone 55 19 3288 0466 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Sergio Medeiros Santi ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar performance
Sergio Santi escreveu: Eu imaginava ter enviado as informações solicitadas. Inclusive estava estranhando a demora de uma resposta, mas queria ficar incomodando. Se houver mais alguma informação que eu possa fornecer não exitem em dizer? As informações eu solicitei em [1]. Execute o que está lá e depois publique o que conseguiu. [1] http://listas.postgresql.org.br/pipermail/pgbr-geral/2009-July/016610.html -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar performance
Euler, Eu escrevi: No meu caso o que sempre fez e continua fazendo uma falta desgraçada no Postgres é um otimizador decente (...) Bem que se podia aproveitar a idéia aplicada no Oracle ou no SQL Server e ter um cache de planos (...) Isso já existe: chama-se comandos preparados (aka _prepared statements_). Isso ??! http://jdbc.postgresql.org/documentation/83/server-prepare.html Não, não estou falando de algo tão simplório. Prepared statements têm diversas desvantagens em relação ao que o Oracle e o SQL Server fazem: * Prepared statements funcionam dentro da mesma conexão. Logo, consultas idênticas feitas por instâncias diferentes da mesma aplicação ou aplicações diferentes que façam as mesmas consultas continuarão tendo um custo alto recompilando dúzias de vezes os mesmos comandos. Isso, é claro, assumindo que eu me dê ao trabalho de mexer na minha aplicação para fazer todas as consultas através da mesma conexão. O ganho disso seria bastante questionável considerando que isso implica em serializar operações que podem correr em paralelo. * Da documentação: (...) Server side prepared statements are planned only once by the server. This avoids the cost of replanning the query every time, but also means that the planner cannot take advantage of the particular parameter values used in a particular execution of the query. (...) Logo, Prepared statements usam o mesmo plano independente dos valores, o que resulta em desastre. Isso é exatamente o *oposto* do que se espera de um otimizador decente. O otimizador deveria ter uma lista de planos para a mesma consulta e usar o mais adequado para cada uma. É claro que você precisa manter a conexão mas nada que um aglomerador de conexões (aka _pool_) não resolva. Como expus acima, fazer isso, ainda por cima em larga escala, resulta em desastre. Como você mesmo disse, o tempo é relativamente pequeno em aplicações Web e OLTP; em OLAP, algumas consultas com dezenas de junções esse tempo é significativo (aumenta 2^n mas é para isso que temos o GEQO) mas mesmo assim bem inferior ao de execução da consulta. Dezenas de junções não são exclusividade de aplicações OLAP, muito pelo contrário. O fato de uma consulta cheia de junções exigir um enorme tempo de planejamento de forma alguma implica em não valer a pena gastá-lo fazendo isso. É exatamente nessas tabelas potencialmente grandes e cheias de índices que uma escolha errada do otimizador resulta em planos catastróficos. É fácil falar do otimizador mas é difícil mexer nele. ;) Ora, ora, pelo menos nisso concordamos integralmente. A pergunta do tópico foi quanto ao que se poderia melhorar em desempenho, só estou expondo a lista para resolver os *meus* problemas. Afinal, custa-me acreditar que sou o único interessado em desempenho por aqui. Já tivemos essa discussão a um tempo atrás (...). Se eu me lembro bem, nenhuma das consultas apresentadas por você produzia um plano que não era ideal. Depende do que chamarmos de ideal. Para mim o ideal é medir as consultas em milissegundos para poder comparar com Oracle e SQL Server, e não em minutos. OK, de fato não tenho no momento exemplos usando a última versão do Postgres, quando tiver passo para a lista. Fazer testes comparativos de desempenho é algo que consome tempo que é dificílimo de conseguir considerando nossas experiências anteriores. Atenciosamente, Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar performance
Pessoal, Eu imagino ter participado da discusso ocorrida "h um tempo atrs" e claro que como j fui e muitas vezes continuo sendo vtima de planos mal escolhidos tenho um detalhe a acrescentar: Um servidor Dell PowerEdge 1800, dual zeon, 4GB, 4 hds SAS em raid 10 executou uma consulta que mostra o valor faturado em 40 impressoras fiscais em um nico dia classificado por impressora fiscal em uns 4 a 5 minutos. Um desktop core2duo, 4GB, 1 hd sata2 executou a mesma consulta sobre um backup do primeiro equipamento restaurado no segundo em 1segundo. Os planos de execuo so muitssimo diferentes e comparando o postgres.conf de cada um, respectivamente, temos as seguintes diferenas principais: max_connections = 70 100 shared_buffers = 1000MB 32MB work_mem = 64MB 1MB maintenance_work_mem = 256MB 16MB max_fsm_pages = 100 324000 checkpoint_segments = 310 effective_cache_size = 256MB 128M Nas prximas semanas pretendo realizar novos testes, mas no a primeira vez que vejo isto e por isto se v tanto ajuste pelo mtodo de tentativa e erro. Abraos, Mozart Hasse escreveu: Euler, Eu escrevi: No meu caso o que sempre fez e continua fazendo uma falta desgraada no Postgres um otimizador decente (...) Bem que se podia aproveitar a idia aplicada no Oracle ou no SQL Server e ter um cache de planos (...) Isso j existe: chama-se comandos preparados (aka _prepared statements_). Isso ??! http://jdbc.postgresql.org/documentation/83/server-prepare.html No, no estou falando de algo to simplrio. Prepared statements tm diversas desvantagens em relao ao que o Oracle e o SQL Server fazem: * Prepared statements funcionam dentro da mesma conexo. Logo, consultas idnticas feitas por instncias diferentes da mesma aplicao ou aplicaes diferentes que faam as mesmas consultas continuaro tendo um custo alto recompilando dzias de vezes os mesmos comandos. Isso, claro, assumindo que eu me d ao trabalho de mexer na minha aplicao para fazer todas as consultas atravs da mesma conexo. O ganho disso seria bastante questionvel considerando que isso implica em serializar operaes que podem correr em paralelo. * Da documentao: "(...) Server side prepared statements are planned only once by the server. This avoids the cost of replanning the query every time, but also means that the planner cannot take advantage of the particular parameter values used in a particular execution of the query. (...)" Logo, Prepared statements usam o mesmo plano independente dos valores, o que resulta em desastre. Isso exatamente o *oposto* do que se espera de um otimizador decente. O otimizador deveria ter uma lista de planos para a mesma consulta e usar o mais adequado para cada uma. claro que voc precisa manter a conexo mas nada que um aglomerador de conexes (aka _pool_) no resolva. Como expus acima, fazer isso, ainda por cima em larga escala, resulta em desastre. Como voc mesmo disse, o tempo relativamente pequeno em aplicaes Web e OLTP; em OLAP, algumas consultas com dezenas de junes esse tempo significativo (aumenta 2^n mas para isso que temos o GEQO) mas mesmo assim bem inferior ao de execuo da consulta. Dezenas de junes no so exclusividade de aplicaes OLAP, muito pelo contrrio. O fato de uma consulta cheia de junes exigir um enorme tempo de planejamento de forma alguma implica em no valer a pena gast-lo fazendo isso. exatamente nessas tabelas potencialmente grandes e cheias de ndices que uma escolha errada do otimizador resulta em planos catastrficos. fcil falar do otimizador mas difcil mexer nele. ;) Ora, ora, pelo menos nisso concordamos integralmente. A pergunta do tpico foi quanto ao que se poderia melhorar em desempenho, s estou expondo a lista para resolver os *meus* problemas. Afinal, custa-me acreditar que sou o nico interessado em desempenho por aqui. J tivemos essa discusso a um tempo atrs (...). Se eu me lembro bem, nenhuma das consultas apresentadas por voc produzia um plano que no era ideal. Depende do que chamarmos de "ideal". Para mim o ideal medir as consultas em milissegundos para poder comparar com Oracle e SQL Server, e no em minutos. OK, de fato no tenho no momento exemplos usando a ltima verso do Postgres, quando tiver passo para a lista. Fazer testes comparativos de desempenho algo que consome tempo que dificlimo de conseguir considerando nossas experincias anteriores. Atenciosamente, Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Sergio Medeiros Santi ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br
Re: [pgbr-geral] Melhorar performance
OK, l vai.
Postgres.conf
Parmetro
Padro ServLento ServRpido
max_connections 100 70100
shared_buffers 32MB 1000MB 32MB
work_mem 1MB 64MB 1MB
maintenance_work_mem 16MB 256MB 16MB
max_fsm_pages 204800 100 204800
max_fsm_relations 1000 2000 2000
checkpoint_segments 3 3 10
enable_seqscan on off off
enable_tidscan on off off
effective_cache_size 128MB 256MB 128MB
Consulta usada tanto no ServLento quanto no ServRapido
EXPLAIN ANALYSE
SELECT
Count("NotaFiscal"."CodigoInternoNota")::Integer As Qtde,
Sum("NotaFiscal"."TotalLiquidoNota")::Numeric(15,4) As
SubTotal,
Sum("NotaFiscal"."TotalNota")::Numeric(15,4) As
TotalNota,
"NotaFiscal"."CodigoEmpresaNota"::Integer As
CodigoEmpresaNota,
--Nmero da impressora j gravada na tabela de nota fiscal
"NotaFiscal"."NumeroImpressoraNota"::Varchar(10) As
NumeroImpressora,
--Retorna o numero de serie da empressora, a partir da
impressora gravada na tabela de nota fiscal
/*(Select "NumeroSerieECF"
From "ECF"
Where "CodigoEmpresaECF" = "NotaFiscal"."CodigoEmpresaNota"
AND "CodigoECF" = "NotaFiscal"."NumeroImpressoraNota") As
"NumeroSerieImpressora",*/
(Sum("NotaFiscal"."TotalLiquidoNota")::Numeric(15,4) /
Count("NotaFiscal"."CodigoInternoNota")::Integer)::Numeric(15,4) As
XMediaSubTotal,
(Sum("NotaFiscal"."TotalNota")::Numeric(15,4) /
Count("NotaFiscal"."CodigoInternoNota")::Integer)::Numeric(15,4)
As XMediaTotal
FROM "NotaFiscal" LEFT JOIN "Operacao" ON
"NotaFiscal"."CodigoOperacaoEstoqueNota" =
"Operacao"."CodigoInternoOperacoes"
WHERE "Operacao"."TipoOperacoes" = 'V'
AND "NotaFiscal"."ModuloOrigemNota" = 'TS-Fature'
AND "NotaFiscal"."NumeroImpressoraNota" between '0001' and ''
AND "NotaFiscal"."DataEmissaoNota" between '2009-05-01' and
'2009-05-30'
AND "NotaFiscal"."SituacaoNota" is null
GROUP BY CodigoEmpresaNota,NumeroImpressora
ORDER BY NumeroImpressora,CodigoEmpresaNota
--
Resultado do explain analyse no ServLento
"GroupAggregate (cost=2696.13..2696.22 rows=1 width=54) (actual
time=638899.183..639115.314 rows=35 loops=1)"
" - Sort (cost=2696.13..2696.13 rows=1 width=54) (actual
time=638896.568..638945.504 rows=97965 loops=1)"
" Sort Key: "NotaFiscal"."NumeroImpressoraNota",
"NotaFiscal"."CodigoEmpresaNota""
" - Nested Loop (cost=2345.56..2696.12 rows=1 width=54)
(actual time=559508.579..638638.195 rows=97965 loops=1)"
" - Index Scan using "Operacao_CodigoInterno_PK" on
"Operacao" (cost=0.00..12.39 rows=1 width=4) (actual time=5.206..5.218
rows=1 loops=1)"
" Filter: (("TipoOperacoes")::text = 'V'::text)"
" - Bitmap Heap Scan on "NotaFiscal"
(cost=2345.56..2683.72 rows=1 width=58) (actual
time=559503.357..638516.721 rows=97965 loops=1)"
" Recheck Cond:
((("NotaFiscal"."NumeroImpressoraNota")::text = '0001'::text) AND
(("NotaFiscal"."NumeroImpressoraNota")::text = ''::text) AND
("NotaFiscal"."CodigoOperacaoEstoqueNota" =
"Operacao"."CodigoInternoOperacoes"))"
" Filter: ((("ModuloOrigemNota")::text =
'TS-Fature'::text) AND ("DataEmissaoNota" = '2009-05-01'::date) AND
("DataEmissaoNota" = '2009-05-30'::date) AND ("SituacaoNota" IS
NULL))"
" - BitmapAnd (cost=2345.56..2345.56 rows=85
width=0) (actual time=559003.403..559003.403 rows=0 loops=1)"
" - Bitmap Index Scan on
"NotaFiscal_Impressora_Intervencao_Cupom_I" (cost=0.00..1079.62
rows=16956 width=0) (actual time=205223.259..205223.259 rows=3374443
loops=1)"
" Index Cond:
((("NumeroImpressoraNota")::text = '0001'::text) AND
(("NumeroImpressoraNota")::text = ''::text))"
" - Bitmap Index Scan on
"NotaFiscal_CodigoOperacaoEstoque_I" (cost=0.00..1265.69 rows=16956
width=0) (actual time=353598.739..353598.739 rows=747641 loops=1)"
" Index Cond:
("NotaFiscal"."CodigoOperacaoEstoqueNota" =
"Operacao"."CodigoInternoOperacoes")"
"Total runtime: 639124.536 ms"
-
Resultado do explain analyse no ServRapido
"GroupAggregate (cost=971.00..971.08 rows=1 width=54) (actual
time=1153.322..1356.063 rows=35 loops=1)"
" - Sort (cost=971.00..971.00 rows=1 width=54) (actual
time=1151.227..1242.719 rows=89221 loops=1)"
" Sort Key: "NotaFiscal"."NumeroImpressoraNota",
"NotaFiscal"."CodigoEmpresaNota""
" - Nested Loop (cost=640.78..970.99 rows=1 width=54)
(actual time=453.271..841.699 rows=89221 loops=1)"
" - Index Scan using "Operacao_CodigoInterno_PK" on
"Operacao" (cost=0.00..12.36 rows=1 width=4) (actual time=0.063..0.070
rows=1 loops=1)"
" Filter: (("TipoOperacoes")::text = 'V'::text)"
" - Bitmap Heap Scan on "NotaFiscal"
(cost=640.78..958.62 rows=1 width=58) (actual time=453.201..793.978
rows=89221 loops=1)"
" Recheck Cond:
(("NotaFiscal"."CodigoOperacaoEstoqueNota" =
"Operacao"."CodigoInternoOperacoes") AND
("NotaFiscal"."DataEmissaoNota" = '2009-05-01'::date) AND
("NotaFiscal"."DataEmissaoNota" = '2009-05-30'::date))"
" Filter: ((("ModuloOrigemNota")::text =
'TS-Fature'::text) AND (("NumeroImpressoraNota")::text =
'0001'::text) AND (("NumeroImpressoraNota")::text = ''::text)
AND ("SituacaoNota" IS NULL))"
" -
[pgbr-geral] Melhorar performance
Pessoal, Vou começar a fazer um estudo sobre como poderia melhorar a performance do Postgresql. Minhas idéias iniciais: Idéia 1: A base fica em um storage, com um sistema de arquivo compartilhado (GFS) e duas ou mais máquinas grava e consulta na mesma base. Idéia 2: Um servidor faz o processo de gravação (insert / update) e replica para outro servidor, onde todas as consultas seria feitas só neste segundo servidor. Alguém já fez algum estudo deste tipo? tem alguma outra ideia ? Obrigado, Marcelo Gomes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar performance
Bom dia a todos, Esta é minha primeira participação na lista mas venho acompanhando de perto os assuntos aqui tratados a pelo menos um ano. Gostaria de parabenizar a todos pelo interesse e esforço em ajudar aqueles que encontram dificuldades neste formidável banco de dados. Só para por lenha na fogueira, a sua idéia 2, não iria gerar o processo de gravação (insert/update) durante a replicação? Ou seja qual ganho com a replicação? []'s Renato 2009/7/13 Marcelo Gomes marcelogome...@gmail.com Pessoal, Vou começar a fazer um estudo sobre como poderia melhorar a performance do Postgresql. Minhas idéias iniciais: Idéia 1: A base fica em um storage, com um sistema de arquivo compartilhado (GFS) e duas ou mais máquinas grava e consulta na mesma base. Idéia 2: Um servidor faz o processo de gravação (insert / update) e replica para outro servidor, onde todas as consultas seria feitas só neste segundo servidor. Alguém já fez algum estudo deste tipo? tem alguma outra ideia ? Obrigado, Marcelo Gomes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar performance
2009/7/13 Marcelo Gomes marcelogome...@gmail.com: Pessoal, Vou começar a fazer um estudo sobre como poderia melhorar a performance do Postgresql. Minhas idéias iniciais: Idéia 1: A base fica em um storage, com um sistema de arquivo compartilhado (GFS) e duas ou mais máquinas grava e consulta na mesma base. Não funciona. Para isso, você teria que ter algo como um Oracle RAC para resolver os problemas em relação ao que está no buffer de cada uma das máquinas. Não funciona e a tentativa de tentar funcionar é desastrosa. O que existe é um fail over onde apenas em um dos nós a base está ativa e se o servidor apresentar problemas o outro nó sobe o PostgreSQL lá e continua trabalhando. Idéia 2: Um servidor faz o processo de gravação (insert / update) e replica para outro servidor, onde todas as consultas seria feitas só neste segundo servidor. Vai gerar over head para gerar a replicação. O Standby é uma forma de replicação sem over head, mas no momento só temos o Warm Standby. Quando tivermos o HOT STANDBY isto será viável. A equipe do PostgreSQL tem se empenhado muito em tornar isto uma realidade, talvez na versão 8.5. Alguém já fez algum estudo deste tipo? tem alguma outra ideia ? Primeiro descreva o tipo de carga da sua aplicação. Descubra quais são os picos, defina os gargalos. Onde está pegando? Disco, memória, processamento? []s Fábio Telles Obrigado, Marcelo Gomes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar performance
Na verdade o que pega aqui é memória...se colocar mais memória vai ficar bom (isso já esta sendo providenciado) mas como tenho máquinas e um storage que poderia usar para testes, e estou com tempo disponível, estava querendo ver como poderia por mais de uma máquina para trabalhar e ter alguma melhora. Já que as minhas duas idéias não iria funcionar... alguém tem alguma outra idéia ??? quero aproveitar esta situação para explorar o postgres e gerar alguns doc. :D Obrigado, Marcelo Gomes 2009/7/13 Fábio Telles Rodriguez fabio.tel...@gmail.com 2009/7/13 Marcelo Gomes marcelogome...@gmail.com: Pessoal, Vou começar a fazer um estudo sobre como poderia melhorar a performance do Postgresql. Minhas idéias iniciais: Idéia 1: A base fica em um storage, com um sistema de arquivo compartilhado (GFS) e duas ou mais máquinas grava e consulta na mesma base. Não funciona. Para isso, você teria que ter algo como um Oracle RAC para resolver os problemas em relação ao que está no buffer de cada uma das máquinas. Não funciona e a tentativa de tentar funcionar é desastrosa. O que existe é um fail over onde apenas em um dos nós a base está ativa e se o servidor apresentar problemas o outro nó sobe o PostgreSQL lá e continua trabalhando. Idéia 2: Um servidor faz o processo de gravação (insert / update) e replica para outro servidor, onde todas as consultas seria feitas só neste segundo servidor. Vai gerar over head para gerar a replicação. O Standby é uma forma de replicação sem over head, mas no momento só temos o Warm Standby. Quando tivermos o HOT STANDBY isto será viável. A equipe do PostgreSQL tem se empenhado muito em tornar isto uma realidade, talvez na versão 8.5. Alguém já fez algum estudo deste tipo? tem alguma outra ideia ? Primeiro descreva o tipo de carga da sua aplicação. Descubra quais são os picos, defina os gargalos. Onde está pegando? Disco, memória, processamento? []s Fábio Telles Obrigado, Marcelo Gomes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail http://www.midstorm.org/%7Etelles/%0Ae-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar performance
Marcelo, Já que as minhas duas idéias não iria funcionar... alguém tem alguma outra idéia ??? quero aproveitar esta situação para explorar o postgres e gerar alguns doc. :D No meu caso o que sempre fez e continua fazendo uma falta desgraçada no Postgres é um otimizador decente. Bem que se podia aproveitar a idéia aplicada no Oracle ou no SQL Server e ter um cache de planos, reduzindo o número de compilações. Esse tempo hoje é relativamente pequeno (e insuficiente) no Postgres, exatamente porque ele precisa fazer isso a cada consulta. Se puder gastar mais tempo e aproveitar esse processamento (como o Oracle e o SQL Server fazem faz tempo), talvez ele se torne viável para mais aplicações. Outra coisa que ajudaria bastante seria a coleta de estatísticas mais detalhadas para uso do otimizador, como dados sobre correlação entre valores de campos dentro da mesma tabela (como o Oracle e o SQL Server fazem faz tempo). Isso obviamente consome um tempo, porém nem se compara com o desperdício que o Postgres faz com as estimativas furadas dele. Atenciosamente, Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar performance
Mozart Hasse escreveu: [é meio off-topic ao assunto inicial mas...] No meu caso o que sempre fez e continua fazendo uma falta desgraçada no Postgres é um otimizador decente. Bem que se podia aproveitar a idéia aplicada no Oracle ou no SQL Server e ter um cache de planos, reduzindo o número de compilações. Esse tempo hoje é relativamente pequeno (e insuficiente) no Postgres, exatamente porque ele precisa fazer isso a cada consulta. Se puder gastar mais tempo e aproveitar esse processamento (como o Oracle e o SQL Server fazem faz tempo), talvez ele se torne viável para mais aplicações. Isso já existe: chama-se comandos preparados (aka _prepared statements_). É claro que você precisa manter a conexão mas nada que um aglomerador de conexões (aka _pool_) não resolva. Como você mesmo disse, o tempo é relativamente pequeno em aplicações Web e OLTP; em OLAP, algumas consultas com dezenas de junções esse tempo é significativo (aumenta 2^n mas é para isso que temos o GEQO) mas mesmo assim bem inferior ao de execução da consulta. Outra coisa que ajudaria bastante seria a coleta de estatísticas mais detalhadas para uso do otimizador, como dados sobre correlação entre valores de campos dentro da mesma tabela (como o Oracle e o SQL Server fazem faz tempo). Isso obviamente consome um tempo, porém nem se compara com o desperdício que o Postgres faz com as estimativas furadas dele. É fácil falar do otimizador mas é difícil mexer nele. ;) Já tivemos essa discussão a um tempo atrás mas em minha opinião, eu não importo se o número de registros indicados na estimativa seja muito diferente dos números reais (afinal de contas, é uma *estimativa*!); o que me incomodaria é se por essa estimativa ser bem diferente do real, eu tenha um plano de execução que não é o ideal. Se eu me lembro bem, nenhuma das consultas apresentadas por você produzia um plano que não era ideal. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
