ARM64 и jemalloc

Внести вклад Ошибка
1

Я экспериментирую с запуском Discourse на инстансах AWS на базе Graviton, так как они привлекательны с точки зрения цены. Я понимаю, что поддержка aarch64 находится в экспериментальной стадии, но сообщение о сборке предлагает сообщать о проблемах, поэтому я пишу об этом. Думаю, многие используют Discourse в AWS, поэтому, надеюсь, это может быть полезно и другим.

Мне удалось запустить существующую установку на 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.

Действительно, на arm64 файла /usr/lib/libjemalloc.so.1 нет, в отличие от образов x86_64, зато присутствует /usr/lib/libjemalloc.so.2. Я проследил причину различия версий на arm64 до этого:

К слову, спасибо за качественную документацию этого изменения.

Полагаю, сообщение об ошибке возникает из-за явного указания несуществующего /usr/lib/libjemalloc.so.1 здесь:

Быстрое и не очень элегантное переопределение переменной $RUBY_ALLOCATOR в файле templates/web.template.yml, похоже, успешно устранило сообщение об ошибке. Таким образом, Rails (Puma?) теперь, вероятно, работает с правильной библиотекой libjemalloc.

Тем не менее, я не знаю, потребует ли правильное исправление большего количества изменений и не повлекут ли такие изменения других последствий для производственных систем. Всё же хотел поделиться этим на случай, если это затронет других, пытающихся использовать Discourse с arm64 в AWS. Возможно, команде Discourse стоит также взглянуть на это?

1 лайк
2

Связано:

2 лайка
3

Спасибо за предупреждение.

Как показывает ссылка от @merefield, я активно работаю над образом контейнера для aarch64, но на прошлой пятнице у меня не хватило времени.

Думаю, я наконец охватил все необходимые места, и следующим шагом будет изменение этой переменной окружения для основной символической ссылки, заканчивающейся на .so, что обеспечит работу как на x64, так и на ARM64.

4 лайка
4

О, как удачно совпало! Я уже давно хотел попробовать arm64, но до сегодняшнего дня так и не дошли руки, а вы как раз начали работу над этим.

С радостью помогу с тестированием, когда будете готовы, если вы хотите, чтобы изменения были протестированы на экземпляре graviton2.

Кстати, раз кастомная версия jemalloc может вызывать проблемы (хотя для некоторых настроек Raspberry Pi она всё ещё необходима), имеет ли смысл принимать решение о версии, проверяя конкретный размер страницы (PAGESIZE) на машине, где собирается образ? Причина, по которой я это предлагаю, в том, что экземпляр graviton2, с которым я тестирую, имеет PAGESIZE=4k. Для некоторых случаев всё ещё понадобится более новая версия jemalloc, но это, возможно, уменьшит различия между настройками образов arm64 и x64.

5

Я уже тестировал это на Graviton несколько лет назад, и всё работало отлично. Сейчас моя задача — также обеспечить совместимость с новыми ARM-платформами, имеющими нестандартный размер страницы (PAGESIZE). Все изменения обратно совместимы со старыми платформами, поэтому для них ничего не изменится.

1 лайк
6

@mentalstring Установка снова должна работать из коробки на ARM64.

3 лайка
7

Могу подтвердить, что сборка проходит успешно без локальных изменений на Graviton2, и в логах я не вижу ошибок, связанных с jemalloc. Спасибо за решение этой проблемы.

Буду продолжать тестировать, так как мы можем перевести наш продакшн-сервер на архитектуру arm64, если она окажется достаточно стабильной. Если я столкнусь с чем-то ещё, сообщу об этом.

2 лайка
Error updating with broken events plugin
8

Эта тема была автоматически закрыта через 4 дня. Новые ответы больше не принимаются.