- Este tópico contém 23 respostas, 4 vozes e foi atualizado pela última vez 16 anos, 3 meses atrás por
Thiago Vilhena.
-
AutorPosts
-
10 de setembro de 2009 às 7:37 pm #89566
Thiago Vilhena
ParticipanteBom diaa pessoal… andei bastante sumido (rsrsrsrs)
Tipo estourou esse evento GC CR MULTI BLOCK REQUEST
versao : 10.2.0.4
tava lendo por ai e vi que poderia ser um BUG.. mas na minha versao ele ja foi corrigido…
ai galerinha da uma luz ai pra min =D
abraços…
10 de setembro de 2009 às 8:30 pm #89567Thiago Vilhena
ParticipanteA pessoal esqueci de lembrar..
Não gostaria de particionar… Vai dar dor de cabeça com os desenvolvedores da aplicação!! se puder evitar é melhor, mas se nao tiver jeito fazer oque!!abraços
10 de setembro de 2009 às 9:25 pm #89568vieri
ParticipantePariticonar oque ?
GC CR MULTI BLOCK REQUEST é um wait event em ambientes
oracle RAC, que gerência requisições de blocos
inter-instâncias é normal ele aparecer nas wait events.Com qual interpretação vc chegou a conclusão que esse wait pode ser um overhead no seu ambiente ?
10 de setembro de 2009 às 10:32 pm #89569Thiago Vilhena
ParticipanteOpa vieri…
Desculpe, nao expliquei direito…
Estou fazendo a performance em um ambiente RACeu gostaria de poder diminuir o tempo deste evento e de um outro mostrados abaixo.
http://img186.imageshack.us/img186/3269/topevents.jpg
desculpe minha burrice mas eu nao sei inserir imagem aqui.. tentei com a tag de img e nada rsr.
10 de setembro de 2009 às 10:39 pm #89570Thiago Vilhena
Participante[img]http://img186.imageshack.us/img186/3269/topevents.jpg
[/img]10 de setembro de 2009 às 11:36 pm #89571vieri
ParticipanteCara to achando muito extrano isso ai…
vc tem usuário reclamando de lentidão ?, ou você está avaliando(validando) um ambiente RAC que ainda não está em produção…
muito extrano eventos de global cache e de leitura de control-file
está maior que db_file_sequencial_read…e apesar do percentual alto, o número de wait’s (qtd) não é tão grande assim…
10 de setembro de 2009 às 11:45 pm #89572vieri
ParticipanteOutro detalhe…
Oracle RAC não performa bem quando se tem problemas
de stand alone…Ou seja um problema de performance x² em ambiente stand alone
em oracle RAC pode tomar proporções maiores 3x³ !!! de acordo com a qtd de nós…Pense no RAC não como vilão… mas sim como um cara mais exigente com relação a boas práticas de performance… da uma verificada geral no ambiente, faça tunning esquecendo que é um cluster….
Se após isso nada feito…. 😯
tente esse texto abaixo: 😉
e poste as dúvidas…
Seeking understanding of my “gc cr multi block request” waits
——————————————————————————–
Hello everyone.
I am the DBA for a three-node RAC database that is suffering from an intermittent performance problem. The Oracle release is 10.2.0.1 on RedHat linux.
Periodically, a particular job that normally runs in less than a second takes several seconds to complete, sometimes requiring as much as 20 seconds.
An examination of raw trace files created during the job execution has revealed that the wait event causing the slowdown is “gc cr multi block
request”. This particular wait event is not well-documented by Oracle, and I have found little information on it on the internet. I am posting this
message to try to get confirmation of my understanding of the event from the other DBA’s who may have experienced it.I’m thinking the cause of the wait event is several possibilities, and I want to get everyone’s opinion on the subject. Mr. Gopalakrishnan’s wonderful
book on RAC does not mention “gc cr multi block request”. It does, however, mention the event “gc cr request” as a “Place Holder” event.1. If “gc cr multi block request” is also a place holder event (which would seem logical, implying multi-block IO), I would think I should never see
it as a major event. I would think it should be substituted by one of the “gc*2-way” or “gc*3-way” events, as the Gopalakrishnan book implies. So, I’m
confused as to why I am getting so much “gc cr multi block request” waits without any “2-way” or “3-way” waits.2. On the other hand, if the “gc cr multi block request” event is not a place holder event, does it indicate the wait time experienced by the instance
while trying to get a lock request from the master of the resource? A few of these waits are over a second, according to the raw trace file. That
seems like an awfully long time to just get a lock request from the master. Any idea what could cause that?3. Could the “gc cr multi block request” event be the total time spent obtaining the block from another instance? This would make sense given the
length of some of these events and the total lack of any “2-way” or “3-way” events. But, that doesn’t jive with the information in the Gopalakrishnan
book or in any other resource I have read.4. There is an Oracle bug #3951017, but it is supposedly fixed in 10gR2, and it causes a widespread slowdown, not the intermittent, specific to a
single session, type of slowdown that I am experiencing. So, I doubt I have this problem.Can anyone confirm if this wait event is one of the four possibilities above or one I haven’t mentioned?
All these possibilities share the same set of possible solutions (except for #4), according to my understanding. Please correct me if my list of
solutions is erroneous or incomplete.1. Use application/data partitioning techniques to try to remove the inter-instance contention for the blocks in question.
2. Use jumbo frames on the interconnect (the current interconnect is configured with an MTU of 1500)
3. I think disk-IO is sometimes involved with these cache fusion operations to flush redo log buffers, so improving disk speed may help as well. We
are currently on RAID-5 but plan to implement a series of RAID-1 arrays under ASM control in the near future.
4. Tweaking the number of LMS processes on the holding instance, but no CPU spikes have been noticed during these slowdowns, so I question having to
do this.Does anyone have any thoughts, comments, suggestions, explanations or solutions that may help me to decipher the reasons for these waits and the means
by which to eliminate them. Any help would be gratefully accepted. Thanks.10 de setembro de 2009 às 11:58 pm #89573Thiago Vilhena
ParticipantePo manuh… Já está em produção a algum tempo.
Eu nao sou o DBA deste Banco.. fui contratado para fazer a performance dele!!
Como nao saco muito de RAC e vi esses parametros ai que tbm achei meio bizarro vim aki pedir HELP pros guruss =DTipo o usuario tava reclamando da aplicação pra caramba…
fiz umas alteraçoes que deu uma melhora. O usuario nao reclamou mais de lentidao. Mas eu acho que da pra fazer alguma coisa a mais pra abaixar esse cara ai pra dar um ganho melhor na performance. Ontem pedi para aumentarem a SGA, ela estava sendo usada em 90%, pedi pra aumentar ela!! agora meu foco é saber sobre esse gc cr multi block request e ve se dar pra cair o time deleVlw pela ajuda ai vieriii…[/u]
11 de setembro de 2009 às 12:06 am #89574Thiago Vilhena
ParticipanteEntao manuh..
Estou trabalhando nele, como trabalhei em outros ambientes sem RAC, logico com cuidado… Acredito que com minhas abilidades já fiz o meu possivel. Mas sabe quando voce sente, Essa M**** podia ter ficado melhor, entao to procurando coisas pra melhorar. Vi esse cara ai com o tempo alto e to atirando nele!!11 de setembro de 2009 às 12:10 am #89576vieri
ParticipanteGere o ASH novamente, após aumentarem a SGA.
outra dica: Verifique se as config’s de SGA estão idênticas nos 2 ambientes…
11 de setembro de 2009 às 12:33 am #89579Thiago Vilhena
ParticipanteJa pedi para gerarem os reports depois da alteração da SGA.. Estou esperando eles me mandarem..
Dai quando eu analisar os reports, post aqui como q está =D
vlw parceiro
E sobre akilo ali que voce postou gc cr multi block request. eu tinha penssado nakelas coisas ali tbm, mas tipo nao posso particionar por causas burocraticas, RAID nem penssar.
Vamor ver se depois do aumento da SGA vai diminuir
abraços
11 de setembro de 2009 às 12:35 am #89580vieri
ParticipanteComo foi a alteração da SGA ?
como estava e como está agora ?
SGA bem confuigurada é extremamente importante
para evitar wait’s GC% …..11 de setembro de 2009 às 1:05 am #89581Thiago Vilhena
ParticipanteQuando chegar o report com a alteração eu posto aqui o antes e o depois.. amanha ja devo te-lo em maos (espero).
rsrsrss
11 de setembro de 2009 às 6:17 pm #89590Thiago Vilhena
ParticipanteAi Vieri, tava assim
http://img15.imageshack.us/img15/2840/sharedpool.jpg
pedi para que aumentassem + 25 %
Mas ainda nao me mandaram os reports com a alteração.
Estou percorrendo os AWR que me enviaram e tentado ver se conssigo achar + alguma cosa pra melhorar
se liga manuh, teve um momento ali em cima que voce disse que os events GC e reads de control_file estam maiores do que db_file_sequencial_read.
entao isso impacta no que ?? pode me dar uma luz para dar uma melhorada???
abraços
11 de setembro de 2009 às 8:41 pm #89604vieri
Participanteisto impacta que está muito extrano…
vc tem um banco de dados que consome mais recurso gerênciando ele mesmo,
do que trabalhando!Mas vc tirou esse ASH em que horário, de pico ?
isso também conta.seu control-file ta multiplexado?
vc faz backup RMAN usando control-file?
O control-file ta na storage ou em File system? -
AutorPosts
- Você deve fazer login para responder a este tópico.