J’expérimente l’exécution de Discourse sur les instances basées sur Graviton d’AWS car elles sont attrayantes en termes de prix. Je comprends que le support aarch64 est expérimental, mais le message de compilation indique de signaler les problèmes, donc voilà. Je pense que beaucoup de gens exécutent Discourse sur AWS, donc j’espère que cela pourra également bénéficier à d’autres.
J’ai réussi à faire fonctionner une installation existante sur arm64 après une reconstruction et quelques vérifications de base pour m’assurer que le frontend se charge. Cependant, un ./launcher logs web_only montre que rails.stderr.log est constamment rempli de ceci :
ERROR: ld.so: object '/usr/lib/libjemalloc.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/libjemalloc.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Et, en effet, /usr/lib/libjemalloc.so.1 n’existe pas sur arm64 comme il le fait sur les images x86, mais /usr/lib/libjemalloc.so.2 existe. J’ai retracé la différence de version sur arm64 à ceci :
Anecdote : félicitations pour la bonne documentation du changement.
Je pense que le message d’erreur provient de la mention spécifique du /usr/lib/libjemalloc.so.1 inexistant ici :
Un remplacement rapide et sale de $RUBY_ALLOCATOR sur templates/web.template.yml semble avoir réussi à arrêter le message d’erreur, donc il semble que rails (puma ?) s’exécute maintenant avec le bon libjemalloc.
Cela dit, je ne sais pas si une correction appropriée pourrait nécessiter plus de changements que cela et si un tel changement pourrait avoir d’autres implications pour les systèmes de production. Néanmoins, je voulais partager au cas où cela affecterait d’autres personnes essayant d’utiliser Discourse avec arm64 sur AWS. Peut-être que l’équipe Discourse pourrait également y jeter un œil ?
Comme le montre le lien de @merefield, je travaille activement sur l’image conteneur aarch64 et j’ai manqué de temps vendredi dernier.
Je pense avoir finalement couvert tous les endroits, et la prochaine étape consiste à modifier cette variable d’environnement pour le lien symbolique principal qui se termine par .so, qui fonctionnera sur x64 et ARM64.
Oh, wow, quelle chance pour moi alors. J’avais l’intention d’essayer arm64 depuis longtemps, mais je ne m’y suis mis qu’aujourd’hui, juste au moment où vous y travailliez.
Je serais heureux de vous aider à tester quand vous serez prêt, si vous souhaitez que les modifications soient testées avec une instance graviton2.
D’ailleurs, puisque la version personnalisée de jemalloc peut casser des choses (mais reste nécessaire pour certaines configurations de Raspberry Pi), serait-il judicieux de baser la décision de version en recherchant le PAGESIZE particulier sur la machine où l’image est construite ? La raison pour laquelle je suggère cela est que l’instance graviton2 avec laquelle je teste a PAGESIZE=4k. Une version plus récente de jemalloc serait toujours nécessaire dans certains cas, mais cela pourrait peut-être réduire les différences entre les configurations d’images arm64 et x64.
Je l’ai testé sur Graviton il y a quelques années, et cela fonctionne très bien. Le travail que j’effectue maintenant consiste également à le rendre compatible avec les plateformes ARM plus récentes avec des PAGESIZE non standard. Les modifications sont toutes rétrocompatibles avec les anciennes plateformes, donc rien ne devrait changer pour celles-ci.
Je peux confirmer que la compilation se déroule bien sans modifications locales sur un graviton2 et qu’il n’y a pas d’erreurs jemalloc dans les journaux que je puisse voir. Merci d’avoir résolu ce problème.
Je vais continuer à l’essayer car nous pourrions déplacer notre serveur de production vers arm64 s’il est suffisamment stable. Si je rencontre autre chose, je le signalerai.