[ruby-core:87616] [Ruby trunk Feature#14718] Use jemalloc by default?

[v.ondruch@tiscali.cz]

Issue #14718 has been updated by vo.x (Vit Ondruch).


Fedora and RHEL Ruby maintainer here. Just a few remarks.

mperham (Mike Perham) wrote:
> ~~~
> Bundle jemalloc and link it statically.
> 
>     pro: No runtime hell.
>     con: Bloats source distribution. Costs non-glibc users.
>     con: Also costs the core devs because they have to sync the bundled jemalloc with the upstream.
> ~~~
> 
> This would be my choice as a maintainer and I trust antirez knows what he's doing when he made the same choice for Redis.  You control the exact version and any resulting bugs.  If you depend on the distro's package, you will integrate with a variety of versions, all with their own set of platform-specific bugs and crash reports.  Ubuntu 14 might have jemalloc 3.6.0, 16 might have 4.2.0, 18 might have 5.0.1, etc.  Dealing with those platform issues will also cost the core devs.

We are always against bundling. You make great disservice to almost every Linux distribution if you ever suggest/consider bundling.


normalperson (Eric Wong) wrote:
> shyouhei@ruby-lang.org wrote:
>  > So, I think it's clear people are interested in replacing _glibc_ malloc, not everything that exist in the whole universe.
>  > 
>  > Let's discuss how we achieve that.  There can be several ways:
>  > 
>  > - Just enable `--with-jemalloc` default on, only for Linux.
>  >     - pro: This is the easiest to implement.
>  >     - pro: Arguably works well. Already field proven.
>  >     - con: Mandates runtime dependency for libjemalloc on those systems.
>  
>  How about only link against it by default if detected.  It will
>  be like our optional dependency on GMP.

This is the preferred way of course. Specifying `--with-jemalloc` configure option while I still have to add `BuildRequires: jemalloc-devel` on the top of the Ruby package just duplicates the effort.

OTOH, if somebody is building Ruby on their system, they want to be in control and be able to disable jemalloc, although the jemalloc-devel is installed. But that is not the case for building package, since in that time we start with minimal buildroot and add just what is necessary.

normalperson (Eric Wong) wrote:
> We will depend on distros to enable/disable the dependency on it.

Thx :) I think that at least in Fedora/RHEL case, the decision will be based on this discussion and on the Ruby defaults, unless some glibc maintainer chimes in and provides some great arguments against.

----------------------------------------
Feature #14718: Use jemalloc by default?
https://bugs.ruby-lang.org/issues/14718#change-72635

* Author: mperham (Mike Perham)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
I know Sam opened #9113 4 years ago to suggest this but I'm revisiting the topic to see if there's any movement here for Ruby 2.6 or 2.7.  I supply a major piece of Ruby infrastructure (Sidekiq) and I keep hearing over and over how Ruby is terrible with memory, a huge memory hog with their Rails apps.  My users switch to jemalloc and a miracle occurs: their memory usage drops massively.  Some data points:

https://twitter.com/brandonhilkert/status/987400365627801601
https://twitter.com/d_jones/status/989866391787335680
https://github.com/mperham/sidekiq/issues/3824#issuecomment-383072469

Redis moved to jemalloc many years ago and it solved all of their memory issues too.  Their conclusion: the glibc allocator "sucks really really hard". http://oldblog.antirez.com/post/everything-about-redis-24.html

This is a real pain point for the entire Rails community and would improve Ruby's reputation immensely if we can solve this problem.



-- 
https://bugs.ruby-lang.org/