Em 5 de maio de 2010 12:35, Fábio Telles Rodriguez <[email protected]>escreveu:
> > > Em 5 de maio de 2010 12:01, sebastiao fidencio <[email protected]>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: >> >> > > Vamos lá: > > 1) Eu não utilizaria um SGDB em produção num SO virtualizado. Não é uma boa > idéia por definição. Pode ser preconceito meu, os tempos podem estar > mudando, mas tem que saber muito bem o que está fazendo para entrar nessa. > R: Então, eu também pensei da mesma forma, até porque quando meu SGBD de > produção estava em um servidor fisico da DELL POWER EDGE 1800 com 8gb de > RAM, dua-processor de 32bits com emulação de 64bits, 4 discos agrupados em > RAID 10, eu não tinha problemas, visto que eu estava utilizando a versão > 8.1.3 (recomendada pelo ERP nosso). Portanto, quando adquirimos o > DataCenter da HP, para trabalharmos com virtualização, criamos um VM com a > configuração inicial de 8GB de RAM, e 150GB de espaço em disco, Detalhe: > Esses discos estão em "LUN/Storage Area" diferente, ou seja, não está > compartilhando recursos com outros SO's. > > 2) Os discos no seu SO estão sendo repartidos com mais alguém? Tem > certeza. Se você coloca fé no seu VM, tudo bem, mas tem que ter certeza de > que os discos do banco de dados não são compartilhados com mais ninguém. > Certeza absoluta. > R: Não, estão em Areas diferentes, ou seja, dedicado para a maquina do SGBd > . > > 3) O PostgreSQL 8.1.3 está meio velinho, não acha? Tá na hora de > atualizar. > > R: Desculpe, a versão usada é a 8.1.20, e com relação a atualização da > versão, eu também queria atualizar, no momemnto que fiz a migração, porém o > pessoal não recomendou usar a ultima versão ainda, e também percebi algumas > diferenças na ultima versão que me deixaram meio com "pé atrás", quand você > cria um DATABASE novo, por default ele seta o COLLATE..para PT-BR, então > fiquei com medo de atualizar para ultima versão, e ter problemas ao > restaurar a base de dados na nova/ultima versão do pgsql, o autovacum e > habilitado, eu não costumo usar AUTOVACCUM habilitado, antes eu usava > desabilitado, e quando ia fazer o backup usando pg_dump toda noite, antes eu > fazia a manutenção do banco, recriando os indices, e vaccumdb, com opção de > freeze e analyze em todos BD's inclusive no bd do ERP que atualmente está > com tamanho de 60GB. Eu até achei que essa opção de habilitar > autovacum..poderia cai performance do meu SGBD, aumentando processos.. > >> 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 >> >> >> > Caracoles? O que é isso no seu shmmax? Isso não pode ser bom, certo? Se > você tem 16GB, um número razoável seria algo como 16GB/3, ou ~ 5368709120 . > NUNCA passe de 2/3 da RAM aqui. Você estará correndo um risco que vai > garantir boas horas diversão quando tudo explodir. > R: OK, vou tentar configurar..então! > > As informações adicionais que você enviou não ajudam se não forem coletadas > num momento de lentidão. Tente o SAR ou outra ferramenta de monitoramento > como o Munin, Zabbix, etc. > > Atenciosamente, > Fábio Telles > -- > blog: http://www.midstorm.org/~telles/ > e-mail / jabber: [email protected] > > _______________________________________________ > 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
