Pessoal, Negocio e seguinte, dando continuidade ao problema que estamos
tendo de performance, ou gargalos que ocorrem em determinados momento do
dia. não sei se tem haver, mas como disse, o banco de dados hoje da
corporação está com:
+81GB de tamanho
+ verifiquei e meu postgresql.conf está tunado já bastante tempo.
+ o SO é de 64 bits (Suse Linux)
+ O Modelo de dados não está normalizado (Não possui Primary Key e nem Fkey
somente indices)
+ É imprevisivel saber se as Query's estão otimizadas, porquanto as mesmas
estão encapsuladas na camada de negocio da aplicação, e não em
procedures/functions.
Configurações da máquina:
16GB de RAM
6CPU (Intel(R) Xeon(R) CPU E5530 @ 2.40GHz)
200GB na partição de dados
FileSystem: ext3
Versão homologado do postgresql para essa aplicação: 8.1x até 8.2x
versão atual: 8.1.17
==============================================================
top - 10:21:44 up 3 days, 23:58, 2 users, load average: 0.48, 0.41, 0.45
Tasks: 232 total, 1 running, 230 sleeping, 1 stopped, 0 zombie
Cpu(s): 3.0%us, 0.3%sy, 0.0%ni, 94.6%id, 2.0%wa, 0.0%hi, 0.0%si,
0.0%st
Mem: 22500396k total, 21845472k used, 654924k free, 41236k buffers
Swap: 1044216k total, 6464k used, 1037752k free, 5042380k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13039 postgres 20 0 2151m 421m 416m S 23 1.9 0:27.14 postmaster
1 root 20 0 1064 80 52 S 0 0.0 0:04.78 init
=================================================================
O Que os Srs. me diz desse cenário?
Em 20 de outubro de 2010 12:50, sebastiao fidencio
<[email protected]>escreveu:
>
>
> 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
