dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
Runbook #1
postgresql
AvailabilitySEV1 · KRİTİK KESİNTİ15-30 dakika / 15-30 minssuperuser / postgres / rds_superuser

PostgreSQL 'too many connections' Hatası: Teşhis ve Acil Müdahale

Bağlantı sınırına ulaşıldığında yeni bağlantıların reddedilmesini adım adım çözer. Sorumlu uygulamayı bulur, güvenli şekilde yer açar ve kalıcı çözümü anlatır.

İlişkili Metrik:M1
İlişkili Script:S12S1
#connections#max_connections#pgbouncer#incident

Operasyonel Güvenlik ve Risk Uyarısı

Bu runbook müdahale adımları içerir; birçok adım yazma etkilidir (KILL, terminate, DROP, RESIZE). Önce test ortamında deneyin, üretimde adımları sırayla ve doğrulayarak uygulayın.

🟢 Salt Okunur (Read-Only)·🟡 Geri Alınabilir (Reversible)·🔴 Yüksek Etkili / Geri Alınamaz (High Impact)

1. Belirti / Symptom

- İstemci hatası: `FATAL: sorry, too many clients already` veya `FATAL: remaining connection slots are reserved for non-replication superuser connections`.

- Uygulamada bağlantı zaman aşımları, 5xx hataları.

- M1 (bağlantı doluluk oranı) %90 üzeri.

2. Etki / Impact

Yeni bağlantılar reddedilir, mevcut oturumlar çalışmaya devam eder. Uygulama kısmen veya tamamen erişilemez olur.

3. Teşhis / Diagnosis

🟢 Salt Okunur1. Superuser için ayrılmış slot ile bağlanın (`superuser_reserved_connections`, varsayılan 3):
bash
psql -U postgres -h <host> -d postgres
🟢 Salt Okunur2. Bağlantıları duruma, kullanıcıya ve uygulamaya göre gruplayın (S12):
sql
SELECT usename, application_name, client_addr, state, count(*) AS conns,
       max(now() - state_change) AS longest_in_state
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY 1,2,3,4
ORDER BY conns DESC
LIMIT 20;
🟢 Salt Okunur3. Yorumlayın:

- Çok sayıda `idle` bağlantı: uygulama havuzu şişmiş veya havuz yok, sızıntı var.

- Çok sayıda `idle in transaction`: transaction kapatılmıyor (S1 ile uzun oturumlara bakın).

- Çok sayıda `active`: sunucu yavaşlamış, sorgular birikiyor. Bu bir bağlantı değil performans sorunudur, `pg-slow-queries-triage` runbook'una geçin.

4. Müdahale / Response

🟡 Geri Alınabilir1. Boşta kalan eski bağlantıları sonlandırarak yer açın (kendi bağlantınızı ve kritik rolleri hariç tutun):
sql
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle'
  AND state_change < now() - interval '10 minutes'
  AND pid <> pg_backend_pid()
  AND usename NOT IN ('postgres','replicator');
🟡 Geri Alınabilir2. Sorumlu uygulamayı (adım 2 sonucu) yeniden başlatmadan önce havuz ayarını düşürün. Bağlantı sızıntısı varsa uygulamayı yeniden başlatmak geçici çözümdür.
🟡 Geri Alınabilir3. Otomatik temizlik için zaman aşımı ayarlayın (yeniden başlatma gerekmez, `reload` yeter):
sql
ALTER SYSTEM SET idle_in_transaction_session_timeout = '5min';
ALTER SYSTEM SET idle_session_timeout = '15min';   -- PG 14+
SELECT pg_reload_conf();
🔴 YÜKSEK RİSK / GERİ ALINAMAZ4. `max_connections` değerini artırmak **yeniden başlatma** gerektirir ve bellek tüketimini artırır. Acil durumda son çare olarak, `work_mem × bağlantı sayısı` etkisini hesaplayarak yapın.

5. **Kalıcı çözüm:** PgBouncer (transaction pooling) ekleyin; uygulama başına havuz boyutunu `(çekirdek × 2) + disk sayısı` civarında tutun.

5. Doğrulama / Verification

- M1 değeri %70'in altına döndü.

- Yeni bağlantılar başarıyla açılıyor, uygulama hataları durdu.

- 15 dakika boyunca tekrar eden doluluk yok.

6. Geri Alma / Rollback

- `pg_terminate_backend` geri alınamaz; etkilenen oturumlar bağlantılarını yeniden kurar.

- Zaman aşımı ayarlarını geri almak için: `ALTER SYSTEM RESET idle_session_timeout;` ardından `pg_reload_conf()`.

Diğer POSTGRESQL Runbook'ları