The presentation was presented at 5th Postgres User Group, Singapore. It explain how to setup pgbouncer and also shows a few demonstration graphs comparing the advantages/gains in performance when using pgbouncer instead of direct connections to PostgreSQL database.

1. The light weight connection pooler for PostgreSQL and
PPAS

2. • Saves connection time
• Can queue the requests
• Less no of connections can serve more requests
• Low system load

3.  [databases]
 edb = host=127.0.0.1 port=5444 dbname=edb

4. [pgbouncer]
 listen_port = 6543
 listen_addr = 127.0.0.1
 auth_type = md5
 auth_file = users.txt
 logfile = pgbouncer.log
 pidfile = pgbouncer.pid
 admin_users = enterprisedb
Create a users.txt file
 "enterprisedb" "password"

5.  psql -p 6432 -U enterprisedb edb

6.  psql -p 6432 -U enterprisedb pgbouncer
 Getting help
 pgbouncer=# show help;
 SHOW command:
SHOW LISTS;
SHOW USERS;
SHOW STATS;
SHOW
SERVERS;
SHOW
CLIENTS;
SHOW
POOLS;
SHOW
DATABASES;
SHOW CONFIG

7.  PAUSE [db];
 SUSPEND;
 RESUME [db];
 KILL db;
 RELOAD;
 SHUTDOWN;

8.  auth_file
 auth_type : md5 | crypt | plain | trust | any
 pool_mode: session | transaction | statement
 max_client_conn
 default_pool_size
 min_pool_size
 reserve_pool_size

9.  server_reset_query
 should not contain rollback; good to use DISCARD ALL
 Should be empty when using session pooling
 server_check_delay : to keep the connection available for immediate reuse
 server_check_query: use any query to confirm if server is live
 server_lifetime
 server_idle_timeout
 server_connect_timeout
 server_login_retry

10.  query_timeout
 query_wait_timeout
 client_idle_timeout
 idle_transaction_timeout

11.  proxy_name= host=hostname port=num dbname=database_name
 proxy_name= host=hostname port=num dbname=database_name
user=username password=pwd
 proxy_name= host=hostname port=num dbname=database_name
pool_size=n
 proxy_name= host=hostname port=num dbname=database_name
connect_query=query client_encoding=UNICODE

14. Database Parameters:
• No of Processors: 2
• Memory: 3GB,
• shared_buffer: 256MB,
• effective_cache_size: 750MB
• work_mem=1MB
Key Learning:
Test 1: Basic Setup with tuned shared_buffer and effective_cache_size
- The performance degrades once the load increases beyond a point
Test 2:Tuned other parameters in postgresql.conf
- Performance gain of 36% at Peak load
- The performance continues to degrade [by a margin of 26%] at higher concurrency
Test 3:Transaction Level Connection Pooling
- Performance is more consistent
- Improvement caused by tuning is more prominent with boosted computing
[1CPU- 46% | 2CPU- 80%]
Even after
boosting
computing
power, to get
best of
resources, tuning
and connection
pooling plays a
major role
© 2014 Ashnik Pte Ltd. The benchmark results belong
to Ashnik Pte Ltd, Singapore

16. Database Parameters:
• No of Processors: 2
• Memory: 4.5GB,
• shared_buffer: 750MB,
• effective_cache_size: 2GB
• work_mem=1MB
Key Learning:
Test 1: Basic Setup with tuned shared_buffer[750MB] and effective_cache_size[2GB]
- The performance degrades once the load increases beyond a point
Test 2:Tuned other parameters in postgresql.conf
- Performance gain of 55% at Peak load
- The performance continues to degrade [by a margin of 15%] at higher concurrency
Test 3:Transaction Level Connection Pooling
- Performance is more consistent
- Gain with additional memory is more prominent after tuning and connection pooling
To make best
use of added
memory tuning
and connection
pooling are
important
© 2014 Ashnik Pte Ltd. The benchmark results belong
to Ashnik Pte Ltd, Singapore

18. Database Parameters:
• No of Processors: 2
• Memory: 3GB/4.5GB,
• shared_buffer: 256MB/750MB,
• effective_cache_size:
750MB/2GB
• work_mem=1MB
Key Learning:
Test 1: Un-tuned PostgreSQL [only shared_buffer and effective_cache_size is tuned]
with 4.5 GB RAM
- The performance continues to degrade [by a margin of 38%] at higher concurrency
Test 3:Tune PostgreSQL with Transaction Level Connection Pooling
- Performance is more consistent
- Despite low memory, performance is comparable at low concurrency
- A Tuned database with proper transaction management does better as load increases
Most of your
performance
issues can be
resolved with
proper
application and
database tuning
© 2014 Ashnik Pte Ltd. The benchmark results belong
to Ashnik Pte Ltd, Singapore

19.  http://wiki.postgresql.org/wiki/PgBouncer
 http://pgfoundry.org/projects/pgbouncer
 http://tinyurl.com/edb-pgbouncer
 Or just mail me…
sameer.kasi200x@gmail.com