PostgreSQL Neden "Process-per-Connection" Mimarisi Kullanır?
MySQL veya Microsoft SQL Server gibi veritabanları yeni bir istemci bağlandığında hafif bir işletim sistemi iş parçacığı (thread) başlatırken; PostgreSQL, 1980'lerin sonundan gelen Unix felsefesi gereği her istemci için tamamen bağımsız bir işletim sistemi süreci (process fork) oluşturur.
Bu mimari olağanüstü bir bellek izolasyonu sağlar (bir sorgu bellek hatasıyla çökerse diğer istemciler etkilenmez). Fakat her bir postgres süreci:
- Tablo şeması ve katalog önbellekleri için 8 ile 12 MB özel bellek (private memory) ayırır.
- Sorgu çalışırken
work_memsınırına kadar ek sıralama ve karma (hash join) belleği tahsis eder. - 1.000 istemci bağlandığında, sadece istemcilerin boşta (idle) beklemesi bile sunucuda 10 GB RAM tüketir.
100'den Fazla Bağlantıda Neden Performans Çöker? (ProcArrayLock)
Çoğu yazılımcı yüksek trafik aldığında postgresql.conf dosyasındaki max_connections = 1000 yaparak sorunu çözeceğini düşünür. Oysa bu ölümcül bir performans tuzağıdır.
⚠️ ProcArrayLock ve CPU Bağlam Değiştirme Kilitlenmesi
PostgreSQL MVCC (Multi-Version Concurrency Control) mekanizması gereği, her yeni işlem başladığında çalışan diğer tüm aktif süreçlerin anlık görüntüsünü almak için ProcArrayLock adında paylaşımlı bir kilit alır. Aktif bağlantı sayısı CPU çekirdek sayısının 4-5 katını aştığında, CPU çekirdekleri sorgu çalıştırmak yerine kilit sırası beklemeye ve yüzlerce süreç arasında bağlam değiştirmeye (context switching) başlar. Veritabanının saniyede işlediği sorgu sayısı (QPS) hızla düşer.
PgBouncer vs Odyssey: Tek Çekirdek vs Çok Çekirdekli Mimari
Bağlantı havuzlayıcılar (connection poolers), 10.000 istemci ile PostgreSQL arasında durarak istemcileri ~2-3 KB RAM ile karşılar ve arka plandaki PostgreSQL'e yalnızca 20-40 adet gerçek bağlantı açar.
PgBouncer (C & libevent)
Dünya standardıdır. Aşırı hafiftir (10.000 bağlantı sadece ~25 MB RAM tutar). Tek bir CPU çekirdeğinde çalışır. 25.000 QPS altındaki çoğu web sitesi ve SaaS için rakipsiz basitlik ve kararlılık sunar.
Odyssey (Yandex - Multi-Threaded)
Yandex tarafından devasa PostgreSQL kümeleri için C dilinde Mach coroutines kullanılarak geliştirilmiştir. Çok iş parçacıklı (multi-threaded) yapısı sayesinde sunucudaki tüm CPU çekirdeklerini eşit şekilde kullanarak yüz binlerce QPS'e ölçeklenir.
Sıkça Sorulan Sorular (SSS)
PgBouncer veritabanı ile aynı sunucuda mı olmalı?
Evet, genellikle PostgreSQL ile aynı VDS üzerinde 127.0.0.1:6432 portunda çalıştırılır. Böylece PgBouncer ile PostgreSQL arasındaki bağlantılar yerel Unix soket üzerinden sıfır ağ gecikmesiyle gerçekleşir.
Prisma ile Transaction Modu güvenli midir?
Evet. Prisma bağlantı URL'inizin sonuna ?pgbouncer=true parametresi eklediğinizde Prisma otomatik olarak protokol düzeyinde prepared statement oluşturmayı devre dışı bırakır ve sorgular sorunsuz çalışır.