Pertama, harap baca pertanyaan kanonik kami tentang Perencanaan Kapasitas .
Saran spesifik yang Anda minta adalah saran perencanaan kapasitas, dan Anda harus mengerjakannya sendiri, untuk lingkungan khusus Anda.
Kedua, Anda melihat ini salah.
Jumlah memori (atau sumber daya lainnya) yang Anda miliki tidak menentukan jumlah koneksi yang Anda tentukan, jumlah koneksi yang Anda butuhkan menentukan seberapa besar server yang harus Anda beli.
Persyaratan sumber daya per-koneksi diberikan dalam manual ini dengan sangat rinci, serta dibahas pada Wiki yang Anda tautkan. Cari tahu apa yang dibutuhkan oleh lingkungan Anda (atau tebak dengan cerdas) dan pastikan perangkat keras yang akan Anda jalankan dapat menangani apa yang akan Anda berikan.
Khususnya: batas koneksi dan ukuran kumpulan, Anda harus memiliki koneksi "cukup" untuk memenuhi persyaratan aplikasi Anda - baik di server tunggal atau melalui pool / bouncer.
"Cukup" adalah angka relatif: Aplikasi yang membuat (dan terus-menerus menggunakan kembali) satu koneksi hanya membutuhkan satu koneksi. Aplikasi yang membuat koneksi untuk setiap pengguna akhir yang log in membutuhkan koneksi DB sebanyak yang dimiliki pengguna.
Nilai default untuk Postgres dan pgbouncer
masuk akal sebagai default :
100 koneksi basis data banyak bagi orang biasa yang melempar Postgres ke suatu lingkungan.
Pengembang mungkin tidak akan membutuhkan lebih dari 10. Orang lain akan cukup tahu untuk menambah jumlahnya.
20 koneksi dari pgbouncer
per DB pool berarti Anda bisa mendapatkan 4 pool yang menunjuk pada satu server dan tidak melebihi batas koneksi Postgres default.
Dimungkinkan untuk memiliki banyak sumber daya yang terkumpul dalam pgbouncer
menunjuk pada satu database back-end, dan Anda selalu menginginkan beberapa koneksi yang tersedia di server back-end Anda.
Jika standarnya tidak sesuai untuk lingkungan Anda, Anda diharapkan mengubahnya.
Ingat bahwa koneksi yang terkumpul tidak berarti "selalu ikat setiap koneksi basis data yang tersedia".
Maksud dari pgbouncer
seperti yang Anda perhatikan adalah menggunakan kembali koneksi. Keuntungan efisiensi di sini tidak mengharuskan Anda mengikat setiap koneksi yang tersedia, hanya bahwa Anda tidak memutuskan, menghubungkan kembali, menegosiasikan ulang SSL, mengautentikasi ulang ke database, dan menjalankan kembali permintaan pengaturan koneksi Anda setiap kali.