Follow
Follow

Linux’ta Bellek ve Disk Tıkanıklıkları: journalctl, lsof ve top/htop ile Anlık Teşhis

Linux sunucularda bellek ve disk kaynaklı tıkanıklıkları journalctl, lsof ve top/htop üçlüsüyle nasıl hızlıca teşhis ettiğimi anlatıyorum.

Bir Linux sunucusunda “disk dolu” veya “bellek yetersiz” hatalarıyla karşılaştığınızda, doğru araç setiyle kök nedene dakikalar içinde ulaşabilirsiniz. Bu yazıda en çok kullandığım üçlüyü paylaşıyorum: journalctl, lsof, top/htop.

1. top / htop: Anlık Kaynak Görünümü

htop, top‘un renkli ve etkileşimli versiyonudur; hangi sürecin CPU ve belleği en çok tükettiğini anında gösterir. Bellek sorunlarında dikkat ettiğim sütun RES (Resident Memory) — sürecin fiziksel olarak kullandığı gerçek bellek miktarı.

htop
# F6 ile sıralama kriterini değiştir (örn. MEM% ile sırala)

2. lsof: “Disk Dolu Ama Neden?” Sorusunun Cevabı

Disk doluluk oranı %100’e ulaştığında ama du ile büyük dosya bulamadığınızda, sorun genellikle silinmiş ama hâlâ bir süreç tarafından açık tutulan dosyalardır. Bu durumda dosya sistemi alanı serbest bırakılmaz.

lsof | grep deleted
# Silinmiş ama hâlâ açık tutulan dosyaları listeler

Bu komutun çıktısında büyük boyutlu bir log dosyasının “deleted” olarak göründüğünü ama hâlâ bir servis tarafından tutulduğunu görürseniz, çözüm genellikle ilgili servisi yeniden başlatmaktır (bu, dosya tanıtıcısını serbest bırakır).

3. journalctl: Zaman Çizelgesi Üzerinden Kök Neden Analizi

Sorunun TAM OLARAK ne zaman başladığını bulmak için journalctl vazgeçilmezdir:

journalctl --since "2 hours ago"        # Son 2 saatteki tüm loglar
journalctl -p err --since today          # Sadece hata seviyesindeki loglar
journalctl -u [servis-adı] -f            # Belirli bir servisi canlı izleme
journalctl --disk-usage                  # journal loglarının kendisinin kapladığı alan

Önemli bir sahadan not: journalctl’in kendisi de zamanla disk doldurabilir! journalctl --vacuum-size=500M komutuyla journal loglarının boyutunu sınırlandırmak, bu tür “kendi kendini besleyen” disk doluluk sorunlarını önler.

Tipik Bir Teşhis Akışı

  1. df -h ile hangi bölümün dolduğunu tespit et
  2. du -sh /* ile büyük klasörleri bul
  3. Büyük dosya görünmüyorsa lsof | grep deleted ile “hayalet” dosyaları kontrol et
  4. htop ile hangi sürecin anormal kaynak tükettiğini gözlemle
  5. journalctl --since ile sorunun başlangıç zamanını ve o anki olayları incele

Sonuç

Bu üç araç birlikte kullanıldığında, “neyin yanlış gittiğini” değil “neden yanlış gittiğini” ortaya çıkarır. Linux sunucu yönetiminde bu üçlüyü refleks haline getirmek, ortalama çözüm sürenizi ciddi şekilde kısaltır.

Comments
Join the Discussion and Share Your Opinion
Add a Comment

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir


Newsletter
Join Design Community
Get the latest updates, creative tips, and exclusive resources straight to your inbox. Let’s explore the future of design and innovation together.