Support for ARM servers

AI-generated summary

The discussion revolves around adding support for ARM servers to Discourse. The main motivation is the extremely low price of ARM servers, such as Scaleway’s 2GB ARM servers for €2.99, making it an attractive option for owners of small communities.

However, there are blockers to achieving this, including issues with the therubyracer and v8 gems, which require patches or different versions to work on ARM. rriemann shared a stack trace and an upstream bug report related to this issue.

Despite these challenges, progress has been made, and some users have successfully installed Discourse on ARM servers by patching the Gemfile and using local versions of the gems. codinghorror noted that mini racer has helped in this regard.

The discussion also touches on the potential benefits of ARM servers, including energy efficiency, lower costs, and improved performance. merefield emphasized the importance of broad adoption of ARM in datacenters, which could have a significant impact on energy efficiency and costs.

Finally, Falco announced that Discourse now supports ARM servers, with a blog post detailing the process of running Discourse on a Raspberry Pi.

https://github.com/discourse/discourse_docker/issues/121

Continuing on from the discussion on ARM support at GitHub.

ARM support would be extremely useful for owners of small communities like myself because of the extremely low price (like the Scaleway 2GB ARM servers for €2.99) and for those who can’t afford the move from cheap shared hosting to the dedicated or KVM machines that Discourse requires.

https://community.scaleway.com/t/discourse-instantapp/452

There has also been some discussion of this on the Scaleway forums, although much of this has been around getting Discourse working without using the Docker method.

5개의 좋아요

As @erlend_sh said, this is a blocker. No updates so far? Maybe Discourse could provide a list of non-ARM gems so far so that we could track here the process with respect to blocking dependencies?

1개의 좋아요

Simplest thing to do is install Ruby on a scaleway copy our Gemfile and do a bundle install… what happens?

bundle install is not an issue.

However, the therubyracer and v8 gem requires some patches/different version. Otherwise, the
RUBY_GC_MALLOC_LIMIT=90000000 RAILS_ENV=production bundle exec rake assets:precompile
does not finish, but break with a stack trace.

Purging temp files
abort:

==== JS stack trace =========================================

Security context: 0x3fd36f3d <JS Object>#0#
    1: /* anonymous */ [<eval>:~56513] (this=0x3fd36fe5 <JS Global Object>#1#,data=0x4f74cec5 <JS Array[2]>#2#)
    2: intersection [<eval>:57141] (this=0x4f74d431 <JS Object>#3#,argument=0x4f74ce7d <JS Object>#4#)
    3: /* anonymous */ [<eval>:58617] (this=0x4f70b199 <an Object>#5#,_dereq_=0x4f70b0f1 <JS Function>#6#,module=0x4f70b1a5 <an Object>#7#,exports=0x4f70b199 <an Object>#5#)
    4: arguments adaptor frame: 7->3
    5: s [<eval>:~2] (this=0x3fd36fe5 <JS Global Object>#1#,o=591,u=0x3fd08091 <undefined>)
    6: arguments adaptor frame: 1->2
    7: /* anonymous */ [<eval>:2] (this=0x3fd36fe5 <JS Global Object>#1#,e=591)

stacktrace.txt (291 KB)

This seems to be the upstream bug: TheRubyRacer 0.12.1 Segmentation Fault · Issue #317 · rubyjs/therubyracer · GitHub
I posted recently a comment, but did not get a response.

Scaleway patches the Gemfile and Gemfile.lock in order to use local versions that have been downloaded from elsewhere: https://github.com/scaleway-community/scaleway-discourse/blob/master/Dockerfile#L53

5개의 좋아요

For those looking into this, a fair amount of progress has been made on this front:

https://community.scaleway.com/

7개의 좋아요

Nice looks like mini racer helped here @sam!

7개의 좋아요

이제 ARM에서 작동하나요?

설치 스크립트만 다듬으면 되는 문제인지, 아니면 실제로 x86 바이너리 블롭이 사용되는 건가요?

지금은 누구나 100Mbit 회선을 갖추고 있고, 많은 사람들이 가정에서 기가비트 광섬유 인터넷을 이용합니다. 30달러짜리 Cortex-A55 TV 박스를 구해, 3달러짜리 어댑터로 구형 SSD 드라이브를 USB 3.0으로 연결하고, 리눅스를 설치하면 바로 사용할 수 있습니다. 전력 소비가 거의 없고, 처리 속도 및 디스크 속도가 놀랍습니다. 데이터센터보다 핑이 더 낮은 경우도 흔합니다. 이것은 이미 미래의 호스팅이 아니라, 꽤 오래전부터 존재해 온 현실입니다. 중급 서버보다 압도적으로 우수하며, 장점이 일방적입니다.

1개의 좋아요

그런 인터넷 속도(광섬유 인터넷은 말할 것도 없이)에 접근할 만큼 운이 좋은 사람은 모두 같은 것은 아닙니다. 여전히 다이얼업 인터넷을 사용하는 사람들도 있습니다. 미국에서는 상황이 조금씩 바뀌고 있지만, 빈곤 지역에서는 그렇지 않습니다. 다만 Starlink에 대해 언급할 가치가 있을 것 같습니다.

1개의 좋아요

좋은 지적이시지만, 저는 데이터센터에서 그 중요성이 더 크다고 생각합니다.

데이터센터에서 ARM의 광범위한 채택은 상당한 에너지 효율성(>2배 이상?)과 비용 절감을 실현할 수 있으며, 이는 막대한 영향을 미칠 수 있습니다. 이는 매우 책임감 있는 목표입니다.

참고로, 이 주제는 최근에 이 토픽에서 논의되었습니다: Require ARM64 Support - #3 by david . 여기서 x86 외에서는 여러 종속성(gem 바이너리)을 사용할 수 없다는 제안이 있었습니다.

3개의 좋아요

이제 지원됩니다

5개의 좋아요