J’ai fait une série de mises à niveau et j’ai décidé que le moyen le plus simple de résoudre les erreurs de mémoire était de doubler le swap à 4 Go. L’inconvénient est que sur une gouttelette de 1 Go, il n’y a que 25 Go de SSD, donc en perdre 4 pour le swap représente une quantité d’espace importante, et c’est déjà un peu juste avec seulement 25 Go.
Alors, devrions-nous modifier discourse-setup pour que la valeur par défaut soit de 3 Go ?
Qu’en penses-tu, @Falco ?
Si cela résout le problème, je suis tout à fait pour.
Puis-je suggérer fortement que le script d’installation définisse également les deux paramètres du noyau qui affectent la gestion de la mémoire ? Il serait bon de savoir que tous ceux qui ont apparemment un problème ont au moins un point de départ de bonne configuration du noyau.
Cela me semble une idée sensée. Je n’arrive pas à imaginer où les THP pourraient être utiles sur une instance de discourse dédiée, et le sur-allocation peut aider à éviter les OOM.
On pourrait envisager de proposer de faire chacune de ces choses séparément, en les définissant comme réponse par défaut, avec l’option non-défaut de se désengager ?
De plus, le script peut utiliser sysctl pour savoir si les paramètres doivent être modifiés en premier lieu avant d’apporter une modification. Si quelqu’un a déjà apporté ces modifications avec des fichiers différents, il serait potentiellement déroutant de créer des remplacements en double. Je pense que toutes les distributions Linux n’expédient pas avec la sur-allocation de mémoire désactivée en premier lieu.
if $(sysctl -n vm.overcommit_memory) != 1 ; then
....
fi
Au risque de diluer le message important sur les paramètres du noyau, il y a une deuxième considération : le script actuel ne crée un espace d’échange que sur une machine à faible quantité de RAM. Je pense que c’est une erreur, à la fois parce que l’espace d’échange est toujours utile pour maximiser l’utilité de la RAM, mais plus important encore, parce qu’il causera des problèmes si quelqu’un crée son Discourse sur une machine à grande quantité de RAM, pour des raisons de vitesse ou de commodité, puis la réduit à une petite quantité de RAM.
La configuration devrait créer un espace d’échange dans tous les cas (sauf s’il y en a déjà suffisamment.) Il est valide et parfois utile d’avoir plusieurs fichiers d’échange.
Je ne suis pas celui qui décide, et je les définis sur les machines que je configure, mais il s’agit d’un script shell qui est exécuté par (la plupart) tous ceux qui installent Discourse. Il doit être aussi simple que possible, et sommes-nous sûrs que ces paramètres fonctionnent sur Raspberry Pi et Mac et tout autre non-sens que les gens essaient de faire ? Et la méthode que vous utilisez pour vérifier s’il est déjà défini fonctionne sur toutes ces plateformes ? Cela semble difficile.
J’ai écrit discourse-setup et je trouve que faire des changements est un peu effrayant.
Offrir toujours de créer un swap n’est pas une mauvaise idée. Peut-être offrir toujours de configurer 3 ou 4 Go de swap ? Mais alors, combien ? Une règle empirique que je connaissais était d’avoir un swap de la même taille que la RAM. Et pour l’instant, si vous ne créez pas de swap, votre seule option est d’interrompre avec control-c. Donc, soit nous allons forcer les gens à créer un swap, soit ajouter une autre question Oui/Non (ce qui me fera modifier mes scripts qui exécutent discourse-setup :pleurer_chat_visage:) Oh ! Ou nous pouvons le contrôler avec un commutateur --skip-swap. Cela me semble bien. Si vous êtes assez intelligent pour connaître le swap, vous trouverez le commutateur pour l’ignorer ; nous pouvons ajouter une note sur le commutateur dans ce message d’AVERTISSEMENT.
Et peut-être ajouter également une note sur --skip-connection-test lorsqu’il échoue.
Je pense que s’ils ont déjà configuré un swap, il est sûr de supposer qu’ils savent ce qu’ils font.
Merci ! Et oui, parfaitement compris, je ressentirais la même chose. Cela nécessite une réflexion et des tests approfondis, à coup sûr. Et ce serait sur au moins quelques machines bon marché de fournisseurs d’hébergement, et aussi sur Raspberry Pi. Je ne suis pas sûr pour Windows ou Mac - s’ils sont censés être pris en charge, alors je suppose que oui. Je m’attendrais plutôt à ce qu’ils soient utilisés comme machines de développement, ce qui est une autre histoire.
En effet. Autant que nécessaire à l’heure actuelle, peut-être. Cela semble avoir franchi une étape. Mais cela me chagrine beaucoup de ne pas savoir si ces rapports incluent ou non le réglage de l’overcommit. Je suis à peu près sûr que nous savons, d’après des discussions précédentes, que l’overcommit fait une différence.
Et nous savons que sur une instance de 25 Go et encore plus sur une instance de 20 Go, l’espace disque est limité. Je fonctionne sur de telles machines : 25 Go de disque et 1 Go de RAM, ce qui nécessite déjà 2 Go de swap et probablement plus ces jours-ci ; et 20 Go de disque avec 2 Go de RAM où j’ai actuellement 1 Go de swap.
Je ne recommanderais pas plus de questions OUI/NON. Les options de ligne de commande semblent être une meilleure voie.
Si nous devons modifier ce script, je recommanderais plusieurs swapfiles de 1 Go, car cela maximise la flexibilité, ne gaspille rien et c’est le moment le plus facile pour prendre cette décision.
Je ne suis pas si sûr de cela. Si la plus petite instance avec Ubuntu ou Debian nu, a déjà un peu de swap - cela devrait être vérifié - alors nous commençons à avoir des problèmes s’il n’y en a pas assez. Il vaut beaucoup mieux mesurer la RAM+swap en utilisant free, ajuster comme d’habitude pour les configurations inférieures à 1 Go (AWS je pense, peut-être Oracle), puis ajouter des swapfiles de 1 Go jusqu’à un certain nombre convenu, quel qu’il soit actuellement. J’espère que 4 Go au total suffiront, avec le paramètre d’overcommit du noyau correctement réglé.
Je suis heureux d’aider.
Hmm. Ouais. J’aurais aimé penser à vérifier cela sur ceux que je viens de régler.
Hmm. Je suis d’avis qu’un est mieux, mais plusieurs ajoutent de la flexibilité et il serait alors possible de faire en sorte que discourse-setup ajoute un autre fichier swap si plus de swap est nécessaire, ce qui signifie que nous pourrions dire à tout le monde d’exécuter discourse-setup pour “résoudre” leur problème de swap. Et peut-être aussi le problème de surallocation - peut-être essayer explicitement de le faire uniquement pour Linux, puisque c’est tout ce qui nous intéresse.
Je ne suis pas d’accord. Le swap n’est pas un bien universel. Il était important pour rendre le code VM plus uniforme dans certaines circonstances, mais les algorithmes VM ont changé.
Cela était basé sur des heuristiques de code noyau très anciennes qui ne s’appliquent plus.
De plus, lorsque l’on considère la mesure : je ne sais même pas ce que vous voudriez faire pour mesurer le swap et la mémoire lorsque zswap est utilisé. C’est probablement un cas de « d’abord, ne pas nuire » cependant.
Je suis à peu près certain que le seul inconvénient d’avoir « trop de swap » est d’utiliser plus d’espace disque que nécessaire. C’est une raison pour laquelle il serait préférable d’avoir plusieurs fichiers swap de taille modeste : on peut les désactiver et les supprimer progressivement, s’il faut récupérer de l’espace disque. De plus, je pense que Linux fait un travail raisonnable pour les utiliser progressivement :
NAME TYPE SIZE USED PRIO
/var/local/swap/swapfile.1 file 1024M 863.6M -2
/var/local/swap/swapfile.0 file 1024M 4.6M -3
La situation dans laquelle nous nous trouvons est que les instances bon marché sont très limitées en RAM et en espace disque, et Discourse en utilise de plus en plus, à mesure que les nombreux packages qu’il contient évoluent. Mais quand même, je pense qu’il existe des moyens de naviguer dans cela judicieusement, pour aider ceux qui ne sont pas en mesure de simplement lever les mains au ciel et de doubler ou quadrupler leur facture mensuelle.
L’échange est suffisamment lent pour que je ne considère pas « presque plus de place » comme une raison d’ajouter plus de 1 Go à la suggestion par défaut à ce stade. Chaque Go est beaucoup d’échange, comme on l’a expérimenté sur une instance Discourse dédiée.
Oui, par défaut, Linux utilise l’échange par ordre de priorité, et il est possible d’utiliser la même priorité sur plusieurs périphériques pour explicitement répartir l’échange. Mais ajouter beaucoup d’échange pour de petits sites n’est pas particulièrement utile, je suggérerais.
Donc, si après une décennie, les gens ne rencontrent que rarement 2 Go, je suggérerais de passer à 3 Go plutôt qu’à 4 Go par défaut. Et la quantité d’échange nécessaire pour une instance Discourse dédiée ne devrait pas augmenter particulièrement avec la mémoire, car le contenu qui serait effectivement échangé ne change pas particulièrement beaucoup.
L’idée de faire croître l’échange avec plus de mémoire provient principalement de l’informatique à usage général, basée sur une hypothèse généralisée selon laquelle plus vous avez besoin de RAM, plus la demande est susceptible d’être importante. Mais la pression d’échange sur une instance Discourse spécialisée ne suivra probablement pas ce schéma, je pense.
THP sont spécifiques aux plates-formes prenant en charge les pages volumineuses, ce qui n’est pas le cas de toutes les plates-formes. La manière générique de gérer cela est de voir si cela existe. Sur un Raspberry Pi que j’ai :
$ sysctl sys.kernel.mm.transparent_hugepage.enabled
sysctl: cannot stat /proc/sys/sys/kernel/mm/transparent_hugepage/enabled: No such file or directory
$ echo $?
255
En revanche, l’overcommit est un paramètre VM général pour Linux depuis quelques décennies. Sur le même Raspberry Pi :
$ sysctl vm.overcommit_memory
vm.overcommit_memory = 0
Analyser la sortie de free dans le shell est un peu pénible. En tant qu’auteur original de procps, pour cela, je chercherais simplement SwapFree dans /proc/meminfo. 
Je suis d’accord que dans nos mondes où les coûts sont limités, la mise à l’échelle de l’échange par la taille de la RAM n’est plus un bon plan. L’idée suivante historiquement semble avoir été que la RAM est énorme et que vous n’avez pas besoin d’échange. Après cela vient la sagesse qu’un peu d’échange est utile car il permet une meilleure utilisation de la RAM. (Dans un monde sans contraintes, nous avons simplement d’énormes quantités de RAM, mais c’est une niche.)
Ce que nous constatons au cours des deux derniers mois, c’est que de plus en plus de personnes ont des problèmes de mémoire insuffisante et des échecs de reconstruction. De plus en plus de personnes constatent que les mises à niveau Web échouent, mais que la ligne de commande fonctionne. D’un point de vue de support simple, et du point de vue de la réputation du produit, je pense que nous devons changer les conseils habituels et la configuration habituelle. Je pense que 3 Go d’échange sont le changement le plus simple et le plus petit, et nous devrions le faire si nous ne faisons rien d’autre.
Mais je pense toujours que plusieurs fichiers d’échange plus petits sont un choix plus judicieux - et nous avons vu des fils de discussion de support ici qui y font allusion. Et je pense toujours qu’il serait préférable d’essayer de dimensionner la RAM + l’échange car c’est le facteur limitant, ce qui cause des problèmes aux gens. Il se peut qu’il existe différentes façons de faire ce calcul. Les mises en garde habituelles s’appliquent quant aux tactiques qui sont maintenables, compréhensibles, qui auront une longévité.
Quant aux pages volumineuses transparentes, je crois comprendre que c’est le terme « transparent » qui cause des problèmes : le noyau peut s’agiter, fusionner et dé-fusionner, pour un impact sur les performances et aucun grand bénéfice. Je suis à peu près sûr que les pages volumineuses sont déconseillées pour les systèmes plus petits.
Il s’agit davantage des caractéristiques de la charge de travail que de la taille du système. Sur un système avec 1 Go de RAM et des processus assez stables avec des blocs de RAM, les hugepages par défaut de 2 Mo peuvent réduire le TLB thrashing et améliorer les performances ; le TLB ne commence pas à couvrir les mappages pour 1 Go de RAM. C’est généralement juste un compromis entre le CPU passé à chercher de la mémoire à agréger et les misses de cache TLB, et il existe de nombreuses charges de travail sur des machines de 1 Go qui peuvent bénéficier considérablement de THP. (De nombreuses recommandations pour le désactiver datent du début de son implémentation ; il a été considérablement amélioré depuis.) La recommandation de désactiver THP pour Discourse n’est pas due à la taille de 1 Go de RAM, mais est spécifique à l’utilisation de redis avec une persistance sur disque, ce que Discourse utilise :
https://redis.io/docs/management/optimization/latency/#latency-induced-by-transparent-huge-pages
Malheureusement, lorsqu’un noyau Linux a les pages transparentes activées, Redis subit une pénalité de latence importante après l’appel
forkutilisé pour persister sur disque. Les hugepages sont la cause du problème suivant :
…