PostgreSQL Autovacuum Ayarları ve Performans

PostgreSQL Autovacuum Ayarları ve Performans Optimizasyonu Rehberi

PostgreSQL veritabanı yönetim sisteminde yüksek performansın ve veri bütünlüğünün korunması için autovacuum mekanizmasının doğru yapılandırılması kritik öneme sahiptir. Bu makalede, MVCC mimarisinden kaynaklanan "bloat" sorununu önlemek, disk alanını geri kazanmak ve sorgu planlayıcısı için istatistikleri güncel tutmak adına autovacuum ayarlarının nasıl optimize edileceğini derinlemesine inceleyeceğiz.

1. Autovacuum Neden Gereklidir? (MVCC ve Bloat Kavramı)

PostgreSQL, eşzamanlı işlemleri yönetmek için MVCC (Multi-Version Concurrency Control) mimarisini kullanır. Bir satır güncellendiğinde, PostgreSQL aslında yeni bir satır versiyonu oluşturur ve eskisini "ölü" olarak işaretler. Eğer bu ölü kayıtlar temizlenmezse:

• Table Bloat: Tablolar gereksiz büyür ve disk alanı israf edilir.
• Performans Kaybı: İndeksler büyür, Sequential Scan işlemleri yavaşlar ve I/O maliyeti artar.
• Transaction ID Wraparound: Kritik bir eşik aşıldığında veritabanı veri kaybını önlemek için kendini kapatabilir.

2. Temel Autovacuum Parametreleri

Autovacuum'un ne zaman ve ne kadar agresif çalışacağını belirleyen ana parametreler postgresql.conf dosyasında bulunur. Aşağıdaki tablo en kritik ayarları özetlemektedir:

3. Performans İçin İleri Düzey Yapılandırma

Büyük ölçekli veritabanlarında varsayılan scale_factor değerleri (0.2) genellikle çok yüksektir. Örneğin, 100 milyon satırlık bir tabloda vacuum tetiklenmesi için 20 milyon satırın değişmesi gerekir. Bu durum, devasa bir bloat oluşmasına neden olur.

3.1. Eşik Değerlerini Optimize Etme

Büyük tablolar için scale factor yerine sabit eşik değerleri (threshold) kullanmak daha mantıklıdır. Bu ayarı tablo bazında spesifik olarak yapabilirsiniz:

-- Büyük bir tablo için autovacuum ayarlarını özelleştirme
ALTER TABLE kullanici_hareketleri SET (
  autovacuum_vacuum_scale_factor = 0.01,
  autovacuum_vacuum_base_threshold = 5000,
  autovacuum_analyze_scale_factor = 0.005,
  autovacuum_analyze_base_threshold = 1000
);

3.2. Maliyet Tabanlı Sınırlandırma (Cost-based Vacuuming)

Autovacuum'un sistemi kilitlememesi için PostgreSQL bir "maliyet" hesabı yapar. autovacuum_vacuum_cost_limit dolduğunda işçi bir süre duraklar. Yoğun yazma alan sistemlerde bu limiti artırmak, vacuum işleminin daha hızlı bitmesini sağlar:

# postgresql.conf ayarları
autovacuum_vacuum_cost_limit = 1000
autovacuum_vacuum_cost_delay = 10ms

4. Autovacuum İzleme ve Teşhis

Sisteminizde autovacuum'un düzgün çalışıp çalışmadığını anlamak için aşağıdaki SQL sorgularını kullanabilirsiniz.

4.1. En Çok Bloat Olan Tabloları Bulma

SELECT
    relname AS tablo_adi,
    n_dead_tup AS olu_kayit_sayisi,
    n_live_tup AS canli_kayit_sayisi,
    (n_dead_tup::float / NULLIF(n_live_tup,0)::float) * 100 AS bloat_orani,
    last_vacuum,
    last_autovacuum
FROM pg_stat_user_tables
WHERE n_dead_tup > 0
ORDER BY n_dead_tup DESC;

4.2. Şu An Çalışan Vacuum İşlemlerini Görme

SELECT pid, datname, relid::regclass, phase, 
       heap_blks_scanned, heap_blks_total 
FROM pg_stat_progress_vacuum;

5. Best Practices (En İyi Uygulamalar)

• Asla Kapatmayın: autovacuum = off komutu veritabanı sağlığı için felakettir. Sadece toplu veri yüklemeleri sırasında geçici olarak kapatılabilir.
• İşçi Sayısını Dengeli Tutun: autovacuum_max_workers sayısını CPU çekirdek sayınıza ve I/O kapasitenize göre artırın (Genellikle 5-10 arası idealdir).
• Loglamayı Açın: Uzun süren vacuum işlemlerini takip etmek için log_autovacuum_min_duration = 250ms ayarını kullanın.
• Bakım Penceresi: Çok yoğun tablolar için manuel VACUUM ANALYZE komutlarını düşük trafikli saatlerde (cron job ile) çalıştırabilirsiniz.

Sonuç

PostgreSQL autovacuum ayarları, "tak ve unut" mantığıyla çalışmamalıdır. Veri büyüklüğünüz ve trafik yoğunluğunuz değiştikçe bu parametreleri periyodik olarak gözden geçirmelisiniz. Doğru yapılandırılmış bir autovacuum, veritabanınızın yıllarca stabil ve hızlı çalışmasını sağlayan en önemli mekanizmadır.