J’utilise une instance AWS EC2 « t2.medium » avec 2 vCPUs et 4 Gio de RAM.
Le disque dur fait 100 Gio avec 60 Gio d’espace libre.
Si cela peut aider, je peux passer de « t2.medium » à un type d’instance plus grand.
Je suis juste confus que cette configuration ait fonctionné de manière très stable (pendant des années) avant mes tests du plugin IA officiel et que ce ne soit que depuis, après l’avoir supprimé, que ces blocages se produisent lors de la mise à niveau.
Autre chose a changé : la version du logiciel vers laquelle vous effectuez la mise à niveau. Elle est devenue plus gourmande en mémoire dernièrement. Je pense donc que cela pourrait être l’un ou l’autre.
Une mise à niveau temporaire et réversible vers une instance avec plus de RAM est probablement le moyen le plus simple de tester si le manque de mémoire est le problème, bien que cela coûte quelques redémarrages. L’autre moyen est d’ajouter du swap, ce qui est également réversible.
C’est un peu hors sujet, mais j’aimerais vraiment comprendre. Pourquoi le swap, qui utilisait 200 Mo, a-t-il aidé alors qu’il restait 2 Go de RAM libre ?
(Je comprends qu’dans le monde des pouces, le système SI puisse être déroutant car il utilise une échelle de 10, mais pourquoi diable Mi ? Je peux en quelque sorte comprendre Gi si c’est l’abréviation de giga, mais méga devrait alors être Me ?)
Je pense que le problème initial était probablement qu’un processus était tué parce que la machine manquait de mémoire (attention au tueur OOM). L’ajout de swap a permis de ne pas épuiser la mémoire. Ces deux sorties de free ne racontent peut-être pas toute l’histoire, à moins qu’elles n’aient été prises très soigneusement au moment de la plus grande contrainte de la machine. C’est l’utilisation maximale du swap qui est intéressante, je pense.
Mais il y a aussi la question du réglage du noyau mentionné dans MKJ’s Opinionated Discourse Deployment Configuration
que j’ai correctement configuré, mais que peut-être beaucoup de gens n’ont pas correctement configuré.
Il est à noter que la sur-allocation de mémoire n’a pas grand-chose à voir avec Redis. C’est juste que Redis est assez gentil pour suggérer qu’elle devrait être correctement configurée.
Je viens de lancer un autre /admin/upgrade et j’ai ouvert un shell pour appeler manuellement tree -h environ une seconde.\n\nLes valeurs d’utilisation de mémoire les plus élevées que j’ai pu trouver étaient les suivantes :\n\ntxt\n$ free -h\n total used free shared buff/cache available\nMem: 3.8Gi 3.2Gi 120Mi 80Mi 542Mi 266Mi\nSwap: 8.0Gi 276Mi 7.7Gi\n\n\nLa mise à niveau a réussi.
Donc 4 Go est juste à la limite au moment de la compilation, si l’on suppose que la dernière capture d’écran montre le moment le plus stressant.
Et c’est une autre chose que je ne comprends pas : pourquoi d’autres rencontrent des problèmes de mémoire faible et moi, qui utilise beaucoup de plugins et de composants, n’ai eu aucun problème qu’est-ce qui fait cette différence ?
Et j’ai utilisé eu parce qu’aujourd’hui j’ai 8 Go grâce à l’IA (et pour moi la différence de prix n’était pas si importante, mais c’est une autre histoire).
Ce fil de discussion devrait-il être déplacé ailleurs ou considérons-nous cela comme une explication sur pourquoi l’utilisation du swap a aidé ?
Quoi qu’il en soit. Pour les autres débutants, voici un exemple où l’on parle un peu de la mémoire faible et des raisons à cela :
C’est une question très fréquente dans la FAQ lorsque la mise à niveau échoue. Mais la raison est rarement expliquée.
Merci @uwe_keim - Je suppose que ces paramètres du noyau sont la raison pour laquelle vous avez dû ajouter du swap, même s’il ne semblait pas être utilisé. (Il en serait de même si vous aviez dû ajouter beaucoup de RAM, car la mémoire totale disponible est RAM + swap.)
.
J’espère que cela restera ainsi.
qu’est-ce qui fait cette différence ?