Hosting Seçerken Disk Alanından Daha Önemli Hangi Değerler Var?

Hosting paketi seçerken “kaç GB disk veriyor?” sorusu önemlidir; ancak çoğu site için tek başına belirleyici değildir. 20 GB disk alanı olan ama CPU, RAM veya PHP işlem limiti düşük bir paket; 5 GB alanı olan daha dengeli bir paketten daha yavaş çalışabilir. Özellikle WordPress, WooCommerce, forum, üyelik sistemi ve yoğun veritabanı kullanan projelerde asıl sorun çoğu zaman disk doluluğu değil, kaynağa erişim sırasındaki sınırlardır.
Bu konuda ne öğreneceksiniz?

• Önce kaynak limitlerini ve ölçüm ekranını öğrenin
• cPanel üzerinde hangi menülere bakılır?
• Değerleri nasıl yorumlamalısınız?
• PHP, veritabanı ve önbellek kapasitesini birlikte değerlendirin
• Yedek, geri yükleme ve destek kalitesini test edin
• Ne zaman paylaşımlı hostingden VPS’e geçilir?

1. Önce kaynak limitlerini ve ölçüm ekranını öğrenin

Satın almadan önce sağlayıcıya yalnızca “CPU kaç çekirdek?” diye sormayın. Şu değerlerin paketiniz için sayısal karşılığını isteyin:

• CPU limiti: Yüzde olarak mı, çekirdek olarak mı tanımlanıyor? Kısa süreli kullanım artışında aşım hakkı var mı?
• RAM veya fiziksel bellek limiti: MB/GB cinsinden kaç? Aşılırsa site yavaşlıyor mu, yoksa 500/503 hatası mı dönüyor?
• PHP worker veya eşzamanlı işlem limiti: Aynı anda kaç PHP isteği çalışabiliyor?
• Entry process: Aynı anda kaç istek hesaba girebiliyor?
• I/O ve IOPS: Disk okuma-yazma hızı KB/s olarak mı, işlem sayısı olarak mı sınırlandırılıyor?
• NPROC/process limiti: Cron, PHP, e-posta ve arka plan işlemleri toplamda kaç süreç çalıştırabiliyor?
• Inode/file usage: Kaç dosya ve klasör oluşturabilirsiniz?
• Veritabanı sınırları: Veritabanı sayısı dışında bağlantı, tablo boyutu, sorgu süresi veya kullanıcı limiti var mı?

CloudLinux kullanılan cPanel sunucularında bu değerler genellikle ayrı kaynak limitleri olarak izlenir. CloudLinux belgelerinde CPU/I/O aşımının yavaşlamaya, bellek veya süreç limitlerinin ise bazı durumlarda 500/503 hatalarına yol açabileceği açıklanır: CloudLinux kaynak limitleri.

2. cPanel üzerinde hangi menülere bakılır?

Sağlayıcı size deneme hesabı veya mevcut hesabınıza erişim veriyorsa şu yolu izleyin:

1. cPanel → Metrics → CPU and Concurrent Connection Usage bölümünü açın. Bu menü görünmüyorsa sağlayıcı özelliği kapatmış veya sunucuda CloudLinux kullanmıyor olabilir.
2. Grafikte CPU, giriş işlemleri, fiziksel bellek ve benzeri limitlerde “fault” veya aşım sayısı olup olmadığını kontrol edin.
3. cPanel ana sayfasında sağ veya üst taraftaki Resource Usage/Statistics alanını açın. CPU Usage, Memory Usage, Entry Processes ve File Usage değerlerini not edin.
4. cPanel → Metrics → Errors bölümünde son 300 hata kaydını inceleyin. 508, 500, 503 veya “resource limit reached” ifadeleri kaynak baskısına işaret edebilir.
5. cPanel → Files → File Usage veya Statistics alanından inode kullanımını kontrol edin. Disk alanınız boş olsa bile inode sınırı doluysa yeni dosya, önbellek veya e-posta oluşturamayabilirsiniz.

cPanel’in kendi dokümantasyonunda CPU, bellek, entry process ve file usage değerlerinin hesap türüne ve sunucu yapılandırmasına göre gösterilebildiği belirtilir: cPanel istatistikleri. Menü adları tema veya cPanel sürümüne göre değişebilir; aynı ekranı bulamazsanız üstteki arama kutusuna “Resource Usage” yazın.

3. Değerleri nasıl yorumlamalısınız?

Tek bir anlık ölçümle karar vermeyin. Normal trafik saatinde ve kampanya/ziyaret artışı sırasında en az iki ayrı zaman aralığını karşılaştırın. Örnek yorumlama:

• CPU sürekli sınıra dayanıyor, fakat bellek ve I/O normalse: PHP kodu, eklenti, sorgu veya trafik yoğunluğu araştırılmalıdır.
• Memory fault artıyor ve 500/503 görülüyorsa: Paket belleği yetersiz olabilir; önce ağır eklenti ve PHP süreçlerini inceleyin, sonra paket yükseltin.
• Entry process doluyor ama CPU düşükse: Çok sayıda eşzamanlı istek, yavaş dış API çağrısı, bot trafiği veya düşük PHP worker sayısı olabilir.
• I/O limitine ulaşılıyor ve sayfalar özellikle yönetim panelinde yavaşlıyorsa: Yedekleme, log, tarama, medya işleme veya veritabanı işlemleri diski meşgul ediyor olabilir.
• Inode doluyor: Çok sayıda önbellek dosyası, eski yedek, e-posta veya küçük oturum dosyası temizlenmelidir.
• Hiç fault görünmüyor fakat site yavaşsa: DNS, uzak API, veritabanı sorguları, görsel boyutu, tema/eklenti kodu veya ağ gecikmesi ayrıca test edilmelidir.

Başarılı sonuç; yalnızca “limit yüksek” görünmesi değildir. Yoğun saatlerde site açılışının kararlı olması, hata günlüğünde tekrarlayan 508/500/503 bulunmaması ve kaynak grafiklerinde sürekli tavana vurulmamasıdır.

4. PHP, veritabanı ve önbellek kapasitesini birlikte değerlendirin

Paket karşılaştırırken sağlayıcıdan şu bilgileri yazılı isteyin:

• Sunucuda hangi PHP sürümleri var ve PHP sürümü cPanel → Software → MultiPHP Manager üzerinden değiştirilebiliyor mu?
• PHP memory_limit, max_execution_time, upload_max_filesize ve post_max_size değerleri nedir?
• PHP-FPM, OPcache ve nesne önbelleği (örneğin Redis/Memcached) destekleniyor mu? Kullanım için ek ücret veya özel izin gerekiyor mu?
• Veritabanı sunucusu MariaDB/MySQL hangi sürümde ve uzak bağlantı kapalı mı?
• Cron Jobs için cPanel → Advanced → Cron Jobs yolundan görev eklenebiliyor mu? Dakikada bir çalışma kısıtlanıyor mu?

Örneğin WordPress’te sayfa önbelleği etkin olsa bile giriş yapmış kullanıcılar, sepet sayfaları ve yönetim paneli her zaman aynı şekilde önbelleğe alınmaz. Bu nedenle “cache var” cevabı tek başına yeterli değildir; hangi katmanların önbelleklendiğini sorun.

5. Yedek, geri yükleme ve destek kalitesini test edin

Yedekleme özelliğinin varlığı ile işe yarar yedek aynı şey değildir. Satın almadan önce şu senaryoyu sorun veya mümkünse küçük bir test yapın:

1. Panel → Files → Backup/Backup Wizard bölümünden dosya ve veritabanı yedeğinin ayrı ayrı alınabildiğini kontrol edin.
2. Yedeklerin aynı sunucuda mı, uzak depolamada mı tutulduğunu öğrenin. Sunucu tamamen erişilemezse aynı sunucudaki yedek tek başına yeterli olmayabilir.
3. Bir test alt alan adı oluşturup yedeği oraya geri yükleyin. Ana site üzerinde deneme yapmayın.
4. Geri yüklemenin kaç tıklama ile yapıldığını ve destek ekibinin hangi durumlarda müdahale ettiğini yazılı teyit edin.

Geri yükleme başarısız olursa sonraki kontrol; dosya izinleri, PHP sürümü, veritabanı kullanıcı yetkileri, disk/inode limiti ve yedek arşivinin eksiksiz inip inmediğidir. Yedek dosyalarını yalnızca web kök dizininde bırakmayın; parola, veritabanı parolası veya API anahtarı içeren arşivleri herkese açık URL ile paylaşmayın.

6. Ne zaman paylaşımlı hostingden VPS’e geçilir?

Tek başına ziyaretçi sayısı VPS için kesin ölçü değildir. Daha anlamlı geçiş sinyalleri şunlardır:

• Kaynak limitleri düzenli olarak aşılır ve optimizasyon sonrası da devam eder.
• Trafik artışı sırasında 508/500/503 hataları oluşur.
• Özel PHP eklentisi, servis, güvenlik kuralı veya işletim sistemi ayarı gerekir.
• Cron, kuyruk, arka plan işçisi veya uzun süren işlemler paylaşımlı pakette kesilir.
• Yedekleme, tarama veya medya dönüştürme işlemleri canlı siteyi belirgin biçimde yavaşlatır.
• Sağlayıcının desteklediği yapılandırma sınırları, projenin teknik gereksinimlerini karşılamaz.

VPS’e geçiş ise otomatik olarak daha hızlı site anlamına gelmez. İşletim sistemi güncellemeleri, güvenlik duvarı, SSH anahtarları, yedekleme, web sunucusu, veritabanı ve izleme sorumluluğunun bir kısmı size geçebilir. Yönetim tecrübeniz yoksa yönetimli VPS seçeneğini veya sistem yöneticisi desteğini ayrıca maliyetlendirin.

Pratik karar formülü

Bir paketi şu basit çerçeveyle puanlayabilirsiniz:

Toplam uygunluk = kaynak limitleri + ölçüm görünürlüğü + yedek geri dönüşü + destek - yönetim riski

Örnek olarak; disk alanı 100 üzerinden 90 görünse bile CPU ve entry process sürekli sınıra ulaşıyorsa paket genel olarak uygun değildir. Buna karşılık daha az disk alanı sunan bir paket, yeterli CPU/RAM, görünür kaynak grafikleri, test edilebilir yedek ve hızlı teknik destek sağlıyorsa daha doğru seçim olabilir. Bu puanlama evrensel bir standart değil, kendi trafik ve uygulamanıza göre kullanabileceğiniz başlangıç çerçevesidir.

Kendi durumunuzu teşhis etmek için

• cPanel’de son 7 günde hangi kaynak değeri en çok sınıra yaklaşıyor: CPU, RAM, I/O, entry process veya inode?
• Yavaşlık tüm ziyaretçilerde mi, yalnızca yönetim paneli/ödeme/arama gibi belirli işlemlerde mi görülüyor?
• Son hata günlüğünde 508, 500, 503 veya veritabanı bağlantı hatası var mı?
• Mevcut sağlayıcınızdan yedek geri yüklemeyi test alt alanında denemeniz mümkün mü?

Bu dört sorunun cevabı, yalnızca daha fazla disk alanına mı, daha dengeli bir pakete mi, yoksa VPS ve uygulama optimizasyonuna mı ihtiyacınız olduğunu genellikle netleştirir.