Un autre mystère de Discourse

Je reçois une alerte AWS CloudWatch à 21h09 ET, ainsi que des amis qui m’envoient un SMS « Hé, est-ce que Discourse est en panne ? »

Je ne peux pas me connecter en SSH à l’instance AWS Lightsail, et toutes les métriques sont bloquées/ne rapportent rien.

Finalement, j’abandonne et j’arrête/redémarre l’instance Lightsail.
Le service est rétabli.

Je vérifie les journaux après le rétablissement du service, cherchant à comprendre.

Je fais fonctionner Discourse comme une instance unique, donc l’erreur à 21h05 concernant la connexion réseau Redis me laisse perplexe.

Je n’arrive pas à comprendre ce qui s’est passé, à part que « quelque chose » s’est bloqué/a échoué pour « une raison quelconque ».

Toute personne capable d’expliquer ou de laisser quelques pistes est appréciée.

Merci !

Quelles sont les spécifications du serveur ? On dirait qu’il manque de ressources ? Probablement le CPU. Y a-t-il une tâche quotidienne qui s’exécute à ce moment-là ?

Il s’agit d’une instance Lightsail de 1 vCPU, 1 Go de RAM et 40 Go de SSD.

Le stockage est consommé à environ 60 %, et lorsque je fais des nettoyages, il diminue considérablement.

AWS indique que je suis à court de crédits CPU bursting, ce qui est étrange car les autres métriques ne le confirment pas.

C’est une communauté assez petite (20-30 participants actifs), donc je serais surpris s’il y avait une réelle contrainte de CPU ou de RAM.

Aucune tâche quotidienne dont j’ai connaissance, à part quelque chose que Discourse pourrait planifier par défaut.

1 Go avec swap est le minimum absolu pour exécuter Discourse.

Depuis combien de temps cette instance est-elle active ? Quelle est la taille de la base de données ?

3 « J'aime »

Je vais vérifier la taille de la base de données, je ne m’attends pas à ce qu’elle soit volumineuse (les sauvegardes font environ 57 Mo).

Le temps de fonctionnement de l’instance n’est pas tout à fait de dix heures maintenant, car la récupération a nécessité l’arrêt et le redémarrage du serveur virtuel - je n’ai pas pu obtenir de connexion shell ou console.

Elle fonctionne bien sur ce type d’instance depuis que je l’ai construite (février 2021, à supposer).

Cela ressemble à ce qui se passe lorsque AWS déplace votre VM d’un hôte à un autre et la laisse dans un état étrange à cause de cela. Habituellement, un redémarrage résout le problème.

5 « J'aime »

La taille totale de la base de données est de 423 Mo.

Les plus grandes tables sont :
Posts 66 Mo
Post_timings 60 Mo

Deuxième échec similaire de « forte charge » survenu.

Je suppose qu’il s’agit d’une contention de ressources.

Quelqu’un a-t-il essayé d’utiliser l’instantané Lightsail pour créer un instantané de l’instance, puis de la restaurer sur une instance plus grande comme méthode de mise à niveau ?

Vous pouvez essayer de redémarrer l’instance AWS, cela peut résoudre de nombreux problèmes.

J’ai migré en utilisant un snapshot Lightsail d’une configuration 1 CPU, 1 Go de RAM, 40 Go SSD vers une configuration 2 CPU, 4 Go de RAM, 80 Go SSD.

Outre le détachement et le rattachement de l’adresse IP publique, ce qui a été assez simple, mes préoccupations restantes sont « qu’ai-je manqué » ?

Y a-t-il quelque chose (sauvegardes, e-mail, configuration du bucket S3, etc.) que je devrais vérifier ou dois-je réexécuter certains paramètres d’installation initiaux pour profiter des ressources améliorées ?

Je pense que, d’après ce lien, je pourrais augmenter le db_shared_buffer à au moins 1 Go.
L’application actuelle app.yml indique 128 Mo, et indique également un ajustement automatique au démarrage.

1 Go est suffisant pour un système de 4 Go. Assurez-vous également de mettre à jour unicorn_workers à 4.

La recommandation habituelle si vous passiez d’un serveur à un autre serait de réexécuter discourse-setup, ce qui s’occuperait automatiquement de ce qui précède.

1 « J'aime »

Merci. Je me plonge maintenant dans l’univers de Prometheus.

Bon travail.