Siteniz açılmıyor veya yavaşladı, destek talebi açtınız ve yanıt olarak "Hosting kaynak tüketiminiz izin verilen sınırı aştı" yazdılar. Şimdi önünüzde birkaç renkli çizgi ve hiçbiri net bir anlam taşımayan sayılarla dolu bir grafik var. Bu metin tam da o an için: o grafiği okumak ve sayıdan kod satırına ulaşmak.
Önce çoğu kişiyi yoldan çıkaran bir nokta: paylaşımlı hostingde CPU size "tahsis" edilmez. Ortak bir işlemcinin bir payına sahipsiniz ve sağlayıcı bunu iki mekanizmayla kontrol eder; biri anlık tüketim tavanı (genellikle CPU yüzdesi olarak ve kısa aralıklarla ölçülür), diğeri eşzamanlı işlem sayısı tavanı, yani entry process. İlk sayı ne kadar hızlı koştuğunuzu, ikinci sayı kaç kişinin aynı anda girebileceğini söyler. Bu ikisini birbiriyle karıştırmayın, çünkü tedavileri tamamen farklıdır.
Yanılmamak için CPU grafiği nasıl okunur
Tepe noktasına değil, grafiğin şekline bakın. Pratikte üç kalıp görüyorum:
- Dar ve sık tekrarlanan tepeler: Belirli bir betik düzenli aralıklarla çalışıyor. Neredeyse her zaman bir cron ya da tarayıcının birkaç saniyede bir gönderdiği bir AJAX isteğidir.
- Saatlerce yüksek ve düz seviye: Gerçek trafik değil, bir döngü. Kendi içinde takılıp sürekli veritabanına vuran bir betik.
- Basamaklı ve belirli saatlerle örtüşen: İnsan trafiği. Her gün saat 10-12 arası yükseliyorsa sorun kapasitedir, hata değil.
Sık gördüğüm gerçek bir sayı: Günde 400 ziyaretçisi olan bir sitenin CPU grafiği her gece saat 3'te yüzde 90'a ulaşıyor ve 20 dakika orada kalıyor. Ne ziyaretçi var ne saldırı. Aynı hostingde 1,2 GB'lık bir veritabanı yedeği alınıyor, --single-transaction olmadan, bu da tabloları kilitliyor ve bitene kadar her şeyi felç ediyor.
Pratikte CPU ve entry process farkı
Entry process dolmuşsa kullanıcı 508 Resource Limit Is Reached hatası görür veya beyaz sayfayla karşılaşır, ama CPU düşük olabilir. Bu durum isteklerin üst üste yığıldığı ve her birinin bir şeyi beklediği anlamına gelir; genellikle yavaş bir dış istek (bir ödeme geçidi API'si, bir SMS web servisi) ya da yanıtı 30 saniye süren ağır bir sorgu. Tersi de olur: CPU yüzde 100'de kilitliyken site açılır, çünkü sadece tek bir işlem çılgınca çalışıyordur.
Yüksek tüketimli betiği şu anda elinizdeki araçlarla bulmak
Her şeyden önce, hosting panelinden access log dosyasını arayın. SSH erişiminiz varsa, suçluya ulaşmanın en hızlı yolu şu iki komuttur:
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -20Bu satır hangi yolların en çok istek aldığını söyler. Listede wp-cron.php veya admin-ajax.php üstteyse sorun trafik değil, sitenin kendisidir. İkinci komut tüketimi zaman aralığına bağlar:
grep "admin-ajax.php" access.log | awk '{print $4}' | cut -d: -f2 | sort | uniq -cBu komutun çıktısı saatlik dağılımı gösterir. Tüm istekler tek bir dakikada yoğunlaşıyorsa, JavaScript'te bir döngü ya da bozuk bir cron'unuz var demektir.
Sorgular için, MySQL erişilebilirse SHOW FULL PROCESSLIST; komutunu birkaç saniye arayla iki kez çalıştırın. Her iki çıktıda da bulunan sorgu, o darboğazdır. WordPress'te sorguları loglayan eklenti genellikle kendisi tüketim yaratır; sadece birkaç dakika açıp sonra kapatın.
Sorunun ağdan mı yoksa DNS'ten mi kaynaklanmadığını ve yavaşlamanın sunucu tarafında olduğunu doğrulamak için DNS ve ağ kontrolü iyi bir başlangıç noktasıdır; TTFB yüksekse ama DNS hızlı çözümleniyorsa, konu tamamen dahilidir.
Cron'ları ciddiye alın
Bana yönlendirilen vakaların yarısı, birinin unuttuğu bir cron'dur. crontab -l ile listeyi görün ve her satır için "en son ne zaman gerekliydi" diye sorun. Beş alanlı sözdizimini tam hatırlamıyorsanız, tam cron sözdizimi referansını açın; dakika alanındaki yanlış bir *, ağır bir betiği her dakika çalıştırır ve siz hacklendiğinizi sanırsınız.
Burada hata yapıyorlar: Kullanıcı grafiği görür, hemen bir önbellek eklentisi kurar ve "çözüldü" der. İki gün sonra aynı tepe geri döner, bu kez daha kötü. Önbellek yalnızca PHP çalıştırma sayısını azaltır; suçlu betik bir cron ya da arka plan işlemiyse, önbelleğin ona hiçbir etkisi yoktur ve yalnızca sorunu siz tekrar sınırı aşana kadar gizler. İşareti şudur: Önbellek kurulduktan sonra CPU tüketimi biraz düşer ama gece tepeleri yerinde kalır.
Hangi çözümü seçmeliyiz
Üç gerçek yol var ve aralarındaki seçim, suçluyu bulup bulmadığınıza bağlıdır.
| Durum | Doğru eylem | Ödediğiniz bedel |
|---|---|---|
| Suçlu belli (cron, eklenti, sorgu) | Kökten çözüm: devre dışı bırakma, sorgu optimizasyonu, indeks | Geliştirici zamanı |
| Suçlu belli değil, trafik gerçek | Daha fazla kaynağa yükseltme veya özel sunucuya geçiş | Daha yüksek aylık maliyet ve sunucu yönetimi sorumluluğu |
| Suçlu belli değil, trafik de az | Temizlik ve yeniden yapılandırma: kullanılmayan eklentileri silme, betiği yeniden yazma | Zaman ve sitenin geçici olarak bozulma riski |
Bana sorarsanız, vakaların yüzde 80'inde birinci satır cevaptır ve plan yükseltmek yalnızca sorunun görünümünü değiştirir. Ama bir şartım var: Suçlu giderildikten sonra sitenin temel tüketimi (trafiksiz) hâlâ payınızın yüzde 30'unun üzerindeyse, optimizasyonun artık faydası yoktur ve kaynakları yükseltmelisiniz. O yüzde 30 keyfi bir sayı değil; trafik tepeleri ve gece yedeği için ihtiyacınız olan boşluktur.
Bir tuzak daha: Bazıları kısıtlamadan kaçmak için veritabanını başka bir sunucuya taşır. İki sunucu arasındaki ağda gecikme varsa, her sorgu birkaç milisaniye yavaşlar ve 200 sorgulu bir sayfada bu birkaç saniye demektir. Sonuç şu olur: CPU düşer ama entry process dolar, çünkü her işlem daha uzun süre açık kalır.
Bugün yapacağınız pratik işler
- Son 24 saatin erişim logunu indirin ve yukarıdaki iki komutu çalıştırın.
- Cron listesini
crontab -lile ve panelden alın, açıklamasını bilmediğiniz her satırı devre dışı bırakın. - Eklentileri tek tek devre dışı bırakın ve her birinden sonra 10 dakika grafiği izleyin. Bu iş yorucudur ama en kesin yöntemdir.
- Veritabanı hatası alıyorsanız ve elinizde ağır bir SQL dosyası varsa, basit içe aktarma yerine zaman aşımı olmadan büyük SQL içe aktarma yöntemini kullanın; eksik içe aktarma, sürekli yüksek tüketimin yaygın nedenlerinden biridir.
- Sunucu kuralları ve yönlendirmeler için htaccess direktifleri referansına bakın; döngüsel bir yönlendirme sonsuza kadar istek üretebilir.
Site WordPress'teyse ve çok sayıda eklentiniz varsa, her şeyden önce kurulu PHP eklenti listesini kontrol edin; bazen bir eklenti, bir modülün eksikliği nedeniyle daha yavaş bir yolu seçer. Desteklenen PHP eklentileri listesi ve test yöntemleri bunu netleştirir.
Ve siteyi sıfırdan sağlam bir altyapıya kurmak istiyorsanız, Linux hosting loglara ve cron'a tam erişimle bu metinde anlattığımız işleri mümkün kılar; log olmadan suçluyu teşhis etmek tahminden ibarettir.
Sık sorulan sorular
Ziyaretçi yokken hosting CPU tüketimim neden geceleri yükseliyor?
Neredeyse her zaman bir cron ya da yedekleme işlemidir. Cron'ları crontab -l ile ve hosting panelinden kontrol edin ve hangilerinin o saatte çalıştığını görün. Tabloları kilitlemeden alınan veritabanı yedeği ve WordPress'in otomatik optimizasyonu, geceleri en yaygın iki suçludur.
508 Resource Limit Is Reached hatası CPU'nun bittiği mi yoksa başka bir şey mi demek?
Bu hata genellikle CPU ile değil, entry process tavanıyla ilgilidir. Yani eşzamanlı işlem sayınız dolmuş ve yeni isteğin oturacak yeri yok. İşareti şudur: CPU grafiği düşükken site bazı kullanıcılar için açılır, bazıları için açılmaz.
Önbellek eklentisi kurmak hosting kaynak tüketimi sorununu çözer mi?
Yalnızca suçlu, tekrarlayan ziyaretçiler için tekrarlanan PHP çalıştırmasıysa. Suçlu bir cron, ağır bir sorgu ya da yavaş bir dış istekse, önbelleğin ona hiçbir etkisi yoktur ve yalnızca tepeleri geciktirir. Önce suçluyu bulun, sonra önbellek koyun.
Planı yükseltmem mi yoksa sadece kodu mu optimize etmem gerektiğini nereden anlarım?
Sitenin temel tüketimini trafiğin sıfır olduğu saatte ölçün. Cron'ları ve gereksiz eklentileri kaldırdıktan sonra hâlâ payınızın yüzde 30'unun üzerindeyse, daha fazla optimizasyon işe yaramaz ve yükseltme zamanıdır. Altındaysa sorun kapasite değil koddur.