Siteniz Belli Saatlerde Yavaşlıyorsa: CPU, IO ve MySQL

Siteniz günün çoğunda hızlıyken belirli saatlerde yavaşlıyorsa, önce olay zamanını ve etkilenen işlemi kaydedin. Trafik artışı, zamanlanmış işler, CPU veya disk sınırları, MySQL beklemeleri ve dış servis gecikmeleri araştırılabilecek nedenlerdir. Paylaşımlı hosting ve VPS ortamlarında aynı belirti farklı katmanlardan kaynaklanabilir. Bu rehber, zaman çizelgesini kaynak ve uygulama verileriyle eşleştirmenize yardımcı olur.

Bu rehberde, 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ı

Performans probleminizin belli saatlere yığılmasında, tek başına veya birlikte etkili olabilecek iki etken şunlardır:

• 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 sunucuda yanıt sürelerini belirgin biçimde uzatabilir. Paylaşımlı hosting tarafında aynı fiziksel sunucuyu kullanan diğer sitelerin yükü de performansa etki edebilir. 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 rehber, özellikle TTFB (Time To First Byte) değeri yükseldiğinde olası sunucu taraflı nedenleri araştırmaya odaklanır. Eğer TTFB sadece belli saatlerde ciddi oranda artıyorsa, CPU/IO/MySQL darboğazı olasılıklardan biridir; ancak ağ gecikmesi, CDN/önbellek davranışı veya uygulamanın dış servisleri beklemesi de araştırılmalıdır. TTFB tek başına darboğazın yerini göstermez. 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. Aynı URL, test konumu, cihaz/ağ profili ve benzer önbellek koşullarıyla ölçüm yapın. TTFB artışını aynı saatlerdeki sunucu metrikleriyle karşılaştırın. First Contentful Paint artışı ise sunucu gecikmesinin yanı sıra istemci tarafındaki kaynak yükleme ve işleme sürelerinden de etkilenebilir; tek başına sunucu darboğazını kanıtlamaz.

Analytics ve Log’larla Trafik Dalgalanmasını Haritalamak

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

• Analytics araçlarında saat bazlı oturumları inceleyin; botlar, engellenen izleme ve önbellek nedeniyle bu sayı sunucu istekleriyle aynı değildir.
• Erişiminiz varsa Apache/Nginx kayıtlarında istek yolu, durum kodu, süre ve hacmi aynı zaman aralığında karşılaştırın.
• Tarayıcı testi, panel, işletim sistemi ve veri tabanı kayıtlarının saat dilimini eşitleyin. Normal ve sorunlu dönemin iş yükünü birlikte kaydedin.

Eğer yavaşlama saatlerinde trafikte bariz bir pik yoksa, zamanlanmış işlemleri ve altyapı bakımlarını kontrol edin; bunlar tek olası neden değildir. İstek sayısı değişmeden isteklerin işlem maliyeti de artabilir. Trafik artışıyla beraber yavaşlama geliyorsa, kapasiteye yaklaştığınız düşünülebilir; bunu aynı saatlerdeki kaynak kullanımı ve limit kayıtlarıyla doğrulayın.

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

cPanel Resource Usage Ekranını Doğru Okumak

Planınız CloudLinux kaynak izleme sunuyorsa, cPanel’deki Resource Usage görünümünü kullanabilirsiniz; cPanel tek başına bu limitlerin uygulayıcısı değildir. Görünen sayaçları, hesabın limitini ve gerçek web sunucusu/PHP handler bilgisini sağlayıcıdan doğrulayın. Aynı hesaptaki birden fazla site veya arka plan görevi ortak LVE limitlerini kullanabilir.

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

• CPU / SPEED: Kullanımı kendi limit çizgisiyle karşılaştırın. CloudLinux SPEED yüzdesinde %100 bir çekirdek kapasitesidir; panelin paket limitine göre normalize ettiği %100 farklı bir gösterim olabilir.
• IO ve IOPS: Disk veri hızı ile saniyedeki işlem sayısı farklıdır. Birimi ve her sınırı ayrı okuyun; bu değerler iowait veya depolama kapasitesi değildir.
• Entry Processes (EP): LVE’ye girişleri sayar; LVE içinde oluşturulan her alt süreci veya ziyaretçiyi saymaz. Apache mod_hostinglimits ile CGI/PHP isteği için giriş reddedildiğinde 508 görülebilir. LiteSpeed sayımı farklıdır: workgroup düzeninde lsphp master alt süreç oluştururken EP her çocuk için artmaz. EP, PHP worker toplamı veya otomatik kuyruk garantisi değildir.
• NPROC: LVE içindeki süreç ve thread toplamını sınırlar. Sınır dolduğunda yeni süreç oluşturulamaz; 500/503 oluşabilir. PHP-FPM havuz sınırıyla aynı sayaç değildir.
• PMEM: Hesabın fiziksel bellek kullanımını izleyin. Disk önbelleği geri kazanımı yetmezse süreçler sonlandırılabilir ve fPMEM artabilir; PHP memory_limit ayrı bir sınırdır.
• Fault / limit kayıtları: Kullanım, limit, mümkünse maksimum değer ve fault sayısını olay zamanı ve uygulama hatasıyla eşleştirin. Tek bir HTTP kodu kök nedeni göstermez.

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 hesabınıza tanımlı limit çizgisine dayanması, CPU kısıtlaması olasılığını araştırmak için bir işarettir. Yüzde 100’ü her plan için limit kabul etmeyin; grafiğin ölçeğini ve tanımlı sınırı kontrol edin. Burada iki kritik soru vardır:

• Kullanım sınıra kısa aralıklarla mı ulaşıyor, yoksa uzun süre sınırda mı kalıyor? Beş dakika veya iki saat gibi süreler yalnız gözlem örneğidir; kısa bir hata da ödeme işlemini etkileyebilir.
• Bu aralıklar aynı görev, istek yolu veya trafik örüntüsüyle birlikte mi tekrarlanıyor?

Kısa patlamalar:

• 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 tetiklenebilir. Saatler süren CPU tavanlarında da incelenebilecek olası nedenler:

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

olabilir. CPU limitine bağlı kısıtlama, isteklerin tamamlanmasını geciktirerek son kullanıcıya “sayfa dönüyor ama açılmıyor” hissi verebilir. Bunun yalnızca yeni gelen PHP işlemleriyle sınırlı olduğunu varsaymayın.

Disk IO Limiti Doluyorsa: Hesap Bazlı Okuma/Yazma Sınırı

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ı durumunda, şu tip işlerin o saatlerde çalışıp çalışmadığını araştırın:

• 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,
• Disk erişimi yoğun veritabanı sorguları; bu yükün hesap IO grafiğine dahil edilip edilmediği ayrıca doğrulanmalıdır.

IO limitine çarptığınızda, CPU boşta görünse bile sayfalar geç açılabilir. Yanıtı üretmek için gereken disk işlemleri bu limite takılıyorsa, oluşan bekleme TTFB’yi artırabilir. Hesabın IO limitinin MySQL işlemlerini de kapsadığını ayrıca doğrulamadan varsaymayın.

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ç sinyal, MySQL kaynaklı darboğaz olasılığını araştırmanıza yardımcı olabilir:

• Sadece veritabanı ağırlıklı sayfalar (kategori listeleri, filtreli arama, rapor ekranları) yavaşlıyorsa,
• Doğrudan statik HTML olarak veya tam sayfa önbelleğinden sunulan sayfalar aynı saatlerde hızlı açılıyorsa (Hakkımızda veya KVKK sayfaları, içerikleri değişmese de CMS tarafından dinamik üretilebilir),
• WordPress admin panelinde ürün/sipariş listeleri çok geç geliyorsa,

MySQL tarafını incelemek anlamlıdır; ancak aynı belirtiler PHP kodundan veya dış servis beklemelerinden de kaynaklanabilir. Sorgu süreleriyle doğrulama yapın. MySQL yükü doğrulanırsa değerlendirilebilecek adımlar:

• Sorgu sürelerini ve çağrı yerini Query Monitor gibi uygulama araçlarıyla inceleyin; ölçüm yükünü ve görünür hassas veriyi sınırlayın.
• Şüpheli eklentiyi üretim kopyasında temsilî işlemlerle karşılaştırın. Ödeme, güvenlik ve veri bağımlılıklarını test etmeden topluca kapatmayın.
• WooCommerce ürün ve sipariş sorgularının planını, mevcut indekslerini ve yazma maliyetini değerlendirin; tablo adı veya büyüklüğü tek başına indeks ekleme gerekçesi değildir.

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 üzerinde gerekli yönetim yetkileriniz varsa, sanal sunucunun süreçlerini ve kaynak kullanımını daha ayrıntılı inceleyebilirsiniz. Bu, fiziksel sunucunun tamamının size ayrıldığı anlamına gelmez. İlk inceleme için şu komutları kullanabilirsiniz:

• top veya htop: CPU, bellek ve süreçleri gözlemlemek için.
• uptime: Son 1, 5 ve 15 dakikanın load average değerlerini görmek için. Linux’ta çalışabilir işler ve kesilemeyen bekleme durumları bu değere katkı sağlar; load average CPU yüzdesi değildir.
• vmstat 1 10: Bir saniyelik örneklerle çalışabilir/bekleyen işler, bellek, swap ve CPU alanlarını karşılaştırmak için. İlk CPU/IO raporu açılıştan beri ortalamadır; sonraki aralıkları olayla eşleştirin.

iowait, CPU muhasebesinde bekleyen IO ile ilişkili boş zamanı gösterir; bütün CPU’nun disk yüzünden durduğu anlamına gelmez. Linux çekirdek belgesi bu alanın özellikle çok çekirdekli sistemlerde sınırlamalarını belirtir. %20–30 gibi tek bir eşiği kesin disk teşhisi olarak kullanmayın. Aynı aralıktaki cihaz gecikmesi, kuyruk, okuma/yazma hacmi, süreçler ve uygulama süresini karşılaştırın. VPS’te CPU steal da sağlayıcıyla araştırılabilecek ayrı bir göstergedir.

Disk IO’yu Yakalamak: iostat -x ve sar

Disk IO tarafını daha net görmek için şu komutları kullanabilirsiniz. Önce iostat ve sar araçlarını sağlayan sysstat paketinin kurulu olduğunu ve gerekli gözlem izinlerine sahip olduğunuzu doğrulayın:

• iostat -y -x 1 10: Açılıştan beri ilk raporu atlayarak bir saniyelik on cihaz örneği üretir. await ortalama IO tamamlanma süresini, aqu-sz ortalama kuyruk uzunluğunu gösterir; eski sürümlerde kuyruk alanı avgqu-sz olarak adlandırılmıştır.
• sar -d 1 10: Canlı disk örnekleri üretir. Geçmiş dönem için önceden etkin sysstat veri toplaması ve ilgili tarih dosyası gerekir; kayıtlı dosyayı sar -d -f /path/to/saDD biçimiyle okuyabilirsiniz. Örnek yolu gerçek kayıt dosyasıyla değiştirin; araç geçmişte toplanmamış veriyi geri getiremez.

Özellikle şunlara dikkat edin:

• await: Kuyrukta bekleme ve hizmet süresini birlikte içeren ortalamayı normal iş yüküyle karşılaştırın. Okuma/yazma türü ve işlem büyüklüğü önemlidir; herkese uygun tek bir milisaniye sınırı yoktur.
• aqu-sz: Artan kuyruk uzunluğunu hacim ve uygulama gecikmesiyle eşleştirin. Eski svctm alanını temel almayın; güncel iostat çıktısında bu alan yoktur.
• %util: Seri çalışan cihazlarda yüksek değer doygunluk işareti olabilir; modern SSD veya RAID’in paralel kapasitesini tek başına göstermez. Konuk VPS cihaz istatistiği fiziksel depolamanın tamamını açıklamaz.

Bu veriler, disk beklemesi hipotezini sınamak için birlikte kullanılır. Yedekleme, log sıkıştırma, rapor dışa aktarma veya veri tabanı işi aynı zamana denk geliyorsa görev kayıtlarını da inceleyin. iostat cihazı gösterir; belirli PHP/MySQL sürecini veya fiziksel depolama nedenini tek başına kanıtlamaz. Gerekirse süreç bazlı IO gözlemi ve sağlayıcı verisiyle tamamlayın.

MySQL Slow Query Log ve SHOW PROCESSLIST ile Tanı Koymak

MySQL’i yöneten yetkiniz varsa ürün ve sürümü doğrulayın; MySQL ile MariaDB ayarları her sürümde aynı değildir. MySQL 8.4 için olaydan önce sınırlı bir gözlem penceresi planlayın. Slow log, sorgu metni ve kişisel veri içerebilir; erişimi, saklama süresini ve disk alanını kontrol edin.

1. Mevcut slow_query_log, long_query_time, min_examined_row_limit, log_output ve slow_query_log_file değerlerini kaydedin. Dosya veya tablo hedefini doğrulayın; varsayılan bir dosya yolu kabul etmeyin.
2. Yetkili yönetici, seçilen pencere için günlüğü ve uygun eşiği yapılandırabilir. Global long_query_time değişikliği yeni bağlantıları etkiler; mevcut uygulama oturumları ve değişikliği yapan oturum kendiliğinden güncellenmez. Etkin oturum değerini doğrulayın ve bağlantı yenilemeyi kontrollü planlayın.
3. Eski log’u silmek yerine başlangıç/bitiş zamanını kaydedip o aralığı analiz edin. Gereken döndürmeyi desteklenen yöntemle ve saklama politikasını koruyarak yapın.
4. Pencere sonunda önceki ayarları geri yükleyin; etkilenen oturumları, günlük boyutunu ve uygulama işlevini kontrol edin. MySQL slow log tamamlanan uygun sorguları yazar; bütün beklemeleri kapsayan eksiksiz bir olay kaydı değildir.

Yavaşlama sırasında SHOW FULL PROCESSLIST; ile o anda görünen oturumları inceleyebilirsiniz. Diğer kullanıcıların oturumları için uygun PROCESS yetkisi gerekir; çıktı sorgu metni içerebilir. Bu bir anlık görüntüdür ve tek başına geçmişi göstermez. Şu alanları birlikte değerlendirin:

• Bağlantının komutu, durumu, o durumdaki süresi ve sorgu metni,
• Gerçek kilit beklemeleri ve gerekiyorsa bekleyen/engelleyen işlemi gösterecek ek veri tabanı araçları,
• Kullanıcı, uygulama isteği ve cron göreviyle eşleştirilebilen zaman bilgisi.

CPU artışı ve uzun sorgu aynı anda görülse de eksik indeks sonucuna hemen varmayın. Sorgu planını, işlenen satırları, beklemeleri ve sonuç doğruluğunu inceleyin. EXPLAIN planı anlamaya yardımcı olur; EXPLAIN ANALYZE sorguyu gerçekten çalıştırdığı için pahalı işlemleri kontrollü bir ortamda değerlendirin.

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

PHP-FPM kullanıyorsanız işleyici kuyruğunu veri tabanı ve CPU kullanımından ayrı gözlemleyin. pm.max_children havuzun aynı anda hizmet verdiği istekleri sınırlar; pm.max_requests ise bir çocuğun yeniden başlatılmadan önce işlediği istek sayısıdır. Bu ayarları CloudLinux EP veya NPROC ile eşitlemeyin.

• Korumalı FPM status görünümündeki listen queue, aktif/boş süreçler ve max children reached verisini olayla eşleştirin; status sayfasını herkese açmayın. Kümülatif göstergeleri önceki örnek ve FPM yeniden başlama zamanıyla birlikte okuyun.
• Yetersiz kullanılabilir worker beklemeye katkı sağlayabilir. Daha fazla worker ise belleği tüketebilir, CPU veya veri tabanı rekabetini artırabilir. Uygulama kapasitesi ve kullanılabilir bellek payıyla birlikte ölçün.

Havuz değişikliğini temsilî sayfa, yönetim ve ödeme işlemleriyle test edin. OPcache, PHP’nin derlenmiş kodunu; nesne önbelleği uygun uygulama verisini; tam sayfa önbelleği uygun yanıtı tekrar kullanır. Etki, isabet oranı ve invalidasyona bağlıdır. Giriş, hesap, sepet, ödeme ve kişiselleştirilmiş yanıtları ortak önbelleğe almayın; gerçek yolları, çerezleri ve yetkilendirmeyi test edin.

WordPress’te CPU artışı yönetim panelindeki oturumlarla aynı saatlere denk geliyorsa, admin-ajax.php üzerinden gelen Heartbeat isteklerini de inceleyin. WordPress Heartbeat API CPU'yu Neden Yükseltir? rehberi, bu isteklerin yükünü ölçmeyi ve gerekli editör işlevlerini koruyarak gereksiz çağrıları azaltmayı açıklar.

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, load average ve gerekiyorsa steal/IO gözlemlerini temel dönemle karşılaştırın.
• Disk gecikmesi, kuyruk, veri hızı ve hesap IO/IOPS sınırlarını ayrı ölçün.
• MySQL bağlantı ve sorgu sürelerini; HTTP hata oranı, TTFB ve kritik kullanıcı işlemleriyle birlikte izleyin.
• Alarmın teslimini ve iyileşme bildirimini kontrollü test edin; tek bir sabit kaynak eşiğini hizmet sağlığıyla eşitlemeyin.

Bu gözlemleri sürekli toplamak, sorunlu saatleri normal dönemlerle karşılaştırmayı kolaylaştırır. Başlangıç için 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, şu alanları değerlendirin:

• Uygulama: Ölçülen pahalı eklenti, sorgu ve dış çağrıyı test kopyasında inceleyin. Tam sayfa önbelleğinde özel yanıt istisnalarını ve invalidasyonu doğrulayın. LiteSpeed Cache için uyumlu etkin sunucu bileşeni veya uygun QUIC.cloud hizmeti gerekir; yalnız eklenti kurulumu yeterli değildir.
• Zamanlanmış işler: E-posta, rapor ve diğer görevlerin son teslim süresini koruyarak çakışmaları ve eşzamanlılığı sınırlayın. Kuyruğa taşımak işi yok etmez. WordPress’te sayfa tetiklemeyi kapatmadan önce çalışan sistem zamanlayıcısını doğrulayın.
• Sunucu: Yetkiniz varsa PHP-FPM pm.max_children, OPcache ve veri tabanı sınırlarını aynı temsilî yükle değerlendirin. Daha yüksek worker veya bağlantı limiti tek başına daha yüksek kapasite sağlamaz.

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 baskısını açıklayabilecek arka plan işleri, sürekli uygulama yükü ve depolama sınırlarını birlikte inceleyin. Zamanlamayı değiştirmek yalnız çakışma gerçekten katkı yapıyorsa yardımcı olur:

• Yedekler: Veri kaybı ve geri dönüş hedefini koruyarak uygun pencere ve çakışma önleme seçin. Araç destekliyorsa artımlı kopyayı değerlendirin; yedeğin oluşmasını ve izole geri yüklemeyi doğrulayın. Gece her site için düşük trafik zamanı değildir.
• Log’lar: Gereksiz debug üretimini azaltın; gerekli güvenlik ve olay kayıtlarını saklayın. Döndürme/sıkıştırma takvimini ölçerek ayarlayın; aktif dosyaları veya inceleme kanıtlarını topluca silmeyin.
• Sorgular: EXPLAIN ile planı ve satır erişimini inceleyin. İndeks değişikliğinin yazma, disk, kilit ve uygulama etkisini test edin.

CDN veya obje depolama, uygun medya isteklerinin origin’e ulaşmasını azaltabilir. Kazanımı gerçek cache isabeti, dış trafik ve yerel IO ile ölçün; önbellek kaçırmaları ve yerel dönüşüm işleri devam edebilir. Özel medya yetkilerini, maliyeti, erişimi ve geri dönüş planını geçişten önce doğrulayın.

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

MySQL tarafında sorgu/şema tasarımı, eşzamanlılık, kilitler ve mevcut kaynakları birlikte inceleyin. Donanım ile yazılımı ölçüm olmadan birbirinin alternatifi saymayın:

• İndeksler: WHERE, ORDER BY ve JOIN kullanımlarını sorgu planıyla değerlendirin. Her kolona indeks eklemeyin; seçicilik, bileşik indeks sırası ve yazma maliyeti önemlidir. Tam tablo taraması her durumda hata değildir.
• Tekrar eden sorgular: Uygun veri için nesne önbelleği veya istek içi tekrar azaltma kullanın; invalidasyonu ve kullanıcı kapsamını koruyun.
• Bağlantılar: Bağlantı açma maliyeti ölçülmüşse kullanılan sürücü ve uygulamanın desteklediği kalıcı bağlantı/havuz modelini değerlendirin. Oturum durumu, açık işlemler ve toplam bağlantı sınırını kontrol edin; PHP’de her uygulama aynı havuz modelini kullanmaz.
• InnoDB: innodb_buffer_pool_size için işletim sistemi, PHP ve diğer işlere bellek bırakın. MySQL 8.4’te redo kapasitesi innodb_redo_log_capacity ile yönetilir; eski sürüm veya MariaDB ayarını körlemesine taşımayın. Redo kapasitesi disk alanı ayarıdır; değişikliği flush davranışı ve kurtarma ihtiyaçlarıyla değerlendirin.

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?

Optimizasyonla Çözülebilen Senaryolar

Her yavaşlama paket yükseltmeyi gerektirmez. Aşağıdaki gözlemler, önce uygulama ve zamanlama değişikliklerini kontrollü test etmek için gerekçe sunabilir:

• 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.

Değişiklikten sonra aynı işlemin gecikmesini, hata oranını ve kaynak kullanımını karşılaştırın. Belirti sürüyorsa başka bağımlılık veya kapasite sınırını araştırın. Kısa süreli pik veya düşük günlük ortalama, sorunun çözüldüğünü göstermez.

Kapasite veya Mimari Değişikliği Ne Zaman Değerlendirilir?

Gerekli işler kullanıcıları etkileyen sınırlara düzenli olarak takılıyorsa, uygulama iyileştirmeleriyle birlikte kapasite ve mimari seçeneklerini değerlendirin:

• Hesap CPU/IO kullanımının normal yoğunlukta gerçek limit çizgisine ulaşması ve bunun hata/gecikmeyle eşleşmesi,
• VPS’te çalışabilir işler veya IO beklemelerinin uzun süre birikmesi; load average ile vCPU oranının tek başına yükseltme kuralı olmaması,
• Doğrulanmış sorgu ve önbellek değişikliklerinden sonra kritik işlemlerin hedef süreyi karşılayamaması.

Daha yüksek limitli paylaşımlı hosting, VPS, dedicated sunucu veya colocation farklı yönetim ve kapasite modelleridir. DCHost’tan seçilen planın gerçek CPU paylaşımını, RAM, IO/IOPS, hesap sınırlarını ve yönetim kapsamını teyit edin. NVMe adı tek başına garantili gecikme veya özel CPU sağlamaz. Geçiş kararı, gerekli kontrol ve ölçülen darboğaza dayanmalı; taşıma, yedek ve geri dönüş adımları ayrıca planlanmalıdır.

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

Periyodik yavaşlık için kullanışlı çıktı, olayın zamanı ve etkilenmiş işlemle birlikte kaynak, istek ve görev kayıtlarını içeren bir inceleme kaydıdır. cPanel verisi, top/htop, iostat, slow query log ve dış testler farklı katmanları gösterir. Birbirlerini desteklediklerinde olası nedeni daraltır; hiçbir tek grafik kesin teşhis sağlamaz.

Bir sonraki adım, ölçümün desteklediği tek bir değişikliği yapmak ve normal/sorunlu dönemde sonucu karşılaştırmaktır. Dedicated sunucu dahil bir plan veya destek görüşmesi için olay saatini, saat dilimini, etkilenen URL/işlemi, hata kodunu ve ilgili limit verisini hazırlayın. Hassas bilgileri paylaşmadan çıkarın; sağlayıcıdan gözlemlemediğiniz katmanın verisini ve mevcut destek kapsamını isteyin. Böylece optimizasyon, kapasite veya dış bağımlılık kararını somut kanıtla verebilirsiniz.