Sunucunuzun teknik özellikleri kağıt üzerinde yeterli görünüyor ama siteniz yavaş. Bu, VDS sunucu sahiplerinin en sık yaşadığı durumdur ve ilk refleks genellikle yanlıştır: daha fazla RAM veya çekirdek satın almak. Oysa yavaşlığın nedeni çoğu zaman kapasite eksikliği değil, yanlış yapılandırılmış bir bileşendir. Kaynak eklemek bu durumda parayı harcar, sorunu çözmez.
Bu rehber, önce nerede tıkandığını bulmayı, sonra ona göre müdahale etmeyi anlatıyor. Sıra önemlidir: ölçmeden optimize etmek, karanlıkta tahmin yürütmektir.
Her Yavaşlık Dört Yerden Birinde Başlar
Bir sunucuda performans sorunu yalnızca dört kaynakta ortaya çıkabilir: işlemci, bellek, disk ve ağ. Teşhis işini kolaylaştıran şey budur — hangisinin dolduğunu bulduğunuzda çözüm kümesi büyük ölçüde daralır.
- CPU darboğazı: Yük ortalaması çekirdek sayısını sürekli aşıyor, işlemci kullanımı uzun süre yüksek kalıyor. Genellikle optimize edilmemiş kod, önbelleksiz sayfa üretimi veya kontrolsüz bot trafiği kaynaklıdır.
- Bellek darboğazı: Boş bellek sürekli düşük, sistem takas alanını (swap) aktif kullanıyor. Takas kullanımı başladığı andan itibaren performans belirgin biçimde çöker, çünkü bellek işi diske devredilmiştir.
- Disk darboğazı: İşlemci boş ama sistem yavaş. İşlemlerin disk beklerken harcadığı süre (I/O wait) yüksektir. Sebebi genellikle veritabanı sorguları veya aşırı log yazımıdır.
- Ağ darboğazı: Sunucu içinde her şey hızlı ama sayfa yavaş açılıyor. Bant genişliği doluluğu, uzak bir API'ye yapılan yavaş çağrılar veya optimize edilmemiş büyük dosyalar suçludur.
Teşhis: Beş Dakikada Suçluyu Bulmak
Ölçüm yaparken tek bir anlık görüntüye bakmayın. Yavaşlığın ne zaman ortaya çıktığı, ne olduğu kadar önemlidir.
Yükün Zaman İçindeki Dağılımını Görün
Sorun her zaman mı var, yoksa günün belirli saatlerinde mi? Sürekli yüksek yük kapasite sorununa; belirli saatlerde sıçrayan yük ise trafik dalgalanmasına veya zamanlanmış bir göreve işaret eder. Gece yarısı düzenli olarak yavaşlayan bir sunucuda genellikle suçlu, o saatte çalışan bir yedekleme veya toplu işlem görevidir.
En Çok Kaynak Tüketen İşlemi Bulun
İşlem listesini CPU ve bellek tüketimine göre sıralayın. Beklediğiniz servisin (web sunucusu, veritabanı) en tepede olması normaldir; beklemediğiniz bir işlemin orada olması bulgudur. Tanımadığınız bir işlem yüksek CPU tüketiyorsa, bu bir performans sorunu değil güvenlik olayı olabilir.
Yavaş Veritabanı Sorgularını Kayda Alın
Dinamik sitelerde performans sorunlarının büyük bölümü veritabanı kaynaklıdır. Yavaş sorgu kaydını (slow query log) açın ve birkaç saat çalıştırın. Genellikle karşınıza çıkan tablo şudur: yüzlerce sorgunun içinde, indeksi eksik olduğu için tabloyu baştan sona tarayan iki üç sorgu, toplam sürenin yarısını yiyor. Bir VDS ortamında bu sorgulara indeks eklemek, çoğu zaman donanım yükseltmesinden fazla kazanç sağlar.
Trafiğin Gerçek Kaynağını Ayırt Edin
Erişim loglarını istek sayısına göre gruplayın. Yüksek yükün kaynağı gerçek ziyaretçiler mi, arama motoru botları mı, yoksa agresif tarama yapan kimliği belirsiz istemciler mi? Üçüncü grubun payı beklenenden yüksek çıkarsa, çözüm optimizasyon değil filtrelemedir.
Sırasıyla Uygulanacak Optimizasyonlar
Aşağıdaki liste kazanç/emek oranına göre sıralanmıştır. Yukarıdan başlayın; alttaki maddelere geçmeden önce üsttekilerin etkisini ölçün.
1. Sayfa Önbelleği Kurun
Her istekte sıfırdan üretilen bir sayfa, sunucunuzun en pahalı işidir. İçeriği her ziyaretçi için değişmeyen sayfaları önbelleğe alın. Blog, kurumsal site ve kategori sayfalarında bu tek adım sunucu yükünü büyük oranda düşürür. Etkisi genellikle bir donanım yükseltmesinden fazladır ve maliyeti yoktur.
2. Nesne Önbelleği Ekleyin
Tam sayfa önbelleği kullanılamayan yerlerde (giriş yapmış kullanıcılar, sepet, panel) tekrar eden veritabanı sorgularının sonucunu bellekte tutan bir nesne önbelleği kurun. Aynı sorgunun her istekte tekrar çalışmasını engeller.
3. Web Sunucusu İşçi Sayısını Doğru Hesaplayın
Varsayılan yapılandırmalar genel kullanım için ayarlanmıştır. İşçi (worker) sayısı çok düşükse istekler kuyrukta bekler; çok yüksekse bellek tükenir ve sistem takas alanına düşer. Doğru sayı, tek bir işçinin ortalama bellek tüketimi ile sunucunun kullanılabilir belleğinden hesaplanır. Bu hesabı yapmak beş dakika sürer ve yanlış ayarlanmış bir sunucuda etkisi çok belirgindir.
4. Veritabanı Bellek Havuzunu Büyütün
Paket yöneticisinden kurulan veritabanı sunucuları, küçük makinelerde çalışacak varsayılanlarla gelir. Sunucunuzun gerçek belleğine göre ayarlanmamış bir bellek havuzu, verinin bellekte tutulabilecekken diskten okunmasına yol açar. Disk okuması bellek okumasından kat kat yavaştır; ayarı düzeltmek disk baskısını doğrudan azaltır.
5. Sıkıştırma ve Tarayıcı Önbelleğini Açın
Metin tabanlı kaynakları (HTML, CSS, JavaScript) sıkıştırarak gönderin ve statik dosyalara uzun süreli tarayıcı önbelleği tanımlayın. Bu, sunucu yükünü ve bant genişliği kullanımını aynı anda düşürür. Sunucu tarafında maliyeti yok denecek kadar azdır.
6. Görselleri Modern Biçimlere Çevirin
Çoğu sitede toplam sayfa ağırlığının büyük bölümü görsellerdir. Modern görüntü biçimleri, görünür kalite kaybı olmadan belirgin biçimde küçük dosyalar üretir. Ayrıca ekranda hemen görünmeyen görselleri geciktirmeli yükleyin.
7. Log Yazımını Disipline Edin
Hata ayıklama seviyesinde açık bırakılmış bir log, sürekli disk yazımı üretir ve I/O darboğazının sessiz nedenidir. Üretim ortamında log seviyesini uygun düzeye çekin ve log döndürmeyi tüm uygulama logları için yapılandırın.
Kaynak Eklemek Gerçekten Gerektiğinde
Yukarıdaki adımları uyguladıktan sonra hâlâ darboğaz varsa, artık büyütme kararı verilebilir. Hangi kaynağı büyüteceğinizi teşhis sonucu söyler:
| Bulgu | Doğru müdahale |
|---|---|
| Yük ortalaması sürekli çekirdek sayısının üzerinde | CPU çekirdeği ekle |
| Takas alanı sürekli kullanımda | RAM ekle (takas alanı çözüm değil, semptomdur) |
| I/O bekleme süresi yüksek, CPU boş | Daha hızlı disk (NVMe) veya sorgu optimizasyonu |
| Bant genişliği tavana vuruyor | Statik içeriği dağıtım ağına taşı |
| Yük yalnızca kampanya saatlerinde | Kalıcı büyütme yerine geçici kapasite artırımı |
Sonuç
Performans işi bir tahmin oyunu değil, ölçüm işidir. Doğru yapılandırılmış bir VDS sunucu, aynı donanımla yapılandırılmamış bir sunucudan kat kat fazla iş çıkarır. Kaynak eklemeyi son adım olarak saklayın: önce ölçün, önbelleği kurun, sorguları düzeltin, işçi sayısını hesaplayın. Bu dört adımdan sonra hâlâ darboğaz varsa, o zaman büyütme kararı gerçekten gerekçelidir ve hangi kaynağı büyüteceğinizi de artık biliyorsunuzdur.
Sıkça Sorulan Sorular (SSS)
RAM eklemek her zaman performansı artırır mı?
Hayır. Bellek darboğazı yoksa eklenen RAM boş durur ve hiçbir kazanç sağlamaz. RAM eklemek yalnızca sistem takas alanını aktif kullanıyorsa veya servisler bellek yetersizliğinden kapanıyorsa anlamlıdır. Darboğaz diskteyse RAM eklemek sorunu çözmez.
Önbellek kullanmak içeriğimin güncel görünmemesine yol açar mı?
Doğru yapılandırıldığında hayır. İçerik güncellendiğinde ilgili önbelleğin temizlenmesi (invalidation) yapılandırmanın parçasıdır. Sorun genellikle önbelleğin kendisinden değil, temizleme kuralının kurulmamasından çıkar. Sepet ve panel gibi kullanıcıya özel sayfalar zaten önbelleğe alınmamalıdır.
Yük ortalaması kaç olmalı?
Tek bir doğru sayı yoktur; ölçüt çekirdek sayısıdır. Dört çekirdekli bir sunucuda 4'e yakın yük ortalaması tam kapasite, sürekli 8 civarında bir değer ise ciddi darboğaz anlamına gelir. Kısa süreli sıçramalar normaldir; kalıcı olarak çekirdek sayısının üzerinde seyreden bir değer müdahale gerektirir.
Dağıtım ağı (CDN) kullanmak sunucu optimizasyonunun yerine geçer mi?
Hayır, tamamlayıcısıdır. Dağıtım ağı statik dosyaları üstlenerek bant genişliği ve istek yükünü azaltır, ancak dinamik sayfa üretimi ve veritabanı sorguları hâlâ sizin sunucunuzda çalışır. Veritabanı kaynaklı bir yavaşlığı dağıtım ağı çözmez.
