Hosting Paketim Yetmiyor: Ne Zaman Yükseltmeli?

Site sabah normal açılıyordu, öğleden sonra bir anda "503 Service Unavailable" vermeye başladı. Panele girdiniz, kırmızı bir uyarı duruyor: "Resource Limit Is Reached". Ya da hiç uyarı yok ama admin paneli üç saniye yerine on iki saniyede açılıyor. İlk refleks hep aynı: hosting paketi yetersiz kaldı, üst pakete geçelim. Bazen doğru karardır. Ama on yıllık sistem yöneticiliğinde gördüğüm tablo şu: hosting paketi yükseltme taleplerinin yaklaşık yarısında paket zaten yeterlidir, sorun tek bir eklenti, tek bir tabloda biriken çöp veri veya kapatılmış bir önbellektir. Yükseltirsiniz, iki hafta rahat edersiniz, sonra aynı duvara daha pahalı bir paketle çarparsınız.

Bu yazı size satış tavsiyesi vermiyor. Size eşikli bir karar akışı veriyor: önce hangi metriği nereden okuyacaksınız, o metrik hangi değerin üstündeyse gerçekten paket sorunudur, altındaysa hangi ayarı düzelteceksiniz. Her bölümün sonunda "yükselt" veya "önce şunu yap" şeklinde net bir çıktı var. cPanel ekranlarındaki gerçek alan adlarını, gerçek komutları ve gerçek log satırlarını kullanacağız; genel geçer "sitenizi optimize edin" cümlesi kurmayacağız.

Önce Doğru Metriği Okuyun: Yavaşlık Bir Sayı Değildir#

Yükseltme kararı "site yavaş" hissiyle verilemez, çünkü yavaşlığın en az beş farklı sebebi vardır ve yalnızca ikisi paketle ilgilidir. Karar vermeden önce şu dört sayıyı toplamanız gerekir:

1. Sunucunun ilk baytı gönderme süresi (TTFB). Tarayıcıda F12 → Network → belgeye tıklayın → "Waiting for server response". 200 ms altı iyi, 200-600 ms normal, 600 ms üstü sunucu tarafında bir şey yanıyor demektir.
2. Kaynak limiti ihlali sayısı (faults). cPanel → Resource Usage ekranı. Burada CPU, Entry Processes, I/O, IOPS, Physical Memory ve Number of Processes için son 24 saat ve son 7 günün "faults" sütunu vardır. Sıfırdan büyük her değer, sunucunun sizi o an durdurduğu anlamına gelir.
3. Disk ve inode doluluğu. cPanel sağ sütun → Disk Usage ve File Usage. Inode konusunu ayrıntısıyla disk kotası ve inode yazısında ele aldık; burada sadece eşiği kullanacağız.
4. Gerçek eşzamanlı ziyaretçi. Analytics'teki "aylık ziyaretçi" işinize yaramaz. Lazım olan, zirve saatteki dakikalık aktif kullanıcı sayısıdır.

Bu dördü elinizde yoksa alacağınız karar tahmindir. Elinizdeyse karar mekanik hâle gelir.

Kaynak Limiti Uyarısı Aldıysanız: Hangi Limit Doldu#

Paylaşımlı hostingte "kaynak yetmedi" tek bir şey değildir; birbirinden bağımsız altı sayaç vardır ve hangisinin dolduğu, ne yapmanız gerektiğini tamamen değiştirir. Bu ayrımı yapmadan yapılan yükseltme çoğu zaman yanlış kaynağı büyütür.

Bu tablonun okunuş biçimi şu: CPU dışındaki hiçbir satırda ilk hamleniz yükseltme olmamalı. 508 hatasının anatomisini 508 Resource Limit Is Reached hatası yazısında adım adım anlattık; limitlerin nasıl tanımlandığını ise paylaşımlı hosting kaynak limitleri yazısında bulacaksınız.

Limitleri SSH erişiminiz varsa doğrudan da okuyabilirsiniz:

# CloudLinux LVE altında son 24 saatin ihlal özeti
lveinfo --period=1d --by-fault=any

# Anlık durum: hangi limit ne kadar dolu
lveps -p

# Hesabınızın anlık PHP süreç sayısı
ps -u $(whoami) -o pid,etime,%cpu,%mem,cmd --sort=-%cpu | head -20

Eşik Tablosu: Hangi Değerin Üstünde Gerçekten Yükseltme Gerekir#

Aşağıdaki tablo bu yazının çekirdeğidir. Sol sütundaki değeri ölçün, sağdaki karara uyun. "İkisi arası" bölgeler kasıtlıdır: orada yapılacak iş optimizasyondur, yükseltme değil.

Kritik nokta şudur: "Önce optimize et" sütunundaki bir değeri gördüğünüzde yükseltirseniz, üç ay sonra aynı satırda bir üst pakette olursunuz. Çünkü optimizasyonla kazanılabilecek 3-5 kat performansı satın alarak elde etmeye çalışmış olursunuz ve o pahalı bir yoldur.

Bir istisna var: CPU fault sayısı düzenli olarak 20'nin üstündeyse ve site içeriği zaten önbelleğe alınmışsa, orada tartışılacak bir şey kalmaz. Sunucu sizi her gün durduruyor demektir.

Yükseltmeden Önce Denenecek Beş Şey#

Bu beş adım, gerçek vakalarda paket yükseltmeyi en sık gereksiz kılan müdahalelerdir. Sıralama önemlidir: yukarıdan aşağı gidin, her adımdan sonra 48 saat bekleyip fault sayısına tekrar bakın.

1. Tam sayfa önbelleğini açın. WordPress'te LiteSpeed Cache veya sunucu tarafı önbellek, giriş yapmamış ziyaretçi için PHP'yi hiç çalıştırmaz. Bu tek başına CPU kullanımını çoğu vitrin sitesinde %70-90 düşürür. Hangi katmanın neyi çözdüğünü WordPress önbellek rehberi yazısında karşılaştırdık.

2. Bot trafiğini ayıklayın. Ham erişim loglarına bakmadan "ziyaretçim arttı" demeyin:

   # Son 10.000 isteğin en çok istek yapan 15 kaynağı
   tail -10000 ~/access-logs/example.com | awk '{print $1}' | sort | uniq -c | sort -rn | head -15
   
   # En çok CPU yiyen URL'ler
   tail -10000 ~/access-logs/example.com | awk '{print $7}' | sort | uniq -c | sort -rn | head -15
   

   /xmlrpc.php, /wp-login.php ve /?s= aramaları listenin başındaysa sorununuz ziyaretçi değil, saldırı ya da tarayıcı botudur.

3. Veritabanını küçültün. WordPress'te en sık şişen üç şey: wp_options tablosundaki autoload verisi, süresi geçmiş transient kayıtları ve revizyonlar.

   -- Otomatik yüklenen veri toplamı: 1 MB üstü ciddi yavaşlıktır
   SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb
   FROM wp_options WHERE autoload = 'yes';
   
   -- En şişkin 20 autoload kaydı
   SELECT option_name, ROUND(LENGTH(option_value)/1024, 1) AS kb
   FROM wp_options WHERE autoload = 'yes' ORDER BY LENGTH(option_value) DESC LIMIT 20;
   
   -- Süresi geçmiş transientler
   DELETE FROM wp_options WHERE option_name LIKE '\_transient\_timeout\_%' AND option_value < UNIX_TIMESTAMP();
   

4. Inode'u boşaltın. Dosya sayısı limiti dolduğunda e-posta bile teslim edilemez ve bu hiçbir zaman paket büyüterek çözülmesi gereken bir sorun değildir:

   # Hangi dizinde kaç dosya var
   for d in ~/*/; do echo -n "$d "; find "$d" -type f | wc -l; done | sort -k2 -rn | head
   
   # Eski önbellek dosyaları ve 90 günden eski yedekler
   find ~/public_html/wp-content/cache -type f -mtime +7 -delete
   find ~/backups -name "*.tar.gz" -mtime +90 -ls
   

5. PHP sürümünü ve OPcache'i kontrol edin. Eski bir PHP sürümünde çalışan site, güncel sürüme geçtiğinde aynı işi belirgin biçimde daha az CPU ile yapar. cPanel'de bu, MultiPHP Manager ekranından tek tıkla değişir; hangi eklentilerin açık olması gerektiğini cPanel PHP eklenti seçimi yazısında listeledik.

Yükseltme Kararı Kesinleştiyse: Aynı Pakette Kalmak mı, Sunucuya Geçmek mi#

Ölçümler yükseltmeyi işaret ediyorsa ikinci soru gelir: bir üst paylaşımlı pakete mi geçilir, yoksa sanal sunucuya mı? Bunun cevabı ziyaretçi sayısında değil, darboğazın türünde saklıdır.

• Darboğaz CPU ve trafikse ve site hâlâ standart bir WordPress/e-ticaret kurulumuysa, bir üst paylaşımlı paket genelde yeterlidir. Bu geçiş dakikalar sürer, IP değişmez, DNS'e dokunmazsınız.
• Darboğaz özel yazılım gereksinimiyse — kendi Node.js servisiniz, kendi cron aralığınız, özel bir PHP eklentisi, root gerektiren bir kurulum — paylaşımlı hostingte kaç kat yükseltirseniz yükseltin çözülmez. Orada sanal sunucu gerekir.
• Darboğaz "birden fazla siteyi tek yerden yönetmek" ise, seçim reseller ile VDS arasındadır; bu ikisini reseller hosting mi VDS mi yazısında karşılaştırdık.

Şu karar cümlesini kullanabilirsiniz: "Kaynak mı yetmiyor, yetki mi yetmiyor?" Kaynak yetmiyorsa paket büyütmek işe yarar. Yetki yetmiyorsa sunucu gerekir.

Kaç ziyaretçinin hangi ölçekte altyapı istediğine dair kaba bir çerçeveyi kaç ziyaretçi için hangi hosting paketi yazısında verdik; hangi paket ailesinin size uyduğunu tahmin etmek için hosting seçici aracını da kullanabilirsiniz.

Yükseltme Sırasında Nelere Dikkat Edilir#

Paket yükseltmesi teknik olarak basit bir işlemdir ama üç noktada insanlar veri ya da erişim kaybediyor:

1. Yükseltme öncesi tam yedek alın. Aynı sunucu içinde paket değişse bile, işlemin öncesinde alınmış bir yedeğin olması pazarlık konusu değildir. cPanel → Backup → "Download a Full Account Backup".
2. PHP sürümü ve eklenti seti taşınmayabilir. Yeni pakette varsayılan PHP sürümü farklıysa site açılmaz. Yükseltme sonrası ilk iş MultiPHP Manager'ı ve .htaccess içindeki AddHandler satırlarını kontrol etmektir.
3. Cron aralıkları sıfırlanabilir. Yeni pakette dakikalık cron'a izin verilmiyorsa, wp-cron alternatifiniz sessizce çalışmaz — siparişler e-postası gitmez, zamanlanmış yazı yayınlanmaz.

Yükseltme sonrası aynı ölçümleri 72 saat boyunca tekrarlayın. Fault sayısı sıfırlanmadıysa yanlış kaynağı büyütmüşsünüzdür ve tabloya dönüp doğru satırı bulmanız gerekir.

Yükseltmenin Çözmediği Üç Sorun#

Bunları baştan bilmek, boşa harcanmış bir yükseltmeyi engeller:

• Kötü yazılmış tek bir sorgu. Her sayfa yüklemesinde 40.000 satır tarayan bir eklenti, iki kat CPU'da iki kat hızlı çalışır ama hâlâ yavaştır. Çözüm indeks ve sorgu düzeltmesidir.
• Uzak servis beklemesi. Sayfa açılırken dış bir API'ye istek atılıyorsa ve o API 4 saniyede cevap veriyorsa, sunucunuz boşta bekler. Fault üretmez, sadece yavaştır. Bu sorunun tipik göstergesi curl error 28 satırlarıdır.
• Coğrafi mesafe. Ziyaretçiniz yurt dışındaysa gecikmenin bir kısmı fizikseldir; onu ancak CDN ya da doğru lokasyon çözer.

Bu üçünde de yükseltme faturayı büyütür, süreyi kısaltmaz.

Kararı Kayıt Altına Alın: Basit Bir İzleme Rutini#

Yükseltme tartışması her ay yeniden başlıyorsa, sebebi ölçümlerin hiçbir yerde tutulmamasıdır. Haftada bir, beş dakikanızı alacak şu rutini uygulayın ve sonucu bir tabloya yazın:

1. cPanel → Resource Usage → "Last 7 days" seçin; CPU, EP ve IOPS fault değerlerini not edin.
2. Disk Usage ve File Usage yüzdelerini not edin.
3. Ana sayfayı gizli sekmede açıp TTFB'yi ölçün, aynı ölçümü giriş yapmış hâlde tekrarlayın (ikinci değer önbelleğin devre dışı kaldığı gerçek maliyeti gösterir).
4. Analytics gerçek zamanlı ekranından haftanın zirve eşzamanlı kullanıcı sayısını yazın.

Dört hafta sonra elinizde bir eğilim olur. Fault sayısı sabitse ve trafik artmıyorsa sorun kapasitede değildir; fault sayısı trafikle birlikte doğrusal büyüyorsa gerçek bir kapasite duvarına yaklaşıyorsunuz demektir ve yükseltmeyi kriz anına bırakmadan planlayabilirsiniz. Sistem yöneticiliğinde en pahalı yükseltme, kampanya sabahı panikle yapılandır.

Ham logları düzenli okumak da bu rutinin parçasıdır. ~/access-logs/ altındaki günlük dosyayı haftada bir tarayıp en çok istek alan 15 URL'yi listelemek, çoğu zaman "trafiğim arttı" sandığınız şeyin aslında tek bir arama sayfasına gelen bot yükü olduğunu gösterir. Hata kayıtlarını da atlamayın: ~/logs/error_log içinde tekrar eden PHP Fatal error ya da mod_fcgid: read data timeout satırları, kaynak yetersizliğinden önce gelen erken uyarılardır.

Sıkça Sorulan Sorular#

Hosting paketi yükseltince sitem kapanır mı#

Hayır, aynı sunucu üzerinde yapılan paket yükseltmelerinde site kapanmaz; işlem çoğunlukla hesabınızın kaynak limitlerinin yeniden tanımlanmasından ibarettir ve saniyeler sürer. Kesinti riski, hesabınızın farklı bir sunucuya taşınmasını gerektiren yükseltmelerde ortaya çıkar. O durumda da veri kopyalandıktan sonra DNS yönlendirmesi değiştiği için kısa bir geçiş penceresi olur. Yükseltme öncesi tam yedek almanız ve işlemi düşük trafikli bir saate planlamanız bu riski pratikte ortadan kaldırır.

Kaynak limiti uyarısı aldım ama sitem normal açılıyor, yine de yükseltmeli miyim#

Hayır, tek başına bir uyarı yükseltme sebebi değildir. Resource Usage ekranındaki "faults" sütununa bakın: son 7 günde toplam birkaç ihlal, genelde bir yedekleme işi ya da bir bot dalgası anlamına gelir ve kalıcı değildir. Karar için ihlalin düzenli olup olmadığına bakın; her gün aynı saatlerde tekrar ediyorsa gerçek bir kapasite sorununuz vardır. Düzensiz ve seyrekse önce kaynağı bulun, çünkü çoğu zaman tek bir cron görevi ya da tek bir eklentidir.

Diskim doldu diye hosting paketimi büyütmem gerekir mi#

Genellikle hayır, çünkü paylaşımlı hesaplarda dolan diskin büyük kısmı gerçek içerik değil biriken çöp veridir. Önce eski yedekleri, önbellek klasörlerini, silinmemiş e-posta kutularını ve log dosyalarını kontrol edin; tipik bir hesapta bunlar toplam kullanımın önemli bir bölümünü tutar. Temizlik sonrası doluluk hâlâ %90'ın üstündeyse ve içerik gerçekten büyüyorsa yükseltme mantıklıdır. Ayrıca disk doluluğuyla inode doluluğunu karıştırmayın; ikisi ayrı sayaçtır ve ikincisi çok daha sık dolar.

Ziyaretçi sayım artınca hangi eşikte paket değiştirmeliyim#

Ziyaretçi sayısı tek başına eşik olamaz, çünkü belirleyici olan sayfa başına harcanan sunucu kaynağıdır. Statik bir kurumsal site günde on binlerce ziyaretçiyi paylaşımlı pakette sorunsuz karşılarken, önbelleksiz bir e-ticaret sitesi birkaç bin ziyaretçide limitlere çarpar. Doğru eşik, zirve saatteki eşzamanlı aktif kullanıcı ve o anki fault sayısıdır. Analytics'in gerçek zamanlı ekranında zirve değeriniz 60'ı aşıyor ve aynı saatlerde EP ihlali görüyorsanız yükseltme zamanı gelmiştir.

Üst pakete geçmek yerine doğrudan VDS almak mantıklı mı#

Sunucu üzerinde root yetkisi gerektiren bir ihtiyacınız varsa evet, yoksa hayır. VDS size kaynak garantisi ve tam kontrol verir ama işletim sistemi güncellemeleri, güvenlik duvarı, yedekleme ve e-posta yapılandırması sizin sorumluluğunuza geçer. Yalnızca "daha hızlı olsun" diye geçilen VDS, yönetilmediği için çoğu zaman eski paylaşımlı paketten daha yavaş ve daha risklidir. Kararı "kaynak mı yetmiyor, yetki mi yetmiyor" sorusuyla verin; yetki sorunu yoksa bir üst paylaşımlı paket daha az iş çıkarır.

Yükseltmeden sonra site hâlâ yavaşsa ne yapmalı#

Yanlış darboğazı büyütmüşsünüz demektir ve ölçüme geri dönmeniz gerekir. Önbellek kapalıyken TTFB'yi tekrar ölçün: değer hâlâ 900 ms üstündeyse sorun kaynak miktarında değil, kodun ya da veritabanının kendisindedir. Bu noktada bakılacak yerler sırasıyla wp_options autoload boyutu, dış API çağrıları ve indekssiz sorgulardır. Sunucu kaynağı artmasına rağmen değişmeyen bir süre, neredeyse her zaman uygulama katmanında bekleyen bir işlemi gösterir.

Kampanya dönemi için geçici olarak paket yükseltilebilir mi#

Evet, kampanya ve yoğun sezon öncesi geçici yükseltme yaygın ve mantıklı bir yaklaşımdır. Önemli olan yükseltmeyi kampanya başlamadan en az bir hafta önce yapıp yük testini o yapı üzerinde çalıştırmaktır; kampanya sabahı yapılan geçiş, sorunu çözmek yerine yeni değişken ekler. Kampanya bittikten sonra ölçümlere bakıp kalıcı ihtiyacınızı belirleyebilir, gerekiyorsa eski pakete dönebilirsiniz. Bu dönemde önbellek ve bot filtresi ayarlarının da yükseltmeyle birlikte gözden geçirilmesi gerekir.

Kapanış#

Hosting paketi yükseltme kararı bir his değil, bir ölçüm sonucudur. Elinizde CPU ve EP fault sayısı, önbelleksiz TTFB, disk ve inode doluluğu ile zirve eşzamanlı ziyaretçi varsa karar kendiliğinden çıkar: "önce optimize et" bölgesindeyseniz önbellek, bot filtresi, veritabanı temizliği ve PHP sürümü sırasıyla denenir; eşiklerin üstündeyseniz ve site zaten önbellekliyse yükseltme gerçekten gereklidir. Bu sırayı ters çevirmek, aynı duvara daha pahalı bir paketle çarpmak anlamına gelir. Yükseltmeden sonra da aynı metrikleri 72 saat izleyin — fault sıfırlanmadıysa yanlış kaynağı büyütmüşsünüzdür.

Ölçümleriniz gerçekten bir üst basamağı gösteriyorsa, aynı sunucu ailesi içinde büyümek en az sancılı yoldur: paylaşımlı hosting paketleri arasında geçiş kesintisiz ilerler, trafiği ve içerik hacmi büyüyen projeler için kurumsal hosting tarafında kaynaklar belirgin biçimde geniştir. İhtiyaç kaynaktan çok yetkiyse — kendi servisinizi çalıştırmak, kendi cron aralığınızı tanımlamak, root gerektiren bir kurulum yapmak istiyorsanız — doğru adres sanal sunucu tarafıdır. Sunucuyu almak isteyip güncelleme, güvenlik ve yedek yükünü üstlenmek istemiyorsanız sunucu yönetimi hizmeti bu işi devralır; siz yalnızca sitenizle ilgilenirsiniz.