Linux Bellek Kullanımını Anlamak (free)

Bir sunucuya bağlanıp free -h komutunu çalıştıran sistem yöneticilerinin büyük bölümü, gördükleri sayı karşısında gereksiz yere paniğe kapılır. "RAM'in neredeyse tamamı dolu, sunucu bellek yetmezliğine giriyor" diye düşünülür, oysa çoğu zaman ortada hiçbir sorun yoktur. Linux'un bellek yönetimi, Windows'a alışkın gözlerin ilk bakışta ters gelen bir felsefeyle çalışır: boşta duran RAM, boşa harcanan RAM'dir. Çekirdek, kullanılmayan her megabaytı disk önbelleğine dönüştürerek sistemi hızlandırır ve bir uygulama belleğe ihtiyaç duyduğunda bu önbelleği saniyeler içinde geri verir. Bu yüzden "dolu görünen" bellek ile "gerçekten baskı altında olan" bellek birbirinden tamamen farklı iki şeydir.

Bu rehberde free çıktısındaki her sütunun ne anlama geldiğini, used ile available arasındaki hayati farkı, buff/cache sütununun neden ürkütücü göründüğü hâlde aslında dostunuz olduğunu ve swap kullanımının ne zaman masum ne zaman alarm olduğunu tek tek çözeceğiz. Ardından /proc/meminfo ile perde arkasına inecek, bir sunucu gerçekten belleği tükendiğinde devreye giren OOM killer mekanizmasını ve onun dmesg günlüklerinde bıraktığı izleri inceleyeceğiz. Amacımız sadece komut ezberletmek değil; bir gerçek bellek darboğazını, önbelleğin doğal doluluğundan ayırt edecek teşhis refleksini kazandırmak. İster paylaşımlı bir hosting hesabının kaynaklarını izleyin, ister kendi VDS sunucunuzda çalışın, buradaki mantık her yerde aynı işler.

free Çıktısının Anatomisi: Satırlar ve Sütunlar#

En yalın haliyle başlayalım. free komutu belleği kilobyte cinsinden gösterir; okunabilir birimler için neredeyse her zaman -h (human readable) bayrağıyla kullanılır.

free -h

Tipik bir çıktı şuna benzer:

               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       2.1Gi       310Mi       180Mi       5.4Gi       5.2Gi
Swap:          2.0Gi       128Mi       1.9Gi

İki satır vardır: Mem fiziksel RAM'i, Swap disk üzerindeki takas alanını gösterir. Sütunların anlamı ise şöyledir:

Buradaki en önemli mesaj şudur: free sütununun düşük olması bir sorun değildir. Yukarıdaki örnekte fiziksel RAM'in yalnızca 310 MiB'ı "boş" görünüyor ama available sütunu 5.2 GiB diyor. Yani sistem, istenildiği anda 5 GiB'dan fazla belleği bir uygulamaya tahsis edebilir. free sütununa değil, available sütununa bakmayı alışkanlık hâline getirin; modern bir Linux sunucusunda karar verilmesi gereken tek sayı odur.

Sürekli izleme için -s bayrağıyla belirli aralıklarla çıktı alabilirsiniz. Örneğin her 2 saniyede bir yenilemek için:

free -h -s 2

Toplam ve kullanılan değerleri tek satırda özetleyen -t (total) bayrağı da raporlarda işe yarar.

used, free ve available Arasındaki Kritik Fark#

Yıllarca Linux free çıktısı kafa karışıklığı ürettiği için, procps araç setinin yeni sürümleri available sütununu ekledi ve eski "buffers/cache" mantığını sadeleştirdi. Bu üç sütunu net ayırmak, bellek okur-yazarlığının temelidir.

used, çekirdeğin ve çalışan süreçlerin gerçekten meşgul ettiği, geri alınamayan bellektir. Bir web sunucusu işçisinin (worker) yığını, PHP-FPM sürecinin veri yapıları, veritabanı arabellek havuzu (buffer pool) buraya girer. Bu bellek "geri ver" denemez; süreç canlı olduğu sürece elindedir.

free, hiçbir amaca hizmet etmeyen, gerçekten atıl belleğdir. Sağlıklı ve uzun süre çalışmış bir sunucuda bu sayı genellikle küçüktür, çünkü çekirdek boş belleği hemen disk önbelleğine çevirir. Yani düşük free, iyi çalışan bir sistemin işaretidir.

available ise gerçek karar sütunudur: çekirdeğin tahminine göre, yeni uygulamalar başladığında swap'a başvurmadan verilebilecek bellek. Bu değer, free artı geri alınabilir önbelleğin büyük kısmını içerir. Pratik kural nettir: available toplam belleğin yüzde 10'unun altına düşmeye başladıysa gerçekten bellek baskısı vardır; available bol olduğu sürece used ve buff/cache ne kadar yüksek görünürse görünsün sorun yoktur.

Süreç bazında hangi uygulamanın ne kadar bellek yediğini görmek için free'yi ps veya top/htop ile birlikte kullanın. Örneğin en çok bellek tüketen 10 süreci sıralamak için:

ps aux --sort=-%mem | head -n 11

Bu komut çıktısındaki RSS (Resident Set Size) sütunu, o sürecin fiziksel RAM'de tuttuğu gerçek boyuttur. top, htop gibi araçların ayrıntılı kullanımını temel Linux komutları rehberinde de bulabilirsiniz.

buff/cache Neden RAM'i Doldurur ve Bu Neden İyidir#

Yeni yöneticileri en çok tedirgin eden sütun buff/cache'tir, çünkü çoğu zaman belleğin en büyük dilimini o kaplar. Ama bu, Linux'un en akıllı özelliklerinden birinin göstergesidir.

Her disk okuması, RAM'e göre kat kat yavaştır. Çekirdek bunu bildiğinden, diskten okunan her bloğu (dosya içerikleri, dizin girdileri, inode bilgileri) atıl RAM'de tutar. Aynı dosya tekrar istendiğinde diske gitmek yerine bellekten anında servis edilir. buff/cache bu önbelleğin toplamıdır: buffers blok cihaz meta verilerini, cache (page cache) dosya içeriklerini barındırır.

Kritik nokta şudur: bu bellek geri alınabilir. Bir uygulama gerçekten RAM'e ihtiyaç duyduğunda çekirdek, önbelleğin gereken kadarını anında serbest bırakıp uygulamaya verir. Yani buff/cache "dolu" olsa bile o bellek pratikte müsaittir ve zaten available sütununa dahildir. Bir web sunucusunun sık okunan statik dosyalarını, WordPress'in şablon dosyalarını veya veritabanının tablo indekslerini bellekten servis etmesi, siteyi belirgin biçimde hızlandırır. Önbellek boşsa değil, doluysa mutlu olmalısınız.

Test amacıyla önbelleğin gerçekten geri alınabilir olduğunu görmek isterseniz (yalnızca test/staging ortamlarında yapın, canlıda gerekmez) çekirdek önbelleğini elle boşaltabilirsiniz:

sync && echo 3 > /proc/sys/vm/drop_caches

Bu komuttan sonra free -h çalıştırdığınızda buff/cache düşer, free artar; ama birkaç dakika içinde normal iş yükü önbelleği yeniden doldurur. Bu, canlı sunucuda yapılması gereken bir "temizlik" değildir, sadece mekanizmayı anlamak için bir gösteridir. Önbelleği boşaltmak sisteminizi hızlandırmaz, tam tersine bir süre yavaşlatır çünkü sıcak veriler yeniden diskten okunmak zorunda kalır.

Swap Kullanımını Doğru Yorumlamak#

Swap, RAM dolduğunda çekirdeğin az kullanılan bellek sayfalarını diske taşıdığı takas alanıdır. free çıktısındaki ikinci satır swap durumunu gösterir. Ama swap'ta bir miktar used görmek tek başına alarm anlamına gelmez.

Modern çekirdekler, bir uygulama uzun süredir hiç dokunmadığı sayfaları (örneğin bir servisin başlangıçta yükleyip bir daha kullanmadığı kütüphaneler) atıl RAM'i boşaltmak için proaktif olarak swap'a taşıyabilir. Bu davranışın ne kadar agresif olacağını vm.swappiness parametresi belirler; 0 ile 100 arası bir değerdir ve varsayılan genellikle 60'tır. Sunucularda bu değeri 10 civarına çekmek yaygın bir ayardır:

# Anlık değeri gör
cat /proc/sys/vm/swappiness

# Kalıcı olarak düşür (ör. 10)
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

Swap'ta durgun bir miktar veri olması sorun değildir. Asıl bakılması gereken şey, swap'ın aktif olarak kullanılıp kullanılmadığıdır — yani sürekli diske sayfa yazılıp okunuyor mu? Bunu vmstat ile görürsünüz:

vmstat 1 5

Çıktıdaki si (swap in) ve so (swap out) sütunları sürekli sıfırdan büyükse, sisteminiz "swap thrashing" denen duruma girmiştir: RAM yetmediği için sürekli disk-bellek arası sayfa taşınıyor ve performans yerlerde sürünüyordur. Bu, gerçek bir bellek darboğazının en net işaretlerinden biridir. Buna karşılık si/so çoğunlukla sıfırsa, swap'taki durgun veri tamamen zararsızdır. Swap alanı oluşturma ve boyutlandırma ayrıntıları için swap alanı oluşturma rehberimize göz atabilirsiniz.

/proc/meminfo ile Derin Analiz#

free komutu aslında bir kolaylık aracıdır; verisini /proc/meminfo sanal dosyasından okur. Daha ince ayrıntıya inmek istediğinizde doğrudan bu dosyaya bakabilirsiniz.

cat /proc/meminfo

Onlarca satır arasında en çok işinize yarayacak olanlar şunlardır:

Belirli bir alanı hızlıca çekmek için grep kullanabilirsiniz. Örneğin yalnızca müsait belleği ve önbelleği görmek için:

grep -E 'MemAvailable|Cached|Dirty' /proc/meminfo

Dirty alanı özellikle ilginçtir: yüksek bir Dirty değeri, çok sayıda değişmiş sayfanın diske yazılmayı beklediğini gösterir. Yoğun yazma yapan bir veritabanı veya log akışı varsa bu değer geçici olarak yükselir; çekirdek arka planda bu sayfaları düzenli olarak diske akıtır (flush). Kalıcı olarak çok yüksek Dirty, yavaş bir disk alt sistemine işaret edebilir. Slab bölümünün ayrıntısını ise slabtop komutuyla canlı izleyebilirsiniz; bazen "belleğim nereye gitti, hiçbir süreç yemiyor" dediğinizde suçlu, şişmiş çekirdek slab önbellekleridir (örneğin çok sayıda küçük dosyanın dentry ve inode önbellekleri).

OOM Killer Nasıl Çalışır ve dmesg İzleri#

Bellek gerçekten tükendiğinde, yani hem RAM hem swap dolduğunda ve çekirdek yeni bir tahsis isteğini karşılayamadığında, sistem çökmek yerine sert bir önlem devreye sokar: OOM Killer (Out Of Memory Killer). Bu mekanizma, sistemin tamamen kilitlenmesini önlemek için belleği en çok tüketen ve "feda edilebilir" görünen bir süreci seçip öldürür.

Çekirdek her sürece bir OOM puanı verir; bu puan sürecin bellek tüketimiyle orantılı artar. Kritik anda en yüksek puanlı süreç sonlandırılır. Sorun şudur: çoğu zaman en çok bellek yiyen süreç, sizin en önemli servisinizdir — MySQL veya PHP-FPM ana süreci gibi. Sabahleyin "sitem çalışmıyordu, ama sunucuya bağlandığımda her şey normaldi" dediğiniz olayların büyük kısmının arkasında gece yaşanmış bir OOM olayı vardır.

OOM Killer'ın devreye girip girmediğini çekirdek günlüklerinden anlarsınız. En hızlı yol dmesg'te aramaktır:

sudo dmesg -T | grep -i -E 'killed process|out of memory|oom'

-T bayrağı zaman damgalarını okunabilir tarihe çevirir. Tipik bir kayıt şöyle görünür:

[Wed Jul 10 03:14:07 2026] Out of memory: Killed process 2043 (mysqld)
total-vm:4821200kB, anon-rss:3120044kB, file-rss:0kB

Bu satır size tam olarak hangi sürecin (PID 2043, mysqld), ne zaman ve ne kadar bellek tutarken öldürüldüğünü söyler. Kalıcı günlüklerde de aynı izi bulabilirsiniz:

sudo journalctl -k | grep -i 'oom'

Kritik bir servisin OOM tarafından öldürülme olasılığını azaltmak isterseniz, o sürecin OOM ayar puanını (oom_score_adj) düşürebilirsiniz. Örneğin systemd servis birimine şu satırı ekleyerek bir servisi öldürülmeye karşı daha dirençli yapabilirsiniz:

[Service]
OOMScoreAdjust=-500

Ama unutmayın: bu yalnızca kurbanı değiştirir, kök nedeni çözmez. Sürekli OOM yaşıyorsanız ya belleği yükseltmeniz ya da uygulamalarınızın bellek ayak izini kısmanız gerekir.

Gerçek Bellek Darboğazını Adım Adım Teşhis Etmek#

Şimdi tüm parçaları bir teşhis akışında birleştirelim. Bir sunucunun "belleği mi yetmiyor yoksa her şey normal mi" sorusunu şu sırayla yanıtlayın.

Önce free -h çalıştırın ve yalnızca available sütununa bakın. Toplam belleğin yüzde 15'inden fazlası müsaitse, used veya buff/cache ne kadar yüksek görünürse görünsün belleğiniz rahattır; muhtemelen sorunun kaynağı bellek değil, CPU veya disk G/Ç'sidir.

available düşükse ikinci adıma geçin ve swap etkinliğine bakın:

vmstat 1 5

si/so sürekli sıfırdan büyükse aktif swap thrashing yaşıyorsunuz demektir — bu, canlı ve ciddi bir bellek darboğazının kanıtıdır. Üçüncü adımda suçluyu bulun:

ps aux --sort=-%mem | head -n 6

En üstteki sürecin RSS değeri beklenenden büyükse, ya bir bellek sızıntısı (memory leak) ya da yanlış yapılandırma vardır. Örneğin MySQL'in innodb_buffer_pool_size değeri sunucu RAM'inden büyük ayarlanmışsa ya da PHP-FPM pm.max_children çok yüksekse, iş yükü arttığında bellek kaçınılmaz olarak tükenir. Dördüncü adımda geçmişteki OOM olaylarını dmesg -T | grep -i oom ile doğrulayın. Bu dört adımı bir tabloya indirgeyelim:

Bu akışı bir kez içselleştirdiğinizde, bir daha "RAM dolu görünüyor" diye gereksiz panik yaşamaz; yalnızca gerçekten önemli olan sinyallere tepki verirsiniz. Bellek baskısı kalıcıysa ve uygulama tarafında kısacak bir şey kalmadıysa, kaynakları esnek biçimde büyütebileceğiniz bir sanal sunucuya geçmek genellikle en sağlıklı çözümdür; sunucu yönetimini bize bırakmak isterseniz sunucu yönetim hizmetimiz bu tür teşhis ve ayarları sizin adınıza üstlenir.

Bellek Baskısını Kalıcı Olarak Azaltma Stratejileri#

Teşhis kadar önemli olan, darboğazı tekrar yaşamamaktır. Birkaç pratik yaklaşım, çoğu sunucuda belleği belirgin biçimde rahatlatır.

İlk olarak, uygulama yapılandırmalarını sunucunuzun gerçek RAM'ine göre boyutlandırın. Veritabanı arabellek havuzları, PHP işçi sayısı, uygulama sunucusu iş parçacığı sayıları gibi değerler "ne kadar çoksa o kadar iyi" mantığıyla değil, mevcut belleğe göre ayarlanmalıdır. Örneğin 4 GB RAM'li bir sunucuda MySQL/MariaDB için buffer pool'u makul tutmak, ani yük altında OOM'u önler. İkinci olarak, sık okunan verileri uygulama seviyesinde önbelleğe alan Redis veya Memcached gibi çözümler, disk okumasını azaltarak sayfa önbelleğine olan bağımlılığı düşürür; ama bunların da kendi bellek limitlerini (maxmemory) ayarlamayı unutmayın, aksi halde önbellek sınırsız büyüyüp OOM'un yeni tetikleyicisi olur.

Üçüncü strateji, düzenli izlemedir. Bellek sorunları çoğunlukla gece yarısı, siz uyurken patlak verir. free, vmstat ve dmesg'i elle kontrol etmek yerine bir izleme aracı kurup available bellek belirli eşiğin altına düştüğünde uyarı almak, olayı çökme yaşanmadan yakalamanızı sağlar. Son olarak, uygulama katmanında bellek sızıntısı yapan bileşenleri (kötü yazılmış eklentiler, kaçak arka plan işleri) tespit edip düzeltmek çoğu zaman RAM yükseltmekten daha kalıcı bir çözümdür — çünkü sızıntı devam ettiği sürece ne kadar bellek eklerseniz ekleyin er ya da geç dolar. Yüksek trafikli bir WordPress kurulumunda bu tür sorunların düzenli bakımını WordPress bakım hizmetimizle sürdürebilir, altyapı tarafında ise yedekleme politikanızı bir OOM sonrası veri kaybına karşı hazır tutabilirsiniz.

Sıkça Sorulan Sorular#

free çıktısında "free" değeri neden bu kadar düşük?#

Düşük free değeri neredeyse her zaman normaldir ve iyiye işarettir. Linux, kullanılmayan belleği disk önbelleğine (buff/cache) çevirerek sistemi hızlandırır; bu yüzden uzun süre çalışmış sağlıklı bir sunucuda free sütunu doğal olarak küçük görünür. Karar verirken free sütununa değil, çekirdeğin "swap'a düşmeden verebileceğim bellek" tahmini olan available sütununa bakmalısınız. available bol olduğu sürece belleğiniz baskı altında değildir.

buff/cache belleğini boşaltmam gerekir mi?#

Hayır, canlı bir sunucuda buna gerek yoktur ve genellikle zararlıdır. buff/cache içindeki bellek geri alınabilir; bir uygulama RAM'e ihtiyaç duyduğunda çekirdek önbelleği anında serbest bırakır. drop_caches ile önbelleği elle boşaltmak sistemi hızlandırmaz, tam tersine sıcak veriler yeniden diskten okunmak zorunda kalacağı için bir süre yavaşlatır. Bu komut yalnızca test veya karşılaştırma amacıyla anlamlıdır, rutin bakım işlemi değildir.

Swap kullanılıyor olması sunucumun belleğinin yetmediği anlamına mı gelir?#

Tek başına hayır. Modern çekirdekler, uzun süredir dokunulmayan atıl bellek sayfalarını proaktif olarak swap'a taşıyabilir; bu, RAM'i daha yararlı işler için boşaltmanın normal bir yoludur. Asıl sorun, swap'ın aktif olarak kullanılması yani sürekli disk-bellek arası sayfa taşınmasıdır. Bunu vmstat 1 çıktısındaki si ve so sütunlarından anlarsınız; bu değerler sürekli sıfırdan büyükse gerçek bir darboğaz vardır, durgun bir swap kullanımı ise zararsızdır.

OOM killer bir sürecimi öldürdü, bir daha nasıl önlerim?#

Kalıcı çözüm, kök nedeni gidermektir. Önce dmesg -T | grep -i oom ile hangi sürecin ve ne kadar bellek tutarken öldürüldüğünü belirleyin. Ardından ya sunucunuzun RAM'ini artırın ya da o uygulamanın bellek yapılandırmasını (veritabanı buffer boyutu, PHP-FPM işçi sayısı gibi) sunucunun kapasitesine göre küçültün. Kritik bir servisi geçici olarak korumak için systemd biriminde OOMScoreAdjust=-500 kullanabilirsiniz, ancak bu yalnızca kurbanı değiştirir; sürekli OOM yaşıyorsanız gerçek çözüm bellek yükseltmek veya yükü azaltmaktır.

free ile top/htop farklı değerler gösteriyor, hangisi doğru?#

İkisi de doğrudur, sadece farklı şeyleri ölçerler. free, sistemin tamamına ait toplam bellek durumunu (total, used, available, önbellek) verir. top ve htop ise süreç bazında bellek gösterir ve buradaki RES/RSS her sürecin fiziksel RAM'de tuttuğu boyuttur. Süreçlerin RSS değerlerini toplarsanız free'nin used değerini birebir bulamazsınız, çünkü paylaşımlı kütüphaneler birden fazla süreçte sayılır ve önbellek ayrı tutulur. Genel durum için free'ye, "hangi süreç ne kadar yiyor" sorusu için top/htop'a bakın.

/proc/meminfo'daki Dirty değeri sürekli yüksekse ne yapmalıyım?#

Dirty, henüz diske yazılmamış değişmiş sayfaları gösterir ve yoğun yazma yapan iş yüklerinde (veritabanı, log akışı) geçici olarak yükselmesi normaldir. Çekirdek bu sayfaları arka planda düzenli olarak diske akıtır. Ancak bu değer kalıcı olarak çok yüksek kalıyorsa, disk alt sisteminiz yazma yüküne yetişemiyor olabilir; yavaş bir disk veya G/Ç darboğazı işaretidir. Bu durumda disk performansını (iostat ile) ölçmeli, gerekirse daha hızlı depolamaya sahip bir sunucuya geçmeyi değerlendirmelisiniz.

Kapanış#

Linux bellek yönetiminin altın kuralı tek cümleyle özetlenebilir: free sütununa değil available sütununa bak, buff/cache'ten korkma. Bu iki alışkanlık, sistem yöneticiliğinde en sık yaşanan gereksiz panik anlarının önüne geçer. Gerçek bir bellek darboğazının imzası, dolu görünen RAM değil; düşük available, aktif swap thrashing (si/so) ve dmesg'teki OOM kayıtlarıdır. Bu sinyalleri okumayı öğrendiğinizde, hem gereksiz müdahalelerden kaçınır hem de gerçek sorunları çökme yaşanmadan yakalarsınız.

Belleği daima dolu görünen, OOM olaylarıyla boğuşan bir hosting hesabında sıkışıp kaldıysanız çözüm çoğu zaman kaynakları esnetebilmektir. Clou.TR'nin VDS ve sanal sunucu paketlerinde belleği ihtiyacınıza göre ölçekler, sunucu yönetim hizmetimizle de bu tür teşhis, ayar ve izleme işlerini uzman ekibimize devredebilirsiniz. Daha fazla pratik komut için temel Linux komutları ve swap alanı oluşturma rehberlerimizle yolculuğunuza devam edebilirsiniz.