ApsaraDB RDS for MySQL örneğindeki yavaş SQL deyimleri genellikle şema veya dizin sorunları, kaynak tükenmesi, sürüm yükseltme yan etkileri, hatalı yapılandırılmış parametreler, önbellek hücumları, yoğun toplu işlemler, kapatılmamış işlemler veya zamanlanmış görevler gibi kök nedenlerden birinden kaynaklanır. Her nedenin belirgin belirtileri ve buna karşılık gelen bir çözümü vardır.
Sorun gidermeye yaklaşım
Herhangi bir özel nedeni araştırmadan önce izleme verilerini inceleyerek başlayın. Aşağıdaki sırayı takip edin:
Herhangi bir özel nedeni araştırmadan önce kaynak darboğazlarını eleyin. ApsaraDB RDS konsolunda Monitoring and Alerts öğesini açın ve Standard Monitoring sekmesini kontrol edin. CPU kullanımı, bellek kullanımı, disk kullanımı, IOPS (saniye başına giriş/çıkış işlemi), bağlantılar, önbellek isabet oranı, saniye başına sorgu sayısı (QPS) ve saniye başına işlem sayısı (TPS) değerlerini gözden geçirmek için Resource Monitoring seçeneğine tıklayın. Bu ölçümlerden herhangi biri tutarlı bir şekilde yüksekse, yavaşlama belirli bir SQL deyimiyle ilgili bir sorundan ziyade muhtemelen bir kaynak darboğazından kaynaklanıyor demektir. Ayrıntılar için bkz. örnek sınırları.
Bir ölçüm %100'e yakınsa örnek sınırları veya toplu işlemler bölümüne bakarak sorunu inceleyin.
Ölçümler normal görünmesine rağmen sorgular hala yavaşsa kapatılmamış işlemler ve SQL istisnaları bölümlerini kontrol edin.
-
Belirli yavaş deyimleri tanımlamak için SQL Explorer and Audit özelliğini açın. Hangi deyimlere öncelik verileceğini belirlemeye yardımcı olan iki ölçüm şunlardır:
Çalıştırma süresi: Uzun süren sorgular kilitleri daha uzun süre tutar ve diğer işlemleri engeller. Önce bunları düzeltin.
Çalıştırma sayısı: Sıkça çalıştırılan sorgular, her bir çalışma hızlı olsa bile yüksek kümülatif yük oluşturur. Bunlar güçlü optimizasyon adaylarıdır.
Örnek sınırlarından kaynaklanan yavaş SQL deyimlerini giderme
Nedenler
Bir örnek birkaç nedenle performans sınırına ulaşır:
İş yükleri, depolama kapasitesi veya hesaplama kaynaklarında karşılık gelen bir artış olmadan büyür.
Fiziksel ana bilgisayar eskir ve genel örnek performansı düşer.
Veri hacmi artar ve veri yapısı değişiklikleri zaman içinde belirli SQL deyimlerini yavaşlatır.
Nasıl tanımlanır
ApsaraDB RDS konsolunda gezinme bölmesinde Monitoring and Alerts seçeneğine gidin. Standard Monitoring sekmesinde, tüm kaynak kullanımı ölçümlerinin %100'e yakın olup olmadığını kontrol etmek için Resource Monitoring seçeneğine tıklayın. Durum böyleyse örnek performans sınırına ulaşmıştır.
Çözüm
Örneğinizin maksimum performansını ölçmek için SysBench kullanın. SysBench tarafından ölçülen QPS ve TPS değerleri, karmaşık sorgu iş yükleri altında bile üst sınırı temsil eder. Kıyaslama prosedürleri için bkz. Test yönergeleri.
Örnek performans sınırına ulaştıysa daha yüksek bir teknik özelliğe yükseltin. Ayrıntılar için bkz. Örnek teknik özelliklerini değiştirme.
SQL istisnalarından kaynaklanan yavaş SQL deyimlerini giderme
Nedenler
SQL istisnaları, sorgular şema tasarımı sorunları, eksik dizinler veya taranması gereken aşırı sayıda satır nedeniyle doğası gereği verimsiz olduğunda oluşur.
Nasıl tanımlanır
ApsaraDB RDS konsolunda gezinme bölmesinde SQL Explorer and Audit seçeneğine gidin. Hangi sorguların dikkat gerektirdiğini belirlemek için her bir yavaş SQL deyiminin çalıştırma süresini ve çalıştırma sayısını gözden geçirin.
Çözüm
Sorunlu SQL deyimlerini iş gereksinimlerinize göre optimize edin. Ayrıntılar için bkz. SQL optimizasyonu.
Sürüm yükseltmelerinden kaynaklanan yavaş SQL deyimlerini giderme
Nedenler
Bir RDS örneğini yükseltmek, mevcut SQL deyimleri için sorgu planlarını değiştirebilir. MySQL sorgu planları, verimlilik açısından farklılık gösteren birleştirme türlerini kullanır. Verimlilik açısından azalan sırada: system, const, eq_ref, ref, fulltext, ref_or_null, index_merge, unique_subquery, index_subquery, range, index ve all. Ayrıntılar için bkz. resmi MySQL belgeleri.
Sıkça yürütülen bir deyimin sorgu planı daha az verimli bir birleştirme türüne (örneğin range veya index) kaydığında, deyim daha yavaş çalışır. Bu tür birçok deyim aynı anda paralelleştirilirse, iş parçacıkları serbest bırakılandan daha hızlı birikir, bağlantı havuzunu tüketir ve örnekteki tüm iş yüklerini etkiler.
Nasıl tanımlanır
ApsaraDB RDS konsolunda gezinme bölmesinde Monitoring and Alerts seçeneğine gidin. Standard Monitoring sekmesinde, etkin bağlantı sayısını kontrol etmek için Resource Monitoring seçeneğine tıklayın. Yükseltmeden sonra bağlantı sayısındaki ani artış güçlü bir göstergedir.
Çözüm
Yavaş deyimler için sorgu planlarını analiz etmek üzere EXPLAIN komutunu kullanın. Her bir deyim için birleştirme türlerini, dizin kullanımını ve taranan satır sayısını belirleyin. Bu analize dayanarak, sorgu verimliliğini geri yüklemek için SQL deyimlerini yeniden yapılandırın veya dizinleri ayarlayın. Ayrıntılar için bkz. SQL optimizasyonu.
Uygun olmayan parametre ayarlarından kaynaklanan yavaş SQL deyimlerini giderme
Nedenler
innodb_buffer_pool_instances ve join_buffer_size parametreleri için yanlış değerler SQL yürütme performansını düşürebilir.
Nasıl tanımlanır
ApsaraDB RDS konsolunda gezinme bölmesinde Parameters seçeneğine gidin. Performans düşüşüyle eş zamanlı olarak son bir değişikliğin olup olmadığını görmek için bu parametrelerin yeniden yapılandırma geçmişini gözden geçirmek üzere Edit History sekmesine gidin.
Çözüm
innodb_buffer_pool_instances ve join_buffer_size değerlerini iş yükünüz ve örnek teknik özellikleriniz için uygun olacak şekilde yeniden yapılandırın.
Önbelleğe alınmış girdilerin süresinin dolmasından kaynaklanan yavaş SQL deyimlerini giderme
Nedenler
Önbelleğe alınmış girdilerin süresi aynı anda dolduğunda (önbellek hücumu), büyük hacimli istekler önbelleği atlayarak doğrudan veritabanına ulaşır. ApsaraDB RDS %100 önbellek isabet oranı garanti etmez; bu nedenle bu senaryo yüksek eşzamanlılık altında mümkündür.
Nasıl tanımlanır
ApsaraDB RDS konsolunda gezinme bölmesinde Monitoring and Alerts seçeneğine gidin. Standard Monitoring sekmesinde, önbellek isabet oranını QPS ve TPS ile birlikte kontrol etmek için Resource Monitoring seçeneğine tıklayın. Önbellek isabet oranındaki ani düşüş, QPS'teki artışla birlikte bir önbellek hücumuna işaret eder.
Çözüm
Artan yükü işlemek ve önbellek isabetlerinin etkisini azaltmak için aşağıdaki özellikleri etkinleştirin:
Thread Pool: Bağlantı eşzamanlılığını yönetir ve iş parçacığı tükenmesini önler. Bkz. İş parçacığı havuzu.
Fast query cache: Tekrarlanan hesaplamayı azaltmak için sorgu sonuçlarını önbelleğe alır. Bkz. Hızlı sorgu önbelleği.
Automatic SQL throttling: Örneği korumak için gelen SQL isteklerinin hızını sınırlar. Bkz. Otomatik SQL kısıtlaması.
Toplu işlemlerden kaynaklanan yavaş SQL deyimlerini giderme
Nedenler
Normal iş yükleriyle eşzamanlı olarak çalışan büyük ölçekli veri içe aktarma, silme veya sorgu işlemleri disk G/Ç ve işlem kaynakları için rekabet ederek tüm SQL yürütmelerini yavaşlatır.
Nasıl tanımlanır
Disk kullanımını, SQL günlüklerini veya yavaş sorgu istatistiklerini kontrol edin. Yararlı bir sinyal: ikili günlük (binlog) dosyaları normalde her biri 500 MB'tır. Bir binlog dosyası 500 MB'ı aşarsa, bunun nedeninin toplu bir işlem olup olmadığını araştırın.
ApsaraDB RDS konsolunda gezinme bölmesinde Monitoring and Alerts seçeneğine gidin. Disk kullanımını ve IOPS değerlerini gözden geçirmek için Standard Monitoring sekmesinde Resource Monitoring seçeneğine tıklayın. TPS değerlerini gözden geçirmek için Engine Monitoring seçeneğine tıklayın.
Çözüm
Toplu işlemleri yoğun olmayan saatlerde planlayın. Yoğun olmayan saatlerde planlama mümkün değilse, tepe yükünü azaltmak için her bir toplu işlemi daha küçük isteklere bölün ve bunları ardışık olarak gönderin.
Kapatılmamış işlemlerden kaynaklanan yavaş SQL deyimlerini giderme
Nedenler
Kapatılmamış işlemler kilitleri tutar ve diğer sorguları engeller. Etkilenen sorgular kuyruğa alınır, yavaş SQL deyimleri olarak görünür ve etkin oturum sayısının artmasına neden olur.
Nasıl tanımlanır
Bir iş yükü aniden yavaşlar ancak CPU kullanımı ve IOPS normal kalır ve etkin oturum sayısı artmaya devam ederse, bunun nedeni muhtemelen kapatılmamış işlemlerdir. Bu durum genellikle SQL deyimleri Data Management Service (DMS) aracılığıyla manuel olarak veya normal uygulama akışlarının dışında çalıştırıldığında ortaya çıkar.
Çözüm
Kilitleri tutan işlemleri tanımlayın. İşlemler arasında kilit çakışmalarını kontrol edin, ardından kilitleri serbest bırakmak için engelleyen SQL deyimlerini sonlandırın.
Zamanlanmış görevlerden kaynaklanan yavaş SQL deyimlerini giderme
Nedenler
Toplu yazma veya güncelleme işlemleri gerçekleştiren zamanlanmış görevler sabit aralıklarla çalışır. Yoğun olmayan saatler için yapılandırılmış olsalar bile, kilitleme ve G/Ç baskısı nedeniyle diğer iş yükleriyle rekabet edebilir ve örtüşme dönemi sırasında yavaş SQL deyimlerine neden olabilir.
Nasıl tanımlanır
Örnek yükü düzenli, öngörülebilir aralıklarla artarsa, zamanlanmış görevler muhtemelen dahilidir. Yük desenlerini görev programlarıyla ilişkilendirmek için Standard Monitoring sekmesindeki Monitoring and Alerts sayfasındaki izleme bilgilerini gözden geçirin.
Çözüm
Görevlerin en düşük trafik dönemlerinde çalışması için programı ayarlayın. Tepe yüklerinin örtüşmesini önlemek için birden çok zamanlanmış görevi farklı zamanlara yaygın.
Ağ sorunlarından kaynaklanan yavaş SQL deyimlerini giderme
Kaynak ölçümleri ve SQL deyimi analizi normal görünmesine rağmen iş yükü hala yavaşsa ağ bağlantısı yöntemini kontrol edin. Örnek ayrıntıları sayfasında uç nokta türünü görüntülemek için Database Connection seçeneğine gidin. Genel uç noktalar, özel (VPC) uç noktalardan daha yüksek gecikme süresine sahiptir. Uygulamanız RDS örneğinizle aynı VPC'deki bir ECS örneğinde çalışıyorsa, ağ gecikme süresini azaltmak için bağlanmak üzere özel uç noktayı kullanın. Ayrıntılar için bkz. Bir örneğe bağlantı hatalarını giderme.
Sonraki adımlar
Yavaş SQL deyimlerini daha fazla araştırmak için aşağıdaki araçları ve konuları kullanın: