AWS의 Graviton 기반 인스턴스에서 Discourse를 실행하는 것을 실험 중입니다. 가격 면에서 매력적이기 때문입니다. aarch64 지원이 실험 단계라는 점은 알고 있지만, 빌드 메시지에 문제를 보고하라고 나와서 이렇게 공유합니다. 많은 분들이 AWS에서 Discourse를 실행하고 계실 것 같아 다른 분들에게도 도움이 되길 바랍니다.
기존 설치 환경을 arm64에서 재빌드하고 프론트엔드가 제대로 로드되는지 확인하는 기본적인 sanity check를 거친 후 정상적으로 구동할 수 있었습니다. 하지만 ./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.
실제로 x84 이미지와 달리 arm64에서는 /usr/lib/libjemalloc.so.1이 존재하지 않지만, /usr/lib/libjemalloc.so.2는 존재합니다. arm64에서 버전 차이가 나는 원인을 다음 링크에서 찾았습니다:
참고: 변경 사항에 대한 훌륭한 문서화에 감사를 표합니다.
에러 메시지는 다음 위치에 존재하지 않는 /usr/lib/libjemalloc.so.1이 명시적으로 언급되고 있기 때문에 발생하는 것으로 보입니다:
templates/web.template.yml에서 $RUBY_ALLOCATOR를 간단하고 급하게 오버라이드했을 때 에러 메시지가 성공적으로 사라졌으므로, 이제 rails(puma?)가 올바른 libjemalloc로 실행되고 있는 것으로 보입니다.
그러나 적절한 수정이 이보다 더 많은 변경 사항이 필요할 수 있으며, 이러한 변경이 프로덕션 시스템에 다른 영향을 미칠 수 있는지 확신할 수 없습니다. 여전히 AWS에서 arm64로 Discourse를 사용하려는 다른 분들에게도 영향을 줄 수 있을 것 같아 공유합니다. 혹시 Discourse 팀에서도 이 문제를 살펴봐 주실 수 있을까요?
오, 정말 운이 좋네. 나는 arm64를 꽤 오래전부터 시도해 보고 싶었는데, 마침 오늘에서야 그 일을 하게 되었네. 네가 바로 그 작업을 하고 있는 타이밍에 말이야.
graviton2 인스턴스로 변경 사항을 테스트해 보고 싶다면, 준비가 되는 대로 테스트를 도와줄 수 있어.
그리고 그와 관련하여, 커스텀 jemalloc 버전이 문제를 일으킬 수 있지만(일부 Raspberry Pi 설정에는 여전히 필요함), 이미지가 빌드되는 머신의 특정 PAGESIZE를 조회하여 버전 결정을 내리는 것이 합리적인가? 이렇게 제안하는 이유는 내가 테스트 중인 graviton2 인스턴스의 PAGESIZE가 4k이기 때문이야. 일부 경우에는 여전히 더 새로운 jemalloc 버전이 필요하겠지만, 이렇게 하면 arm64와 x64 이미지 설정 간의 차이를 줄일 수 있을지도 몰라.
몇 년 전에 Graviton에서 테스트해 봤는데, 잘 작동했습니다. 현재 진행 중인 작업은 비표준 PAGESIZE를 가진 새로운 ARM 플랫폼과의 호환성도 확보하는 것입니다. 모든 변경 사항은 이전 플랫폼과 완전히 하위 호환되므로, 기존 플랫폼에서는 아무런 변화가 없을 것입니다.