Repository navigation
fix: size the connection pool for reuse, not for opening - #14
Merged
Merged
Conversation
Go retains only MaxIdleConns; anything opened above it is closed as soon as the query finishes. The previous settings kept far fewer idle than they were willing to open, so most connections were built per query -- TCP, TLS and Postgres auth each time, against RDS over the internet. MaxIdleConns now matches MaxOpenConns, which is what makes the pool a pool. The sizes are small because the database is: db.t4g.micro allows 79 connections in total and roughly 36 pods share them, against configured ceilings summing to about 935. APIs take 5, consumers 2 -- a consumer processes one message at a time, so 25 could never be used but still counted against the budget. ConnMaxIdleTime moves off 90s, which was reaping connections between requests on light traffic so the pool never warmed up. Lifetime stays bounded so a failover or DNS change is still picked up without a restart.
Contributor
Author
|
🎉 This PR is included in version 1.15.1 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The pool was sized to open connections, not to reuse them.
Go retains only
MaxIdleConns. Anything opened above that is created for one query and closed the moment it finishes — so a pool of 100 open / 10 idle was never reusing 100 connections. It held 10 and rebuilt up to 90, paying a TCP connect, TLS handshake and Postgres auth per query, against RDS over the internet withsslmode=require.ConnMaxIdleTimeat 90s was working against reuse too: on light traffic, connections were reaped between requests and rebuilt on the next one, so the pool never warmed up.Why the numbers are small
The database is small.
db.t4g.microallows 79 connections in total, and roughly 36 pods share them. The configured ceilings summed to about 935.A warm pool of 5 serves more traffic than a churning pool of 25, while claiming a fraction of the budget.
The symptom this explains
Intermittent slow GraphQL responses with no errors. At 48/79 connections the database was not exhausted — requests were waiting on handshakes.
authanduser-servicewere the acute case: each pod was configured for 100, so a single pod could have exhausted the database on its own.🤖 Generated with Claude Code