dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
Runbook #7
postgresql
MaintenanceSEV3 · PERFORMANS / RİSK15-30 dakika / 15-30 minssuperuser / postgres / rds_superuser

PostgreSQL Bloat ve Autovacuum Ayarı

Dead tuple artışının nedenini ve autovacuum eşiğini değerlendirir; güvenli tablo bazlı ayarla bloat'ın tekrarlamasını önler.

İlişkili Metrik:M6
İlişkili Script:S3S19S8
#autovacuum#dead-tuples#bloat#vacuum

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

- 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. Etki / 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. Teşhis / Diagnosis

🟢 Salt Okunur1. 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;
🟢 Salt Okunur2. İş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.

🟢 Salt Okunur3. 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.
🟢 Salt Okunur4. İ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. Müdahale / Response

🟡 Geri Alınabilir1. Uzun açık transaction'ı sahibine bildirip güvenli şekilde bitirin (ilgili `pg-long-transactions-idle-in-tx`). Anti-wraparound autovacuum'u durdurmayın.
🟡 Geri Alınabilir2. 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.

🟡 Geri Alınabilir3. Kritik tabloda boşluk temizlemek için yoğun olmayan zamanda, transaction bloğu dışında:
sql
VACUUM (VERBOSE, ANALYZE) public.hedef_tablo;
🔴 YÜKSEK RİSK / GERİ ALINAMAZ4. **`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. Doğrulama / Verification

- 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. Geri Alma / Rollback

- 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.

Diğer POSTGRESQL Runbook'ları