É bom você verificar, para especificação da sua máquina:
1 - A taxa de crescimento do seu banco
2 - É melhor você ter mais cores que cpus. Mas também dê prioridade ao
clock ao invés de cores.
3 - Cache secundário grande também ( L2 )
4 - No servidor para banco deve seguir essa premissa: NO-BREAK < CPU < RAM
< DISCO

Quanto a atual lentidão do seu processo. Como é feita a transação ele
avalia os dados e envia pra sua aplicação processar mais algo, ou é tudo
feito no banco?
Já verificou estatísticas? A possibilidade de criação de índices? Ou até
mesmo índices clusterizados? ( não sei se é esse o termo - mas sei que
alguém vai me corrigir )


Bruno E. A. Silva.




2012/8/31 Jean Domingues <[email protected]>

> Valeu pessoal. Vou reavaliar essas questões. Creio que apresentando alguns
> planos de execução aqui na lista, vcs consigam me ajudar melhor.
>
> Valeu a todos.
>
> ----- Mensagem original -----
> > De: Flavio Henrique Araque Gurgel <[email protected]>
> > Para: [email protected]
> > Cc:
> > Enviadas: Sexta-feira, 31 de Agosto de 2012 17:01
> > Assunto: Re: [pgbr-geral] Fwd: Servidor de Banco de Dados
>
> >
> >
> > Em 31-08-2012 16:47, Guimarães Faria Corcete DUTRA, Leandro escreveu:
> >> Mandando à lista mais uma mensagem respondida fora dela…
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: Jean Domingues<[email protected]>
> >> Date: 2012/8/31
> >> Subject: Re: [pgbr-geral] Servidor de Banco de Dados
> >> To: "Guimarães Faria Corcete DUTRA, Leandro"<[email protected]>
> >>
> >>
> >>
> >> Tenho algumas rotinas pesadas, como fechar um romaneio de carga, que
> >> gera uma série de operações no banco de dados (estoque, contábil,
> >> financeiro, frota, etc). Um romaneio chega a ter 150 pedidos. E também
> >> tenho alguns relatórios complexos, que geram comparativos de vendas
> >> (de 6 meses, por exemplo), que tem que analisar uma quantidade
> >> razoável de registros (pra se ter uma ideia, só os itens das vendas já
> >> são 4 milhões de registros. Nessas rotinas venho tendo alguma
> >> dificuldade com desempenho no nosso servidor atual (um Core 2 quad com
> >> 4 GB de ram, com discos sata rodando em raid via software num linux
> >> debian). O cache_mem o deixei com 1500 MB. Ao monitor o servidor, o
> >> que percebo nessas rotinas é que o processador que está executando o
> >> processo fica em 100% por 2, 3 minutos, até que procedure (pl) devolva
> >> para a aplicação o resultado. É muito pro usuário, que tem pressa,
> >> principalmente quando ele quer apenas um relatório. Não sei se
> >>   estou subestimando o custo de execução, ou se tá normal, e é isso
> >> mesmo. Se houver mais alguma informação que seja importante pra poder
> >> me ajudar, me avisa.
> >>
> >
> > Jean, seu problema é complexo.
> > Você pode estar passando por:
> > - falta de capacidade de discos;
> > - falta de capacidade de processamento (CPU rodando PL);
> > - mau modelo de dados;
> > - mau uso de índices;
> > - outros problemas de hardware;
> > - pl mal escrita;
> > - etc, etc, etc.
> >
> > Talvez você precise mesmo de uma consultoria.
> > Ou faça perguntas mais específicas como:
> > "tenho uma tabela assim, assim e assado, com as colunas a, b e c, com
> > índices d, e e f, e uma PL bla ble bli e o tempo de execução é X
> > minutos. Dá pra otimizar?
> >
> > Do jeito que você tá perguntando, você está no problema "preciso
> > implementar algo correndo e não sei como, HELP". E isso, não é bom.
> >
> > []s
> >
> > Flavio Henrique A. Gurgel
> > Consultor e Instrutor 4Linux
> > Tel: +55-11-2125-4747
> > www.4linux.com.br
> > _______________________________________________
> > 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
>
>
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a