Shared Hosting’den VPS’e Ne Zaman Geçmelisiniz?
Hosting seçimi, çoğu zaman “en ucuzu al, sonra bakarız” mantığıyla yapılıyor. Sonra bir gün siteniz çöküyor, hosting panelinize giriyorsunuz, “CPU throttled” yazısıyla karşılaşıyorsunuz ve kendinizi çaresiz hissediyorsunuz. Bu yazıyı tam olarak o anın öncesinde okumanız için yazdım.
Shared hosting, başlangıç için mükemmel bir seçenek. Ucuz, bakımı yok, teknik bilgi gerektirmiyor. Ama büyüme başladığında, ya da büyümeden önce bile bazı sinyaller gelmeye başlıyor. Bu sinyalleri okumayı bilmek, hem paranızı hem de saçlarınızı kurtarır.
Shared Hosting’in Gerçek Yüzü
Shared hosting’de bir sunucuyu yüzlerce, bazen binlerce kullanıcıyla paylaşıyorsunuz. Hosting firmaları bunu “sınırsız” gibi kelimelerle pazarlıyor ama altta yatan gerçek şu: fiziksel kaynaklar sınırlı, sizin kullanabileceğiniz pay ise çok daha sınırlı.
Tipik bir shared hosting ortamında CPU kullanımınız genellikle birkaç dakika içinde throttle ediliyor. RAM’iniz paylaşımlı havuzdan geliyor. Disk I/O’nuz komşu hesabın ani trafik alması durumunda doğrudan etkileniyor. Buna hosting sektöründe “noisy neighbor” problemi deniyor.
Bunu test etmek için en basit yöntem, kendi sitenize bağlanıp sunucu yanıt sürelerini ölçmek:
# Curl ile basit response time ölçümü
curl -o /dev/null -s -w "DNS: %{time_namelookup}snConnect: %{time_connect}snTTFB: %{time_starttransfer}snTotal: %{time_total}sn" https://siteniz.comBu komutu günün farklı saatlerinde çalıştırın. Eğer gece 02:00’de 0.3 saniye olan TTFB, öğleden sonra 14:00’te 2-3 saniyeye çıkıyorsa, bu doğrudan shared hosting’in sunucu yükünden kaynaklanıyor olabilir.
Geçiş Zamanını Gösteren Kritik Sinyaller
1. Sürekli “Resource Limit Exceeded” Hataları
cPanel veya DirectAdmin üzerinden error log’larınızı kontrol ettiğinizde şuna benzer satırlar görüyorsanız:
# cPanel error loglarına bakış
tail -f /home/kullanici/logs/siteniz.com-error_log | grep -i "resource|limit|cpu|memory"Bu loglar genellikle şöyle görünür:
[Tue Oct 15 14:23:11 2024] [error] [client 1.2.3.4] Resource temporarily unavailable: couldn't spawn child processBu mesajı haftada birden fazla görüyorsanız, shared hosting sizi zorluyor demektir.
2. PHP İşlemlerinin Öldürülmesi
Shared hosting’de PHP işlemleri belirli bir memory limitine ulaştığında hosting sistemi tarafından otomatik olarak sonlandırılır. WordPress sitenizde büyük bir import yapıyorsunuz, yarım kaldı. WooCommerce raporunuzu çalıştırdınız, 30 saniyede timeout aldınız. Bu durumların nedeni çoğunlukla shared hosting kısıtlamaları.
# VPS'e geçtikten sonra PHP memory limitini kontrol etmek
php -i | grep memory_limit
# php.ini üzerinden değiştirmek
sed -i 's/memory_limit = 128M/memory_limit = 512M/' /etc/php/8.2/fpm/php.ini
systemctl restart php8.2-fpm3. Veritabanı Bağlantı Hataları
MySQL bağlantı sayısı shared hosting’de genellikle 20-30 ile sınırlı tutulur. Sitenize anlık 50-60 ziyaretçi geldiğinde “Too many connections” hatası alıyorsunuz demektir.
# VPS'te MySQL max connections durumunu kontrol etmek
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections';"
mysql -u root -p -e "SHOW STATUS LIKE 'Threads_connected';"4. SSH Erişiminin Olmaması veya Kısıtlı Olması
Cron job’larınızı web arayüzünden ayarlamak zorunda kalıyorsunuz. Script çalıştırmak istiyorsunuz ama SSH yok, ya da varsa son derece kısıtlı. Basit bir deployment pipeline kurmak imkansız. Bu tek başına bile VPS’e geçiş için güçlü bir sebep.
Trafik Eşikleri: Rakamlarla Konuşalım
“Ne kadar trafik alınca geçeyim?” sorusunun kesin bir cevabı yok, ama pratik eşiklerden bahsedebiliriz.
Statik içerikli bir site için shared hosting genellikle aylık 50.000-100.000 sayfa görüntülemeye kadar yeterli.
WordPress gibi dinamik bir site için bu eşik çok daha düşük. Özellikle iyi optimize edilmemişse, aylık 20.000-30.000 ziyaretçide sorunlar başlayabilir.
WooCommerce veya e-ticaret kullanıyorsanız işlemler veritabanı yoğun olduğu için, 500 ürünlü bir mağazada çok daha erken sorunlarla karşılaşabilirsiniz.
Sitenizin anlık kaç ziyaretçi aldığını ve sunucunun bunu nasıl karşıladığını görmek için şu yaklaşımı kullanabilirsiniz:
# Apache access log'undan son 1 saatteki istek sayısını çekmek (VPS'e geçtikten sonra)
awk -v d="$(date -d '1 hour ago' '+%d/%b/%Y:%H')" '$4 ~ d' /var/log/apache2/access.log | wc -l
# Nginx için
awk -v d="$(date -d '1 hour ago' '+%d/%b/%Y:%H')" '$4 ~ d' /var/log/nginx/access.log | wc -lGüvenlik: Shared Hosting’de Gözden Kaçan Risk
Bu konudan hosting firmalarının pek bahsetmediği bir gerçekle başlayalım: shared hosting’de aynı sunucudaki başka bir hesap hacklenirse, sizin siteniz de etkilenebilir.
2022 yılında bir müşterimin sitesi hacklendiğinde inceleme yaparkek fark ettim ki asıl açık başka bir hesaptaydı. Oradan filesystem üzerinden diğer hesaplara yayılmış. Bu “cross-account contamination” olarak bilinen bir saldırı vektörü.
VPS’te ise siz tek kiracısınız. Kernel seviyesinde izolasyon var. Başkasının güvenlik açığı sizi doğrudan etkilemez.
Shared hosting güvenlik durumunu kontrol etmek için yapabilecekleriniz kısıtlı, ama VPS’te şunları yapabilirsiniz:
# Sisteme yapılan son başarısız SSH girişimlerini görmek
grep "Failed password" /var/log/auth.log | tail -20
# Fail2ban kurulumu ve aktif yasaklı IP'leri görmek
fail2ban-client status sshd
# Açık portları listelemek
ss -tlnp | grep LISTENGeçiş Öncesi Yapmanız Gereken Hazırlıklar
VPS’e atlayacaksanız bunu “yarın taşınıyoruz” modunda yapmayın. Plansız geçişler, özellikle aktif e-ticaret sitelerinde felaket olabilir.
Mevcut Durumu Belgeleyin
# Shared hosting'den site dosyalarını yedeklemek
# SSH varsa:
tar -czf yedek_sitedosyalari_$(date +%Y%m%d).tar.gz public_html/
# Veritabanı yedeği
mysqldump -u kullanici -p veritabani_adi > yedek_db_$(date +%Y%m%d).sql
# Dosyaları yerel bilgisayara indirmek
rsync -avz -e "ssh" [email protected]:~/public_html/ ./local_backup/DNS TTL’yi Düşürün
Geçişten en az 48 saat önce DNS kayıtlarınızın TTL değerini düşürün. Böylece geçiş yaptığınızda DNS değişikliği çok daha hızlı yayılır.
# Mevcut TTL değerini kontrol etmek
dig +nocmd siteniz.com A +noall +answer
# Geçiş döneminde ideal TTL: 300 saniye (5 dakika)
# Geçiş tamamlandıktan sonra tekrar 3600'e çıkarabilirsinizVPS Seçimi: Hangi Özelliklere Bakmalısınız
RAM Miktarı
WordPress tabanlı bir site için minimum 1 GB RAM ile başlayabilirsiniz, ama 2 GB daha rahat. WooCommerce veya yüksek trafikli bir site için 4 GB’tan başlamanızı öneririm. Redis veya Memcached ekleyecekseniz bu rakamı artırın.
vCPU
Tek bir WordPress sitesi için 1 vCPU yeterli başlangıç noktası. Birden fazla site veya yoğun arka plan işlemleri için 2 vCPU.
Disk Tipi
NVMe > SSD > HDD. Veritabanı ağırlıklı uygulamalarda disk I/O performansı kritik. Aynı RAM ve CPU’ya sahip iki VPS arasında NVMe ile HDD arasındaki fark, web sitesi yüklenme sürelerinde 3-5 kata kadar çıkabilir.
Bandwidth ve Network
Türkiye’deki kullanıcılara hizmet veriyorsanız, sunucunun lokasyonu önemli. Frankfurt veya Amsterdam genellikle iyi ping değerleri sağlıyor. Özellikle yerel bir kullanıcı kitleniz varsa, yerli VPS sağlayıcılarını da değerlendirin.
VPS Kurulumu: İlk Adımlar
VPS’inizi aldınız, IP adresiniz var, şifreniz var. Şimdi ne yapacaksınız? İşte ilk yapmanız gerekenler:
# Root ile bağlandıktan sonra sistemi güncelleyin (Ubuntu/Debian için)
apt update && apt upgrade -y
# Yeni bir sudo kullanıcısı oluşturun, root ile çalışmaktan kaçının
adduser siteyonetici
usermod -aG sudo siteyonetici
# SSH key ile giriş için public key'i ekleyin
mkdir -p /home/siteyonetici/.ssh
echo "ssh-rsa AAAA...sizin_public_key..." >> /home/siteyonetici/.ssh/authorized_keys
chmod 700 /home/siteyonetici/.ssh
chmod 600 /home/siteyonetici/.ssh/authorized_keys
chown -R siteyonetici:siteyonetici /home/siteyonetici/.ssh# SSH konfigürasyonunu güvenli hale getirin
nano /etc/ssh/sshd_config
# Şu değerleri değiştirin:
# PermitRootLogin no
# PasswordAuthentication no
# PubkeyAuthentication yes
# Port 22'yi değiştirmeyi de düşünebilirsiniz
systemctl restart sshd# UFW firewall'u aktif edin
ufw allow 22/tcp # veya değiştirdiğiniz SSH portu
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw statusGeçiş Sürecinde Sık Yapılan Hatalar
Hata 1: DNS’i değiştirmeden önce siteyi test etmemek. VPS’inize sitenizi kurduktan sonra, DNS değişikliği yapmadan önce /etc/hosts dosyasını düzenleyerek sitenizi test edin:
# Yerel makinenizde (Linux/Mac)
sudo nano /etc/hosts
# Şunu ekleyin:
# 1.2.3.4 siteniz.com www.siteniz.com
# (1.2.3.4 = VPS IP adresiniz)Böylece sadece sizin bilgisayarınız yeni sunucuya bağlanır, ziyaretçiler hala eski sunucuda. Her şey çalışıyor mu kontrol edin, sonra DNS’i değiştirin.
Hata 2: SSL sertifikasını unutmak. Let’s Encrypt ile ücretsiz SSL kurabilirsiniz:
# Certbot kurulumu (Nginx için)
apt install certbot python3-certbot-nginx -y
certbot --nginx -d siteniz.com -d www.siteniz.com
# Otomatik yenilemeyi test etmek
certbot renew --dry-runHata 3: Swap alanı olmadan çalışmak. Özellikle 1 GB RAM’li VPS’lerde swap hayat kurtarır:
# 2 GB swap oluşturmak
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
# Kalıcı hale getirmek için /etc/fstab'a ekleyin
echo '/swapfile none swap sw 0 0' | tee -a /etc/fstab
# Swap kullanımını kontrol etmek
free -h
swapon --showVPS’e Geçtikten Sonra Performans Optimizasyonu
Geçişi yaptınız ama iş bitmedi. Shared hosting’den VPS’e geçen çoğu kişi optimizasyon adımlarını atlıyor.
WordPress kullanıyorsanız, PHP-FPM + Nginx kombinasyonu Apache’den çok daha iyi performans verir. Redis ile oturum ve nesne önbellekleme ekleyin. Nginx’te FastCGI cache kurarsanız veritabanı sorgusu olmadan sayfa sunabilirsiniz.
# PHP-FPM process sayısını kontrol etmek ve optimize etmek
nano /etc/php/8.2/fpm/pool.d/www.conf
# Önemli parametreler:
# pm = dynamic
# pm.max_children = 10 (RAM'e göre ayarlayın: her child ~50MB)
# pm.start_servers = 3
# pm.min_spare_servers = 2
# pm.max_spare_servers = 5
systemctl restart php8.2-fpm# MySQL/MariaDB için temel optimizasyon kontrol
mysql -u root -p -e "SHOW STATUS LIKE 'Qcache%';"
mysql -u root -p -e "SHOW STATUS LIKE 'Innodb_buffer_pool%';"
# my.cnf'e eklenebilecek temel parametreler (2GB RAM için)
# innodb_buffer_pool_size = 512M
# query_cache_size = 64M
# max_connections = 100Managed VPS mi, Unmanaged VPS mi?
Bu soru aslında “ne kadar zaman harcayabilirim?” sorusuna dönüşüyor.
Unmanaged VPS: Daha ucuz, tam kontrol sizdeydiniz. Güvenlik yamaları, servis konfigürasyonları, yedekleme, monitoring hepsi sizin sorumluluğunuzda. Eğer Linux komut satırında rahat değilseniz, bu seçenek başlangıçta sizi zorlayacak.
Managed VPS: Hosting firması temel yönetimi üstleniyor. Güvenlik güncellemeleri, sunucu monitöring, yedekleme servisleri dahil oluyor. Maliyeti yüksek ama teknik bilginiz sınırlıysa ya da zamanınız yoksa mantıklı bir seçenek.
Orta yol olarak cPanel/Plesk lisanslı unmanaged VPS da bir seçenek. Komut satırından korkuyorsanız ama managed’ın maliyetini de istemiyorsanız, bu geçiş döneminde işe yarayabilir.
Monitoring: Gözlerinizi Açık Tutun
VPS’e geçtikten sonra en önemli alışkanlık, sistemin ne yaptığını düzenli takip etmek. Shared hosting’de bunu hosting firması yapıyordu, artık siz yapacaksınız.
# Basit sistem durumu kontrolü
htop
# Disk kullanımı
df -h
du -sh /var/log/* | sort -rh | head -10
# Son 24 saatteki yüksek CPU kullanan processler (atop kuruluysa)
atop -r /var/log/atop/atop_$(date +%Y%m%d) | grep "CPU|MEM" | tail -50
# Nginx/Apache erişim loglarında hata oranını kontrol etmek
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10Uzun vadede Netdata, Prometheus + Grafana veya en azından UptimeRobot gibi basit bir uptime monitoring aracı kurun. Siteniz çöktüğünde siz değil sistem sizi uyarısın.
Sonuç
Shared hosting’den VPS’e geçiş kararı, çoğunlukla “çok geç” alınıyor. Siteniz yavaşlamaya başladığında, hata logları dolmaya başladığında veya bir gece downtime aldığınızda karar veriyorsunuz. Oysa bu sinyalleri erkenden okumak, hem kullanıcı deneyiminizi hem de iş sürekliliğinizi korur.
Geçiş kararı için bekleyeceğiniz kesin bir trafik rakamı yok. Ama şu üç koşuldan herhangi biri gerçekleştiyse, artık geçiş zamanınız gelmiştir: kaynak limiti hatalarını düzenli görüyorsanız, güvenlik veya özelleştirme ihtiyacınız shared hosting’in sınırlarına dayıyorsa, ya da siteniz gelir getirmeye başladıysa ve downtime’ın maliyeti VPS maliyetinin üstüne çıkıyorsa.
VPS yönetimi ilk başta korkutucu görünebilir. Ama bir kez temel güvenlik yapılandırmasını, web sunucusunu ve veritabanını kurduğunuzda, shared hosting’e geri dönmek istemeyeceğinizi göreceksiniz. Kontrol sizdeydiniz ve bu fark çok şeyi değiştirir.