Site normal çalışıyor, trafik biraz artıyor ve aniden "çok fazla bağlantı" hatası geliyor. Sunucunuzun belleği boş, işlemcisi rahat — ama veritabanı yeni bağlantı kabul etmiyor.
Bu yazı, bağlantı yönetiminin nasıl çalıştığını ve bu hatanın nasıl önleneceğini ele alıyor.
Neden Sınır Var?
Her veritabanı bağlantısı sunucuda bir maliyet taşır:
- Bellek ayrılır. Her bağlantı için tampon alanları.
- Süreç veya iş parçacığı oluşur.
- Bağlantı kurulumu zaman alır. Kimlik doğrulama dahil.
- Boşta duran bağlantı da kaynak tüketir.
Dördüncü madde çoğu kişinin gözden kaçırdığı noktadır: hiçbir sorgu çalıştırmayan boştaki bir bağlantı bile bellek tutar ve sınıra dahildir.
Bu yüzden veritabanı sunucuları eşzamanlı bağlantı sayısını sınırlar. Sınır olmasaydı, bağlantı sayısı arttıkça sunucu bellek tükenmesine kadar giderdi.
Bağlantı Havuzu Ne Yapar?
Havuz, bağlantıları her istekte kurup kapatmak yerine yeniden kullanır:
- Başlangıçta belirli sayıda bağlantı açılır
- Bir istek geldiğinde havuzdan bağlantı alınır
- İş bitince bağlantı kapatılmaz, havuza iade edilir
- Bir sonraki istek aynı bağlantıyı kullanır
Kazanç iki yönlüdür: bağlantı kurma maliyeti ortadan kalkar ve toplam bağlantı sayısı öngörülebilir bir sınırda kalır.
Havuz dolduğunda yeni istekler bağlantı bekler — hata almak yerine sıraya girer. Bu, ani trafik artışlarında sistemin çökmek yerine yavaşlamasını sağlar.
PHP'de Durum Farklı
Klasik PHP çalışma modelinde havuz mantığı doğrudan uygulanmaz:
| Durum | Davranış |
|---|---|
| Her istek yeni süreç | Bağlantı istek sonunda kapanır |
| Kalıcı bağlantı kullanımı | Süreç ömrü boyunca açık kalır |
| Süreç havuzu | Bağlantı sayısı süreç sayısına bağlanır |
Üçüncü satır kritik bir bağlantı kurar: web sunucusu süreç sayınız, açılabilecek maksimum veritabanı bağlantısı sayısını belirler.
Yani hesap basittir — süreç havuzunuzda elli süreç varsa ve her biri bir bağlantı açıyorsa, elli bağlantıya kadar çıkabilirsiniz. Veritabanı sınırınız otuz ise, hata kaçınılmazdır.
Doğru Sayıyı Belirlemek
Sınırları uyumlu hâle getirmek için yapılacak hesap:
- Web sunucusu maksimum süreç sayısını belirleyin.
- Arka plan işçilerini ekleyin. Onlar da bağlantı açar.
- Zamanlanmış görevleri ekleyin.
- Yönetim erişimi için pay bırakın.
- Toplamı veritabanı sınırının altında tutun.
Dördüncü madde kriz anında hayat kurtarır: tüm bağlantılar tükendiğinde, sorunu incelemek için veritabanına bağlanamazsınız — birkaç bağlantı yönetim için ayrılmalıdır.
İkinci ve üçüncü maddeler ise en sık atlanan kalemlerdir. Kuyruk işçileri ve zamanlanmış görevler sessizce bağlantı tüketir ve hesaba katılmazsa sınır beklenmedik anda aşılır.
Bağlantı Sızıntısı
Bazen sorun sayıda değil, bağlantıların kapanmamasındadır:
- Uzun süren sorgular bağlantıyı meşgul tutar.
- Hata durumunda bağlantı kapatılmayabilir.
- Kalıcı bağlantılar boşta birikir.
- Ölü bağlantılar temizlenmemiş olabilir.
İkinci madde kod kaynaklı en yaygın sorundur: bir istisna oluştuğunda bağlantıyı kapatan kod çalışmazsa, o bağlantı süreç ölene kadar açık kalır.
Dördüncü madde ağ kaynaklıdır — bağlantı koptuğunda veritabanı bunu hemen fark etmeyebilir ve kayıt bir süre daha açık görünür. Boşta kalma zaman aşımı ayarı bu birikimi temizler.
Teşhis Yöntemi
Hata alındığında bakılacaklar:
| Kontrol | Ne gösterir |
|---|---|
| Aktif bağlantı listesi | Kim, ne kadar süredir bağlı |
| Bağlantı durumları | Çalışıyor mu boşta mı |
| Uzun süren sorgular | Tıkanmanın kaynağı |
| Maksimum bağlantı ayarı | Sınır nerede |
| Zirve bağlantı sayısı | Geçmişte ne kadar çıkmış |
İkinci satır sorunu ikiye ayırır: bağlantıların çoğu boştaysa sorun sızıntıdır, çoğu çalışıyorsa sorun yavaş sorgulardır.
Bu ayrım çözümü belirler — birinci durumda kod incelenir, ikinci durumda sorgular optimize edilir.
Kalıcı Çözümler
Sınırı yükseltmek geçici bir çözümdür. Kalıcı yaklaşımlar:
- Sorguları hızlandırın. Kısa süren sorgu bağlantıyı erken bırakır.
- İndeks eksiklerini giderin.
- Önbellek katmanı ekleyin. Veritabanına hiç gitmeyin.
- Bağlantıyı geç açın, erken kapatın.
- Okuma işlerini kopyaya yönlendirin.
Dördüncü madde basit bir kod disiplinidir ama büyük fark yaratır: sayfanın başında açılıp sonuna kadar tutulan bir bağlantı, gerçekte yalnızca birkaç milisaniye kullanılıyor olabilir.
Kaynak ayarlarını kendiniz belirlediğiniz sanal sunucu yapılandırmalarında hem web sunucusu süreç sayısını hem veritabanı bağlantı sınırını uyumlu şekilde ayarlayabilirsiniz — paylaşımlı ortamlarda bu esneklik bulunmaz.
Sonuç
"Çok fazla bağlantı" hatası bir kaynak sorunu değil, bir uyum sorunudur: web sunucusu süreç sayınız, açılabilecek maksimum veritabanı bağlantısını belirler ve bu toplam veritabanı sınırının altında kalmalıdır. Hesaba arka plan işçilerini ve zamanlanmış görevleri de katın; ayrıca birkaç bağlantıyı yönetim için ayırın — tüm bağlantılar tükendiğinde sorunu incelemek için bağlanamazsınız. Teşhiste ilk soru şudur: bağlantılar boşta mı çalışıyor mu?
Sıkça Sorulan Sorular (SSS)
Sunucumun kaynağı boş ama bağlantı hatası alıyorum?
Çünkü sınır kaynak değil, yapılandırmadır. Veritabanı eşzamanlı bağlantı sayısını açıkça sınırlar ve bu sınır aşıldığında yeni bağlantı reddedilir — bellek boş olsa bile. Web sunucusu süreç sayınızla veritabanı sınırınızı karşılaştırın.
Sınırı yükseltmek çözer mi?
Geçici olarak evet ama kalıcı çözüm değil. Her bağlantı bellek tuketir; sınırı yükseltmek sorunu bellek tükenmesine ötelemekten ibarettir. Asıl çözüm sorguları hızlandırmak, önbellek eklemek ve bağlantıları erken bırakmaktır.
Bağlantı sızıntısını nasıl anlarım?
Aktif bağlantı listesindeki durumlara bakın. Bağlantıların çoğu boşta görünüyorsa sorun sızıntıdır — muhtemelen hata durumunda kapatılmayan bağlantılar var. Çoğu çalışıyorsa sorun yavaş sorgulardır.
Arka plan işlerini hesaba katmalı mıyım?
Mutlaka. Kuyruk işçileri ve zamanlanmış görevler de bağlantı açar ve genellikle hesaba katılmaz. Toplam bağlantı bütçenizi hesaplarken web süreçleri, işçiler, zamanlanmış görevler ve yönetim payını birlikte toplayın.
