Performa kueri yang buruk adalah masalah paling umum yang harus dihadapi DBA. Ada banyak cara untuk mengumpulkan, memproses, dan menganalisis data yang terkait dengan kinerja kueri - kami telah membahas salah satu alat paling populer, pt-query-digest, di beberapa entri blog kami sebelumnya:
Menjadi seri blog MySQL DBA
- Menganalisis Beban Kerja SQL Anda menggunakan pt-query-digest
- Analisis Beban Kerja SQL Menyelam Mendalam menggunakan pt-query-digest
Saat Anda menggunakan ClusterControl, ini tidak selalu diperlukan. Anda dapat menggunakan data yang tersedia di ClusterControl untuk menyelesaikan masalah Anda. Dalam posting blog ini, kita akan melihat bagaimana ClusterControl dapat membantu Anda memecahkan masalah yang terkait dengan kinerja kueri.
Mungkin saja kueri tidak dapat diselesaikan tepat waktu. Kueri mungkin macet karena beberapa masalah penguncian, mungkin tidak optimal atau tidak diindeks dengan benar atau mungkin terlalu berat untuk diselesaikan dalam waktu yang wajar. Ingatlah bahwa beberapa gabungan yang tidak diindeks dapat dengan mudah memindai miliaran baris jika Anda memiliki basis data produksi yang besar. Apa pun yang terjadi, kueri mungkin menggunakan beberapa sumber daya - baik itu CPU atau I/O untuk kueri yang tidak dioptimalkan atau bahkan hanya kunci baris. Sumber daya tersebut juga diperlukan untuk kueri lain dan ini dapat memperlambat segalanya. Salah satu tugas yang sangat sederhana namun penting adalah menentukan kueri yang menyinggung dan menghentikannya.
Ini cukup mudah dilakukan dari antarmuka ClusterControl. Buka tab Query Monitor -> bagian Running Query - Anda akan melihat output yang mirip dengan screenshot di bawah ini.
Seperti yang Anda lihat, kami memiliki setumpuk pertanyaan yang macet. Biasanya kueri yang menyinggung adalah kueri yang membutuhkan waktu lama, Anda mungkin ingin mematikannya. Anda mungkin juga ingin menyelidikinya lebih lanjut untuk memastikan Anda memilih yang benar. Dalam kasus kami, kami dengan jelas melihat SELECT … FOR UPDATE yang menggabungkan beberapa tabel dan yang berada dalam status 'Mengirim data' yang berarti sedang memproses data, selama 90 detik terakhir.
Jenis pertanyaan lain yang mungkin perlu dijawab oleh DBA adalah - kueri mana yang membutuhkan waktu paling lama untuk dieksekusi? Ini adalah pertanyaan umum, karena kueri semacam itu mungkin merupakan buah yang menggantung rendah - kueri tersebut dapat dioptimalkan, dan semakin banyak waktu eksekusi yang menjadi tanggung jawab kueri tertentu dalam keseluruhan campuran kueri, semakin besar keuntungan dari pengoptimalannya. Ini adalah persamaan sederhana - jika kueri bertanggung jawab atas 50% dari total waktu eksekusi, membuatnya 10x lebih cepat akan memberikan hasil yang jauh lebih baik daripada mengoptimalkan kueri yang hanya bertanggung jawab untuk 1% dari total waktu eksekusi.
ClusterControl dapat membantu Anda menjawab pertanyaan seperti itu, tetapi pertama-tama kita perlu memastikan Monitor Kueri diaktifkan. Anda dapat mengaktifkan Monitor Kueri ke AKTIF di bawah halaman Monitor Kueri. Selanjutnya, Anda dapat mengonfigurasi opsi "Waktu Kueri Lama" dan "Log kueri yang tidak menggunakan indeks" di bawah Setelan agar sesuai dengan beban kerja Anda:
Monitor Kueri di ClusterControl bekerja dalam dua mode, bergantung pada apakah Anda memiliki Skema Kinerja yang tersedia dengan data yang diperlukan pada kueri yang sedang berjalan atau tidak. Jika tersedia (dan ini benar secara default di MySQL 5.6 dan yang lebih baru), Skema Kinerja akan digunakan untuk mengumpulkan data kueri, meminimalkan dampak pada sistem. Jika tidak, log kueri lambat akan digunakan dan semua pengaturan yang terlihat pada tangkapan layar di atas digunakan. Itu dijelaskan dengan cukup baik di UI, jadi tidak perlu melakukannya di sini. Saat Monitor Kueri menggunakan Skema Kinerja, setelan tersebut tidak digunakan (kecuali untuk mengaktifkan/MENONAKTIFKAN Monitor Kueri untuk mengaktifkan/menonaktifkan pengumpulan data).
Saat Anda mengonfirmasi bahwa Monitor Kueri diaktifkan di ClusterControl, Anda bisa pergi ke Monitor Kueri -> Kueri Teratas, di mana Anda akan disajikan dengan layar yang mirip dengan di bawah ini:
Apa yang dapat Anda lihat di sini adalah daftar kueri paling mahal (dalam hal waktu eksekusi) yang mengenai klaster kami. Masing-masing dari mereka memiliki beberapa detail lebih lanjut - berapa kali dieksekusi, berapa banyak baris yang diperiksa atau dikirim ke klien, bagaimana waktu eksekusi bervariasi, berapa banyak waktu yang dihabiskan cluster untuk mengeksekusi jenis kueri tertentu. Kueri dikelompokkan menurut jenis dan skema kueri.
Anda mungkin terkejut mengetahui bahwa tempat utama di mana waktu eksekusi dihabiskan adalah kueri 'COMMIT'. Sebenarnya, ini cukup khas untuk kueri OLTP cepat yang dieksekusi di kluster Galera. Melakukan transaksi adalah proses yang mahal karena sertifikasi harus terjadi. Hal ini menyebabkan COMMIT menjadi salah satu kueri yang paling memakan waktu dalam campuran kueri.
Saat Anda mengklik kueri, Anda dapat melihat kueri lengkap, waktu eksekusi maksimum, jumlah kemunculan, beberapa petunjuk pengoptimalan umum, dan output JELASKAN untuknya - cukup berguna untuk mengidentifikasi jika ada yang salah dengan kueri tersebut. Dalam contoh kami, kami telah memeriksa SELECT ... FOR UPDATE dengan jumlah baris yang diperiksa. Seperti yang diharapkan, kueri ini adalah contoh SQL yang mengerikan - GABUNG yang tidak menggunakan indeks apa pun. Anda dapat melihat pada output EXPLAIN bahwa tidak ada indeks yang digunakan, bahkan tidak ada satu pun yang dianggap mungkin untuk digunakan. Tidak heran jika kueri ini sangat memengaruhi kinerja cluster kami.
Cara lain untuk mendapatkan wawasan tentang kinerja kueri adalah dengan melihat Query Monitor -> Query Outliers. Ini pada dasarnya adalah daftar kueri yang kinerjanya sangat berbeda dari rata-ratanya.
Seperti yang Anda lihat pada tangkapan layar di atas, kueri kedua membutuhkan waktu 0,01116 detik (waktu ditampilkan dalam milidetik) di mana waktu eksekusi rata-rata untuk kueri tersebut jauh lebih rendah (0,000142 detik). Kami juga memiliki beberapa info statistik tambahan tentang standar deviasi dan waktu eksekusi kueri maksimum. Daftar kueri seperti itu mungkin tampak tidak terlalu berguna - itu tidak sepenuhnya benar. Saat Anda melihat kueri di daftar ini, itu berarti ada sesuatu yang berbeda dari biasanya - kueri tidak selesai dalam waktu yang teratur. Ini mungkin merupakan indikasi dari beberapa masalah kinerja pada sistem Anda dan sinyal bahwa Anda harus menyelidiki metrik lain, dan memeriksa apakah ada hal lain yang terjadi pada saat itu.
Orang cenderung fokus pada pencapaian kinerja maksimal, lupa bahwa memiliki throughput yang tinggi tidak cukup - tetapi juga harus konsisten. Pengguna menyukai kinerja yang stabil - Anda mungkin dapat memeras lebih banyak transaksi per detik dari sistem Anda, tetapi jika itu berarti beberapa transaksi akan mulai terhenti selama beberapa detik, itu tidak sepadan. Melihat Histogram Kueri di ClusterControl membantu Anda mengidentifikasi masalah konsistensi seperti itu dalam campuran kueri Anda.
Selamat memantau kueri!
PS.:Untuk memulai ClusterControl, klik di sini!
