Paylaşımlı Hostingde Kaynak Limitleri: CPU, RAM ve IO

Paylaşımlı hostingde kaynak limitleri; bir hesabın kullanabileceği işlemci yüzdesi, bellek miktarı, disk okuma/yazma hızı ve eş zamanlı süreç sayısı için tanımlanmış üst sınırlardır. Aynı fiziksel sunucuyu paylaşan tüm hesapların adil ve öngörülebilir performans alması için uygulanır. Limit aşıldığında yalnızca ilgili hesap yavaşlatılır; diğer siteler etkilenmez.

Bu tanımı okuyup “yani beni kısıtlıyorlar” diye düşünmek çok kolay. Oysa tersi doğrudur: sizi kısıtlayan şey, aynı zamanda sizi komşunuzdan koruyan şeydir. Bu yazıda limitlerin tam olarak neyi ölçtüğünü, nasıl takip edildiğini, aşıldığında ne olduğunu ve kaynak tüketimini nasıl düşüreceğinizi teknik ayrıntısıyla anlatıyoruz.

Limitler Neden Var? Dürüst Cevap

Paylaşımlı hosting, bir fiziksel sunucunun işlemci, bellek ve disk kaynaklarının çok sayıda hesap arasında paylaşılması esasına dayanır. Bu model, barındırmayı ekonomik hâle getiren şeydir; küçük bir kurumsal siteye tek başına bir sunucu ayırmak hem gereksiz hem de anlamsız derecede pahalı olurdu.

Ancak paylaşım, doğası gereği bir risk taşır: komşu etkisi. Limit tanımlanmamış bir sunucuda, sonsuz döngüye giren tek bir betik ya da hatalı bir zamanlanmış görev, işlemcinin tamamını tüketebilir. O anda aynı sunucudaki diğer bütün siteler yavaşlar, hatta yanıt veremez hâle gelir. Kendi sitenizde tek bir satır kod değiştirmemiş olmanız hiçbir şeyi değiştirmez; komşunuzun hatası sizin ziyaretçinize yansır.

Kaynak limitleri tam olarak bunu engellemek için vardır. Her hesap kendi kaynak zarfının içinde çalışır. Bir hesap zarfını doldurduğunda etki o zarfın içinde kalır: yalnızca o hesap yavaşlar. Yani limit, sizin sitenize konulmuş bir tavan olduğu kadar, komşunuzun sitesine konulmuş bir duvardır. Alastyr paylaşımlı hosting sunucularında bu izolasyon CloudLinux ve CageFS ile sağlanır: her hesabın kendi sanallaştırılmış dosya sistemi ve kendi kaynak konteyneri vardır. Bir hesap diğerinin dosyalarını göremez, kaynağını çalamaz.

Bu yüzden “limitsiz” vaadi teknik olarak bir vaat değil, bir belirsizliktir. Sınırın nerede olduğunu bilmemek, sınırın olmadığı anlamına gelmez. Bizim tercihimiz limitleri gizlemek değil, şeffaf biçimde yazmak ve panelden anlık olarak göstermektir.

Limit Türleri: Ne Ölçer, Aşılınca Ne Olur?

Paylaşımlı hesaplarda karşınıza çıkan limitler tek bir sayı değildir; birbirinden bağımsız yedi ayrı sayaç çalışır. Hangi sayacın dolduğunu bilmek, sorunu çözmenin yarısıdır.

Limit	Ne ölçer?	Aşılınca ne olur?	Tipik belirti
CPU (%)	Hesabın kullanabileceği işlemci gücü. %100, tam bir çekirdeğe karşılık gelir; paketler genelde birkaç yüz yüzde tanımlar.	İstekler kuyruğa alınır, işlem süresi uzar. Sunucu durdurmaz, yavaşlatır (throttling).	Sayfa yükleme süresi aniden 2-3 katına çıkar; yönetim paneli ağırlaşır.
Fiziksel bellek (RAM)	Hesabın süreçlerinin aynı anda tutabileceği toplam bellek.	Bellek isteyen süreç anında sonlandırılır. Yavaşlama değil, kesme yaşanır.	500 Internal Server Error; “Allowed memory size exhausted” hataları; içe aktarma işlemi yarıda kesilir.
IO hızı (KB/s)	Diske saniyede yazılan/okunan veri miktarı.	Disk erişimi yavaşlatılır; sayfa üretimi diski beklerken uzar.	Site yavaş ama işlemci boşta görünüyor; yedekleme ve dosya yükleme çok uzun sürüyor.
IOPS	Saniyedeki disk işlem sayısı (boyuttan bağımsız, okuma/yazma adedi).	Küçük ve çok sayıda dosya erişimi kuyruklanır.	Çok sayıda küçük dosya kullanan siteler (büyük eklenti setleri, çok dosyalı önbellek) beklenmedik biçimde yavaşlar.
Entry Processes (EP)	Aynı anda işlenmekte olan istek sayısı. Eş zamanlı ziyaretçi değil, eş zamanlı PHP çalıştırması demektir.	Yeni istekler reddedilir; ziyaretçi hata sayfası görür.	508 Resource Limit Is Reached hatası; trafiğin en yoğun olduğu anda site yanıt vermiyor.
Number of Processes (NPROC)	Hesaba ait toplam süreç sayısı (PHP, cron, kabuk komutları dâhil).	Yeni süreç başlatılamaz.	Zamanlanmış görevler çalışmıyor; “fork: retry: Resource temporarily unavailable” mesajı.
inode	Hesaptaki toplam dosya ve klasör adedi (boyut değil, adet).	Yeni dosya yazılamaz. Disk boş görünse bile yazma başarısız olur.	E-posta gelmiyor, önbellek oluşmuyor, yükleme başarısız; “disk dolu” görünmüyor ama yazılamıyor.

Bu tabloda gözden kaçan en kritik ayrım Entry Processes ile eş zamanlı ziyaretçi arasındaki farktır. 20 EP limiti “aynı anda 20 ziyaretçi” demek değildir. Bir PHP sayfası 200 milisaniyede üretiliyorsa, tek bir EP saniyede yaklaşık beş isteği karşılar. Önbellekten dönen sayfalar ise PHP’yi hiç çalıştırmadığı için EP sayacına neredeyse hiç dokunmaz. Bu yüzden önbellek, EP sorununun en doğrudan çözümüdür.

Kaynak Kullanımı Nasıl Ölçülür ve Takip Edilir?

Limitleri yönetmenin ön koşulu, onları görebilmektir. Alastyr paylaşımlı hosting hesaplarında cPanel içindeki kaynak kullanımı ekranı, hesabınızın CPU, bellek, IO, IOPS ve giriş süreçleri değerlerini anlık ve geçmişe dönük olarak grafiklerle gösterir. Ayrıca son 24 saat ve son 30 gün içinde hangi limite kaç kez takıldığınız listelenir.

Bu ekranı doğru okumanın üç kuralı vardır:

• Anlık tepe değil, süreye bakın. Kaynak kullanımının kısa süreliğine tavana vurması normaldir. Sorun, tavanda kalınan süredir.
• Hangi sayacın dolduğunu tespit edin. “Site yavaş” bilgisi çözüm üretmez; “IO limiti günde 40 kez doluyor” bilgisi üretir.
• Zamanla eşleştirin. Limit aşımları her gece 03.00’te oluyorsa sebep ziyaretçi değil, yedekleme ya da zamanlanmış görevdir.

Ne yaptığınızdan emin değilseniz bu tabloyu yorumlamak için tek başınıza kalmazsınız: 7/24 destek ekibimiz kaynak kullanımı kayıtlarınızı inceleyip hangi süreçlerin tükettiğini raporlar. Limit aşımı bir “ceza” değil, bir teşhis verisidir.

Limit Aşımının Sebepleri ve Çözümleri

Paylaşımlı hesapların büyük çoğunluğunda kaynak tüketiminin sebebi trafik değil, verimsizliktir. Aynı ziyaretçi sayısı, optimize edilmiş bir sitede beşte bir kaynakla karşılanabilir.

Sebep	Hangi limiti doldurur?	Çözüm
Önbelleksiz WordPress: her istek veritabanına gidiyor	CPU, EP	Sunucu seviyesinde önbellek (LiteSpeed + LSCache) devreye alın; sayfalar PHP çalıştırmadan sunulsun.
Ağır veya çakışan eklentiler (özellikle sayfa oluşturucular, istatistik eklentileri)	CPU, RAM	Kullanılmayan eklentileri silin; aynı işi yapan iki eklentiyi tekilleştirin.
Şişmiş veritabanı: wp_options autoload alanı, geçici kayıtlar, revizyonlar	CPU, IO	Revizyon ve geçici kayıtları temizleyin; autoload verisini küçültün; tabloları onarın.
Optimize edilmemiş görseller ve statik dosyalar	IO, IOPS	Görselleri WebP’ye çevirin, boyutlandırın; tarayıcı önbelleği ve sıkıştırma açın.
Bot ve tarayıcı trafiği; agresif içerik kazıma	EP, CPU	Zararlı botları engelleyin, tarama hızını sınırlayın, arama/filtre URL’lerini kapatın.
Yönetim paneli zamanlayıcısının her istekte çalışması	CPU, EP	Dâhilî zamanlayıcıyı kapatıp gerçek zamanlanmış göreve bağlayın.
Eski PHP sürümü	CPU, RAM	Desteklenen güncel PHP sürümüne geçin; performans farkı kayda değerdir.
Yedekleme eklentisinin site içinden tam yedek alması	IO, IOPS, inode	Yedeklemeyi sunucu tarafındaki yedekleme sistemine bırakın; eklenti yedeğini seyrekleştirin.
Sunucuda biriken e-posta ve önbellek dosyaları	inode	Eski önbellek/oturum dosyalarını ve gereksiz posta kutularını temizleyin.
Gerçekten büyümüş trafik ve iş yükü	Hepsi	Bu bir hata değil, bir başarıdır. Kaynak sınıfını yükseltmenin zamanıdır.

Kaynak Kullanımını Düşürme Adımları

Aşağıdaki sıra rastgele değildir: en çok kazancı en az riskle veren adım en başta durur. Her adımdan sonra panelden kaynak grafiğine bakıp değişimi ölçün.

1. Önbelleği devreye alın. Kaynak tüketimini düşürmenin tek ve en büyük kaldıracı budur. Sunucu seviyesinde çalışan LiteSpeed ve LSCache, üretilen sayfayı saklayıp bir sonraki ziyaretçiye PHP ve veritabanı hiç çalışmadan sunar. Aynı trafikte CPU ve giriş süreci tüketimi tipik olarak kat kat düşer. WordPress hosting paketlerinde bu katman hazır gelir.
2. Eklenti ve tema envanteri çıkarın. Devre dışı eklentileri silin (pasif eklenti bile inode ve güncelleme yükü demektir). Aynı işi yapan eklentileri tekilleştirin. Site içi arama, ziyaretçi sayacı, ilgili yazılar ve anlık sohbet eklentileri en çok kaynak tüketen sınıflardır; gerçekten gerekli olup olmadıklarını sorgulayın.
3. Veritabanını optimize edin. Yazı revizyonlarını sınırlandırın, süresi dolmuş geçici kayıtları temizleyin, çöp kutusunu boşaltın. Her istekte belleğe yüklenen otomatik yüklenen ayar verisi (autoload) 1 MB’ı geçiyorsa, hangi eklentinin şişirdiğini bulup temizleyin. Tabloları onarıp optimize edin.
4. Görselleri ve statik dosyaları hafifletin. 4000 piksel genişliğinde bir fotoğrafı 800 piksellik alanda göstermek, her ziyaretçide gereksiz disk okuması ve bant genişliği demektir. Görselleri kullanılacak boyuta indirin, WebP’ye çevirin, geç yükleme (lazy load) açın. Tarayıcı önbelleği başlıklarını ve sıkıştırmayı etkinleştirin.
5. Bot trafiğini sınırlayın. Sunucu kayıtlarında ziyaretçilerinizin değil, tarayıcı botlarının ilk sırada olduğunu görmek şaşırtıcı biçimde yaygındır. Zararlı ve gereksiz botları engelleyin, arama sonucu ve filtre kombinasyonu üreten URL’leri taramaya kapatın, giriş sayfasına hız sınırı koyun. Bu adım genelde giriş süreçleri (EP) sorununu tek başına çözer.
6. PHP sürümünü güncelleyin. Güncel PHP sürümleri aynı işi belirgin biçimde daha az işlemci ve bellekle yapar. Uyumluluğu bir test kopyasında doğruladıktan sonra en güncel desteklenen sürüme geçin ve OPcache’in açık olduğundan emin olun.
7. Hâlâ yetmiyorsa yükseltin. Yukarıdaki altı adımı uyguladıktan sonra limitler hâlâ doluyorsa sorun optimizasyon değil, kapasitedir. Bu noktada daha yüksek kaynaklı bir pakete ya da bulut sunucuya geçmek doğru karardır; kaynak eklemek artık israf değil, ihtiyaçtır.

Ne Zaman Yükseltmeli?

Yükseltme kararı duyguyla değil, veriyle verilir. Aşağıdaki tablonun herhangi bir satırı sizde geçerliyse paylaşımlı hostingin tavanına dayanmışsınız demektir.

Sinyal	Anlamı	Doğru basamak
Optimizasyondan sonra bile limitler her gün doluyor	Kapasite gerçekten yetmiyor	Üst paket ya da bulut sunucu
Trafik yoğun saatlerde 508 hatası tekrarlıyor	Eş zamanlılık ihtiyacı paylaşımlı zarfı aşmış	Ayrılmış kaynak: VDS veya bulut sunucu
Kök yetkisi, özel modül veya özel sürüm gerekiyor	Paylaşımlı ortam mimari olarak yetersiz	VDS veya bulut sunucu
Yoğun ve sürekli veritabanı yazma yükü var	IO ve IOPS yapısal darboğaz	Bulut sunucu
Kesinti maliyeti yüksek, taahhütlü çalışma süresi isteniyor	Öngörülebilirlik iş kritiği	Uptime taahhütlü üst basamaklar

Bu noktada en sık sorulan soru şudur: “Yükseltirsem sitem kapanır mı?” Hayır. Büyüyen altyapı yaklaşımımızda paylaşımlı hostingden buluta geçiş aynı çatı altında, ekibimiz tarafından ve kesintisiz yapılır. Sitenizi taşımak, yeniden kurmak ya da başka bir sağlayıcıyla uğraşmak zorunda kalmazsınız; yalnızca zarfınız büyür.

Alastyr Paylaşımlı Hostingde Limitler Nasıl Çalışır?

Dört noktada özetlenebilir. Birincisi izolasyon: CloudLinux ve CageFS sayesinde her hesap kendi kaynak konteynerinde ve kendi sanallaştırılmış dosya sisteminde çalışır; komşu etkisi mimari olarak ortadan kalkar. İkincisi şeffaflık: hangi limite ne kadar yaklaştığınızı cPanel’deki kaynak kullanımı ekranından anlık olarak görürsünüz; sürpriz yoktur. Üçüncüsü verimlilik: LiteSpeed web sunucusu ve LSCache, aynı trafiği belirgin biçimde daha az işlemci ve bellekle karşılar; yani limitler pratikte çok daha geç dolar. Dördüncüsü destek: limitleri zorluyorsanız 7/24 destek ekibi sebebi analiz eder, optimizasyon önerir ve gerekiyorsa doğru paketi birlikte belirleriz.

Limitleri saklamak yerine açıkça yazmayı, ölçülebilir kılmayı ve gerektiğinde birlikte çözmeyi tercih ediyoruz. Çünkü paylaşımlı hostingde asıl değer, sınırsızlık iddiası değil; sınırların öngörülebilir olmasıdır.

Sıkça Sorulan Sorular

Paylaşımlı hostingde kaynak limitleri neden var?

Aynı fiziksel sunucuyu paylaşan tüm hesapların adil ve öngörülebilir performans alması için. Limit olmasaydı, sonsuz döngüye giren tek bir betik ya da hatalı bir zamanlanmış görev sunucunun tüm işlemcisini tüketebilir ve diğer bütün siteleri birlikte yavaşlatabilirdi. Limit, sizin sitenize konulmuş bir tavan olduğu kadar komşunuzun sitesine konulmuş bir duvardır.

Limiti aştığımda sitem kapatılır mı?

Hayır, hesabınız kapatılmaz. Limit türüne göre farklı davranış olur: CPU ve IO limitlerinde istekleriniz yavaşlatılır (throttling), bellek limitinde ilgili süreç sonlandırılır, giriş süreci limitinde yeni istekler geçici olarak reddedilir ve ziyaretçi 508 hatası görür. Yük normale döndüğünde site kendiliğinden eski hâline döner.

508 Resource Limit Is Reached hatası tam olarak ne demek?

Hesabınızın aynı anda işleyebileceği istek sayısı (Entry Processes) limitinin dolduğu anlamına gelir. Genellikle önbelleğin olmaması, ağır sorgular ya da bot trafiği yüzünden her isteğin PHP çalıştırmasıyla oluşur. Sunucu seviyesinde önbellek devreye alındığında bu hata çoğu sitede tamamen ortadan kalkar.

Entry Processes limiti eş zamanlı ziyaretçi sayısı mıdır?

Hayır. Entry Processes, aynı anda işlenmekte olan istek sayısıdır. Bir sayfa 200 milisaniyede üretiliyorsa tek bir giriş süreci saniyede yaklaşık beş isteği karşılar. Önbellekten dönen sayfalar PHP çalıştırmadığı için bu sayaca neredeyse hiç dokunmaz; bu yüzden önbellekli bir sitede aynı limit çok daha fazla ziyaretçiye yeter.

inode limiti nedir, disk alanımdan farkı ne?

inode, hesabınızdaki dosya ve klasörlerin toplam adedidir; disk alanı ise toplam boyuttur. 100 MB’lık tek bir dosya 1 inode, 1 KB’lık yüz bin dosya ise 100.000 inode tüketir. inode limiti dolduğunda disk alanınız boş görünse bile yeni dosya yazılamaz; e-posta gelmez ve önbellek oluşmaz. En sık sebepler biriken önbellek/oturum dosyaları ve temizlenmemiş posta kutularıdır.

Kaynak kullanımımı nasıl takip ederim?

cPanel içindeki kaynak kullanımı ekranından. Burada CPU, fiziksel bellek, IO, IOPS ve giriş süreçleri değerlerinizi anlık ve geçmişe dönük grafiklerle görebilir, son 24 saat ve son 30 gün içinde hangi limite kaç kez takıldığınızı inceleyebilirsiniz. Yorumlamakta zorlanırsanız 7/24 destek ekibimiz kayıtları sizin için analiz eder.

Kaynak tüketimini düşürmenin en etkili tek adımı hangisi?

Sunucu seviyesinde önbellek. LiteSpeed ve LSCache, üretilmiş sayfayı saklayıp sonraki ziyaretçiye PHP ve veritabanı hiç çalışmadan sunar. Aynı trafikte işlemci ve giriş süreci tüketimi kat kat düşer. Önbellek devredeyken ikinci en etkili adımlar, kullanılmayan eklentileri silmek ve bot trafiğini sınırlamaktır.

Limitleri artırabilir miyim?

Bir dereceye kadar evet: daha yüksek kaynak sınıfına sahip bir paket, daha geniş bir kaynak zarfı verir. Ancak paylaşımlı modelin doğası gereği bir tavan her zaman vardır. Optimizasyona rağmen limitler her gün doluyorsa doğru çözüm limit yükseltmek değil, ayrılmış kaynaklı bir basamağa geçmektir.

Bulut sunucuya geçersem sitem kesintiye uğrar mı?

Hayır. Büyüyen altyapı yaklaşımımızda paylaşımlı hostingden VDS veya bulut sunucuya geçiş aynı çatı altında, teknik ekibimiz tarafından ve kesintisiz yürütülür. Sitenizi yeniden kurmanız ya da başka bir sağlayıcıyla uğraşmanız gerekmez.