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
