[firebase-br] Socorro 100%

Suporte Orel suporte em orel.com.br
Ter Out 4 08:39:01 -03 2005


Dú,

Você é o cara!!! Valeu, estou estar fazendo tudo hoje e te passando os 
dados.

Obrigado

Eduardo de Carvalho


> Quanto menor o PageSize, mais rápida é a atualização de Dados e índices, 
> seja através de novos registros, alteração ou exclusão de dados, porém 
> pageSize exageradamente pequeno pode causar muita fragmentação (os dados 
> não cabem numa página e precisam ser migrados para mais uma ou mais 
> páginas) e muitas leituras nos índices para conseguir localizar algum 
> registro em particular.
>
> Quanto maior o PageSize, mais rápida a consulta / Recuperação de dados e 
> índices. Isto quer dizer que mais dados serão carregados com menos 
> leituras físicas ao Disco. Consulta aos índices tornam-se drasticamente 
> mais eficientes, pois menos ponteiros relativos (e ponteiro para ponteiro) 
> de índices serão utilizados, tornando-os mais simples, e diretos. PageSize 
> exageradamente grande pode também resultar em fragmentação - por motivos 
> diferentes - ou seja, grandes áreas (não contíguas) vazias em páginas que 
> dificilmente poderão ser reaproveitadas sem um backup e restore, além de 
> que, como as cadeias de índice numa página serão  maiores, eles ficarão 
> mais "lentos" para serem atualizados.
>
> Em condições normais é recomendado um banco com páginas de 4KB, mas quando 
> a performance começa a ficar muito degradada, convém analizar friamente as 
> estatísticas e forma de utilização do banco para otimizá-lo.
>
> Se o FB está ficando com 98% (constantemente, sem ter outro processo 
> consumindo CPU vez ou outra), então provavelmente é sobrecarga no banco 
> mesmo...  Acho que é hora de trocar o Servidor por outro mais rápido.... 
> como te disse, não é o tamanho da base ou quantidade de registros o 
> problema, e sim a quantidade de usuários concorrentes. Já pensou num 
> servidor RISC de 64 Bits rodando Linux e FB 1.5 ???? de R$ 15 a 20 Mil já 
> dá para tirar uma idéia dessas do papel... Não é tão mais caro que um 
> servidor Intel top com Windows 2000 Server para 80 máquinas. Mas vamos 
> esperar pelo Gstat em horário de pico.
>
> Ahhh, tem mais um detalhe de última hora... como está a tua rede ??? A 
> Placa de rede do servidor é On-Board ??? Se for, experimente colocar uma 
> placa da Intel ou 3Com, vai perceber que elas consomem muito menos CPU que 
> as on-board, que nem computam seu custo de processamento no painel de 
> controle. Outra coisa, você utiliza HUB, Hub inteligente ou switch ??? 
> Saiba que HUBs acabam com o desempenho da Rede, e também do servidor da 
> rede por culpa das retransmissões geradas pelo excesso de colisões de 
> pacotes numa rede com muitas máquinas.
>
> Quanto ao norton, esta diferença será perceptível apenas nos "picos" de 
> consumo, ou seja, quando tem CPU sobrando não há como perceber a 
> diferença... é como você dirigir um carro mil na cidade com o ar 
> condicionado ligado e depois querer ultrapassar uma carreta numa subida 
> forte.... Se desligar o ar na cidade, talvez nem sinta diferença, mas na 
> estrada...
>
> =========================
> Eduardo Jedliczka
> (Membro do TeamFB)
> Apucarana - Pr
> =========================
>
> ----- Original Message ----- 
> From: "Suporte Orel" <suporte em orel.com.br>
> To: "FireBase" <lista em firebase.com.br>
> Cc: "Eduardo Jedliczka (TeamFB)" <jedyfb em gmail.com>
> Sent: Monday, October 03, 2005 11:44 PM
> Subject: [firebase-br] Socorro 100%
>
>
>
>
>
>
>> Vi seu GSTAT completo...
>>
>> Reparei que a parte crítica do seu sistema é a tabela FU_EXPAC. e 
>> provavemente seus relacionamentos.
>>
> RC : O FU_EXPAC é o "coração" do sistema
>
>> Além da PK, reparei que há outros 6 Índices... eles são FKs, são índices 
>> Únicos, ou índices quaisquer, só para "tentar" melhorar o desempenho.
>>
>
> RC: Algumas FK, e outro para melhorar a performance, que melhorou.
>
>> Depois de ver alguns de suas respostas, eu tenderia a responder que, para 
>> você, é melhor utilizar um PageSize grande do que um médio ou pequeno. 
>> Experimente mudar o PageSize para 8KB ou 16KB, e veja se a performance 
>> melhora.
>
> RC: Quais são os efeitos colaterais de um PageSize de 16 ?
>
>>
>> Mas deixe-me fazer outra pergunta. esses 20 Mil novos registros por dia, 
>> são gravados em "lote", ou seja, numa pancada, ou picado, um por um 
>> durante o dia ??? Você saberia dizer, qual horário (seria às 11h00 ou às 
>> 16h00) que mais se cadastra registros ???
>
> RC: Entram em lote de 400, 300 após as 14:00h, as 16:00h já estão no fim.
>
>>
>> Agora, respondendo sua outra pergunta, é perfeitamente normal que um 
>> terminal realize mais de uma conexão com o banco, isto depende de como 
>> você desenvolveu o seu sistema, e como não tenho conhecimentos de 
>> DBExpress, seria uma boa idéia, conversar com o PHA ou outro entendido 
>> desta metodologia de acesso, para evitar problemas de Lock, e/ou 
>> transações longas, como o recordista disparado de problema de 
>> performance, ou de "registros aparentemente desaparecidos" são "modelo 
>> transacional ineficiente ou inexistente", o Cantu pediu o GStat, mas por 
>> favor, esta estatística deve ser extraída com o banco em pleno 
>> funcionamento, e geralmente, quando o sistema está lento...
>
> RC: Amanha eu estou enviando o Gstat com o banco "fervendo"
>
>>
>> Como sua base é acessada pela web, não dá para desligar o Anti-Virus. Mas 
>> se o servidor WEB / PHP for independente desta máquina, dá para "lacrar" 
>> o seu servidor de Banco, e aí sim, eliminar o norton, e colher de 20% a 
>> 40% de performance do banco de dados.
>
> RC: Já desliguei o norton, e não subiu tudo isso não, foi pouca, quase
> imperceptivel a diferença.
>
>>
>> Mais uma coisa... você disse que o processador fica em 100%, mas quais os 
>> processos (e quanto) estão consumindo mais que 2% da CPU nestes momentos 
>> ??? Acho que o Norton está "matando" o banco durante o garbage... 
>> procurando por vírus a cada leitura...
>
> RC: Pode ser, mas 98% fica com o SErver do FB.
>
>>
>> =========================
>> Eduardo Jedliczka
>> (Membro do TeamFB)
>> Apucarana - Pr
>> =========================
>>
>> ----- Original Message ----- 
>> From: "Suporte Orel" <suporte em orel.com.br>
>> To: "Lista - fire" <lista em firebase.com.br>
>> Sent: Monday, October 03, 2005 4:20 PM
>> Subject: [firebase-br] Socorro 100%
>>
>>
>> Olá Edú,
>>
>> Desculpe, deixei passar esta, foi mal.
>>
>> Eu coloquei a Versão 1.5.3, mas vou seguir o seu conselho, hoje a noite 
>> vou
>> voltar para a 1.5.1
>>
>>>
>>> - Sua base tem 4.5 GB, isto não é motivo para deixar o servidor lento. 
>>> Mas, como está a qualidade dos seus índices, os plans das querys estão 
>>> bons (utilizando PKs ou índices únicos, minimizando o uso de FKs, e 
>>> evitar o uso do "NATURAL", ou seja, querys sem índices) ???
>>>
>>
>> Para este pergunta a resposta é a seguinte: Em 70% do dia de trabalho, o
>> servidor fica normal, fica entre 2 - 30%, dando picos rapidos de 100% que
>> ao
>> meu ver isso é normal. A querys são bem rapidas e sempre com indices.
>>
>>> - Você tem 80 usuários concorrentes (ou seja simultâneos) ou no total, 
>>> se for no total, quantos acessos simultâneos ???
>>
>> RC: Simultâneos
>>
>>> - Qual a maior utilização desta base: consultas e/ou relatórios, 
>>> manutenção dos dados(cadastro, alteração, exclusão), ou há um equilíbrio 
>>> entre estas duas opções ???
>>
>> RC: Equilibrio, incluo cerca de 20.000 registro dia, consulto uns 50.000 
>> e
>> movimento o mesmo registro em torno de 30.000.
>>
>>> - Você tem muitas view ??? StoredProcedures ???
>>
>> Rc: 8 view, e 1 SP
>>
>>>
>>> Mas já vou adiantando, se realmente for 80 usuários concorrentes, com 
>>> alimentação maciça, e emissão frequente de relatórios  pesados, o 
>>> problema pode estar aqui... Sendo assim, pode-se adotar um, ou mais, 
>>> servidores para realizar a emissão dos relatórios (se seu sistema puder 
>>> tolerar o atrazo de algumas horas nas informações impressas) através de 
>>> uma rotina automática de backup do servidor principal e restorne no 
>>> servidor de impressão de tempo em tempo.
>>
>> Rc: Bom hoje eu chequei a 98 user, mas eu acho que deve ter alguma coisa
>> pendurando, pois a empresa não tem isso de máquinas, tem umas 50 
>> máquinas,
>> e
>> só roda uma copia do sistema por máquina.
>>
>> Como eu posso ter certeza que o user de fato está ativo ?
>>
>>
>>>
>>> [s]
>>>
>>> =========================
>>> Eduardo Jedliczka
>>>> (Membro do TeamFB)
>>>> Apucarana - Pr
>>>> =========================
>>>>
>>>> ----- Original Message ----- 
>>>> From: "Eduardo Jedliczka (TeamFB)" <jedyfb em gmail.com>
>>>> To: "FireBase" <lista em firebase.com.br>
>>>> Sent: Friday, September 30, 2005 1:56 PM
>>>> Subject: Re: [firebase-br] Socorro 100%
>>>>
>>>>
>>>>> Vamos fazer algumas perguntinhas básicas para termos uma noção do que 
>>>>> está acontecendo:
>>>>>
>>>>> - Utiliza o FireBird Classic ou SuperServer ??? Qual a versão ??? 1.0, 
>>>>> 1.5, 2.0 ???
>>>>> - Você utiliza Eventos ???
>>>>> - Você utiliza UDFs ??? Pouco, muito, não utiliza, apenas as UDFs do 
>>>>> firebird, ou também utiliza outras (próprias) ???
>>>>> - Tem alguma query ligada num Timer (disparada regularmente de x em x 
>>>>> segundos) ???
>>>>> - Esta base sofre (sofreu) muitas alterações de estrutura sem que seja 
>>>>> feito um backup/restore ???
>>>>> - Faz relatórios muito pesados, que possam demorar vários minutos ???
>>>>> - Há algum módulo de backup e/ou replicação trabalhando durante este 
>>>>> pico ???
>>>>> - Tem anti-virus e/ou firewall instalado na máquina ???
>>>>> - Qual foi a última vez que você fez um Backup / Restore na base ???
>>>>> - Esta máquina também é servidora de Arquivos ???
>>>>> - Qual o sistema de arquivo (NTFS ou FAT32), tamanho do cluste e 
>>>>> pagesize adotado ???
>>>>> - O Congelamento acontece num horário específico, ou não ???
>>>>> - Seu sistema foi feito em qual linguagem ??? Qual componente de 
>>>>> acesso você utiliza ???
>>>>> - E quanto ao modelo transacional, está utilizando commit, 
>>>>> commitretainning ou mantendo a transação ligada por horas ???
>>>>>
>>>>> [s]
>>>>>
>>>>> =========================
>>>>> Eduardo Jedliczka
>>>>> (Membro do TeamFB)
>>>>> Apucarana - Pr
>>>>> =========================
>>>>>
>>>>> ----- Original Message ----- 
>>>>> From: "Suporte Orel" <suporte em orel.com.br>
>>>>> To: "Lista - fire" <lista em firebase.com.br>
>>>>> Sent: Friday, September 30, 2005 12:57 PM
>>>>> Subject: [firebase-br] Socorro 100%
>>>>>
>>>>>
>>>>> Pessoal
>>>>>
>>>>> Estou precisando de uma consultoria aqui em São Paulo, o meu banco 
>>>>> fica em determinados período dando pico de 100% e derruba todos, 
>>>>> alias, congela todos, eu já revi todas as querys, só que eu não sai 
>>>>> mais o que fazer, como resolver isso, alias, não sei como monitorar o 
>>>>> que está acontecendo, quem é o vilão da história.
>>>>>
>>>>> Preciso de algo que me mostre qual é a query ou o que está levando a 
>>>>> esse pico.
>>>>>
>>>>> P4 com 1024 de RAM, win2000 dedicado, base com 4.5GB
>>>>>
>>>>> Quem se habilita ?
>>>>>
>>>>> Eduardo de Carvalho
>>>>> Orel Consultores & Sistemas - www.orel.com.br - MSN : orel_carvalho
>>>>> São Paulo-SP- Brasil - (11)6193-4049 - (11)9196-4243
>>>>>
>>>>> "Respondeu-lhe Jesus: Eu sou o caminho, e a verdade, e a vida; ninguém 
>>>>> vem ao Pai, senão por mim."
>>>>> ______________________________________________
>>>>> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
>>>>> Para editar sua configuração na lista, use o endereço 
>>>>> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>>>>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>>>>
>>>>> ______________________________________________
>>>>> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
>>>>> Para editar sua configuração na lista, use o endereço 
>>>>> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>>>>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>>>
>>>>
>>>> ______________________________________________
>>>> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
>>>> Para editar sua configuração na lista, use o endereço 
>>>> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>>>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>>
>>
>>
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
>> Para editar sua configuração na lista, use o endereço 
>> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
>> Para editar sua configuração na lista, use o endereço 
>> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço 
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço 
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> 





Mais detalhes sobre a lista de discussão lista