Le VPS que nous venons d’acheter est livré avec 3 Go de RAM + 1 Go de partition swap - dois-je également configurer un fichier swap, ou cela devrait-il suffire ?
C’est suffisant pour une petite instance Discourse.
Je veux dire, pas en termes de rapidité d’exécution, etc., mais en termes de génération ou non d’erreurs, comme par exemple l’impossibilité d’allouer de la mémoire supplémentaire, etc. Ma question a-t-elle un sens ? De plus, ajouter un fichier d’échange avec une priorité encore plus basse aiderait-il ? Juste pour être sûr.
Payez simplement pour un VPS plus puissant avec au moins 8 Go de RAM. Vous perdrez votre temps sinon.
Cela ne répond pas à ma question.
Je n’arrive pas à imaginer faire tourner Discourse avec moins de 8 Go de RAM.
Un membre de l’équipe Discourse dit que c’est bon, je suis sûr que c’est bon.
Bonne chance.
Discourse-setup signalera tout problème de mémoire.
Cela ne répond pas non plus à ma question. Peut-être ai-je mal formulé ma question ?
J’ai un forum relativement calme sur une instance Digital Ocean de 2 Go de mémoire/50 Go de disque et cela fonctionne bien.
À l’époque, le guide d’installation de Discourse recommandait un minimum de 1 Go, mais j’ai mis à niveau à un moment donné.
Si vous fournissez plus d’informations sur la taille/l’activité de votre forum, je suis sûr que vous obtiendrez une réponse plus détaillée.
Je pense que l’installateur de Discourse configure automatiquement un fichier de swap (je n’ai rien fait manuellement) - donc cela répond en partie à votre question, je pense.
Je pense qu’il crée un fichier de 2 Go lors de l’installation s’il détecte que vous n’en avez pas déjà un.
Modification : Je pense que c’est plus exact :
La configuration minimale officiellement prise en charge est de 1 Go de RAM + 2 Go de swap - et cela suffit, si vous avez un forum assez petit. Cependant, chaque mise à jour devient un peu plus volumineuse, donc je m’attends à ce qu’il y ait un moment où cela ne suffira plus.
Pour que le forum fonctionne correctement et ne plante pas, la somme totale de la RAM et du swap est le chiffre important.
Pour que le forum soit réactif et ne soit pas trop lent, plus de RAM est préférable. Donc, si 1 Go de RAM + 2 Go de swap suffisent, alors 3 Go de RAM + 1 Go de swap suffiront, et pourraient offrir de meilleures performances.
J’ai deux forums, tous deux assez petits, l’un fonctionne avec 1+2 et l’autre avec 2+2.
L’année dernière, j’ai écrit ceci :
Modification : si vous avez de l’espace disque pour ajouter du swap, faites-le - il n’y a aucune bonne raison de ne pas le faire, et cela pourrait être nécessaire. La commande free vous indiquera la quantité utilisée, la commande vmstat peut vous donner un commentaire en continu. Mais l’utilisation moyenne n’est pas intéressante - c’est l’utilisation maximale qui est intéressante.
Ok, ma question est plus théorique. Je ne peux pas prédire la popularité du forum pour le moment. Ce que j’essaie de comprendre, c’est ce que je devrais faire pour atténuer la possibilité théorique de manquer de RAM dans certains scénarios. Je ne sais pas quand Discourse consomme le plus de mémoire - que ce soit lors de la création de sauvegardes, du redimensionnement d’images, des mises à jour via la console d’administration, ou… Je n’en ai aucune idée.
Donc, mon idée était, quel fichier d’échange devrais-je créer pour m’assurer que Discourse ne plante pas mais devienne juste très lent s’il n’y a pas assez de mémoire. Dans le même temps, j’ai découvert qu’il existe déjà une partition d’échange de 1G, donc ma pensée était, que se passe-t-il si 3G de mémoire réelle + 1G de swap de partition ne suffisent pas… devrais-je également créer un fichier d’échange de quelques gigaoctets avec une priorité encore plus faible (par rapport au gigaoctet de partition). J’espère que ma question a plus de sens maintenant.
S’il le fait, alors oui. Il serait utile de mettre à jour le fichier README d’installation. Venant des anciens jours où il était officiellement mentionné de créer un fichier d’échange directement dans le README d’installation, je suis maintenant un peu confus quant à savoir si cela est fait automatiquement, ou si ce n’est plus nécessaire, ou pour toute autre raison pour laquelle il a été retiré du guide officiel.
… qu’en est-il s’il détecte celui de 1G mais celui basé sur une partition ?
Donc, la suite de ma question serait, est-ce une bonne idée d’avoir deux zones de swap, l’une basée sur une partition et l’autre basée sur un fichier.
Aucun problème à avoir plusieurs zones de swap (ou plusieurs fichiers de swap)\n\nJe pense que le pic de mémoire le plus important se produit lors d’une mise à niveau - et le risque est que le forum soit indisponible jusqu’à ce que vous puissiez obtenir de l’aide.\n\nIl est également utile de régler le surallocation (overcommit) sur un paramètre plus généreux : vous constaterez qu’il est déjà noté dans votre journal de mise à niveau, si vous ne l’avez pas encore ajusté\n\u003e ATTENTION : overcommit_memory est défini sur 0 ! La sauvegarde en arrière-plan peut échouer dans des conditions de faible mémoire. Pour résoudre ce problème, ajoutez ‘vm.overcommit_memory = 1’ à /etc/sysctl.conf, puis redémarrez ou exécutez la commande ‘sysctl vm.overcommit_memory=1’ pour que cela prenne effet.\n\nCela a été mentionné de nombreuses fois auparavant, mais il y a une résistance à l’ajouter à la recette d’installation standard de Discourse. C’est le genre de paramètre qui ne peut pas être fait à l’intérieur de l’image docker mais qui doit être fait sur l’hôte.
Tout ce que vous pouvez faire est de réduire les risques, et si vous avez plus de fonds, vous pouvez réduire les risques à un plus grand degré. Cette question relève du domaine des compromis !
Si j’avais un disque illimité, j’ajouterais certainement jusqu’à 4G d’espace d’échange avant même d’y penser - cela ne ferait aucun mal. Si j’avais des fonds illimités, j’aurais le maximum de RAM que je pourrais obtenir. Mais dans mon cas, ce n’est pas le cas.
Si vous vous attendez à ce que votre forum puisse croître, vous devriez vous attendre à augmenter les ressources dont vous avez besoin pour le faire fonctionner, au fil du temps, plutôt que de vous attendre à dimensionner la machine une fois au départ.
Je n’ai pas encore augmenté la taille des machines que j’utilise pour mes forums, mais je m’attends à le faire, peut-être cette année ou peut-être l’année prochaine.
Ça devrait l’être. Je configure régulièrement des droplets de 1 et 2 Go avec 2 Go de swap et ils fonctionnent. Actuellement, une reconstruction consomme beaucoup de RAM, mais cela devrait fonctionner.
Il faut avoir plus d’imagination.
Je n’en utilise autant que sur des sites avec environ un million de pages vues par mois et des bases de données assez volumineuses.
J’ai mentionné cela dès la première installation de Discourse (Warnings: overcommit_memory and Transparent Huge Pages). Pourquoi est-ce utile et quelle est la raison de cette résistance ? Je n’ai pas modifié le réglage par défaut.
Voici quelque chose que j’ai écrit précédemment :
En particulier
Tel quel, le noyau rejettera les allocations qu’il ne peut satisfaire. Avec ce réglage, il acceptera ces allocations, et l’échec pourrait être évité, ou il pourrait se produire plus tard, lorsque l’allocation deviendra une utilisation.
Si votre total de RAM et de swap est suffisamment important, vous n’aurez jamais besoin de modifier ce paramètre. S’il n’est pas important, le modifier pourrait aider.
Aussi
Il s’agit d’augmenter la quantité de mémoire virtuelle disponible. (C’est-à-dire la somme de la RAM et du swap.) Si vous manquez de RAM, vous commencez à avoir des problèmes de performance. Mais si vous manquez de mémoire virtuelle, les processus ne parviennent pas à démarrer, meurent ou sont tués. C’est brutal.
Ceux d’entre nous qui ont à la fois peu de RAM et peu de disque ne sont peut-être pas libres d’ajouter beaucoup de swap, mais 2G semble être un minimum décent. (Si vous aviez 16G de RAM, vous n’auriez peut-être pas besoin de swap, mais c’est une autre histoire. C’est la somme des deux qui compte, lorsque le problème est que les choses échouent.)
Quant à la résistance, je pense que c’est dû à la perception que ce changement est au bénéfice de redis, et que la plupart des gens n’en auront pas besoin.
Modification : ce fil récent est peut-être un exemple, où une petite instance a manqué de mémoire et n’avait pas l’option overcommit activée. Mais nous ne savons pas si l’activation de l’overcommit aurait résolu ce problème - la personne a mis à niveau vers 8G de RAM.
