Configurer la limite de mémoire de ruby ?

Contribuer Fonctionnalité
1

Pourrait-on en faire une option de configuration du site pour déterminer la quantité de mémoire utilisable ? Actuellement, le réglage est fixé à 2 Go (Édité : oops, je me trompe, voir ci-dessous) — auparavant, il était de 4 Go — alors que la configuration matérielle recommandée est de 1 Go + swap. Il me semble qu’un nœud de 1 Go pourrait facilement entrer dans une boucle de pagination intensive si l’utilisation de Ruby atteignait réellement 2 Go.

Extrait d’un journal de mise à niveau :

Migration par défaut
Initialisation par défaut
*** Agrégation des assets. Cela prendra un certain temps ***
$ RUBY_GC_MALLOC_LIMIT_MAX=20971520 RUBY_GC_OLDMALLOC_LIMIT_MAX=20971520 RUBY_GC_HEAP_GROWTH_MAX_SLOTS=50000 RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=0.9 bundle exec rake assets:precompile
Nettoyage des fichiers temporaires
Agrégation des assets
1 « J'aime »
2

Je ne suis pas sûr de la pertinence de ces paramètres dans Ruby moderne, mais @sam le saurait mieux.

1 « J'aime »
3

Euh, excusez-moi, ce n’est pas 2G, c’est 20 M. Donc, rien de comparable à la situation que j’imaginais. (Edit : c’est pire ! Voir ci-dessous)

1 « J'aime »
4

Essayez 20 Go. :wink: :slightly_smiling_face:

1 « J'aime »
5

Discourse a une utilisation de la mémoire prévisible, donc le paramètre que vous devez ajuster est le nombre de workers Unicorn.

Si vous disposez d’un serveur de 1 Go, nous utiliserons par défaut 2 workers, ce qui devrait fonctionner correctement avec cette faible quantité de mémoire.

2 « J'aime »
6

En effet, cela fonctionne lorsque le site est configuré en tant que forum. Mais ce n’est pas le cas ici !

Lors des mises à niveau, certaines tâches spécifient ces variables d’environnement pour Ruby.

1 « J'aime »
7

Oui, lors des mises à jour, nous définissons ces variables afin que la mise à niveau ne échoue pas en raison d’un manque de mémoire sur les machines très peu puissantes.

2 « J'aime »
8

D’accord, et mon observation est que les limites pourraient être trop élevées dans certains cas, alors je me demande si elles peuvent être rendues configurables.

2 « J'aime »
9

Nous avons testé cette procédure à de nombreuses reprises au fil des années et pouvons garantir qu’elle fonctionnera parfaitement pour les petites communautés utilisant un VPS de 1 Go. Elle met même fin aux processus Unicorn supplémentaires pour libérer de la mémoire pendant la mise à niveau, afin d’aider.

Vous pouvez consulter le code issu de ce commit :

Si vous parvenez à reproduire un échec sur une instance Digital Ocean, nous serons ravis de l’examiner.

Si cela est indispensable, vous pouvez bifurquer le plugin et l’adapter à vos besoins.

4 « J'aime »
10

Merci, je vois maintenant l’image. (Deux points très importants : ces paramètres GC sont ajustés spécifiquement pour les mises à niveau, et les unités sont en octets, donc la limite est actuellement fixée à 20 Mo. Vous trouverez des détails utiles et intéressants dans ce fil de discussion antérieur [lien d’archive car il n’est pas accessible pour moi actuellement].)

2 « J'aime »
11

Devons-nous restaurer ce sujet @sam ? A-t-il une valeur historique ou est-il obsolète ?

1 « J'aime »
12

C’est certainement obsolète : la dernière version de Ruby comporte plusieurs limites de malloc. C’est un sujet intéressant qui a une certaine valeur historique, mais il faudrait y apposer un grand panneau « Obsolète » en haut.

Notre mise à niveau fonctionne déjà au maximum de ses capacités ; la seule chose que nous pourrions faire en plus serait de réduire la disponibilité. Si la mémoire est extrêmement limitée, vous devrez accepter des interruptions lors de la mise à niveau.

5 « J'aime »