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

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.

Mühendislik Triadı: Doğrudan Teşhis Scriptleri

Bu runbook kriz müdahalesinde darboğazı tespit etmek için önerilen hazır SQL / Shell scriptleri:

Tüm Scriptler (100)
#3 · SQLMaintenance

PostgreSQL Dead Tuple, Bloat ve Autovacuum Durumu Kontrolü

Tablo bazında dead tuple oranını ve son vacuum/analyze zamanlarını gösterir. Autovacuum ayarının yetersiz kaldığı tabloları tespit etmenizi sağlar.

#8 · SQLStorage

PostgreSQL'de En Büyük Tablolar ve İndeks Boyutları

Tablo, indeks ve toplam boyutu tahmini satır sayısıyla sıralar. Kapasite planlaması ve bölümleme adaylarını belirlemek için kullanılır.

#19 · SQLMaintenance

PostgreSQL Çalışan VACUUM İşlemlerinin İlerlemesi

Şu anda çalışan vacuum işlemlerinin hangi fazda olduğunu ve yüzde kaçının tamamlandığını gösterir. Uzun süren bir vacuum'un ne zaman biteceğini tahmin etmeye yarar.

Tetikleyen Alarmlar ve Metrikler
M6PostgreSQL Dead Tuple OranıPostgreSQL

Diğer POSTGRESQL Runbook'ları