MySQL için Azure Veritabanı - Esnek Sunucuda yüksek CPU kullanımı sorunlarını giderme
ŞUNLAR IÇIN GEÇERLIDIR:
MySQL için Azure Veritabanı - Tek Sunucu MySQL için Azure Veritabanı - Esnek Sunucu
Önemli
MySQL için Azure Veritabanı tek sunucu kullanımdan kaldırma yolundadır. Esnek MySQL için Azure Veritabanı sunucuya yükseltmenizi kesinlikle öneririz. MySQL için Azure Veritabanı esnek sunucuya geçiş hakkında daha fazla bilgi için bkz. MySQL için Azure Veritabanı Tek Sunucu'ya neler oluyor?
MySQL için Azure Veritabanı esnek sunucu, sunucudaki kaynak performans sorunlarını ve performans sorunlarını belirlemek için kullanabileceğiniz bir dizi ölçüm sağlar. Sunucunuzun yüksek CPU kullanımıyla karşılaşıp karşılaşmadığını belirlemek için "Konak CPU yüzdesi", "Toplam Bağlan ions", "Konak Bellek Yüzdesi" ve "GÇ Yüzdesi" gibi ölçümleri izleyin. Bazen bu ölçümlerin bir bileşimini görüntülemek, MySQL için Azure Veritabanı esnek sunucu örneğinizde artan CPU kullanımına neyin neden olabileceğine ilişkin içgörüler sağlar.
Örneğin, CPU kullanımının artmasına neden olan veritabanı sorgularının artışını başlatan bağlantılarda ani bir artış olduğunu düşünün.
Ölçümleri yakalamanın yanı sıra, bir veya daha fazla sorgunun CPU kullanımında ani artışa neden olup olmadığını anlamak için iş yükünü izlemek de önemlidir.
Yüksek CPU nedenleri
CPU ani artışları, öncelikle bağlantılardaki ani artışlar ve kötü yazılmış SQL sorgularından veya her ikisinin birleşiminden kaynaklanabilir:
Bağlantılarda ani artış
Bağlantılarda artış, iş parçacıklarında artışa neden olabilir ve bu da sorgular ve kaynaklarıyla birlikte bu bağlantıları yönetmek zorunda olduğu için CPU kullanımında artışa neden olabilir. Bağlantılardaki ani artışlarla ilgili sorunları gidermek için Toplam Bağlan ions ölçümünü denetlemeniz ve bu bağlantılar hakkında daha fazla bilgi için sonraki bölüme bakmanız gerekir. Şu anda sunucuya bağlı konakları ve kullanıcıları tanımlamak için aşağıdaki komutlarla performance_schema kullanabilirsiniz:
Geçerli bağlı konaklar
select HOST,CURRENT_CONNECTIONS From performance_schema.hosts
where CURRENT_CONNECTIONS > 0
and host not in ('NULL','localhost');
Geçerli bağlı kullanıcılar
select USER,CURRENT_CONNECTIONS from performance_schema.users
where CURRENT_CONNECTIONS >0
and USER not in ('NULL','azure_superuser');
Kötü yazılmış SQL sorguları
Dizin olmadan çok sayıda satırı yürütmek ve taramak için pahalı olan sorgular veya diğer verimsiz planlarla birlikte geçici sıralamalar gerçekleştiren sorgular, CPU artışlarına neden olabilir. Bazı sorgular tek bir oturumda hızla yürütülse de birden çok oturumda çalıştırıldığında CPU ani artışlarına neden olabilir. Bu nedenle, show processlist'ten yakaladığınız sorgularınızı her zaman açıklamak ve yürütme planlarının verimli olduğundan emin olmak çok önemlidir. Bu, filtreleri/where yan tümcesini kullanarak en az sayıda satırı taramalarını, dizinleri kullanmalarını ve diğer hatalı yürütme planlarıyla birlikte büyük geçici sıralama kullanmaktan kaçınmalarını sağlayarak elde edilebilir. Yürütme planları hakkında daha fazla bilgi için bkz . EXPLAIN Output Format.
Geçerli iş yükünün ayrıntılarını yakalama
SHOW (FULL) PROCESSLIST komutu, şu anda MySQL için Azure Veritabanı esnek sunucu örneğine bağlı olan tüm kullanıcı oturumlarının listesini görüntüler. Ayrıca, her oturumun geçerli durumu ve etkinliği hakkında ayrıntılar sağlar.
Bu komut yalnızca geçerli oturum durumunun anlık görüntüsünü oluşturur ve geçmiş oturum etkinliği hakkında bilgi sağlamaz.
Şimdi bu komutu çalıştırmanın örnek çıktısına göz atalım.
mysql> SHOW FULL PROCESSLIST;
+-------+------------------+--------------------+---------------+-------------+--------+-----------------------------+------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-------+------------------+--------------------+---------------+-------------+--------+-----------------------------+------------------------------------------+
| 1 | event_scheduler | localhost | NULL | Daemon | 13 | Waiting for next activation | NULL |
| 6 | azure_superuser | 127.0.0.1:33571 | NULL | Sleep | 115 | | NULL
|
| 24835 | adminuser | 10.1.1.4:39296 | classicmodels | Query | 7 | Sending data | select * from classicmodels.orderdetails;|
| 24837 | adminuser | 10.1.1.4:38208 | NULL | Query | 0 | starting | SHOW FULL PROCESSLIST |
+-------+------------------+--------------------+---------------+-------------+--------+-----------------------------+------------------------------------------+
5 rows in set (0.00 sec)
Müşteriye ait "adminuser" kullanıcısının sahip olduğu iki oturum olduğuna ve her ikisinin de aynı IP adresinden olduğuna dikkat edin:
- Oturum 24835 son yedi saniyedir bir SELECT deyimi yürütüyor.
- Oturum 24837 , "tam işlem listesini göster" deyimini yürütüyor.
Gerektiğinde, üretim iş yükü CPU kullanımınızda ani artışa neden olan raporlama veya HTAP sorgusu gibi bir sorguyu sonlandırmak gerekebilir. Ancak, CPU kullanımını azaltma girişiminde bulunan eylemi gerçekleştirmeden önce her zaman sorguyu sonlandırmanın olası sonuçlarını göz önünde bulundurun. Diğer durumlarda, CPU ani artışlarına yol açan uzun süre çalışan sorgular varsa, kaynakların en iyi şekilde kullanılması için bu sorguları ayarlayın.
Ayrıntılı geçerli iş yükü analizi
Oturum, işlem ve sorgunun durumu hakkında doğru bilgi edinmek için en az iki bilgi kaynağı kullanmanız gerekir:
- sunucunun INFORMATION_SCHEMA işlem listesi. SHOW [FULL] PROCESSLIST komutunu çalıştırarak da erişebileceğiniz PROCESSLIST tablosu.
- InnoDB'nin INFORMATION_SCHEMA işlem meta verileri. INNODB_TRX tablo.
Bu kaynaklardan yalnızca birinden alınan bilgilerle bağlantı ve işlem durumunu açıklamak mümkün değildir. Örneğin, işlem listesi oturumlardan herhangi biriyle ilişkilendirilmiş açık bir işlem olup olmadığını size bildirmez. Öte yandan, işlem meta verileri oturum durumunu ve bu durumda harcanan zamanı göstermez.
İşlem listesi bilgilerini InnoDB işlem meta verilerinin bazı önemli parçalarıyla birleştiren aşağıdaki örnek sorgu:
mysql> select p.id as session_id, p.user, p.host, p.db, p.command, p.time, p.state, substring(p.info, 1, 50) as info, t.trx_started, unix_timestamp(now()) - unix_timestamp(t.trx_started) as trx_age_seconds, t.trx_rows_modified, t.trx_isolation_level from information_schema.processlist p left join information_schema.innodb_trx t on p.id = t.trx_mysql_thread_id \G
Aşağıdaki örnekte bu sorgunun çıktısı gösterilmektedir:
*************************** 1. row ***************************
session_id: 11
user: adminuser
host: 172.31.19.159:53624
db: NULL
command: Sleep
time: 636
state: cleaned up
info: NULL
trx_started: 2019-08-01 15:25:07
trx_age_seconds: 2908
trx_rows_modified: 17825792
trx_isolation_level: REPEATABLE READ
*************************** 2. row ***************************
session_id: 12
user: adminuser
host: 172.31.19.159:53622
db: NULL
command: Query
time: 15
state: executing
info: select * from classicmodels.orders
trx_started: NULL
trx_age_seconds: NULL
trx_rows_modified: NULL
trx_isolation_level: NULL
Oturuma göre bu bilgilerin analizi aşağıdaki tabloda listelenmiştir.
| Alan | Analiz |
|---|---|
| Oturum 11 | Bu oturum şu anda boşta (uykuda) ve çalışan sorgu yok ve 636 saniyedir. Oturumda, 2908 saniye boyunca açık olan bir işlem 17.825.792 satırı değiştirdi ve REPEATABLE READ yalıtımını kullanıyor. |
| Oturum 12 | Oturum şu anda 15 saniye boyunca çalışan bir SELECT deyimini yürütüyor. trx_started ve trx_age_seconds için NULL değerleriyle gösterildiği gibi oturum içinde çalıştırılan bir sorgu yoktur. Oturum, daha rahat READ COMMITTED yalıtımını kullanmadığı sürece çalıştığı sürece çöp toplama sınırını tutmaya devam eder. |
Bir oturum boşta olarak bildirilirse artık herhangi bir deyimi yürütmediğini unutmayın. Bu noktada, oturum önceki tüm çalışmaları tamamlamış ve istemciden yeni deyimler bekliyor. Ancak boşta kalan oturumlar hala bazı CPU tüketiminden ve bellek kullanımından sorumludur.
Açık işlemleri listeleme
Aşağıdaki sorgudan elde edilen çıktı, işlem başlangıç zamanı sırasına göre veritabanı sunucusunda çalışmakta olan tüm işlemlerin listesini sağlar, böylece beklenen çalışma zamanını aşan uzun süre çalışan ve engelleyen işlemler olup olmadığını kolayca belirleyebilirsiniz.
SELECT trx_id, trx_mysql_thread_id, trx_state, Unix_timestamp() - ( To_seconds(trx_started) - To_seconds('1970-01-01 00:00:00') ) AS trx_age_seconds, trx_weight, trx_query, trx_tables_in_use, trx_tables_locked, trx_lock_structs, trx_rows_locked, trx_rows_modified, trx_isolation_level, trx_unique_checks, trx_is_read_only FROM information_schema.innodb_trx ORDER BY trx_started ASC;
İş parçacığı durumlarını anlama
Yürütme sırasında daha yüksek CPU kullanımına katkıda bulunan işlemler, aşağıdaki bölümlerde açıklandığı gibi çeşitli durumlarda iş parçacıklarına sahip olabilir. Sorgu yaşam döngüsünü ve çeşitli iş parçacığı durumlarını daha iyi anlamak için bu bilgileri kullanın.
İzinleri denetleme/Tabloları açma
Bu durum genellikle açık tablo işleminin uzun zaman harcadığı anlamına gelir. Genellikle, sorunu geliştirmek için tablo önbelleği boyutunu artırabilirsiniz. Ancak tabloların yavaş açılması, aynı veritabanı altında çok fazla tablo olması gibi diğer sorunların da göstergesi olabilir.
Veri gönderme
Bu durum iş parçacığının ağ üzerinden veri gönderdiği anlamına gelebilir ancak sorgunun diskten veya bellekten veri okuduğu anlamına da gelebilir. Bu duruma sıralı tablo taraması neden olabilir. Diskten belleğe çok sayıda sayfa sunulup sunulmadığını belirlemek için innodb_buffer_pool_reads ve innodb_buffer_pool_read_requests değerlerini denetlemeniz gerekir. Daha fazla bilgi için bkz. Esnek MySQL için Azure Veritabanı sunucuda yetersiz bellek sorunlarını giderme.
Güncelleştirme
Bu durum genellikle iş parçacığının bir yazma işlemi gerçekleştirdiğini gösterir. Geçerli oturumların ne yaptığını daha iyi anlamak için Performans İzleyicisi GÇ ile ilgili ölçümü denetleyin.
lock_type> kilidi bekleniyor <
Bu durum, iş parçacığının ikinci bir kilit beklediğini gösterir. Çoğu durumda bu bir meta veri kilidi olabilir. Diğer tüm iş parçacıklarını gözden geçirmeli ve kilidi kimin aldığını görmelisiniz.
Bekleme olaylarını anlama ve analiz etme
MySQL altyapısında temel alınan bekleme olaylarını anlamak önemlidir, çünkü veritabanında uzun beklemeler veya çok fazla bekleme sayısı CPU kullanımının artmasına neden olabilir. Aşağıdaki örnekte uygun komut ve örnek çıktı gösterilmektedir.
SELECT event_name AS wait_event,
count_star AS all_occurrences,
Concat(Round(sum_timer_wait / 1000000000000, 2), ' s') AS total_wait_time,
Concat(Round(avg_timer_wait / 1000000000, 2), ' ms') AS
avg_wait_time
FROM performance_schema.events_waits_summary_global_by_event_name
WHERE count_star > 0 AND event_name <> 'idle'
ORDER BY sum_timer_wait DESC LIMIT 10;
+--------------------------------------+-----------------+-----------------+---------------+
| wait_event | all_occurrences | total_wait_time | avg_wait_time |
+--------------------------------------+-----------------+-----------------+---------------+
| wait/io/file/sql/binlog | 7090 | 255.54 s | 36.04 ms |
| wait/io/file/innodb/innodb_log_file | 17798 | 55.43 s | 3.11 ms |
| wait/io/file/innodb/innodb_data_file | 260227 | 39.67 s | 0.15 ms |
| wait/io/table/sql/handler | 5548985 | 11.73 s | 0.00 ms |
| wait/io/file/sql/FRM | 1237 | 7.61 s | 6.15 ms |
| wait/io/file/sql/dbopt | 28 | 1.89 s | 67.38 ms |
| wait/io/file/myisam/kfile | 92 | 0.76 s | 8.30 ms |
| wait/io/file/myisam/dfile | 271 | 0.53 s | 1.95 ms |
| wait/io/file/sql/file_parser | 18 | 0.32 s | 17.75 ms |
| wait/io/file/sql/slow_log | 2 | 0.05 s | 25.79 ms |
+--------------------------------------+-----------------+-----------------+---------------+
10 rows in set (0.00 sec)
SELECT Deyimleri yürütme süresini kısıtlama
SELECT sorguları içeren veritabanı işlemlerinin yürütme maliyetini ve yürütme süresini bilmiyorsanız, uzun süre çalışan SELECT'ler veritabanı sunucusunda öngörülemezliğe veya değişkenliğe yol açabilir. Deyim ve işlemlerin boyutu ve ilişkili kaynak kullanımı, temel alınan veri kümesi büyümesine bağlı olarak büyümeye devam eder. Bu ilişkisiz büyüme nedeniyle, son kullanıcı deyimleri ve işlemleri daha uzun sürer ve veritabanı sunucusunu bunaltana kadar giderek daha fazla kaynak tüketir. İlişkisiz SELECT sorguları kullanılırken, bu süreyi aşan tüm sorguların durdurulması için max_execution_time parametresinin yapılandırılması önerilir.
Öneriler
- Veritabanınızda sorgularınızı çalıştırmak için yeterli kaynak ayrıldığınızdan emin olun. Bazen iş yükünüz için daha fazla CPU çekirdeği elde etmek için örnek boyutunu artırmanız gerekebilir.
- Büyük veya uzun süre çalışan işlemleri daha küçük işlemlere ayırarak önleyin.
- Mümkün olduğunda okuma amaçlı çoğaltma sunucularında SELECT deyimlerini çalıştırın.
- Sistem belirtilen eşiklerden herhangi birini aşarsa bildirim almak için "Konak CPU Yüzdesi" uyarılarını kullanın.
- Sorunlu veya yavaş çalışan sorguları belirlemek ve ardından bunları iyileştirmek için Sorgu Performansı Analizler veya Azure Çalışma Kitapları'nı kullanın.
- Üretim veritabanı sunucuları için, her şeyin sorunsuz çalıştığından emin olmak için düzenli aralıklarla tanılamaları toplayın. Aksi takdirde, tanımladığınız sorunları giderin ve çözün.
Sonraki adımlar
En önemli sorularınızın eş yanıtlarını bulmak veya soru göndermek veya yanıtlamak için Stack Overflow'u ziyaret edin.