PostgreSQL & PgBouncer Pool Sizing Simulator
Kalkulasikan kapasitas ideal pooling PostgreSQL, cegah crash saat traffic spike, dan hemat gigabytes RAM server dengan konfigurasi PgBouncer production-ready.
Spesifikasi Hardware & Aplikasi
ā Rekomendasi 95% aplikasi web (Next.js, Node, Go, Laravel). Koneksi dilepas segera setelah query/transaksi selesai.
Konfigurasi Siap Deploy (pgbouncer.ini)
Optimasi berbasis 8 CPU Cores & 32 GB RAM
; ========================================== ; PgBouncer Configuration Generated by PuluhLabs ; Mode: transaction | High-Throughput Tuning ; ========================================== [databases] * = host=127.0.0.1 port=5432 auth_user=postgres [pgbouncer] logfile = /var/log/postgresql/pgbouncer.log pidfile = /var/run/postgresql/pgbouncer.pid listen_addr = 0.0.0.0 listen_port = 6432 auth_type = scram-sha-256 auth_file = /etc/pgbouncer/userlist.txt ; Connection Limits pool_mode = transaction max_client_conn = 600 default_pool_size = 20 min_pool_size = 5 reserve_pool_size = 5 reserve_pool_timeout = 5.0 max_db_connections = 24 ; Timeouts & Keepalives server_idle_timeout = 600.0 server_connect_timeout = 15.0 server_login_retry = 1.0 client_idle_timeout = 0.0 query_timeout = 120.0
Database Sering Mengalami Error 503 atau Connection Exhaustion?
Konsultasikan audit kinerja dan perancangan High-Availability Postgres cluster bersama PuluhLabs.
Mengapa Rumus Koneksi Postgres Tidak Boleh Asal Diperbesar?
1. PostgreSQL Process Model (Bukan Thread)
Setiap koneksi klien di Postgres menciptakan proses OS terpisah (fork), menghabiskan ~10MB RAM dasar ditambah alokasi work_mem per sort/hash operation. 500 koneksi langsung dapat menghabiskan 6GB+ RAM murni tanpa menjalankan query.
2. CPU Context Switching & Lock Contention
Server dengan 8 core CPU yang dipaksa melayani 500 koneksi konkuren akan mengalami context switching brutal dan lock contention pada shared buffer database, menurunkan throughput hingga 70%.
3. Solusi PgBouncer Multiplexing
PgBouncer menggunakan event loop asynchronous (libevent). 5.000 koneksi frontend aplikasi dapat dimultiplexing secara mulus ke hanya 20-30 koneksi backend Postgres murni dengan latency sub-milidetik.