ARM64 und jemalloc

[mentalstring (Paulo)]

Ich experimentiere damit, Discourse auf den Graviton-basierten Instanzen von AWS auszuführen, da diese preislich attraktiv sind. Ich verstehe, dass die Unterstützung für aarch64 experimentell ist, aber die Build-Nachricht besagt, dass Probleme gemeldet werden sollen, also ist dies hier. Ich denke, viele betreiben Discourse bei AWS, daher kann dies hoffentlich auch anderen zugutekommen.

Ich habe eine bestehende Installation unter arm64 zum Laufen gebracht, nachdem ich sie neu erstellt und einige grundlegende Plausibilitätsprüfungen durchgeführt hatte, um sicherzustellen, dass das Frontend geladen wird. Ein ./launcher logs web_only zeigt jedoch, dass rails.stderr.log ständig mit Folgendem gefüllt wird:

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.

Und tatsächlich existiert /usr/lib/libjemalloc.so.1 unter arm64 nicht, wie es bei den x86-Images der Fall ist, aber /usr/lib/libjemalloc.so.2 schon. Ich habe den Versionsunterschied unter arm64 auf Folgendes zurückgeführt:

image/base/install-jemalloc

Nebenbemerkung: Lob für die gute Dokumentation der Änderung.

Ich denke, die Fehlermeldung stammt aus der spezifischen Erwähnung des nicht vorhandenen /usr/lib/libjemalloc.so.1 hier:

image/base/slim.Dockerfile

Eine schnelle und schmutzige Überschreibung von $RUBY_ALLOCATOR in templates/web.template.yml scheint die Fehlermeldung erfolgreich gestoppt zu haben, sodass Rails (Puma?) jetzt mit der richtigen libjemalloc läuft.

Nichtsdestotrotz weiß ich nicht, ob eine ordnungsgemäße Korrektur mehr Änderungen als diese erfordert und ob eine solche Änderung andere Auswirkungen auf Produktionssysteme haben könnte. Ich wollte es trotzdem teilen, falls es andere betrifft, die versuchen, Discourse mit arm64 bei AWS zu verwenden. Vielleicht kann sich das Discourse-Team das auch ansehen?

[merefield (Robert)]

Verwandt:

Bootstrap failed with exit code 1 on Raspberry Pi 5

Hey @keviiNN25 and @lemonade, This issue was caused by the fact the the OS for Pi5 uses 16k for PAGESIZE by default, which isn’t supported by the jemalloc version we ship. The first thing to break during a rebuild is redis-server being able to start, which in turn means our asset compilation fails. I baked a image that solves this, can you give it a try? cd /var/discourse sed -i -- 's/discourse\/base:aarch64/discourse\/base:aarch64-pi5/' launcher ./launcher rebuild app

[Falco]

Danke für den Hinweis.

Wie der Link von @merefield zeigt, arbeite ich aktiv am aarch64-Container-Image und hatte am letzten Freitag keine Zeit mehr dafür.

Ich glaube, ich habe endlich alle Stellen abgedeckt, und der nächste Schritt ist die Änderung dieser ENV für den Haupt-Symlink, der auf .so endet und sowohl auf x64 als auch auf ARM64 funktioniert.

[mentalstring (Paulo)]

Oh, wow, das ist ja ein glücklicher Zufall für mich. Ich wollte arm64 schon seit langem ausprobieren, habe es aber erst heute geschafft, gerade als Sie daran gearbeitet haben.

Ich helfe gerne beim Testen, wenn Sie bereit sind, falls Sie möchten, dass die Änderungen mit einer Graviton2-Instanz getestet werden.

Wo wir gerade davon sprechen: Da die benutzerdefinierte jemalloc-Version Dinge kaputt machen kann (aber für einige Raspberry Pi-Setups immer noch benötigt wird), wäre es sinnvoll, die Versionsentscheidung auf der Grundlage der Suche nach der bestimmten PAGESIZE auf der Maschine zu treffen, auf der das Image erstellt wird? Der Grund, warum ich dies vorschlage, ist, dass die Graviton2-Instanz, mit der ich teste, PAGESIZE=4k hat. Eine neuere jemalloc-Version wäre für einige Fälle immer noch erforderlich, aber sie könnte vielleicht die Unterschiede zwischen arm64- und x64-Image-Setups verringern.

[Falco]

@mentalstring

Ich helfe gerne beim Testen, wenn Sie bereit sind, falls Sie möchten, dass die Änderungen mit einer Graviton2-Instanz getestet werden.

Ich habe es vor ein paar Jahren auf Graviton getestet und es funktioniert einwandfrei. Die Arbeit, die ich jetzt mache, dient auch dazu, es mit neueren ARM-Plattformen mit nicht standardmäßiger PAGESIZE kompatibel zu machen. Die Änderungen sind alle rückwärtskompatibel mit alten Plattformen, sodass sich für diese nichts ändern sollte.

[Falco]

@mentalstring Die Installation sollte jetzt wieder auf Anhieb auf ARM64 funktionieren.

[mentalstring (Paulo)]

Kann bestätigen, dass es ohne lokale Änderungen auf einem Graviton2 fehlerfrei kompiliert und dass in den Protokollen keine jemalloc-Fehler zu sehen sind. Danke für die Behebung.

Ich werde weiter damit experimentieren, da wir unseren Produktionsserver möglicherweise auf arm64 umstellen, wenn er stabil genug ist. Wenn mir etwas anderes auffällt, werde ich es melden.