Em 11 de outubro de 2010 13:00, <[email protected] > escreveu:
> Send pgbr-geral mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of pgbr-geral digest..." > > > Tópicos de Hoje: > > 1. Re: PROBLEMAS DE PERFORMANCE COM SGBD (Moisés Caribé) > 2. Re: PROBLEMAS DE PERFORMANCE COM SGBD (Osvaldo Kussama) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 10 Oct 2010 12:00:18 -0300 > From: Moisés Caribé <[email protected]> > Subject: Re: [pgbr-geral] PROBLEMAS DE PERFORMANCE COM SGBD > To: Comunidade PostgreSQL Brasileira > <[email protected]> > Message-ID: > > <[email protected]<aanlktimmdpw%[email protected]> > > > Content-Type: text/plain; charset="iso-8859-1" > R: acho que "evitar virtualização" não seria o caminho Moisés, visto que > hoje em dia vitualização está se tornando comum em diversos cenários, > portanto, sendo assim varias empresas já teriam tido problema com seus > servidores de SGBD, segundo pessoal especializado no VM4, é totalmente > transparente a VM em relação a maquina fisica, ou seja, o SO nem sabe que > está atuando em um ambiente virtualizado, e outra os perififericos como > disco no final das contas estão armazenados no storage, e isso é > transparente visto que as maquinas estao ligadas ao controlador do storage > via fibra óptica. (8GB/s) > > Sebastião; > > Evite virtualizações em ambientes de produção. O sistema fica mais lento > devido à escrita em arquivos (maq virtual) do disco; > > R: Avaliar o plano de execução se torna meio complicado visto que o codigo SQL não está no SGBD e sim na camada de negocio da aplicação. Isso no caso teria que ser a software house que fez o sistema, que teria que fazer. > Avalie o plano de execução das consultas para ver a necessidade de criação > de índices ou o excesso deles; > > Verifique as seguintes variáveis do postgresqk.conf: > > R: Essas duas estão habilitadas > max_connections = trabalhe com uma folga > shared_buffers = 20 a 25% da ram (para máquina dedicada utilize 25) > R: Essas não estão > effective_cache_size (25 a 50%) (para máquina dedicada utilize 50) > enable_bitmapscan = on > enable_hashagg = on > enable_hashjoin = on > enable_indexscan = on > enable_mergejoin = on > enable_nestloop = on > enable_seqscan = off > enable_sort = on > enable_tidscan = off > > R: está ativo.. > Ative as estatísticas e o autovacuum. > Sei que você já pode ter feito muitas dessas coisas, mas, infelizmente, > terás que fazer um pente-fino para descobrir o problema. Esse é o início. > Espero ter ajudado. > Moisés. > > Em 10 de outubro de 2010 11:43, sebastiao fidencio > <[email protected]>escreveu: > > > Pessoal, temos um sgbd postgres versao 8.3 rodando em um datacenter > > virutalizado, > > > > + Vmware 4 > > + Linux Suse 11 Enterprise > > + 16 GB d RAM + 250GB de espaço em disco > > + 100GB o tamanho atual do bd de produção > > + Cerca de 100 Conexões simultanea > > > > > > Problemas: > > > > 1. Objeto Sequência da NF/NFE eventualmente incrementa 2 valores, > > recentemente incrementou 11 valores o que pode ser isso? > > 2. Sistema do nada começa a ficar "lento" quando os usuarios tentam > emitir > > relatorio, até mesmo logar no sistema, onde são poucas a consultas ao > logar. > > 3. As vezes acontece do Servidor Travar que só um reset na VM resolve o > > problema não entendo o que está acontecendo, alguem pode ajudar? > > 4. O Servidor Fisico é da HP (38GB de RAM TOTAL.. e salvo erro 78GHZ de > > processamento com nucleos.) > > > > Já foi feito tunnig no mesmo, e não resolveu, quando era no DELL power > edge > > 1800, não tinhamos esse problema, era portanto uma maquina fisica > dedicada > > so pra SGBD agora depois que migrou estamos com esses problemas, já > > cogitaram em migrar prá oracle, mas acho que não é bem por ai, alguem tem > > alguma sugestão ou já teve algum problema parecido nesse cenário? > > > > > > > > > > _______________________________________________ > > pgbr-geral mailing list > > [email protected] > > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > > > > > > -- > Moisés Caribé Ribeiro > AD, DBA > [email protected] > 71-91350152 > > MCTS 70-431 > https://mcp.microsoft.com/authenticate/validatemcp.aspx > Transcript ID: 879519 > Access Code: 884D1F114FF24 > -------------- Próxima Parte ---------- > Um anexo em HTML foi limpo... > URL: > http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20101010/1cb749dd/attachment.html > > ------------------------------ > > Message: 2 > Date: Sun, 10 Oct 2010 18:04:08 -0300 > From: Osvaldo Kussama <[email protected]> > Subject: Re: [pgbr-geral] PROBLEMAS DE PERFORMANCE COM SGBD > To: Comunidade PostgreSQL Brasileira > <[email protected]> > Message-ID: > > <[email protected]<aanlktimmcnaeqra4y9cyxqoynentyntqmoq5bldk%[email protected]> > > > Content-Type: text/plain; charset=ISO-8859-1 > > Em 10/10/10, sebastiao fidencio<[email protected]> escreveu: > > Pessoal, temos um sgbd postgres versao 8.3 rodando em um datacenter > > virutalizado, > > > > + Vmware 4 > > + Linux Suse 11 Enterprise > > + 16 GB d RAM + 250GB de espaço em disco > > + 100GB o tamanho atual do bd de produção > > + Cerca de 100 Conexões simultanea > > > > > > Problemas: > > > > 1. Objeto Sequência da NF/NFE eventualmente incrementa 2 valores, > > recentemente incrementou 11 valores o que pode ser isso? > > Provavelmente a transação falhou. É feito o rollback dos registros > criados/atualizados na transação mas as sequência, por definição, não > são retornadas. > > http://www.postgresql.org/docs/current/interactive/functions-sequence.html > "Important: To avoid blocking concurrent transactions that obtain > numbers from the same sequence, a nextval operation is never rolled > back; that is, once a value has been fetched it is considered used, > even if the transaction that did the nextval later aborts. This means > that aborted transactions might leave unused "holes" in the sequence > of assigned values. setval operations are never rolled back, either." > > > > 2. Sistema do nada começa a ficar "lento" quando os usuarios tentam > emitir > > relatorio, até mesmo logar no sistema, onde são poucas a consultas ao > logar. > > 3. As vezes acontece do Servidor Travar que só um reset na VM resolve o > > problema não entendo o que está acontecendo, alguem pode ajudar? > > 4. O Servidor Fisico é da HP (38GB de RAM TOTAL.. e salvo erro 78GHZ de > > processamento com nucleos.) > > > > Já foi feito tunnig no mesmo, e não resolveu, quando era no DELL power > edge > > 1800, não tinhamos esse problema, era portanto uma maquina fisica > dedicada > > so pra SGBD agora depois que migrou estamos com esses problemas, já > > cogitaram em migrar prá oracle, mas acho que não é bem por ai, alguem tem > > alguma sugestão ou já teve algum problema parecido nesse cenário? > > > > Osvaldo > > > ------------------------------ > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > > Fim da Digest pgbr-geral, volume 22, assunto 20 > *********************************************** >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
