search

gaffneyc / heroku-buildpack-jemalloc

Heroku buildpack that installs the Jemalloc memory allocator
BSD 3-Clause "New" or "Revised" License
252 stars 77 forks source link

Not sign of Jemalloc on the rails app #24

Closed rhtaylor closed 3 years ago

rhtaylor commented 3 years ago

I followed the instructions and cannot see any hint of Jemalloc running in the app. On my local machine I was able to use jemalloc with rvm reinstall 2.6.4 --with-jemalloc and I can print to the console that it is in fact running. I am unable to do so with this setup. Either what do you suggest I do to get it running or what command will enable me to verify it is installed?

gaffneyc commented 3 years ago

Take a look at #23. There isn't a good way from within Ruby to tell that jemalloc is loaded because of how it's injected into the environment (think of it as monkey patching the malloc functions). I believe --with-jemalloc links against the library itself but it's not necessary to use jemalloc with Ruby.

rhtaylor commented 3 years ago

malloc vs jemalloc Thank you for the help on this. I added the build pack to the web app. This is for a startup that is GROWING. They were having Heroku R14 memory issues. That lead me to you. Now that I have added your buildpack we are still getting issues. At first the memory use went way down. However It would build over time. Unexpectedly the memory did not go back down at midnight like it had been without the Jemalloc buildpack. It is as if there was not the overnight reset that happens every day.

buildpack https://github.com/gaffneyc/heroku-buildpack-jemalloc.git JEMALLOC_ENABLED true JEMALLOC_VERSION 5.2.1

With this addition The above photo is the result I got. Is this expected behavior? Is there something incorrect? Is this a different Issue and not related to memory allocation and heaps?

gaffneyc commented 3 years ago

@rhtaylor I can't really say anything for sure without digging into the app itself.

My guess is that what you're seeing is fine and probably expected. You've changed the algorithm used to allocate memory from glibc's ptmalloc2 to jemalloc. As with any algorithm change there are different behaviors and trade offs. You app is still allocating the same number of objects as before and those objects require the same amount of space in memory. What's different is that jemalloc does a better job of placing new objects in memory that has already been allocated rather than requesting (allocating) more memory from the operating system (which is why you see a lot of growth and swap on the left).

As for why the memory at start is higher than it was before... I can't really say. That's not something I've seen but as long as there isn't memory pressure it should be fine.