Mais de 8GB de RAM. Em vez de ter 2 servidores de 38 GB cada porque não 8 com 10GB de ram cada.
Antes de dizer que fica mais caro, não fica porque vc vai dimensionar o que precisa em cada maquina e não precisa pagar licença de VM. Fiz um orçamento com a dell, e os servidores virtualizados ficaram 20% mais caro. Preferi ficar com 8 maquinas de 32GB de RAM cada fico bem mais barato. andrecf wrote: > > Mais de 8Gb de RAM ou de disco? > Enviado através do meu BlackBerry® da Nextel > > -----Original Message----- > From: mateusgra <[email protected]> > Date: Wed, 5 May 2010 20:52:47 > To: <[email protected]> > Subject: Re: [pgbr-geral] PROBLEMAS DE PERFORMANCE > > > Maquinas virtuais tem degradaçao de performance com mais de 8GB. > > Vc pode confirmar isso com desenvolvedores do VmWare. > > VM no maximo com 8GB. > > > > Wolak Sistemas - Fabiano Machado Dias wrote: >> >> >> >> >> >> >> >> Boa tarde, >> >> Concordo com o Telles, rodar um banco de dados em um ambiente >> virtualizado não é uma boa idéia a não ser >> para fins de testes e olhe >> lá! >> >> Recomendo que você leia atentamente esse artigo [1] e configure >> melhor >> o seu postgresql.conf >> >> Neste outro link [2] você pode colocar o valor em GB que ele te >> dá o >> valor correto em bytes. >> >> Para o valor de shmmax você pode utilizar o valor calculado pelo >> site, >> e para o shmall pegue o mesmo valor (ou o que você quer >> especificar) >> e >> divida por 4096. >> >> Por exemplo: >> >> 6 GB = 6442450944 bytes >> 6442450944 / 4096 = 1572864 >> >> então >> >> >> kernel.shmmax = 6442450944 >> kernel.shmall = 1572864 >> >> shared_buffers deve ser igual ou menor que o valor de kernel.shmmax >> >> Não lembro se na 8.1 os valores já são em MB, mas de >> qualquer forma >> atualize a sua versão para a 8.4 >> >> Outras coisas que você pode alterar de cara são esses: >> >> work_mem - Cuidado com valores grandes, leia o artigo que você vai >> enteder >> max_stack_depth - utilize o "ulimit - s" e veja o valor retonado, >> faça >> testes mas nunca ultrapasse o valor >> vaccum_cost_delay - habilite porém o valor vai depender bastante >> da >> aplicação >> commit_delay - idem vaccum_cost_delay >> random_page_cost = 2 >> >> >> [1] - >> http://www.pgcon.org/2008/schedule/attachments/44_annotated_gucs_draft1.pdf >> [2] - http://www.easycalculation.com/bandwidth-calculator.php >> >> Abração, >> Fabiano Machado Dias >> >> >> sebastiao fidencio escreveu: >> >> Pessoal Bom dia, estou enviando esse email, porquanto estou com >> sério problemas de performance eu meu banco de dados. Segue meu >> cenário: >> >> servidores fisicos >> >> 2 servidores - DLG 160 com 38 GB de ram cada um, trabalhando >> em >> cluster.. (hd dos servidres e de 146GB) - cada máquina >> fisica >> tem 2 >> CPU quad..da intel >> storage com 8 discos de 400 gb, trabalhando em raid. >> >> >> Sistema operacional instalado nos Servidores fisicos: VMWARE >> ENTERPRISE ESX 4.0 >> >> >> Tenho umas 13 máquinas virtuais criadas entre windows e linux, >> Entretanto o servidor de banco de dados(maquina virtual) que de fato >> é >> o postgresql 8.1.3 com a seguinte configuração: >> >> 6 (cpu's) >> 16GB de ram >> 150GB na partição /dados onde está montado o >> cluster do banco de >> dados de produção. >> 10 GB onde está instalado a distribuição >> SUSE >> Linux Enterprise >> 11 64bits >> >> >> >> Problema: >> >> >> Acontece que, pessoal começa usar o sistema pela parte da >> manhã, >> e por volta de 10:00hrs da manhão o ERP começa a ficar >> bastante lento >> até chegar o ponto de travar, e percebo que quanto mais recurso >> disponibilizo para o servidor de sgbd, mais ele consome, poxa..na tem >> hardware que de conta disso. as consultas, a CPu e memoria vai para o >> ultimo estagio, e toda vez tem q ficar reiniciando o sgbd, já >> segui >> alguns conselhos para realizar tunnig no sgbd, mas não deu >> certo.., >> gostaria da opinião de vocês o que eu tenho que fazer para >> resolver >> esse problema. >> >> segue o link para vocês verem minhas conf's >> >> postgresql.conf >> http://200.175.138.130/postgresql.conf >> >> >> System V: (configuração defaul que veio, eu nem mexi em >> nada) >> >> kernel.shmmax = 18446744073709551615 >> kernel.shmall = 1152921504606846720 >> kernel.shmmni = 4096 >> >> >> >> >> >> estado da maquina agora sem problemas: (porem a qualquer momento >> ela pode apresenta problemas, principalmente quando os usuarios racam >> relatorios pesados).. >> >> a rede hoje tem cerca de 150 usuarios ativos no sistema. >> >> >> >> uso de memoria >> >> ============================================================================= >> >> dberp:/dados/pgsql # cat /proc/meminfo >> MemTotal: 16307396 kB >> MemFree: 1711440 kB >> Buffers: 23724 kB >> Cached: 4221676 kB >> SwapCached: 80676 kB >> Active: 4742244 kB >> Inactive: 1533132 kB >> SwapTotal: 1044216 kB >> SwapFree: 592144 kB >> Dirty: >> 1012 kB >> Writeback: 0 >> kB >> AnonPages: 1954908 kB >> Mapped: 1075736 kB >> Slab: >> 70516 kB >> SReclaimable: 34456 kB >> SUnreclaim: 36060 kB >> PageTables: 201260 kB >> NFS_Unstable: 0 kB >> Bounce: >> 0 kB >> WritebackTmp: 0 kB >> CommitLimit: 9197912 kB >> Committed_AS: 3784748 kB >> VmallocTotal: 34359738367 kB >> VmallocUsed: 306132 kB >> VmallocChunk: 34359431799 kB >> HugePages_Total: 0 >> HugePages_Free: 0 >> HugePages_Rsvd: 0 >> HugePages_Surp: 0 >> Hugepagesize: 2048 kB >> DirectMap4k: 10240 kB >> DirectMap2M: 16766976 kB >> dberp:/dados/pgsql # >> ========================================================================================================================== >> >> >> >> >> >> cpu >> =================================================================== >> top - 11:55:46 up 21:26, 2 users, load average: 0.71, 0.40, >> 2.34 >> Tasks: 197 total, 1 running, 194 sleeping, 2 >> stopped, 0 zombie >> Cpu0 : 2.2%us, 0.8%sy, 0.0%ni, 95.8%id, >> 1.3%wa, 0.0%hi, 0.0%si, >> 0.0%st >> Cpu1 : 14.8%us, 1.7%sy, 0.0%ni, 71.9%id, 11.3%wa, >> 0.0%hi, 0.1%si, >> 0.0%st >> Cpu2 : 1.5%us, 0.8%sy, 0.0%ni, 97.2%id, >> 0.6%wa, 0.0%hi, 0.0%si, >> 0.0%st >> Cpu3 : 0.3%us, 0.7%sy, 0.0%ni, 98.6%id, >> 0.3%wa, 0.0%hi, 0.0%si, >> 0.0%st >> Cpu4 : 0.2%us, 0.7%sy, 0.0%ni, 98.9%id, >> 0.2%wa, 0.0%hi, 0.0%si, >> 0.0%st >> Cpu5 : 0.2%us, 0.6%sy, 0.0%ni, 99.1%id, >> 0.1%wa, 0.0%hi, 0.0%si, >> 0.0%st >> Mem: 16307396k total, 14723100k used, 1584296k >> free, 24536k buffers >> Swap: 1044216k total, 451616k used, 592600k >> free, 4371700k cached >> PID USER PR NI >> VIRT RES SHR S %CPU %MEM TIME+ >> COMMAND >> 11807 postgres 20 0 1108m 303m 296m D >> 5 1.9 1:02.66 postmaster >> 1 root 20 >> 0 1064 76 32 S 0 >> 0.0 0:15.54 init >> 2 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.02 kthreadd >> 3 root RT >> -5 0 0 0 >> S 0 0.0 0:00.04 migration/0 >> 4 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.18 ksoftirqd/0 >> 5 root RT >> -5 0 0 0 >> S 0 0.0 0:00.02 migration/1 >> 6 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.06 ksoftirqd/1 >> 7 root RT >> -5 0 0 0 >> S 0 0.0 0:00.00 migration/2 >> 8 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.02 ksoftirqd/2 >> 9 root RT >> -5 0 0 0 >> S 0 0.0 0:00.00 migration/3 >> 10 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.00 ksoftirqd/3 >> 11 root RT >> -5 0 0 0 >> S 0 0.0 0:00.02 migration/4 >> 12 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.00 ksoftirqd/4 >> 13 root RT >> -5 0 0 0 >> S 0 0.0 0:00.00 migration/5 >> 14 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.00 ksoftirqd/5 >> 15 root 15 >> -5 0 0 0 >> S 0 0.0 0:01.58 events/0 >> 16 root 15 >> -5 0 0 0 >> S 0 0.0 0:01.62 events/1 >> 17 root 15 >> -5 0 0 0 >> S 0 0.0 0:01.52 events/2 >> 18 root 15 >> -5 0 0 0 >> S 0 0.0 0:02.16 events/3 >> 19 root 15 >> -5 0 0 0 >> S 0 0.0 0:02.06 events/4 >> 20 root 15 >> -5 0 0 0 >> S 0 0.0 0:02.74 events/5 >> 21 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.00 khelper >> 22 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.00 >> kintegrityd/0 >> 23 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.00 >> kintegrityd/1 >> 24 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.00 >> kintegrityd/2 >> 25 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.00 >> kintegrityd/3 >> 26 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.00 >> kintegrityd/4 >> 27 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.00 >> kintegrityd/5 >> 28 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.04 kblockd/0 >> 29 root 15 >> -5 0 0 0 >> S 0 0.0 0:04.58 kblockd/1 >> 30 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.06 kblockd/2 >> 31 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.02 kblockd/3 >> 32 root 15 >> -5 0 0 0 >> S 0 0.0 0:00.02 kblockd/4 >> ============================================================ >> >> >> >> >> >> Ficarei grato por isso! >> >> >> >>_______________________________________________ >> 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 >> >> > > -- > View this message in context: > http://old.nabble.com/PROBLEMAS-DE-PERFORMANCE-tp28462191p28469041.html > Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. > > _______________________________________________ > 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 > > -- View this message in context: http://old.nabble.com/PROBLEMAS-DE-PERFORMANCE-tp28462191p28473152.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
