Utilizzo elevato della memoria senza traffico?

[Haddoq]

Sto testando Discourse come possibile destinazione per il nostro forum esistente e sto cercando di capire i requisiti.

Attualmente sto eseguendo il droplet Discourse su un nodo Digitalocean con 4vCPU e 8GB di RAM.

Con il sito vbulletin importato in esecuzione qui senza traffico e senza attività, il sistema inizia utilizzando circa il 75% di questi 8 GB di RAM e nel giro di pochi giorni sale al 100% per poi smettere completamente di rispondere.

Questo mi confonde dato che il minimo richiesto sembra essere molto inferiore.

(Ho ricostruito il container, ho controllato e cancellato i task di sidekiq, l’utilizzo è ancora alto)

Qualcuno ha qualche consiglio o dovrei considerare una configurazione con molta RAM solo per mantenere attivo il forum?

[pfaffman (Jay Pfaffman)]

Quanti post sono stati importati?

Il sistema potrebbe essere in fase di rielaborazione dei post e ridimensionamento delle immagini, il che potrebbe utilizzare molte risorse anche se non hai utenti. Puoi controllare /sidekiq per vedere se ci sono molti processi in coda e/o in esecuzione. Inoltre, htop potrebbe darti alcuni indizi su cosa è in esecuzione.

[Haddoq]

Circa 240.000 post.

L’importazione è avvenuta circa 5 settimane fa, sono state effettuate 5 ricostruzioni dell’app da allora, che sembrano essere la soluzione al problema di memoria una volta che il container entra in uno stato di non reattività al 100% della memoria.

Ho cancellato tutti i task in sidekiq come menzionato e l’utilizzo è ancora al 75%

Il grafico della memoria da quando ho ricostruito il server ieri:

RAM: 8 GB

CPU

Traffico

Sidekiq

[Haddoq]

A me, questo sembra che stia lentamente perdendo memoria fino alla sua morte in pochi giorni… (che è stato il comportamento osservato finora.

[RGJ (Richard - Communiteq)]

Dopo l’importazione, è sempre una buona idea per le prestazioni del database creare un backup e ripristinarlo nella stessa istanza.

Quel grafico di memoria include o esclude la cache? (ovvero, come appare l’output di free -m?)

Ci sono plugin?

[Haddoq]

## I plugin vanno qui
## vedi https://meta.discourse.org/t/19157 per i dettagli
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

[Haddoq]

@RGJ

Dopo l’importazione, è sempre una buona idea per le prestazioni del database creare un backup e ripristinarlo nella stessa istanza.

Buona idea. Qualcosa che proverò.

[Haddoq]

Quindi il sito è diventato non reattivo.. (Eseguito backup.. ripristinato il backup e poi riavviato)

Utilizzo della RAM aumentato da 6 GB a 7 GB e sito non rispondente.

[Falco]

Ci sono quasi 5 GB utilizzati da Redis, il che lascia a Discourse poco margine di manovra, soprattutto considerando quanti unicorni stai eseguendo.

Se la tua coda sidekiq è pulita, prova a pulire Redis poiché potrebbe contenere troppa spazzatura dall’importazione:

./launcher enter app
redis-cli flushall

[Haddoq]

Capito, proverò il comando redis.
Il problema dei worker di unicorn è stato uno che ho controllato abbastanza presto. Ho modificato sia l’utilizzo della RAM per db_shared_buffers sia impostato i worker di unicorn a 3.
L’impostazione dei worker di unicorn sembra avere un effetto minimo o nullo sul numero di worker che vengono effettivamente eseguiti.

Dal mio file app.yml

  ## Quante richieste web concorrenti sono supportate? Dipende dalla memoria e dai core della CPU.
  ## verrà impostato automaticamente da bootstrap in base alle CPU rilevate, o puoi sovrascriverlo
  UNICORN_WORKERS: 3

[Haddoq]

@Falco

redis-cli flushall

Quel comando flushall ha fatto miracoli… sceso a 2 GB di utilizzo… vedremo se continuerà così.

La parte preoccupante era che le cose continuavano a crescere prima. Speriamo che questo permetta all’app di autogestirsi meglio.

Comunque… quindi l’importazione mantiene le cose permanentemente in redis? sembra strano ma non ho idea di come funzioni redis, quindi

Grazie mille per l’aiuto