Postgres havuzlayıcı olmadan max_connections

Postgres, bağlantıları için hafif bir iş parçacığı havuzu kullanmaz. Her istemci bağlantısı tam teşekküllü bir sistem sürecini tetikler.

postmaster işlemi, kapatılana kadar her bağlantı denemesi için bu tek oturuma ayrılmış yeni bir ("çatal") oluşturur. Resmi proje belgeleri, mimari temeller bölümünde bu mekanizmayı tam olarak açıklamaktadır (postgresql.org/docs/current/connect-estab.html, “Bağlantı Semantiği” bölümü, 24 Ağustos 2026'da erişildi).

Bu seçimin gerçek bir avantajı vardır: Bir bağlantıdaki çökme diğerlerini etkilemez, her işlem sunucunun geri kalanından izole edilir. Aynı zamanda doğrudan bir maliyeti de vardır: her ek bağlantı, kendi bellek alanı ve çekirdek için kendi içerik değiştirme yüküyle birlikte, zamanlamaya tam bir işletim sistemi süreci ekler.

Belleği etkileyen iki farklı mekanizma vardır ve bunların karıştırılması neredeyse her zaman yanlış tanıya yol açar.

İlki sabittir. Başlangıçta Postgres, bu bağlantıların daha sonra açılıp açılmadığına bakılmaksızın, max_connections değerine göre boyutlandırılmış paylaşılan bellek yapılarını (kilitlemeler, işlem tablosu) ayırır. Bu ayara ilişkin resmi belgeler açıkça şunu belirtmektedir: bunun arttırılması, işletim sisteminizin varsayılan yapılandırmasının izin verdiğinden daha fazla sistem paylaşımlı belleği gerektirebilir (postgresql.org/docs/current/runtime-config-connection.html, 24 Ağustos 2026'da erişildi).

İkincisi değişkendir ve ölçekte çok daha tehlikelidir: work_mem bağlantı başına bir kez değil, sorgu planındaki sıralama veya karma işlemi başına bir kez tahsis edilir. Resmi belgeler bu noktada açıktır: karmaşık bir sorgu bu işlemlerin birçoğunu paralel olarak başlatabilir ve birkaç oturum aynı anda aynısını yapabilir, böylece gerçekte kullanılan belleğin değeri birkaç kat daha fazla olabilir work_mem (postgresql.org/docs/current/runtime-config-resource.html, 24 Ağustos 2026'da erişildi).

Resmi PostgreSQL projesi wiki'si, donanımınızın paralel olarak kaç tane aktif bağlantı verimli bir şekilde işleyebileceğini hesaplamak için bir kıyaslama formülü belgelemektedir; toplamda kaç bağlantı açıldığını değil (wiki.postgresql.org/wiki/Number_Of_Database_Connections, 24 Ağustos 2026'da erişildi).

8 fiziksel çekirdeğe ve SSD depolamaya sahip bir sunucuda formül, verim düşmeye başlamadan önce (8 × 2) + 1 = 17 aktif bağlantı sağlar. Bu rakam genellikle şaşırtıcıdır: Bir uygulamanın pratikte açtığı yüzlerce bağlantıyla karşılaştırıldığında çok küçük görünür. Aşağıdaki paragrafın konusu tam olarak budur.

The number calculated by the formula measures the concurrency that the CPU and disk can absorb, not the number of client connections your application needs to open. A fleet of 20 application processes, each with its own pool of 10 connections, opens 200 simultaneous connections to Postgres even if only 17 of them are actively working at any given time. Without a pooler, max_connections must cover the 200, not the 17. It is this gap that pushes most architectures to add a pooler in transaction mode, even if it means choosing which one (see our comparison PgBouncer, Supavisor and PgCat).

max_connections çalışırken değiştirilemez. Bu bir postmaster bağlam parametresidir: Postgres, paylaşılan belleğini boyutlandırmak için başlangıçta bunu bir kez okur. Yapılandırmanın yeniden yüklenmesi (pg_reload_conf() veya SIGHUP) yeterli değildir; sunucuyu yeniden başlatmanız gerekir.

Yeniden başlatmanın gerekli olup olmadığını doğrulamak için öncelikle mevcut değeri ve içeriğini kontrol edin:

SHOW max_connections;

SELECT name, setting, context
FROM pg_settings
WHERE name = 'max_connections';

-- context='postmaster' yeniden başlatmanın gerekli olduğunu doğrular

Ardından yeni değeri uygulayın ve yeniden başlatın:

ALTER SYSTEM SET max_connections = '300';

-- Postgresql.auto.conf'ta yazılmıştır.
-- Postgres yeniden başlatılana kadar hiçbir etkisi olmaz.

# Sistemd ile
sudo systemctl restart postgresql

# Systemd olmadan, doğrudan pg_ctl ile
pg_ctl restart -D $PGDATA -m fast

max_connections'ın boyutlandırılması yalnızca teorik bir alıştırma değildir. Aurabase, yönetilen Postgres kümelerinde bütçesini şu şekilde ayırıyor:

Özel kümeler: proje başına bir Postgres kümesi

Bu düzeyde (bkz. ayrılmış ve paylaşılan tabankarşılaştırmamız), her proje kendi CloudNativePG kümesini ve örneğin boyutuna göre boyutlandırılmış kendi max_connections bütçesini alır:

Paylaşılan kümeler: bir kuruluşun çeşitli projeleri, paylaşılan bir bütçe

Bu ikinci yolda, aynı kuruluşun tüm projeleri, paylaşılan bir birincilin önünde bir CNPG havuzlayıcı (PgBouncer, transactionmodu) aracılığıyla bağlanır:

Bir kuruluştaki tüm projeler, paylaşılan bir uygulama rolü aracılığıyla bağlanır. Bu nedenle, max_user_connections tek başına bu rolün tüm küme genelinde açabileceği toplam sunucu bağlantılarını sınırlar: bu, yalnızca havuz oluşturucunun kendisiyle olan istemci bağlantılarını sınırlayan max_client_conndeğil, gerçek küme geneli korumadır.

Ancak bu havuz oluşturucu yalnızca SDK uygulama trafiğine hizmet eder. PostgREST, birincil hizmete (-rw) doğrudan bağlı kalır: işlem modunda havuzlama, pgrstadlı özel bir LISTEN kanalını dinleyen şema yeniden yükleme mekanizmasını bozar. Kendi bağlantıları (paylaşılan düzeyde çoğaltma başına 2, tahsis edilmiş düzeyde çoğaltma başına 10), bu nedenle herhangi bir havuzlayıcının dışında doğrudan birincilin max_connections bütçesinde sayılır ve tam olarak aşağıdaki prosedürün 1. adımının içermesi gereken türden "unutulmuş" bağlantıdır.

Bu prosedür herhangi bir araca bağlı değildir: yönetilen veya kendi kendine barındırılan herhangi bir Postgres sunucusu için geçerlidir.

1. Gerçek istemci bağlantılarınızı sayın. Uygulama işlemlerinin sayısı ile dahili havuzlarının boyutunun çarpımı, ayrıca yönetim araçları, çoğaltma ve izleme. max_connections tabanını belirleyen formül değil bu sayıdır.
2. Donanımınızın ideal eşzamanlılığını PostgreSQL wiki'sindeki formülle hesaplayın: (fiziksel çekirdekler × 2) + verimli diskler. Bu şekil, bu bağlantılardan kaçının gerçekte verimi düşürmeden paralel olarak çalışabileceğini gösterir.
3. Maksimum_bağlantıları, superuser_reserved_connections ve uygulama dışında kendi bağlantılarını açan tüm yönetici araçları için kenar boşluğuyla birlikte, 1. adım için gerçek ihtiyacın üzerine ayarlayın.
4. Değişikliği ALTER SYSTEM SET ile uygulayın ve ardından sunucuyu yeniden başlatın. Bu bir postmaster parametresidir: yukarıda açıklandığı gibi basit bir yeniden yükleme yeterli değildir.
5. Zaman içindeki pg_stat_aktivitesini izleyin. Boştaki bağlantıların sayısı etkin bağlantıların sayısını büyük ölçüde aşarsa, bu bir max_connections sorunu değildir: bu, daha yüksek bir sayı değil, sunucunun önünde bir havuzlayıcıya ihtiyacınız olduğunun sinyalidir.

5. adımdaki izleme isteği doğrudan kullanılabilir:

SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state
ORDER BY count(*) DESC;

Değeri ne olursa olsun max_connections artık yeterli olmadığında üç sinyal sistematik olarak geri döner.

1. FATAL: sorry, too many clients already hatası, en yüksek yük sırasında görünürken, pg_stat_activity tarafından görüntülenen bağlantıların çoğunluğu boş durumda.
2. Uygulama, sunucusuz bir ortamda veya bağlantıları Postgres'in bağlantı başına işlem modelinin uyum sağlamak üzere tasarlandığı zamandan çok daha hızlı açıp kapatan geçici çalışanlarla (uç işlevler, kısa işler) çalışır.
3. Yukarıdaki formül ve prosedür zaten uygulanmıştır ve istemci bağlantılarına olan gerçek ihtiyaç, iş_mem veya paylaşılan_buffer'ları tehlikeye atmadan kullanılabilir belleğin ayırabileceği miktarı aşmaya devam etmektedir.

Bu üç durumda doğru cevap, daha yüksek bir max_connections değil, neredeyse her zaman uygulama ile Postgres arasında konumlandırılan bir havuzlayıcıdır. karşılaştırmamız PgBouncer, Supavisor ve PgCat üç seçeneğin ayrıntılarını verir ve işlem modu kılavuzumuz havuzlayıcı devreye girdiğinde en yaygın uzlaşmayı açıklar. Bağlantıların ötesindeki tüm Postgres ayarlamaları için üretim Postgres ayarlama kontrol listemizebakın.