VDS Aldıktan Sonra Yavaşlık (Kasma) Sorunu Nasıl Giderilir

Son doğrulama: Eylül 2026 · Ubuntu 24.04 test sunucusunda denendi

Hızlı çözüm

VDS aldım ama kasıyor ne yapmalıyım sorusunun tek bir cevabı yoktur; yavaşlığın beş olası kaynağı vardır: CPU yükü, RAM/swap yetersizliği, disk G/Ç darboğazı, ağ sorunu ve tek bir uygulamanın kaynak tüketmesi. Aşağıdaki adımları sırayla çalıştırıp hangisinin eşiği aştığını bulun.

  1. uptime ile “load average” değerinin çekirdek sayınızı (nproc) aşıp aşmadığına bakın.
  2. free -h ile kullanılabilir belleğin ve swap kullanımının durumuna bakın.
  3. ps aux --sort=-%cpu | head ile tek bir sürecin kaynakları tüketip tüketmediğini görün.
Panel Yok — VPS/VDS yönetimsizdir; teşhis işletim sistemi üzerinden yapılır
Sistem Ubuntu 22.04/24.04, Debian 12, AlmaLinux 8/9, Rocky 9
Yetki Sunucunuzun root ya da sudo yetkili kullanıcısı
Narhost ürünü VDS Sunucu, VPS Sunucu

Başlamadan önce

  • Sunucunuza SSH ile bağlı olun; aşağıdaki komutların tamamı salt okunurdur, hiçbiri servis durdurmaz.
  • iostat için sysstat paketi gerekir; kurulu değilse apt install sysstat ile kurun.
  • Sunucunun kaç çekirdeği (nproc) ve ne kadar RAM’i (free -h) olduğunu önceden not edin.

VDS Aldım Ama Kasıyor Ne Yapmalıyım Sorusunun Nedenleri

Narhost’ta VDS sunucular yönetimsizdir: altyapı ve ağ sağlanır, işletim sistemi içindeki yük ve yapılandırma sunucuyu teslim alan sizin sorumluluğunuzdadır. “VDS aldım ama kasıyor” belirtisinin beş farklı kök nedeni olabilir: CPU darboğazı, yetersiz RAM’in swap’a yaptırdığı yavaşlama, disk G/Ç darboğazı, ağ katmanında paket kaybı ya da tek bir uygulamanın kaynak tüketmesi.

Bu kart “sunucunuz yavaşsa yeniden başlatın” gibi genel bir tavsiye vermez; her nedeni ayrı bir ölçüm komutuyla ayırt edip yalnızca gerçekten darboğaz olan katmana müdahale etmenizi sağlar.

VDS aldım ama kasıyor ne yapmalıyım akış şeması — CPU, RAM/swap, disk G/Ç, ağ ve süreç teşhisi adımları
Beş ölçümle yavaşlığın gerçek kaynağını sırayla ayırt eden teşhis akışı.

Adım Adım Yavaşlığın Gerçek Nedenini Ayırma

1. CPU Yükünü Ölçün

  1. Yük ortalamasını (load average) çekirdek sayınızla karşılaştırın:
    uptimenproc

    Beklenen sonuç (test sunucusunda alınan gerçek çıktı): load average: 0.00, 0.00, 0.00, nproc “10” döndü. Load average değeri 1, 5 ve 15 dakikalık ortalamayı gösterir; bu sayı sürekli çekirdek sayınızı (burada 10) aşıyorsa CPU kuyruğu birikiyor demektir.

  2. Hangi sürecin CPU’yu kullandığını anlık görün:
    top -bn1 | head -12

    Beklenen sonuç (test sunucusunda alınan gerçek çıktı, kısaltılmış): %Cpu(s): 0.8 us, 0.8 sy, 96.7 id, 0.8 wa. “id” (idle) yüksekse CPU boştadır; “wa” (I/O wait) yüksekse asıl darboğaz disktir, CPU değil. Sütun tanımları vmstat man sayfasında yer alır.

2. RAM ve Swap Durumunu Ölçün

  1. Kullanılabilir belleği ve swap kullanımını görün:
    free -hswapon --show

    Beklenen sonuç (test sunucusunda alınan gerçek çıktı): Mem: 31Gi total, 746Mi used, 30Gi available, Swap: 1.5Gi total, 0B used. “available” sütunu gerçek boş kapasiteyi gösterir (önbellek dahil “free”den daha güvenilirdir); swap kullanımı sürekli 0’ın üzerindeyse RAM yetersiz kalıp diske taşıyor demektir.

3. Disk Giriş/Çıkış (G/Ç) Yükünü Ölçün

  1. Disk kullanım oranını izleyin:
    iostat -x 1 3

    Beklenen sonuç (test sunucusunda alınan gerçek çıktı): boştaki diskte %util sütunu 1-2 civarında, w_await (yazma gecikmesi) birkaç milisaniye. %util sürekli yüzde doksanın üzerindeyse ve w_await/r_await onlarca milisaniyeyi buluyorsa disk darboğazdadır; genellikle yoğun bir veritabanı ya da yedekleme sürecinin işaretidir.

4. Ağ Katmanını Ölçün

  1. Arayüz hata ve düşme sayaçlarına bakın:
    ip -s link

    Beklenen sonuç (test sunucusunda alınan gerçek çıktı): RX errors 0 dropped 0, TX errors 0 dropped 0. Bu sayaçlar zamanla artıyorsa ağ sürücüsünde ya da bağlantıda bir sorun var demektir; sayaçlar sıfırda kalıp yalnızca uygulama yanıtı yavaşsa sorun ağda değil uygulamadadır.

  2. Açık bağlantı sayısını görün:
    ss -s

    Beklenen sonuç (test sunucusunda alınan gerçek çıktı): TCP: 4 (estab 1, closed 0, orphaned 0, timewait 0). Bu sayı normalde birkaç yüzü geçmez; binlerce bağlantı ve yüksek timewait sayısı, uygulamanızın bağlantıları düzgün kapatmadığını gösterir (bkz. ss’in resmi man sayfası).

5. Yanlış Yapılandırılmış Uygulamayı Bulun

  1. En çok CPU ve RAM tüketen süreçleri listeleyin:
    ps aux --sort=-%cpu | head -8ps aux --sort=-%mem | head -8

    Beklenen sonuç: listenin en üstündeki satır tek bir sürecin toplam CPU/RAM içindeki payını (%CPU, %MEM sütunları) gösterir. Boş bir sunucuda bu değerler %1’in altındadır; canlı bir sistemde bir veritabanı, önbellek ya da uygulama süreci sürekli %50’nin üzerinde görünüyorsa yavaşlığın kaynağı odur.

Doğrulama

Sonuç

Beş ölçümü çalıştırdıktan sonra hangi eşiğin aşıldığını (yüksek load average, düşük “available” RAM, yüksek %util, artan hata sayaçları ya da baskın bir süreç) işaretleyin; gerçek neden genellikle bunlardan yalnızca biridir.

Hâlâ Çözülmediyse

  • CPU sürekli yük altında. Hangi sürecin sorumlu olduğunu top‘ta bulup uygulamanızı optimize edin ya da sunucunuzu daha fazla çekirdekli bir pakete yükseltin.
  • RAM yetersiz, swap sürekli dolu. Kısa vadeli çözüm için swap alanı oluşturun; kalıcı çözüm daha fazla RAM’li bir pakete geçmektir.
  • Belirli bir servis kaynak tüketiyor. Servisi yeniden başlatıp davranışın değişip değişmediğini gözlemleyin.
  • Disk dolmaya yakın ya da G/Ç yüksek. Önce disk kullanımını denetleyin.

Narhost desteği

Talebe şunları ekleyin: sunucunuzun IP adresi, işletim sisteminiz, yukarıdaki beş komutun çıktıları ve yavaşlığın ne zaman başladığı.

Destek talebi aç

Sıkça sorulan sorular

Sunucuyu yeniden başlatmak yavaşlığı çözer mi?

Geçici olarak biriken bellek sızıntısını ya da takılı kalmış bir süreci temizleyebilir ama kök nedeni ortadan kaldırmaz; aynı belirti birkaç gün içinde tekrarlanırsa yeniden başlatmadan önce bu karttaki beş ölçümü mutlaka çalıştırın.

Narhost bu teşhisi benim yerime yapar mı?

Hayır, VDS yönetimsizdir; Narhost altyapıyı ve ağı sağlar, işletim sistemi içindeki yük teşhisi ve müdahale sunucunuzda size aittir. Destek ekibi ağ ve altyapı tarafını kontrol edebilir.

iostat komutu “command not found” diyor, ne yapmalıyım?

iostat, sysstat paketinin parçasıdır ve bazı temel imajlarda kurulu gelmez; dağıtımınıza göre apt install sysstat ya da dnf install sysstat ile kurabilirsiniz.

Bu makale sorununuzu çözdü mü?

Çözemediniz mi?

Teknik ekibimiz sunucu tarafındaki ayarları sizin için kontrol edebilir. Destek talebinizde alan adınızı ve aldığınız hata metnini paylaşmanız süreci hızlandırır.

Etiketler: performans

İlgili çözümler