I, [2024-04-17T09:57:04.110084 #1] INFO -- : > cd /var/www/discourse & su discourse -c 'bundle exec rake assets:precompile:build'
97:M 17 Apr 2024 10:01:01.012 * 100 changes in 300 seconds. Saving...
97:M 17 Apr 2024 10:01:01.012 * Background saving started by pid 3733
3733:C 17 Apr 2024 10:01:01.026 * DB saved on disk
3733:C 17 Apr 2024 10:01:01.027 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 0 MB
97:M 17 Apr 2024 10:01:01.112 * Background saving terminated with success
97:M 17 Apr 2024 10:56:01.848 * Replication backlog freed after 3600 seconds without connected replicas.
Le serveur a 64 Go de mémoire, donc je ne pense pas que ce soit un problème de mémoire, bien que dans le conteneur j’aie spécifié db_shared_buffers: "4096MB" conformément aux recommandations de configuration.
Des idées sur ce qui se passe ? Comment dépanner ? Corriger ?
Merci Jay, j’ai attendu deux heures et j’ai fait ça (c’est un forum archivé donc je ne me souciais pas trop du temps d’arrêt).
La seule chose que j’ai faite différemment, c’est que j’avais ajouté - git clone https://github.com/discourse/discourse-calendar mais j’ai remarqué que c’était sans le .git à la fin - je ne sais pas si cela a fait une différence cependant.
Depuis ce problème, nous rencontrons maintenant des problèmes avec le serveur. Lorsque cela s’est produit pour la première fois, nous avons remarqué que d’autres sites Ruby sur le serveur n’étaient pas accessibles. Cela s’est produit deux fois à plusieurs jours d’intervalle et un redémarrage a résolu le problème (ces sites utilisent l’authentification Discourse). Cela s’est reproduit, mais cette fois, deux des forums Discourse recevaient également une erreur 504 Gateway Time-out.
J’ai remarqué que d’autres avaient eu un problème similaire de reconstruction bloquée et je me demande si quelque chose a changé récemment dans Discourse qui pourrait être lié à cela ? Discourse modifie-t-il quelque chose en dehors des conteneurs, comme le Ruby système peut-être ? C’est très étrange
Hier, il y a eu une correction qui permet aux serveurs à faible quantité de RAM de reconstruire beaucoup plus bizarrement/rapidement, mais je pense que cela pourrait ne pas fonctionner car il teste pour 2 Go et votre problème est probablement que vous avez plus de 2 Go mais qu’ils sont tous occupés par d’autres choses sur le serveur.
Je suppose simplement que vous avez besoin de plus de RAM.
Le serveur dispose de 64 Go de RAM Jay, et chaque instance DC est configurée avec db_shared_buffers: \"4096MB\".
De plus, ces problèmes supplémentaires n’ont pas été rencontrés lors de la reconstruction, mais semblent être des restes du problème initial.
Je vais nettoyer docker ./launcher cleanup pour voir si cela aide, mais si vous ou quelqu’un d’autre avez d’autres idées en attendant, ce sera grandement apprécié.
