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

- Bağlantı: https://musti.org/sunucu/linux-bellek-disk-tikanikliklari-journalctl-lsof-top/
- Yayımlanma: 2026-09-21T21:30:44+03:00
- Yazar: mmutlu

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. En çok güvendiğim
üçlü şu: **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
    ```

journalctl’in kendisi de zamanla disk doldurabilir — bu, sık gözden kaçan bir detay.`
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

## Neden Bu Üçlü Yeterli?

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

_💡 Sorununuzu adım adım teşhis etmek için [interaktif Ağ Sorun Giderme Sihirbazı](https://musti.org/ag-sorun-giderme-sihirbazi/)
na da göz atabilirsiniz._