Sunucu yavaşladığında ne yapmalı? Teşhis rehberi

Sunucu yavaşladığında ilk refleks genellikle "paketi büyütelim" olur. Oysa dar boğazın hangi katmanda olduğunu bilmeden kaynak eklemek, çoğu zaman parayı harcayıp sorunu çözmemek demektir.

Aşağıdaki sıra, dört katmanı birkaç dakikada eler.

1. Genel duruma bakın

bashuptime

Çıktının sonundaki üç sayı yük ortalamasıdır (son 1, 5 ve 15 dakika). Bu değerleri çekirdek sayınızla karşılaştırın:

bashnproc

4 çekirdekli bir sunucuda yük ortalaması 4'ün altındaysa işlemci dar boğaz değildir. Sürekli 8-10 gibi değerler görüyorsanız işlemci ya da disk beklemesi var demektir.

Üç sayının yönü de bilgi verir: 1 dakikalık değer 15 dakikalıktan büyükse yük artıyor, küçükse geçmiş bir tepe noktasından çıkıyorsunuz.

2. İşlemci mi, disk beklemesi mi?

bashtop -bn1 | head -5

İlk satırlardaki %Cpu(s) bölümünde şunlara bakın:

• us (user) yüksek → uygulamalarınız işlemciyi tüketiyor
• sy (system) yüksek → çekirdek düzeyinde bir sorun, genellikle aşırı sistem çağrısı
• wa (iowait) yüksek → işlemci boşta bekliyor, disk yetişemiyor
• st (steal) yüksek → sanallaştırma katmanında komşu yük var; garantili kaynaklı bir pakette bu değerin sıfıra yakın olması beklenir

wa değeri %10'un üzerindeyse sorun işlemcide değil diskte aramalısınız.

3. Bellek gerçekten dolu mu?

bashfree -h

used sütunu yanıltıcıdır — Linux boş belleği dosya önbelleği olarak kullanır ve ihtiyaç olduğunda anında bırakır. Bakılacak sütun available'dır.

Asıl uyarı işareti takas alanıdır:

bashvmstat 1 5

si ve so sütunları sürekli sıfırdan büyükse sunucu takas alanına yazıp okuyor demektir. Bu, yavaşlığın en sert sebeplerinden biridir ve bellek eklemek dışında kalıcı çözümü yoktur.

4. Diski kim meşgul ediyor?

bashapt install -y sysstat     # gerekiyorsa
iostat -x 1 3

%util sütunu %90'a yaklaşıyorsa disk doyuma ulaşmıştır. await sütunu ise isteklerin ortalama bekleme süresidir; NVMe bir diskte bu değerin milisaniyenin altında olması beklenir.

Bir de basit ama sık atlanan kontrol:

bashdf -h
df -i

Dolu disk, hizmetin sessizce durmasının en yaygın sebebidir. İkinci komut inode doluluğunu gösterir — küçük dosyaların çok olduğu sunucularda disk boş görünürken inode'lar tükenmiş olabilir.

5. Hangi süreç sorumlu?

bash# bellege gore ilk 10 surec
ps aux --sort=-%mem | head -11

# islemciye gore ilk 10 surec
ps aux --sort=-%cpu | head -11

Web sunucusu ya da PHP süreçleri listenin başındaysa sorun uygulama katmanındadır. Veritabanı başı çekiyorsa yavaş sorgu aramaya geçin:

bashmysqladmin -u root -p processlist

Uzun süredir çalışan bir sorgu görüyorsanız dar boğazı buldunuz demektir.

6. Ağ tarafı

bashss -s
ss -ant | awk '{print $1}' | sort | uniq -c

TIME-WAIT durumundaki bağlantıların çok olması normaldir. Ama SYN-RECV sayısı olağandışı yüksekse bir SYN flood ile karşı karşıya olabilirsiniz — bu durumda DDoS koruma rehberimize bakın.

7. Günlükleri okuyun

bashjournalctl -p err -n 50 --no-pager
dmesg -T | tail -30

dmesg çıktısında OOM killer kayıtları görüyorsanız çekirdek, bellek yetmediği için süreçleri öldürüyor demektir. Bu, "sunucu ara ara duruyor" şikâyetinin en yaygın açıklamasıdır.

Teşhisten sonra

Dar boğazı bulduğunuzda çözüm genellikle kaynak eklemek değildir:

• İşlemci → önbellekleme, yavaş sorguların düzeltilmesi, gereksiz eklentilerin kaldırılması
• Bellek → bellek sızıntısı olan sürecin bulunması, PHP-FPM işçi sayısının ayarlanması
• Disk → veritabanı indeksleri, günlük dosyalarının döndürülmesi, NVMe'ye geçiş
• Ağ → önbellek, CDN, hız sınırlama

Ölçmeden büyütmeyin. Ölçüm elinizdeyse kaynak planlamasını birlikte yapabiliriz.