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.