A maquina é virtualizada ? 200 GB de partiação esta em RAID ? Se esta qual ? Tipo de disco da sua maquina ?
Se esta homologado para 8.2 serial ideal migrar. Poste as mudanças que vc fez no seu postgresql.conf, limits.conf e sysctl.conf. So uma duvida isso é o ERP da TOTVS ? 2010/10/22 sebastiao fidencio <sfiden...@gmail.com> > 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 > <sfiden...@gmail.com>escreveu: > > >> >> Em 11 de outubro de 2010 13:00, < >> pgbr-geral-requ...@listas.postgresql.org.br> escreveu: >> >>> Send pgbr-geral mailing list submissions to >>> pgbr-geral@listas.postgresql.org.br >>> >>> 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 >>> pgbr-geral-requ...@listas.postgresql.org.br >>> >>> You can reach the person managing the list at >>> pgbr-geral-ow...@listas.postgresql.org.br >>> >>> 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é <asmoi...@gmail.com> >>> Subject: Re: [pgbr-geral] PROBLEMAS DE PERFORMANCE COM SGBD >>> To: Comunidade PostgreSQL Brasileira >>> <pgbr-geral@listas.postgresql.org.br> >>> Message-ID: >>> >>> <aanlktimmdpw+gy710hb3own_vzk_lp8j6ucs4z8yr...@mail.gmail.com<aanlktimmdpw%2bgy710hb3own_vzk_lp8j6ucs4z8yr...@mail.gmail.com> >>> > >>> 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 >>> <sfiden...@gmail.com>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 >>> > pgbr-geral@listas.postgresql.org.br >>> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >>> > >>> > >>> >>> >>> -- >>> Moisés Caribé Ribeiro >>> AD, DBA >>> asmoi...@gmail.com >>> 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 <osvaldo.kuss...@gmail.com> >>> Subject: Re: [pgbr-geral] PROBLEMAS DE PERFORMANCE COM SGBD >>> To: Comunidade PostgreSQL Brasileira >>> <pgbr-geral@listas.postgresql.org.br> >>> Message-ID: >>> >>> <aanlktimmcnaeqra4y9cyxqoynentyntqmoq5bldk+...@mail.gmail.com<aanlktimmcnaeqra4y9cyxqoynentyntqmoq5bldk%2b...@mail.gmail.com> >>> > >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Em 10/10/10, sebastiao fidencio<sfiden...@gmail.com> 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 >>> pgbr-geral@listas.postgresql.org.br >>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >>> >>> >>> Fim da Digest pgbr-geral, volume 22, assunto 20 >>> *********************************************** >>> >> >> > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Charles Viana. Tel Celular: (19) 8118-6705 Email: charles.vi...@gmail.com charlesrvi...@hotmail.com cr_vi...@yahoo.com.br
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
