Autovacuum ve Bloat İçin Önce Kanıt Toplayın
Varsayımsal bir örnek düşünün: VPS üzerinde CPU ve disk I/O yükü artıyor, uygulama yavaşlıyor. Autovacuum’un bu yüke katkısını anlamak için logları ve kaynak kullanımını birlikte incelemek gerekir; yüksek yük tek başına autovacuum’un suçlu olduğunu göstermez.
Bu rehber, PostgreSQL’de ölü satır sürümleri ile fiziksel şişkinliği ayırır; autovacuum eşikleri, kaynak bütçesi ve pg_repack ile alan geri kazanma koşullarını ele alır. Ayar açıklamaları PostgreSQL 17’ye, repack örnekleri 1.5.3’e göre hazırlanmıştır. Kurulu sürüm farklıysa aynı değerleri ve kilit davranışını varsaymayın. pg_repack çalışırken de kilitler ve kaynak tüketimi vardır.
Önce ihtiyacı belirleyin: ölü satırların düzenli temizlenmesi, sorgu istatistiklerinin yenilenmesi, işlem kimliklerinin dondurulması ve dosyaların küçültülmesi farklı işlerdir. Bir tabloda boş alan bulunması her zaman sorun değildir; yeni satırlar bu alanı yeniden kullanabilir. Bakım kararını yalnız dosya boyutuna veya bir ölü satır sayacına bağlamayın.
Ölü Satır, Yeniden Kullanılabilir Alan ve Bloat
MVCC nedeniyle güncellenmiş veya silinmiş satırların eski sürümleri, başka işlemler onları görebildiği sürece korunur. Artık gerekmeyen sürümler VACUUM ile temizlenebilir; HOT sayfa budaması gibi bazı temizlikler normal işlemler sırasında da yapılır. Standart VACUUM alanı çoğunlukla tablo içinde yeniden kullanılabilir hâle getirir. Yalnız tamamen boş son sayfalar, gerekli özel kilit alınabilirse dosyadan kesilip işletim sistemine dönebilir.
Bloat değerlendirmesi, mevcut veri ve beklenen büyüme için gerekenden fazla fiziksel alan bulunup bulunmadığıyla ilgilidir. n_dead_tup tahmini ölü satır sayısıdır; bayt cinsinden geri kazanılabilir alan ölçümü değildir. VACUUM sonrasında ölü satır sayısı düşerken dosya boyutu aynı kalabilir. Tablo ve indeks boyutlarını, doluluğu, sorgu planlarını ve tekrar kullanılacak alanı birlikte değerlendirin.
Autovacuum, VACUUM ve gerektiğinde ANALYZE işlerini zamanlar; ANALYZE planlayıcı istatistiklerini, VACUUM ise temizleme ve dondurma işlerini yürütür. Eski açık işlemler, snapshot’lar veya ilgili çoğaltma durumu temizlenebilecek sürümleri sınırlayabilir. Kaynak sınırını artırmadan önce bu engelleri araştırın. VACUUM FULL dosyayı yeniden yazar ve ACCESS EXCLUSIVE kilidiyle diğer erişimleri engeller; pg_repack farklı kilit ve kaynak koşullarıyla bir alternatif olabilir.
Bakım Sinyallerini Fiziksel Ölçümden Ayırın
Aşağıdaki sorgu, incelenecek tabloları önceliklendirmek içindir. Sayılar tahmindir; istatistik sıfırlanması ve güncellenme zamanı sonucu etkileyebilir. En yüksek sayıya sahip tabloyu otomatik olarak repack etmeyin.
SELECT schemaname, relname, n_dead_tup
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;
Ölü satır tahmininin eğilimini, son autovacuum/analyze zamanlarını ve çalışan VACUUM aşamalarını birlikte inceleyin. Uzun işlemler veya kilitler ilerlemeyi geciktirebilir. Kısa bir inceleme dönemi için tüm autovacuum eylemlerini kaydetmek isterseniz aşağıdaki ayar kullanılabilir; kayıt hacmini, erişimi ve saklamayı önceden belirleyin.
# Active postgresql.conf: temporary diagnostic scope
log_autovacuum_min_duration = 0
Bu parametre yeniden yüklenebilir; yetkili yönetici yapılandırmayı doğrulayıp yeniden yükledikten sonra etkin değeri kontrol etmelidir. Sıfır tüm autovacuum eylemlerini kaydeder; örneğin 5s, en az beş saniye süren işleri seçer. İnceleme sonrasında ölçülen ihtiyaca uygun eşiğe dönün. Merkezi VPS log yönetimi rehberi kayıtları ilişkilendirmeye yardımcı olabilir; kuracağınız toplayıcının destek durumunu ayrıca kontrol edin.
pgstattuple fiziksel uzunluk, ölü satır ve boş alan bilgilerini; pgstatindex ise B-tree indeks yapısına ilişkin ölçümleri sağlar. Eklenti ve gereken okuma yetkileri önceden hazırlanmalıdır. Büyük ilişkilerde tarama I/O üretir ve eşzamanlı değişiklikler nedeniyle sonuç tek anlık snapshot değildir. Düzenli vacuum rehberi hangi alanın yeniden kullanılacağını ve hangi durumda yeniden yazım gerekeceğini açıklar.
Autovacuum Eşikleri, Tempo ve Bellek Bütçesi
PostgreSQL 17’de normal vacuum uygunluk eşiği, taban eşik + scale factor × tahmini satır sayısı olarak hesaplanır ve eski sürüm sayısıyla karşılaştırılır. Insert odaklı vacuum için ayrı eşikler vardır. ANALYZE eşiği ise son analizden beri eklenen, güncellenen ve silinen satırları değerlendirir. Düşük scale factor işi daha erken uygun hâle getirebilir; çalışan bulunacağını veya hemen başlayacağını garanti etmez. naptime farklı bir zamanlama ayarıdır.
# PostgreSQL 17: illustrative candidates, not a universal VPS profile
autovacuum = on
autovacuum_naptime = '30s'
# This parameter requires a restart in PostgreSQL 17
autovacuum_max_workers = 3
autovacuum_vacuum_scale_factor = 0.1
autovacuum_vacuum_threshold = 50
autovacuum_analyze_scale_factor = 0.05
autovacuum_analyze_threshold = 50
autovacuum_vacuum_cost_delay = '2ms'
autovacuum_vacuum_cost_limit = 200
maintenance_work_mem = '256MB'
autovacuum_work_mem = '64MB'
# Optional timing instrumentation; measure its platform overhead
# track_io_timing = on
Autovacuum’a özgü cost_delay -1 ise genel vacuum_cost_delay devralınır; PostgreSQL 17 varsayılanı 2ms olduğundan yalnız genel ayarı değiştirmek beklenen etkiyi vermeyebilir. Cost_limit -1 ise genel limit devralınır; küresel autovacuum limiti normalde çalışanlar arasında paylaştırılır, bazı tablo bazlı maliyet ayarları bu dengelemenin dışındadır. Limit veya gecikme gerçek MB/s kotası değildir. Üç çalışan × 64 MiB yaklaşık 192 MiB çalışma alanıdır; süreç ek yükü, sorgular ve elle bakım ayrıca bütçelenir. autovacuum_work_mem -1 olursa her çalışan maintenance_work_mem kullanır.
Değerleri etkin yapılandırma dosyasında değiştirin; yalnız yeniden yüklenebilir parametrelerde reload yeterlidir. PostgreSQL 17’de autovacuum_max_workers için yeniden başlatma planlayın ve pg_settings.context/pending_restart ile etkin değeri doğrulayın. Büyük bir tablo için daha dar kapsamlı aday aşağıdadır. ALTER TABLE kilit gerektirebilir; önce hedefi ve bakım koşullarını inceleyin.
ALTER TABLE public.olaylar SET (
autovacuum_vacuum_scale_factor = 0.02,
autovacuum_analyze_scale_factor = 0.02,
autovacuum_vacuum_threshold = 50,
autovacuum_analyze_threshold = 50
);
Bu örnek sabit 50 satır eşiği değildir; satır sayısının yüzde 2’si de eklenir. Yeni değerleri bakımın tamamlanması, kullanıcı gecikmesi ve kaynak tüketimiyle değerlendirin. Mikro önbellekleme uygun okuma yükünü azaltabilir, ancak ölü satır temizliği, freezing veya eski snapshot engelini ortadan kaldırmaz.
pg_repack İçin Önkoşullar ve Kilit Davranışı
Önce yeniden yazımla gerçekten geri kazanılacak alanı ve operasyon maliyetini ölçün. pg_repack, değişiklikleri kaydeden tetikleyici ve yardımcı tabloyla yeni bir kopya oluşturur, indeksleri kurar ve son değişimleri uygulayıp nesneleri değiştirir. 1.5.3 sürümü başlangıç ve bitişte ACCESS EXCLUSIVE, aradaki tam tablo işlemi boyunca SHARE UPDATE EXCLUSIVE kilidi kullanır. Normal veri işlemleri çoğu aşamada sürebilir; DDL ve çakışan bakım işleri engellenebilir. Kesintisizlik garantisi yoktur.
Bu örnek PostgreSQL 17 ve pg_repack 1.5.3 içindir. İstemci programı, sunucu kitaplığı ve veritabanındaki SQL eklentisi aynı pg_repack sürümüyle eşleşmelidir. Tam tablo repack için PRIMARY KEY veya geçerli, partial/expression olmayan ve bütün anahtar kolonları NOT NULL olan UNIQUE indeks gerekir. Anahtar yoksa araç tam tablo repack yerine kendiliğinden geniş kilitli bir yönteme geçmez. Anahtar eklemek ayrı bir veri ve kilit değişikliğidir.
Paket ve sunucu dosyaları kurulmuş olmalıdır. Yetkili yönetici hedef veritabanında eklentiyi hazırlayıp sürümünü kontrol eder; IF NOT EXISTS mevcut eski sürümü güncellemez:
CREATE EXTENSION IF NOT EXISTS pg_repack;
SELECT extversion FROM pg_extension WHERE extname = 'pg_repack';
İstemci sürümünü ayrıca pg_repack –version ile karşılaştırın. İşlemi süper kullanıcı veya 1.5.3’te –no-superuser-check ile hedef tablo/indekslerin sahibi çalıştırabilir. Aşağıdaki maintenance_owner bu sahiplik koşulunu sağlayan örnek roldür; bayrak yetki kazandırmaz.
Resmi kılavuz, tam repack için hedef tablo ve indekslerin toplam boyutunun yaklaşık iki katı kadar ek boş disk alanı ister. Örneğin toplam 1 GiB hedef için yaklaşık 2 GiB ek alan; buna çalışma sırasında büyüme, değişiklik kayıtları ve WAL payı da eklenir. Hedef tablespace ve WAL diskini, arşivlemeyi ve replikayı kontrol edin. PostgreSQL’e doğrudan bağlanın; bağlantı bilgilerini, yetkileri ve korunan parola dosyası gibi kimlik doğrulama yöntemini hazırlayın. Önce dry-run ile kapsamı listeleyin; bu adım kilit alınabileceğini veya yeterli alan olduğunu kanıtlamaz.
# Scope preview: no table rewrite
pg_repack -h 127.0.0.1 -p 5432 -U maintenance_owner \
-d uygulama -t public.olaylar --no-superuser-check \
--no-order --wait-timeout=60 --no-kill-backend --dry-run
# After reviewing the preview and all operational prerequisites
pg_repack -h 127.0.0.1 -p 5432 -U maintenance_owner \
-d uygulama -t public.olaylar --no-superuser-check \
--no-order --wait-timeout=60 --no-kill-backend
–no-kill-backend, belirtilen sürede gerekli kilit alınamazsa çakışan sorguları iptal etmek yerine tabloyu atlamayı seçer; atlama başarıyla yeniden yazılmış tablo anlamına gelmez. Bu seçenek olmadan zaman aşımı sorgu iptaline, devam eden çakışmada backend sonlandırmaya yol açabilir. Kilit bekleme ve alınmış kilidin kullanıcı etkisini izleyin. –no-order fiziksel sıralama isteğini kaldırır, kaynak tüketimini sıfırlamaz. Ayrıntılar pg_repack resmi projesinde bulunur.
Tek veritabanındaki uygun tablolar için -d veritabanı kullanılır; -t verilmezse kapsam genişler. -a tüm cluster veritabanları içindir ve -d/-t ile birlikte kullanılmaz. Toplu çalıştırmadan önce her hedefin anahtar, sahiplik, alan ve kilit koşullarını ayrı gözden geçirin. MySQL’de çevrimiçi şema değişikliği rehberi benzer planlama konuları taşır; araçların kilit ve geri alma davranışları aynı değildir.
Bakımın Başarı ve Durdurma Ölçütleri
Tutarlı PostgreSQL yedeğini ayrı bir ortamda geri yükleyerek doğrulayın. Yapılandırma geri alma ile veri kurtarma aynı işlem değildir; repack için tek düğmeyle eski fiziksel duruma dönüş varsaymayın. Yedek ve kurtarma planı rehberi kabul edilen veri kaybı ve kurtarma süresini belirlemeye yardımcı olabilir.
Önce küçük bir hedefte gerçek iş yüküne benzer test yapın. Çalışma sırasında serbest alan, WAL, replika gecikmesi, kilit bekleme ve uygulama hataları için karar sınırları belirleyin. pg_repack –jobs ek bağlantılarla indeks kurulumunu paralelleştirir; bir I/O hız sınırlayıcısı değildir. Yoğun yazımlar değişiklik kuyruğunu büyütebilir. Sonuç kodu, günlükler ve atlanan hedefleri incelemeden bakım tamamlandı demeyin.
Gereksiz güncellemeleri azaltmak yeni eski-sürüm üretimini azaltabilir. Uygun fillfactor ve indeks tasarımı da bakım yükünü etkiler; okuma önbelleği tek başına bloat tedavisi değildir. İşlem sonrasında boyutları, sorgu planlarını ve uygulama doğruluğunu karşılaştırın. Başarısız veya kesilmiş repack sonrasında kalan nesneleri resmi sürüm yönergesiyle inceleyin; eklentiyi körlemesine CASCADE ile silmeyin.
Sık Karıştırılan Bakım Kararları
Büyük tablolarda yüzdeye bağlı eşik yüksek olabilir; ancak ölçek katsayısını düşürmek eski snapshot’ları kaldırmaz veya yeni çalışan oluşturmaz. Eşik, zamanlama, kaynak bütçesi ve temizlemeyi engelleyen işlemleri ayrı inceleyin. Ayrıca XID ve multixact yaşlarını izleyin; düşük ölü satır sayısı freezing gereksiniminin bulunmadığını göstermez. Wraparound riski rutin repack işi olarak ele alınmamalıdır.
VACUUM FULL tüm yeniden yazım boyunca güçlü kilit tutar; pg_repack ise daha dar kilit dönemleriyle birlikte ek disk, tetikleyici ve WAL maliyeti getirir. Kararı yalnız “online” etiketine bağlamayın. Anahtar eklenmesi veya indeks kaldırılması gerekiyorsa uygulama kısıtları ve sorgu bağımlılıkları incelenmeli, değişiklik ayrıca test edilmelidir.
Bakım belleğini artırmak her işi hızlandırmaz. VACUUM, indeks kurma, repack bağlantıları ve kullanıcı sorguları aynı kaynakları paylaşabilir; autovacuum için çalışan başına sınır ayrıca geçerlidir. Daha kısa iş süresi ile daha düşük tepe kaynak kullanımı farklı hedeflerdir. İkisini de ölçün ve kapasiteye göre karar verin.
Ölçülen İhtiyaca Göre Bakım Seçin
Autovacuum ayarını, temizliğin yetişmesi ve kullanıcı iş yükünün kabul edilen sınırlar içinde kalması için değerlendirin. Dosya küçültme gerekiyorsa önce fiziksel ölçüm ve yeniden kullanım beklentisini inceleyin. pg_repack ancak sürüm, anahtar, yetki, ek alan ve kilit koşulları sağlandığında adaydır.
Bir seferde sınanabilir değişiklik yapın; etkin değeri, bakımın ilerlemesini ve uygulama etkisini kaydedin. Atlanan veya tamamlanmayan işi başarı saymayın. Resmi vacuum kılavuzunu sürümünüzle birlikte kullanın ve aynı ölçümleri tablo büyümesi veya iş yükü değiştiğinde tekrarlayın.
Son kontrol yalnız boşalan disk değildir: uygulama doğru çalışmalı, düzenli vacuum/analyze sürmeli, işlem kimliği yaşları kontrol altında kalmalı ve kurtarma planı kullanılabilir olmalıdır.
