25 ms·
This is so awesome. For those wondering why a pooler is needed, Tl;DR containers. It's much more normal to have hundreds of containers running an application
by everfrustrated 5y ago
This is so awesome.
For those wondering why a pooler is needed, Tl;DR containers.
It's much more normal to have hundreds of containers running an application configured to have tens of connections. Now you have thousands.
Each connection costs postgres something on the order of ~2.5MB ram, so once you get into the thousands you're starting to talk real numbers = ~2.5GB
Problems I've had with pgbouncer in the past:
- stats. Any modern tool should natively emit its own statistics in something like statsd format.
- pgbouncer is a single process - I can't throw more CPU cores at it to make it faster.
Problems that I'm still struggling to solve...
We use RDS/Aurora which uses DNS to fail over. Yes applications should handle this. Yes they should retry. Yes devs should have tested this. But in any large company this is a uphill battle involving many teams and apps. Much easier to introduce a proxy layer to handle fast failover. Even better if it can re-try queries that fail transparently to the application.
- levkk 5y agoThank you! Retries are on the road map.
- nsaje 5y agoPgbouncer does have stats, you can get them using the `SHOW STATS` family of commands. You can then either manually scrape them or use something like pgbouncer_exporter[1] for Prometheus. [1] https://github.com/prometheus-community/pgbouncer_exporter https://github.com/prometheus-community/pgbouncer_exporter