Runbooks Library/postgresql/#7

Runbook #7

postgresql

MaintenanceSEV3 · RISK / WARNING15-30 dakika / 15-30 minssuperuser / postgres / rds_superuser

PostgreSQL Bloat and Autovacuum Tuning

Diagnoses dead tuple growth, evaluates autovacuum triggers and uses safe per-table tuning to prevent recurring bloat.

Related Metrics:M6

Related Scripts:S3 S19 S8

#autovacuum#dead-tuples#bloat#vacuum

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

- M6 dead tuple oranı yüksek; S3 ile belirli tablolarda `n_dead_tup` artarken `last_autovacuum` eskidir.

- Büyük tablolarda sorgu ve indeks boyutu büyür, disk kullanımı artar.

2. Business & Technical Impact

Vacuum yetişmezse tarama ve indeks performansı düşer; XID freeze gecikirse `pg-xid-wraparound-emergency` riski artar. Dead tuple yüzdesi **kesin fiziksel bloat ölçümü değildir**.

3. Diagnosis & Root-Cause Analysis

🟢 Read-Only1. S3 ve S8 ile tablo boyutlarını ve son vacuum zamanlarını karşılaştırın:

sql

SELECT relid::regclass AS tbl, n_live_tup, n_dead_tup,
       last_autovacuum, autovacuum_count,
       pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_stat_user_tables
WHERE n_live_tup > 100000 ORDER BY n_dead_tup DESC LIMIT 25;

🟢 Read-Only2. İşleyen vacuum ve eşikleri inceleyin (S19):

sql

SELECT p.pid, p.relid::regclass, p.phase, p.heap_blks_scanned,
       p.heap_blks_total FROM pg_stat_progress_vacuum p;
SHOW autovacuum_vacuum_scale_factor;
SHOW autovacuum_vacuum_threshold;

Yaklaşık tetikleme = `threshold + scale_factor × tahmini canlı satır`; sürüm ve insert eşiği (`autovacuum_vacuum_insert_*`) ayrı değerlendirilir.

🟢 Read-Only3. Engelleyicileri görün: `SELECT pid, state, now()-xact_start AS age FROM pg_stat_activity WHERE xact_start IS NOT NULL ORDER BY xact_start;` Uzun transaction, prepared transaction, slot `xmin` ve `hot_standby_feedback` vacuum'u sınırlayabilir.

🟢 Read-Only4. İstatistikler tahminidir ve sıfırlanabilir. Gerçek fiziksel bloat için bakım penceresinde `pgstattuple`/`pgstattuple_approx` eklentisini, büyük tablolarda I/O maliyetini dikkate alarak kullanın.

4. Remediation & Action Plan

🟡 Reversible1. Uzun açık transaction'ı sahibine bildirip güvenli şekilde bitirin (ilgili `pg-long-transactions-idle-in-tx`). Anti-wraparound autovacuum'u durdurmayın.

🟡 Reversible2. Büyük ve yoğun güncellenen tabloya tablo bazlı eşikler verin:

sql

ALTER TABLE public.hedef_tablo SET (
  autovacuum_vacuum_scale_factor = 0.02,
  autovacuum_vacuum_threshold = 1000,
  autovacuum_analyze_scale_factor = 0.05
);

Bu ayar tablo metadata'sını değiştirir; yük ve disk I/O eğilimini izleyin.

🟡 Reversible3. Kritik tabloda boşluk temizlemek için yoğun olmayan zamanda, transaction bloğu dışında:

sql

VACUUM (VERBOSE, ANALYZE) public.hedef_tablo;

🔴 HIGH RISK / IRREVERSIBLE4. **`VACUUM FULL` rutin çözüm değildir:** `ACCESS EXCLUSIVE` kilidi, ek disk alanı ve kesinti gerektirir. Gerçekten dosya boyutunu geri kazanmak gerekiyorsa ayrıca bakım penceresi, yedek ve alternatifleri (`pg_repack` ek eklenti) değerlendirin.

5. Verification & Health Checks

- M6 ve S3 `n_dead_tup` trendi düşüyor; `last_autovacuum` güncel; sorgu süreleri iyileşiyor.

- Tablo boyutu sıradan `VACUUM` sonrasında küçülmeyebilir: boş yer iç kullanım için geri kazanılır. Dosya boyutunu ayrıca ölçün.

6. Rollback & Contingency Plan

- Tablo ayarlarını önceki değerlere dönmek için: `ALTER TABLE public.hedef_tablo RESET (autovacuum_vacuum_scale_factor, autovacuum_vacuum_threshold, autovacuum_analyze_scale_factor);` (önceki özel değerler varsa onları yeniden koyun).

- `VACUUM` geri alınamaz, fakat normal koşullarda veri silmez. `VACUUM FULL` kesintisi/ek disk maliyeti geçmişe döndürülemez.

PostgreSQL Bloat and Autovacuum Tuning

Operational Safety & Risk Notice

1. Symptom & Signals

2. Business & Technical Impact

3. Diagnosis & Root-Cause Analysis

4. Remediation & Action Plan

5. Verification & Health Checks

6. Rollback & Contingency Plan

More POSTGRESQL Runbooks

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

PostgreSQL Transaction ID Wraparound Emergency: Freeze Plan

PostgreSQL Lock Chain and Blocking: Find and Resolve the Root Blocker

PostgreSQL Slowdown and High Disk Read Triage