AWS の graviton ベースのインスタンスで Discourse を実行する実験をしています。価格的に魅力的だからです。aarch64 のサポートは実験的であることは理解していますが、ビルドメッセージには問題を報告するように書かれているため、これがその報告です。多くの人が AWS で Discourse を実行していると思うので、これも他の人に役立つことを願っています。
既存のインストールを再構築して arm64 で起動し、フロントエンドがロードされることを確認するための基本的な健全性チェックを行いました。しかし、./launcher logs web_only を実行すると、rails.stderr.log が常に次のような内容でいっぱいになっていることがわかります。
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.
そして実際、x86 イメージには存在する /usr/lib/libjemalloc.so.1 は arm64 には存在しませんが、/usr/lib/libjemalloc.so.2 は存在します。arm64 でのバージョンの違いは、次の点に起因していることを特定しました。
# Newer aarch64 platforms, like Raspberry Pi 5 with Debian Bookworm, are
# shipping with PAGESIZE=16K. Setting it here is retrocompatible with older
# systems, so it's safe to set it unconditionally for arm.
# This means aarch64 will use the latest jemalloc, where we can configure the
# page size, while x64 will keep using our pinned 3.6.0 jemalloc
if uname -m | grep -qi 'aarch64'; then
mkdir /jemalloc-new
cd /jemalloc-new
wget -q https://github.com/jemalloc/jemalloc/releases/download/5.3.0/jemalloc-5.3.0.tar.bz2
sha256sum jemalloc-5.3.0.tar.bz2
echo "2db82d1e7119df3e71b7640219b6dfe84789bc0537983c3b7ac4f7189aecfeaa jemalloc-5.3.0.tar.bz2" | sha256sum -c
tar --strip-components=1 -xjf jemalloc-5.3.0.tar.bz2
./configure --prefix=/usr --with-lg-page=16 && make build_lib -j"$(nproc)" && make install_lib
cd / && rm -rf /jemalloc-new
else
# jemalloc stable
ちなみに、変更に関する優れたドキュメントに感謝します。
エラーメッセージは、次の箇所で存在しない /usr/lib/libjemalloc.so.1 が具体的に指定されていることから来ていると思います。
templates/web.template.yml で $RUBY_ALLOCATOR をクイック＆ダーティにオーバーライドしたところ、エラーメッセージは正常に停止したようです。これにより、rails (puma?) が適切な libjemalloc で実行されているように見えます。
とはいえ、適切な修正にはこれ以上の変更が必要かどうか、またそのような変更が本番システムに他の影響を与える可能性があるかどうかはわかりません。それでも、AWS で arm64 を使用して Discourse を利用しようとしている他の人に影響を与える可能性があるため、共有しておきたかったのです。おそらく Discourse チームも確認してくれるでしょうか？
「いいね！」 1
Falco
2024 年 3 月 3 日午後 8:05
3
お知らせありがとうございます。
@merefield さんのリンクにあるように、aarch64 コンテナイメージに積極的に取り組んでおり、先週金曜日は時間が足りなくなってしまいました。
これで全ての箇所をカバーできたと思いますが、次のステップは、x64 と ARM64 の両方で動作する .so で終わるメインのシンボリックリンクの ENV を変更することです。
「いいね！」 4
ちょうど良いタイミングでしたね。以前から arm64 を試してみたかったのですが、あなたが作業しているまさに今日、ようやく着手したところでした。
準備ができたら、graviton2 インスタンスでテストしてほしいということであれば、喜んでテストのお手伝いをします。
ところで、カスタム jemalloc バージョンは（一部の Raspberry Pi セットアップには必要ですが）問題を発生させる可能性があります。特定のマシンで PAGESIZE を調べることで、バージョンを決定するようにするのは理にかなっているでしょうか？私がテストしている graviton2 インスタンスでは PAGESIZE=4k なので、このように提案する次第です。新しい jemalloc バージョンは一部のケースで必要になるかもしれませんが、これにより arm64 と x64 のイメージセットアップ間の違いを減らせるかもしれません。
Falco
2024 年 3 月 4 日午後 5:20
5
数年前にGravitonでテストしましたが、問題なく動作しました。現在行っている作業は、PAGESIZEが標準でない新しいARMプラットフォームとの互換性も確保することです。変更はすべて古いプラットフォームとの後方互換性があるため、それらには何も変更はありません。
「いいね！」 1
Falco
2024 年 3 月 4 日午後 7:45
6
@mentalstring ARM64でインストールがすぐに動作するようになりました。
「いいね！」 3
Graviton2 でローカルの変更なしでビルドできていること、ログに jemalloc のエラーが見られないことを確認しました。対応ありがとうございます。
安定していれば、本番サーバーを arm64 に移行する可能性があるので、引き続き試してみます。他に何か問題があれば報告します。
「いいね！」 2
Falco
2024 年 3 月 9 日午前 11:00
8
このトピックは4日後に自動的に閉じられました。新しい返信は許可されていません。