Базы данных6 мин чтения
Connection pools, and the error that arrives at the worst time
Too many clients is a configuration error, not a capacity one. How pools work, how to size one, and why more connections make things slower.
Эта статья пока на английском. Мы её переводим.
Every database has a maximum number of simultaneous connections, and it is lower than most people assume. Exceeding it does not slow things down gracefully; it produces an error, and it produces it under load, which is when you least want a new failure mode.
Why more is not better
Each connection costs memory and a scheduling slot. Beyond the point where the database can keep them all busy, adding connections adds contention rather than throughput. A pool of ten that stays busy will outperform a pool of a hundred that thrashes.
- Pool size is per process. Four processes with a pool of twenty is eighty connections, not twenty.
- Background workers need their own budget and are usually forgotten in that sum.
- Leave headroom for you to connect with a client when something is wrong.
The leak
A connection acquired and not returned is gone until the process restarts. If your pool exhausts slowly over hours and a restart fixes it, you are not short of capacity; you have a path through the code that forgets to release.