Mimari ve çalışma modeli
PostgreSQL, veri sayfalarını diske checkpoint sırasında yazar; WAL ise değişikliklerin crash recovery için sıralı kaydını tutar. Checkpoint_timeout veya max_wal_size nedeniyle başlayan checkpoint, çok kısa sürede büyük dirty page hacmini yazarsa uygulama gecikmesi ve storage kuyruk derinliği artabilir. Her yavaş commit checkpoint kaynaklı değildir; WAL flush, veri dosyası yazımı ve lock beklemeleri ayrılmalıdır.
checkpoint_completion_target yazımı checkpoint aralığına yaymaya yardımcı olur. Değeri düşürmek işi daha kısa pencereye sıkıştırıp I/O tepesini artırabilir. max_wal_size büyütmek checkpoint sıklığını azaltabilir fakat crash recovery süresi, disk kullanımı ve replication slot/WAL arşiv sorunlarıyla birlikte değerlendirilmelidir.
PostgreSQL sürümüne göre pg_stat_bgwriter ve pg_stat_checkpointer görünümleri farklı metrikler sunar. Sayaçlar kümülatiftir; başlangıç zamanını bilmeden tek değer yorumlanmamalıdır. Veritabanı metriklerini blok cihaz gecikmesi, fsync süresi, WAL üretim hızı ve uygulama p95/p99 gecikmesiyle aynı zaman ekseninde toplayın.
- 1Transaction ve WAL üretimi
- 2WAL flush
- 3Checkpoint sayfa yazımı
- 4Storage latency ve uygulama yanıtı
Tasarım parametreleri
- Checkpoint nedeni
- Zaman aşımı ve requested checkpoint sayılarını ayırın; sık requested checkpoint için max_wal_size ve WAL üretimini inceleyin.
- WAL hacmi
- Saatlik ve tepe WAL byte hızını ölçün; arşivleme ve replikasyon tüketiminin geride kalmasını ayrıca izleyin.
- Depolama
- Ortalama IOPS yerine p95/p99 yazma gecikmesi, queue depth ve fsync davranışını ölçün.
- Dayanıklılık
- fsync veya full_page_writes kapatmayı performans düzeltmesi saymayın; veri güvenliği sınırlarını koruyun.
Hesap ve uygulama örneği
İş yükü 15 dakikada 120 GiB WAL üretiyorsa ortalama yaklaşık 136 MiB/s olur. 10 dakikalık checkpoint penceresinde aynı zamanda 300 GiB dirty page yazılması gerekiyorsa yalnız WAL değil yaklaşık 512 MiB/s ek veri yazımı söz konusu olabilir. Gerçek değerler cache, full-page write ve background writer davranışına göre ölçülmelidir.
Teşhis penceresinde her 10 saniyede pg_stat_checkpointer/pg_stat_bgwriter, pg_stat_wal ve işletim sistemi disk gecikmesini alın. Log_checkpoints çıktısındaki write ve sync sürelerini uygulama p99 sıçramasıyla eşleyin; ayarı değiştirmeden önce bir tam iş döngüsü baseline kaydedin.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
SELECT now(), checkpoints_timed, checkpoints_req, checkpoint_write_time, checkpoint_sync_time
FROM pg_stat_bgwriter;
SELECT now(), wal_records, wal_fpi, wal_bytes, wal_write_time, wal_sync_time
FROM pg_stat_wal;
SHOW checkpoint_timeout;
SHOW checkpoint_completion_target;
SHOW max_wal_size;Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Düzenli aralıkla p99 sıçrıyor | Checkpoint yazımı kısa pencerede I/O'yu doyuruyor olabilir. | log_checkpoints sürelerini disk latency ve checkpoint sayaçlarıyla eşleyin. |
| WAL dizini hızla büyüyor | Replication slot, archive_command veya uzun recovery tüketicisi WAL'ı tutuyor olabilir. | pg_replication_slots, archiver durumu ve en eski gerekli LSN'i inceleyin. |
| Commit yavaş ama checkpoint sakin | WAL fsync, senkron standby veya storage cache davranışı etkili olabilir. | wait event, wal_sync_time ve standby gecikmesini kontrol edin. |
Kabul ve doğrulama kontrolleri
- Sayaç başlangıç zamanını ve PostgreSQL sürümünü kaydedin.
- Checkpoint nedenini timeout/requested olarak ayırın.
- WAL byte hızını normal ve tepe yükte ölçün.
- Log checkpoint write/sync sürelerini etkinleştirin.
- Storage p99 latency ve queue depth ile korelasyon kurun.
- Ayar değişikliğinden sonra crash recovery ve replica/archive akışını sınayın.
İlgili kavramlar
İş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.
IOPS ve blok boyutu
IOPS saniyedeki I/O işlem sayısını, MB/s ise taşınan veri miktarını anlatır. Aynı IOPS sayısı farklı blok boyutlarında çok farklı bant genişliği üretir. Örneğin 10.000 işlem/s × 4 KiB yaklaşık 39,1 MiB/s eder. Okuma/yazma oranı, rastgele veya sıralı erişim ve veri koruma mekanizması sonucu değiştirir. Bir benchmark sonucunu üretim uygulamasına doğrudan taşımak yerine gerçek blok dağılımını ve eşzamanlılığı ölçün. Diskin yüksek IOPS göstermesi, uygulama yanıtının iyi olduğu anlamına gelmez; gecikme de birlikte incelenmelidir.
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 sırası 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.
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
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.
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; log yokluğu, olay yokluğu şeklinde yorumlanmamalı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.