4 ms·

You don't need special talent to do that. I actually have a mention of this in my book on deploying Rails (https://deploymentfromscratch.com/ https://deploymen

You don't need special talent to do that. I actually have a mention of this in my book on deploying Rails (https://deploymentfromscratch.com/ https://deploymentfromscratch.com/). Here's a one liner with ruby-install: $ sudo dnf install -y jemalloc-devel $ ruby-install 3.0.0 -- --with-jemalloc Then check you have it: $ ruby -r rbconfig -e "puts RbConfig::CONFIG['LIBS']" ... -ljemalloc

FooBarWidget 5y ago
It's 2021. Installing from source is no longer a low-friction, non-scary, default thing to do or something that people want to bother with. 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-edition/blob/main/resources/jemalloc_cxx_fix.patch 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-edition#vs-ld_preloading-jemalloc-yourself https://github.com/fullstaq-labs/fullstaq-ruby-server-editio...

FooBarWidget 5y ago

It's 2021. Installing from source is no longer a low-friction, non-scary, default thing to do or something that people want to bother with. 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-edition/blob/main/resources/jemalloc_cxx_fix.patch 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-edition#vs-ld_preloading-jemalloc-yourself https://github.com/fullstaq-labs/fullstaq-ruby-server-editio...