Linux’ta RAM Tüketimini Kontrol Etmek için Komutlar ve Araçlar

Linux’ta RAM kullanımını izlemek, fiziksel bellek tahsisi, swap kullanımı ve işlem başına yerleşik küme boyutları hakkında metrikler almak için çekirdeğin bellek alt sistemini sorgulamak anlamına gelir. En doğrudan yöntemler yerleşik yardımcı programları kullanır — free, top, htop, ps, vmstat ve smem — her biri sistem geneli toplamlardan işlem başına orantılı küme boyutuna (PSS) kadar bellek hiyerarşisinin farklı bir katmanını ortaya koyar.

Aşırı bellek baskısı, RAM’i geri kazanmak için işlemleri zorla sonlandıran Linux Yetersiz Bellek (OOM) öldürücüsünü tetikler. Hangi komutların hangi metrikleri ortaya koyduğunu — ve bu metriklerin gerçekte ne anlama geldiğini — anlamak, reaktif sorun giderme ile proaktif kapasite yönetimi arasındaki farktır. Bu kılavuz, her önemli aracı, bunların okudukları çekirdek veri kaynaklarını ve deneyimli yöneticileri bile şaşırtan uç durumları kapsamaktadır.

Linux Sunucularında RAM İzlemenin Önemi

Linux bellek yönetimi kasıtlı olarak agresiftir. Çekirdek, disk G/Ç’sini hızlandırmak için mevcut tüm RAM’i sayfa önbelleği olarak kullanır; bu da sıfıra yakın boş bellek bildiren bir sistemin mutlaka baskı altında olmadığı anlamına gelir — yalnızca verimli şekilde önbellekleme yapıyor olabilir. Bu davranışı yanlış okumak, ham bellek rakamlarını yorumlarken yapılan en yaygın hatalardan biridir.

RAM’i sürekli izlemenin temel nedenleri:

• OOM öldürücüsünü önleme: Çekirdek kritik servisleri sonlandırmadan önce bellek açlığı çeken işlemleri tespit edin.
• Swap kullanımı tespiti: Yoğun swap etkinliği (swapping), RAM tükenmesini gösterir ve ciddi G/Ç gecikmesine neden olur.
• Bellek sızıntısı teşhisi: Zaman içinde sürekli büyüyen RSS’e sahip işlemler, uygulama düzeyinde sızıntılara işaret eder.
• Kapasite planlaması: Trend verileri, dikey ölçeklendirme veya iş yükü yeniden dağıtımı kararlarını destekler.
• Performans ayarı: vm.swappiness, büyük sayfalar ve NUMA topolojisini ayarlamak için temel bellek verisi gereklidir.

Kaynakların paylaşıldığı veya hiper yönetici limitleriyle kısıtlandığı bir VPS Hosting ortamında, doğru RAM izleme özellikle kritiktir — bir bellek tavanına çarpmak, herhangi bir uyarı tetiklenmeden önce performansı sessizce düşürür.

Linux Bellek Terminolojisini Anlamak

Herhangi bir komut çalıştırmadan önce, çıktı sütunlarının gerçekte neyi temsil ettiğini anlamanız gerekir.

Kritik bilgi: Bir sistemin yeni bir iş yükü için yeterli RAM’e sahip olup olmadığını değerlendirirken free -h çıktısındaki Free sütununu değil, her zaman Available sütununu kullanın. Free sütunu geri kazanılabilir önbelleği göz ardı ederek yanlış alarmlara yol açar.

/proc/meminfo Dosyası: Yetkili Kaynak

Bu makalede açıklanan her araç, çekirdek tarafından gerçek zamanlı olarak tutulan sanal bir dosya olan /proc/meminfo dosyasından okur. Doğrudan incelemek size mevcut en ayrıntılı verileri sunar:

cat /proc/meminfo

İzlenecek temel alanlar:

• MemTotal — kullanılabilir toplam RAM
• MemFree — tamamen boşta olan RAM
• MemAvailable — yeni işlemler için tahmini kullanılabilir RAM
• Buffers — ham disk blok önbelleği
• Cached — dosyalar için sayfa önbelleği
• SwapTotal / SwapFree — swap kapasitesi ve kullanılabilirliği
• Dirty — diske yazılmayı bekleyen bellek (yüksek değerler G/Ç baskısına işaret eder)
• HugePages_Total / HugePages_Free — büyük sayfa tahsis durumu
• Slab — çekirdek veri yapısı önbelleği (yoğun NFS veya veritabanı sunucularında büyük boyutlara ulaşabilir)

/proc/meminfo dosyasını anlamak, diğer tüm araçların çıktılarını tam bağlamıyla yorumlamanızı sağlar.

free Komutuyla RAM Kontrolü

free, sistem genelinde bellek anlık görüntüsü almanın en hızlı yoludur. Doğrudan /proc/meminfo dosyasından okur ve çıktıyı insan tarafından okunabilir bir tabloya biçimlendirir.

Temel Kullanım

free

Çıktı varsayılan olarak kilobayt cinsindendir. Daha okunabilir biçimler için bayraklar kullanın:

free -h        # Human-readable (MB/GB)
free -m        # Output in megabytes
free -g        # Output in gigabytes
free -s 5      # Refresh every 5 seconds (continuous monitoring)
free -h --si   # Use SI units (1000-based) instead of binary (1024-based)

Örnek Çıktının Açıklaması

              total        used        free      shared  buff/cache   available
Mem:           15Gi       4.2Gi       1.1Gi       312Mi       9.8Gi       10.9Gi
Swap:         2.0Gi       128Mi       1.9Gi

Bu örnekte sistem yalnızca 1,1 GB boş belleğe sahip gibi görünmektedir, ancak çekirdek buff/cache’i talep üzerine geri kazanacağından yeni işlemler için aslında 10,9 GB kullanılabilir durumdadır. Bu, free çıktısı hakkında anlaşılması gereken en önemli şeydir.

Uç Durum: Uyarı Sinyali Olarak Swap Kullanımı

Bir üretim sunucusunda küçük miktarda bile swap kullanımı (Swap: used > 0) araştırmayı gerektirir. Bu, çekirdeğin bazı bellek sayfalarını RAM yerine diskte depolamanın daha iyi olduğuna karar verdiği anlamına gelir — çalışma kümesinin fiziksel belleği aştığının bir işareti.

top Komutuyla RAM Kontrolü

top, sıralı bir işlem listesiyle CPU ve bellek istatistiklerini birleştirerek sistem kaynak kullanımının sürekli güncellenen, gerçek zamanlı bir görünümünü sunar.

top

top İçindeki Temel Bellek Alanları

top arayüzünün üst kısmında, iki satır bellek istatistiklerini gösterir:

MiB Mem :  16384.0 total,   1126.4 free,   4301.2 used,  10956.4 buff/cache
MiB Swap:   2048.0 total,   1920.0 free,    128.0 used.  11200.0 avail Mem

İşlem tablosunda en ilgili bellek sütunları şunlardır:

• VIRT — sanal bellek boyutu (VSZ eşdeğeri)
• RES — yerleşik fiziksel bellek (RSS)
• SHR — RES’in paylaşılan bellek kısmı
• %MEM — kullanılan toplam fiziksel RAM yüzdesi

Kullanışlı top Etkileşimli Komutlar

top‘u Etkileşimsiz Çalıştırma

Betik yazma ve günlük yakalama için top‘u toplu modda çalıştırın:

top -b -n 1 | head -30

Bu, tek bir anlık görüntü çıktısı verir — cron tabanlı izleme betikleri için kullanışlıdır.

htop ile RAM Kontrolü

htop, top ile aynı temel verileri çok daha kullanışlı bir arayüzle sunan, ncurses tabanlı gelişmiş bir işlem görüntüleyicisidir. Çoğu dağıtımda varsayılan olarak kurulu değildir.

Kurulum

# Debian / Ubuntu
apt-get install htop

# RHEL / CentOS / AlmaLinux / Rocky Linux
yum install htop
# or on newer versions:
dnf install htop

# Alpine Linux
apk add htop

htop‘ın top‘a Göre Avantajları

• Kullanılan belleği, arabellekleri ve önbelleği bir bakışta ayırt eden renk kodlu bellek çubukları
• Yatay ve dikey işlem ağacı görünümü (F5)
• Tıklama ve kaydırma için fare desteği
• Toplu işlem yönetimi için çoklu seçim
• Tuş bağlamlarını ezberlemeden yerleşik arama (F3) ve filtre (F4)
• Başlıkta kullanılabilir belleğin belirgin şekilde doğrudan gösterimi

htop Bellek Çubuğu Renk Açıklaması

Profesyonel ipucu: htop‘da, bellek verileriyle birlikte daha eksiksiz bir görünüm için F2 (Kurulum) > Görüntüleme Seçenekleri > “CPU frekansını göster” ve “Ayrıntılı CPU süresi” seçeneklerini etkinleştirin.

ps Komutuyla RAM Kontrolü

ps (işlem durumu), çekirdeğin işlem tablosunu sorgular ve belirli bir anda en fazla bellek tüketen işlemleri belirlemek için sıralanıp filtrelenebilir.

İşlemleri Bellek Tüketimine Göre Sıralama

ps aux --sort=-%mem

Çıktı Sütunlarının Açıklaması

Pratik Tek Satırlık Komutlar

İnsan tarafından okunabilir çıktıyla en fazla bellek tüketen ilk 10 işlemi göster:

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

Belirli bir işlem adı için bellek kullanımını göster (örn. Apache):

ps aux | grep apache2 | awk '{sum += $6} END {print sum/1024 " MB"}'

Bu, tüm apache2 çalışan işlemlerinin RSS değerlerini toplar — çok işlemli web sunucularının gerçek ayak izini anlamak için kritiktir.

Önemli uyarı: ps RSS gösterir ve paylaşılan kütüphaneleri çift sayar. 20 Apache çalışanının her biri aynı 50 MB paylaşılan kütüphaneyi eşliyorsa, ps bunlar genelinde 1.000 MB paylaşılan kütüphane kullanımı raporlarken gerçek fiziksel maliyet yalnızca 50 MB’tır. Doğru hesaplama için smem kullanın.

smem ile RAM Kontrolü

smem, PSS (Orantılı Küme Boyutu) raporladığı için Linux’ta mevcut en doğru işlem başına bellek hesaplama aracıdır — paylaşılan bellek, onu eşleyen tüm işlemler arasında orantılı olarak bölünür ve RSS tabanlı araçlarda bulunan çift sayım sorununu ortadan kaldırır.

Kurulum

# Ubuntu / Debian
apt-get install smem

# CentOS / RHEL 7
yum install smem

# RHEL 8+ / AlmaLinux / Rocky Linux
dnf install smem

# Alternatively, install via pip
pip install smem

Temel Kullanım

smem

Kullanışlı smem Seçenekleri

smem -r              # Sort by RSS (descending)
smem -s pss -r       # Sort by PSS (most accurate, descending)
smem -u              # Aggregate by user
smem -m              # Show system-wide memory map
smem -p              # Show percentages instead of raw KB
smem -k              # Show values in KB
smem -t              # Show totals row
smem --pie name      # Generate a pie chart (requires matplotlib)
smem -P apache2      # Filter by process name pattern

PSS ve RSS: Neden Önemlidir

100 MB V8 çalışma zamanı kütüphanesini paylaşan 10 Node.js çalışan işlemi çalıştıran bir sunucu düşünün:

• İşlem başına RSS: 200 MB (100 MB paylaşılan + 100 MB özel)
• Raporlanan toplam RSS: 2.000 MB
• İşlem başına PSS: 110 MB (100 MB’ın 10 MB payı + 100 MB özel)
• Raporlanan toplam PSS: 1.100 MB
• Kullanılan gerçek fiziksel RAM: 1.100 MB

Bu senaryoda RSS, kullanımı neredeyse 2 kat abartmaktadır. Bir Dedicated Server üzerinde ölçeklendirme kararları alırken smem aracından PSS kullanmak size gerçek verileri sağlar.

vmstat ile RAM Kontrolü

vmstat (sanal bellek istatistikleri), bellek, swap, G/Ç ve CPU etkinliğinin daha geniş bir görünümünü sağlar; bu da onu bireysel işlem sorunları yerine sistem genelindeki bellek baskısını teşhis etmek için ideal kılar.

vmstat 2 10    # Report every 2 seconds, 10 times

Temel Bellek Sütunları

Kritik sinyal: Çalışan bir vmstat akışında sıfırdan farklı si (swap-in) ve so (swap-out) değerleri, aktif swapping’e işaret eder — bellek tükenmesinin kesin bir göstergesi. so değerindeki kısa süreli artışlar bile yüzlerce milisaniyelik uygulama gecikme artışlarına neden olabilir.

sar ile RAM Kontrolü (Sistem Etkinlik Raporlayıcısı)

sysstat paketindeki sar, geçmişe dönük analiz imkânı sağlayan tarihsel bellek verilerini kaydeder — gerçek zamanlı araçların sağlayamadığı bir özellik.

Kurulum

apt-get install sysstat    # Debian/Ubuntu
yum install sysstat        # CentOS/RHEL

Kullanım

sar -r 1 5          # Memory stats every 1 second, 5 times
sar -r -f /var/log/sysstat/sa$(date +%d)   # Today's historical data
sar -S 1 5          # Swap statistics

sar, “Sabah 3’te uygulama çökmesine neden olan bir bellek artışı var mıydı?” gibi soruları yanıtlamak için paha biçilmezdir — gerçek zamanlı hiçbir araç bu soruyu olaydan sonra yanıtlayamaz.

/proc/<PID>/status ve /proc/<PID>/smaps ile RAM Kontrolü

Derin işlem başına analiz için çekirdek, ayrıntılı bellek haritalarını doğrudan /proc içinde sunar.

Hızlı İşlem Başına Bellek Kontrolü

cat /proc/$(pgrep nginx | head -1)/status | grep -E "VmRSS|VmPeak|VmSize|VmSwap"

Çıktı örneği:

VmPeak:   512340 kB
VmSize:   498120 kB
VmRSS:    102400 kB
VmSwap:        0 kB

• VmPeak — bu işlem tarafından ulaşılan en yüksek sanal bellek boyutu
• VmRSS — mevcut yerleşik küme boyutu
• VmSwap — bu işlemin ne kadarının swap’a alındığı

smaps ile Ayrıntılı Bellek Haritası

cat /proc/$(pgrep mysql | head -1)/smaps | grep -E "^(Size|Rss|Pss|Shared|Private)"

Bu, her bellek eşlemesini (heap, stack, paylaşılan kütüphaneler, anonim eşlemeler) bireysel RSS ve PSS değerleriyle ortaya koyar — bir profil oluşturucu olmadan mevcut en ayrıntılı bellek görünümü.

Araç Karşılaştırması: Doğru Komutu Seçmek

Pratik İzleme İş Akışları

İş Akışı 1: Hızlı Triyaj (60 Saniyenin Altında)

free -h                          # Step 1: Is Available memory critically low?
vmstat 1 5                       # Step 2: Is active swapping occurring?
ps aux --sort=-%mem | head -15   # Step 3: Which processes are the top consumers?

İş Akışı 2: Bellek Sızıntısını Tespit Etme

# Watch a specific process's RSS grow over time
watch -n 5 'ps -o pid,rss,vsz,comm -p $(pgrep your_app)'

# Or use smem with repeated snapshots
while true; do smem -P your_app -t; sleep 30; done

İş Akışı 3: Olay Sonrası Tarihsel Analiz

sar -r -f /var/log/sysstat/sa$(date +%d --date='yesterday')

İş Akışı 4: Otomatik Uyarı Betiği

#!/bin/bash
THRESHOLD=90
USED_PCT=$(free | awk '/^Mem:/ {printf "%.0f", $3/$2 * 100}')
if [ "$USED_PCT" -gt "$THRESHOLD" ]; then
    echo "ALERT: RAM usage at ${USED_PCT}% on $(hostname)" | mail -s "Memory Alert" admin@example.com
fi

Bu betik, herhangi bir üretim VPS with cPanel veya bare-metal sunucuda sürekli otomatik izleme için pratik bir zorunluluk olan cron işine yerleştirilebilir.

Gelişmiş: Çekirdek Bellek Ayar Parametreleri

Bellek baskısını tespit ettikten sonra, bu sysctl parametreleri davranışı doğrudan etkiler:

# View current swappiness (default: 60)
sysctl vm.swappiness

# Reduce swap tendency (recommended for databases: 10)
sysctl -w vm.swappiness=10

# Increase dirty page write-back aggressiveness
sysctl -w vm.dirty_ratio=15
sysctl -w vm.dirty_background_ratio=5

# Drop page cache manually (use with caution on production)
sync; echo 3 > /proc/sys/vm/drop_caches

vm.swappiness açıklaması: 60 değeri, çekirdeğin RAM %40 kullanıldığında swap’a başlayacağı anlamına gelir. Veritabanı sunucuları (MySQL, PostgreSQL, Redis) için bunu 10 olarak ayarlamak, verileri çok daha uzun süre RAM’de tutar ve G/Ç gecikmesini önemli ölçüde azaltır. Masaüstü sistemler veya sınırlı RAM’e sahip sistemler için varsayılan değer daha uygundur.

Yaygın Tuzaklar ve Yanlış Yorumlamalar

Tuzak 1: Düşük “free” bellek nedeniyle paniklemek

Daha önce açıklandığı gibi, Linux boş RAM’i kasıtlı olarak önbellek olarak kullanır. 200 MB boş ama 8 GB kullanılabilir belleğe sahip bir sistem sağlıklıdır. Her zaman Available sütununu okuyun.

Tuzak 2: Toplam bellek kullanımını tahmin etmek için RSS’leri toplamak

Tüm işlemlerdeki ps RSS değerlerini toplamak, paylaşılan kütüphane çift sayımı nedeniyle genellikle toplam fiziksel RAM’i aşar. Doğru sistem toplamı için smem -t kullanın.

Tuzak 3: Slab önbelleğini göz ardı etmek

Yoğun NFS istemcilerinde veya çok sayıda küçük dosyaya sahip sunucularda, çekirdek Slab ayırıcısı gigabaytlarca RAM tüketebilir. cat /proc/meminfo | grep Slab değerini kontrol edin — bu bellek teknik olarak geri kazanılabilir ancak işlem düzeyindeki araçlarda görünmez.

Tuzak 4: VSZ’yi gerçek bellek kullanımıyla karıştırmak

Bir Java uygulaması 4 GB VSZ gösterebilir ancak yalnızca 512 MB RSS’e sahip olabilir. VSZ, belleğe eşlenmiş dosyaları, rezerve edilmiş ancak tahsis edilmemiş heap’i ve paylaşılan kütüphaneleri içerir — bunların çoğu fiziksel RAM’e hiçbir zaman yüklenmez.

Tuzak 5: Konteynerleştirilmiş iş yüklerinde belleği gözden kaçırmak

Bir Docker konteyneri içinde free, konteynerin cgroup limitini değil, ana makinenin toplam belleğini gösterir. Doğru konteyner düzeyinde metrikler için cat /sys/fs/cgroup/memory/memory.usage_in_bytes ve cat /sys/fs/cgroup/memory/memory.limit_in_bytes kullanın.

Kalıcı RAM İzleme Kurulumu

Üretim ortamları için anlık komutlar yetersizdir. Sürekli görünürlük için şu yaklaşımları değerlendirin:

• sysstat ile cron: sar tarihsel veri toplamayı otomatik olarak etkinleştirir.
• Prometheus + Node Exporter: /proc/meminfo metriklerini toplar ve Grafana panoları için sunar.
• Netdata: Saniye başına ayrıntı düzeyinde ve yerleşik bellek anomali tespiti ile sıfır yapılandırmalı gerçek zamanlı izleme.
• Zabbix veya Nagios: Yapılandırılabilir bellek eşikleri ve yükseltme politikalarıyla kurumsal düzeyde uyarı.

GPU Hosting altyapısında iş yükleri çalıştırırken, sistem RAM’inin yanı sıra GPU VRAM’ini de izleyin — nvidia-smi --query-gpu=memory.used,memory.free --format=csv, GPU belleği için eşdeğer metrikleri sağlar.

VPS Control Panels aracılığıyla yönetilen web barındırma ortamlarında, çoğu panel yerleşik bellek grafikleri içerir — ancak bunlar genellikle 1–5 dakikalık aralıklarla yoklama yapar ve vmstat veya sar‘ın yakalayabileceği kısa süreli artışları kaçırır.

Teknik Karar Matrisi: Hangi Durumda Hangi Araç Kullanılır

Temel Çıkarımlar Kontrol Listesi

• Gerçek kapasiteyi değerlendirmek için free -h çıktısındaki Free sütununu değil, her zaman Available belleği kontrol edin.
• Bir araştırmayı tırmandırmadan önce aktif swapping’i doğrulamak veya dışlamak için vmstat 1 5 kullanın.
• Doğru işlem başına bellek rakamlarına ihtiyaç duyduğunuzda — özellikle kütüphaneleri paylaşan çok sayıda işlem içeren sunucularda — ps aux --sort=-%mem yerine smem -s pss -r kullanın.
• Tarihsel sar veri toplamayı etkinleştirmek için sağlama işleminin hemen ardından her üretim sunucusuna sysstat kurun.
• Swap kullanımını en aza indirmek için veritabanı sunucularında /etc/sysctl.conf içinde vm.swappiness=10 değerini kalıcı olarak ayarlayın.
• Standart araçlar gözlemlenen bellek baskısını açıklamadığında Slab ve Dirty değerleri için /proc/meminfo dosyasını kontrol edin.
• Konteynerleştirilmiş iş yükleri için doğru limitler ve kullanım bilgisi için free yerine cgroup bellek dosyalarını okuyun.
• Paylaşılan barındırma veya VPS ortamlarında, anomalilerin hemen fark edilebilmesi için normal çalışma sırasında bellek temel değerleri oluşturun.

—

Sıkça Sorulan Sorular

Linux’ta “free” ve “available” bellek arasındaki fark nedir?

“Free”, şu anda hiçbir kullanımı olmayan RAM’dir. “Available”, swap tetiklenmeden yeni işlemlere tahsis edilebilecek belleğin gerçekçi tahminidir — geri kazanılabilir sayfa önbelleği ve arabellekleri içerir. Sağlıklı bir Linux sunucusunda “free” genellikle sıfıra yakınken “available” yüksek kalır. Kapasite değerlendirmeleri için her zaman “available” kullanın.

Tüm işlemlerin RSS değerlerinin toplamı neden toplam fiziksel RAM’i aşıyor?

RSS (Yerleşik Küme Boyutu), paylaşılan belleği — örneğin paylaşılan kütüphaneleri — onu eşleyen her işlem için bir kez sayar. 50 işlemin her biri 100 MB’lık bir paylaşılan kütüphaneyi eşliyorsa, toplam RSS toplamı gerçek fiziksel maliyetin 4.900 MB üzerine çıkar. Bu çift sayımı ortadan kaldırmak için PSS raporlamasıyla smem kullanın.

Linux OOM öldürücüsünü hangi işlemin tetiklediğini nasıl bulabilirim?

dmesg | grep -i "oom|killed process" veya journalctl -k | grep -i oom komutunu çalıştırın. Çekirdek, sonlandırma anında tam işlem adını, PID’i ve bellek istatistiklerini, değerlendirilen tüm işlemlerin oom_score değerleri dahil olmak üzere günlüğe kaydeder.

Yüksek swap kullanımı ne anlama gelir ve ne kadar ciddidir?

Sürekli swap kullanımı, sistemin çalışma kümesinin fiziksel RAM’i aştığı anlamına gelir. Çekirdek, verileri diske sayfalayarak telafi eder; bu da genellikle RAM erişiminden 100–1.000 kat daha yavaştır. Mütevazı swap etkinliği bile ölçülebilir uygulama gecikmesine neden olur. Bu, bellek tüketimini azaltmak, RAM’i artırmak veya iş yüklerini yeniden dağıtmak için kesin bir sinyaldir.

Docker konteyneri içinde standart Linux komutlarını kullanarak RAM kullanımını izleyebilir miyim?

Konteyner içindeki free gibi standart komutlar, konteynerin cgroup limitini değil, ana makinenin toplam RAM’ini gösterir. Doğru konteyner düzeyinde metrikler için mevcut kullanım için /sys/fs/cgroup/memory/memory.usage_in_bytes ve yapılandırılmış limit için /sys/fs/cgroup/memory/memory.limit_in_bytes dosyasını okuyun. Alternatif olarak, biçimlendirilmiş bir görünüm için ana makineden docker stats <container_name> kullanın.