- Konu sahibi
- #1
İlk bakış için SSH ile sunucuya bağlanıp
SSH oturumunda aşağıdaki komutu çalıştırın:
Çıktıdaki
Örnek olarak
Belleği belirli aralıklarla izlemek için:
Bu komut
Anlık süreç sıralaması için:
Bu listede
Daha etkileşimli inceleme için:
Yüklüyse daha ayrıntılı bir görünüm için
Bir sürecin yüksek bellek kullanması, tek başına bellek sızıntısını kanıtlamaz. Örneğin veritabanı önbelleği veya uygulamanın normal çalışma alanı zaman içinde büyüyebilir. Aynı süreci belirli aralıklarla izleyin; kullanım sürekli yükseliyor ve yeniden başlatma dışında düşmüyorsa uygulama yapılandırması, sürüm, istek trafiği ve süreç başına ayrılan sınırlar incelenmelidir.
Aşağıdaki komut, belirli bir işlemin PID değerini ve bellek kullanımını görmenizi sağlar:
Buradaki
Bellek durumunu tek bir sütuna bakarak değerlendirmeyin. Aşağıdaki ayrım hangi adımın uygun olduğunu gösterir:
Swap alanının etkin ve ne kadar kullanıldığını ayrıca görmek için:
RAM ve swap hareketini kısa aralıklarla izlemek için:
Bu komut iki saniye arayla beş ölçüm alır.
Sorun yalnızca belirli saatlerde oluşuyorsa tek bir
Bu komut her 60 saniyede bir tarihi ve bellek durumunu
Tanılama tamamlandığında log dosyası hassas süreç veya sistem bilgileri içeriyorsa erişimini sınırlandırın ya da artık gerekmiyorsa silin. Dosyayı paylaşmanız gerekiyorsa kullanıcı adları, işlem komut satırları, IP adresleri, ortam değişkenleri ve uygulama sırlarını ayıklayın.
En çok bellek kullanan süreç bir uygulamaya aitse önce o uygulamanın kendi metriklerini ve günlüklerini kontrol edin. Web sunucularında çalışan PHP-FPM işçi sayısı, veritabanlarında önbellek ve bağlantı ayarları, Java veya Node.js uygulamalarında ise süreç başına ayrılan bellek sınırları toplam tüketimi etkileyebilir. Değişiklik yapmadan önce mevcut ayarları kaydedin ve mümkünse kontrollü bir bakım aralığı belirleyin.
Bir servis beklenmedik şekilde büyüyorsa yalnızca servisi yeniden başlatmak geçici rahatlama sağlayabilir; kök nedeni kanıtlamaz. Yeniden başlatmadan önce ve sonra
Sunucuda bellek yetersizliği nedeniyle süreçler sonlandırılmışsa kernel günlüklerinde OOM belirtilerini arayın:
Bazı sistemlerde bu komut için yönetici yetkisi gerekebilir. OOM kaydı bulunması, çekirdeğin bellek baskısı sırasında bir süreci sonlandırdığını gösterir; hangi uygulamanın neden aşırı bellek kullandığını tek başına açıklamaz. Kaydı, olay saatindeki süreç ölçümleri ve uygulama günlükleriyle birlikte değerlendirin.
Bu ölçümler sonucunda
free -h komutunu çalıştırın; ardından bellek kullanımının hangi süreçlerden kaynaklandığını görmek için top veya ps aux --sort=-%mem kullanın. free çıktısındaki available değeri düşükse sistem belleği gerçekten sınırlanıyor olabilir; yalnızca used değerinin yüksek olması tek başına sorun anlamına gelmez. Sonucu süreç listesi, takas alanı ve gerekiyorsa geçmiş ölçümlerle birlikte değerlendirerek hangi uygulamanın inceleneceğine karar verin.Bellek kullanımını anlık olarak görme
SSH oturumunda aşağıdaki komutu çalıştırın:
Bash:
free -hÇıktıdaki
Mem satırında toplam bellek, kullanılan bellek, boş bellek, önbellek ve kullanılabilir bellek gösterilir. Swap satırı ise RAM yetmediğinde kullanılan takas alanının durumunu gösterir.Örnek olarak
available değeri 3,2 GiB olan bir sunucuda uygulamaların kullanabileceği yaklaşık bellek hâlâ 3,2 GiB düzeyindedir. free değerinin düşük olması tek başına alarm değildir; Linux, boş RAM’i dosya önbelleği olarak kullanabilir ve gerektiğinde bu alanı uygulamalara bırakabilir.Belleği belirli aralıklarla izlemek için:
Bash:
watch -n 2 free -hBu komut
free -h çıktısını iki saniyede bir yeniler. Çıkmak için Ctrl+C tuşlarına basın. available değeri sürekli düşüyor, swap kullanımı artıyor ve sistem yanıtları yavaşlıyorsa sorun anlık bir dalgalanmadan çok sürekli bellek baskısı olabilir.Belleği hangi süreçlerin kullandığını bulma
Anlık süreç sıralaması için:
Bash:
ps aux --sort=-%mem | head -n 15Bu listede
%MEM sütunu, sürecin toplam fiziksel belleğe oranını gösterir. RSS değeri ise sürecin RAM’de tuttuğu yaklaşık fiziksel bellek miktarını kilobayt cinsinden verir. Listenin ilk sırasında bir web sunucusu, veritabanı, PHP-FPM işçisi veya başka bir servis bulunabilir.Daha etkileşimli inceleme için:
Bash:
toptop açıldığında bellek kullanımını sıralamak için genellikle M tuşuna basabilirsiniz. Ekranın üst kısmındaki toplam bellek, boş bellek, önbellek ve swap bilgilerini; süreç bölümündeki %MEM ve RES sütunlarını birlikte inceleyin. Çıkmak için q tuşunu kullanın.Yüklüyse daha ayrıntılı bir görünüm için
htop da kullanılabilir:
Bash:
htopBir sürecin yüksek bellek kullanması, tek başına bellek sızıntısını kanıtlamaz. Örneğin veritabanı önbelleği veya uygulamanın normal çalışma alanı zaman içinde büyüyebilir. Aynı süreci belirli aralıklarla izleyin; kullanım sürekli yükseliyor ve yeniden başlatma dışında düşmüyorsa uygulama yapılandırması, sürüm, istek trafiği ve süreç başına ayrılan sınırlar incelenmelidir.
Aşağıdaki komut, belirli bir işlemin PID değerini ve bellek kullanımını görmenizi sağlar:
Bash:
ps -p PID -o pid,ppid,cmd,%mem,rss,vszBuradaki
PID yerine gerçek işlem kimliğini yazın. RSS RAM’deki fiziksel kullanımın, VSZ ise sürecin ayırdığı sanal adres alanının yaklaşık göstergesidir. VSZ değerinin yüksek olması doğrudan aynı miktarda RAM tüketildiği anlamına gelmez; RAM baskısını yorumlarken öncelikle RSS, sistemdeki available ve swap durumu dikkate alınmalıdır.Çıktıyı birlikte yorumlama
Bellek durumunu tek bir sütuna bakarak değerlendirmeyin. Aşağıdaki ayrım hangi adımın uygun olduğunu gösterir:
| Görülen durum | Anlamı | Sonraki adım |
|---|---|---|
| Used yüksek, available yeterli | Linux önbellek kullanıyor olabilir; tek başına sorun kanıtı değildir. | Süreç listesini ve uygulama yanıt sürelerini izleyin. |
| Available sürekli düşük | Uygulamaların kullanabileceği RAM azalmış olabilir. | En çok RSS kullanan süreçleri bulun ve yapılandırmalarını inceleyin. |
| Swap kullanımı artıyor | RAM baskısı veya daha önce yaşanmış bellek baskısı olabilir. | Swap hareketini ve sistem yavaşlığını vmstat ile kontrol edin. |
| Bir süreç sürekli büyüyor | Yük artışı, önbellek davranışı veya olası bellek sızıntısı olabilir. | PID, RSS ve zaman bilgisini düzenli kaydedip uygulama günlükleriyle karşılaştırın. |
Bash:
swapon --showRAM ve swap hareketini kısa aralıklarla izlemek için:
Bash:
vmstat 2 5Bu komut iki saniye arayla beş ölçüm alır.
si ve so sütunlarında sürekli giriş-çıkış görülmesi, belleğin swap ile taşındığını gösterir. Bu durum yüksek RAM baskısına işaret edebilir; ancak yalnızca swap’ın dolu olması her zaman aktif bir problem olduğu anlamına gelmez. Asıl belirti, swap hareketine eşlik eden yavaşlama, yüksek bekleme süreleri veya uygulama hatalarıdır.Ölçümü kaydedip artışı doğrulama
Sorun yalnızca belirli saatlerde oluşuyorsa tek bir
free -h çıktısı yeterli olmaz. Örneğin varsayımsal olarak aşağıdaki komutla temel bellek değerlerini zaman damgasıyla kaydedebilirsiniz:
Bash:
while true; do date; free -h; echo; sleep 60; done | tee -a memory.logBu komut her 60 saniyede bir tarihi ve bellek durumunu
memory.log dosyasına ekler. İşlem bitince Ctrl+C ile durdurun. Dosyada available değerinin zamana göre düşüp düşmediğini ve swap kullanımının artıp artmadığını karşılaştırın.Tanılama tamamlandığında log dosyası hassas süreç veya sistem bilgileri içeriyorsa erişimini sınırlandırın ya da artık gerekmiyorsa silin. Dosyayı paylaşmanız gerekiyorsa kullanıcı adları, işlem komut satırları, IP adresleri, ortam değişkenleri ve uygulama sırlarını ayıklayın.
Bulgudan sonra ne yapılmalı?
En çok bellek kullanan süreç bir uygulamaya aitse önce o uygulamanın kendi metriklerini ve günlüklerini kontrol edin. Web sunucularında çalışan PHP-FPM işçi sayısı, veritabanlarında önbellek ve bağlantı ayarları, Java veya Node.js uygulamalarında ise süreç başına ayrılan bellek sınırları toplam tüketimi etkileyebilir. Değişiklik yapmadan önce mevcut ayarları kaydedin ve mümkünse kontrollü bir bakım aralığı belirleyin.
Bir servis beklenmedik şekilde büyüyorsa yalnızca servisi yeniden başlatmak geçici rahatlama sağlayabilir; kök nedeni kanıtlamaz. Yeniden başlatmadan önce ve sonra
free -h, ps veya top çıktısını; PID, saat, RSS, swap durumu ve ilgili uygulama günlükleriyle birlikte kaydedin. Böylece sorunun belirli bir istek, görev, sürüm veya yapılandırma sonrasında tekrarlanıp tekrarlanmadığını karşılaştırabilirsiniz.Sunucuda bellek yetersizliği nedeniyle süreçler sonlandırılmışsa kernel günlüklerinde OOM belirtilerini arayın:
Bash:
dmesg -T | grep -i -E 'out of memory|oom|killed process'Bazı sistemlerde bu komut için yönetici yetkisi gerekebilir. OOM kaydı bulunması, çekirdeğin bellek baskısı sırasında bir süreci sonlandırdığını gösterir; hangi uygulamanın neden aşırı bellek kullandığını tek başına açıklamaz. Kaydı, olay saatindeki süreç ölçümleri ve uygulama günlükleriyle birlikte değerlendirin.
Bu ölçümler sonucunda
available sürekli düşük, swap hareketi sürekli yüksek ve en büyük süreçlerin normal çalışma sınırlarını aştığı görülüyorsa seçenekler; uygulama ayarlarını düzeltmek, gereksiz servisleri azaltmak, iş yükünü bölmek veya RAM kapasitesini artırmaktır. Sadece önbelleği temizlemek ya da swap eklemek, gerçek bellek ihtiyacını ortadan kaldırmaz; bunlar ancak ölçüm sonucuna göre geçici veya tamamlayıcı çözümler olarak değerlendirilmelidir.