RAM Balloon ve Bellek Aşırı Tahsisi

Panelde "8 GB RAM" yazan bir sanal sunucun var, ama free -m çıktısında toplam bellek 6 GB görünüyor ve uygulaman hiç beklemediğin bir anda OOM killer tarafından öldürülüyor. Ya da tam tersi: hipervizör üzerinde 128 GB fiziksel bellek varken toplam 200 GB bellek satmışsın ve aylardır hiçbir sorun yaşamamışsın. Bu iki senaryonun ortak açıklaması, sanallaştırmanın en az anlaşılan konularından biri olan bellek aşırı tahsisi (memory overcommit) ve onun en görünür aracı olan RAM balloon sürücüsüdür.

Bu rehberde balloon sürücüsünün fiziksel olarak ne yaptığını, hipervizörün belleği misafir makinelerden nasıl geri aldığını, KSM ve zswap gibi tamamlayıcı tekniklerin devreye ne zaman girdiğini ve en önemlisi kendi sunucunda bu mekanizmaların çalışıp çalışmadığını hangi komutlarla ölçebileceğini anlatacağım. Sonunda "RAM'im nereye gitti" sorusuna tahminle değil, ölçümle cevap verebiliyor olacaksın.

Bellek Aşırı Tahsisi (Overcommit) Ne Demek#

Aşırı tahsis, hipervizörün fiziksel olarak sahip olduğundan daha fazla belleği misafir sanal makinelere vaat etmesidir. Mantık aslında işletim sistemlerinin onlarca yıldır yaptığı şeyin bir üst katmana taşınmış hâlidir: Linux zaten malloc() ile istenen belleği hemen fiziksel sayfalara bağlamaz, gerçekten yazılana kadar bekler. Hipervizör de aynı gözlemi kullanır — çoğu sanal makine tahsis edilen belleğin tamamını asla aynı anda kullanmaz. 8 GB verilen bir web sunucusu gerçekte 2,5 GB dokunulmuş sayfa ile yaşıyorsa, kalan 5,5 GB fiziksel RAM boşuna rezerve edilmiş olur.

Bu boşluğu değerlendirmenin üç ayrı yolu vardır ve hepsi aynı anda açık olabilir:

Bu tablonun en kritik satırı sonuncudan bir öncekidir. Host tarafı swap, aşırı tahsisin son çare mekanizmasıdır ve devreye girdiğinde misafirin hiçbir haberi olmaz: sanal makine kendi RAM'ine eriştiğini sanır, oysa arkada bir disk okuması yapılmaktadır. Mikrosaniye beklediğini sandığın bir bellek erişimi milisaniyeye çıkar. Balloon'un varlık sebebi tam olarak budur — belleği zorla almak yerine misafirden nazikçe istemek, böylece hangi sayfanın feda edileceğine misafir işletim sisteminin kendi çekirdeği karar verebilsin.

Balloon Sürücüsü Fiziksel Olarak Ne Yapar#

Balloon, misafir işletim sisteminin içinde çalışan küçük bir sürücüdür — KVM/QEMU dünyasında virtio_balloon, VMware'de vmmemctl, Hyper-V'de Dynamic Memory bileşeni. Adındaki "balon" metaforu şudur: sürücü misafirin içinde şişer, yani normal bir uygulama gibi bellek ayırır. Ayırdığı bu sayfaları hiçbir şey için kullanmaz; sadece "bu sayfalar bende, kimse dokunmasın" der. Sonra bu sayfaların fiziksel adreslerini hipervizöre bildirir ve hipervizör onları serbestçe başka bir sanal makineye verebilir.

Süreci adım adım izlemek gerekirse:

1. Hipervizör, misafirin hedef bellek boyutunu düşürür (örneğin 8 GB'tan 6 GB'a).
2. Misafirdeki balloon sürücüsü 2 GB'lık sayfa ayırarak "şişer".
3. Misafir çekirdeği, kalan alanda sıkışmaya başlarsa kendi önbelleklerini (page cache, slab) boşaltır — yani ilk feda edilen şey uygulama verisi değil, geri kazanılabilir önbellektir.
4. Balloon sayfaların adreslerini hipervizöre iletir; hipervizör bu fiziksel sayfaları geri alır.
5. Talep tersine dönerse balloon "söner", sayfalar misafire iade edilir.

En kritik nokta üçüncü adımdır: balloon şiştiğinde misafir çekirdeği kendi bellek yönetimi politikasını çalıştırır. Yani hangi sayfanın atılacağına LRU listesine bakarak misafir karar verir. Host swap'ında ise bu karar hipervizöre aittir ve hipervizör, misafirin hangi sayfasının aktif çalışma seti olduğunu bilmez — kritik bir veritabanı indeksini diske atabilir. Balloon'un "iyi", host swap'ının "kötü" olmasının teknik sebebi tam olarak budur.

Libvirt tabanlı bir kurulumda cihazın tanımı sanal makinenin XML'inde şöyle görünür:

<!-- virsh edit <vm-adi> çıktısındaki ilgili blok -->
<memory unit='KiB'>8388608</memory>        <!-- tavan: 8 GB -->
<currentMemory unit='KiB'>6291456</currentMemory>  <!-- şu anki hedef: 6 GB -->
<devices>
  <memballoon model='virtio'>
    <stats period='10'/>                    <!-- 10 sn'de bir istatistik gönder -->
  </memballoon>
</devices>

Buradaki memory ile currentMemory arasındaki fark, balloon'un şişirilebileceği maksimum alandır. stats period satırı olmadan hipervizör misafirin gerçek bellek kullanımını göremez — bu satırı eklemek, teşhis yeteneğin açısından tek satırlık ama çok değerli bir kazançtır.

Misafir Tarafında Balloon'u Tespit Etmek#

Sanal sunucunun içindeysen ve panelde yazan RAM ile free çıktısı uyuşmuyorsa, ilk bakacağın yer balloon sürücüsünün yüklü olup olmadığıdır:

# Sürücü yüklü mü
lsmod | grep -i balloon
# Örnek çıktı:
# virtio_balloon         24576  0

# Cihaz gerçekten var mı
ls -l /sys/devices/virtual/misc/ 2>/dev/null | grep -i balloon
find /sys/devices -name "*balloon*" -maxdepth 4 2>/dev/null

Sürücü yüklüyse, misafirin gördüğü toplam belleğin neden düştüğünü /proc/meminfo üzerinden çapraz kontrol edebilirsin:

# Toplam ve kullanılabilir bellek
grep -E "^(MemTotal|MemFree|MemAvailable|Committed_AS)" /proc/meminfo
# MemTotal:        6291456 kB    <-- panelde 8 GB yazıyorsa fark balloon'dadır
# MemAvailable:    2103488 kB

# Çekirdek günlüğünde balloon hareketi var mı
dmesg | grep -iE "balloon|virtio_balloon"

Burada dikkat edilmesi gereken ince nokta şudur: Linux'ta balloon şiştiğinde bazı yapılandırmalarda MemTotal düşer, bazılarında ise MemTotal sabit kalıp balloon sayfaları kullanılmış gibi görünür. İkinci durumda free -m sana "8 GB'ın 5 GB'ı kullanımda" der ama o 5 GB'ın önemli bir kısmı senin uygulamanda değil, balon içindedir. Bu yüzden free tek başına yeterli bir tanı aracı değildir; /proc/meminfo içindeki Committed_AS değeriyle uygulamalarının gerçekten ne kadar bellek talep ettiğini karşılaştırmak gerekir.

Bellek baskısının uygulamana yansıyıp yansımadığını anlamanın en net yolu ise OOM killer kayıtlarına bakmaktır:

# OOM killer bir şey öldürmüş mü
dmesg -T | grep -i "out of memory"
journalctl -k --since "24 hours ago" | grep -i "killed process"

Bu satırlardan biri çıkıyorsa artık teori değil, ölçülmüş bir sorunla karşı karşıyasın. Genel disk ve kaynak teşhis alışkanlıkları için df, du ve ncdu ile disk kullanımı yazısındaki yaklaşım burada da işe yarar: önce ölç, sonra yorumla.

Hipervizör Tarafından Ölçüm ve Ayarlama#

Kendi hipervizörünü yönetiyorsan (örneğin bir dedicated sunucu üzerinde KVM), misafirin gerçek bellek davranışını virsh dommemstat ile görebilirsin. Bu komut ancak XML'de stats period tanımlıysa anlamlı çıktı verir:

# Tek bir misafirin bellek istatistikleri
virsh dommemstat web01
# actual 6291456        <-- misafire şu an verilen (balloon hedefi)
# swap_in 0
# swap_out 0
# unused 1048576        <-- misafirin kullanmadığı
# available 6291456
# rss 5400128           <-- host tarafında gerçekten tutulan fiziksel bellek

Buradaki rss ile actual arasındaki fark, aşırı tahsisin ne kadar işe yaradığının doğrudan ölçüsüdür. rss sürekli actual'a çok yakınsa, o misafir belleğini gerçekten kullanıyor demektir ve ondan balloon ile bellek almaya çalışmak sadece performansını düşürür.

Balloon hedefini elle değiştirmek için:

# Çalışan misafire 6 GB hedef ver (kalıcı değil)
virsh setmem web01 6291456 --live
# Kalıcı olarak da yaz
virsh setmem web01 6291456 --config
# Maksimum tavanı görmek için
virsh dominfo web01 | grep -E "Max memory|Used memory"

Host tarafında toplam durumu değerlendirirken en kritik metrik, hipervizörün kendi swap kullanımıdır. Misafirlerin toplam rss değeri fiziksel belleği aşmaya başladığında host swap'a düşer ve bu, tüm misafirlerin aynı anda yavaşlamasına yol açar:

# Host swap aktivitesi — si/so sütunları sıfırdan farklıysa alarm
vmstat 1 5
# Hangi süreç ne kadar swap kullanıyor
for p in /proc/*/status; do awk '/^Name|^VmSwap/{printf "%s ", $2}END{print ""}' "$p"; done | sort -k2 -n -r | head

KSM, Zswap ve Diğer Bellek Kazanma Teknikleri#

Balloon tek başına çalışan bir mekanizma değildir. Yanında genellikle KSM (Kernel Samepage Merging) bulunur. KSM, hipervizörün fiziksel bellek sayfalarını tarayıp içerik olarak birebir aynı olanları tek bir fiziksel sayfaya indirmesidir. Aynı işletim sistemi sürümünü çalıştıran on adet sanal makinede çekirdek kodu, paylaşılan kütüphaneler ve sıfırlanmış sayfalar büyük ölçüde aynıdır; KSM bu tekrarları eritir. Kazanç bazen yüzde 20-30'a kadar çıkar ama tarama işi CPU harcar ve bir sayfa değiştiği anda kopyalanması gerekir (copy-on-write).

Host üzerinde KSM'nin durumunu şöyle görürsün:

# KSM açık mı (1 = açık)
cat /sys/kernel/mm/ksm/run
# Kaç sayfa paylaşılıyor, kaç sayfa tasarruf edildi
cat /sys/kernel/mm/ksm/pages_shared
cat /sys/kernel/mm/ksm/pages_sharing
# Kaba tasarruf: pages_sharing * 4096 bayt

Bir diğer tamamlayıcı teknik zswap / zram'dir: swap'a gidecek sayfayı diske yazmak yerine RAM içinde sıkıştırarak tutar. Disk gecikmesinden kurtulursun ama CPU harcarsın. Yoğun CPU kullanan bir iş yükünde zram, sorunu bellekten CPU'ya taşımaktan başka bir işe yaramaz; buna karşılık az CPU kullanan ama bellek dalgalanması yüksek bir uygulamada gerçekten hayat kurtarır.

Son olarak, sanallaştırma katmanında büyük sayfaların (hugepages) balloon ile birlikte kullanılamadığını bilmen gerekir. Bir misafire hugepage tabanlı bellek verirsen, o bellek sabitlenir (pinned) ve balloon o alandan tek sayfa bile geri alamaz. Bu, bilinçli bir tercih olabilir: veritabanı sunucularında hugepage kullanmak TLB isabet oranını artırır ve balloon'un öngörülemezliğini tamamen ortadan kaldırır. Bellek yerleşiminin fiziksel işlemci soketleriyle ilişkisini merak ediyorsan NUMA ve VM performansı yazısı bu tabloyu tamamlıyor.

Sık Yapılan Hatalar ve Tuzaklar#

Yıllardır gördüğüm hataların büyük kısmı birkaç başlıkta toplanıyor. Birincisi, free çıktısını mutlak gerçek saymak. Balloon aktifse free -m sana misafirin o anki penceresini gösterir, satın aldığın tavanı değil. Kapasite planlaması yaparken tavanı dmidecode ya da hipervizör paneli üzerinden doğrula, free ile değil.

İkincisi, aşırı tahsis oranını tek bir sayı olarak düşünmek. "1.5x overcommit güvenlidir" gibi genellemeler tehlikelidir çünkü güvenli oran iş yükünün profiline bağlıdır. Aynı anda hiç zirve yapmayan, birbirinden bağımsız küçük web siteleri barındıran bir hipervizörde 2x rahat çalışır. Ama hepsi gece 03:00'te yedek alan on adet veritabanı sunucusu varsa, 1.1x bile riskli olabilir — çünkü zirveler aynı anda gelir. Doğru soru "oran kaç" değil, "zirveler korelasyonlu mu" sorusudur.

Üçüncüsü, host swap'ı bir emniyet subabı sanmak. Host swap devreye girdiğinde misafir bunu ölçemez; sadece "sunucum yavaşladı" der. Bu durumda misafirin içinde top, iostat, vmstat çalıştırırsın ve hiçbir şey bulamazsın, çünkü darboğaz senin göremediğin bir katmandadır. Aynı gizli-katman etkisi CPU tarafında da vardır ve orada en azından ölçülebilir bir göstergesi bulunur; CPU steal time yazısında bunun nasıl okunacağını anlattım.

Dördüncüsü, balloon sürücüsünü kaldırmak. Bazı yöneticiler "RAM'imi geri alsın" diye virtio_balloon modülünü blacklist eder. Bu, sorunu çözmez; sadece hipervizörün nazik yolunu kapatır. Hipervizör hâlâ bellek sıkışması yaşarsa bu kez seni doğrudan host swap'ına iter ve durum daha da kötüleşir. Balloon'un varlığı bir sorun değil, sorunun nazik yönetim aracıdır.

Beşincisi, uygulama seviyesinde tampon ayarlarını tavana göre yapmak. MySQL'in innodb_buffer_pool_size değerini panelde yazan 8 GB'a göre ayarlarsan ve balloon 6 GB'a indiğinde OOM killer devreye girer. Uygulama tamponlarını her zaman garantili (rezerve) belleğe göre boyutlandır, tavana göre değil.

Ne Zaman Garantili Bellek İstemelisin#

Aşırı tahsis, doğru iş yüklerinde son derece verimlidir; yanlış iş yüklerinde ise sessiz bir performans vergisidir. Karar vermeni kolaylaştıracak pratik bir ayrım şu:

Redis satırı özellikle önemlidir: Redis tüm veri kümesini bellekte tutar ve balloon şiştiğinde ya OOM killer Redis'i öldürür ya da persistence sırasında fork edilen çocuk süreç için gereken alan bulunamaz. Bellek yoğun servisler için garantili bellekli bir VDS ya da bulut sunucu planı, ucuz görünen aşırı tahsisli bir alternatiften uzun vadede daha ekonomiktir — çünkü bir gecelik kesintinin maliyeti aradaki fiyat farkını kolayca aşar.

Sıkça Sorulan Sorular#

Panelde yazan RAM ile free komutunun gösterdiği neden farklı#

Aradaki farkın en yaygın sebebi balloon sürücüsüdür: hipervizör senin sanal makinenin bellek hedefini tavanın altına çekmiştir ve balloon o farkı misafirin içinde tutmaktadır. İkinci olası sebep, çekirdeğin kendisi için ayırdığı alan ve donanım rezervasyonlarıdır; bu genelde birkaç yüz MB'ı geçmez. Aradaki fark yüzlerce MB'ı aşıyorsa lsmod | grep balloon çıktısına ve dmesg kayıtlarına bakarak balloon aktivitesini doğrulayabilirsin.

Bellek aşırı tahsisi sunucumu yavaşlatır mı#

Doğrudan yavaşlatmaz; yavaşlama, aşırı tahsisin sınırının aşıldığı anda başlar. Balloon şiştiğinde misafir önce geri kazanılabilir önbelleğini bırakır ve bu genellikle fark edilmez. Ancak hipervizör fiziksel belleği tükettiğinde host tarafı swap devreye girer ve o noktadan sonra tüm misafirler ciddi biçimde yavaşlar. Kritik olan, hipervizörün swap'a hiç düşmemesidir.

Balloon sürücüsünü kapatmalı mıyım#

Genelde hayır. Sürücüyü kaldırmak hipervizörün bellek talep etme yeteneğini ortadan kaldırır ama bellek sıkışmasını ortadan kaldırmaz; hipervizör bu kez daha yıkıcı olan host swap'ına başvurur. Gerçekten garantili belleğe ihtiyacın varsa çözüm sürücüyü kapatmak değil, sağlayıcından bellek rezervasyonu yapılmış bir plan istemek ya da tek kiracılı bir sunucuya geçmektir.

KSM güvenli mi, veri sızıntısı riski var mı#

KSM aynı içerikli sayfaları birleştirdiği için, teoride sayfa birleşmelerinin zamanlamasını ölçerek başka bir misafirde belirli bir verinin bulunup bulunmadığı çıkarılabilir; akademik yan kanal çalışmaları bunu göstermiştir. Pratikte bu saldırı zor ve gürültülüdür, ama yüksek hassasiyetli ortamlarda KSM'yi kapatmak makul bir tercihtir. Aynı müşteriye ait makineleri gruplayıp KSM'yi yalnızca grup içinde çalıştırmak da yaygın bir orta yoldur.

OOM killer uygulamamı neden öldürüyor, RAM boştu#

free çıktısında görünen "boş" alan çoğu zaman önbellektir ve gerçekten tahsis edilebilir olması gerekmez; ayrıca balloon şişmişse görünen tablo yanıltıcı olur. OOM killer, çekirdek bir tahsis isteğini karşılayamadığı anda devreye girer — bu, ortalamaya değil o milisaniyedeki ani talebe bağlıdır. dmesg -T | grep -i "out of memory" çıktısındaki süreç tablosu, hangi sürecin ne kadar bellek tuttuğunu net gösterir ve gerçek suçluyu bulmanın en hızlı yoludur.

Aşırı tahsis oranını nasıl hesaplarım#

En sağlıklı yöntem, tüm misafirlerin hipervizör tarafındaki gerçek rss toplamını fiziksel belleğe oranlamaktır; tahsis edilmiş tavanların toplamı değil. virsh dommemstat çıktısındaki rss değerlerini toplayıp fiziksel RAM'e bölersen gerçek doluluk oranını elde edersin. Bu oranı yüzde 80'in altında tutmak ve zirve saatlerinde de ölçmek, ortalamaya bakmaktan çok daha güvenilirdir.

Bellek yoğun uygulamalar için hangi sunucu tipini seçmeliyim#

Redis, Elasticsearch, büyük InnoDB tampon havuzları veya büyük JVM heap'leri gibi belleği sürekli sıcak tutan uygulamalarda garantili bellekli planları tercih et. Aşırı tahsisli, düşük fiyatlı bir paylaşımlı sanal sunucu bu iş yüklerinde öngörülemez gecikmeler üretir. Kaynakların tamamen sana ait olduğu VDS ya da fiziksel sunucu seçenekleri, bu tür uygulamalarda hem daha kararlı hem de teşhis açısından çok daha şeffaftır.

Kapanış#

Bellek aşırı tahsisi kötü bir şey değildir; kötü olan, onun varlığından habersiz kapasite planlaması yapmaktır. Aklında tutman gereken dört alışkanlık şu: misafirin gördüğü MemTotal ile satın aldığın tavanı asla eşit varsayma, uygulama tamponlarını garantili belleğe göre boyutlandır, hipervizör tarafında rss toplamını izleyerek gerçek doluluğu ölç ve host swap'ının sıfırdan farklı olduğu her anı bir olay olarak ele al. Balloon şişmesi normaldir; host swap'ı değildir.

Bellek davranışının öngörülebilir olması senin için kritikse, kaynakların paylaşılmadığı planlar hayatını kolaylaştırır. Garantili kaynak isteyen veritabanı ve önbellek katmanları için VDS ve bulut sunucu paketlerimize, tek kiracılı tam kontrol istiyorsan dedicated sunucu seçeneğimize göz atabilirsin. Mevcut kurulumundaki bellek baskısının kaynağını birlikte çıkarmak istersen sunucu yönetimi hizmetimiz ölçüm ve ayarlama işini sizin yerinize üstlenir.