Connection Pooling in PostgreSQL using pgbouncer
19
The light weight connection pooler for PostgreSQL and PPAS
-
Upload
sameer-kumar -
Category
Technology
-
view
748 -
download
10
description
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.
Transcript of Connection Pooling in PostgreSQL using pgbouncer
The light weight connection pooler for PostgreSQL and PPAS
• Saves connection time
• Can queue the requests
• Less no of connections can serve more requests
• Low system load
[databases]
edb = host=127.0.0.1 port=5444 dbname=edb
[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"
psql -p 6432 -U enterprisedb edb
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
PAUSE [db];
SUSPEND;
RESUME [db];
KILL db;
RELOAD;
SHUTDOWN;
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
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
query_timeout
query_wait_timeout
client_idle_timeout
idle_transaction_timeout
proxy_name= host=hostname port=num dbname=database_name
proxy_name= host=hostname port=num dbname=database_nameuser=username password=pwd
proxy_name= host=hostname port=num dbname=database_namepool_size=n
proxy_name= host=hostname port=num dbname=database_nameconnect_query=query client_encoding=UNICODE
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
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
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
http://wiki.postgresql.org/wiki/PgBouncer
http://pgfoundry.org/projects/pgbouncer
http://tinyurl.com/edb-pgbouncer
Or just mail me…
