dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
Runbooks Library/postgresql/#4
Runbook #4
postgresql
PerformanceSEV2 · DEGRADATION15-30 dakika / 15-30 minssuperuser / postgres / rds_superuser

PostgreSQL Slowdown and High Disk Read Triage

Separates slow queries, lock waits, disk reads and temp-file spills to guide the right response.

Related Metrics:M2
Related Scripts:S9S5S16
#slow-query#disk-io#pg_stat_activity#pg_stat_statements#triage

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

- Uygulama p95/p99 sorgu gecikmesi ve disk okuma süresi yükselir; M2 (buffer cache hit oranı) alışılmış seviyesinin altına iner.

- `pg_stat_activity` içinde uzun süren aktif oturumlar veya I/O beklemeleri artar.

2. Business & Technical Impact

İstek zaman aşımı, bağlantı havuzunda birikme ve diğer sorgularda ikincil gecikme oluşabilir. Düşük cache hit oranı tek başına arıza kanıtı değildir.

3. Diagnosis & Root-Cause Analysis

🟢 Read-Only1. Önce baskın bekleme sınıfını ve çalışan sorguyu saptayın:
sql
SELECT wait_event_type, wait_event, state, count(*) AS sessions
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY 1,2,3 ORDER BY sessions DESC;

SELECT pid, datname, usename, now() - query_start AS query_age,
       wait_event_type, wait_event, left(query, 200) AS query
FROM pg_stat_activity
WHERE state = 'active' AND pid <> pg_backend_pid()
ORDER BY query_start NULLS LAST LIMIT 20;
🟢 Read-Only2. Kilit beklemesi baskınsa `pg-lock-chain-blocking` runbook'una yönelin. `Client` beklemesi I/O darboğazı demek değildir. Disk baskısını işletim sistemi metrikleriyle (IOPS/latency) doğrulayın.
🟢 Read-Only3. S9 ile cache oranına trend olarak bakın; indeks/sorgu erişim desenini ve sürüm 13+ / etkin `pg_stat_statements` varsa S5 ile toplam zamanı inceleyin:
sql
SELECT calls, round(total_exec_time::numeric, 1) AS total_ms,
       round(mean_exec_time::numeric, 1) AS mean_ms,
       shared_blks_read, temp_blks_written, left(query, 160) AS query
FROM pg_stat_statements
ORDER BY total_exec_time DESC LIMIT 15;
🟢 Read-Only4. Tek sorgunun planı için üretimde `EXPLAIN (FORMAT TEXT) SELECT ...` kullanın. `EXPLAIN (ANALYZE, BUFFERS)` sorguyu **gerçekten yürütür**; yazan komutlarda rollback bile yan etkileri tamamen temizlemeyebilir. Gerçek üretim verisiyle önce test ortamında deneyin.

4. Remediation & Action Plan

🟡 Reversible1. Yeni başlayan ağır bir raporlama/toplu işi kısıtlayın veya iş sahibiyle mutabık kalıp yalnızca ilgili sorguyu iptal edin:
sql
SELECT pg_cancel_backend(12345); -- PID'i teşhis sorgusundan doğrulayın
🟡 Reversible2. S16 ile diske taşma baskınsa `pg-temp-file-spill` runbook'una geçin; sequential scan ve yüksek `shared_blks_read` baskınsa indeks/istatistik ve erişim desenini inceleyin. İstatistikler bayatsa tablo adı doğrulandıktan sonra:
sql
ANALYZE public.hedef_tablo;
🟡 Reversible3. Yeni bir sorgu dağıtımıyla başladıysa uygulama sürümünü geri alın; önce/sonra plan ve parametreleri kaydedin. Kalıcı çözüm sorgu/indeks tasarımıdır, `shared_buffers` değerini refleks olarak büyütmek değildir.

5. Verification & Health Checks

- Uygulama p95/p99 ve disk latency baz seviyesine döndü; M2 eğilimi stabil. Aktif kuyruk ve temp dosya artışı durdu.

- Müdahale sonrası en az 15 dakika aynı sorgunun tekrar birikmediğini doğrulayın.

6. Rollback & Contingency Plan

- İptal edilmiş sorgu otomatik geri gelmez; uygulama yeniden denemeli. `ANALYZE` istatistikleri değiştirir, eski istatistiklere güvenli genel bir geri alma yoktur; plan regresyonunda DBA incelemesi yapın.

- Dağıtım geri alması uygulama prosedürüne göre gerçekleştirilir.

More POSTGRESQL Runbooks