Site Belirli Saatlerde Yavaşlıyor: Nedenleri

Site belirli saatlerde yavaşlıyor şikâyeti, performans sorunları arasında teşhisi en kolay ama en çok gözden kaçanıdır. Kolaydır çünkü elinde çok güçlü bir ipucu vardır: sorunun bir saati vardır ve o saatte ne olduğunu bulmak, "genel olarak yavaş" şikâyetini çözmekten kat kat basittir. Gözden kaçar çünkü sen sabah kontrol ettiğinde her şey normaldir, hız testi 90 puan verir ve sorunu "bende olmuyor" diyerek kapatma eğilimine girersin.

Bu yazıda önce desenin gerçekten zamana bağlı olup olmadığını doğrulayacağız, sonra en sık karşılaşılan beş nedeni tek tek ele alacağız: zamanlanmış görevler, trafik zirveleri, paylaşımlı altyapıdaki komşu etkisi, bot tarama dalgaları ve arka plan bakım işleri. Her nedenin nasıl doğrulanacağını ve nasıl kalıcı olarak çözüleceğini komutlarla göstereceğim.

Önce Deseni Doğrula: Gerçekten Saate Bağlı mı#

İlk adım, hissi veriye çevirmektir. "Akşamları yavaşlıyor" ifadesi çoğu zaman doğrudur ama bazen sadece akşamları siteye bakıldığı için öyle görünür. Elinde saat bazında bir dağılım olmadan hiçbir hipoteze yatırım yapma.

Web sunucusu erişim günlüğünde süre alanın varsa desen zaten oradadır. Yoksa önce onu ekle; yöntemi sunucu yanıt süresi izleme yazısında adım adım anlattım. Süre alanı varsa saatlik özet çıkarmak tek komutluk iştir:

LOG=/var/log/nginx/firmaniz-access.log

# Saat bazında istek sayısı ve ortalama yanıt süresi
awk '{
  for (i=1; i<=NF; i++) if ($i ~ /^rt=/) { sub("rt=","",$i); sure=$i }
  split($4, t, ":"); saat=t[2]
  adet[saat]++; topla[saat]+=sure
} END {
  for (s in adet) printf "%s:00  istek=%-7d ort=%.3f sn\n", s, adet[s], topla[s]/adet[s]
}' "$LOG" | sort

Sistem tarafında da geçmişe dönük veri toplayabilirsin. sysstat paketi kuruluysa sar sana günün her dakikasına ait CPU, disk ve bellek geçmişini verir:

# Bugünün CPU geçmişi - %iowait ve %steal sütunlarına dikkat
sar -u

# Disk aktivitesi geçmişi
sar -d -p

# Belirli bir güne ait kayıt (ayın 14'ü)
sar -u -f /var/log/sysstat/sa14

sysstat kurulu değilse hemen kur ve bir gün bekle; tek bir günlük veri bile çoğu deseni ortaya çıkarır. Elde iki grafik olacak: istek yoğunluğu ve kaynak kullanımı. Bu ikisinin birlikte mi yoksa ayrı ayrı mı tırmandığı, nedeni doğrudan ikiye ayırır.

Neden 1: Zamanlanmış Görevler ve Cron#

Yavaşlama tam ve yuvarlak bir saatte başlıyorsa (03:00, 04:00, her saat başı, her yarım saatte) neden neredeyse kesinlikle bir zamanlanmış görevdir. Yedekleme, günlük döndürme, veritabanı optimizasyonu, e-posta kuyruğu, sitemap üretimi ve arama indeksleme bu kategorinin klasikleridir.

Önce sistemdeki tüm zamanlanmış görevleri tek yerde topla:

# Kullanıcı cron tabloları
for k in $(cut -f1 -d: /etc/passwd); do
  echo "=== $k ==="; crontab -u "$k" -l 2>/dev/null
done

# Sistem geneli cron dizinleri
cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/

# systemd zamanlayıcıları - cron kadar sık atlanır
systemctl list-timers --all

systemctl list-timers çıktısını mutlaka kontrol et. Modern dağıtımlarda paket güncelleme kontrolü, dosya sistemi taraması ve günlük temizliği gibi işler cron yerine systemd zamanlayıcılarıyla çalışır ve klasik cron listesinde hiç görünmezler.

WordPress kullanıyorsan ayrı bir tuzak var: WP-Cron varsayılan olarak gerçek bir zamanlayıcı değildir, ziyaretçi isteği geldiğinde tetiklenir. Trafiğin arttığı saatte planlanmış görevler birikmişse her ziyaretçi isteği bir arka plan işini de sırtlar. Doğru çözüm WP-Cron'u kapatıp gerçek bir cron kurmaktır:

// wp-config.php içine, "That's all" satırından önce
define('DISABLE_WP_CRON', true);

# Ardından gerçek bir cron kur - trafikten bağımsız, düzenli çalışır
*/5 * * * * cd /var/www/firmaniz && /usr/bin/php wp-cron.php >/dev/null 2>&1

Görevin kendisi gerekliyse ve kaldıramıyorsan iki şey yap: çalışma saatini trafiğin en düşük olduğu ana kaydır ve işi önceliksizleştir. nice ve ionice bir yedekleme işinin CPU ve disk üzerindeki baskısını ciddi biçimde azaltır:

# CPU ve disk önceliği düşürülmüş yedekleme
30 4 * * * nice -n 19 ionice -c2 -n7 /usr/local/bin/yedek-al.sh

Neden 2: Trafik Zirveleri ve Kaynak Doygunluğu#

Yavaşlama saati aynı zamanda en yoğun trafik saatinse ve istek grafiği ile kaynak grafiği birlikte tırmanıyorsa neden basittir: sunucu o yükte yetmiyor. Burada önemli olan hangi kaynağın önce dolduğunu bulmaktır, çünkü yanlış kaynağı büyütmek para harcayıp sorunu çözmemek demektir.

Son satır en çok atlanan durumdur. Sunucunun CPU'su boş, belleği bol ama kullanıcılar bekliyorsa sorun kaynak değil, aynı anda kaç isteği işleyebildiğindir. PHP-FPM havuz durumunda listen queue sürekli sıfırdan büyükse tam olarak budur:

# Kuyrukta bekleyen istek var mı
curl -s "http://127.0.0.1/fpm-status" | grep -E "listen queue|active processes|max children"

Yük ortalamasını yorumlarken çekirdek sayısına bölmeyi unutma; 8 çekirdekli bir makinede 6,00 yük sağlıklıyken tek çekirdeklide 2,00 zaten sıkışmadır. Ayrımın detayı için load average nasıl okunur yazısına bak. Yoğun saatte uygulamaya inen istek sayısını düşürmenin en ucuz yolu ise önbellektir; nginx FastCGI cache ya da LiteSpeed Cache ile aynı donanımda birkaç kat daha fazla ziyaretçi taşıyabilirsin.

Neden 3: Komşu Etkisi ve Steal Time#

Paylaşımlı hosting ya da aşırı satılmış (oversold) bir sanallaştırma ortamındaysan, yavaşlamanın nedeni senin sitende hiç olmayabilir. Aynı fiziksel makineyi paylaştığın başka bir müşterinin yoğun saati, senin sitene yavaşlama olarak yansır. Buna "gürültücü komşu" denir ve tek başına en can sıkıcı senaryodur çünkü senin tarafında düzeltilecek bir şey yoktur.

Sanal sunucuda bunun doğrudan bir göstergesi vardır: steal time. Bu, hipervizörün senin sanal makinene CPU vermek istediği ama fiziksel çekirdeğin başkası tarafından meşgul edildiği için veremediği zamanın oranıdır.

# %st sütunu steal time - sürekli %2'nin üzerindeyse dikkat
vmstat 1 10

# Geçmişe dönük steal time
sar -u | awk '{print $1, $6}'   # %steal sütunu

# top içinde "st" değeri, ilk CPU satırında görünür
top -bn1 | head -3

Steal time yorumu şöyledir: yüzde 0–1 normaldir, yüzde 2–5 dikkat gerektirir, yüzde 5 üzeri sürekli devam ediyorsa komşuların kaynağını yiyor demektir. Bu değer yavaşlama saatinde tırmanıp diğer saatlerde düşüyorsa teşhis tamamlanmıştır.

Paylaşımlı hostingde steal time'ı göremezsin ama benzer belirtiler vardır: aynı işlem bazı saatlerde iki üç kat uzun sürer, disk okuma hızları dalgalanır ve hosting panelindeki kaynak grafiklerinde limitine hiç yaklaşmadığın hâlde yavaşlık yaşarsın. Bu tabloda tek kalıcı çözüm izole kaynağa geçmektir; ayrılmış çekirdek ve garanti edilmiş bellek sunan bir yapıya taşınmak sorunu tümden ortadan kaldırır.

Neden 4: Bot ve Tarama Dalgaları#

Kaynak grafiği tırmanıyor ama gerçek kullanıcı sayısı artmıyorsa, aradaki farkı bot trafiği kapatıyordur. Arama motoru tarayıcıları, fiyat karşılaştırma robotları, içerik kazıyıcılar ve güvenlik açığı tarayıcıları genellikle gece ve sabaha karşı yoğunlaşır; çünkü o saatler onların da boş zamanıdır.

Trafiğin ne kadarının bot olduğunu görmek için erişim günlüğünde kullanıcı aracısı alanını say:

LOG=/var/log/nginx/firmaniz-access.log

# Saat bazında bot ve insan isteklerini ayır
awk '{
  split($4, t, ":"); saat=t[2]
  satir=tolower($0)
  if (satir ~ /bot|crawl|spider|slurp|bingpreview|headless/) bot[saat]++; else insan[saat]++
} END {
  for (s in bot) printf "%s:00  bot=%-7d insan=%-7d oran=%%%.0f\n", s, bot[s], insan[s], 100*bot[s]/(bot[s]+insan[s])
}' "$LOG" | sort

Bot oranının belirli saatlerde yüzde 40–50'ye çıkması hiç de nadir değildir. Sorun sadece istek sayısı da değildir: botlar genellikle önbelleğe girmeyen, filtreli ve parametreli adresleri gezerler, yani her istekleri uygulamaya kadar iner ve gerçek bir kullanıcıdan kat kat pahalıya mal olur. Bu mekanizmanın ayrıntısı ve sınırlama yöntemleri için bot trafiği sunucu yükünü nasıl artırır yazısına bak; tarama hızının site hızıyla ilişkisini ise tarama bütçesi ve site hızı yazısında ele aldım.

Neden 5: Arka Plan Bakım İşleri ve Güncellemeler#

Son kategori, senin kurmadığın ama sistemin kendi kendine çalıştırdığı işlerdir. Bunlar cron listesinde bazen görünmez ve tam olarak bu yüzden teşhiste en son akla gelirler.

• Paket güncelleme kontrolleri. Otomatik güncelleme açıksa günün belirli bir saatinde depo indeksleri çekilir ve paketler kurulur. Kurulum sırasında servis yeniden başlatılabilir.
• Dosya sistemi ve kötü amaçlı yazılım taramaları. Sunucu güvenlik araçları tüm disk ağacını gezer; bu, ağır bir disk yüküdür ve iowait'i tavana vurdurur.
• Günlük döndürme ve sıkıştırma. Büyük erişim günlüklerinin sıkıştırılması hem CPU hem disk tüketir.
• Veritabanı bakımı. Tablo optimizasyonu ve indeks yeniden oluşturma işlemleri tablo kilidi alabilir; kilit süresince o tabloya dokunan her istek bekler.
• Yedekleme. Özellikle anlık görüntü almayan, dosya dosya kopyalayan yedekleme yöntemleri hem disk hem ağ üzerinde ciddi baskı yaratır.

Bu işlerin ne zaman çalıştığını sistem günlüklerinden doğrulayabilirsin:

# Yavaşlama saatinde sistemde ne olmuş
journalctl --since "bugün 03:00" --until "bugün 05:00" --no-pager | less

# Cron'un o aralıkta ne çalıştırdığı
journalctl -u cron --since "bugün 03:00" --until "bugün 05:00" --no-pager

Çözüm genelde işi kaldırmak değil, zamanlamasını dağıtmaktır. Beş farklı bakım işi hepsi 03:00'te başlıyorsa hepsini yirmişer dakika arayla dağıt; aynı toplam iş yapılır ama tepe yük beşte bire iner.

Sık Yapılan Hatalar#

Yavaşlama saatinde ölçüm yapmamak. Sabah bakıp "sorun yok" demek en yaygın hatadır. Ölçümü mutlaka olayın olduğu saatte, mümkünse otomatik olarak topla.

Tek bir nedeni doğrulamadan kabul etmek. Cron listesinde bir yedekleme görünce teşhisi kapatma; aynı saatte bot dalgası da olabilir. En az iki bağımsız kanıt ara: kaynak grafiği ve günlük verisi.

Görevleri hepsini aynı saate koymak. Yuvarlak saatler cazip görünür ama beş işi 03:00'e koymak yapay bir zirve üretir. Dakikaları dağıt.

Belirtiyi bastırmak. Yavaşlama saatinde önbellek süresini uzatmak ya da bazı özellikleri kapatmak semptomu gizler, nedeni ortadan kaldırmaz. Bir sonraki büyümede aynı sorun daha şiddetli geri gelir.

Komşu etkisini hiç değerlendirmemek. Kendi tarafında saatlerce arayıp bir şey bulamıyorsan ve steal time yüksekse, sorun senin yapılandırmanda olmayabilir. Bu ihtimali erken kontrol et.

Sıkça Sorulan Sorular#

Site her gece aynı saatte yavaşlıyorsa ilk nereye bakmalıyım#

Zamanlanmış görevlere. Yuvarlak ve tekrarlayan bir saat, neredeyse her zaman bir cron ya da systemd zamanlayıcısına işaret eder. Önce tüm kullanıcı cron tablolarını, /etc/cron.* dizinlerini ve systemctl list-timers çıktısını topla. Yedekleme, günlük sıkıştırma ve veritabanı bakımı listenin başında yer alır. İkinci sırada gece yoğunlaşan bot tarama dalgaları gelir.

Steal time yüksek çıkıyor, ne yapmalıyım#

Steal time senin sanal makinene ayrılan CPU zamanının fiziksel sunucudaki başka bir makine tarafından kullanıldığını gösterir ve kendi tarafında yazılımla çözemezsin. Sürekli yüzde 5'in üzerindeyse sağlayıcına bu ölçümlerle birlikte başvur; çoğu durumda makineni daha az yüklü bir düğüme taşırlar. Kalıcı çözüm ayrılmış çekirdek sunan bir plana geçmektir.

Yoğun saatte sunucuyu büyütmek çözüm mü#

Darboğaz gerçekten kaynak yetersizliğiyse evet, ama önce hangi kaynağın dolduğunu doğrula. CPU doygunsa çekirdek eklemek işe yarar; sorun eşzamanlılık limitindeyse aynı donanımda havuz ayarını düzeltmek bedava çözer. Çoğu sitede en yüksek getirili adım donanım değil, önbellek katmanını doğru kurmaktır: önbellekten dönen istek uygulamaya hiç inmez ve aynı sunucuda birkaç kat trafik taşınır.

Paylaşımlı hostingde bu sorunu çözebilir miyim#

Sınırlı ölçüde. Kendi tarafında yapabileceklerin var: önbellek eklentisini doğru yapılandırmak, ağır zamanlanmış görevleri seyrekleştirmek, gereksiz eklentileri kaldırmak ve sayfa ağırlığını düşürmek. Ancak yavaşlama komşu etkisinden geliyorsa hiçbiri kalıcı sonuç vermez, çünkü sorunun kaynağı senin hesabının dışındadır. O noktada izole kaynaklı bir yapıya geçmek tek gerçek çözümdür.

Yavaşlamanın bot kaynaklı olduğunu nasıl kesinleştiririm#

Erişim günlüğünde saat bazında bot ve insan isteklerini ayır. Yavaşlama saatinde bot oranı belirgin biçimde artıyorsa ve gerçek kullanıcı sayısı sabitse teşhis nettir. Ek bir kanıt olarak istenen adreslere bak: botlar genellikle filtreli, sayfalanmış ve parametreli adresleri gezer, bunlar önbelleğe girmez ve uygulamaya kadar iner. Kendini Googlebot olarak tanıtan istekleri ters DNS ile doğrulamayı da unutma.

sysstat kurulu değil, geçmiş veriyi nasıl toplarım#

sysstat paketini kur ve servisi etkinleştir; varsayılan olarak on dakikada bir örnek alır ve verileri günlük dosyalarda saklar. Bir gün beklemen yeterlidir. Daha yüksek çözünürlük istiyorsan Netdata gibi bir ajan kurabilir ya da basitçe bir cron göreviyle her dakika uptime, free -m ve vmstat 1 2 çıktısını bir dosyaya ekleyebilirsin. Bu kadar basit bir kayıt bile çoğu deseni ortaya çıkarır.

Kapanış#

Zamana bağlı yavaşlama, elinde en güçlü ipucunun olduğu performans sorunudur; onu çözmenin yolu tahmin etmek değil, o saatte ne olduğunu kayda geçirmektir. Aklında kalması gereken dört alışkanlık şu: hipoteze girmeden önce deseni saat bazında doğrula, zamanlanmış görevleri cron ve systemd tarafında birlikte listele, kaynak grafiği ile trafik grafiğini üst üste koyup ikisinin birlikte mi tırmandığına bak ve bakım işlerini aynı dakikaya yığmak yerine zamana yay.

Steal time yüksekse ya da yoğun saatte kaynağın sürekli sınırına dayanıyorsa çözüm yapılandırmada değil, izole kaynakta olabilir: ayrılmış çekirdekli VDS ve talebe göre ölçeklenen bulut sunucu paketlerimiz komşu etkisini tamamen ortadan kaldırır. Zamanlanmış görevleri düzenlemek, önbellek katmanını kurmak ve izlemeyi ayağa kaldırmak için yardım istersen sunucu yönetimi hizmetimiz bu işi üstlenir. Trafiğinin ne kadar bant genişliği tükettiğini merak ediyorsan bant genişliği hesaplayıcı aracımızla hızlıca hesaplayabilirsin.