Alto uso de memória sem tráfego?

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?

Quantas postagens foram importadas?

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.

3 curtidas

Cerca de 240.000 postagens.

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:

RAM: 8 GB

CPU

Tráfego

Sidekiq

Para mim, parece que está vazando memória lentamente até a morte em alguns dias… (que tem sido o comportamento observado até agora.

1 curtida

Após a importação, é sempre uma boa ideia para o desempenho do banco de dados criar um backup e restaurá-lo na mesma instância.

Esse gráfico de memória inclui ou exclui o cache? (ou seja, como é a saída de free -m?)

Algum plugin?

1 curtida

## Plugins vão aqui
## veja https://meta.discourse.org/t/19157 para detalhes
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/discourse/discourse-data-explorer.git
          - git clone https://github.com/discourse/discourse-solved.git
          - git clone https://github.com/discourse/discourse-cakeday.git
          - git clone https://github.com/discourse/discourse-spoiler-alert.git
          - git clone https://github.com/discourse/discourse-user-card-badges.git
          - git clone https://github.com/discourse/discourse-adplugin.git

Boa ideia. Algo que vou tentar.

Isso tornou o site irresponsivo.. (Fiz backup.. restaurei o backup e depois reiniciei)

Uso de RAM aumentou de 6 GB para 7 GB e o site não responde.

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:

./launcher enter app
redis-cli flushall
1 curtida

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

Muito obrigado pela ajuda

2 curtidas

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.