D’accord, je peux comprendre cela. Ne serait-il pas possible de rationaliser le processus de démarrage/compilation pour qu’il prenne plus de temps (CPU/sérialisation) mais dans des ressources contraintes (c’est-à-dire la RAM) ?
1 « J'aime »
Je pense que ce serait une excellente idée. Et l’une des raisons est la suivante : si l’on ne peut pas reconstruire sur un petit serveur, alors on ne peut pas l’installer sur un petit serveur. Et si l’on installe sur un serveur de taille moyenne, on n’obtiendra pas le fichier d’échange créé qui sera nécessaire sur le petit serveur. (Idéalement, le script d’installation créerait le fichier d’échange de toute façon, et définirait également les deux paramètres du noyau qui devraient être définis.)
C’est aussi une excellente idée. De la même manière qu’idéalement un processus d’ingénierie logicielle surveille les temps de compilation, car sinon les temps de compilation s’allongent sans cesse, pour Discourse le processus testerait et surveillerait idéalement l’installabilité sur de petites instances. Faites-en un objectif.
1 « J'aime »
J’ai expérimenté la création d’images bootstrapées qui migrent et précompilent les actifs au lancement (avec des paramètres ENV pour sauter ces tâches). Cela fonctionne la plupart du temps (pas tellement pour les sites énormes et pour les choses qui dépendent du lancement pour se produire dans un certain laps de temps.
Ceux-ci dépendent cependant de l’existence de redis et de postgres.
Avec une installation à 2 conteneurs, la plupart du temps standard, il pourrait être possible de faire en sorte que cela fonctionne la plupart du temps.
Ooooooooooooooooooooooh, mais la précompilation des actifs est, je suppose, l’étape qui cause les problèmes. . .
Je lis à propos de cette mise à niveau Ember 5 qui progresse dans le système. Quel impact cela aurait-il sur les ressources de build ?
Je pense que la documentation a besoin d’une mise à jour, discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub
- La valeur par défaut de 1 Go de RAM convient aux petites communautés Discourse.
1 Go n’est plus une option. La configuration minimale requise est de 2 Go pour construire discourse.
1 « J'aime »
J’ai un tas de sites que j’ai récemment mis à niveau avec 1 Go de RAM. Je leur ai cependant augmenté leur swap à 3 ou 4 Go.
Je ne le recommande certainement pas, mais pour certaines personnes, c’est une énorme barrière de coût et elles s’en sortent. Mais peut-être que « fonctionne bien » est une exagération.
3 « J'aime »
Oui, peut-être préciser que 1 Go de RAM + 4 Go de swap. Il a échoué avec un swap de 2 Go.
Avez-vous des plugins ? Beaucoup de thèmes ?
9 plugins et un seul thème. Encore une fois, tout cela fonctionnait très bien jusqu’à la version 3.1.x avec 1 Go de RAM et 2 Go de swap (c’était un peu lent, peut-être 20 minutes pour reconstruire, mais cela a toujours fonctionné).
En essayant de passer à la version 3.2.0, cela a échoué de manière constante (voir ci-dessus).
Oui. Absolument aucun plugin avec 1 Go de RAM. Cela semble être quelque chose à ajouter à la documentation d’installation.
Je serais intéressé de savoir si cela a fonctionné sans les plugins.
En tant que raccourci extrême, je peux comprendre pourquoi vous diriez cela, mais ne pensez-vous pas que le critère de réussite pour exécuter Discourse est RAM + swap ? 1+3 est aussi bon que 2+2 d’un point de vue critère de réussite.
Seules les performances (réactivité) dépendent de la quantité de RAM dont vous disposez.
RAM+swap est la bonne chose à vérifier et à tester. Mémoire=RAM+swap.
Au fait, si quelque chose ne fonctionne pas sans raison évidente, et surtout si vous suspectez un manque de mémoire, il est utile de vérifier le tueur de mémoire insuffisante, également connu sous le nom de OOM-killer. Je recommande
dmesg|egrep -i "memory|oom|kill"
Edit : par souci de commodité, je vais ajouter cela à ma liste de diagnostics instantanés standard :
cat /etc/lsb-release
uptime
df -h /
free
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc
5 « J'aime »
J’ai rencontré le même problème, mais pas lors d’une mise à niveau, plutôt lors d’une nouvelle installation de la version 3.2.0.
J’utilise AWS EC2, tout comme @RBoy.
Je cherche une solution pour installer la version 3.1.5 au lieu de la 3.2.0, car l’ancien forum n’a apporté aucune aide.
MISE À JOUR :
Désolé, j’ai trouvé ceci :
1 « J'aime »
Je serais très intéressé de savoir si vous avez pu faire une nouvelle installation de la version 3.1.5 en utilisant la méthode de balise mentionnée dans votre lien. Merci de nous faire un retour si vous l’essayez.
Quant à l’installation de la version 3.2.0 sur un système de 1 Go, vous pourriez essayer ceci : réglez votre taille de SWAP à 8 Go et voyez si cela fonctionne. Cela sera probablement TRÈS LENT, mais cela pourrait fonctionner.
Merci pour vos précieux conseils.
J’ai récemment effectué une nouvelle installation de la version Docker de Discourse 3.15 et je voulais partager à quel point le processus a été simple, surtout pour ceux qui utilisent le niveau gratuit d’AWS EC2, comme moi.
Voici un guide concis basé sur mon expérience :
-
Accédez à votre fichier de configuration Discourse situé à
/var/discourse/containers/app.yml. -
Dans la section
params, mettez à jour le paramètreversionpour qu’il corresponde à la version souhaitée de Discourse. Par exemple :params: # ... ## Specify the Git revision for this container (default: tests-passed) version: v3.1.5 # Use the specific tag name here -
Enregistrez vos modifications et quittez l’éditeur. Ensuite, exécutez la commande suivante pour reconstruire votre application Discourse :
/var/discourse/launcher rebuild app
Le processus a fonctionné sans problème pour moi, prouvant qu’il est tout à fait possible de maintenir une installation Discourse à faible coût, voire sans budget.
J’espère que ce guide aidera d’autres personnes cherchant à gérer leurs installations Discourse de manière efficace et économique.
2 « J'aime »