Our great sponsors
-
server-edition
A server-optimized Ruby distribution: less memory, faster, easy to install and security-patch via APT/YUM
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
cinder
Cinder is Meta's internal performance-oriented production version of CPython. (by facebookincubator)
It's 2021. Installing from source is no longer a low-friction, non-scary, default thing to do. Users now expect binaries and proper package management.
Furthermore, it's not just "dnf install jemalloc-devel". The Jemalloc version matters a lot. For reasons that are not yet clear, significant memory savings are only achieved with Jemalloc 3, not with Jemalloc 5. And your distribution only ships 1 Jemalloc version. So likely you need to compile Jemalloc 3 yourself.
But Jemalloc 3 no longer compiles by default on some modern distributions, such as Debian 10. Fullstaq Ruby fixes this by patching Jemalloc: https://github.com/fullstaq-labs/fullstaq-ruby-server-editio...
Another caveat is that LD_PRELOADing Jemalloc is more effective than compiling with --with-jemalloc.
Furthermore, installing Ruby is one thing. Keeping it security-patched without having to constantly monitor things, is a whole other can of worms. Here's where Fullstaq Ruby's second value proposition comes in: we supply DEB/RPMs and do the tiny version patching for you, you don't have to go through the whole compilation process and gem migration process every time there's a new Ruby tiny version.
See also this FAQ entry, "Fullstaq Ruby vs LD_PRELOADing Jemalloc yourself": https://github.com/fullstaq-labs/fullstaq-ruby-server-editio...
It's 2021. Installing from source is no longer a low-friction, non-scary, default thing to do. Users now expect binaries and proper package management.
Furthermore, it's not just "dnf install jemalloc-devel". The Jemalloc version matters a lot. For reasons that are not yet clear, significant memory savings are only achieved with Jemalloc 3, not with Jemalloc 5. And your distribution only ships 1 Jemalloc version. So likely you need to compile Jemalloc 3 yourself.
But Jemalloc 3 no longer compiles by default on some modern distributions, such as Debian 10. Fullstaq Ruby fixes this by patching Jemalloc: https://github.com/fullstaq-labs/fullstaq-ruby-server-editio...
Another caveat is that LD_PRELOADing Jemalloc is more effective than compiling with --with-jemalloc.
Furthermore, installing Ruby is one thing. Keeping it security-patched without having to constantly monitor things, is a whole other can of worms. Here's where Fullstaq Ruby's second value proposition comes in: we supply DEB/RPMs and do the tiny version patching for you, you don't have to go through the whole compilation process and gem migration process every time there's a new Ruby tiny version.
See also this FAQ entry, "Fullstaq Ruby vs LD_PRELOADing Jemalloc yourself": https://github.com/fullstaq-labs/fullstaq-ruby-server-editio...
It's possible you can already easily use with chruby by just pointing chruby at it? I haven't tried, I am interested if anyone wants to report back!
https://github.com/postmodern/chruby#rubies-1
(You don't need to use ruby-install with chruby, you can use whatever method of installing rubies you want. The chruby README even includes instructions for `ruby-build`. But normally whatever method you use, you install to `/opt/rubies` or `~/.rubies` which is where chruby will look. But fullstaq ruby insists on installing to it's own locations. But possibly chruby will be fine with that if you just tell it where that is... but you might need to do it for each ruby you install, which woudl be annoying. You could probably write a little bash shim which just checked the fullstaq install location for which rubies it had, and then just added them each individually?)