PgBouncer'da Session/Transaction/Statement modlarından hangisini seçmeliyim?

Kısa cevap: Web/mikroservis filosu için Transaction modu — çok-statement’lı trafikte bağlantı yeniden kullanımını en yükseğe çıkaran en pratik seçenek bu.

Kısa cevap

Yaşadığın şey net: 50 pod × min bağlantı, max_connections’ı tüketiyor. PgBouncer tam da bunu çözer — çok sayıda client bağlantısını az sayıda sunucu bağlantısına multiplexler, yani max_connections’ı şişirmeden RAM’i kurtarırsın. Bağlantı havuzu doyduğunda sorgunun kendisinin de pay sahibi olduğunu unutma; sıcak sorgunun index’ini composite index kolon sırası kaydında ele almıştım.

Neden

1. Transaction modu en yüksek yeniden kullanımı verir. Sunucu bağlantısını her transaction sonunda havuza iade eder; iki ardışık transaction farklı sunucu bağlantısına düşebilir. Yüzlerce kısa ömürlü mikroservis isteği için doğru mod budur.

2. Session modu avantajı çöpe atar. Her client’a tüm oturumu boyunca bir sunucu bağlantısı bağlar — yani 50 pod yine 50+ sunucu bağlantısı tutar; multiplexing kazancı kaybolur. Sadece session state’e gerçekten muhtaçsan mantıklı.

3. Statement modu uygulamayı kırar. Bağlantıyı her statement sonunda iade eder, bu da çok statement’lı transaction’ları bozar. Pratikte web uygulaması için kullanılmaz.

Ne yapmalı

1. Transaction modunu seç. Havuzlama kazancının tamamı bu moddan gelir.

2. Prepared statement tuzağını kapat. Protokol seviyesi prepared statement’lar, SET, advisory lock ve LISTEN gibi bağlantıya bağlı durumlar farklı sunucu bağlantısına düşünce kaybolur. Client-side prepared statement’ları kapat (örn. PDO ATTR_EMULATE_PREPARES) ya da PgBouncer 1.21’den beri gelen named prepared statement desteğini kullan — max_prepared_statements sıfırdan büyükken PgBouncer bu komutları transaction ve statement modunda izler ve gerektiğinde yeni sunucu bağlantısında yeniden hazırlar.

3. Statement’lar arası session state’e asla güvenme. Transaction modunda bağlantı kimliği kalıcı değildir.

4. default_pool_size’ı ölçülmüş eşzamanlılığa göre dar tut. Sunucu bağlantısı havuzunu kocaman yapma — multiplexing’in tüm anlamı az sunucu bağlantısıyla çok client’a hizmet etmek.

Sonuç: Ben olsam Transaction modu seçerdim, uygulamada protokol seviyesi prepared statement’ları kapatırdım (ya da PgBouncer’ı 1.21+‘a yükseltirdim) ve default_pool_size’ı ölçülmüş eşzamanlılığa göre dar tutardım. Session modu sorununu çözmez, Statement modu uygulamanı kırar. Dikeyde max_connections ve RAM’i katlamak yerine bağlantı havuzlamayı çözmek çoğu zaman tam da PostgreSQL’i “yeterli” kılan hamledir — bu tartışmanın derinine sade.dev’deki yazıda girdim.