mysql sunucu Yavaşlığı Nasıl Teşhis Edilir?

mysql sunucu yavaşladığında önce tüm kaynak limitlerini artırmak yerine aynı işlemin ne zaman ve hangi sorguda geciktiğini belirleyin. Paylaşımlı hostingde panel, hata günlüğü ve sağlayıcının sunduğu verilerle ilerlenir; yönetilen veya kendi yönettiğiniz sunucuda sorgu günlükleri, işlem listesi ve kaynak ölçümleri incelenebilir. Kanıtı topladıktan sonra tek bir nedeni değiştirip aynı işlemi yeniden test etmek en güvenli yoldur.

Önce erişim düzeyini ve belirtiyi netleştirin

Paylaşımlı hosting kullanıyorsanız MySQL yapılandırma dosyalarına veya sistem kaynaklarına erişiminiz olmayabilir. Hosting panelindeki veritabanı istatistikleri, hata günlükleri, işlem listesi ve varsa yavaş sorgu raporlarıyla sınırlı kalın; sağlayıcının değiştirdiği ayarları doğrudan ezmeye çalışmayın. Yönetilen ya da kendi yönettiğiniz sunucuda ise veritabanı yöneticisi hesabı, uygulama günlükleri ve sunucu izleme ekranları gerekir.

İlk olarak başarısız veya yavaş işlemin saatini, kullandığı URL ya da ekranı, yaklaşık bekleme süresini ve bunun her seferinde mi yoksa yoğun saatlerde mi oluştuğunu not edin. Yalnız giriş yapma yavaşsa bağlantı veya kimlik doğrulama sorununu; belirli bir rapor gecikiyorsa sorgu planı ve disk erişimini; tüm uygulama yavaşsa CPU, bellek, disk veya ağ baskısını öncelemeniz gerekir. Bu ayrım, yanlış ayarı büyütmenizi önler.

mysql sunucu performansını kanıtla daraltın

Paneldeki veritabanı işlem listesini veya yönetici erişiminiz varsa salt okunur işlem görünümünü, gecikmenin gerçekleştiği zaman aralığında inceleyin. Aynı sorgu uzun süre çalışıyor ve bekleme durumu gösteriyorsa sorgunun kendisi ya da kilitlenme olasılığı öne çıkar. Sorgu görünmüyor, fakat bağlantı sayısı limite dayanıyorsa uygulamanın bağlantı havuzu veya bağlantıları kapatma davranışı araştırılmalıdır.

Yavaş sorgu günlüğü açıksa yalnız yeni oluşan ve test saatinizle eşleşen kayıtları değerlendirin. Kayıtta sorgunun toplam süresi, kilit bekleme süresi ve incelenen satır sayısı bulunabilir; sağlayıcıya göre alanlar değişir. Sorgu süresi yüksekken kilit bekleme süresi de yüksekse indeks eklemek yerine aynı tabloya yazan işlemleri ve uzun açık kalan işlemleri inceleyin. Kilit beklemesi düşük, incelenen satır sayısı yüksekse sorgu planı ve indeks yapısı daha olası nedendir.

Güvenli inceleme ve düzeltme sırası

1. Mevcut durumu kaydedin. Paneldeki kaynak grafiğini, ilgili ayarların mevcut değerlerini ve son çalışan uygulama değişikliğini not edin. Yapılandırma değişecekse önce sağlayıcının yedekleme veya geri alma olanağını doğrulayın. Aynı anda birden fazla ayarı değiştirmeyin; aksi halde hangi müdahalenin etkili olduğunu ayırt edemezsiniz.
2. Uygulama ve veritabanı günlüklerini aynı zaman aralığında karşılaştırın. Uygulama günlüğünde tek bir sorgu veya tablo adı görünüyorsa veritabanı tarafındaki yavaş sorgu kaydıyla eşleştirin. Yeni kayıt yoksa günlük özelliği kapalı, filtrelenmiş veya erişim düzeyinizin dışında olabilir; bu durumda rastgele ayar değiştirmek yerine sağlayıcıdan ilgili zaman aralığının sorgu süresini isteyin.
3. Sorgu planını salt okunur biçimde değerlendirin. Yönetici erişiminiz varsa sorgunun önüne veritabanı sürümünüzle uyumlu EXPLAIN analizi uygulayın; bunu üretim verisini değiştiren bir işlem gibi kullanmayın. Plan büyük tabloda geniş tarama ve yüksek tahmini satır sayısı gösteriyorsa, WHERE veya JOIN koşullarındaki sütunların mevcut indekslerle uyumunu geliştiriciyle inceleyin. Eksik indeks olasıysa önce test ortamında veya bakım planında yalnız ilgili indeksi değerlendirin; tüm sütunlara gelişigüzel indeks eklemek yazma işlemlerini ve disk kullanımını artırabilir.
4. Kaynak baskısını ayrı kontrol edin. CPU sürekli yüksekse sorgu planı ve eşzamanlı işlem sayısını; bellek azalıp takas kullanımı artıyorsa çalışan servislerin bellek tüketimini ve sorgu eşzamanlılığını; disk kullanımı yükseliyorsa günlük büyümesi, tablo taramaları ve disk gecikmesini inceleyin. Bağlantı sayısı sınıra ulaşıyorsa limiti hemen yükseltmek yerine kullanılmayan bağlantıların kapanıp kapanmadığını ve uygulama havuzunun makul bir üst sınıra sahip olup olmadığını kontrol edin. Sorun kaynak yetersizliğiyse sorguyu azaltmak veya uygun kaynak planına geçmek, yalnız limiti büyütmekten daha hedefli olabilir.
5. Tek değişkenle doğrulayın. Örneğin belirli rapor sorgusunun planı geniş tablo taraması gösteriyor ve ilgili filtre sütununda uygun indeks bulunmuyorsa, önce mevcut yapılandırmayı kaydedip yalnız bu sorguya yönelik indeks değişikliğini yetkili bakım sürecinde uygulayın. Aynı raporu benzer veri koşullarında yeniden çalıştırın; yeni işlem günlüğünde sorgu süresi, taranan satır veya kilit beklemesi değişmiş olmalıdır. Sonuç değişmiyorsa veya yazma işlemleri ağırlaşıyorsa değişikliği geri alın ve yeni bulguya göre sorgu yapısını ya da kaynak baskısını ele alın.

Belirtiye göre hedefli karar verin

Diyelim ki bir e-ticaret uygulamasında yalnız tarih aralığı seçilen satış raporu gecikiyor. Aynı saatlerde CPU normal, fakat yavaş sorgu kaydı bu raporu ve çok sayıda incelenen satırı gösteriyor. Bu bulgu bağlantı limitini artırmayı değil, rapordaki filtre ve birleştirme koşullarına uygun indeks tasarımını test etmeyi gerektirir. Buna karşılık yeni bulgu bağlantıların kapanmadan biriktiğini gösterseydi sorguya indeks eklemek yerine uygulamanın bağlantı havuzu ve hata sonrası bağlantı kapatma akışı düzeltilmeliydi; iki belirti aynı çözümü göstermez.

Başka bir durumda sorgular kısa sürede tamamlanıyor, ancak yeni bağlantı kurulması bekliyorsa bağlantı sayısı, kimlik doğrulama hataları ve ağ gecikmesi incelenmelidir. Tüm sorgular disk takası sırasında yavaşlıyorsa önce bellek baskısının kaynağını ve eşzamanlılığı azaltma olanağını değerlendirin. Sistem yöneticisi değilseniz yapılandırma değişikliği yapmadan önce bu zaman eşleşmeli kanıtları sunucu kiralama çözümleri hakkında görüşeceğiniz teknik ekiple paylaşabilirsiniz.

Değişiklik işe yaramazsa güvenli geri dönüş

Aynı işlemi tekrar ettikten sonra yeni günlük kaydı oluşmuyor, hata türü değişiyor veya gecikme sürüyorsa ilk bulguyu bütün sorunun açıklaması kabul etmeyin. Son değiştirdiğiniz değeri önceki haline döndürün; yalnızca geri dönüşün güvenli olduğundan ve uygulamanın eski değeri desteklediğinden emin olun. Paylaşımlı ya da yönetilen ortamda gerekli günlük ve kaynak verileri erişiminiz dışında kalıyorsa, sorgu metnini veya kimlik bilgilerini herkese açık biçimde paylaşmadan sağlayıcının özel destek kanalına zaman damgası ve hata türüyle başvurun.

Bir sonraki güvenli adım, aynı başarısız işlemi tekrar üretip yalnız bu yeni denemeye ait günlük satırlarını işlem listesi ve kaynak grafiğiyle eşleştirmektir. Böylece düzeltmenin gerçekten etkili olup olmadığı, sorunun başka bir katmana taşınıp taşınmadığı veya önceki ayarın geri alınması gerekip gerekmediği görülebilir.