Skip to content

Conversation

joshleblanc
Copy link
Contributor

This is less of a "this is ready to be merged", and more of an effort to reinvigorate conversation around this feature. I cobbled this together as a proof of concept because I simply couldn't use the multi-process approach on the server I'm trying to deploy to. This is related to #343, and tries to naively reimplement this

I originally stumbled on this feature because I was testing Kamal on a 1GB VPS. The initial deploy would work, however there wasn't enough resource headroom for the second deploy. I narrowed this down to SQ using ~100MB per process, essentially taking up half the available memory on the system.

image

After implementing this change, I saw the application memory drop from ~700MB to ~270MB.

image

The usage is simply placing this in puma.rb

if ENV["SOLID_QUEUE_IN_PUMA"]
  plugin :solid_queue
  solid_queue_mode :async
end

I currently have this deployed to a 1GB droplet - the application is running quickly, background jobs are running, and redeploys are succeeding

@ka8725
Copy link

ka8725 commented Oct 11, 2025

@joshleblanc thanks for this amazing job! I installed the fork in an app hosted on Heroku that servers webhooks from a live application. I've run it as a separate process though (as a worker). My Procfile:

web: bin/rails server -p $PORT -e $RAILS_ENV
worker: bin/jobs --mode=async

So far it looks very good:

image

I used to run the worker before without recurring jobs because it would consume all RAM. Now, even with recurring jobs it takes ~2x less RAM! Thanks for sharing this work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants