Linux'ta Yavaşlık Tanılama: Bellek, İşlemci ve Disk Darboğazını Bulmak

"Sunucu yavaş" demek bir teşhis değildir. Yavaşlığın nedeni dört kaynaktan birindedir: işlemci, bellek, disk ya da ağ. Doğru kaynağı bulmak, yanlış şeyi büyütmekten (örneğin sorun diskteyken RAM eklemekten) kurtarır. Bu rehber, ek yazılım kurmadan elinizdeki komutlarla sistematik bir tanı yöntemi sunar. Örnekler Raspberry Pi ve küçük sunucular için yazılmıştır.

Adım 0: Genel bakış (uptime)

uptime

Çıktıdaki son üç sayı 1, 5 ve 15 dakikalık yük ortalamasıdır. Yorum için çekirdek sayısıyla karşılaştırın: 4 çekirdekli bir Pi'de 4.0 yük "tam dolu" demektir; 1.0 rahattır. Yük ortalaması yalnızca işlemciyi değil, disk beklemesini de içerir; yüksek yük ama düşük işlemci kullanımı genelde disk sorunudur.

Adım 1: İşlemci

top (ya da htop) açın. %Cpu(s) satırına bakın:

• us yüksekse kullanıcı süreçleri (uygulamanız) işlemciyi yiyor; en üstteki süreç suçludur.
• sy yüksekse çekirdek tarafında yoğun iş var (ağ, disk, çok sayıda bağlam geçişi).
• wa yüksekse işlemci boşta ama diski bekliyor: sorun diskte.
• st yüksekse sanal makinenin ev sahibi sizden işlemci çalıyor (bulut sunucularında).

Pi'de sıcaklık da önemlidir: aşırı ısınan işlemci frekansını düşürür. vcgencmd measure_temp ve vcgencmd get_throttled ile bakın (güç ve ısınma).

Adım 2: Bellek

free -h

Dikkat edilecek sütun available (kullanılabilir). Linux boş belleği dosya önbelleği için kullandığından free sütununun düşük olması normaldir; available düşükse gerçek sıkıntı vardır. Ardından swap satırına bakın: swap kullanımı sürekli artıyorsa bellek yetmiyordur. Belleği en çok kullanan süreçleri görmek için ps aux --sort=-%mem | head.

vmstat 5 komutunda si ve so sütunları (swap giriş/çıkış) sıfırdan farklıysa sistem bellek baskısı altındadır ve yavaşlamanın ana nedeni budur. Pi'de swap SD kartta olduğundan hem yavaşlık hem aşınma demektir (SD kart ömrü). Bellek yetmezse çekirdek bir süreci öldürebilir (OOM killer); journalctl -k | grep -i "out of memory" ile kontrol edin (journalctl rehberi).

Adım 3: Disk

Önce doluluk: df -h. Yüzde 90'ın üstü tehlikelidir; ayrıntılı arama için disk doluluk tanılama rehberine bakın. Sonra hız ve bekleme: iostat -x 5 (sysstat paketi) çıktısında %util %80–100 ve await yüksekse disk darboğazdır. Hangi sürecin yazdığını sudo iotop -o gösterir.

SD kartlı sistemlerde disk yavaşlığı sıradandır; kart yaşlandıkça yazma gecikmeleri artar. dmesg | grep -i -E "mmc|i/o error" hatalara bakar. Bir "I/O error" görürseniz yedeği hemen kontrol edin (yedek tatbikatı).

Adım 4: Ağ

ss -s bağlantı sayılarının özetini, ss -tnp ayrıntıyı gösterir. Çok sayıda TIME-WAIT ya da SYN-RECV bir uygulama ya da saldırı sinyali olabilir. Hat hızı şüpheliyse gerçek ölçümü hız testi ile alın, ayrıntılı ağ tanıları için ağ sorun giderme yazısına bakın.

Karar tablosu

Küçük bir saha örneği

Bir personel panelinin her sabah 08:00'de yavaşladığı bildirildi. top işlemciyi normal gösterdi, ama vmstat yoğun swap hareketi ortaya çıkardı: sabah herkes aynı anda rapor açınca gunicorn işçileri belleği doldurmuştu. Çözüm işçi sayısını azaltmak ve ağır raporu önceden hesaplayıp önbelleğe almaktı; yeni donanım gerekmedi. Aynı hatayı kendi servisinizde yakalamak için işçi ayarını Flask servis rehberindeki gibi bellek durumuna göre seçin.

Sık sorulan sorular

Yük ortalaması ne kadar olmalı? Çekirdek sayısının altında. Kısa süreli yükselmeler normaldir.

Swap'i kapatmalı mıyım? Bellek yeterliyse azaltın; kapatırsanız bellek dolduğunda süreçler öldürülür.

htop yoksa ne yapmalıyım? top her sistemde vardır; sudo apt install htop ile daha okunaklı bir arayüz kurabilirsiniz.