Sunucum Yavaşladı: CPU mu, RAM mi, Disk mi? Adım Adım Teşhis

Saat 14:40, telefon çalıyor: "Site açılmıyor." SSH'a bağlanıyorsunuz, kabuk isteminin gelmesi bile üç saniye sürüyor. uptime yazıyorsunuz, load average 9.60 görünüyor. Refleks olarak systemctl restart mysql ya da systemctl restart php8.3-fpm yazıyorsunuz; sistem beş dakika rahatlıyor, yarım saat sonra aynı yere dönüyor. Çünkü servisi yeniden başlatmak bir teşhis değildir — semptomu geçici olarak silmektir ve ertesi gün aynı saatte yine karşınıza çıkar.

Sunucuda "yavaşlık" tek bir arıza değildir. Dört ayrı kaynaktan (CPU, RAM, disk, ağ) herhangi birinin tükenmesi, dışarıdan bakınca birbirine çok benzeyen bir görüntü üretir: yükselen load, geciken cevaplar, zaman aşımına düşen istekler. Bu yüzden "hangi araç kullanılır" sorusu yanlış sorudur; doğru soru "hangi sırayla bakılır ve her adımda hangi rakam beni bir sonraki adıma yollar" sorusudur.

Bu rehber bir araç tanıtımı değil, bir eleme akışıdır. Beş adımda kaynakları teker teker devre dışı bırakacak, her adımda "bu değer normal mi" eşiğini vereceğiz. Sonunda elinizde tek bir cümle kalacak: "Bu sunucuda darboğaz şu kaynakta." Teşhisi koyduktan sonra hangi konuya devam edeceğinizi de yazının sonundaki yönlendirme tablosunda bulacaksınız.

Teşhise Başlamadan Önce Cevaplamanız Gereken Üç Soru#

Terminale bir komut yazmadan önce bu üç sorunun cevabı, sonraki adımlarda dakikalar kazandırır.

1. Ne zaman başladı ve deseni var mı? Sürekli yavaş bir sunucuyla, her gün 03:00'te ve her ayın 1'inde yavaşlayan bir sunucu tamamen farklı iki vakadır. Periyodik yavaşlık neredeyse her zaman zamanlanmış bir işe işaret eder: yedekleme, log rotasyonu, updatedb, cron ile çalışan bir rapor sorgusu. crontab -l, ls /etc/cron.daily/ ve systemctl list-timers üç komutta bu ihtimali kapatır.

2. Ne değişti? Yavaşlığın başladığı ana en yakın değişiklik nedir — bir dağıtım, bir eklenti kurulumu, yeni açılan bir reklam kampanyası, bir paket güncellemesi? Hiçbir şey değişmediyse çoğunlukla değişen şey trafik hacmi ya da veri hacmidir: dün 200 bin satır olan tablo bugün 2 milyon satırdır ve indeksi olmayan sorgu artık tüm tabloyu taramaktadır.

3. Yavaş olan sunucu mu, uygulama mı? Bu ayrımı en hızlı yapan test SSH'ın kendisidir. SSH oturumunda ls yazdığınızda cevap anında geliyor, ancak site hâlâ yavaşsa sunucunun kaynakları büyük ihtimalle iyidir; sorun uygulama katmanında, veritabanı sorgularında veya bir dış servis çağrısındadır. Kabuğun kendisi de takılıyorsa sorun sistem kaynaklarındadır ve aşağıdaki akış tam olarak size göredir. Uygulama tarafına yöneldiyseniz sitenin neden yavaş açıldığını ölçerek ayırma yazısı daha isabetli bir başlangıçtır.

Adım 1: Load Average — Ortada Gerçekten Bir Kuyruk Var mı?#

İlk komut her zaman aynıdır ve tek başına hiçbir şeyi teşhis etmez; sadece "kuyruk var mı, yok mu" sorusuna cevap verir.

uptime
nproc                      # sunucunun mantıksal çekirdek sayısı
cat /proc/loadavg

Load average bir yüzde değil, çalışan ya da çalışmayı bekleyen süreçlerin ortalama sayısıdır. Linux'ta bu sayıya diskten veri bekleyen (D durumundaki) süreçler de dâhildir; bu yüzden yüksek load tek başına "CPU doldu" demek değildir.

Değeri mutlaka çekirdek sayısına bölerek okuyun:

Üç değerin sırası da bilgi taşır: 9.60 4.20 1.80 yükselen bir olayın ortasında olduğunuzu, 1.10 3.40 8.90 ise en kötü anın geçtiğini söyler. Bu değerlerin ayrıntılı yorumu ve tuzakları için load average'ı doğru okumak yazısına bakabilirsiniz.

Kritik nokta şudur: load 1'in altındaysa bile sunucu yavaş olabilir. Tek çekirdeği tam dolduran tek iş parçacıklı bir PHP süreci, 8 çekirdekli bir makinede load'ı yalnızca 1,0'a çıkarır ama o isteği bekleyen kullanıcı için sunucu tamamen kilitlenmiş gibidir. O yüzden load düşük diye elemeyi burada bırakmayın; ikinci adıma geçin.

Adım 2: CPU Zamanı Nereye Gidiyor? us, sy, wa ve st#

top açıp gözünüzü süreç listesine değil, üstteki %Cpu(s) satırına dikin. Asıl teşhis o satırdadır. Daha da iyisi, anlık ekran yerine örnekleme almaktır:

vmstat 1 5                 # 1 saniye aralıkla 5 örnek
top -bn1 | head -5         # tek seferlik özet
mpstat -P ALL 1 3          # çekirdek başına dağılım (sysstat paketi)

vmstat çıktısının sağındaki cpu bloğu beş sütundur ve her biri farklı bir suçluyu gösterir:

Eşikler:

• us sürekli %80'in üzerindeyse darboğaz CPU'dur ve suçlu bir uygulamadır. Süreç bazında kimin yediğini bulmak için top içinde P tuşuna basın veya ps -eo pid,comm,%cpu --sort=-%cpu | head çalıştırın. Ayrıntı için ps, top ve htop ile süreç izleme.
• sy tek başına %30'un üzerindeyse alışılmadık bir durumdur: genellikle binlerce kısa ömürlü süreç doğuran bir betik, hatalı bir döngü ya da aşırı bağlam değişimi vardır. vmstat çıktısındaki cs (context switch) sütunu saniyede on binleri geçiyorsa bu şüpheyi doğrular.
• wa sürekli %15'in üzerindeyse CPU'yu suçlamayı bırakın; sistem diski bekliyor demektir. Doğrudan Adım 4'e geçin.
• st sürekli %5-10'un üzerindeyse sorun sizin sunucunuzda bile değildir: sanal makineniz fiziksel CPU'yu isteyip alamıyordur. Bu, paylaşımlı ana makinenin aşırı yüklü olduğunun göstergesidir ve tek çözümü sağlayıcıya bulguyla birlikte kayıt açmaktır. Kendi sunucunuzda yapacağınız hiçbir optimizasyon steal time'ı düşürmez.

mpstat -P ALL 1 3 çıktısı ayrıca çok değerli bir ayrım yapar: tüm çekirdekler eşit doluysa yük gerçekten paraleldir; tek bir çekirdek %100 iken diğerleri boştaysa suçlu tek iş parçacıklı bir süreçtir ve ona daha fazla çekirdek eklemek hiçbir işe yaramaz.

Adım 3: RAM Baskısı mı Var? free ve vmstat Birlikte Okunur#

Bellek teşhisinde en sık yapılan hata, free -h çıktısındaki used sütununa bakıp panik yapmaktır. Linux boştaki RAM'i disk önbelleğine çevirir; "dolu" görünmesi normaldir ve sağlıklıdır.

free -m
vmstat 1 5                 # si ve so sütunlarına bakın
grep -E 'MemAvailable|Committed_AS|Dirty' /proc/meminfo

Bakmanız gereken tek sütun available'dır: bu, önbelleğin geri alınabilir kısmı dâhil, yeni bir uygulamanın gerçekten kullanabileceği bellektir.

Kritik ayrım burada: swap'in dolu olması sorun değildir, swap'e sürekli giriş-çıkış olması sorundur. Uzun süre önce swap'e taşınmış ve bir daha dokunulmamış 300 MB tamamen zararsızdır. Ama vmstat çıktısında si (swap in) ve so (swap out) sütunları saniye başına sürekli sıfırdan büyükse sistem "thrashing" durumundadır: aynı sayfaları sürekli diske yazıp geri okur. Bu durumda CPU boşta görünse bile sunucu felç olmuş gibidir, çünkü her bellek erişimi disk erişimine dönüşmüştür. free çıktısının satır satır yorumu için bellek kullanımını free ile analiz etme yazısı ayrıntılı bir kaynak.

Belleği kimin yediğini bulmak için:

ps -eo pid,comm,rss --sort=-rss | head -10
# rss değerleri KB cinsindendir; MB için 1024'e bölün

Burada gördüğünüz tabloda MySQL ya da PHP-FPM tepedeyse, çözüm hemen daha fazla RAM almak olmayabilir: her ikisi de kendilerine verilen sınırı sonuna kadar kullanacak şekilde yapılandırılır, dolayısıyla önce o sınırların doğru ayarlandığından emin olun.

Adım 4: Disk Darboğazı — iostat Çıktısını Doğru Okumak#

Adım 2'de wa yüksek çıktıysa buradasınız. iostat sysstat paketiyle gelir (apt install sysstat veya dnf install sysstat).

iostat -xz 1 3             # ilk örneği yok sayın: açılıştan beri olan ortalamadır
iotop -o                   # anlık olarak G/Ç yapan süreçler (root gerekir)
dmesg -T | tail -30        # disk hatası, yeniden bağlanma, zaman aşımı var mı

iostat -xz çıktısında üç sütun kararı verir:

%util konusunda dikkatli olun: bu sütun "cihaza en az bir istek gönderilmiş olan zamanın oranıdır". Tek kafalı dönen bir diskte %100 gerçekten doygunluk demektir. Buna karşılık NVMe cihazlar onlarca isteği paralel işler; %100 %util gördüğünüz bir NVMe hâlâ kapasitesinin dörtte birinde olabilir. NVMe ve SSD'de karar sütunu await süresidir, %util değil.

Yüksek await gördüğünüzde sıradaki soru "kim yazıyor" olur. iotop -o anlık suçluyu gösterir. Sık çıkan üç desen:

• MySQL/MariaDB: indekssiz sorgular yüzünden geçici dosyalara yazıyor ya da innodb_buffer_pool_size çok küçük olduğu için her sorguda diske iniyordur. Bu durumda çözüm disk değil yapılandırmadır; MySQL ve MariaDB performans optimizasyonu doğru durak.
• Yedekleme veya arşivleme süreci: geçicidir, ama iş saatine denk geliyorsa zamanlamasını değiştirin ya da ionice -c3 ile önceliğini düşürün.
• Log yazımı: hata seviyesi yanlışlıkla debug bırakılmış bir uygulama saniyede yüzlerce satır yazıyordur.

Bir de disk dolu olduğu için yavaşlayan sunucu vakası vardır ve bu iostat çıktısında değil df çıktısında görünür. Dosya sistemi %95'in üzerinde doluysa yazma performansı belirgin düşer, veritabanları yazamaz hâle gelir. df -h ve df -i (inode) çıktısını mutlaka kontrol edin; ayrıntı için df, du ve ncdu ile disk analizi.

Adım 5: Ağ, Bağlantı Kuyruğu ve Sınır Tabloları#

Üç kaynağın da temiz çıktığı, ama sunucunun hâlâ isteği zamanında karşılamadığı durumlar vardır. Burada suçlu genellikle tükenen bir sayaçtır, tükenen bir kaynak değil.

ss -s                                  # soket özeti
ss -lnt                                # dinleyen soketlerde Recv-Q / Send-Q
nstat -az | grep -iE 'ListenOverflows|ListenDrops|TCPSynRetrans'
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

Yorum kuralları:

• ss -lnt çıktısında dinleyen bir soketin Recv-Q sütunu, kabul edilmeyi bekleyen bağlantı sayısıdır; Send-Q ise izin verilen en büyük kuyruktur. Recv-Q sürekli Send-Q'ya yakınsa uygulama gelen bağlantıları yeterince hızlı kabul edemiyor demektir. Bu, PHP-FPM'de pm.max_children yetmediğinde ortaya çıkan klasik tablodur; hesabı PHP-FPM pool ayarları yazısında bulabilirsiniz.
• ListenOverflows sayacı artıyorsa yukarıdaki kuyruk gerçekten taşmıştır ve istemciler sessizce reddedilmektedir. Kullanıcı tarafında bu, "bazen açılıyor bazen açılmıyor" olarak görünür.
• nf_conntrack_count değeri nf_conntrack_max sınırına dayanmışsa çekirdek yeni bağlantıları düşürmeye başlar; dmesg çıktısındaki nf_conntrack: table full, dropping packet satırı bunun kesin kanıtıdır. Sınırı yükseltmek doğru çözümdür; kalıcı ayar için sysctl ile kernel optimizasyonu.

Kararsız Kaldığınızda Hakem: /proc/pressure#

Modern çekirdeklerde (4.20 ve sonrası) hangi kaynağın gerçekten süreçleri beklettiğini tek bakışta söyleyen bir arayüz vardır: PSI (Pressure Stall Information).

cat /proc/pressure/cpu
cat /proc/pressure/io
cat /proc/pressure/memory

Her satırda avg10, avg60 ve avg300 değerleri bulunur ve bunlar yüzdedir: son 10, 60 ve 300 saniyede işlerin ne kadarlık bir zaman diliminde o kaynağı bekleyerek durduğunu gösterir. some en az bir sürecin, full ise tüm süreçlerin beklediği süredir.

Yorumu basittir: avg10 değeri hangi dosyada 10'un üzerindeyse darboğaz o kaynaktadır. Üç dosyanın da 1'in altında olduğu bir sunucuda kaynak darboğazı yoktur — yavaşlığın kaynağı uygulama mantığında, veritabanı sorgusunda ya da beklenen bir dış servistedir. Bu, load average'ın veremediği kesinlikte bir cevaptır ve teşhis akışını dakikalar yerine saniyelere indirir. Sürekli izleme kurmak isterseniz Netdata ile sunucu izleme bu metrikleri hazır grafiklerle sunar.

Teşhis Sonrası: Bulgudan Çözüme Yönlendirme Tablosu#

Eleme akışını tamamladığınızda elinizde bir bulgu vardır. Bu tablo, o bulguyu bir sonraki adıma bağlar.

Kalıcı olarak dört göstergesi de doygun bir sunucuda cevap yapılandırma değil kapasitedir; ihtiyacı doğru hesaplamak için VDS için kaç CPU ve RAM gerekir yazısındaki yöntemi kullanabilirsiniz.

Teşhiste En Sık Yapılan Beş Hata#

1. Tek bir anlık ekrana bakıp karar vermek. top ve iostat'ın ilk ekranı açılıştan beri olan ortalamayı içerir ve yanıltır. Her ölçümü en az 3-5 örnekle, 1 saniye aralıkla alın.
2. Load'ı çekirdek sayısıyla normalize etmemek. 8 çekirdekli makinede 4,0 rahat bir yüktür; tek çekirdekli makinede aynı değer felakettir.
3. buff/cache dolu diye "RAM bitti" demek. Karar sütunu available'dır.
4. Steal time'ı görmezden gelmek. Sanal sunucularda gerçek darboğaz bazen sizin makinenizde bile değildir; st sütununu her zaman kontrol edin.
5. Teşhis bitmeden servis yeniden başlatmak. Yeniden başlatma kanıtı (bellek büyümesi, açık bağlantı sayısı, çalışan sorgu) siler ve aynı sorunun tekrarını beklemek zorunda kalırsınız. Önce ps, ss ve log çıktılarını bir dosyaya alın, sonra müdahale edin.

Sıkça Sorulan Sorular#

Load average yüksek ama CPU boşta görünüyor, bu nasıl olur?#

Linux'ta load hesabına yalnızca CPU bekleyen süreçler değil, kesintisiz uykuda (D durumu) disk ya da ağ deposundan veri bekleyen süreçler de dâhildir. CPU'nun boşta, load'ın yüksek olduğu bir tabloda darboğaz neredeyse her zaman disktedir. vmstat çıktısındaki wa sütununa ve iostat -xz 1 çıktısındaki await değerine bakarak bunu doğrulayabilirsiniz.

Sunucu yavaşladığında ilk hangi komutu çalıştırmalıyım?#

Tek komut seçmek gerekirse vmstat 1 5 en verimlisidir: aynı ekranda CPU dağılımını, swap giriş-çıkışını, disk blok trafiğini ve bağlam değişimi sayısını birlikte gösterir. Çekirdek 4.20 ve üzeriyse /proc/pressure dosyalarını okumak daha da doğrudan bir cevap verir ve hangi kaynağın süreçleri beklettiğini yüzde olarak söyler.

RAM'i artırmak sunucumu hızlandırır mı?#

Yalnızca darboğaz bellekse. available değeri toplam RAM'in %20'sinin üzerindeyse ve vmstat çıktısında swap giriş-çıkışı yoksa RAM eklemek ölçülebilir bir hız kazandırmaz. Buna karşılık sürekli swap kullanan bir sunucuda RAM artırımı, disk beklemesini de ortadan kaldırdığı için beklenenden büyük bir iyileşme sağlar.

Steal time nedir, yüksekse ne yapabilirim?#

Steal time, sanal makinenizin CPU istediği hâlde fiziksel işlemciyi alamadan geçirdiği süredir. Sürekli %5-10'un üzerindeyse ana makine aşırı yüklüdür. Sunucu içinde yapacağınız hiçbir ayar bunu düzeltmez; ölçüm çıktılarını tarih ve saatle birlikte ekleyerek sağlayıcınıza kayıt açmanız veya kaynakları garantili bir pakete geçmeniz gerekir.

Servisleri yeniden başlatmak neden kalıcı çözüm olmuyor?#

Yeniden başlatma biriken belleği ve açık bağlantıları sıfırlar; bu yüzden sistem geçici olarak rahatlar. Ancak belleği büyüten sızıntı, indeksi olmayan sorgu veya yetersiz işçi süreç sayısı yerinde durduğu için aynı birikim yeniden başlar. Üstelik yeniden başlatma teşhis için gereken kanıtları da siler. Doğru sıra önce ölçüm ve kayıt, sonra müdahaledir.

Aynı anda hem CPU hem disk yüksek görünüyorsa hangisi asıl sebep?#

Genellikle biri diğerinin sonucudur. Bellek yetersizliğinde sistem swap'e yazar, bu disk yükü yaratır ve sayfa hatalarını yönetmek CPU'da sy süresini yükseltir; yani tek kök sebep RAM'dir. Bu yüzden sıralama önemlidir: önce belleği eleyin, sonra diski, en son CPU'yu. /proc/pressure dosyalarındaki avg10 değerlerini karşılaştırmak da hangisinin daha fazla beklemeye yol açtığını doğrudan gösterir.