DT

Drizzle Team•2y ago

vr7bd

too many clients already, remaining slots reserved for superuser

I have a production deployment where I'm facing this issue. I ran SELECT count(*) FROM pg_stat_activitySELECT count(*) FROM pg_stat_activity and noticed that there are indeed 100 connections which is the max. However, I noticed most of them are idle. Temporarily I've increased the max_connectionsmax_connections to 500. I have couple of questions to which I'm not getting straightforward answers:

1. Why are there so many idle connections? I understand if there are many active connections. But why idle?
2. If there are that many idle connections, shouldn't the connection pool of postgres.js kick in as it says here (https://github.com/porsager/postgres?tab=readme-ov-file#the-connection-pool) that the previous open connection will be used? So my understanding is that the idle connections will be made active with the new queries. Why isn't that happening?
3. Will I have to manually set the idle_timeoutidle_timeout and max_lifetimemax_lifetime values to lower and optimal values for my use case to get rid of idle connections?
4. Along with the increasing max_connectionsmax_connections, should I increase anything else? Do I need something like pg_bouncerpg_bouncer and how would that help?

GitHub

GitHub - porsager/postgres: Postgres.js - The Fastest full featured...

Postgres.js - The Fastest full featured PostgreSQL client for Node.js, Deno, Bun and CloudFlare - porsager/postgres