Je teste Discourse comme destination possible pour notre forum existant et j’essaie de comprendre les exigences.
Actuellement, j’exécute le droplet Discourse sur un nœud Digitalocean avec 4 vCPU et 8 Go de RAM.
Avec le site vBulletin importé fonctionnant ici sans trafic ni activité, le système commence par utiliser environ 75 % de ces 8 Go de RAM et, au bout de quelques jours, monte à 100 % puis cesse complètement de répondre.
Cela me confond car le minimum requis semble être beaucoup moins que cela.
(J’ai reconstruit le conteneur, j’ai vérifié et effacé les tâches Sidekiq, l’utilisation est toujours élevée)
Quelqu’un a-t-il des conseils ou dois-je envisager une configuration avec beaucoup de RAM juste pour maintenir le forum en ligne ?
Le système peut être en train de refondre les publications et de redimensionner les images, ce qui peut consommer beaucoup de ressources même si vous n’avez pas d’utilisateurs. Vous pouvez consulter /sidekiq pour voir s’il y a beaucoup de tâches dans la file d’attente et/ou en cours d’exécution. De plus, htop peut vous donner quelques indices sur ce qui s’exécute.
L’importation a eu lieu il y a environ 5 semaines, et j’ai procédé à 5 reconstructions de l’application depuis, ce qui semble être la solution au problème de mémoire une fois que le conteneur devient complètement insensible à la mémoire.
J’ai vidé toutes les tâches dans Sidekiq comme mentionné, et l’utilisation est toujours à 75 %.
Le graphique de mémoire depuis que j’ai reconstruit le serveur hier :
Après l’importation, il est toujours conseillé pour les performances de la base de données de créer une sauvegarde et de la restaurer dans la même instance.
Ce graphique de mémoire inclut-il ou exclut-il le cache ? (c’est-à-dire, à quoi ressemble la sortie de free -m ?)
Il y a près de 5 Go utilisés par Redis, ce qui laisse peu de marge de manœuvre à Discourse, surtout si l’on considère le nombre de licornes que vous exécutez.
Si votre file d’attente sidekiq est vide, essayez de nettoyer Redis car il pourrait contenir trop de déchets provenant de l’importation :
Bien reçu, je vais essayer la commande redis.
Le problème des workers unicorn était l’un de ceux que j’avais vérifiés assez tôt. J’ai modifié l’utilisation de la RAM pour db_shared_buffers et j’ai également défini les workers unicorn à 3.
Le réglage des workers unicorn semble avoir peu ou pas d’effet sur le nombre de workers qui s’exécutent réellement.
Extrait de mon fichier app.yml
## Combien de requêtes web simultanées sont prises en charge ? Dépend de la mémoire et des cœurs CPU.
## sera défini automatiquement par bootstrap en fonction des CPU détectés, ou vous pouvez le remplacer
UNICORN_WORKERS: 3
Cette commande flushall a fait des merveilles… réduit à 2 Go utilisés… nous verrons si cela continue maintenant.
La partie inquiétante était que les choses continuaient de grossir avant. J’espère que cela permettra à l’application de mieux s’auto-gérer.
Quoi qu’il en soit… donc l’importation garde les choses de manière permanente dans redis ? cela semble étrange mais je n’ai aucune idée de comment fonctionne redis donc
