Paylaşımlı Hostingde Hız Limitleri

Paylaşımlı hostingde hız limitleri, çoğu site sahibinin ancak sorun yaşadığında farkına vardığı görünmez bir tavan oluşturur. Paket sayfasında "sınırsız trafik" yazar, panelde disk alanı bol görünür, her şey yolundadır — ta ki bir gün site akşam saatlerinde ağırlaşana, arada bir "Resource limit reached" sayfası çıkana ya da yönetim paneli garip biçimde yavaşlayana kadar. Bu noktada sorunun kodda mı sunucuda mı olduğunu anlamak zorlaşır, çünkü hiçbir hata günlüğünde net bir açıklama yoktur.

Bu yazıda paylaşımlı bir pakette gerçekte hangi kaynakların sınırlandığını, bu sınırların hangi mekanizmayla uygulandığını, limite takıldığını nasıl anlayacağını ve takıldığında ne yapabileceğini anlatacağım. Amacım paylaşımlı hostingi kötülemek değil — doğru kullanıldığında son derece verimli bir modeldir. Amaç, sınırların nerede olduğunu bilerek karar vermeni sağlamak.

Paylaşımlı Modelde Kaynaklar Nasıl Bölüşülür#

Paylaşımlı hostingin ekonomisi basittir: tek bir fiziksel sunucuda yüzlerce, bazen binlerce hesap barınır ve her hesap donanımın küçük bir dilimini kullanır. Bu model, ortalama bir sitenin kaynağının çoğu zaman boşta durduğu gerçeğine dayanır. Yüz sitenin hepsi aynı anda tepe yükte çalışmaz, dolayısıyla toplam kapasite herkese yetecek şekilde paylaştırılabilir.

Sorun, bu dayanağın ihlal edildiği anlarda başlar. Bir hesap kontrolsüz kaynak tüketmeye başlarsa (kötü yazılmış bir eklenti, sonsuz döngüye giren bir görev, bir bot saldırısı) sunucudaki diğer herkes bundan etkilenir. Modern paylaşımlı sunucular bu yüzden hesap başına sert sınırlar uygular. Yaygın uygulama CloudLinux gibi bir katmanla her hesabı kendi hafif sanal ortamına (LVE) kapatmaktır; bu ortam CPU, bellek ve işlem sayısı için ayrı kotalar taşır.

Buradaki kritik ayrım şudur: sınır seni durdurmaz, yavaşlatır. CPU kotanı aştığında hesabın hata vermez; sadece işlemcinin sana ayrılan payı kısılır ve sayfa üretimi uzar. Kullanıcının gördüğü şey bir hata değil, "site bugün ağır" hissidir. Bu, teşhisi zorlaştıran ve konuyu bu kadar kafa karıştırıcı yapan ana sebeptir.

Hangi Kaynaklar Sınırlanır#

Paylaşımlı bir pakette tipik olarak beş kaynak sınırlanır ve her birinin belirtisi farklıdır. Bu tabloyu tanımak, sorunun hangi kotadan geldiğini anlamanın en hızlı yoludur.

Bu listede en çok yanlış anlaşılan giriş işlemi (entry process) sınırıdır. Bu, aynı anda kaç PHP isteğinin işlenebileceğini gösterir ve tipik paketlerde tek haneli sayılardadır. Şöyle düşün: sınır 20 ise ve sayfan üretilirken 1 saniye sürüyorsa, teorik olarak saniyede yaklaşık 20 isteği karşılarsın. Sayfa üretimini 200 milisaniyeye indirirsen aynı sınırla saniyede 100 istek karşılarsın. Yani giriş işlemi sınırına takılmanın çözümü genellikle daha büyük paket değil, sayfayı daha hızlı üretmektir.

İkinci en çok yanlış anlaşılan sınır inode'dur. inode, dosya ve dizin sayısını sayar; boyutu değil. 10 GB disk alanın boş olabilir ama 200 bin küçük dosya oluşturmuşsan inode sınırına takılırsın. En sık suçlular şunlardır: eski oturum dosyaları, temizlenmeyen önbellek klasörleri, biriken e-posta kuyruğu ve her sürümü ayrı klasörde saklayan yedekleme eklentileri.

Limite Takıldığını Nasıl Anlarsın#

Paylaşımlı pakette teşhisin ilk durağı kontrol panelidir. cPanel kullanan sağlayıcıların büyük çoğunluğunda Resource Usage (Kaynak Kullanımı) adında bir bölüm vardır ve son 24 saat ile son haftanın kota grafiklerini gösterir. Buradaki grafiklerde tepe yaptığın anları ve hangi kotayı zorladığını doğrudan görürsün; bir kaynak için "Faults" (ihlal) sayısı sıfırdan büyükse o kotaya çarpmışsın demektir.

Panelde bu bölüm yoksa ya da yeterince ayrıntı vermiyorsa, SSH erişimin varsa doğrudan bakabilirsin:

# CloudLinux tabanlı sunucuda kendi hesabının anlık kota kullanımı
lveinfo --period=1d --by-fault=any 2>/dev/null || echo "lveinfo yok"

# Kendi süreçlerinin sayısı ve bellek kullanımı
ps -u "$(whoami)" -o pid,pcpu,rss,etime,cmd --sort=-rss | head -15

# Hesabındaki toplam dosya sayısı (inode) - dizin başına döküm
find "$HOME" -xdev -type f 2>/dev/null | wc -l
du --inodes -d 1 "$HOME" 2>/dev/null | sort -rn | head -10

Son komut inode sorunlarını teşhis etmenin en pratik yoludur; hangi dizinin yüz binlerce dosya barındırdığını saniyeler içinde gösterir. Çoğu durumda sonuç şaşırtıcıdır: yedekleme eklentisinin unutulmuş klasörü ya da yıllardır temizlenmeyen bir oturum dizini listenin başındadır.

Sunucu tarafına hiç erişimin yoksa, dışarıdan davranışsal bir test yapabilirsin. Sınırlara takılıp takılmadığını anlamanın en net yolu, tek istek performansı ile eşzamanlı istek performansını karşılaştırmaktır:

# Tek istek: temel süre
curl -s -o /dev/null -w "tek istek ttfb: %{time_starttransfer}\n" https://firmaniz.com/

# 10 eşzamanlı istek: sınıra takılıyorsan süre orantısız artar
for i in $(seq 1 10); do
  curl -s -o /dev/null -w "%{time_starttransfer}\n" https://firmaniz.com/ &
done | sort -n | tail -3
wait

Tek istek 400 milisaniyede dönüyorken 10 eşzamanlı istekte en yavaş üçü 4-5 saniyeye çıkıyorsa, eşzamanlı işlem ya da CPU kotasına çarpıyorsun demektir. Bu testi kendi siten üzerinde ve makul sayıda yap; yüzlerce eşzamanlı istekle sunucuyu zorlamak sağlayıcının kullanım şartlarına aykırı olabilir.

En Sık Karşılaşılan Hata: 508 Resource Limit Reached#

508 Resource Limit Reached hatası, paylaşımlı hostingin imza hatasıdır ve neredeyse her zaman eşzamanlı işlem sınırının aşıldığını gösterir. Yani sunucu "sen bozuksun" demiyor, "aynı anda izin verilenden fazla istek işlemeye çalıştın" diyor.

Bu hatayı üreten dört tipik senaryo var ve çözümleri tamamen farklı:

1. Gerçek trafik artışı. Kampanya, sosyal medya paylaşımı, haber bülteni gönderimi. Çözüm önbellek ya da paket yükseltmesidir.
2. Yavaş sayfa üretimi. Trafik normaldir ama her istek 3 saniye sürdüğü için istekler üst üste binmiştir. Çözüm sayfayı hızlandırmaktır; paket büyütmek pahalı bir yamadır.
3. Bot trafiği. Bir tarayıcı botu, tarama aracı ya da içerik kazıyıcı siteyi hızla geziyordur. Özellikle filtreli mağaza URL'leri sonsuz sayıda sayfa üretir ve bir bot bunu gezmeye başlarsa sunucuyu tek başına doldurur.
4. Kendi kendine istek atan kod. Zamanlanmış görevler, kendi API'sine istek atan eklentiler ya da sonsuz döngüye giren bir yönlendirme.

İkinci ve üçüncü senaryo, gerçekte en yaygın olanlardır ve ikisi de paket yükseltmeden çözülür. Bot trafiğini görmek için erişim günlüğüne bakman yeterlidir:

# En çok istek atan IP adresleri (son 10 bin satır)
tail -10000 ~/access-logs/firmaniz.com | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

# Hangi kullanıcı aracıları en çok geziyor
tail -10000 ~/access-logs/firmaniz.com | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -10

# En çok istenen yollar: filtre URL'leri patlıyorsa burada görünür
tail -10000 ~/access-logs/firmaniz.com | awk '{print $7}' | cut -d'?' -f1 | sort | uniq -c | sort -rn | head -10

Tek bir IP'den binlerce istek görüyorsan ve bu bir arama motoru değilse, engellemek doğru adımdır. Filtre URL'leri listenin başındaysa, o alanı taramaya kapatmak sunucu yükünü anında düşürür.

Sınırlara Takılmadan Daha Fazla Yapmak#

Paylaşımlı pakette kapasiteni artırmanın en etkili yolu daha fazla kaynak almak değil, her isteğin maliyetini düşürmektir. Kotalar istek başına maliyetle çarpılarak tavanı oluşturur; maliyeti yarıya indirirsen tavanı ikiye katlamış olursun.

Öncelik sırası şudur. Birincisi tam sayfa önbelleği: önbellekten servis edilen bir sayfa PHP çalıştırmaz, veritabanına gitmez ve giriş işlemi kotasını neredeyse hiç tüketmez. Bu tek adım çoğu sitede kaynak kullanımını onda birine indirir. Sunucun LiteSpeed ise LiteSpeed Cache doğrudan sunucu seviyesinde çalışır ve paylaşımlı ortamda kurulabilen en verimli seçenektir. Apache üzerindeysen .htaccess önbellek ve sıkıştırma ayarları tarayıcı tarafı önbelleği için iyi bir başlangıçtır.

İkincisi statik varlıkları siteden ayırmak. Her görsel, CSS ve JavaScript isteği bir bağlantı tüketir. Bunları bir CDN üzerinden servis edersen sunucuna hiç ulaşmazlar. Karşılaştırma için CDN mi daha iyi hosting mi yazısına bakabilirsin.

Üçüncüsü bot ve tarama yükünü kısmak. Arama motorlarının filtre, arama sonucu ve sayfalama URL'lerini gezmesini engelle; kötü niyetli tarayıcıları ise doğrudan blokla. Cloudflare kullanıyorsan saldırı anlarında Under Attack modu trafiği hızlıca süzer.

Dördüncüsü zamanlanmış görevleri seyrekleştirmek. Bazı uygulamalar planlanmış işleri her ziyaretçi isteğiyle tetikler; yoğun saatte bu, her sayfa yüklemesine ek yük bindirir. Bunu gerçek bir sunucu zamanlayıcısına taşıyıp beş dakikada bir çalıştırmak, hem yükü düzleştirir hem de öngörülebilir yapar.

Beşincisi veritabanı bakımı. Şişmiş tablolar, eksik indeksler ve biriken geçici veriler her sorgunun maliyetini artırır; paylaşımlı ortamda bu maliyet doğrudan CPU kotandan düşer.

Ne Zaman Paylaşımlı Paket Yetmez#

Optimizasyonun bir tavanı vardır ve bazı site profilleri paylaşımlı modele yapısal olarak uymaz. Şu üç işaretten ikisi varsa paket değiştirme zamanı gelmiş demektir.

Birinci işaret, önbelleklenemeyen trafik oranının yüksek olmasıdır. Ziyaretçilerinin çoğu oturum açmışsa, sepetliyse ya da kişiye özel içerik görüyorsa her istek gerçekten PHP çalıştırır. Bu durumda önbellek seni kurtaramaz ve giriş işlemi kotası gerçek bir tavan olur. Mağaza ve üyelik siteleri tipik olarak bu kategoridedir; sepet ve ödeme adımlarının neden önbelleklenemediğini sepet ve ödeme sayfasını hızlandırma yazısında anlattım.

İkinci işaret, sürekli çalışan bir arka plan işine ihtiyaç duymandır. Kuyruk işçisi, WebSocket sunucusu, dizin oluşturma servisi, özel bir daemon — paylaşımlı ortam bunlara yer vermez, çünkü süreç sayısı kotası ve barındırma modeli buna uygun değildir.

Üçüncü işaret, kök erişimi gerektiren bir ihtiyacın olmasıdır: özel bir PHP eklentisi, farklı bir veritabanı motoru, özel bir web sunucusu yapılandırması ya da sistem seviyesinde bir servis.

Karar verirken paket türlerinin hızı nasıl etkilediğini bütünüyle görmek istersen hosting seçimi site hızını nasıl etkiler yazısı tabloyu tamamlıyor.

Sık Yapılan Hatalar#

"Sınırsız" ifadesini kaynak sınırsızlığı sanmak. Paket sayfalarındaki "sınırsız trafik" ifadesi bant genişliğiyle ilgilidir; CPU, bellek ve eşzamanlı işlem kotaları her zaman vardır ve asıl tavanı onlar belirler. Satın almadan önce bu üç değeri sor.

508 hatasını gördüğünde doğrudan paket yükseltmek. Hatanın en yaygın iki sebebi yavaş sayfa üretimi ve bot trafiğidir; ikisi de paket büyütmeden çözülür ve büyütmek bunları yalnızca erteler.

inode sorununu disk alanı sorunuyla karıştırmak. Panelde 8 GB boş alan görünüyorken "disk dolu" hatası alıyorsan sorun dosya sayısıdır. Önce eski önbellek ve yedek klasörlerini temizle.

Yedekleme eklentilerini denetimsiz bırakmak. Site içine yedek alan eklentiler hem inode hem disk hem de yedekleme anında CPU tüketir; üstelik sunucu çökerse yedek de onunla gider. Yedekleri dış bir konuma al.

Kaynak grafiklerine hiç bakmamak. cPanel'in Resource Usage bölümü sana sorunun tam saatini ve hangi kotanın aşıldığını söyler. Aylık bir kez bakmak, sorunu ortaya çıkmadan görmeni sağlar.

Bot trafiğini gerçek ziyaretçi sanmak. Analitik aracın botları saymaz ama sunucu kotan onları sayar. "Trafiğim az ama kaynağım doluyor" diyorsan cevap erişim günlüğündedir.

Sıkça Sorulan Sorular#

508 Resource Limit Reached hatası neden alınır#

Bu hata neredeyse her zaman eşzamanlı işlem (entry process) sınırının aşıldığını gösterir; yani aynı anda paketinin izin verdiğinden fazla PHP isteği işlenmeye çalışılmıştır. Sebebi gerçek bir trafik artışı olabileceği gibi, çok daha sık olarak yavaş sayfa üretimi ya da bot trafiğidir. Önce erişim günlüğüne bakıp trafiğin gerçek olup olmadığını doğrula, sonra sayfa üretim süreni ölç.

Paylaşımlı hostingde CPU limitim ne kadar#

Sağlayıcıya ve pakete göre değişir; tipik olarak bir ya da birkaç çekirdek eşdeğeri şeklinde ifade edilir ve panelde Resource Usage bölümünden görülebilir. Önemli olan rakamın kendisi değil, ihlal (fault) sayınızın sıfır olup olmadığıdır. Grafiklerde tepe noktalarında kotaya değiyorsan, kullanım düzenli olarak sınırın altında kalsa bile o anlarda siten yavaşlıyor demektir.

inode limiti nedir ve nasıl temizlenir#

inode, hesabındaki dosya ve dizinlerin sayısını ölçer; boyutunu değil. Sınıra takıldığında disk alanın boş olsa bile yeni dosya oluşturulamaz. Temizlemek için önce hangi dizinin şiştiğini bul (du --inodes -d 1 ~ komutu bunu gösterir), sonra eski oturum dosyalarını, temizlenmeyen önbellek klasörlerini ve site içinde biriken yedek arşivlerini sil. Yedekleri sunucu dışında saklamak bu sorunu kalıcı olarak çözer.

Kaynak limitine takıldığımı sağlayıcıya sormadan anlayabilir miyim#

Evet. cPanel'in Resource Usage bölümü son 24 saatlik ve haftalık kota grafiklerini gösterir, ihlal sayısını ayrıca listeler. Panel erişimi yoksa dışarıdan davranışsal bir test de işe yarar: tek istek hızlı dönerken 10 eşzamanlı istekte sürelerin orantısız biçimde uzaması, eşzamanlı işlem ya da CPU kotasına çarptığının güçlü bir işaretidir.

Paket yükseltmek sorunumu çözer mi#

Sorunun kaynağına bağlı. Gerçek ve sürekli bir trafik artışı yaşıyorsan evet. Ama yavaş sayfa üretimi, bot trafiği ya da kötü yazılmış bir eklenti yüzünden kotaya çarpıyorsan yükseltme yalnızca zaman kazandırır; birkaç ay sonra aynı duvara daha pahalı bir pakette çarparsın. Önce sayfa üretim süreni ve erişim günlüğünü kontrol et.

Önbellek kurmak kaynak kullanımımı gerçekten düşürür mü#

Belirgin biçimde düşürür ve bu, paylaşımlı pakette yapabileceğin en etkili tek iyileştirmedir. Önbellekten servis edilen bir sayfa PHP çalıştırmaz, veritabanına gitmez ve giriş işlemi kotasını neredeyse hiç tüketir. Anonim ziyaretçi oranı yüksek bir sitede bu, kaynak kullanımını onda birine indirebilir; kişiye özel içerik oranı yüksek sitelerde kazanç daha sınırlı kalır.

Kapanış#

Paylaşımlı hostingde sınırlarla yaşamanın dört alışkanlığı var. Birincisi, kaynak grafiklerine düzenli bak; sorun ortaya çıkmadan önce grafiklerde görünür. İkincisi, bir limite takıldığında refleks olarak paket yükseltme — önce sayfa üretim süreni ölç ve erişim günlüğünde bot trafiği ara. Üçüncüsü, tam sayfa önbelleğini kur; kotaların tavanını en ucuza yükselten şey budur. Dördüncüsü, inode ve disk kullanımını yılda birkaç kez temizle, yedeklerini site dışında sakla.

Sınırlar sana dar gelmeye başladıysa Clou.TR tarafında geçiş yolun hazır. Önbellekli ve orta ölçekli siteler için NVMe diskli web hosting ve WordPress hosting paketleri; sepetli, önbelleklenemez trafiği yoğun mağazalar için e-ticaret hosting; kaynakların tamamen sana ayrıldığı ve kök erişimi istediğin projeler için VDS sunucu ile esnek bulut sunucu seçenekleri var. Geçişi kesintisiz yapmak istersen site taşıma hizmetimiz devreye girer.