Estou testando o Discourse como um possível destino para o nosso fórum existente e estou tentando descobrir os requisitos.
Atualmente, estou executando o droplet Discourse em um nó Digitalocean com 4vCPUs e 8GB de RAM.
Com o site vBulletin importado rodando aqui sem tráfego e sem atividade, o sistema começa usando cerca de 75% desses 8GB de RAM e, ao longo de alguns dias, sobe para 100% e para de responder completamente.
Isso me confunde, já que o mínimo necessário parece ser muito menos do que isso.
(Eu reconstruí o contêiner, verifiquei e limpei as tarefas do Sidekiq, ainda com alto uso)
Alguém tem alguma dica ou devo estar procurando uma configuração de RAM monstruosa apenas para manter o fórum funcionando?
O sistema pode estar reprocessando postagens e redimensionando imagens, o que pode usar muitos recursos, mesmo que você não tenha usuários. Você pode verificar /sidekiq para ver se há muitos trabalhos na fila e/ou em execução. Além disso, htop pode dar algumas dicas sobre o que está em execução.
A importação ocorreu há cerca de 5 semanas, passei por 5 reconstruções de aplicativos desde então, que parecem ser o que resolve o problema de memória quando o contêiner entra em 100% de falta de resposta de memória.
Limpei todas as tarefas no sidekiq, como mencionado, e o uso ainda está em 75%.
O gráfico de memória desde que reconstruí o servidor ontem:
Há quase 5 GB sendo usados pelo Redis, o que deixa o Discourse com pouco para trabalhar, especialmente considerando quantos unicórnios você está executando.
Se sua fila do sidekiq estiver limpa, tente limpar o Redis, pois ele pode ter muito lixo da importação:
Entendi, vou tentar o comando redis.
O problema do worker do unicorn foi um que verifiquei bem cedo. Mudei tanto o uso de memória para db_shared_buffers quanto configurei os workers do unicorn para 3.
A configuração de workers do unicorn parece ter pouco ou nenhum efeito no número de workers que realmente rodam.
Do meu arquivo app.yml
## Quantas requisições web concorrentes são suportadas? Depende da memória e dos núcleos de CPU.
## será definido automaticamente pelo bootstrap com base nas CPUs detectadas, ou você pode substituir
UNICORN_WORKERS: 3
Esse comando flushall fez maravilhas… caiu para 2gb usados… veremos se isso se mantém agora.
A parte preocupante era que as coisas continuavam crescendo antes. Espero que isso permita que o aplicativo se autogerencie melhor.
De qualquer forma… então a importação mantém as coisas permanentemente no redis? parece estranho, mas eu não tenho ideia de como o redis funciona, então