Been a while since I messed with Rails, but there're usually a few culprits here.
1) What did you configure your connection pool to be in Rails? Your Rails application uses a connection pool to connect to whatever, so if you set Rails to only have 2 connections in its pool that's all it can have and will fail if 2 aren't enough based on the demand. This has nothing to do with your underlying database.
2) What is happening with the connections that are in use? While many people will naively raise their pool numbers, this hits a limit where it still doesn't quite stabilize things and becomes clear it isn't the pool. That is to say if you have queries or odd things happening where your Rails application cannot "release" something back to the pool then you'll always run out. This one can be a little trickier to debug, but is almost always one of the culprits.
I know this isn't as nice an answer as, "Turn this option on," but in my experience with other connection pooling patterns these are the two things that are always at fault.
1) I've been setting my connection pool to my thread count... but based on an answer above, it seems like that may not be enough sometimes. I'm going to try increasing it, we'll see how that goes...
2) I will definitely be digging through my queries to see if I can optimize things.
Could you post somewhere your puma settings? A good practice is to basically multiply thread numbers by process numbers and then leave a margin of free connections to avoid getting to the limit.
My advice is to read this article and implement the suggestions, it has never failed me in the past :D
Been a while since I messed with Rails, but there're usually a few culprits here.
1) What did you configure your connection pool to be in Rails? Your Rails application uses a connection pool to connect to whatever, so if you set Rails to only have 2 connections in its pool that's all it can have and will fail if 2 aren't enough based on the demand. This has nothing to do with your underlying database.
2) What is happening with the connections that are in use? While many people will naively raise their pool numbers, this hits a limit where it still doesn't quite stabilize things and becomes clear it isn't the pool. That is to say if you have queries or odd things happening where your Rails application cannot "release" something back to the pool then you'll always run out. This one can be a little trickier to debug, but is almost always one of the culprits.
I know this isn't as nice an answer as, "Turn this option on," but in my experience with other connection pooling patterns these are the two things that are always at fault.
1) I've been setting my connection pool to my thread count... but based on an answer above, it seems like that may not be enough sometimes. I'm going to try increasing it, we'll see how that goes...
2) I will definitely be digging through my queries to see if I can optimize things.
Thanks!
Could you post somewhere your puma settings? A good practice is to basically multiply thread numbers by process numbers and then leave a margin of free connections to avoid getting to the limit.
My advice is to read this article and implement the suggestions, it has never failed me in the past :D
Configuring Puma, Unicorn and Passenger for Maximum Efficiency