dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
Runbooks Library/postgresql/#1
Runbook #1
postgresql
AvailabilitySEV1 · CRITICAL OUTAGE15-30 dakika / 15-30 minssuperuser / postgres / rds_superuser

PostgreSQL 'too many connections' Error: Diagnosis and Emergency Response

Walks through resolving rejected new connections when the limit is reached. Finds the responsible app, frees slots safely and covers the permanent fix.

Related Metrics:M1
Related Scripts:S12S1
#connections#max_connections#pgbouncer#incident

Operational Safety & Risk Notice

This runbook contains operational intervention steps; several are write-impacting (KILL, terminate, DROP, RESIZE). Verify in a staging environment first, and apply sequentially in production with verification.

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

1. Symptom & Signals

- İ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. Business & Technical Impact

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

3. Diagnosis & Root-Cause Analysis

🟢 Read-Only1. Superuser için ayrılmış slot ile bağlanın (`superuser_reserved_connections`, varsayılan 3):
bash
psql -U postgres -h <host> -d postgres
🟢 Read-Only2. 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;
🟢 Read-Only3. 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. Remediation & Action Plan

🟡 Reversible1. 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');
🟡 Reversible2. 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.
🟡 Reversible3. 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();
🔴 HIGH RISK / IRREVERSIBLE4. `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. Verification & Health Checks

- 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. Rollback & Contingency Plan

- `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()`.

More POSTGRESQL Runbooks