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

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ğlantılar", "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ılarda ani artış sorununu gidermek için Toplam Bağlantı ölçümüne bakmanız 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.

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ı İçgörüleri'ni 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.