• Registered: 2017-04-09
  • Posts: 15

Topic: jemalloc 5.1.0

Hi Remi,

I noticed that the jemalloc version in EPEL is far behind (v3.6.0, released on March 31, 2014) and that Redis 4.0.11 and 5.0-rc4 depends on this older version of jemalloc. Note that Redis 4.0.11 ships with jemalloc 4.0.3 and Redis 5.0-rc4 ships with jemalloc 5.1.0 (see the deps/jemalloc/VERSION file in the tarballs).

Could you perhaps backport the Fedora one (v5.1.0) to your repo (for RHEL / CentOS)? jemalloc 5.1.0 seems to be a good candidate for applications to upgrade, see the Changelog: "Given the long and successful production runs, this release is likely a good candidate for applications to upgrade, from both jemalloc 5.0 and before".

Thanks for all the great work!

  • Remi
  • Remi
  • Administrateur
  • Offline
  • From: Champagne...
  • Registered: 2009-04-28
  • Posts: 3,834

Re: jemalloc 5.1.0

I will rather think to use to bundled library instead.

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Remi's Website

  • Remi
  • Remi
  • Administrateur
  • Offline
  • From: Champagne...
  • Registered: 2009-04-28
  • Posts: 3,834

Re: jemalloc 5.1.0

New build (5.0.0~RC4-2) available in remi-test use the upstream bundled library.

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Remi's Website

  • Registered: 2017-04-09
  • Posts: 15

Re: jemalloc 5.1.0

Seems to work, thanks!

Redis server v=4.9.104 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=b88bdb55c77de13

Is there a simple way to request an update for jemalloc in EPEL? We're testing libvips in combination with jemalloc 3.6.0 (under heavy load) and see a much better memory usage than the default allocator in glibc.

We'd like to test with jemalloc 5.1.0, but prefer to not build the dependencies ourselves.

  • Remi
  • Remi
  • Administrateur
  • Offline
  • From: Champagne...
  • Registered: 2009-04-28
  • Posts: 3,834

Re: jemalloc 5.1.0

> Is there a simple way to request an update for jemalloc in EPEL?

File a bug on https://bugzilla.redhat.com/

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Remi's Website

  • Registered: 2017-04-09
  • Posts: 15

Re: jemalloc 5.1.0

Thanks! Reported as https://bugzilla.redhat.com/1625747.

  • Registered: 2017-04-09
  • Posts: 15

Re: jemalloc 5.1.0

FYI: https://bugzilla.redhat.com/1625747 is closed as WONTFIX.

https://fedoraproject.org/wiki/EPEL/Gui … ndPolicies
https://fedoraproject.org/wiki/EPEL_Updates_Policy

The behaviour of jemalloc has changed a lot from the 3.x series to the 5.x series. While the API might still be compatible, I presume users fetching jemalloc from epel7 will prefer stable behaviour over new functionality.

According to https://github.com/jemalloc/jemalloc/releases , there are even changes that are incompatible with previous releases.

Also, Jason still keeps a branch for the stable 3.x series, and has said that he still will continue to fix serious bugs.

Based on this, I will not update jemalloc to a newer major release in epel7 unless there appear major bugs that are impossible to fix otherwice.

I think the only solution (at this moment) is to build jemalloc 5.1.0 by myself (I've already done this in the meantime).

  • Remi
  • Remi
  • Administrateur
  • Offline
  • From: Champagne...
  • Registered: 2009-04-28
  • Posts: 3,834

Re: jemalloc 5.1.0

> I think the only solution (at this moment) is to build jemalloc 5.1.0 by myself (I've already done this in the meantime).

So... you also have to rebuild everything that use it.

From my repository, only redis use it, but it already uses the bundled version.

I notice v 3.6 and v 5.1 use a different soname (1 vs 2), so possible to install multiple versions, as I already do for some libraries (libzip5, libicu62, ImageMagick6... and soon libwebp5)

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Remi's Website

  • Registered: 2017-04-09
  • Posts: 15

Re: jemalloc 5.1.0

> So... you also have to rebuild everything that use it.

Or you could switch out the default allocator (glibc's malloc) with LD_PRELOAD:

# Affects all dynamically linked programs; be careful
echo '/usr/lib64/libjemalloc.so' >> /etc/ld.so.preload

This is what I'm currently doing. Although, it's better to only rebuild those packages that benefit from jemalloc. For example:

# nginx
./configure --with-ld-opt="-ljemalloc"

Or to selectively set the environment variable LD_PRELOAD for a program, for example:

LD_PRELOAD="foobar.so" someprogram

> I notice v 3.6 and v 5.1 use a different soname (1 vs 2), so possible to install multiple versions, as I already do for some libraries (libzip5, libicu62, ImageMagick6... and soon libwebp5)

It would be great if you did the same for jemalloc. Long running / critical PHP processes can also benefit from this allocator. For example, I noticed that Swoole can be configured with jemalloc:
https://github.com/swoole/swoole-src/bl … fig.m4#L49

It's your choice; I understand that this may not be fully related to PHP.