In theory, jemalloc would have been more conservative in post-boot allocations, keeping memory consumption growing at a lower rate and eventually more stable, due to its focus on handling fragmentation. It wouldn't do much to the baseline memory consumption that Puma/Sidekiq require after boot.
Is this a fair statement? I've never had the chance to try jemalloc myself, so I'm unaware of how it affects the runtime in practice. I've read a few articles here and there.
Sounds like a fair statement. Not sure what we can do about baseline memory requirements on boot.
Though I'm currently using jemalloc on a Standard 1x Heroku dyno (512MB ~ $25/mo) serving about 1.5 million requests/day and it averages 275MB of memory usage with a mean response time of 35ms.
-edit
Note that this is a standard Rails 5+ app using Sidekiq for background jobs. Currently processing about 50k jobs/day.
In theory, jemalloc would have been more conservative in post-boot allocations, keeping memory consumption growing at a lower rate and eventually more stable, due to its focus on handling fragmentation. It wouldn't do much to the baseline memory consumption that Puma/Sidekiq require after boot.
Is this a fair statement? I've never had the chance to try
jemallocmyself, so I'm unaware of how it affects the runtime in practice. I've read a few articles here and there.Sounds like a fair statement. Not sure what we can do about baseline memory requirements on boot.
Though I'm currently using jemalloc on a Standard 1x Heroku dyno (512MB ~ $25/mo) serving about 1.5 million requests/day and it averages 275MB of memory usage with a mean response time of 35ms.
-edit
Note that this is a standard Rails 5+ app using Sidekiq for background jobs. Currently processing about 50k jobs/day.
That's a very efficient Rails app, well done!