Craig Kerstiens

Talking with someone the other day that estimated they had about 25,000 idle connections to Postgres. My actual response to them: "holy shit". They double checked, it was only about 12,000 Same day had a conversation with someone saying they didn't need pgbouncer because of activerecord's connection pooling. Let's dig into connection pooling in Postgres. Prior to Postgres 14 every connection to the database consumed memory, roughly 10MB, it may be slightly less but it still wasn't free. Even beyond Postgres 14 there is still various contention that happens when Postgres starts to use a connection. An application pooler maintains a set of connections and hands them out when needed on the application side. These are idle and real connections against the database that indeed do impact performance negatively. In contrast pgbouncer speaks the wire protocol, waits for the begin part of the transaction and then uses a connection. It more strictly manages how many idle ones it's having instead of per web server you're running. pgbouncer up until recently really needed to be run in transaction mode (which meant disabling prepared statements in your application framework). prepared_statement support in pgbouncer was added recently, and now you don't have to disable. Even when running with an older version of pgbouncer with prepared_statements disabled you'd still see a big performance gain. A quick check to know if you'd benefit from pgbouncer, run this query: SELECT count(*), state FROM pg_stat_activity GROUP BY 2; If you're idle account is high (yes this is dependent on your view, but to me if it's above 25-30 range, and especially if active is until half that) then you'd already start to benefit from pgbouncer. If it's at 10,000 then post haste get pgbouncer in place. Finally, you don't have to not use a framework pooler, they're fine, but don't think it replaces a native Postgres connection pooler.

12,357 görüntüleme