Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Connection Pooling in PostgreSQL using pgbouncer

2,679 views

Published on

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.

Published in: Technology
  • Be the first to comment

Connection Pooling in PostgreSQL using pgbouncer

  1. 1. The light weight connection pooler for PostgreSQL and PPAS
  2. 2. • Saves connection time • Can queue the requests • Less no of connections can serve more requests • Low system load
  3. 3.  [databases]  edb = host=127.0.0.1 port=5444 dbname=edb
  4. 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. 5.  psql -p 6432 -U enterprisedb edb
  6. 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. 7.  PAUSE [db];  SUSPEND;  RESUME [db];  KILL db;  RELOAD;  SHUTDOWN;
  8. 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. 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. 10.  query_timeout  query_wait_timeout  client_idle_timeout  idle_transaction_timeout
  11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15.  http://wiki.postgresql.org/wiki/PgBouncer  http://pgfoundry.org/projects/pgbouncer  http://tinyurl.com/edb-pgbouncer  Or just mail me… sameer.kasi200x@gmail.com

×