Mimari ve çalışma modeli
PostgreSQL MVCC, UPDATE ve DELETE sonrasında eski satır sürümlerini hemen dosyadan kaldırmaz. VACUUM yeniden kullanılabilir alanı işaretler, visibility map’i günceller ve transaction ID wraparound’a karşı tuple’ları freeze eder. Autovacuum launcher iş seçer, worker süreçleri tabloları işler; ANALYZE istatistikleri sorgu planlayıcı için ayrıca günceller.
Varsayılan vacuum tetikleyicisi yaklaşık base threshold + scale factor × tablo tuple sayısıdır. Büyük tabloda küçük yüzdelik bile milyonlarca dead tuple bekletebilir; yoğun güncellenen tabloya reloptions ile daha düşük scale factor gerekebilir. Küçük tabloda çok düşük eşik gereksiz sık çalışmayı artırabilir. Freeze ayarları yalnız bloat değil veri güvenliği yaşam döngüsüdür.
Bloat teşhisi n_dead_tup tek başına yapılmaz; istatistikler tahminidir ve reset zamanı önemlidir. Uzun transaction, replication slot veya hot_standby_feedback cleanup’ı engelleyebilir. VACUUM FULL dosyayı küçültür fakat daha güçlü kilit ve ek alan ister; düzenli autovacuum ayarının yerine geçmez.
- 1UPDATE/DELETE ile eski satır sürümü
- 2Autovacuum eşiği ve worker seçimi
- 3VACUUM cleanup/visibility/freeze
- 4Alan yeniden kullanımı ve planner istatistikleri
Tasarım parametreleri
- Tetikleme eşiği
- Tablo değişim hızı ve boyutuna göre threshold + scale factor sonucunu satır cinsinden hesaplayın.
- Worker ve I/O bütçesi
- max workers, cost limit/delay ve maintenance I/O kapasitesini diğer bakım işleriyle birlikte planlayın.
- Uzun transaction
- En eski xmin yaşı ve replication feedback, dead tuple temizliğinin gerçek sınırı olabilir.
- Freeze marjı
- age(relfrozenxid) değerini autovacuum_freeze_max_age’e yaklaşmadan alarm ve bakım penceresiyle izleyin.
Hesap ve uygulama örneği
500 milyon satırlı bir tabloda base threshold 50 ve scale factor 0,2 ise yaklaşık 100.000.050 değişiklik vacuum tetikleyebilir. Günde 25 milyon UPDATE alan tabloda bu dört güne yaklaşır. Tabloya özel 0,01 scale factor yaklaşık 5.000.050 değişiklikte tetikleme sağlar; worker süresi ve I/O etkisi pilotta ölçülür.
Autovacuum dakikada 2 milyon dead tuple temizliyor fakat iş yükü 3 milyon üretiyorsa kuyruk büyür. Yalnız daha sık başlatmak yetmez; worker paylaşımı, indeks maliyeti, uzun transaction ve storage latency aynı zaman serisinde incelenir.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
SELECT relname,n_live_tup,n_dead_tup,last_autovacuum,autovacuum_count
FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 20;
SELECT datname,age(datfrozenxid) FROM pg_database ORDER BY 2 DESC;
SELECT * FROM pg_stat_progress_vacuum;
ALTER TABLE public.events SET (autovacuum_vacuum_scale_factor=0.01, autovacuum_vacuum_threshold=5000);
VACUUM (VERBOSE, ANALYZE) public.events;Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| n_dead_tup sürekli artıyor | Worker kapasitesi yetersiz, vacuum engelli veya tetikleme eşiği geniş olabilir. | pg_stat_user_tables, pg_stat_progress_vacuum ve uzun transaction/slot durumunu eşleyin. |
| VACUUM çalışıyor ama dosya küçülmüyor | Normal VACUUM alanı işletim sistemine döndürmek yerine tablo içinde yeniden kullanılabilir yapar. | Tablo boyutu, free space ve sonraki insert/update davranışını izleyin; kilit etkisini değerlendirmeden VACUUM FULL çalıştırmayın. |
| Wraparound uyarısı oluşuyor | Freeze ilerlemesi engelli veya iş yükü bakım kapasitesini aşmış olabilir. | age(relfrozenxid), oldest xmin, autovacuum log ve progress görünümünü kontrol edin. |
Kabul ve doğrulama kontrolleri
- İstatistik reset zamanını kaydedip tablo değişim hızını ölçün.
- En büyük ve yoğun tablolar için gerçek tetikleme satır sayısını hesaplayın.
- Uzun transaction, prepared transaction ve replication slotları kontrol edin.
- log_autovacuum_min_duration ile süre ve atlanan iş nedenlerini izleyin.
- Tek tablo reloptions değişikliğini bir tam iş döngüsünde pilotlayın.
- Freeze yaşı, sorgu gecikmesi, WAL ve storage latency etkisini değişiklik sonrası karşılaştırın.
İlgili kavramlar
Transaction sınırı
Transaction, uygulamanın belirli işlemleri birlikte başarılı veya başarısız kabul ettiği mantıksal birimdir. Veritabanı içindeki atomiklik, e-posta gönderimi veya farklı servislerdeki değişikliklerin otomatik olarak aynı atomik kapsamda olduğu anlamına gelmez. Commit noktası ve hata sonrasında tekrar denemenin davranışı açık olmalıdır. Aynı isteğin iki kez işlenmesini önlemek için idempotency gereksinimini değerlendirin. Testte ağ kesintisi ve bağlantı kopmasını commit öncesi ve sonrasında ayrı uygulayın; istemcinin hata alması işlemin kesinlikle başarısız olduğu anlamına gelmeyebilir.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Kalıcılaştırma ve güç kaybı
Commit edilmiş verinin güç kaybından sonra korunması veritabanı, işletim sistemi, dosya sistemi, kontrolcü ve diskin yazma garantilerinin birleşimine bağlıdır. Yazma önbelleği ve flush davranışını bilmeden performans için güvenlik ayarlarını kapatmayın. Güç kaybı korumalı depolama faydalıdır fakat bütün zincirin doğru yapılandırıldığını tek başına kanıtlamaz. Üretim yerine kontrollü laboratuvarda arıza ve recovery testi yapın. Veri bütünlüğünü örnek dosya açılmasıyla değil, uygulama kayıtları ve desteklenen tutarlılık kontrolleriyle doğrulayın.
İşlem günlüğü ve recovery zinciri
WAL, redo veya transaction log gibi mekanizmalar, veri değişikliklerinin kalıcılaştırılması ve kurtarılması için sıralı kayıt tutar; ürünler arasında ayrıntılar farklıdır. Veri dosyası kopyası ile işlem günlüklerinin zamanı ve zinciri uyumlu olmalıdır. Günlüklerin bulunması tek başına belirli bir zamana dönülebileceğini kanıtlamaz: başlangıç yedeği ve kesintisiz gerekli günlük aralığı da gerekir. Arşivleme gecikmesini, günlük hacmini ve geri oynatma süresini ölçün. Günlükleri kapasite kazanmak için rastgele silmeyin; saklama ve temizleme ürünün desteklediği yöntemle yapılmalıdır.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.