Berurusan dengan MySQL Long Running Query

Kueri/pernyataan/transaksi yang berjalan lama terkadang tidak dapat dihindari di lingkungan MySQL. Dalam beberapa kesempatan, kueri yang berjalan lama bisa menjadi katalis untuk peristiwa yang membawa malapetaka. Jika Anda peduli dengan database Anda, mengoptimalkan kinerja kueri dan mendeteksi kueri yang berjalan lama harus dilakukan secara teratur. Hal-hal menjadi lebih sulit ketika beberapa instance dalam grup atau cluster terlibat.

Saat berhadapan dengan banyak node, tugas berulang untuk memeriksa setiap node adalah sesuatu yang harus kita hindari. ClusterControl memantau beberapa aspek server database Anda, termasuk kueri. ClusterControl mengumpulkan semua informasi terkait kueri dari semua node dalam grup atau cluster untuk memberikan tampilan beban kerja yang terpusat. Ada cara yang bagus untuk memahami cluster Anda secara keseluruhan dengan sedikit usaha.

Dalam posting blog ini, kami menunjukkan cara mendeteksi query MySQL yang berjalan lama menggunakan ClusterControl.

Mengapa Kueri Membutuhkan Waktu Lebih Lama?

Pertama-tama, kita harus mengetahui sifat kueri, apakah kueri yang diharapkan berjalan lama atau berjalan singkat. Beberapa operasi analitik dan batch seharusnya merupakan kueri yang berjalan lama, jadi kami dapat melewatinya untuk saat ini. Juga, tergantung pada ukuran tabel, memodifikasi struktur tabel dengan perintah ALTER dapat menjadi operasi yang berjalan lama.

Untuk transaksi jangka pendek, itu harus dilakukan secepat mungkin, biasanya dalam hitungan subdetik. Semakin pendek semakin baik. Ini dilengkapi dengan seperangkat aturan praktik terbaik kueri yang harus diikuti pengguna, seperti menggunakan pengindeksan yang tepat dalam pernyataan WHERE atau JOIN, menggunakan mesin penyimpanan yang tepat, memilih tipe data yang tepat, menjadwalkan operasi batch selama jam tidak sibuk, membongkar analitik /melaporkan lalu lintas ke replika khusus, dan seterusnya.

Ada beberapa hal yang dapat menyebabkan kueri membutuhkan waktu lebih lama untuk dieksekusi:

Kueri tidak efisien - Gunakan kolom yang tidak diindeks saat mencari atau bergabung, sehingga MySQL membutuhkan waktu lebih lama untuk menyesuaikan kondisi.
Kunci tabel - Tabel dikunci, dengan kunci global atau kunci tabel eksplisit saat kueri mencoba mengaksesnya.
Deadlock - Sebuah kueri menunggu untuk mengakses baris yang sama yang dikunci oleh kueri lain.
Set data tidak cocok dengan RAM - Jika data set kerja Anda cocok dengan cache itu, maka kueri SELECT biasanya akan relatif cepat.
Sumber daya perangkat keras yang kurang optimal - Ini bisa berupa disk lambat, pembangunan kembali RAID, jaringan jenuh, dll.
Operasi pemeliharaan - Menjalankan mysqldump dapat membawa sejumlah besar data yang tidak digunakan ke dalam kumpulan buffer, dan pada saat yang sama data (yang mungkin berguna) yang sudah ada akan dikeluarkan dan dibuang ke disk.

Daftar di atas menekankan bukan hanya kueri itu sendiri yang menyebabkan segala macam masalah. Ada banyak alasan yang memerlukan melihat aspek yang berbeda dari server MySQL. Dalam beberapa skenario kasus yang lebih buruk, kueri yang berjalan lama dapat menyebabkan gangguan layanan total seperti server down, server crash dan koneksi maksimal. Jika Anda melihat kueri membutuhkan waktu lebih lama dari biasanya untuk dieksekusi, lakukan selidiki.

Bagaimana Cara Memeriksa?

DAFTAR PROSES

MySQL menyediakan sejumlah alat bawaan untuk memeriksa transaksi yang berjalan lama. Pertama-tama, perintah SHOW PROCESSLIST atau SHOW FULL PROCESSLIST dapat mengekspos kueri yang sedang berjalan secara real-time. Berikut adalah screenshot dari fitur ClusterControl Running Queries, mirip dengan perintah SHOW FULL PROCESSLIST (tetapi ClusterControl menggabungkan semua proses menjadi satu tampilan untuk semua node dalam cluster):

Seperti yang Anda lihat, kami dapat langsung melihat kueri ofensif langsung dari output. Tapi seberapa sering kita menatap proses itu? Ini hanya berguna jika Anda mengetahui transaksi yang berjalan lama. Jika tidak, Anda tidak akan tahu sampai sesuatu terjadi - seperti koneksi menumpuk, atau server menjadi lebih lambat dari biasanya.

Log Kueri Lambat

Log kueri lambat menangkap kueri lambat (pernyataan SQL yang memakan waktu lebih dari long_query_time detik untuk dieksekusi), atau kueri yang tidak menggunakan indeks untuk pencarian (log_queries_not_using_indexes ). Fitur ini tidak diaktifkan secara default dan untuk mengaktifkannya cukup atur baris berikut dan mulai ulang server MySQL:

[mysqld]
slow_query_log=1
long_query_time=0.1
log_queries_not_using_indexes=1

Log kueri lambat dapat digunakan untuk menemukan kueri yang membutuhkan waktu lama untuk dieksekusi dan oleh karena itu merupakan kandidat untuk pengoptimalan. Namun, memeriksa log kueri yang panjang dan lambat bisa menjadi tugas yang memakan waktu. Ada alat untuk mengurai file log kueri lambat MySQL dan meringkas kontennya seperti mysqldumpslow, pt-query-digest, atau Kueri Teratas ClusterControl.

ClusterControl Top Query merangkum kueri lambat menggunakan dua metode - log kueri lambat MySQL atau Skema Kinerja:

Anda dapat dengan mudah melihat ringkasan ringkasan pernyataan yang dinormalisasi, diurutkan berdasarkan sejumlah kriteria:

Tuan rumah
Kejadian
Total waktu eksekusi
Waktu eksekusi maksimum
Waktu eksekusi rata-rata
Waktu simpangan baku

Kami telah membahas fitur ini dengan sangat rinci dalam posting blog ini, Cara menggunakan Monitor Kueri ClusterControl untuk Server MySQL, MariaDB, dan Percona.

Skema Kinerja

Skema Kinerja adalah alat hebat yang tersedia untuk memantau internal Server MySQL dan detail eksekusi di tingkat yang lebih rendah. Tabel berikut dalam Skema Kinerja dapat digunakan untuk menemukan kueri lambat:

events_statements_current
events_statements_history
events_statements_history_long
events_statements_summary_by_digest
events_statements_summary_by_user_by_event_name
events_statements_summary_by_host_by_event_name

MySQL 5.7.7 dan yang lebih tinggi menyertakan skema sys, satu set objek yang membantu DBA dan pengembang menafsirkan data yang dikumpulkan oleh Skema Kinerja ke dalam bentuk yang lebih mudah dipahami. Objek skema sistem dapat digunakan untuk kasus penggunaan penyetelan dan diagnosis yang khas.

ClusterControl menyediakan penasihat, yang merupakan program mini yang dapat Anda tulis menggunakan ClusterControl DSL (mirip dengan JavaScript) untuk memperluas kemampuan pemantauan ClusterControl yang disesuaikan dengan kebutuhan Anda. Ada sejumlah skrip yang disertakan berdasarkan Skema Kinerja yang dapat Anda gunakan untuk memantau kinerja kueri seperti menunggu I/O, mengunci waktu tunggu, dan sebagainya. Misalnya di bawah Kelola -> Developer Studio , buka s9s -> mysql -> p_s -> top_tables_by_iowait.js dan klik tombol "Kompilasi dan Jalankan". Anda akan melihat output di bawah tab Pesan untuk 10 tabel teratas yang diurutkan berdasarkan I/O, tunggu per server:

Ada sejumlah skrip yang dapat Anda gunakan untuk memahami informasi tingkat rendah di mana dan mengapa kelambatan terjadi seperti top_tables_by_lockwait.js , top_accessed_db_files.js dan seterusnya.

ClusterControl - Mendeteksi dan memperingatkan kueri yang berjalan lama

Dengan ClusterControl, Anda akan mendapatkan fitur canggih tambahan yang tidak akan Anda temukan di instalasi MySQL standar. ClusterControl dapat dikonfigurasi untuk secara proaktif memantau proses yang berjalan, dan membunyikan alarm dan mengirim pemberitahuan kepada pengguna jika ambang batas kueri yang panjang terlampaui. Ini dapat dikonfigurasi dengan menggunakan Konfigurasi Runtime di bawah Pengaturan:

Untuk pra1.7.1, nilai default untuk query_monitor_alert_long_running_query adalah palsu. Kami mendorong pengguna untuk mengaktifkan ini dengan menyetelnya ke 1 (benar). Untuk membuatnya persisten, tambahkan baris berikut ke /etc/cmon.d/cmon_X.cnf:

query_monitor_alert_long_running_query=1
query_monitor_long_running_query_ms=30000

Setiap perubahan yang dibuat di Konfigurasi Runtime diterapkan segera dan tidak diperlukan restart. Anda akan melihat sesuatu seperti ini di bawah bagian Alarm jika kueri melebihi ambang batas 30000ms (30 detik):

Jika Anda mengonfigurasi pengaturan penerima email sebagai "Kirim" untuk kategori keparahan DbComponent plus CRITICAL (seperti yang ditunjukkan pada tangkapan layar berikut):

Anda harus mendapatkan salinan alarm ini di email Anda. Jika tidak, itu dapat diteruskan secara manual dengan mengklik tombol "Kirim Email".

Selanjutnya, Anda dapat memfilter segala jenis sumber daya daftar proses yang cocok dengan kriteria tertentu dengan ekspresi reguler (regex). Misalnya, jika Anda ingin ClusterControl mendeteksi kueri yang berjalan lama untuk tiga pengguna MySQL yang disebut 'sbtest', 'myshop', dan 'db_user1', hal berikut harus dilakukan:

Setiap perubahan yang dibuat di Konfigurasi Runtime diterapkan segera dan tidak diperlukan restart.

Selain itu, ClusterControl akan mencantumkan semua transaksi kebuntuan bersama dengan status InnoDB saat terjadi di bawah Kinerja -> Log Transaksi :

Fitur ini tidak diaktifkan secara default, karena deteksi deadlock akan mempengaruhi penggunaan CPU pada node database. Untuk mengaktifkannya, cukup centang kotak "Enable Transaction Log" dan tentukan interval yang Anda inginkan. Untuk membuatnya persisten, tambahkan variabel dengan nilai dalam hitungan detik di dalam /etc/cmon.d/cmon_X.cnf:

db_deadlock_check_interval=30

Demikian pula, jika Anda ingin memeriksa status InnoDB, cukup buka Kinerja -> Status InnoDB , dan pilih server MySQL dari dropdown. Misalnya:

Ini dia - semua informasi yang diperlukan dapat diperoleh dengan mudah dalam beberapa klik.

Ringkasan

Transaksi yang berjalan lama dapat menyebabkan penurunan kinerja, server down, koneksi maksimal dan kebuntuan. Dengan ClusterControl, Anda dapat mendeteksi kueri yang berjalan lama langsung dari UI, tanpa perlu memeriksa setiap node MySQL dalam cluster.