Invalid conf pair: prof:true

[gummybuns]

Problem

I am trying to do some heap profiling on our application through jemalloc using all of the various prof options similar to the Heap Profiling UseCase on the jemalloc wiki.

Looking through some code it does not build jemalloc with the --enable-prof flag. Which is why I am guessing its not working for me.

heroku-buildpack-jemalloc/bin/compile

Lines 93 to 94 in b393799

	# Configure jemalloc to run in /app/vendor/jemalloc
	./configure --prefix=/app/vendor/jemalloc

Curious if you have any advice for how to get the profiling tools to work or plans to allow for additional configuration options to maybe be passed as environment variables

Logs

heroku config | grep MALLOC
JEMALLOC_ENABLED:                                 true
MALLOC_CONF:                                      prof:true,prof_active:true

heroku logs | grep malloc
2024-12-18T20:03:16.505070+00:00 app[web.2]: <jemalloc>: Invalid conf pair: prof:true
2024-12-18T20:03:16.505074+00:00 app[web.2]: <jemalloc>: Invalid conf pair: prof_active:true
2024-12-18T20:03:16.508180+00:00 app[web.2]: <jemalloc>: Invalid conf pair: prof:true
2024-12-18T20:03:16.508180+00:00 app[web.2]: <jemalloc>: Invalid conf pair: prof_active:true
2024-12-18T20:03:16.511202+00:00 app[web.2]: <jemalloc>: Invalid conf pair: prof:true
2024-12-18T20:03:16.511203+00:00 app[web.2]: <jemalloc>: Invalid conf pair: prof_active:true
2024-12-18T20:03:16.514084+00:00 app[web.2]: <jemalloc>: Invalid conf pair: prof:true
2024-12-18T20:03:16.514084+00:00 app[web.2]: <jemalloc>: Invalid conf pair: prof_active:true
2024-12-18T20:03:16.517053+00:00 app[web.2]: <jemalloc>: Invalid conf pair: prof:true
2024-12-18T20:03:16.517054+00:00 app[web.2]: <jemalloc>: Invalid conf pair: prof_active:true

$ heroku ps:exec --dyno web.1

$ cd vendor/jemalloc/bin/
$ jemalloc-config --config
--prefix=/app/vendor/jemalloc

[gaffneyc]

Thanks for reporting the issue! The quickest workaround would be to fork the buildpack and add the --enable-prof option to your fork then deploy that with your application(s).

I'm open to adding --enable-prof to the build process or another solution like JEMALLOC_BUILD_FLAGS. My main concern is whether or not building with the profiler will cause a runtime performance hit even if it's not enabled via MALLOC_CONF. My guess would be no but getting confirmation would be appreciated.

[gummybuns]

Hey thanks for the response. I confirmed that adding --enable-prof solves the problem. Im just a guest here, so I'd be happy to open a PR for whichever way you would prefer between just adding the flag or a JEMALLOC_BUILD_FLAGS.

We actually dont use jemalloc in production at the moment so i cant give any numbers to show a performance impact yet.

fwiw I found this discussion from the jemalloc mailing list:

I need to profile my application running in production. Is it performance safe to build jemalloc with "--enable-prof", start application with profiling disabled and enable it for short time (probably via mallctl() call), when I need?

Yes, you can use jemalloc's heap profiling as you describe, with essentially no performance impact while heap profiling is inactive. You may even be able to leave heap profiling active all the time with little performance impact, depending on how heavily your application uses malloc. At Facebook we leave heap profiling active all the time for a wide variety of server applications; there are only a couple of exceptions I'm aware of for which the performance impact is unacceptable (heavy malloc use, ~2% slowdown when heap profiling is active)

let me know what you prefer

[gummybuns]

one other tangent -

jemalloc's profiling tool jeprof is already included in the bin/ that you have set up. this is working fine using the --text flag like

jeprof --text `which ruby` /path/to/dump.heap

but the powerful thing is to create the graphs using the --svg flag like this guy as an example
https://perlun.eu.org/images/debugging-memory-leak-5-jemalloc-graph.gif

in order to create these types of images, the dot command needs to be installed via the graphviz package. i dont know if you want that to also be baked in to this. it prolly adds some scope for both complexity and maintenance. but figured i would share