PostgreSQL Connection Limit Hatası Nasıl Çözülür?
Web siteniz veya uygulamanız çalışırken bir anda veritabanına bağlanamıyorsa PostgreSQL bağlantı sınırı dolmuş olabilir. Bu durumda kullanıcılar hata sayfasıyla karşılaşabilir, API istekleri başarısız olabilir veya arka plan görevleri beklemeye başlayabilir.
PostgreSQL connection limit hatasını çözmek için önce hangi bağlantı sınırına ulaşıldığını belirlemek gerekir. Ardından açık bağlantılar incelenmeli, uygulamanın bağlantı havuzu düzenlenmeli ve gerekiyorsa sunucu kapasitesine uygun bir limit belirlenmelidir.
PostgreSQL Connection Limit Hatası Nedir?
PostgreSQL, aynı anda kabul edeceği bağlantı sayısını sınırlandırır. Bu sınır dolduğunda aşağıdaki hata mesajlarından biri görülebilir:
FATAL: sorry, too many clients already
FATAL: remaining connection slots are reserved...
Kullanıcı veya veritabanı için ayrıca sınır tanımlanmışsa şu mesajlarla da karşılaşılabilir:
FATAL: too many connections for role "uygulama"
FATAL: too many connections for database "veritabani"
Bu hatalar aynı sorunu işaret etmez. Sunucunun genel bağlantı sınırını artırmak, kullanıcıya özel bir sınırı çözmeyebilir. Ayrıca yönetim işlemleri için ayrılan bağlantılar nedeniyle uygulamalar, toplam max_connections değerine ulaşılmadan da reddedilebilir.
1. Mevcut Bağlantı Limitlerini Kontrol Edin
Ubuntu üzerinde doğrudan kurulu PostgreSQL’e yönetici hesabıyla bağlanmak için:
sudo -u postgres psql
Birden fazla PostgreSQL örneği varsa doğru port ve sunucuya bağlandığınızdan emin olun. Docker veya yönetilen veritabanı hizmetlerinde bağlantı yöntemi farklı olabilir.
PostgreSQL konsolunda genel sınırı kontrol edin:
SHOW max_connections;
SHOW superuser_reserved_connections;
Kullanıcı ve veritabanı sınırlarını görüntüleyin:
SELECT rolname, rolconnlimit
FROM pg_roles
WHERE rolcanlogin;
SELECT datname, datconnlimit
FROM pg_database;
rolconnlimit ve datconnlimit alanlarında -1, ilgili kullanıcı veya veritabanı için ayrı bir sınır tanımlanmadığını belirtir. Sunucunun genel bağlantı sınırı yine geçerlidir.
Yönetici bağlantısı da kurulamıyorsa sürekli yeniden bağlanmayı deneyen uygulama süreçlerini kontrollü olarak azaltın veya durdurun. Böylece inceleme için bağlantı alanı açılabilir.
2. Bağlantıları Hangi Uygulamanın Tükettiğini Bulun
Aşağıdaki sorgu, istemci bağlantılarını kullanıcı, veritabanı, uygulama adı ve durumlarına göre gruplandırır:
SELECT
datname,
usename,
application_name,
state,
COUNT(*) AS baglanti_sayisi
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY datname, usename, application_name, state
ORDER BY baglanti_sayisi DESC;
Sonuçları yorumlarken şu durumlara dikkat edin:
- active: Bağlantı bir sorgu çalıştırıyor; sorgu bir kaynağı bekliyor da olabilir.
- idle: Bağlantı açık, uygulamadan yeni komut bekliyor.
- idle in transaction: İşlem başlatılmış ancak tamamlanmadan beklemeye bırakılmış.
idle bağlantılar tek başına sorun değildir. Bağlantı havuzları, yeniden kullanmak üzere boşta bağlantı tutabilir. Uzun süre idle in transaction durumunda kalan oturumlar ise ayrıca incelenmelidir.
3. Gereksiz Bağlantıları Kontrollü Şekilde Kapatın
Bağlantıların ayrıntılarını görmek için:
SELECT
pid,
usename,
application_name,
client_addr,
state,
now() - state_change AS durum_suresi
FROM pg_stat_activity
WHERE backend_type = 'client backend'
AND pid <> pg_backend_pid()
ORDER BY state_change;
Hangi uygulamaya ait olduğunu doğruladığınız ve kapatılması uygun olan tek bir bağlantıyı sonlandırabilirsiniz:
SELECT pg_terminate_backend(12345);
12345 yerine, kontrol ettiğiniz bağlantının PID değerini yazın. Bu işlem bağlantıyı keser ve varsa tamamlanmamış işlemini geri alır. Yetki gerektirir; tüm boşta bağlantıları topluca kapatmak yerine sorunlu oturumu belirleyin.
pg_cancel_backend() yalnızca çalışan sorguyu iptal eder; bağlantıyı kapatmadığı için tek başına bağlantı kotasını boşaltmaz.
Uygulama kapatılan bağlantıları hemen yeniden açıyorsa kalıcı çözüm uygulamanın bağlantı yönetimindedir.
4. Uygulamanın Bağlantı Havuzunu Düzenleyin
Bağlantı sınırının dolmasının yaygın nedenlerinden biri, her uygulama sürecinin kendi havuzunu oluşturmasıdır.
Örneğin 5 uygulama süreci, ayrı ayrı 20 bağlantılık havuz kullanıyorsa toplam ihtiyaç 100 bağlantıya ulaşabilir. Arka plan görevleri, yönetim araçları ve diğer servisler de buna eklenir.
Uygulama tarafında şunları kontrol edin:
- Her istek için yeni havuz oluşturuluyor mu?
- Kullanılan bağlantılar işlem bitince havuza iade ediliyor mu?
- Hata oluştuğunda bağlantılar açık kalıyor mu?
- Uygulama kopyaları veya çalışan süreç sayısı arttığında toplam limit hesaplanıyor mu?
Havuz sınırını yalnızca tek bir uygulama örneğine göre belirlemeyin. Yönetim, izleme ve diğer servisler için de boş bağlantı kapasitesi bırakın.
Çok sayıda istemci bulunan sistemlerde PgBouncer değerlendirilebilir. Transaction pooling modunda veritabanı bağlantısı işlem tamamlanınca havuza geri döner. Ancak bu mod bazı oturuma bağlı özelliklerle uyumlu değildir; uygulamanızla birlikte test edilmelidir.
5. Gerekiyorsa max_connections Değerini Artırın
Bağlantılar düzgün yönetiliyor ancak kapasite yine de yetersiz kalıyorsa genel sınır artırılabilir. Önce etkin yapılandırma dosyasının konumunu öğrenin:
SHOW config_file;
Dosyayı yedekleyin ve mevcut max_connections satırını düzenleyin. Örneğin:
max_connections = 150
150 örnek bir değerdir; her sunucu için önerilen ayar değildir. Daha fazla bağlantı, bellek ve diğer kaynaklara olan ihtiyacı artırabilir. Sadece limiti yükseltmek, bağlantı sızıntısını veya yavaş sorguları çözmez.
Bu ayar için PostgreSQL’in yeniden başlatılması gerekir; yapılandırmayı yeniden yüklemek yeterli değildir. Ubuntu paket kurulumunda önce örnekleri listeleyin:
pg_lsclusters
Örneğin listede sürüm 16, küme adı main ise:
sudo pg_ctlcluster 16 main restart
Komuttaki sürüm ve küme adını kendi çıktınıza göre değiştirin. Yeniden başlatma bağlantıları keser; işlemi bakım zamanında gerçekleştirin. Ardından yeniden bağlanıp değeri doğrulayın:
SHOW max_connections;
Replika kullanıyorsanız bağlantı ayarlarını birlikte planlayın; standby sunucunun max_connections değeri primary sunucudan düşük olmamalıdır.
Hatanın Tekrarlamaması İçin Ne Yapılmalı?
Bağlantı sayısını özellikle yoğun saatlerde izleyin. Uzun süren sorgular ve açık bırakılan işlemler, bağlantıların daha geç serbest kalmasına neden olabilir. Uygulama havuzlarını sınırlandırmak, sorguları iyileştirmek ve kontrollü yeniden deneme kullanmak sorunun tekrarlamasını azaltır.
PostgreSQL için sunucu seçerken yalnızca bağlantı sayısını değil, eşzamanlı çalışan sorguları, bellek ihtiyacını ve disk performansını birlikte değerlendirin. Projenize uygun VDS veya fiziksel sunucu seçenekleri için Ekiphost üzerinden bizimle iletişime geçebilirsiniz.
