Olá!
Estou com o Discourse rodando no Docker, e ele parece nunca usar swap quando a memória RAM está sendo muito utilizada. Isso faz com que ele trave ou retorne o erro fatal error: out of memory allocating heap arena map se eu tentar reconstruir, a menos que eu reinicie a cada poucas horas. Caso contrário, não parece funcionar.
Alguém sabe como resolver isso?
Obrigado,
Kian
Supondo que você esteja no Linux, o que o comando free -h mostra? (De preferência, imediatamente após a reinicialização e também pouco antes do erro.)
Talvez o swappiness esteja definido como 0?
cat /proc/sys/vm/swappiness
Oi!
Estava em 40, mas agora configurei para 60.
O sistema sempre armazena em cache grandes blocos de RAM, e a swap nunca é usada, mesmo quando o uso da RAM está alto.
Acho que as duas partes da saída em que vale a pena se concentrar são os 5,5 GB de memória disponível e os 0 B de swap utilizada. Ou talvez os 9 GB de swap livre. A soma de 5,5 GB + 9 GB indica quanto espaço livre você tem. A quantidade de memória usada para buffers e cache é dinâmica e nunca deve causar falta de recursos.
Considerando que o tempo até a falha é de apenas algumas horas, eu executaria um vmstat 5 e capturaria a saída de forma que seja possível observar os momentos finais. Eu costumava usar um job do cron para rodar vmstat 5 5 em um arquivo de log a cada 10 minutos.
É possível que, com um software malcomportado, todos os recursos disponíveis sejam consumidos muito rapidamente. Nesse caso, um log do comando ps uax a cada poucos minutos — para obter alguns instantâneos nos momentos cruciais — pode ser muito útil.
Também é possível que outros limites estejam em vigor. Presume-se que se trata de uma instalação padrão em um sistema operacional padrão, sem nada mais rodando e sem configurações especiais?
Olá!
Como posso configurar o comando vmstat 5 para ser registrado em um log a cada 10 minutos? E como posso fazer com que o ps uax escreva em um log a cada poucos minutos?
Sim, é uma instalação padrão do Ubuntu Server 18.04. Tenho apenas coisas como Apache, Docker, etc.
Acabei de lembrar que também tenho o Varnish Cache instalado, o que explica a RAM que está em cache. Mas não entendo por que o Discourse não usaria swap também. Configurei sua alocação há alguns dias com um comando Docker para definir o limite de swap, mas não surtiu efeito algum.
Aqui está uma linha única, simples e eficaz (embora o cron seja uma abordagem melhor):
sh -c 'rm -f /tmp/stop; while [ ! -e /tmp/stop ]; do (date; uptime; free; ps faux; vmstat 5 5) >> /var/log/monitor.log; sleep 600; done' &
Ele será executado indefinidamente: para interrompê-lo, use touch /tmp/stop.
O log aparecerá em /var/log/monitor.log. Use tail -99 para ver as últimas entradas ou less para navegar pelo arquivo. De alguma forma, você precisará localizar as seções do log que mostram o problema se desenvolvendo.
Parece que você está fazendo a pergunta errada aqui. É o kernel do Linux que gerencia a memória virtual, incluindo o uso de buffers e de swap. Se o comando free indicar que o swap está configurado, isso está correto e não há nada que você precise fazer.
Sua verdadeira pergunta deveria ser: por que meu Discourse não está funcionando bem, por que precisa ser reiniciado e por que estou vendo o fatal error?
Recomendo fortemente que você renomeie este tópico para:
Por que “fatal error: out of memory allocating heap arena map”?
Além disso, me preocupo que você pareça ter várias observações distintas:
E não está claro para mim exatamente como essas observações se relacionam.
Seria ótimo ouvir as respostas!
Hmm, o que você fez? O que o comando
docker stats --no-stream --no-trunc
relata para MEM USAGE / LIMIT e MEM %?
(No meu caso, o LIMIT é um pouco menor que a memória física da máquina. Talvez isso signifique que nada que esteja rodando dentro do container provavelmente causará swap, e você pode ver um processo falhar ao alocar memória mesmo quando há pouco ou nenhum swap em uso.)
Olá!
Acredito que o Discourse tenha travado, pois ao acessar o domínio, recebo o erro Nginx 502 Bad Gateway. No entanto, o contêiner Docker ainda está em execução.
Sim, exceto em ocasiões ocasionais.
Reconstruí o contêiner, pois isso costuma resolver o erro 502 Bad Gateway por um tempo.
Também reinicio o servidor para ver se isso corrige o erro. Muitas vezes funciona, mas é mais provável que não funcione, e uma reconstrução resolve o problema por um tempo.
Em breve, também enviarei o log de erro.
Ao executar /var/log/monitor.log com tail -99, recebo: -bash: /var/log/monitor.log: Permissão negada
(Pela sua captura de tela, vejo que o contêiner chamado “app” tem um limite de memória de 7,8G e está usando apenas 3%, então isso está tudo bem. Edição: mas pode ser suspeito que ele esteja usando 100% da CPU.)
Precisamos apenas olhar o final desse arquivo de log, então
tail -199 /var/log/monitor.log
possivelmente nos dará o que precisamos. Mas talvez precisemos olhar mais do arquivo: talvez você possa compactar o arquivo de log e anexá-lo ou compartilhá-lo de outra forma. Qual é o tamanho do arquivo de log?
ls -l /var/log/monitor.log
Acho que 100% equivale a 1 núcleo. Porque o sistema funciona bem.
log.txt|anexo (25,0 KB)
199 linhas do log.
monitor.txt (39,3 KB)
Aqui está o log completo 
Obrigado. Tudo parece saudável, mas é apenas um único snapshot. O que deveria acontecer é que a cada 10 minutos outra seção seja anexada ao log. Aguarde até ver o problema no seu Discourse e, em seguida, compartilhe as últimas seções.
Preciso dizer que não sei o que está acontecendo.
Notei que seus 3 unicórnios estão usando muita CPU, e não sei por que deveriam.
USUÁRIO PID %CPU %MEM VSZ RSS TTY STAT INÍCIO TEMPO
COMANDO
x 434 51,9 2,8 443732 234144 ? Sl 18:26 0:11 \_ master do unicorn -E production -c config/unicorn.conf.rb
x 662 103 3,6 8877408 301148 ? Rl 18:26 0:08 | \_ sidekiq do discourse
x 686 99,7 3,6 8873312 301916 ? Rl 18:26 0:06 | \_ worker do unicorn[0] -E production -c config/unicorn.conf.rb
x 731 94,3 3,6 8873312 294368 ? Rl 18:26 0:05 | \_ worker do unicorn[1] -E production -c config/unicorn.conf.rb
x 744 77,2 3,3 8873312 276788 ? Rl 18:26 0:03 | \_ worker do unicorn[2] -E production -c config/unicorn.conf.rb
Você pode executar top e pressionar shift+m para ordenar por uso de RAM e ver o que está consumindo mais memória. Pode postar o resultado aqui?
