sql*net more data from client

Reparei que a documentação e a quantidade de relatos a respeito de problemas com os wait events ‘SQL*Net More Data To Client‘ e ‘SQL*Net More Data From Client‘ é escassa.

Enfrentei problemas com o segundo caso, From Client, durante alguns dias. Não havia impacto aparente na aplicação, mas o gráfico incomodada e deixava o mistério no ar. Pesquisas a respeito disso resultavam em respostas vagas. Afinal, partia-se da premissa que era ou um problema de rede ou um problema em que a aplicação tinha muito o que enviar para o banco e ocorria algum problema no processo.

Verificando no EM eu chegava a uma query, um insert bem simples, sempre atrelada aos picos de rede. Talvez havia ocorrido alguma mudança na aplicação em que a inserção de dados no sentido aplicação – banco era atrasada? Pesquisa aqui, pesquisa ali, consulta tais e tais queries. Nada.

Vamos então verificar a rede. Será um gargalo?

No servidor da aplicação vou verificar a placa de rede. Configurada corretamente, estável no geral:

[root@aplicacao1 ~]# mii-tool eth0
eth0: negotiated 100baseTx-FD, link ok

Desconfiado, pesquiso uma alternativa ao mii-tool e acho a mais moderna e parruda ethtool. Resultados corretos, dessa vez, e condizentes com as portas do switch no qual os servidores estão conectados (output cortado para reduzir o tamanho):

[root@aplicacao1 ~]# ethtool eth0
Settings for eth0:
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Link detected: yes

Agora sim.

Daí então verifico como anda o tráfego em tempo real. Uso a ferramenta iftop para tal. Nela eu verifico que TX e RX estão acima de 90Mb/s mas não ultrapassam essa marca. Verifico então o servidor do banco:

[root@banco ~]# ethtool eth0
Settings for eth0:
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Link detected: yes

Ahá. Hora de trocar alguns cabos no switch. Colocando o banco na saída certa, uma 100/1000, pode-se verificar a mudança imediata:

[root@banco ~]# ethtool eth0 | grep Speed
Speed: 1000Mb/s

Perfeito. Com o iftop consigo ver que agora a aplicação supera os 100Mb/s mas não muito. Havia, enfim, um gargalo de rede com um teto causado pela porta 10/100 do switch do lado do banco.

Problema de SQL*Net More Data From Client resolvido!

WordPress E Os Dois Hifens

Revisando o meu último post, notei que havia algo diferente do que eu havia escrito originalmente nos meus comandos. Antes da maior parte dos parâmetros havia um travessão em vez de dois hifens, o que não condiz com a sintaxe aceita do comando rsync (e nem mesmo condiz com o que eu escrevi).

Acabei descobrindo que o WordPress tem um “feature” inconveniente, que é transformar automaticamente dois hifens (--) em um travessão (–) e que não há opção clara para desabilitar essa transformação. Excelente, especialmente para quem rodar os comandos do post passado com apenas um hífen e receber as seguintes mensagens:

rsync: link_stat “/hd-backup/\#226partial” failed: No such file or directory (2)
rsync: link_stat “/hd-backup/\#226append” failed: No such file or directory (2)
rsync: link_stat “/hd-backup/\#226progress” failed: No such file or directory (2)
rsync: link_stat “/hd-backup/\#226bwlimit=20480” failed: No such file or directory (2)
rsync: link_stat “/hd-backup/\#226no-whole-file” failed: No such file or directory (2)
delta-transmission disabled for local transfer or --whole-file

Obrigado, WordPress, por não ser Linux-friendly.

Agora, como corrigir isso nos posts do WordPress:

Ir para a opção de entrada Text (em contrapartida a Visual), e lá substitua os seus -- por:

&#45 ; &#45 ;

Atenção, sem os espaços antes e depois dos ponto-e-vírgula.

E voilá:

rsync -vv --partial --append --progress --bwlimit=20480 --no-whole-file arquivo.tar.gz /mnt/servidorbackup/

OBS: o primeiro hífen antes de vv é realmente simples e não foi um erro.

É isso. Até!

SCP vs RSYNC

Eu tinha a seguinte situação: eu tinha que transferir, diariamente, um arquivo de backup .tar.gz de 140+Gb de um servidor para o outro. Era um Linux transferindo de uma localização para um ponto de montagem que na verdade era um outro servidor Windows. Acontece que, durante a longa transferência, o servidor primário ficava sobrecarregado (até porque é onde roda o Oracle de produção), e congelava diversos sistemas da empresa, o que gerava uma série de razoáveis reclamações. Sempre que acontecia isso, eu tinha que cancelar a cópia e recomeçar algum tempo depois, quando o banco estivesse com uma utilização reduzida – correndo o risco de novamente ter um pico de utilização, gerar mais congelamento e ter que parar novamente.

O comando que eu utilizava era o:

scp arquivo.tar.gz /mnt/servidorbackup/

Então pesquisei alternativas, e cheguei ao rsync. Um comando bem parrudo, com diversas utilidades. Então comecei a testar os parâmetros e observar o impacto no banco. Comecei com as seguintes opções:

rsync -vv --partial --progress arquivo.tar.gz /mnt/servidorbackup/

No caso -vv é verbose (o v duplo é para mais informações de verbose), --partial é para manter o arquivo parcialmente transferido caso o rsync tenha que ser interrompido e --progress é para imprimir o progresso da transferência.

Mas, com esse comando, eu notei que quando eu retomava a transferência após interrupção, o rsync criava um outro arquivo e recomeçava a transferência. Tinha algo errado. Pesquisei mais e descobri que quando ocorre a transferência dentro do mesmo sistema local (mesmo que o destino fosse um servidor remoto, ele estava sendo tratado como local por ser um ponto de montagem), o delta-transmission é desligado por padrão – isso quer dizer que a transferência não pode ser resumida de onde parou, só começada do zero. A solução vem do parâmetro --no-whole-file que força o delta-transmission mesmo para transferências locais. E o meu comando ficou assim:

rsync -vv --partial --progress --no-whole-file arquivo.tar.gz /mnt/servidorbackup/

Mesmo com o rsync sendo mais lento que o scp e o cp, a transferência impactava no banco em pouco tempo. Pesquisando um pouco mais, vi que podia limitar a taxa de transferência do arquivo com o parâmetro --bwlimit, sendo este definido em Kb/s. Então limitei a transferência em 20Mb/s, como pode ser visto no comando abaixo:

rsync -vv --partial --append --progress --bwlimit=20480 --no-whole-file arquivo.tar.gz /mnt/servidorbackup/

No caso, o --append é para que o rsync não verifique todo o arquivo temporário já presente no servidor remoto e simplesmente retome a transferência a partir de onde parou. Só utilizo isso por saber que o arquivo de origem não sofreu alterações desde que comecei a primeira transferência.

A saída desse comando é:

[root@quaseparando]# rsync -vv --partial --append --progress --bwlimit=20480 --no-whole-file arquivo.tar.gz /mnt/servidorbackup/
sending incremental file list
delta-transmission enabled
arquivo.tar.gz
53696366592 97% 10.69MB/s 0:06:40

Agora só acompanho com o top para ver se preciso parar o rsync com ctrl+c e não preciso mais passar pelo perrengue de recomeçar do zero duas ou três vezes por dia.

É isso. Até!