Closed bdmac closed 10 years ago
Alternatively and probably a lot more simply maybe we could just specify an absolute upper bound to how many workers we can grow to?
Errr... wait a second maybe I'm just really dumb. I thought PumaAutoTune.max_workers was being used internally to track the currently allowed max workers but it looks like maybe it's also settable at config time to give an initial upper bounds < the default of INFINITY...
The Problem
It seems like puma_auto_tune will lead to problems in an environment like Heroku if you are on a database tier that has a low(ish) number of allowed connections.
The behavior I am seeing upon restarting my app with very low traffic is that puma_auto_tune just keeps growing and growing... I made it up to 9 workers I think before I started bumping into the 512MB dyno limit.
With 9 workers and 16 threads per worker that takes up a theoretical max of 144 database connections. That's for a single web dyno. If you had 2 web dynos or a worker dyno (as we do) you could find yourself in a situation where you're well beyond the cap of 200 connections that many of the lower (even production level) postgres plans come with.
Obviously that's how big the pool is so to actually HIT that you'd have to have a sudden insane flurry of requests but still seems problematic.
Proposed Change
Would it be possible or make sense to allow for setting a maximum thread pool size for a given puma? What I envision is maybe being able to set an ENV var like
ENV[MAX_PUMA_THREADS]=64
and then accounting for that in the puma_auto_tune logic when it tries to grow the number of workers. It would have to calculate max threads per puma (hopefully accessible from puma itself) and multiply that by the proposed new number of workers to make sure you are still <= the max threads. In this example, assuming max threads of 16 per worker we'd have a max number of workers of 4.One could then basically just do the math to figure out what to set the max threads to for puma_auto_tune. E.g.
It's not ideal but at least I would sleep more soundly knowing that I'm not gonna start hitting DB connection pool timeout errors left and right...