Setelah node akses frontend dari kluster AnalyticDB for MySQL menerima permintaan kueri, kluster membagi kueri menjadi beberapa tahap. Data kemudian dibaca dan dihitung secara terdistribusi pada node pekerja dan node eksekutor. Beberapa tahap dapat dieksekusi secara paralel, sementara tahap lain dengan dependensi hanya dapat dieksekusi secara seri. Akibatnya, pernyataan SQL yang kompleks dapat menyebabkan masalah kueri lambat. Anda dapat menggunakan detail tahap dan tugas untuk menganalisis masalah ini melalui operasi API atau di konsol AnalyticDB for MySQL. Topik ini menjelaskan cara menggunakan detail tahap dan tugas untuk menganalisis kueri.
Prosedur
Masuk ke konsol AnalyticDB for MySQL. Di pojok kiri atas konsol, pilih wilayah. Di panel navigasi sisi kiri, klik Clusters. Temukan kluster yang ingin dikelola dan klik ID kluster.
Di panel navigasi sisi kiri, klik Diagnostics and Optimization.
Pada tab SQL Queries, temukan kueri yang ingin didiagnosis dan klik Diagnose di kolom Aksi.
Klik tab Stages & Tasks untuk melihat detail sebuah tahap. Untuk informasi tentang hasil kueri tahap, lihat bagian "Parameter tahap" dari topik ini.
Klik stage ID untuk melihat detail semua tugas dalam tahap tersebut. Untuk informasi tentang hasil kueri tugas, lihat bagian "Parameter tugas" dari topik ini.
PentingAnda hanya dapat melihat detail tugas untuk kueri yang memakan waktu lebih dari 1 detik.
Parameter
Parameter tahap
Parameter | Deskripsi |
ID Tahap | Pengenal unik dari tahap, yang sesuai dengan ID tahap dalam pohon rencana eksekusi. |
Status | Status eksekusi tahap. Nilai valid:
|
Jumlah Baris Data Masukan | Jumlah baris data yang dimasukkan ke dalam tahap. |
Jumlah Data Masukan | Jumlah data yang dimasukkan ke dalam tahap. |
Jumlah Baris Data Keluaran | Jumlah baris data yang dikeluarkan dari tahap. |
Jumlah Data Keluaran | Jumlah data yang dikeluarkan dari tahap. |
Memori Puncak | Penggunaan memori puncak dari tahap. |
Durasi Kumulatif | Jumlah total waktu yang dikonsumsi untuk mengeksekusi semua operator dalam tahap. Anda dapat menggunakan parameter ini untuk mengidentifikasi tahap yang membutuhkan waktu lama untuk dieksekusi dan mengonsumsi banyak sumber daya CPU. Saat membandingkan durasi kumulatif dengan durasi kueri, Anda harus mempertimbangkan konkurensi tahap. |
Parameter tugas
Parameter | Deskripsi |
ID Tugas | Pengenal unik dari tugas. Contoh: |
Status | Status eksekusi tugas. Nilai valid:
|
Jumlah Data Masukan | Jumlah baris data yang dimasukkan ke dalam tugas dan jumlah data masukan. Anda dapat mengurutkan jumlah data masukan untuk semua tugas untuk memeriksa apakah terjadi skew data pada data masukan tahap. Skew data dapat disebabkan oleh pengaturan field yang tidak tepat dalam klausa GROUP atau JOIN. Untuk menyelesaikan masalah ini, lacak kembali ke tahap hulu dari tahap tempat tugas saat ini berada. Catatan Jika bidang distribusi yang ditentukan tidak tepat, data mungkin didistribusikan secara tidak merata di antara node pekerja. Ini disebut skew data. |
Jumlah Data Keluaran | Jumlah baris data yang dikeluarkan dari tugas dan jumlah data keluaran. Anda dapat memeriksa apakah ada field gabungan dalam klausa GROUP atau JOIN dari pernyataan SQL berdasarkan atribut node Aggregation atau Join dalam pohon rencana operator tahap saat ini. Sebagai contoh, |
Memori Puncak | Penggunaan memori puncak dari tugas. Memori puncak sebanding dengan jumlah data masukan. Anda dapat menggunakan parameter ini untuk memeriksa apakah kegagalan kueri disebabkan oleh distribusi data masukan yang tidak seimbang. |
Durasi Membaca Data Tabel | Jumlah total waktu yang dikonsumsi oleh semua operator TableScan dari tahap untuk membaca data tabel. Parameter ini adalah nilai kumulatif yang melibatkan beberapa node dan thread dan tidak dapat dibandingkan dengan durasi kueri. Jika Anda membandingkan parameter ini dengan durasi kumulatif, Anda dapat menentukan berapa banyak sumber daya komputasi dari tahap yang digunakan untuk pemindaian data. |
Jumlah Data Tabel yang Dibaca | Jumlah baris data dan jumlah data yang dibaca oleh semua operator TableScan dari tahap. Anda dapat mengurutkan jumlah data tabel yang dibaca untuk semua tugas untuk memeriksa apakah terjadi skew data pada data tabel sumber. Jika skew data terjadi, Anda dapat memeriksa apakah skew data tersebut disebabkan oleh bidang distribusi di konsol AnalyticDB for MySQL. Untuk informasi lebih lanjut, lihat Diagnosis pemodelan data. |
Dibuat Pada | Waktu ketika tugas dibuat. |
Durasi Antrian | Jumlah waktu antrian tugas sebelum eksekusi. |
Selesai Pada | Waktu ketika tugas selesai. |
Interval Waktu Mulai dan Selesai | Interval antara waktu pembuatan dan waktu selesai tugas. Sebagai contoh, jika tugas dibuat pada 2022-12-12 12:00:00 dan selesai pada 2022-12-12 12:00:04, interval waktu mulai dan selesai adalah 4 detik. Jika Anda membandingkan parameter ini dengan durasi kueri, Anda dapat mengidentifikasi penyebab utama pelaksanaan lambat. Sebagai contoh, jika durasi kueri adalah 6 detik dan interval waktu mulai dan selesai adalah 4 detik, tahap saat ini adalah alasan utama mengapa kueri membutuhkan waktu lama untuk dieksekusi. Untuk informasi lebih lanjut, lihat bagian "Contoh perhitungan durasi tugas dan konkurensi" dari topik ini. |
Durasi Kumulatif | Jumlah total waktu yang dikonsumsi oleh semua thread dari semua tugas dalam tahap. Untuk informasi lebih lanjut, lihat bagian "Contoh perhitungan durasi tugas dan konkurensi" dari topik ini. |
Rasio Waktu Komputasi | Rasio durasi komputasi data terhadap siklus hidup subtugas. Parameter ini dapat dihitung dengan menggunakan rumus berikut: Rasio waktu komputasi = (Durasi kumulatif/Konkurensi subtugas)/Interval waktu mulai dan selesai. Dalam rumus ini, (Durasi kumulatif/Konkurensi subtugas) menunjukkan jumlah rata-rata waktu yang dikonsumsi oleh setiap thread untuk menghitung data. Interval waktu mulai dan selesai mencakup waktu komputasi data aktual, durasi antrian subtugas, dan latensi jaringan. Untuk informasi lebih lanjut, lihat bagian "Contoh perhitungan durasi tugas dan konkurensi" dari topik ini. Catatan Interval waktu mulai dan selesai yang lebih lama menghasilkan rasio waktu komputasi yang lebih kecil. Dalam hal ini, Anda perlu mengidentifikasi operator yang mengonsumsi waktu lama. Interval waktu mulai dan selesai yang lebih pendek menghasilkan rasio waktu komputasi yang lebih besar. Dalam hal ini, Anda perlu fokus pada masalah seperti antrian dan latensi jaringan. |
Konkurensi Subtugas | Jumlah thread yang secara bersamaan mengeksekusi tugas pada sebuah node. Untuk informasi lebih lanjut, lihat bagian "Contoh perhitungan durasi tugas dan konkurensi" dari topik ini. |
Node Eksekusi | Alamat IP dari node tempat tugas dieksekusi. Jika masalah ekor panjang terjadi pada node yang sama untuk beberapa kueri, Anda harus memeriksa node ini. Catatan Masalah ekor panjang di AnalyticDB for MySQL mengacu pada situasi di mana beberapa tugas membutuhkan waktu jauh lebih lama untuk dieksekusi daripada tugas lainnya. |
Contoh perhitungan durasi tugas dan konkurensi
Dalam contoh ini, interval waktu mulai dan selesai, durasi kumulatif, rasio waktu komputasi, dan konkurensi subtugas dari Tugas 2.1 dihitung.
Tugas 2.1 termasuk dalam Tahap 2. Anggaplah bahwa Tahap 2 terdiri dari empat operator: StageOutput, Join, TableScan, dan RemoteSource. Gambar berikut menunjukkan diagram pohon operator dari Tahap 2.
Operator-operator ini dieksekusi secara bersamaan pada beberapa node dalam arah panah. Pada node dengan alamat IP 192.168.12.23, Tugas 2.1 dieksekusi dengan empat thread bersamaan. Keempat thread tersebut masing-masing mengonsumsi 5, 5, 6, dan 6 detik untuk menghitung data, seperti yang ditunjukkan pada gambar berikut.
Durasi kumulatif tugas: 5s + 5s + 6s + 6s = 22s.
Interval waktu mulai dan selesai: 10s.
Rasio waktu komputasi: (22s/4)/10s = 0,55.
Operasi terkait
Operasi | Deskripsi |
Menanyakan informasi eksekusi tentang pernyataan SQL. | |
Menanyakan informasi eksekusi tentang tugas terdistribusi dalam tahap kueri. |