Linux sunucuda CPU, RAM ve disk kullanımı nasıl kontrol edilir?
Bu rehberin sonunda: Yavaşlığın CPU, RAM veya diskle ilgili olup olmadığını araştırmak için ölçümleriniz olacak. CPU işlem yapar, RAM geçici çalışma alanıdır, disk ise dosyaları saklar.
Sunucu yavaşladığında önce sorunun hangi kaynaktan geldiğini belirleyin. RAM doluluğu, işlemci yükü, disk kapasitesi ve uygulamanın dış bir servisten yanıt beklemesi aynı durum değildir. Tek bir ekran görüntüsü yerine sorunun yaşandığı zamanla birlikte birkaç ölçüm alın.
Kapsam: Ubuntu 24.04 LTS ve Debian 13; standart procps ve GNU coreutils araçları. Aşağıdaki komutlar ayar değiştirmez, dosya silmez ve servis yeniden başlatmaz. SSH erişimi gerekir. Araçlardan biri yoksa acil olay sırasında rastgele bir kurulum betiği çalıştırmayın.
Aynı belirti, farklı kaynak sorunlarından doğabilir.
Ölçümün saatini kaydedin; aynı kontrolleri normal kullanımda da yapın.
- CPU: işlem gücü
İşlemci sürekli meşgul mü? Yükü ve yoğun süreçleri birlikte inceleyin.
- RAM: çalışma alanı
Kullanılabilir bellek ve sürekli swap hareketini birlikte kontrol edin.
- Disk: saklama alanı
Boş alan, inode ve I/O bulgularını ayrı inceleyin; rastgele dosya silmeyin.
Dış bir servisin yavaş yanıtı da uygulamayı yavaşlatabilir; her sorun paket yetersizliği değildir.
1. Zamanı ve işlemci sayısını kaydedin
Önce SSH ile sunucuya bağlanın. Bu rehberdeki bütün komutlar sunucuda çalışır. Satırları tek tek çalıştırıp çıktıyı not edin.
| Komut | Beklenen bilgi |
|---|---|
date -Is | Ölçüm zamanı ve saat dilimi farkı |
uptime | Açık kalma süresi ve üç yük ortalaması |
nproc | Bu süreç için kullanılabilir işlem birimi sayısı |
Tek bir “iyi” yük sayısı yoktur. Sorun yaşanırken ve normal kullanımda aldığınız ölçümleri karşılaştırın.
Komutları sunucuda çalıştırın:
date -Is
uptime
nproc
uptime içindeki load average, son 1, 5 ve 15 dakikadaki yük ortalamalarını gösterir. Bu sayı yalnız CPU kullanım yüzdesi değildir; çalışmayı bekleyen veya kesilemeyen bekleme durumundaki işler de etkiler. Sürekli yüksek yükü sunucunun gördüğü işlemci sayısı ve aşağıdaki ölçümlerle birlikte değerlendirin.
DCHost VPS ve VDS sayfalarında aynı paketler sunulur. Paketinizin CPU sayısı, fiziksel çekirdeğin yalnız size ayrıldığı anlamına gelmez. Proxmox/KVM altyapısı kullanılması da tek başına uygulama performansı garantisi değildir.
2. Kullanılabilir RAM ve swap'a bakın
Sunucu penceresinde çalıştırın. free -h, belleği okunabilir birimlerle gösterir. vmstat 1 5, bir saniye arayla toplam beş rapor üretir; birkaç saniye sürmesi normaldir.
free -h
vmstat 1 5
free çıktısında yalnız free sütununa bakmayın. Linux belleğin bir bölümünü önbellek için kullanır; available, yeni uygulamalar için swap'a başvurmadan kullanılabilecek belleğin tahminidir.
vmstat ilk rapordaki CPU ve I/O hızlarını sistemin açılışından beri geçen süre üzerinden, sonraki raporları ölçüm aralığı üzerinden hesaplar; süreç ve bellek değerleri ise o anki durumu gösterir. si ve so swap giriş/çıkışını, us ve sy CPU kullanımını, wa I/O beklemesini gösterir. Sürekli düşük kullanılabilir bellek ve devamlı swap hareketi birlikte görülüyorsa bellek baskısı araştırılmalıdır. Swap'ta veri bulunması tek başına sorun kanıtı değildir.
vmstat sütunu | Basit anlamı |
|---|---|
si / so | RAM ile swap arasındaki veri hareketi |
us / sy | Uygulama ve çekirdek tarafındaki CPU kullanımı |
wa | I/O tamamlanmasını bekleyen CPU zamanı |
Kontrol: İlk satırın CPU/I/O ortalamaları açılıştan beri geçen süreyi kapsar. Güncel eğilim için sonraki örnekleri karşılaştırın. Swap, belleğe yardımcı disk alanıdır; içinde veri bulunması tek başına arıza değildir.
3. Disk alanı ile inode kullanımını ayrı kontrol edin
Diskte boyut ve dosya kaydı için iki ayrı sınır vardır.
- Disk alanı: df -hT
Dosyaların toplam boyutu için kalan alanı gösterir. Use% sütununa bakın.
- Inode: df -i
Dosya ve dizin kayıtları için kullanımı gösterir. IUse% sütununa bakın.
Uygulamanın verilerini tutan dosya sistemini kontrol edin; yalnız / bölümüne bakmayın.
İki ayrı sınırı kontrol ediyoruz:
- Disk alanı: Dosyaların toplam boyutu için yer var mı?
- Inode: Yeni dosya veya dizin için kayıt kapasitesi var mı?
Aynı diskte bir sınır dolup diğeri boş kalabilir. İki komut bu nedenle ayrı çalıştırılır.
df -hT
df -i
df -hT, her dosya sisteminin kapasitesini ve türünü gösterir. Yalnız / bölümüne bakmayın; veritabanı veya uygulama verileri ayrı bir bölümde olabilir. df -i, dosya ve dizin sayısıyla ilişkili inode kullanımını gösterir. Boş GB görünmesine rağmen inode tükenmişse yeni dosya oluşturulamayabilir.
Disk doluysa neyin yer kapladığını belirlemeden logları, veritabanı dosyalarını veya yedekleri silmeyin. Canlı dosya silmek hem veri kaybına yol açabilir hem de açık tutulan dosya nedeniyle beklenen alanı hemen kazandırmayabilir. Paket yükseltmek de dosya sisteminin kendiliğinden büyüdüğünü kanıtlamaz; yükseltme sonrasında kapasiteyi yeniden kontrol edin.
Kontrol: Use% disk alanını, IUse% inode kullanımını gösterir. Uygulamanızın verilerini tutan dosya sistemini inceleyin; doluluk sınırına yaklaşan değeri ve zamanı kaydedin.
4. Yoğun süreçleri belirleyin
Sunucu penceresinde: İlk komut CPU'ya, ikinci komut belleğe göre sıralar. head -n 11, başlıkla birlikte ilk 11 satırı gösterir. PID, çalışan işin süreç numarasıdır.
Beklenen sonuç: Süreç adları ve kullanım yüzdeleri görünür. Bir süreci listede görmek, onu durdurmanız gerektiği anlamına gelmez.
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -n 11
ps -eo pid,comm,%cpu,%mem --sort=-%mem | head -n 11
Bu listeler süreç adı ve kaynak kullanımını gösterir; tam komut satırını göstermediği için komutlara yazılmış sırları açığa çıkarma riskini azaltır. ps CPU yüzdesi anlık bir benchmark değildir. Aynı sürecin sorun yaşanan aralık boyunca üst sıralarda olup olmadığını kontrol edin. Yüksek kullanım normal bir yedekleme veya veri işleme işi de olabilir; yalnız listede ilk sırada diye süreci sonlandırmayın.
Ölçümden sonra hangi yolu izlemeli?
| Birlikte görülen bulgular | Sonraki inceleme |
|---|---|
Düşük available, sürekli swap hareketi | Uygulama ve veritabanının bellek ihtiyacı; eşzamanlı iş sayısı |
| Uzun süre yüksek CPU, aynı yoğun süreç | Uygulama sorguları, kuyruklar ve zamanlanmış işler |
| Kapasite veya inode doluluğu | Büyüyen veri türü, saklama politikası ve disk planı |
Sürekli yüksek wa, düşük uygulama CPU kullanımı | Depolama I/O'su, ilgili süreçler ve hata günlükleri |
| Kaynaklar normal ama belirli sayfa yavaş | O sayfanın sorguları, API bağlantıları ve uygulama hataları |
wa tek başına disk arızası kanıtı değildir; ilgili süreç ve depolama ölçümleriyle birlikte değerlendirin. Dış bir API'nin yanıtını beklemek de mutlaka yüksek wa üretmez. Değişiklikten sonra aynı işlemi benzer kullanım altında tekrar ölçün. Tek başına bir yüzdeye bakarak paket yükseltmek yerine, ihtiyaç duyulan kaynağın yeni pakette artıp artmadığını inceleyin.
Son kontrol: Değişiklik yaptıysanız aynı işlemi benzer kullanımda tekrar ölçün. Yüzdenin değişmesi kadar, müşterinin yaşadığı yavaşlığın giderilip giderilmediğini de kontrol edin.
Destek için toplanacak bilgiler
Hizmet numarası, saat dilimiyle olay zamanı, yavaşlayan işlem, son değişiklik ve ilgili komut çıktılarından kısa kesitler yeterli bir başlangıçtır. Sunucu adlarını ve kişisel bilgileri herkese açık paylaşımlardan çıkarın. Parola, özel anahtar veya tüm uygulama yapılandırmasını paylaşmayın. Salt okunur ölçümlerin geri alınması gerekmez.