Hosting Kaynak Limitleri Nedir? CPU, RAM, IO Aşılınca Ne Olur?

Hosting kaynak limitleri nedir ve neden vardır?

Hosting kaynak limitleri, paylaşımlı bir sunucuda her hesaba ayrılan işlemci, bellek, disk hızı, eşzamanlı işlem ve dosya sayısı gibi kaynakların üst sınırıdır. Sağlayıcı bu sınırları, tek bir sitenin yoğun yükü yüzünden aynı sunucudaki diğer siteler yavaşlamasın diye koyar; sınır aşılınca siteniz yavaşlar ya da hata verir.

Biz Talha Aslan ve ekibi olarak dijital pazarlama ve web tarafında çalışıyoruz; hosting firması değiliz. Bu yüzden bu rehberde teknik tanımları CloudLinux ve cPanel'in resmi belgelerine dayandırıyoruz. Amacımız, paylaşımlı hostingte site işleten birinin panelde gördüğü rakamları okuyabilmesi ve sorunu doğru kişiye doğru soruyla taşıyabilmesi.

Kısacası bu yazı size üç şey kazandırmayı hedefliyor. İlk olarak her limitin neyi ölçtüğünü anlayacaksınız. Ardından limit dolduğunda sitenizin nasıl davrandığını tanıyacaksınız. Son olarak da hangi adımı kendiniz atabileceğinizi, hangisini sağlayıcıya bırakmanız gerektiğini ayırt edeceksiniz.

Paylaşımlı hostingte limitleri kim ve nasıl uygular?

Paylaşımlı hostingte yüzlerce hesap aynı fiziksel ya da sanal sunucuyu paylaşır. Bu yüzden sağlayıcının, bir hesabın tüm işlemciyi ya da belleği tek başına tüketmesini engelleyen bir mekanizmaya ihtiyacı vardır. cPanel kullanan pek çok sunucuda bu iş için CloudLinux işletim sistemi ve onun LVE (Lightweight Virtual Environment) teknolojisi çalışır.

LVE, her hesabı kendi sınırları olan küçük bir kap gibi ele alır. Örneğin bir hesabın PHP süreçleri belirlenen işlemci payını aşamaz; bellek sınırına gelince sistem fazlasına izin vermez. Hesapların dosya sistemi düzeyinde birbirinden ayrılmasını sağlayan CageFS ise ayrı bir konudur; onu CageFS nedir yazımızda anlattık, burada tekrar etmiyoruz.

Ancak her sağlayıcı CloudLinux kullanmaz. Bazı firmalar farklı panel ya da farklı sınırlama araçları tercih eder. Dolayısıyla hosting kaynak limitleri sizin panelinizde birebir aynı adla görünmeyebilir. Yine de mantık aynıdır: işlemci, bellek, disk erişimi, eşzamanlı işlem ve dosya sayısı her yerde ölçülen temel kalemlerdir.

CPU limiti (SPEED) neyi ölçer?

CPU limiti, hesabınızın kullanabileceği işlemci gücünün üst sınırıdır. CloudLinux belgesi bu limiti SPEED adıyla anlatır ve değeri bir çekirdeğin yüzdesi olarak tanımlar. Yani yüzde yüz, tek bir işlemci çekirdeğinin tamamına karşılık gelir; daha yüksek değerler birden fazla çekirdek anlamına gelir.

Bu limit dolduğunda sistem süreçlerinizi sonlandırmaz. Belgeye göre site işlemci ya da disk erişimi nedeniyle sınırlanınca daha yavaş yanıt vermeye başlar. Dolayısıyla CPU limitinin tipik belirtisi hata sayfası değil, sayfaların geç açılmasıdır.

Peki işlemciyi en çok ne tüketir? Önbelleksiz çalışan bir WordPress sitesinde her ziyaret PHP kodunu baştan çalıştırır ve veritabanına sorgu gönderir. Ağır bir sayfa oluşturucu, çok sayıda eklenti ya da verimsiz bir arama sorgusu bu yükü katlar. Üstelik bu yük ziyaretçi sayısıyla doğrusal artar; aynı anda gelen yüz istek, yüz ayrı PHP çalışması demektir.

Bu nedenle CPU sınırına sık dayanan bir sitede ilk bakmanız gereken yer önbellektir. PHP kodunu bellekte tutan önbellek için OPcache rehberimize göz atabilirsiniz.

RAM limiti (PMEM) aşılınca ne olur?

RAM limiti, hesabınızın süreçlerinin aynı anda kullanabileceği fiziksel bellek miktarıdır. CloudLinux bu sınırı PMEM olarak adlandırır ve belgeye göre bu değere paylaşılan bellek ile disk önbelleği de dahildir.

Bellek sınırının davranışı CPU limitinden farklıdır. Hesap PMEM sınırına ulaşınca sistem o hesaptaki bazı süreçleri sonlandırır ve hata sayacını artırır. CloudLinux belgesi bunun genellikle web sunucusunun 500 ve 503 hataları vermesine yol açtığını belirtir. Yani bellek sorunu yavaşlıktan çok, ara ara gelen hata sayfalarıyla kendini gösterir.

Belleği en çok yoran işler genellikle büyük dosya işlemleridir. Örneğin yüksek çözünürlüklü görselleri sunucuda yeniden boyutlandıran bir eklenti, binlerce satırlık bir ürün içe aktarımı ya da yedek arşivi oluşturan bir betik kısa sürede belleği doldurabilir. Ayrıca PHP'nin kendi bellek sınırı (memory_limit) ile hesabın PMEM sınırı aynı şey değildir; biri tek bir PHP sürecini, diğeri hesabın tamamını sınırlar.

Bu yüzden memory_limit değerini yükseltmek, PMEM sınırına takılan bir siteyi kurtarmaz; hatta aynı anda çalışan süreç sayısı fazlaysa sorunu büyütebilir.

IO ve IOPS limitleri siteyi nasıl yavaşlatır?

IO limiti, hesabınızın saniyede diske ne kadar veri yazıp okuyabileceğini sınırlar. CloudLinux belgesi bu değeri okuma ve yazmanın toplamı olarak tanımlar. IOPS ise veri miktarına değil, saniyedeki okuma ve yazma işlemi sayısına bakar.

İki sınır da dolunca sonuç benzerdir: sistem süreçleri bekletir. Belgeye göre sistem IO limitine ulaşan süreçleri kısar, yani uyutur; onları durdurmaz ama yavaşlatır. Dolayısıyla IO sorunu da CPU gibi önce yavaşlık olarak kendini gösterir.

Disk erişimini en çok zorlayan işler şunlardır:

• Yedekleme: Tüm dosyaları ve veritabanını okuyup tek bir arşiv dosyasına yazmak çok yoğun disk işi gerektirir.
• Dosya tabanlı önbellek temizliği: Binlerce küçük önbellek dosyasını aynı anda silmek ya da yeniden oluşturmak IOPS sınırına hızla dayanır.
• Günlük dosyaları: Hata ayıklama modu açık kalmış bir site her istekte diske satır yazar.
• Büyük içe aktarımlar: Ürün ya da medya aktarımı hem okuma hem yazma tarafını aynı anda zorlar.

Çok sayıda küçük dosyayla çalışan siteler IOPS sınırına, büyük dosyalarla çalışan siteler ise IO sınırına daha önce ulaşır.

Entry processes (EP) nedir, 508 hatası neden çıkar?

Entry processes, kısaca EP, hesabınıza aynı anda giren süreçlerin sayısıdır. CloudLinux belgesi bu limiti genellikle Apache'deki dinamik betiklere yapılan eşzamanlı bağlantı sayısı olarak açıklar; belgeye göre aynı anda çalışan SSH oturumları ve cron işleri de bu sayıya girer.

Burada önemli bir ayrım var. EP, sitenizi o an ziyaret eden kişi sayısı değildir. Statik bir görsel ya da CSS dosyası genellikle PHP çalıştırmaz. Bir PHP isteği ise saniyenin küçük bir kısmında bittiği sürece yer tutmaz. EP sınırı, yavaş biten istekler üst üste bindiğinde dolar.

Sınır dolunca ne olur? Belgeye göre web sunucusu yeni isteği hesabın LVE'sine yerleştiremez ve 508 kodunu döndürür. Ziyaretçi bu durumda genellikle "Resource Limit Is Reached" başlıklı bir sayfa görür. CloudLinux'un varsayılan tablosunda EP değeri 20'dir; ancak sağlayıcılar kendi paketlerine göre farklı değer belirler.

Örnek olarak, bir sayfanın oluşması normalde yarım saniye sürüyorsa EP sınırı nadiren dolar. Aynı sayfa yavaş bir dış servis ya da kilitlenen bir sorgu yüzünden on saniye sürüyorsa, birkaç ziyaretçi bile sınırı doldurabilir. Bu nedenle 508 hatası çoğu zaman yoğun trafikten çok yavaş koddan doğar.

NPROC yani toplam işlem limiti neyi sınırlar?

NPROC, hesabınız içinde aynı anda var olabilecek toplam süreç sayısıdır. EP yalnızca hesaba giren süreçleri sayarken NPROC, bu süreçlerin başlattığı alt süreçler dahil her şeyi sayar.

Fark şöyle düşünülebilir: bir PHP isteği tek bir giriş sürecidir; ancak o istek arka planda bir görsel işleme komutu ya da bir e-posta gönderim süreci başlatırsa NPROC sayısı artar. Benzer biçimde cron ile başlayan bir yedekleme betiği de birden fazla alt süreç açabilir.

CloudLinux belgesine göre NPROC sınırı dolduğunda Apache 500 ya da 503 hatası döndürebilir. Yani belirti, bellek sınırına benzer biçimde hata sayfasıdır. Bu yüzden ara ara gelen 500 ve 503 hatalarında yalnızca belleğe değil, süreç sayısına da bakmanız gerekir. 503 hatasının genel nedenleri ve çözüm sırası için 503 Service Unavailable rehberimize göz atabilirsiniz.

Öte yandan NPROC sorunları genellikle tek bir kötü yapılandırmadan doğar. Üst üste binen cron işleri, takılıp kalan arka plan betikleri ya da kapanmayan SSH oturumları bunun tipik örnekleridir.

Inode limiti dolunca ne olur?

Inode, sunucudaki her dosya ve klasör için tutulan kayıttır. cPanel belgesi, panelin istatistik bölümündeki File Usage satırını hesabınızın kullandığı dosya ve dizin sayısı, yani inode sayısı olarak tanımlar. Dolayısıyla inode limiti, dosyaların boyutunu değil adedini sınırlar.

Disk alanınız boş görünse bile inode sınırı dolabilir. Örneğin her ziyarette yeni bir dosya üreten oturum klasörleri, temizlenmeyen önbellek dizinleri, binlerce küçük küçük resim, eski e-postalarla dolu posta kutuları ve eski yedek klasörleri bu sayıyı hızla yükseltir.

CloudLinux belgesi inode için yumuşak ve sert olmak üzere iki sınırdan söz eder. Yumuşak sınır bir süre aşılabilir ve uyarı niteliğindedir. Sert sınıra ulaşınca ise kullanıcı diske yeni veri yazamaz. Bu durumda eklenti güncellemesi yarıda kalabilir, yüklediğiniz görsel kaybolur, posta kutusu yeni ileti kabul etmez ve önbellek dosyası oluşamaz.

Kısacası inode sorunu ani ve garip hatalar üretir: site açık görünür ama form gitmez ya da güncelleme tamamlanmaz.

Disk alanı ve bant genişliği limitleri nasıl işler?

Disk alanı, hesabınızdaki dosyaların, veritabanlarının ve e-postaların toplam boyutudur. cPanel'in istatistik bölümü bunu Disk Usage satırında, veritabanı kullanımını da ayrı bir satırda gösterir. Alan dolduğunda etki inode sınırına benzer: yeni dosya yazılamaz, yedek oluşmaz, veritabanı tablosu büyüyemez.

Bant genişliği ya da trafik ise sitenizden dışarı aktarılan veri miktarıdır. cPanel belgesi Bandwidth satırını içinde bulunulan ay için aktarılan veri olarak tanımlar. Bazı paketlerde aylık kota dolunca sağlayıcı siteyi askıya alır; bazılarında ise yalnızca uyarı gelir. Bu davranış tamamen sağlayıcının politikasına bağlıdır.

Trafik kotasının mantığını ve ne kadarına ihtiyaç duyduğunuzu nasıl hesaplayacağınızı bant genişliği nedir yazımızda ayrıntılı anlattık. Burada tek bir noktayı vurgulayalım: sıkıştırmadığınız büyük görseller ve kendi sunucunuzda barındırdığınız videolar trafiği en hızlı tüketen kalemlerdir.

Ayrıca eski yedeklerin hesabın içinde birikmesi hem disk alanını hem inode sayısını aynı anda şişirir. Yedekleri hesabın dışına taşımak bu iki sınırı birden rahatlatır.

MySQL bağlantı ve sorgu limitleri neden önemlidir?

Veritabanı tarafında da sınırlar vardır ve site sahipleri bunları çoğu zaman gözden kaçırır. MySQL, hesap bazında kaynak sınırı tanımlamaya izin verir. Resmi MySQL belgesi saatlik sorgu sayısı, saatlik güncelleme sayısı, saatlik bağlantı sayısı ve eşzamanlı bağlantı sayısı için ayrı ayrı sınır koyulabileceğini anlatır.

Paylaşımlı hostingte en sık karşılaşılan sınır eşzamanlı bağlantı sayısıdır. Bu sınır dolunca siteniz veritabanına bağlanamaz ve WordPress gibi sistemler "veritabanı bağlantısı kurulamadı" türünde bir hata gösterir. Hata günlüğünde ise çoğu zaman max_user_connections ifadesi geçen bir mesaj yer alır.

Bazı CloudLinux sunucularında MySQL Governor adlı bir bileşen veritabanı kullanımını kullanıcı bazında izler. Ancak bunun açık olup olmadığı ve hangi eşiklerle çalıştığı sağlayıcıya bağlıdır; panelden her zaman göremezsiniz.

Veritabanı sınırını en çok yoran işler şunlardır: kapatılmayan kalıcı bağlantılar, her sayfada onlarca sorgu çalıştıran eklentiler ve indekssiz büyük tablolarda yapılan aramalar. Dolayısıyla veritabanı hatası aldığınızda önce yavaş sorguları ve bağlantı açan eklentileri inceleyin.

Hangi limit aşılınca hangi belirtiyi verir?

Aşağıdaki tablo, hosting kaynak limitleri dolduğunda her birinin tipik olarak nasıl göründüğünü ve ilk nereye bakmanız gerektiğini özetliyor. Belirtiler CloudLinux ve cPanel belgelerine dayanır; sağlayıcınızın yapılandırmasına göre küçük farklar olabilir.

Tabloyu okurken bir kuralı akılda tutun: yavaşlık genellikle CPU ya da IO, hata sayfası ise genellikle bellek, süreç ya da EP sınırına işaret eder.

cPanel'de kaynak kullanımını nasıl görürsünüz?

cPanel'de iki ayrı yerden kaynak bilgisi alırsınız. İlki ana sayfadaki istatistik bölümüdür. cPanel belgesine göre bu bölüm disk kullanımı, dosya kullanımı yani inode, aylık bant genişliği ve veritabanı disk kullanımı gibi değerleri gösterir. Aynı belgeye göre CPU kullanımı, bellek kullanımı ve entry processes satırlarını yalnızca CloudLinux çalışan sunucularda görürsünüz.

İkinci yer daha ayrıntılıdır. CloudLinux belgesine göre son kullanıcı, cPanel'de Metrics bölümündeki "CPU and concurrent connection usage" kutucuğuna tıklayarak Resource Usage eklentisini açar. Panelinizin dili ya da teması farklıysa bu adın Türkçe karşılığını görebilirsiniz.

Bu ekranda üç sekme var:

1. Dashboard: Sitenizin son dönemde sınırlanıp sınırlanmadığını ve hangi kaynağın sınıra takıldığını gösterir.
2. Current usage: Kaynak kullanımını grafik ve tablolarla sunar; tabloda kullanım, limit ve hata sayısı yan yana durur.
3. Snapshot: Belirli anlarda kaydettiği süreç listesini, veritabanı sorgularını ve HTTP isteklerini içerir.

cPanel'in genel yapısına yabancıysanız önce cPanel nedir rehberimizi okumanızı öneririz.

Fault sayacını ve Snapshot ekranını nasıl okursunuz?

Current usage tablosundaki en değerli sütun fault, yani hata sayısıdır. Bu sayı, ilgili kaynağın sınıra kaç kez dayandığını gösterir. Kullanım yüksek ama fault sıfırsa siteniz sınıra yaklaşmış ama takılmamıştır. Fault sayısı artıyorsa ziyaretçileriniz o anlarda yavaşlık ya da hata yaşamıştır.

Grafiklerde zaman aralığını gün, saat ya da dakika olarak daraltabilirsiniz. Böylece sorunun her gün aynı saatte mi tekrarladığını, yoksa rastgele mi geldiğini görürsünüz. Her gece aynı saatte yükselen bir IO grafiği çoğu zaman yedekleme ya da cron işine işaret eder.

Snapshot sekmesi ise "o anda ne çalışıyordu?" sorusunun cevabıdır. Süreç listesinde hangi betiğin en çok işlemci ya da bellek kullandığını görürsünüz. HTTP istekleri bölümünde hangi adreslerin çağrıldığını, veritabanı bölümünde de hangi sorguların çalıştığını incelersiniz.

Örneğin snapshot'ta aynı arama adresine yüzlerce istek geldiğini görüyorsanız sorun büyük olasılıkla bot trafiğidir. Buna karşılık tek bir yönetim paneli betiği uzun süre çalışıyorsa sorun bir eklenti ya da planlı görevdir.

Limite yaklaşan bir sitede teşhise nereden başlamalısınız?

Teşhiste sıralı gitmek zaman kazandırır. Önce Dashboard'da hangi kaynağın sınırlandığını görün, sonra o kaynağın grafiğinde zaman desenini bulun. Ardından snapshot'larla o andaki süreçleri eşleştirin.

Saha tecrübemize göre paylaşımlı hostingte sınıra dayanmanın en sık nedenleri şunlardır:

• Eklentiler: Her sayfada ağır sorgu çalıştıran istatistik, güvenlik tarama ya da ilişkili içerik eklentileri.
• Bot trafiği: Arama motoru dışı tarayıcılar, fiyat toplayıcılar ve kaba kuvvet giriş denemeleri.
• Cron işleri: Sık çalışan ya da üst üste binen planlı görevler.
• Yedekleme saati: Tüm hesabı sıkıştıran yedeklerin trafik saatine denk gelmesi.
• Büyük yedekler: Hesabın içinde biriken arşivlerin disk ve inode tüketmesi.

Bir değişikliği denediğinizde sonucu birkaç gün izleyin. Çünkü tek bir sakin günde fault sayısının sıfır görünmesi, sorunun çözüldüğünü kanıtlamaz. Sunucu tarafındaki genel yavaşlık nedenleri için sunucu kaynaklı yavaşlık rehberimize da bakabilirsiniz.

Bot trafiği hosting kaynak limitlerini nasıl tüketir?

Botlar, insan ziyaretçilerden çok daha hızlı ve çok daha fazla sayfa ister. Önbelleksiz bir sitede her bot isteği tam bir PHP çalışması demektir. Dolayısıyla sıradan bir tarayıcı dalgası bile EP ve CPU sınırını kısa sürede doldurabilir.

Ancak her botu engellemek doğru değildir. Googlebot gibi arama motoru tarayıcılarını kesmek görünürlüğünüze zarar verir. Bu nedenle önce gelen isteğin gerçekten iddia ettiği bot olup olmadığını doğrulayın; yöntemini Googlebot doğrulama yazımızda anlattık.

Google'ın resmi belgesine göre sunucu 5xx hataları ya da 429 yanıtı verdiğinde Google tarayıcıları taramayı geçici olarak yavaşlatır. Yani sınıra takılan bir site yalnızca ziyaretçi kaybetmez; arama motorunun tarama hızını da düşürebilir.

Uyumlu botları yönlendirmek için robots.txt kullanabilirsiniz; dosyayı robots.txt oluşturucu ile hazırlamak kolaydır. Öte yandan kötü niyetli botlar robots.txt kuralına uymaz. Bunlar için sağlayıcınızın güvenlik duvarı ya da önünüze koyacağınız bir CDN katmanı daha etkili çözümdür.

Cron ve yedekleme saatleri neden ani zirve yaratır?

Planlı görevler, kaynak grafiğinde düzenli aralıklarla tekrarlayan tepelerin en sık nedenidir. WordPress'in yerleşik zamanlayıcısı WP-Cron, gerçek bir sunucu cron'u değildir; ziyaretçi sayfa açtıkça çalışır. Yoğun bir sitede bu, gereğinden sık çalışma anlamına gelebilir.

WordPress belgeleri, yerleşik zamanlayıcıyı wp-config.php dosyasına şu satırı ekleyerek kapatıp yerine gerçek bir cron işi tanımlamayı önerir:

define( 'DISABLE_WP_CRON', true );

Ardından cPanel'deki Cron Jobs ekranından wp-cron.php dosyasını belirli aralıklarla çalıştıran bir görev eklersiniz. PHP yolunu sağlayıcınızın belgesinden alın. Adım adım kurulum için cron job oluşturma rehberimize bakabilirsiniz.

Yedekleme ise tek seferde en çok IO ve bellek tüketen iştir. Bu yüzden yedek eklentinizi trafiğin en düşük olduğu saate kurun ve aynı saatte başka ağır görev çalıştırmayın. Ayrıca yedekleri hesabın içinde biriktirmek yerine uzak bir depolamaya gönderin; doğru yapı için web sitesi yedekleme stratejisi yazımıza göz atın.

Doğru çözüm sırası: önbellekten paket yükseltmeye

Sınıra dayanan bir sitede ilk refleks çoğu zaman paket yükseltmektir. Ancak yükü yaratan sorun çözülmeden yükseltme yapmak, aynı sorunu daha pahalı bir pakete taşımak anlamına gelebilir. Bizim önerdiğimiz sıra şudur:

1. Önbellek: Sayfa önbelleği ve PHP kod önbelleği, her ziyarette yeniden hesaplanan işi ortadan kaldırır. En büyük kazanç çoğu zaman buradan gelir.
2. Bot engelleme: Kimliğini doğrulayamadığınız ve gereksiz tarayıcıları durdurun; arama motoru botlarına dokunmayın.
3. Kod ve eklenti: Kullanılmayan eklentileri kaldırın, ağır olanları hafif alternatiflerle değiştirin, yavaş sorguları düzeltin.
4. Zamanlama: Cron ve yedek saatlerini trafik saatlerinden ayırın.
5. Paket yükseltme: Bu adımlardan sonra hâlâ düzenli fault görüyorsanız siteniz gerçekten büyümüştür.

Yükseltme kararı verdiğinizde kesinti yaşamadan geçiş için hosting paketi yükseltme rehberimize bakın. Paylaşımlı hostingin artık yetmediğini düşünüyorsanız VPS, VDS ve bulut sunucu farkı yazımız bir sonraki adımı netleştirir.

"Sınırsız" hosting paketlerinde limit yok mu?

Hayır, sağlayıcılar sınırsız ifadesini çoğu zaman disk alanı ya da trafik gibi tek bir kalem için kullanır. İşlemci, bellek, eşzamanlı işlem ve inode gibi kaynaklar ise paylaşımlı bir sunucuda fiziksel olarak sınırlıdır. Bu yüzden "sınırsız" paketlerde bile CPU, RAM ve EP sınırları çalışmaya devam eder.

Ayrıca pek çok sağlayıcı, sınırsız paketlerin kullanım koşullarına adil kullanım maddesi ekler. Yani teoride sınır yoktur, ancak hesabınız sunucuyu belirgin biçimde zorlarsa sağlayıcı sizinle iletişime geçebilir ya da hesabı kısıtlayabilir.

Bu konuyu ayrı bir yazımızda daha ayrıntılı ele alıyoruz; burada yalnızca şunu not edelim: paket karşılaştırırken "sınırsız" kelimesine değil, CPU, RAM, EP, IO ve inode değerlerine bakın. Bu değerler paket sayfasında yazmıyorsa satın almadan önce sağlayıcıdan yazılı olarak isteyin. Genel hosting seçim kriterleri için hosting seçimi rehberimiz işinizi kolaylaştırır.

Hosting sağlayıcınıza hangi soruları sormalısınız?

Paket seçerken ya da hosting kaynak limitleri yüzünden sorun yaşadığınızda doğru sorular, sağlayıcıyla yazışmayı hızlandırır. Bizim kullandığımız soru listesi şöyledir:

• Paketimde CPU, RAM, IO, IOPS, EP ve NPROC değerleri tam olarak nedir?
• Inode sınırı var mı; varsa yumuşak ve sert değerleri nedir?
• MySQL eşzamanlı bağlantı sınırı ve saatlik sorgu sınırı var mı?
• Aylık trafik kotası dolunca sağlayıcı siteyi askıya mı alıyor, yalnızca uyarı mı geliyor?
• Resource Usage ekranı hesabımda açık mı; geçmiş kaç gün geriye gidiyor?
• Son bir haftada hesabımda hangi limitte fault oluştu, hangi saatlerde?
• Sunucu tarafında bot ya da kaba kuvvet koruması var mı?
• Bir üst pakete geçişte kesinti ya da IP değişikliği oluyor mu?

Sorun bildirirken de somut olun. "Site yavaş" yerine "her gece belirli bir saatte IO fault sayısı artıyor, snapshot'ta yedek betiği çalışıyor" gibi bir cümle, destek ekibinin doğrudan doğru yere bakmasını sağlar.

Ne zaman kendiniz uğraşmamalı, sağlayıcıya bırakmalısınız?

Paylaşımlı hostingte sizin kontrol alanınız hesabınızla sınırlıdır. Eklenti, önbellek ayarı, cron zamanı, robots.txt ve dosya temizliği sizin işinizdir. Buna karşılık sunucunun kendisiyle ilgili konular sağlayıcının sorumluluğundadır.

Şu durumlarda kendiniz deneme yapmak yerine doğrudan destek talebi açın:

• Fault görmediğiniz hâlde siteniz yavaşsa: sorun büyük olasılıkla sunucu genelindedir.
• Snapshot'ta tanımadığınız süreçler varsa: bu bir güvenlik sorunu olabilir.
• Limit değerlerinin değiştiğinden şüpheleniyorsanız: yalnızca sağlayıcı bunu doğrulayabilir.
• Kaba kuvvet ya da hizmet engelleme saldırısı yaşıyorsanız: ağ düzeyinde engelleme sağlayıcının işidir.

Öte yandan site tarafındaki sorunlar için sağlayıcıdan çözüm beklemek de gerçekçi değildir. Hosting firması genellikle eklentinizi ya da temanızı optimize etmez. Bu tür işlerde geliştiricinizle ya da web tasarım ve geliştirme ekibimizle çalışmak daha doğru olur.

Hosting kaynak limitlerini yönetmek için kısa kontrol listesi

Bu rehberin özeti, düzenli aralıklarla uygulayabileceğiniz birkaç adımdan oluşuyor. Ayda bir Resource Usage ekranını açın ve fault sütununa bakın. Ardından istatistik bölümünde disk alanı ve inode kullanımının yüzde kaçta olduğunu not edin.

Ayrıca her yeni eklentiden sonra birkaç gün kaynak grafiğini izleyin. Yedek ve cron saatlerinin trafik saatleriyle çakışmadığından emin olun. Eski yedekleri ve kullanılmayan dosyaları hesabın dışına taşıyın.

Son olarak paket değerlerinizi yazılı olarak saklayın. Böylece bir sorun yaşadığınızda neyin değiştiğini sağlayıcıyla karşılaştırabilirsiniz. Hosting kaynak limitleri sizi cezalandırmak için değil, sunucudaki herkesi korumak için vardır; onları okumayı öğrendiğinizde çoğu yavaşlık ve hata sayfası tahmin edilebilir bir soruna dönüşür.

Kaynaklar: CloudLinux limit belgesi, CloudLinux Resource Usage eklentisi, cPanel arayüz belgesi, MySQL hesap kaynak sınırları, Google Search Central: HTTP ve ağ hataları.