MySQL Sunucu Yavaşlığı Nasıl İncelenir?

MySQL sunucu yavaşlığını gidermek için önce sorunun tüm uygulamada mı, belirli sorgularda mı görüldüğünü ayırın. Bunun için aynı işlemi tekrar edebilecek uygulama erişimine ve sunucu yönetiliyorsa işlemci, bellek, disk ile MySQL durum bilgilerine erişime ihtiyacınız vardır. Değişiklik yapmadan önce mevcut ayarları kaydedin; tek seferde yalnızca bir faktörü değiştirerek sonucu yeni kayıtlarla doğrulayın.

MySQL sunucu sorununda önce belirtiyi sınıflandırın

Sayfa veya API istekleri yalnızca veritabanı sorgusu çalışırken bekliyorsa yavaş sorgu, eksik dizin ya da kilitlenme olasılıkları öne çıkar. Aynı anda sunucudaki farklı hizmetler de yavaşlıyorsa bellek baskısı, disk gecikmesi veya CPU doygunluğu daha olasıdır. Bağlantı kurulamadığında ise sorgu optimizasyonuna geçmeden önce port erişimi, kullanıcı yetkisi ve bağlantı sınırları incelenmelidir.

İlk karar, belirtinin kapsamına göre verilir: yalnızca bir rapor veya arama yavaşsa o işlemin ürettiği SQL sorgusunu ve sorgu planını inceleyin; tüm site yavaşsa işletim sistemi kaynaklarını ve aynı zaman aralığındaki MySQL durumunu karşılaştırın. CPU düşük, disk bekleme süresi yüksek görünüyorsa işlemciyi büyütmek yerine depolama gecikmesi ve sorgunun çok sayıda satır tarayıp taramadığı ele alınmalıdır.

İnceleme için erişim ve kanıtları hazırlayın

Paylaşımlı hosting kullanıyorsanız genellikle yalnızca kontrol panelindeki kaynak kullanımı, veritabanı yönetim aracı ve sağlayıcının sunduğu hata veya yavaş sorgu kayıtlarına erişebilirsiniz. Yönetilen ya da kendi yönettiğiniz sunucuda ise MySQL durum ekranlarına, işletim sistemi gözlemlerine ve yapılandırmanın etkin değerlerine erişim gerekir. Yetkiniz yoksa yapılandırmayı rastgele değiştirmek yerine aynı zaman damgalarını sağlayıcıya iletin.

Başlamadan önce yavaş işlemin URL’sini veya uygulama adımını, gözlemlenen saati, yaklaşık bekleme süresini ve bunun her seferinde olup olmadığını not edin. MySQL yapılandırma dosyasının ve değiştireceğiniz değerin özgün halini saklayın. Yedek, özellikle tablo yapısı veya dizin değişikliği planlanıyorsa, geri dönüş için uygun bir araçtır; yalnızca performans sorunu var diye veri silmek güvenli bir çözüm değildir.

Yavaş MySQL sorgusunu adım adım ayırın

1. Aynı işlemi yeniden üretin. Sorunlu sayfayı, aramayı veya raporu bir kez çalıştırırken başlangıç ve bitiş saatini kaydedin. Uygulamanın hata günlüğü ile MySQL’in hata veya yavaş sorgu kaydında aynı dakikaya ait yeni satırları arayın. Kayıt belirli bir sorgu, tablo ya da kilit beklemesi gösteriyorsa kaynak incelemesine geçmeden o kanıtı temel alın; yeni kayıt yoksa uygulama önbelleği, ağ gecikmesi veya yanlış zaman aralığını değerlendirin.
2. Sorgu planını inceleyin. Yönetim aracında veya yetkili bir yönetici oturumunda, üretim verisini değiştirmeyen bir plan inceleme yöntemiyle sorgunun hangi tabloyu taradığını, tahmini satır sayısını ve uygun dizin kullanıp kullanmadığını kontrol edin. Büyük bir tablo baştan sona taranıyor ve sorgu bir filtre veya birleştirme koşulu kullanıyorsa, koşula uygun bir dizin adayını geliştiriciyle değerlendirin. Ancak her kolona dizin eklemeyin; yazma işlemlerinde ek maliyet ve depolama kullanımı doğabilir.
3. Kilit ve bağlantı durumunu karşılaştırın. Aynı zaman aralığında aktif işlemler, bekleyen kilitler ve bağlantı sayısını kontrol edin. Bir işlem uzun süre kilit tutuyor, diğerleri bu nedenle bekliyorsa bağlantı sayısını artırmak sorunu büyütebilir. İşlemin neden uzun sürdüğünü ve uygulamanın işlemi güvenli biçimde sonlandırıp sonlandıramadığını belirleyin; hedefli düzeltme, ilgili işlemin yaşam döngüsünü veya sorgusunu ele almaktır.
4. Sunucu kaynaklarını ayrı ölçün. CPU, kullanılabilir bellek, takas kullanımı ve disk bekleme göstergelerini aynı zaman damgasıyla inceleyin. Bellek yetersizliği ve takas gözleniyorsa sorgu önbelleği gibi tek bir MySQL değerini körlemesine yükseltmek yerine bellek tüketen süreçleri ve veritabanının etkin bellek ayarlarını yöneten kişiyle değerlendirin. Disk beklemesi baskınsa hızlı depolama, tablo büyümesi ve yedekleme gibi eşzamanlı işler incelenmelidir.
5. Tek bir hedefli değişiklik uygulayın. Örneğin kayıt, belirli bir arama sorgusunun uygun dizin olmadan çok sayıda satır taradığını gösteriyorsa önce tablo yedeğini ve özgün şemayı saklayıp yalnızca o sorgu için doğrulanmış dizin değişikliğini planlayın. Değişiklikten sonra aynı aramayı aynı koşullarla yeniden çalıştırın; yeni zaman damgasındaki sorgu planında taranan satırların ve bekleme süresinin azaldığını, ayrıca hata kaydında yeni bir sorun oluşmadığını kontrol edin. Düzelme yoksa ilk sonucu başarı kanıtı saymayın; değişikliği geri alıp bir sonraki faktöre geçin.

Olası bulgular nasıl yorumlanır?

Diyelim ki bir ürün araması yalnız yoğun saatlerde yavaşlıyor ve yeni kayıtlarda bekleyen kilitler görülüyor. Bu bulgu, doğrudan disk kapasitesinin yetersiz olduğunu kanıtlamaz; önce kilidi uzun süre tutan yazma işleminin hangi uygulama akışından geldiği incelenmelidir. Kilit ortadan kalktığında aynı arama normale dönüyorsa işlem süresi veya işlem sınırları hedeflenir. Kilit yok, plan sürekli geniş tablo taraması gösteriyorsa bu kez sorgu ve dizin tasarımı ele alınır.

Düzeltme sonrası doğrulama ve güvenli geri dönüş

Her değişiklikten sonra aynı başarısız işlemi tekrarlayın; fakat değerlendirmeyi eski kayıtlara değil, değişiklikten sonra oluşan yeni ve zamanla eşleşen kanıtlara dayandırın. Uygun sonuç yalnızca sayfanın açılması değildir: sorgu planı beklenen yolu kullanmalı, hata veya kilit kaydı tekrarlamamalı ve diğer işlemlerde belirgin bir bozulma görülmemelidir.

Performans düzelmiyor, yeni bir hata oluşuyor veya yazma işlemleri belirgin biçimde yavaşlıyorsa özgün ayara ya da şemaya dönün ve değişikliği geri alın. Yönetilen veya paylaşımlı ortamda gerekli kanıtları, saat bilgisini ve denediğiniz tek değişikliği sağlayıcıya iletin. Sunucu seçimini yeniden değerlendirmek gerekiyorsa sunucu kiralama çözümleri hakkında seçenekleri incelerken MySQL’in disk gecikmesi, bellek sınırı ve yönetim erişimi gereksinimlerini özellikle sorun.

Bir sonraki güvenli adım, sorunlu işlemi bir kez daha aynı koşullarda çalıştırıp sorgu kaydı ile kaynak göstergelerini birlikte karşılaştırmaktır. Böylece rastgele kaynak artırmak yerine hangi katmanın gerçekten beklemeye neden olduğunu belirleyebilirsiniz.