Menu de navegação

[invoidParticipante]

Olá pessoal! Tudo bem?

Recentemente passei por uma situação que queria compartilhar com vocês
e ver se há mais algo a ser feito.

Fui chamado a um cliente por conta da implantação de um novo sistema.
Eles precisavam fazer diversas importações e atualizações de dados na
base para o sistema ser colocado no ar, e a empresa que desenvolve o
sistema informou que estava muito lento em relação aos demais
clientes.

Bom, temos o seguinte ambiente:

1 servidor Dell, 2x Quadcore, 16 GB RAM, com 6 discos SAS 300 GB 15K
em RAID50, usando VMWare ESXi.
Máquina virtual com 4 GB RAM, 150 GB HD, 2 processadores.
Instância com 2 GB SGA.

Uma das máquinas virtuais é a que está o Oracle. O cliente não dispõe
de recursos imediatos para modificar a infra dele, então temos que
trabalhar com isso aí.

Após fazer algumas análises, verifiquei:

– Os dois cores alocados para a máquina virtual estavam topados, tendo
muita conteção de requisições de sistema.
– Muitos processos “blocked” indicados no vmstat.
– A largura de banda utilizada durante estas cargas chegava perto de
100%, medido com o iostat.
– Não há utilização de SWAP.
– Checkpoints sendo feitos muito rapidamente, não dando tempo para os
redos rotacionarem e causando contenção.
– 3 Redo’s group de 50 MB.
– Archivelog habilitado.

De imediato, adicionamos mais 2 processadores à máquina virtual.
Agora, os 4 estavam “topados”. Fiz mais o seguinte:

– Adicionei 4 REDOs de 300 MB e removi os de 50 MB.
– Desativei o archivelog.
– Solicitei ao desenvolvedor que adicionasse a cláusula nologging às
instruções create table que ele estivesse gerando para inserir dados,
quando fosse este o caso.
– Solicitei também que ao invés de executar um commit após cada
insert, update ou delete, executasse o commit no final do bloco de
transações que estava executando.

Antes, levaram 2 horas para importar os dados de uma loja. Após estas
intervenções, levaram 40 minutos para importar os dados de todas as
lojas (cerca de 8). Notei também que agora a maior parte do
processamento é de processos de usuários, e não de sistema.

Mesmo assim, ainda estão reclamando que está “bem mais lento que os
demais clientes deles”.

No final do atendimento, recoloquei o banco no modo archivelog, pois
como iriam levar alguns dias fazendo estas rotinas, fiquei receoso de
haver algum problema com o banco e daí perdermos dados.

Sei que os ambientes são diferentes e é meio arriscado fazer esta
comparação que o desenvolvedor fez, mas mesmo assim, gostaria de saber
se além dessas medidas, haveria alguma outra que pudesse ser feita
para ainda assim melhorar a performance.

Obs.: As tabelas não estão particionadas.

Abraços, e obrigado pela atenção!

André Sousa

[IshiiParticipante]

Olá,

Qual a SO da VM? É possível aumentar a SGA? Pelo visto o problema está no processo de Importação, isso é um batch? Conseguiu identificar quais as queries mais lentas?

Com isso aumentamos o panorama…

[]s Ishii

[hudsonaParticipante]

Andre

Te aconselho a monitorar os Waits events .
Você precisa verificar se o banco ainda esta sofrendo com eventos como o
log file swith completion que é causado devido a falta de redo logs.

Va no alert.log e verifique se os checkpoints estão sendo completos.
Não sei como as inserções e atualizações são feitas mas o banco pode estar sofrendo com muitas compilações de comandos sql, o que iria carecer de variaves bind.

Abraços !

[invoidParticipante]

Ishii, Hudson, obrigado pela resposta rápida!!!!!

Ishii… Olha só, estou usando um CentOS 4.7 (equivalente ao RHEL 4.7). No caso, não seria possível aumentar por conta da plataforma (32 bits), aí já teria que mudar kernel, fazer uns “workarounds”, etc.

Os desenvolvedores estão selecionando dados de uma tabela e inserindo em uma outra tabela que eles criam neste momento, através de inserts mesmo. Geram os inserts e entopem no banco.

Hudson, eu esqueci de mencionar, mas com a alteração dos redo logs a situação dos checkpoints foi regularizada. Antes estava realmente havendo espera, depois que aumentei o tamanho dos redos não só os checkpoints ficaram menos frequentes como também passaram a ser feitos normalmente, sem espera.

O Spotlight acusou problemas na library cache, sugerindo a utilização de mais variáveis bind para diminuirem os hard parses. Porém, infelizmente, topamos com a velha situação de desenvolvedores que colocam o pé na porta e dizem: “Já está tudo otimizado, não vou mexer, já fizemos isso em vários clientes e foi tudo certo”. Já consegui muito convencendo a utilizar o NOLOGGING e alterar os commits.

[hudsonaParticipante]

invoid

Te aconselho a verificar as suas principais WAITS events , provavelmente devem ter eventos lógicos relacionados a falta de bind, nas estruturas de memória.

Como o próprio spotligth disse.

Reuna todas evidências as quais mostrem que o tempo gasto pelo banco esta na falta de binds, caso esse realmente seja o seu problema.
Relatórios do awr também são ótimos no seu caso.
Reuna tudo e jogue tudo na mesa na reunião.

Eu pelo menos consegui muita coisa aqui na empresa assim ….

[invoidParticipante]

Hudson,

Estou fazendo um relatório sobre essas coisas para passar ao cliente. Pelo menos quando saí de lá ontem ele já havia entendido que a infra-estrutura dele hoje não era a ideal, e que seria melhor investir em algo mais maleável, que permitisse trabalharmos com mais disponibilidade e maleabilidade.

Mas, bom, voltando às questões técnicas, eu estava dando uma olhada no seu blog e um dos posts me lembrou de outra coisa, que é os redo log buffers. Lá está configurado para 15M. Não mexi, pois ainda não sei dimensionar exatamente este buffer nem ver qual é o valor ideal. Por alto, futucando na internet, juntei umas informações e imaginei que este valor não estaria ruim, mas na realidade não foi algo medido. No caso, aumentar este valor poderia também trazer benefícios, uma vez que agora o commit está sendo executado no final do “catatau” de inserts?

[hudsonaParticipante]

Andre

Contra fatos não há argumentos, mostre seus relatorios e os desenvolvedores vão ter que acabar entendo a sua situação, embora sempre que possivel a conversa é a melhor forma de tentar resolver essa situação.
Acho ainda que você pode e vai descobrir mas coisas olhando os waits events. incluse pode ter a certeza se os seus problemas são realmente a falta de binds.

Não acredito que o aumento do log bufer no seu caso traga beneficios não.

A Redo log buffer armazena as alterações mais recentes até que LGWR grava-las no redo log files.
Porém imagino que deva estar pensando , já que eu não tenho mais a mesma quantidade de commits,
então LGWR não esta mais fazendo a mesma quantidade de flush de todas as alterações referentes aos blocos
para dos redo logs, então se eu tiver um Log buffer maior vou ter menos i/o de disco.
Bem se pensou assim esta errado, porque os dados que estão no Log Bufer vão para os redo log files
rapidamente de qualquer jeito, com ou sem commit, quando 1/3 do buffer tiver preenchido,quando 1MB de entradas no buffer de redo log tiver sido armazenado ou a cada
3 segundos o oracle vai gravar os registors do buffer nos redo log files.
E um buffer de redo log grande pode até prejudicar seu ambiente.
Quando uma instrução commit é enviada, parte desse processo consiste em gravar o conteudo do buffer de redo log
nos redo log files, um buffer de redo log grande pode significar que existem mais dados para serem gravados quando
uma instrução commit é emitida, e enquanto os dados não são gravados do buffer para o disco, a sessão fica
suspensa e a mensagem commit-complete não é retornada.
Mas ainda assim, se quiser ter certeza olhe as waits events e verifique se aparece muitos log_buffer_space waits.

Existe uma formula padrão para calculo do log buffer que é a :
LOG_BUFFER = 128K * total_processador;

Abraços

[hudsonaParticipante]

E complementando,

Como no seu ambiente você sofre co muitas atualizações e inserções, tome cuidado com os indices desnecessarios, monitore os indices pra saber se existe algum indice desnecessario no seu banco de dados ocupando espaço e piorando o seu tempo de inserção e atualização.

Abraços !

[invoidParticipante]

Hudson,

Obrigado pelos esclarecimentos !!!! Realmente eu estava pensando daquela forma. Bem equivocada! hehehe

O pessoal do sistema conseguiu fazer as operações durante este feriado e então o banco já está na sua utilização “normal”. Como o sistema está entrando no ar agora, vou ficar monitorando para ver os gargalos, e ficarei atento aos wait events.

Só me tira mais uma dúvida… Neste cálculo, total_processador é a quantidade de processadores ???

Abraços!!!

André

[vieriParticipante]

Roda um statspack ai , ou awr ou addm.
E faça uma análise as queryes que estão levando mais tempo
e quais wait’s elas estão sofrendo.

[hudsonaParticipante]

invoid

Isso monitora tudo, de preferencia no pico do banco e segue o conselho do nosso amigo vieri, e principalmente os relatorios do awr, pra você ter fatos na mão.

A Formula é a seguinte.

LOG_BUFFER = 128K * numero_cpu;

Exemplo, se o seu servidor é DUAL PROCESSOR, então:

LOG_BUFFER = 128K * 2; ==> LOG_BUFFER = 263168;

Abraços!

[VitorLeandroParticipante]

Só completando o que o pessoal falou aqui, sempre monitorar os Waits, principalmente do system_events, podes descobrir muita coisa que nem mesmo o EM e seus relatórios mostram.

Se existir muitos eventos de I/O, log buffer space, pode existir um gargalo de I/O. RAID 50, é o raid 5 + 0, ou seja, teoricamente é duas vezes mais rápido que o RAID5, mas não deixa de ser RAID5. Já tive problemas com isso. Raid 5 e suas derivações não é pra banco de dados.

É só uma observação…

[Autor]

Posts