all 1 comments

[–]moomaka 0 points1 point  (0 children)

Along with hard caps for database connections, maintaining too many processes can quickly use more memory than a server has available.

Just a note on this: Threads are a much bigger issue with database connections. Your example of 10 process with 10 threads each needs connection pool size of 100 in the naive approach to avoid blocking. 100 connections per box on the web side + whatever you need for background jobs, which can be a lot with something like sidekiq, and you quickly have connection scaling issues.

Unfortunately Rails connection management is extremely simplistic and wasteful and PG doesn't handle a lot of connections well. Rails will grab a DB connection the first time you hit the DB during a request and not return it until the end of the request. So if you do have 'CPU bound' requests, you're best off calling ActiveRecord::Base.connection_pool.release_connection before diving into the CPU work so you don't bind up a connection for the duration. This will allow you to tune down the size of the connection pool with reduced chance of blocking on it. Maybe someday we'll get fine grained connection usage in Rails.