Skip to main content

> bağlantı_havuzu_açlığı_(starvation),_thread_tükenmesi_ve_zincirleme_çöküşler

Bağlantı Havuzu Açlığı (Starvation), Thread Tükenmesi ve Zincirleme Çöküşler

Tek bir yavaş veritabanı sorgusu neden uygulama sunucusunun tüm bağlantı havuzunu kilitler, thread tükenmesini tetikler ve zincirleme bir şekilde üst servisleri çökerterek felakete yol açar?

Senior (L5)

ÖZET VE TEKNİK CEVAP

Arka plan sunucularında (Node.js, Go, Java Spring Boot) veritabanı iletişimi sabit boyutlu bir Bağlantı Havuzuna (Connection Pool - HikariCP, 20-50 bağlantı) dayanır. İndekssiz yavaş bir sorgu veya satır kilidi sorgu süresini 5 ms'den 10 saniyeye çıkardığında, bağlantı alan iş parçacıkları (threads) kilitlenir. Saniyeler içinde 50 bağlantının tamamı tükenir. Gelen yeni HTTP istekleri boş bağlantı beklerken bu kez web sunucusunun tüm thread havuzunu (Tomcat 200 thread) tüketir. Thread'leri biten sunucu yeni istek kabul edemez ve sağlık kontrolü (health check) çöker. Yük dengeleyici bu sunucuyu 'ölü' sayıp tüm yükü kalan sunuculara aktarır; kalan sunucular da anında kilitlenir ve tüm sistem zincirleme bir domino etkisiyle çöker.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Zincirleme bağlantı havuzu çöküşü 4 aşamada patlak verir: (1) Gecikme Sıçraması: İndekssiz bir kilitlenme sorgu süresini 5 ms'den 5.000 ms'ye çıkarır. (2) Little Kanunu ile Havuzun Kilitlenmesi: Little Kanununa göre ($L = lambda imes W$), saniyede 100 istek gelirken bekleme süresi 5 saniyeye çıkarsa ihtiyaç duyulan eşzamanlı bağlantı 500'e fırlar ve 50'lik havuz saniyede tükenir. (3) Thread Açlığı ve Sağlık Kontrolü Çöküşü: Tüm thread'ler `getConnection()` çağrısında kilitlenir, Kubernetes liveness probları zaman aşımına uğrar. (4) Sürü Yük Devretmesi: Yük dengeleyici çöken pod'ları devreden çıkarıp tüm trafiği kalanlara yıkar ve saniyeler içinde tüm küme çöker.

2. Doğru Kullanım Senaryosu

İlişkisel veritabanı mimarileri (PostgreSQL, MySQL), bağlantı havuzu yöneticileri (HikariCP, PgBouncer, ProxySQL) ve mikroservis API sunucuları.

3. Prodüksiyon Arıza Modları

Bağlantı alma zaman aşımını sonsuz (`connectionTimeout = 0`) bırakmak ve binlerce HTTP thread'inin sonsuza kadar kilitlenip RAM'i tüketerek OOM çöküşü yaratması; bağlantı havuzunu veritabanı CPU/RAM kapasitesinin çok üzerinde açıp doğrudan veritabanı motorunu kilitlemek.

4. Teşhis ve Telemetri Sinyalleri

Loglarda `Connection is not available, request timed out after 30000ms` hatalarının patlaması; veritabanı CPU'su %15 iken aktif bağlantıların %100'e vurması; Kubernetes pod'larının sağlık kontrolü geçemeyip aynı anda restart olması.

5. Önleme ve Mimari Bariyerler

Çok katı ve kısa bağlantı alma zaman aşımı uygulayın (`connectionTimeout = 1000ms`); veritabanı sorgu zaman aşımını zorunlu kılın (`statement_timeout = 2000ms`); PgBouncer gibi ara bağlantı havuzlayıcıları kurun; Kubernetes sağlık kontrolü (health check) uç noktasını veritabanı bağlantı havuzundan tamamen izole edin.

6. Mimari Ödünleşimler (Trade-offs)

Kısa zaman aşımları yavaşlayan istekleri HTTP 503 ile hızlıca reddeder (fail-fast); ancak sistemin %99,9'luk sağlıklı trafiğini korur ve tüm kümenin çökmesini kesinlikle engeller.

Vaka İncelemesi (TinyCTO Örneği)

Bir sosyal ağda indekssiz bir analitik sorgusunun kullanıcı tablosunu kilitlemesi sonucu tüm site çöktü. 40 uygulama pod'unun tamamı 12 saniyede 50'lik bağlantı havuzunu tüketti, 8.000 thread kilitlendi ve yük dengeleyici tüm pod'ları kapattı. Ekip sistemi düzeltti: (1) PostgreSQL'e `statement_timeout = 1500ms` konuldu, (2) Bağlantı alma zaman aşımı 500 ms'ye çekildi, (3) Sağlık kontrolleri veritabanından bağımsız sadece bellek kontrolüne alındı. İndekssiz sorgu tekrar çalıştığında yalnızca o tek istek hata verdi; sitenin geri kalanı %100 kesintisiz çalışmaya devam etti.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Bağlantı Havuzu Açlığı (Connection Pool Starvation) nedir?

Havuzdaki tüm veritabanı bağlantılarının yavaş sorgular tarafından tutulması ve gelen yeni isteklerin bağlantı bulamayarak kilitlenmesidir.
Q2

Kubernetes liveness sağlık kontrolleri neden ASLA veritabanı bağlantı havuzunu sorgulamamalıdır?

Çünkü bağlantı havuzu geçici olarak dolduğunda sağlık kontrolü başarısız olur ve Kubernetes tüm sağlıklı sunucuları aynı anda yeniden başlatarak çöküşü büyütür.

Bağlantı Havuzu Açlığı (Starvation), Thread Tükenmesi ve Zincirleme Çöküşler — Sıkça Sorulan Sorular

Little Kanunu nedir ve veritabanı bağlantı havuzlarına nasıl uygulanır?

Little Kanununa göre ($L = lambda imes W$) eşzamanlılık ($L$), istek hızı ($lambda$) ile gecikmenin ($W$) çarpımıdır. Sorgu gecikmesi 10 ms'den 1 saniyeye çıkarsa, gereken bağlantı sayısı 100 katına fırlar.

Pod başına 500 gibi çok büyük bir bağlantı havuzu boyutu tanımlamak neden bir anti-patterndir?

Çünkü pod başına yüzlerce bağlantı açmak veritabanı CPU'sunu context switching ve kilit çekişmesiyle boğarak veritabanının çökmesine yol açar.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸Slow queries tie up connection pools, cascading into web server thread pool exhaustion.
  • ▸Per Little's Law, a 10x jump in query latency multiplies required connections by 10x.
  • ▸Enforce strict short connection checkout timeouts (500-1000ms) and statement timeouts.
  • ▸Never link Kubernetes liveness/readiness probes to database connection checkout.

Yaygın Yanılgılar

  • ✗Yanılgı: Increasing connection pool size fixes slow database queries (Gerçek: It merely pushes the bottleneck to database CPU context switching).
  • ✗Yanılgı: Applications should wait infinitely for a database connection (Gerçek: Fail-fast with HTTP 503 protects system stability).

Karar Kılavuzu & Önceliklendirme

Set PostgreSQL `statement_timeout` to 2-3 seconds globally on all web API roles. Deploy PgBouncer in transaction pooling mode to multiplex thousands of app connections into 50 database sockets.

Doğrulanmış Kaynaklar & Referanslar