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ê.
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
