ApsaraDB RDS:High CPU utilization on ApsaraDB RDS for MySQL or MariaDB instances

Sorun açıklaması

ApsaraDB RDS for MySQL veya MariaDB örneğinizin CPU kullanımı yüksektir ve zaman zaman %100'e ulaşabilir.

Nedenler

Bir uygulama bir sorgu veya veri değişikliği gönderdiğinde sistem çok sayıda mantıksal okuma işlemi gerçekleştirir. Bu işlemler, bir tablodaki birçok veri satırına erişilmesini içerir. Sistem daha sonra depolama alanı ile bellek arasındaki veri tutarlılığını korumak için önemli miktarda CPU kaynağı kullanır. Bu konu, saniyedeki sorgu sayısı (QPS) olarak ölçülen yüksek uygulama yükü ve yavaş SQL deyimlerinden kaynaklanan yüksek sorgu maliyetleri olmak üzere %100 CPU kullanımının iki yaygın nedenini ve çözümlerini açıklamaktadır. MySQL'de yüksek CPU kullanımı genellikle birçok veri satırına erişen ve bu nedenle yüksek sorgu maliyetine yol açan yavaş SQL deyimlerinden kaynaklanır.

• Yüksek uygulama yükü (yüksek QPS):

  • Özellikler: Örnekte yüksek QPS değeri bulunur. Sorgular basit ve verimlidir. Optimizasyon için çok az alan vardır.

  • Belirtiler: Yavaş sorgu oluşmaz veya yavaş sorgular ana neden değildir. QPS ve CPU kullanımı eğrileri eşleşir.

  • Yaygın senaryolar: Bu sorun, sipariş sistemleri gibi optimize edilmiş çevrimiçi işlem işleme (OLTP) sistemlerinde, yüksek okuma oranına sahip popüler web uygulamalarında ve Sysbench gibi üçüncü taraf stres testi araçlarında yaygındır.

• Yavaş SQL deyimlerinden kaynaklanan yüksek sorgu maliyetleri (çok sayıda veri satırına erişim):

  • Özellikler: Örnekte düşük QPS değeri bulunur. Sorgu çalıştırma verimsizdir ve büyük miktarda tablo verisinin taranmasını gerektirir. Optimizasyon için önemli ölçüde alan vardır.

  • Belirtiler: Yavaş sorgular mevcuttur. QPS ve CPU kullanımı eğrileri eşleşmez.

  • Neden analizi: Verimsiz sorgular, beklenen sonuçları almak için büyük miktarda veriye erişmelidir. Bu durum yüksek ortalama mantıksal G/Ç'ye yol açar. Sonuç olarak, trafiği düşük bir web sitesinde olduğu gibi QPS düşük olsa bile CPU kullanımı yüksek olabilir.

Çözümler

Belirli durumunuza göre bir çözüm seçin.

Yüksek uygulama yükü (yüksek QPS)

Yüksek CPU kullanımı yüksek bir uygulama yükünden kaynaklanıyorsa SQL optimizasyonu için çok az alan vardır. Sorunu uygulama mimarisini veya örnek türünü ayarlayarak giderin. Aşağıdaki yöntemleri göz önünde bulundurun:

• Daha fazla CPU kaynağı eklemek için örnek türünü yükseltin. Daha fazla bilgi için bkz. Örnek yapılandırmalarını değiştirme.

• Salt okunur örnekler ekleyin. Ürün kategorisi veya tren tarifesi sorguları gibi veri tutarlılığına duyarlı olmayan sorguları salt okunur örneklere aktarın. Bu işlem birincil örneğin yükünü azaltır. Daha fazla bilgi için bkz. ApsaraDB RDS for MySQL salt okunur örneği oluşturma.

• Alibaba Cloud'un cloud-native dağıtılmış veritabanı olan PolarDB-X'i kullanın. Bu hizmet, sorgu yükünü birden çok RDS örneğine dağıtmak için otomatik olarak parçalama (sharding) gerçekleştirir.

• Alibaba Cloud Memcache veya Tair (Redis OSS uyumlu) kullanın. Sık kullanılan sorgu sonuçlarını önbellekten alarak RDS örneğinin yükünü azaltın.

• Nispeten statik verileri sorgulayan, sorgu tekrarı yüksek olan ve sonuç kümeleri 1 MB'tan küçük olan uygulamalar için sorgu önbelleğini etkinleştirmeyi düşünün.

  Not

  Sorgu önbelleğini etkinleştirmenin uygulamanız için yararlı olup olmadığını test edin. Ayarlar hakkında daha fazla bilgi için bkz. ApsaraDB RDS for MySQL için sorgu önbelleğini ayarlama ve kullanma.

• Geçmiş verileri düzenli olarak arşivleyin. Sorgular tarafından erişilen veri miktarını azaltmak için parçalama (sharding) veya bölümleme (partitioning) kullanın. Uygulama ölçeklenebilirliğini artırmak ve yürütme maliyetlerini düşürmek için sorguları optimize edin.

Yavaş SQL deyimlerinden kaynaklanan yüksek sorgu maliyetleri

Bu sorunu çözmenin temel ilkesi, verimsiz sorguları belirlemek, yürütme verimliliklerini optimize etmek ve yürütme maliyetlerini azaltmaktır.

1. Verimsiz sorguları aşağıdaki yollarla belirleyin:

   • Şu anda çalışan sorguları görüntülemek için aşağıdaki SQL deyimini çalıştırın.

     show processlist;
     show full processlist;

     Sistem aşağıdakine benzer bir çıktı görüntüler:

     mysql> show processlist;
     +----------+-------+-------------------+---------+---------+-------+--------------+----------------------------------------------+
     | Id       | User  | Host              | db      | Command | Time  | State        | Info                                         |
     +----------+-------+-------------------+---------+---------+-------+--------------+----------------------------------------------+
     |101031643 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
     |117731567 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
     |134298793 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
     |134384670 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   |     0 | Init         | show processlist                             |
     |234891284 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
     |235125098 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
     |235200576 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
     |235633985 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
     |235887773 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
     |251990394 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
     |252662718 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
     +----------+-------+-------------------+---------+---------+-------+--------------+----------------------------------------------+
     11 rows in set (0.00 sec)

     Uzun süre çalışan ve durumu Sending data, Copying to tmp table, Copying to tmp table on disk, Sorting result veya Using filesort olan sorgu oturumlarında performans sorunları olabilir.

     • Yüksek QPS'nin yüksek CPU kullanımına neden olduğu senaryolarda sorgular genellikle hızlı bir şekilde çalışır. Bu durum, bunları show processlist; komutuyla veya örnek oturumlarını görüntüleyerek yakalamayı zorlaştırabilir. Bu durumda aşağıdaki SQL deyimini çalıştırın:

       explain [$SQL]

       Not

       [$SQL], performans sorunları olan SQL sorgusudur.

     • Uzun süren bir oturumu durdurmak için kill [$ID]; gibi bir komut çalıştırabilirsiniz. Oturumları durdurma hakkında daha fazla bilgi için bkz. ApsaraDB RDS for MySQL örneğinde oturumları nasıl durdurulur.

       Not

       [$ID], sorguya karşılık gelen oturum kimliğidir.

   • Database Autonomy Service (DAS) kullanarak şu anda çalışan sorguları görüntüleyin:

     1. DAS konsolunda oturum açın.

     2. Soldaki gezinme bölmesinde Intelligent O&M Center > Instance Monitoring seçeneğini tıklayın.

     3. Hedef örneği bulun ve örnek ayrıntıları sayfasını açmak için örnek kimliğini tıklayın.

     4. Sol gezinme bölmesinde Instance Sessions öğesini tıklayın.

     5. Tam sorguyu ve yürütme planını görüntülemek için SQL sütunundaki sorgu metnini tıklayın.

2. Optimizasyon gerektiren sorguları belirledikten sonra, optimizasyon önerileri almak için DMS konsolundaki SQL Tanılama özelliğini kullanın. Tanılama raporu, geçmişteki yüksek CPU kullanımı sorunlarının giderilmesinde de faydalıdır:

   1. DMS konsolunda örnekte oturum açın. Daha fazla bilgi için bkz. Veritabanı örneğinde oturum açma.

   2. Sayfanın üst kısmında SQL Window seçeneğini tıklayın ve hedef veritabanını seçin.

   3. Sorguyu SQL penceresine yapıştırın ve optimizasyon önerilerini almak için SQL Diagnostics seçeneğini tıklayın.

3. Gerektiğinde optimizasyon önerilerini uygulayın. Örneğin, bir dizin eklemek sorgu yürütme maliyetlerini önemli ölçüde azaltabilir.

Daha fazla bilgi

Performans sorunlarını gidermeye yönelik özellikler

Data Management (DMS), örnek performans sorunlarını gidermenize ve çözmenize yardımcı olacak birkaç özellik sunar. Tanılama raporu, MySQL ve MariaDB örneklerindeki performans sorunlarını gidermek için en iyi araçtır. Nedenden bağımsız olarak öncelikle tanılama raporunu kontrol edin. Özellikle SQL optimizasyonu, oturum listesi ve yavaş SQL özeti bölümlerine dikkat edin.

• Tanılama raporu

• SQL tanılama

• Oturum yönetimi

%100 CPU kullanımını önleme ilkeleri

%100 CPU kullanımını önlemek için bu ilkeleri izleyin:

• Örneğinizin yeterli bir CPU tamponuna sahip olduğundan emin olmak için CPU kullanımı uyarıları ayarlayın.

• Uygulama tasarımı ve geliştirme sırasında sorgu optimizasyonunu göz önünde bulundurun. Mantıksal G/Ç'yi azaltmak ve uygulama ölçeklenebilirliğini artırmak için MySQL genel optimizasyon ilkelerini izleyin.

• Yeni bir özellik veya modül çevrimiçi hale gelmeden önce üretim verileriyle stres testi gerçekleştirin .

• Yeni bir özellik veya modül çevrimiçi hale gelmeden önce üretim verileriyle regresyon testi gerçekleştirin.

Sistem kaynağı algoritması

Aşağıdaki basitleştirilmiş model, sistem kaynakları, SQL deyimi yürütme maliyetleri ve saniyedeki sorgu sayısı (QPS) arasındaki ilişkiyi açıklamaktadır:

• Koşul: Uygulama modeli sabittir, yani uygulama değiştirilmez.

• avg_lgc_io: Her bir sorguyu yürütmek için gereken ortalama mantıksal G/Ç.

• total_lgc_io: Örnek CPU kaynaklarının birim zaman başına işleyebileceği toplam mantıksal G/Ç.

• Formül: total_lgc_io = avg_lgc_io × QPS. Bu, Birim zaman başına toplam CPU kaynağı = Sorgu başına ortalama mantıksal G/Ç × Birim zaman başına sorgu sayısı anlamına gelir.

Başvurular

Autonomy service kullanarak ApsaraDB RDS for MySQL örneğinde yüksek CPU kullanımını çözme

Uygulanabilir sürümler

• ApsaraDB RDS for MySQL

• ApsaraDB RDS for MariaDB