Siteniz Belli Saatlerde Yavaşlıyorsa: Paylaşımlı Hosting ve VPS’te CPU, IO ve MySQL Darboğazı Teşhisi

Sitenizin gün içinde çoğu zaman akıcı çalışıp, belli saat aralıklarında anlamsız şekilde ağırlaştığını fark ettiğinizde, akla ilk gelen şey genelde “trafik arttı” olur. Oysa gerçek çoğu zaman daha karmaşıktır: CPU yükü, disk IO bekleme süreleri veya MySQL tarafındaki bir tıkanma aynı anda devreye giriyor olabilir. Özellikle paylaşımlı hosting ve VPS ortamlarında bu üç bileşen (CPU, IO ve MySQL) birbirini tetikleyerek, sadece belli saat dilimlerinde ortaya çıkan sinir bozucu bir yavaşlamaya yol açar.

Bu rehberde, DCHost altyapısında en sık gördüğümüz senaryolardan yola çıkarak, siteniz belli saatlerde yavaşlıyorsa bunun gerçekten CPU mu, disk IO mu, yoksa MySQL mi kaynaklı olduğunu nasıl anlayabileceğinizi adım adım anlatacağız. Hem paylaşımlı hosting kullanıcıları için cPanel ve istatistik ekranlarından, hem de VPS kullanıcıları için SSH üzerinden top, iostat ve MySQL log’larına kadar uzanan pratik bir kontrol listesi hazırladık. Amacımız, “Sunucu yavaş.” gibi genel bir hissi; ölçülebilir, tekrar edilebilir metriklere dönüştürüp, doğru çözüm yolunu netleştirmek.

Belli Saatlerde Yavaşlamanın Tipik Nedenleri

Neden Hep Aynı Saatler? Davranış ve Altyapı Çakışması

Önce şunu netleştirelim: Performans probleminizin belli saatlere yığılması genelde iki şeyin çakışmasıyla olur:

• Kullanıcı davranışı (iş çıkış saatinde trafik artışı, kampanya e-postalarında tıklamaların aynı zaman dilimine yığılması vb.)
• Sunucu tarafında planlı işler (cron job’lar, yedekleme, rapor üretimi, antivirüs taraması gibi periyodik görevler)

Bu iki dalga üst üste bindiğinde, normalde sorun yaratmayan bir sorgu, CPU veya IO sınırına çok yaklaşmış bir sunucuyu anında kilitleyebilir. Paylaşımlı hosting tarafında buna bir de aynı fiziksel sunucuyu kullanan diğer sitelerin yükü eklenir. VPS’te ise arka planda çalışan bakım script’leri, log döndürme (logrotate), veritabanı bakımları gibi görevler aynı etkiyi yaratabilir.

“Yavaş” Ne Demek? TTFB, Sayfa Yüklenme Süresi ve Zamanlama

Her yavaşlık aynı değil. Bazen tarayıcı adres çubuğunda uzun süre bekler, bazen HTML hızlı gelir ama görseller ve JS geç yüklenir. Bu rehberin odak noktası sunucu taraflı yavaşlık; yani özellikle TTFB (Time To First Byte) değerinin yükselmesi. Eğer TTFB sadece belli saatlerde ciddi oranda artıyorsa, bu çok büyük ihtimalle CPU/IO/MySQL tarafında bir darboğaz olduğuna işaret eder. Sunucu taraflı metrikleri okumayı bilmeden bunu anlamak zordur; bu yüzden önce doğru ölçümle başlamak gerekir.

Önce Ölçelim: Gerçekten Ne Zaman ve Ne Kadar Yavaş?

Dışarıdan Ölçüm: Aynı Saatleri Tekrar Test Etmek

İlk adım, hissiyatı veri ile doğrulamaktır. Bunun için sitenizin hızını günün farklı saatlerinde, özellikle de yavaşladığını düşündüğünüz zaman dilimlerinde test edin. Daha önce hazırladığımız Web sitenizin hızını doğru ölçmek için GTmetrix, PageSpeed Insights ve WebPageTest rehberi bu adımda size detaylı yol gösterebilir.

Önemli olan, bu testleri:

• En az bir “normal” saat diliminde (örneğin sabah 06:00)
• En az bir “sorunlu” saat diliminde (örneğin akşam 21:00)

tekrar ederek karşılaştırmaktır. Özellikle TTFB ve First Contentful Paint gibi metriklerin, sorunlu saat aralığında bariz şekilde arttığını görüyorsanız, odağı kesin olarak sunucu tarafına kaydırabilirsiniz.

Analytics ve Log’larla Trafik Dalgalanmasını Haritalamak

Sunucu metriklerine geçmeden önce, ziyaretçi tarafını da anlamak önemli:

• Google Analytics gibi araçlardan saat bazlı oturum sayısını inceleyin.
• Sunucunuzda erişiminiz varsa Apache/Nginx access log’larındaki istek sayısını saat bazlı gruplayın.

Eğer yavaşlama saatlerinde trafikte bariz bir pik yoksa, sorun büyük ihtimalle zamanlanmış işlemler veya altyapı bakımlarının yoğun saatlere denk gelmesidir. Trafik artışıyla beraber yavaşlama geliyorsa, o zaman gerçekten kapasiteye yaklaştığınız anlamına gelir.

Paylaşımlı Hosting’de CPU, IO ve MySQL Darboğazı Nasıl Teşhis Edilir?

cPanel Resource Usage Ekranını Doğru Okumak

Paylaşımlı hosting kullananların en büyük avantajlarından biri, CloudLinux benzeri izolasyon katmanları sayesinde, her hesabın CPU, IO ve RAM limitlerinin ayrı ayrı izlenebilmesidir. DCHost gibi sağlayıcılarda cPanel hesabınızda genellikle “Resource Usage” veya benzeri bir bölüm görürsünüz.

Bu ekrandaki grafik ve tablolarda özellikle şunlara bakın:

• CPU Usage: Yüzde kaç kullanıldığını ve limit çizgisine ne kadar sık değdiğini inceleyin.
• IO Usage: Disk okuma/yazma (MB/s veya KB/s) değerlerinin limitlere çarpıp çarpmadığını kontrol edin.
• Entry Processes (EP): Aynı anda çalışan PHP işlemi / istek sayısı.
• Faults / Limit Hits: Kaynak limitine çarpıldığı anlar.

Bu metriklerin detaylı yorumlanması için hazırladığımız cPanel’de CPU, IO, EP, RAM limitleri ve Resource Limit Reached hatası rehberini mutlaka incelemenizi öneririz.

CPU Limiti Doluyorsa: Hangi Saatte, Ne Kadar Süreyle?

Resource Usage grafiğinde CPU kullanımının belli saat dilimlerinde yüzde 100’e yaslanması, doğrudan CPU darboğazına işarettir. Ancak burada iki kritik soru vardır:

• CPU limiti sadece 5–10 dakikalık kısa patlamalarda mı doluyor, yoksa 1–2 saat boyunca mı tavan yapıyor?
• Bu patlamalar her gün aynı saatte mi tekrarlanıyor?

Kısa patlamalar genelde:

• WordPress veya başka bir CMS’in yoğun cron işleri (otomatik yedek, e-posta bülteni gönderimi, rapor oluşturma),
• Yoğun bot taramaları (özellikle arama motoru dışındaki agresif botlar)

gibi sebeplerle tetiklenir. Saatler süren CPU tavanları ise çoğunlukla:

• Ağır sorgularla çalışan e-ticaret / raporlama sayfaları,
• Eksik indeksli MySQL tabloları,
• Cache (önbellek) mekanizması düzgün kurulmamış WordPress / WooCommerce siteleri

ile ilgilidir. CPU limiti dolduğunda sunucu, yeni gelen PHP işlemlerini kısar; bu da son kullanıcı tarafında “sayfa dönüyor ama açılmıyor” hissi olarak yansır.

Disk IO Limiti Doluyorsa: iowait’in Paylaşımlı Versiyonu

Paylaşımlı hostingde IO limiti, hesabınızın saniyede ne kadar veri okuyup yazabileceğini sınırlar. Belli saatlerde IO kullanım grafiğinin sürekli limit çizgisine çarpması, şu tip işlerin o saatlerde yoğunlaştığını gösterir:

• Büyük yedeklerin alınması veya arşivlenmesi (özellikle eklenti bazlı backup çözümleri),
• Çok sayıda resim / video yükleme veya toplu import işlemleri,
• MySQL’in diskle çok konuşmak zorunda kaldığı, indekslenmemiş ağır sorgular.

IO limitine çarptığınızda, CPU boşta görünse bile sayfalar yine de geç açılır. Çünkü PHP kodu ve MySQL, diskten veri okuyup yazmak için bekler; bu bekleme süresi de TTFB’ye doğrudan yansır.

MySQL Darboğazını Paylaşımlı Ortamda Anlamak

Paylaşımlı hostingde doğrudan MySQL konfigürasyonuna veya slow query log’larına erişiminiz olmayabilir. Yine de birkaç sinyalden MySQL kaynaklı darboğazı anlayabilirsiniz:

• Sadece veritabanı ağırlıklı sayfalar (kategori listeleri, filtreli arama, rapor ekranları) yavaşlıyorsa,
• Statik sayfalar (Hakkımızda, KVKK metni gibi) aynı saatlerde bile hızlı açılıyorsa,
• WordPress admin panelinde ürün/sipariş listeleri çok geç geliyorsa,

büyük olasılıkla MySQL tarafında bir tıkanma söz konusudur. Bu durumda yapılabilecek en etkili şeyler:

• Yoğun sorgu üreten eklentileri azaltmak veya değiştirmek,
• WooCommerce gibi sistemlerde ürün ve sipariş tablosu indekslerini kontrol etmek,
• Query Monitor, Debug Bar gibi araçlarla en yavaş sorguları tespit etmek

olur. Daha teknik optimizasyonlar için WooCommerce için MySQL/InnoDB tuning kontrol listesi yazımızdan da yararlanabilirsiniz.

VPS Üzerinde Detaylı Teşhis: top, iostat ve MySQL Log’ları

İlk Bakış: load average, CPU ve iowait

VPS kullanıyorsanız işiniz hem biraz daha zor hem de çok daha esnek. Çünkü artık tüm sunucu sizin; dolayısıyla hem problemin hem de çözümün sahibi sizsiniz. İlk bakış için şu komutlar yeterli olur:

• top veya htop: Anlık CPU, RAM ve proses dağılımını görmek için.
• uptime: Load average değerlerinin özellikle sorunlu saatlerde ne kadar arttığını izlemek için.
• vmstat 1: CPU bekleme (iowait) oranlarını takip etmek için.

Özellikle iowait değeri (çoğu araçta wa veya %wa olarak geçer) önemlidir. CPU kullanımınız görece düşük görünse bile iowait %20–30 ve üzerine çıkıyorsa, asıl darboğaz disktedir.

Disk IO’yu Yakalamak: iostat -x ve sar

Disk IO tarafını daha net görmek için şu komutları kullanabilirsiniz:

• iostat -x 1: Her saniye disk başına kullanım, bekleme süresi (await), kuyruk uzunluğu (avgqu-sz) vb.
• sar -d 1: Tarihsel IO istatistiklerini izlemek için (sysstat paketine ihtiyaç duyar).

Özellikle şunlara dikkat edin:

• await değerinin onlarca milisaniyenin üzerine çıkması,
• svctm ile await arasındaki uçurum (disk hizmet süresine göre çok yüksek bekleme),
• util değerinin uzun süre %90–100 bandında kalması.

Bu göstergeler yüksek ihtimalle VPS’in disk tarafında yoğun IO baskısı altında olduğunu ve bu yüzden PHP/MySQL işlemlerinin beklediğini gösterir. Özellikle yoğun saatlere denk gelen yedekleme, log sıkıştırma, büyük rapor export’ları suçlu olabilir.

MySQL Slow Query Log ve SHOW PROCESSLIST ile Tanı Koymak

VPS’in en büyük avantajı, MySQL’inizi özgürce izleyebilmenizdir. Belli saatlerde yavaşlama yaşıyorsanız:

1. Slow query log’u aktif edin (my.cnf veya mysqld.cnf içinde slow_query_log = 1, long_query_time vb.).
2. Yavaşladığını bildiğiniz saatlerden önce slow log’u temizleyin.
3. Sorunlu saat sona erdiğinde slow log’u analiz edin.

Ek olarak, yavaşlama anında SHOW PROCESSLISTG; çıktısını alarak:

• Hangi sorguların uzun süredir çalıştığını,
• Hangi tablolarda kilitlenme (Locked) olduğunu,
• Hangi kullanıcı / uygulamanın (örneğin belirli bir cron job) bu sorguları tetiklediğini

gözlemleyebilirsiniz. Bu çıktı, CPU yüksekliğiyle eş zamanlıysa, darboğaz çoğunlukla ağır sorgular + yetersiz indeksleme kombinasyonudur.

Uygulama Katmanı: PHP-FPM, Worker Sayısı ve Kuyruklar

VPS’te CPU darboğazı çoğu zaman sadece MySQL’den ibaret değildir. PHP-FPM veya benzeri PHP işlem yöneticiniz yanlış ayarlıysa, yoğun saatlerde:

• Yetersiz worker sayısı yüzünden istekler kuyruğa girer,
• Aşırı worker yüzünden CPU tavan yapar ve her şey yavaşlar.

WordPress ve WooCommerce gibi PHP uygulamaları için PHP-FPM havuz ayarlarını doğru yapmak, CPU yükünü dengeler ve yoğun saatlerde daha öngörülebilir sonuç verir. Aynı zamanda Redis/Memcached nesne önbelleği, OPcache ve tam sayfa cache yapılarını doğru kurmak da CPU ve MySQL yükünü ciddi şekilde hafifletir.

VPS’te İzleme ve Alarm Kurmak: Sorun Çıkmadan Fark Etmek

Siteniz belli saatlerde yavaşlıyorsa, bunu her seferinde manuel testlerle keşfetmek yerine, otomatik izleme sistemleri kurmak çok daha sağlıklı olur. Özellikle:

• CPU ve load average için eşik değerler belirlemek,
• Disk IO (iowait) için alarm kurmak,
• MySQL bağlantı sayısı ve sorgu süreleri için metrik toplamak

büyük kolaylık sağlar. Bu konuda başlangıç yapmak istiyorsanız, VPS izleme ve uyarı kurulum rehberimizde Prometheus, Grafana ve Node Exporter ile temel bir monitoring altyapısını nasıl ayağa kaldırabileceğinizi adım adım anlattık.

Darboğaza Göre Çözüm Stratejileri

CPU Darboğazı İçin Uygulama ve Sunucu Taraflı Çözümler

CPU limitine düzenli olarak çarpıyorsanız, çözüm genelde iki koldan ilerler:

• Uygulama tarafı:
  • Gereksiz veya ağır eklentileri devre dışı bırakmak,
  • WordPress/WooCommerce için tam sayfa önbellek (LiteSpeed Cache, Nginx FastCGI cache vb.) kullanmak,
  • Yoğun cron işlerini gece geç saatlere veya trafiksiz zamanlara kaydırmak,
  • Arama, raporlama gibi CPU-yoğun işlemleri mümkünse ayrı iş kuyruğu sistemlerine taşımak.
• Sunucu tarafı:
  • PHP-FPM worker ve pm.max_children ayarlarını trafiğe göre yeniden hesaplamak,
  • OPcache ayarlarını optimize ederek PHP kodunu daha az derler hale getirmek,
  • MySQL için connection limit ve buffer ayarlarını gözden geçirmek.

CPU darboğazının TTFB’ye yansımasını anlamak için yüksek TTFB sorununu çözme rehberimizde WordPress ve PHP siteler için tipik CPU kaynaklı senaryoları ayrıntılı şekilde anlattık.

Disk IO Darboğazı İçin Yedekleme, Log ve Sorgu Stratejileri

IO darboğazı genelde “arka plan” işlerinin hatalı zamanlamasından kaynaklanır. Aşağıdakileri kontrol edin:

• Yedekleme saatleri: Günlük/haftalık backup’lar yoğun trafik saatine denk gelmemeli. Paylaşımlı hostingde yedek eklentilerinin planlarını, VPS’te ise cron ile çalışan backup script’lerini gece geç saatlere alın.
• Log büyümesi: Uygulama log’ları veya access log’larınız çok hızlı büyüyorsa, log döndürme (logrotate) ayarlarını sıklaştırın ve sıkıştırmayı yoğun olmayan saatlere kaydırın.
• MySQL veritabanı yapısı: Büyük tablolar üzerinde indekslenmemiş sorgular, IO tarafında ciddi yük yaratır. Özellikle EXPLAIN ile sorgularınızın index kullanıp kullanmadığını kontrol edin.

Disk tarafı sınırlı olan VPS’lerde, medya dosyalarını CDN veya obje depolama (S3 benzeri) çözümlerine taşımak da IO yükünü ve disk kapasitesi baskısını ciddi şekilde azaltır.

MySQL Darboğazı İçin Şema, İndeks ve Sorgu Optimizasyonu

MySQL darboğazı çoğu zaman donanımdan çok yazılımsal tasarım problemidir. Dikkat edilmesi gereken başlıklar:

• İndeksler: Özellikle WHERE, ORDER BY ve JOIN kullanılan kolonlarda uygun indeksler yoksa, MySQL tam tablo taraması (full table scan) yapar ve bu büyük tablolarda felaket sonuçlar doğurur.
• Yinelenen sorgular: Her sayfa yüklenişinde yüzlerce kez tekrar eden benzer sorgular, nesne önbelleği (Redis/Memcached) ile ciddi ölçüde azaltılabilir.
• Bağlantı yönetimi: PHP tarafında her istek için yeni bağlantı açmak yerine, bağlantı havuzu (pooling) stratejileriyle çalışmak daha verimlidir (özellikle yoğun API veya arka plan işlerinde).
• InnoDB ayarları: innodb_buffer_pool_size, innodb_log_file_size gibi temel parametrelerin sunucu belleğine göre doğru ayarlanması, disk IO’yu ve sorgu gecikmesini hissedilir seviyede düşürür.

Bu noktada, WooCommerce odaklı ama genel MySQL ince ayar prensiplerini de anlatan MySQL/InnoDB tuning kontrol listesi rehberimiz size derinlemesine bir yol haritası sağlayacaktır.

Paylaşımlı Hosting mi, VPS mi? Ne Zaman Yükseltme Zamanı Gelmiş Demektir?

Optimizasyonla Çözülebilen Senaryolar

Her yavaşlama paketi yükseltmeyi gerektirmez. Şu durumlarda genellikle doğru optimizasyonlarla sorun büyük ölçüde çözülür:

• CPU/IO limitine sadece kampanya veya kampanya benzeri kısa süreli trafik patlamalarında çarpıyorsanız,
• Resource Usage grafiğinde genel eğri düşük, ancak belirli cron işlerinin çalıştığı dakikalarda sivri uçlar görüyorsanız,
• Slow query log’da birkaç bariz problemli sorguyu tespit edip düzelttiğinizde tablo hızla iyileşiyorsa.

Bu senaryolarda, kod ve veritabanı optimizasyonu, doğru cache kullanımı ve cron zamanlamasını düzeltmek çoğu zaman yeterlidir.

Sürekli Tavan Vuran Kaynaklar: Paketi Büyütme Zamanı

Aşağıdaki işaretler ise genellikle artık yalnızca optimizasyonla yetinemeyeceğiniz anlamına gelir:

• Paylaşımlı hostingde CPU ve IO grafikleri, günün yoğun saatlerinde her gün %100’e yaslanıyorsa,
• VPS’te load average değeriniz çekirdek sayısının 2–3 katına düzenli olarak çıkıyorsa,
• Slow query optimizasyonlarına rağmen, artan trafikle birlikte dar boğaz tekrar oluşuyorsa.

Bu durumda, DCHost tarafında paylaşımlı hostingden NVMe diskli VPS’e, oradan da gerektiğinde dedicated sunucu veya colocation çözümlerine kadar esnek bir yükseltme yolu bulunuyor. Yükseltme sürecini planlarken, saat bazlı trafik ve kaynak kullanım grafiğiniz, hangi adımın sizin için en mantıklı olduğuna karar vermede kritik rol oynar.

Sonuç: Yavaşlığı Hissetmekten, Ölçüp Yönetmeye Geçmek

Sitenizin belli saatlerde yavaşlaması, “Sunucu kaldırmıyor galiba.” diye genelleyip geçilecek bir durum değil. Bu rehberde gördüğünüz gibi, paylaşımlı hosting ve VPS ortamlarında CPU, IO ve MySQL darboğazlarını ayırt etmek için elinizde pek çok somut araç var: cPanel Resource Usage grafikleri, top/htop, iostat, slow query log, access log’lar ve harici hız testleri… Bunları birlikte okuduğunuzda, yavaşlamanın tam hangi dakikada, hangi bileşen yüzünden yaşandığını netleştirebiliyorsunuz.

Buradan sonraki adım, sorunlu saatlerdeki yükü dağıtmak, sorgularınızı ve cron işlerinizi optimize etmek ve gerektiğinde daha güçlü bir altyapıya geçmek. DCHost ekibi olarak, ister paylaşımlı hosting ister VPS veya dedicated sunucu kullanın, bu tür saat bazlı performans problemlerini birlikte analiz etmeye ve en uygun çözümü planlamaya alışığız. Mevcut hesabınızda kaynak grafiklerine bakarak nerede takıldığınızı göremiyorsanız veya bu rehberdeki adımları uygulayıp hâlâ kararsızsanız, destek talebi açarak altyapınızı birlikte gözden geçirebilir, size özel bir optimizasyon ve ölçeklendirme planı çıkarabiliriz.