Diske snapshot yazilirken ana process calismaya devam eder; degisen sayfalar CoW ile kopyalanir.
CoW Bellek Amplifikasyonu
29.4x Katlanma
4KB: 765.6 MB vs THP: 22528 MB
Zirve Bellek (RSS) ve OOM
44 GB / 32 GB
Durum: kesin oom_cokusu
p99 Gecikme Dikenleri (Stall)
114 ms
Normal: 0.08 ms (1425x gecikme patlamasi)
Sayfa Tablosu (PTE) Tasarrufu
43.9 MB
44 MB (4KB) → 0.086 MB (2MB)
Kritik Kernel ve Bellek Uyarisi:
Kritik OOM Riski: Mevcut THP ayari altinda snapshot aninda olusan 44 GB RSS bellek, 32 GB sunucu RAM limitini asarak Linux OOM-Killer tarafindan Redis surecinin oldurulmesine neden olacaktir!
Transparent HugePages (THP) vs Statik HugePages Karsilastirmasi
Kriter / Davranis
Transparent HugePages (THP)
Statik HugePages (vm.nr_hugepages)
Hosting & Veritabani Etkisi
Sayfa Tahsis Mekanizmasi
Kernel arka planda (khugepaged) dinamik birlestirir
Boot aninda veya sysctl ile sabit ayrilir
Statik mod sifir compaction gecikmesi sunar
Redis Fork CoW Davranisi
512x Kopyalama: 1 bayt icin 2MB kopyalanir
Redis statik hugepages kullanmaz (4KB standart)
THP Redis'i OOM-Killer ile oldurur; THP=never zorunludur
PostgreSQL Destegi
Gecikme dalgalanmalari ve ani drop yaratir
huge_pages = on ile %10-14 verim artisi
shared_buffers icin statik 2MB sayfa standarddir
Compaction Gecikme Dikenleri
Var: 30 ms - 200 ms arasi p99 patlamasi
Yok: Surekli 0.08 ms mikrosaniye seviyesi
SLA garantili API'lerde THP tail-latency'yi bozar
HostBilgim Mimari Karari:
Redis icin Transparent HugePages kesinlikle 'never' olarak kapatilmalidir. BGSAVE / BGREWRITEAOF aninda 2MB CoW bellek patlamasi sunucuyu OOM krizine sokar ve khugepaged milisaniyelik gecikme dikenleri uretir.
Transparent HugePages (THP) Nedir ve Neden Veritabanlarında Kapatılmalıdır?
Modern x86-64 işlemciler belleği standart olarak 4KB'lik sayfalara böler. Sunucularda RAM 32GB veya 64GB'a çıktığında, milyonlarca 4KB sayfasını takip etmek donanımsal TLB (Translation Lookaside Buffer) önbelleğini doldurur. Linux geliştiricileri, uygulamaların kodunu değiştirmeden 2MB'lik büyük sayfaları otomatik olarak tahsis etmesi için Transparent HugePages (THP) mekanizmasını çekirdeğe ekledi.
Ancak teoride verimi artırması beklenen THP, veritabanı motorları (Redis, PostgreSQL, MongoDB, MySQL) için tam bir operasyonel kabusa dönüşmektedir:
Compaction (Birleştirme) Kilitlenmeleri: Bellek zamanla parçalanır. Çekirdek bitişik 2MB alan bulamadığında khugepaged devreye girer ve sayfaları taşırken spinlock kilitleri uygular. Bu kilitlenme milisaniyeler sürer ve sorguları durdurur.
Copy-on-Write (CoW) Çarpanı: Redis gibi snapshot alan motorlarda küçük bir yazma 2MB'lik bloğun tamamını kopyalatır; RAM tüketimi saniyeler içinde ikiye katlanarak sunucuyu çökertir.
Redis BGSAVE ve OOM-Killer Tuzağı
Redis, tek iş parçacıklı (single-threaded) yapısını koruyarak arka planda disk yedeği (RDB snapshot) oluşturmak içinfork() sistem çağrısını kullanır. Çocuk süreç diske yazarken, ebeveyn süreç gelen istekleri karşılar ve bellekte değişiklik yapar.
THP açıkken (transparent_hugepage=always), ebeveyn sürecin dokunduğu her 2MB'lik alanda çekirdek 4KB yerine 2048KB tahsis eder. 20 GB'lık bir Redis verisetinde aktif yazma yapılıyorsa, ek CoW belleği 10-15 GB'a fırlayabilir. 32 GB RAM'e sahip bir VPS'te toplam bellek 34 GB'a dayanır ve Linux çekirdeğinin OOM-Killer mekanizması en çok bellek tüketen süreç olan Redis'i acımasızca sonlandırır.
Çözüm: Statik HugePages (vm.nr_hugepages) Kullanımı
Büyük sayfaların getirdiği TLB avantajından (işlemci L1/L2 önbellek rahatlaması ve 2D page walk tasarrufu) yararlanmanın doğru yolu, THP'yi kapatıp (never), ihtiyaç duyulan miktarda Statik HugePages tahsis etmektir:
Statik sayfalar boot anında belleğin kesintisiz bloğundan bir kez ayrılır.
Arka planda dinamik compaction veya defragmentation çalışmaz; gecikme dikenleri sıfırlanır.
PostgreSQL huge_pages = on ile shared_buffers alanını bu statik havuzdan tahsis eder; sayfa tablosu boyutu 64MB'den 256KB'ye düşer ve TPS verimi %10-14 artar.