Je vous remercie, mais la reconstruction de l’application prend environ 3 heures !
Et ce, sur un VPS massif.
Ne serait-il pas intéressant de pouvoir supprimer des plugins tout comme nous pouvons ajouter et supprimer des thèmes ?
Peut-être quelque chose à considérer comme une fonctionnalité à l’avenir ?
Merci !!
Pardon ?! Cela devrait prendre environ 20 minutes ?!
pas ici
L’installation d’origine a pris 2 heures.
Maintenant, le ./launcher rebuild app est parti comme ceci :
Ensuring launcher is up to date
Fetching origin
Updating Launcher...
Updating eeefdde..30be122
Fast-forward
image/base/install-imagemagick | 5 ++++-
launcher | 2 +-
templates/web.letsencrypt.ssl.template.yml | 2 +-
templates/web.template.yml | 6 +++---
4 files changed, 9 insertions(+), 6 deletions(-)
Launcher updated, restarting...
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
Stopping old container
+ /usr/bin/docker stop -t 60 app
app
Unable to find image 'discourse/base:2.0.20220818-0047' locally
2.0.20220818-0047: Pulling from discourse/base
1efc276f4ff9: Pulling fs layer
1b880e64942b: Pulling fs layer
794f6dc9a2ff: Pulling fs layer
1efc276f4ff9: Verifying Checksum
1efc276f4ff9: Download complete
1efc276f4ff9: Pull complete
794f6dc9a2ff: Verifying Checksum
794f6dc9a2ff: Download complete
1b880e64942b: Verifying Checksum
1b880e64942b: Download complete
1b880e64942b: Pull complete
794f6dc9a2ff: Pull complete
Digest: sha256:7734701087766821ffb2ddcef423754798bd345c2ac0d550131c6e6905c268e8
Status: Downloaded newer image for discourse/base:2.0.20220818-0047
Et après la dernière ligne, ça continue de clignoter (le processus est en cours)
Ça fait environ 30 minutes maintenant.
La dernière fois que j’ai fait ça, ça a pris 160 minutes complètes.
Mémoire totale du serveur : 4.657GiB, Version du noyau : 5.15.0-43-generic, Système d’exploitation : Ubuntu 22.04 LTS, disque SSD de 50 Go, 2.5 cœurs, 5 threads Intel® Xeon® CPUs
…
Je ne suis pas sûr de ce qui pourrait clocher, à part le fait que ça prend très longtemps 
3 heures, c’est très long. Vous devez enquêter sur ce problème et le résoudre en priorité.
Il y a des « pauses visuelles » dans le journal de build, c’est normal, mais ce délai ne l’est pas.
Mon intuition est que vous commencez à utiliser le swap pendant la compilation, mais je ne suis pas un SA. Exécutez-vous autre chose sur cette machine ?
Les téléchargements nécessitent la décompression, ce qui est coûteux en calcul, mais ce sont les mêmes images pour tout le monde.
À titre de référence, je viens de reconstruire un site maintenant et cela a pris 13 minutes et 46 secondes sur une machine de 2 Go et 2 vCPU sur https://scaleway.com.
Non, il s’agit d’un VPS qui est uniquement destiné à cette instance Discourse. Et j’utilise de nombreux autres VPS avec la même société, qui fonctionnent tous très bien (mais ce ne sont pas des instances Discourse, ce sont d’autres applications telles que des instances CMS PHP personnalisées ou WP/CP, etc.).
Je ne suis au courant d’aucune utilisation de swap, et je ne vois aucune pointe d’utilisation des ressources qui justifierait même cela.
Maintenant, il est à building.... - cela semble un peu plus rapide que la dernière fois, pourtant, cela prend toujours clairement plus de 20 minutes.
Je vais demander aux fournisseurs de serveurs s’ils peuvent repérer quelque chose d’inhabituel de leur côté, cependant, je me souviens qu’ils m’ont personnellement dit que leur propre instance Discourse avait également mis environ 2 heures à se construire. (PS Ces VPS sont sur des machines Hetzner louées via un tiers, je doute de pouvoir obtenir mieux.)
Dans tous les cas, ma suggestion reste qu’il serait formidable de pouvoir ajouter et supprimer des plugins comme nous pouvons le faire avec les thèmes. Peut-être est-ce quelque chose à considérer ?
Je ne sais vraiment rien, mais à ma connaissance, ce n’est pas possible, car Discourse est constitué de nombreux scripts compilés. Lorsqu’il est nécessaire d’ajouter ou de supprimer quelque chose qui modifie le fonctionnement du cœur, il faut reconstruire.
C’est très similaire à la situation avec Varnish, par exemple.
Ok…
Au fait, j’ai vérifié avec les équipes serveur et en effet, nous avons atteint 100% de mémoire.
5 Go ??? 5 Go de RAM, c’est un peu beaucoup à consommer pour quoi que ce soit.
Les exigences de Discourse indiquent qu’il a besoin de 1 Go de RAM !
Et il est maintenant bloqué sur ceci :
104:M 04 Oct 2022 07:19:27.251 # Redis est maintenant prêt à quitter, au revoir...
sha256:662695076506add39a630c2169b8b618f0121386951e93c6ffd2a6473107ae55
f4a95a1e69d5375e6ea30dfb22576209d249e5bc67b04a6fa09df289b1441888
Suppression de l'ancien conteneur
+ /usr/bin/docker rm app
app
Ainsi, je ne peux même pas mettre à niveau le serveur car le processus serait interrompu.
Vraiment, je ne pense pas que ce soit un problème de serveur du tout. Si nous avons besoin de 1 Go, alors 5 Go devraient être plus que suffisants.
Quelque chose ne va pas avec ça, terriblement mal.
Je comprends que d’autres doivent avoir une meilleure expérience (en regardant @merefield qui a dit de mettre à niveau sur un 2 Go…) pourtant, cela ne fonctionne pas pour nous comme il se doit.
Quoi qu’il en soit, c’est hors sujet pour ce fil de discussion, je suppose.
J’ai juste reconstruit un autre site, 4 Go, 3 vCPU, encore une fois en moins de 15 minutes (c’est-à-dire que la mémoire/CPU supplémentaire n’a pas vraiment aidé beaucoup dans mon cas, mais toujours loin d’heures !).
La seule chose que je viens de remarquer est que mon VPS utilise vfs au lieu de aufs ou overlay suggérés.
Pourtant, selon ceci Can't run ./launcher rebuild app - Docker storage driver is unsupported - #45 by david, cela ne devrait pas être important, et donc nous exécutons le lanceur avec --skip-prereqs, car sinon nous ne pouvons même pas exécuter Discourse.
Je me demande s’il y a plus à cette exigence de pilote de stockage.
C’est un peu… trop optimiste. À des fins de test, cela peut suffire, et même être un peu juste. 2 Go est beaucoup plus proche de la réalité.
4 Go suffisent pour des instances plus importantes, cependant. Mais le nombre et la puissance des cœurs jouent également un rôle important.
Et quand même… si vous avez 5 Go et que la reconstruction prend autant de temps, il doit y avoir quelque chose qui ne va pas.
Je suis sur DigitalOcean/4 Go/2 vCPU Intel et la reconstruction prend environ 25 minutes.
Quel est votre système exactement, plus app.yml — y a-t-il quelque chose de personnalisé ?
Salut, la seule personnalisation est celle que j’ai mentionnée précédemment (vfs au lieu de aufs/overlay).
Le reste est standard.
Serveur :
Mémoire totale du serveur : 4,657 Gio, version du noyau : 5.15.0-43-generic, système d’exploitation : Ubuntu 22.04 LTS, disque SSD de 50 Go, 2,5 cœurs, 5 threads Intel® Xeon® CPUs
Le yaml est original à part ces plugins supplémentaires :
discourse-assign
discourse-chat
discourse-checklist
discourse-docs
discourse-reactions
discourse-solved
discourse-surveys
discourse-voting
docker_manager
styleguide
Je ne vois pas dans ces données pourquoi la reconstruction prendrait autant de temps.
Je louerais un VPS Ubuntu de même taille ailleurs. Juste pour voir si le problème vient de la société d’hébergement. Cela vous coûtera quelques dollars et une heure ou deux de travail.
Beaucoup de mémoire est nécessaire pour précompiler le javascript. Essayez d’ajouter du swap.
La superposition
Je pense que ce test est peut-être là pour une raison. Cela pourrait être votre problème.
Pourquoi 5 Go de RAM avec Discourse vanilla auraient-ils besoin de plus de swap si des configurations plus petites sont totalement satisfaites de ce qu’elles obtiennent automatiquement ?
Parce que c’est plus facile que de faire ce que vous devez vraiment faire.
L’ajout de swap pourrait aider, mais ce n’est pas votre plus gros problème.
Je suppose que j’aurais dû essayer ceci avant de déployer le conteneur discourse : How to change the Docker storage driver – Webdock
Apparemment, il est possible de changer le pilote de stockage - contrairement à ce que l’hôte m’a dit à l’époque où nous avons déployé le conteneur (qui était soit de modifier le fichier du chargeur, soit d’ignorer la vérification)
Duh, maintenant il est trop tard, je suppose.
Merci quand même, si c’est la cause des problèmes, je suppose que c’est de ma faute. Mea culpa 
Je ne pense pas.
De plus, la configuration à deux conteneurs a réduit le temps d’arrêt puisque vous reconstruisez le nouveau conteneur web par CSV pendant que l’ancien continue de fonctionner.
Quelle est la taille de votre site ? J’ajouterais une permutation quoi qu’il en soit pour résoudre le problème de mémoire.
Une instance vierge de 1 Go avec 1 Go de permutation fonctionne bien pour une petite communauté de test, mais dès qu’elle grandit, cela ne suffira pas. La permutation fait absolument une différence.
Si la reconstruction sur un VPS « massif », situé dans un centre de données avec une connexion Internet rapide, prend 3 heures, et que la reconstruction de mon installation sur https://discourse-on-a-pi.falco.dev, qui fonctionne sur une carte de la taille d’une carte de crédit sur mon bureau, connectée à Internet via un plan domestique standard dans un pays du tiers monde, prend seulement 14 minutes (+4 minutes lorsqu’il y a une nouvelle image de conteneur), il y a quelque chose qui ne va pas dans le produit qu’ils vous vendent…
Quelle est l’utilisation de la mémoire sur le serveur ? Si vous êtes à capacité maximale ou proche de celle-ci avant de commencer la reconstruction, vous aurez beaucoup d’échange de mémoire (swapping) et cela rendra certainement tout excessivement long.
Si c’est le cas, je vous suggérerais de désactiver temporairement tout ce qui pourrait s’exécuter sur le serveur, si possible.