Je reconstruit l’image sur une instance Digital Ocean et quelque chose prend une éternité :
I, [2024-01-10T09:47:14.854311 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (492.75) is less than 2048MB. Setting --max-old-space-size=2048.
[WARN] (broccoli-terser-sourcemap) Minifying "assets/admin.js" took: 25461ms (more than 20,000ms)
[WARN] (broccoli-terser-sourcemap) Minifying "assets/plugins/chat.js" took: 47818ms (more than 20,000ms)
Purging temp files
Bundling assets
I, [2024-01-10T10:06:07.644096 #3264] INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js
L’instance a 1 Go de RAM et fonctionne par ailleurs très bien avec Discourse. Est-ce que je fais quelque chose de mal ? Puis-je faire quelque chose pour accélérer la reconstruction ? Merci !
Je pense que cela vous rendra très limité en mémoire maintenant.
On en arrive au point où je recommanderais un minimum de 4 Go pour une instance Discourse (plus du swap !) (même avec 2 Go + 2 Go de swap, je trouve les mises à jour en ligne douloureusement lentes).
Merci ! Malheureusement, c’est environ quatre fois le prix pour une amélioration que je ne ressentirais probablement que lors des mises à jour. De plus, le guide d’installation cloud indique toujours :
La valeur par défaut de 1 Go de RAM fonctionne bien pour les petites communautés Discourse. Nous recommandons 2 Go de RAM pour les communautés plus importantes.
Savons-nous d’où vient la pression sur la mémoire à cette étape ? Peut-être serait-il possible d’échanger un taux de compression moins bon ou autre chose contre des exigences de mémoire réduites ?
Je pense que pour ma prochaine mise à jour sur mes deux serveurs, j’utiliserai la flexibilité du fournisseur d’hébergement pour migrer vers une RAM plus importante avant la mise à jour, et je migrerai à nouveau vers mon minimum actuel immédiatement après. Il y a une petite période d’indisponibilité supplémentaire, mais si la reconstruction est beaucoup plus rapide, cela pourrait être un avantage global. La dépense supplémentaire devrait être inférieure à 1 ou peut-être même juste 1 centime, pour une heure de RAM supplémentaire (dans mon cas, de 6 par mois à 12 $ par mois, facturé à l’heure sur Digital Ocean respectivement à 1 centime et 2 cents.)
Comme indiqué dans le fil de discussion lié, un redémarrage est parfois utile dans tous les cas, c’est donc un bon moment pour mettre à jour les paquets du système d’exploitation et redémarrer, pour moi.
J’espère que cela causera moins d’usure pour moi aussi.
Je pourrais en fait choisir de passer de 1 Go à 8 Go, ce qui coûtera 6 cents supplémentaires par heure, pour me donner la liberté de supprimer temporairement mon fichier de swap et d’alléger la pression sur l’espace disque.
Tout atteint son maximum au moment de la mise à jour - entre-temps, la configuration minimale actuelle semble toujours adéquate.
Je peux certainement me permettre 6 cents par cycle de mise à niveau.
OK, mais toujours sur place. C’est une excellente option, mais oui, des tracas supplémentaires… et des temps d’arrêt.
Étant donné que le temps de reconstruction sur une machine de 1 Go prend tellement de temps que vous pourriez aussi bien faire cela, car elle sera en panne pendant 30 minutes de toute façon !
Et bien sûr, si vous êtes prêt à le faire, même une mise à niveau temporaire d’une machine de 16 Go pourrait s’avérer rentable
Je soupçonne que beaucoup considéreront leur temps comme plus précieux et devraient probablement commencer à penser à 4 Go + sur une base permanente.
C’est certainement une contrepartie entre le coût et le temps. Pour ma part, je me suis déjà engagé à faire une heure de babysitting pour les mises à niveau, et je sais parfaitement comment faire cette danse d’administrateur système, donc le temps est déjà réservé. Je préfère maintenir le coût d’exploitation mensuel aussi bas que possible, même si cela me prend du temps - d’autres feront d’autres compromis.
Bien sûr, si dépenser de l’argent est facile, prenez une instance confortablement grande !
Pour information, je viens de mettre à jour mes deux forums, tous deux terminés en moins d’une heure, dans les deux cas j’ai temporairement augmenté la RAM à 8 Go puis je l’ai ramenée. Cette étape particulière a pris environ 5 minutes, avec (temporairement) 4 CPU et 8 Go de RAM.
I, [2024-01-10T16:07:58.323464 #1] INFO -- : cd /var/www/discourse && su discourse -c 'bundle exec rake themes:update assets:precompile'
110:M 10 Jan 2024 16:08:52.047 * 100 changes in 300 seconds. Saving...
110:M 10 Jan 2024 16:08:52.048 * Background saving started by pid 3276
3276:C 10 Jan 2024 16:08:52.384 * DB saved on disk
3276:C 10 Jan 2024 16:08:52.386 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 0 MB
110:M 10 Jan 2024 16:08:52.449 * Background saving terminated with success
Purging temp files
Bundling assets
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
I, [2024-01-10T16:12:14.362017 #3300] INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js
Ici, on voit que ember (colonne 12) utilise 2,5 Go de RAM (colonne 6) et plus d’un CPU (colonne 3).
Probablement 4 Go de RAM auraient suffi pour moi, mais comme mentionné, tout cela n’a coûté que quelques centimes. (Je vois maintenant que j’aurais pu choisir des CPU plus rapides pour un centime de plus.)
Edit : J’ai fait une sauvegarde avant de commencer et une autre après la fin du travail, et elles étaient espacées de 35 minutes. Donc, le temps d’arrêt tel que vu par les utilisateurs n’a pas été plus long que cela.
Edit : notez que le panneau de contrôle Digital Ocean indique que l’opération de redimensionnement peut prendre jusqu’à 1 minute par Go de données sur le disque - dans mon cas seulement 14 Go et il s’est avéré seulement 2 minutes pour chaque redimensionnement. Mais si vous avez beaucoup de données sur l’instance, cette danse de redimensionnement pourrait prendre plus de temps. (Encore une fois, si vous avez beaucoup de données, vous n’essayez peut-être pas de fonctionner avec moins de 4 Go de RAM)
4 Go de RAM ne suffisent toujours pas dans certains cas. Par exemple, j’ai un bac à sable avec 8 Go de RAM et pratiquement aucun trafic, mais il s’agit d’une configuration multisite pour permettre d’avoir 5 bacs à sable jetables. La reconstruction aujourd’hui a échoué en raison de l’erreur 137 (OOM) et j’avais essayé l’astuce suggérée par @richard ci-dessus. Cependant, pour m’éviter les tracas de devoir faire cela à chaque fois, j’ai créé un swap plus important (4 Go) qui semble avoir permis les reconstructions pour le moment. Il semble que nous ne faisons qu’améliorer les serveurs au cours de la dernière année, car les reconstructions de Discourse consomment vraiment beaucoup de RAM pour une raison quelconque.
(Il est toujours utile d’avoir de l’espace disque libre pour le swap, 2G, 4G ou ce que l’espace disque disponible permet. J’ai un swap minimal car j’ai un espace disque minimal.)
En y réfléchissant, l’avantage est vraiment limité aux reconstructions complètes - je ne peux pas actuellement utiliser les mises à niveau en ligne dans une configuration 2+2 … et je ne pense pas que je vais faire cette danse de mise à niveau/rétrogradation juste pour mettre à jour, par exemple, un seul plugin …
Je pense personnellement qu’une mise à niveau permanente à au moins 4 Go est la seule solution …
Remarque : Je ne me plains pas vraiment d’avoir à évoluer avec son temps … mais nous devrions peut-être commencer à refléter la réalité dans la documentation et les conseils aux administrateurs ?
Cela rend malheureusement Discourse un peu moins accessible aux nouveaux venus, en particulier aux plus jeunes
Je suis en fait d’accord avec cette idée : garder la configuration minimale recommandée actuelle comme cible et examiner les ajustements dans le code ou les changements en amont pour maîtriser les choses. C’est un changement majeur dans l’offre si la configuration minimale coûte maintenant deux fois plus cher. C’est pourquoi j’ai dit ailleurs que des exigences excessives en matière de mémoire sont un bug.
En effet, il s’agit d’une erreur de manque de mémoire. Si vous avez suffisamment d’espace disque pour ajouter du swap, cela suffira, bien que le processus prenne plus de temps que si vous ajoutiez de la RAM. Votre fournisseur d’hébergement pourrait offrir la possibilité d’augmenter temporairement la RAM, puis de la rétablir, ce qui vous coûtera probablement quelques redémarrages, un peu de temps d’arrêt et quelques centimes de coût supplémentaire.
Edit : pour être clair, mémoire = RAM + swap. La RAM est rapide et le swap est bon marché.
… et je ne pense pas que je vais faire cette danse de mise à niveau/rétrogradation juste pour mettre à jour, par exemple, un seul plugin …