[FUG-BR] [HISTORICO][RESOLVIDO] - scp fatal: Write failed: Cannot allocate memory no /var/log/messages

[Paulo Henrique - BSDs]

Saudações,

O intuito da thread é apenas para documentar caso algum outro 
companheiro sofra ou venha sofrer com tal problema.

O problema em si é que qualquer copia de uma grande quantidade de 
arquivos ou mesmo de um arquivo grande apenas através do scp faz o 
servidor sshd não conseguir alocar memoria e resetar a conexão, contudo 
pelo que observei ( no meu ambiente 2 servidores e nos ambientes das 
threads que tinha a solução ) o problema só ocorre quando o servidor que 
está rodando o sshd ( acontece com o rsync também ) tem junto a execução 
do Hipervisor VirtualBox.

A solução do problema é o ajuste da variavel net.graph.maxdata=65536 no 
arquivo /boot/loader.conf, por padrão essa variável tem o valor 512.

  ##### Trecho da mensagem exibida no /var/log/messages  do lado do 
servidor sshd #####
Aug 27 00:13:36 cloud02 sshd[76535]: fatal: Write failed: Cannot 
allocate memory
Aug 27 00:31:57 cloud02 sshd[76577]: fatal: Write failed: Cannot 
allocate memory
Aug 27 00:35:54 cloud02 sshd[76599]: fatal: Write failed: Cannot 
allocate memory
###########################################################################

No lado cliente o erro poder se parecer com o abaixo no caso do scp.

##### Retorno de erro por parte do scp no lado do cliente 
###########################
Connection to cloud02.intranet closed by remote host.
lost connection
###########################################################################

Tal tunning requerido para resolver esse problema foi muito discutido em 
varias outras threads na internet contudo somente nas que estou postando 
abaixo foi descriminada a solução e o por que de tal ajuste, vale a pena 
ler a discussão inteira descobri um monte de coisas no FreeBSD.

http://lists.freebsd.org/pipermail/freebsd-emulation/2011-July/008977.html
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2011-07/msg00154.html

Para se saber que há necessidade de ajustar a variável net.graph.maxdata 
tem que se observar a ultima linha da saída do comando "vmstat -z" ( não 
conhecia ).
Se a saída for igual ou parecida com  essa abaixo onde o penúltimo campo 
tem contadores diferente de 0 então o ajuste de tal variavel se faz 
necessário.

ITEM                                   SIZE  LIMIT     USED FREE      
REQ             FAIL     SLEEP
NetGraph data items:     72,    527,       0,             527, 
1234536576,3001,   0 ( essa é a ultima linha do comando e o campo 
importante aqui é o campo FAIL ).

Como teste estava usando um diretório com aproximadamente 25 000 000  de 
arquivos ( 265 Gbytes ) no qual faz parte do backup da empresa, antes 
estava usando uma gambiarra via script para manter o backup desse 
diretorio, porem agora efetuei tres copias consecutivas e o teste foi um 
sucesso, não ocorreu nenhuma interrupção na copia.

Recomento para quem não conhece as variáveis do vmstat -z que de uma 
lida no manual, pois tem muita informação boa sobre o que elas manipula 
no sistema.

Abraços a todos e espero que ninguém mais perca tempo com essa pequena 
inconsistência.

-- 
Paulo Henrique.
Grupo de Usuários de Sistemas BSDs no Brasil.
Fone: +55 21 96713-5042

Não importa o que faça, sempre haverá alguém em algum lugar do mundo que será sempre melhor do que você.