Pular para o conteúdo

Seu RAC está lento, né?

Seu RAC está lento, né?

Isto não é ensinado no Treinamento Oficial de Oracle RAC, mas é ensinado no Treinamento Oracle 11gR2 RAC na Nerv. Para quem vem de fora de SP, temos o Treinamento Intensivo (quinta, sexta e sábado), com hotel incluso. Maiores informações: contato@nervinformatica.com.br.

O tamanho de bloco padrão nos Bancos de Dados Oracle (10g / 11g) é 8k (8192 bytes). Em contrapartida, o pacote padrão de transferência das redes Ethernet (ou Fast Ethernet ou Gigabit) é de 1500 bytes. Ou seja, são necessários vários pacotes de rede e várias conversas entre cliente e servidor para se transmitir um único bloco.
Isto não é um problema para uma instalação do Oracle Database em Single Instance, já que apenas resultados – e não blocos – são enviados para os clientes.

Mas isto é um problema em Oracle RAC – um nó precisa trocar pacotes, de 8k, com os outros nós. O resultado destas conversas adicionais é uma potencial escalabilidade inferior, facilmente comprovada pelos Wait Events GC – Global Cache.

Este gargalo pode ser solucionado utilizando-se Jumbo Frames na camada de rede, que transferem pacotes de rede de 9000 bytes – que acomoda o bloco de dados do Oracle sem problemas. Todas as camadas envolvidas precisam suportar os Jumbo Frames: Sistema Operacional, Switch e Placas de Rede. Por isto o DBA deve ser envolvido com o RAC desde a escolha do hardware – não basta ser Switch Gigabit, tem que ter suporte a Jumbo Frames.

Acho que esta técnica não é ensinada nos cursos e documentações oficiais porque os Jumbo Frames não são formalizados no padrão Ethernet. Mas funcionam perfeitamente.

Para habilitar os Jumbo Frames, execute este comando nos dois Nós, como root:

# ifconfig eth0 mtu 9000

Para que a alteação seja permanente, adicione uma linha com “MTU 9000” no arquivo “/etc/sysconfig/network-script/ifcfg-eth0”.

Para testar se os Jumbo Frames estão funcionando, utilizamos o comando do Linux ping especificando o tamanho do bloco enviado. Veja no teste abaixo, que antes de habilitar os Jumbo Frames, o pacote de 8192 bytes necessitaria de fragmentação. Após a ativação dos Jumbo Frames nos dois Nós, a fragmentação não é mais necessária.

[root@centos5-01 ~]# ping -s 8192 -M do 192.168.56.200 -c 5 
PING 192.168.56.200 (192.168.56.200) 8192(8220) bytes of data.
From 192.168.56.101 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.56.101 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.56.101 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.56.101 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.56.101 icmp_seq=1 Frag needed and DF set (mtu = 1500)

--- 192.168.56.200 ping statistics ---
0 packets transmitted, 0 received, +5 errors

[root@centos5-01 ~]# ifconfig eth0 mtu 9000
[root@centos5-01 ~]# ssh 192.168.56.200
The authenticity of host '192.168.56.200 (192.168.56.200)' can't be established.
 RSA key fingerprint is 94:cc:d4:76:06:9c:e3:c4:ed:98:2c:c1:db:92:8e:6b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.56.200' (RSA) to the list of known hosts.
root@192.168.56.200's password:
Last login: Thu Aug  5 08:51:18 2010 from 192.168.56.1
[root@centos5-02 ~]# ifconfig eth0 mtu 9000
[root@centos5-02 ~]# exit
logout
Connection to 192.168.56.200 closed.
[root@centos5-01 ~]# ping -s 8192 -M do 192.168.56.200 -c 5 
PING 192.168.56.200 (192.168.56.200) 8192(8220) bytes of data.
8200 bytes from 192.168.56.200: icmp_seq=1 ttl=64 time=0.804 ms
8200 bytes from 192.168.56.200: icmp_seq=2 ttl=64 time=0.905 ms
8200 bytes from 192.168.56.200: icmp_seq=3 ttl=64 time=1.11 ms
8200 bytes from 192.168.56.200: icmp_seq=4 ttl=64 time=1.18 ms
8200 bytes from 192.168.56.200: icmp_seq=5 ttl=64 time=1.36 ms

--- 192.168.56.200 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4131ms
rtt min/avg/max/mdev = 0.804/1.073/1.363/0.201 ms
[root@centos5-01 ~]#

Abaixo estão as fotos dos equipamentos que comprei para o Treinamento Oracle 11gR2 RAC na Nerv. Vejam no detalhe das caixas a especificação dos Jumbo Frames.

Quão útil foi este post ?

Clique em uma estrela para classificar o post

nota média 5 / 5. Contagem de votos: 11

Sem votos ! Seja o primeiro a classificar !

19 comentários em “Seu RAC está lento, né?”

  1. Avatar de Fabio Ishii

    Essa dica é a famosa “escovada nos bits” literalmente!!! Garanto que tem muitas empresas querendo saber o porque do investimento ainda não ter dado resultado esperado…
    Abraços Ishii

  2. Avatar de Regis Araujo

    Fala Portilho..!

    Excelente demonstração.. Isto para o interconnect é excelente..
    Outra maneira também de usar “Jumbo Frames” é em rede exclusiva para geração de backups..

    Quais seriam os prós e contras de habilitar “jumbo Frames” na rede principal de acessos?

    Abraços..!

    Regis Araujo

  3. Avatar de Vinicius

    Falar que é um grande post é chover no molhado se tratando de você, Portilho!

    Excelente!

    A nota “Recommendation for the Real Application Cluster Interconnect and Jumbo Frames [ID 341788.1]” do Metalink só corrobora tudo o que você disse.

    Lembrando sempre que é bom homologar bem a solução, já que a Red Hat tem alguns bugs no RHEL3 utilizando Jumbo Frames. Mas a Oracle mesmo assim afirma que é recomendado utilizar Jumbo Frames.

    Abraço

    Vinicius

  4. Avatar de Marcelo

    Estou começando a ler sobre o Oracle RAC e achei bastante interessante a sua “dica” sobre Jumbo Frames, entretanto, como sou leigo no assunto fiquei com a seguinte dúvida: Caso o Hardware seja compatível, existe como configurar Jumbo Frames em um RAC implementado em Windows Server?

    Agradeço Antecipadamente.

    Atenciosamente,

    Marcelo Torres

Deixe um comentário para Ricardo Portilho Proni Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

plugins premium WordPress