The document discusses a lightweight connection pooler for PostgreSQL, emphasizing its features such as connection time savings, request queuing, and reduced system load. It also contains several tests that demonstrate performance improvements through various tuning parameters and connection pooling strategies, showing the importance of database optimization. Key benchmarks indicate that proper tuning can significantly enhance performance, especially under higher loads.

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