Son doğrulama: Eylül 2026 · Ubuntu 24.04 test sunucusunda denendi
Hızlı çözüm
Linux RAM kullanımı izlemenin en hızlı yolu free -h komutudur; “free” sütunu düşük görünse de “available” sütunu asıl boş belleği gösterir, swap ve OOM riskini de aynı adımda kontrol edersiniz.
free -h çalıştırıp “available” sütununa bakın, düşük “free” değeri tek başına sorun değildir.swapon --show ile swap kullanımını görün; sürekli dolu swap gerçek bellek darlığına işaret eder.ps aux --sort=-%mem | head ile bulun.dmesg | grep -i oom ile OOM killer izini arayın.| Panel | Yok — VPS/VDS yönetimsizdir; izleme işletim sistemi üzerinden yapılır |
|---|---|
| Sistem | Ubuntu 22.04/24.04, Debian 12, AlmaLinux 8/9, Rocky 9 (coreutils free, ps, vmstat her dağıtımda yerleşik) |
| Yetki | Sunucunuzun herhangi bir kullanıcısı; OOM günlüğü için sudo/root önerilir |
| Narhost ürünü | VPS Sunucu, VDS Sunucu |
Başlamadan önce
swapon --show boş döner, bu normaldir.Linux RAM kullanımı ölçülürken en sık yapılan hata free -h çıktısındaki “free” sütununu esas almaktır. Çekirdek, boşta kalan belleği çöpe atmaz; disk önbelleğine (buff/cache) ayırır ve bir uygulama istediği an bu alanı geri alır. Bu yüzden “free” düşük görünse de sunucu sıkışık değildir; gerçek durumu available sütunu gösterir, o düşükse sorun vardır.
Bellek gerçekten yetersiz kaldığında iki şey olur: sistem swap alanına yazmaya başlar (disk hızında olduğu için belirgin yavaşlama hissedilir) ya da çekirdeğin OOM (Out Of Memory) killer’ı en çok bellek tüketen süreci öldürerek sunucuyu ayakta tutar. İkisi de free -h, vmstat ve dmesg çıktısında iz bırakır; adımlar bu izleri sırayla okur.
-h bayrağı baytları okunabilir birime (Gi/Mi) çevirir.
free -hBeklenen sonuç (test sunucusunda alınan gerçek çıktı): total 31Gi, used 1.2Gi, free 29Gi, buff/cache 1.2Gi, available 30Gi. “used” düşük, “buff/cache” küçük; sunucu rahat çalışıyor demektir.
cat /proc/meminfo | grep -E "^Mem(Total|Free|Available):"Beklenen sonuç: test sunucusunda MemTotal 32819460 kB, MemFree 30668660 kB, MemAvailable 31471536 kB — “available” değeri her zaman “free”ye eşit ya da ondan büyük çıkar.
swapon --showBeklenen sonuç (test sunucusunda alınan gerçek çıktı): /swap.img file 1.5G 0B -2. “USED” sütunu 0’a yakınsa swap’a ihtiyaç yok; sürekli yüksekse RAM gerçekten yetersizdir.
%MEM sütunuyla sıralayın; bir paket kurulumu ya da güncelleme sürüyorsa ilgili süreçler listenin başına çıkar, bu beklenen bir durumdur.
ps aux --sort=-%mem | head -6Beklenen sonuç: sütunlar %MEM, RSS (gerçek fiziksel bellek, KB) ve COMMAND‘ı gösterir; en üstteki süreç anlık en çok RAM tüketendir.
si (swap in) ve so (swap out) sütunları saniyede kaç KB’ın diske yazılıp okunduğunu gösterir.
vmstat 1 3Beklenen sonuç (test sunucusunda alınan gerçek çıktı): si 0, so 0; bu değerler sıfırdan uzaklaşırsa sunucu aktif olarak swap’a yazıyor, performans düşüşü buradan gelir.
dmesg | grep -i "out of memory\|oom"Beklenen sonuç: test sunucusunda bu komut boş döndü (OOM olayı yok). Bir kayıt varsa Out of memory: Killed process <PID> (<isim>) satırı, öldürülen süreci ve zamanı verir.
Sonuç
free -h‘taki “available” sütunu ihtiyacınızın belirgin üzerindeyse, swapon --show‘daki “USED” sıfıra yakınsa ve dmesg‘de OOM kaydı yoksa, linux RAM kullanımı bu sunucuda güvenli sınırda demektir.
Narhost desteği
Talebe şunları ekleyin: sunucunuzun IP adresi, işletim sisteminiz, free -h ve swapon --show çıktısı, varsa dmesg‘deki OOM satırı.
Sonraki adımlar
Çekirdek kullanılmayan RAM’i boşa harcamaz, disk önbelleğine (buff/cache) ayırır ve uygulama istediği an geri verir. Gerçek boş belleği görmek için “free” değil “available” sütununa bakılır.
Hayır, tek seferlik küçük swap kullanımı normaldir. Sorun, swapon --show‘daki “USED” değerinin sürekli yüksek kalması ve vmstat‘taki si/so sütunlarının sıfırdan uzaklaşmasıdır; bu, sunucunun aktif olarak diske yazdığını gösterir.
Çekirdek, kullanılabilir bellek ve swap tükendiğinde sunucunun tamamen kilitlenmesini önlemek için en çok bellek tüketen süreci sonlandırır. Bu olay dmesg | grep -i oom çıktısında Killed process satırıyla görünür.
Bu makale sorununuzu çözdü mü?
Geri bildiriminiz için teşekkürler.
Çözemediniz mi?
Teknik ekibimiz sunucu tarafındaki ayarları sizin için kontrol edebilir. Destek talebinizde alan adınızı ve aldığınız hata metnini paylaşmanız süreci hızlandırır.
