AnalyticDB：Gunakan informasi pemantauan untuk mengoptimalkan kinerja cluster

Peningkatan utilisasi CPU rata-rata

Metrik utilisasi CPU rata-rata menunjukkan nilai rata-rata utilisasi CPU di seluruh node pada titik waktu tertentu. Peningkatan utilisasi CPU rata-rata dapat memengaruhi stabilitas cluster serta mengakibatkan penurunan kecepatan query dan penulisan. Jika utilisasi CPU rata-rata terus meningkat, cluster berisiko mengalami masalah dan harus segera dioptimalkan.

Peningkatan dalam rata-rata utilisasi CPU dapat disebabkan oleh beberapa alasan berikut:

• Query

  Peningkatan utilisasi CPU rata-rata dapat disebabkan oleh query, seperti query SQL yang tidak optimal. Contohnya, sebuah query SQL mungkin mengandung logika komputasi yang kompleks, memproses sejumlah besar data, atau menghasilkan kesalahan Produk Kartesius akibat kondisi JOIN yang tidak lengkap. Dalam situasi ini, Anda dapat menggunakan fitur diagnosis di halaman Pemantauan dan Peringatan untuk mengidentifikasi query bermasalah.

  • Untuk hasil deteksi SQL yang buruk, peningkatan dalam utilisasi CPU rata-rata dapat disebabkan oleh query SQL yang membutuhkan waktu lama untuk diselesaikan, memproses sejumlah besar data, melibatkan beberapa tahap, dan mengonsumsi banyak sumber daya CPU. Anda harus menganalisis penyebab berdasarkan hasil diagnosis mandiri atau rencana eksekusi.

  • Untuk hasil deteksi pola abnormal, Anda dapat mengidentifikasi penyebab dari berbagai faktor seperti jumlah data yang besar, waktu, dan sumber daya CPU.

  • Jika utilisasi CPU rata-rata di seluruh node komputasi atau node penyimpanan meningkat, Anda dapat menggunakan hasil deteksi operator abnormal dalam deteksi lapisan komputasi dan deteksi lapisan penyimpanan untuk menganalisis penyebabnya. Detail operator dan ringkasan operator membantu Anda mengidentifikasi operator abnormal berdasarkan sumber daya CPU yang dikonsumsi.

• Penulisan

  Operasi penulisan, seperti INSERT, UPDATE, DELETE, REPLACE, INSERT OVERWRITE, dan INSERT INTO SELECT, dapat mengonsumsi sejumlah besar sumber daya CPU serta menyebabkan peningkatan utilisasi CPU rata-rata di seluruh node penyimpanan. Dalam situasi ini, Anda dapat memeriksa lonjakan metrik seperti transaksi penghapusan per detik (TPS), TPS penulisan, TPS pembaruan, dan metrik TPS beban.

  Peningkatan dalam rata-rata utilisasi CPU akibat penulisan dapat disebabkan oleh alasan berikut:

  • Kunci utama panjang

    Kunci utama yang panjang dapat menghasilkan indeks kunci utama yang besar, yang mengonsumsi sejumlah besar sumber daya CPU.

  • Pernyataan DELETE

    Jika satu pernyataan DELETE WHERE cocok dengan sejumlah besar baris data, mesin komputasi harus menghitung kunci utama dari semua baris dan mengirimkan kunci utama ke node penyimpanan untuk penghapusan. Sebuah pernyataan DELETE dapat diperbesar berkali-kali dan menyebabkan peningkatan dalam utilisasi CPU rata-rata.

  • Pernyataan UPDATE

    Jika satu pernyataan UPDATE WHERE cocok dengan sejumlah besar baris, mesin komputasi harus menghitung kunci utama dari semua baris tersebut, memperbarui nilai-nilai bidang yang sesuai, dan kemudian mengirimkan kunci utama dan nilai baru ke node penyimpanan untuk menandai baris lama dan menambahkan baris baru. Sebuah pernyataan UPDATE dapat diperbesar berkali-kali dan menyebabkan peningkatan dalam utilisasi CPU rata-rata.

  • Pernyataan INSERT OVERWRITE SELECT

    Sebuah beban batch memerlukan penguraian data, pengurutan data berdasarkan bidang indeks terkluster (jika ada), dan pembuatan indeks kunci utama dan indeks reguler. Operasi-operasi sebelumnya bersifat terbatas CPU dan memerlukan satu thread untuk setiap shard. Batas diberlakukan pada jumlah operasi beban batch konkuren. Sebagai contoh, Anda dapat mengeksekusi hingga dua pernyataan beban batch pada saat yang sama. Namun, utilisasi CPU masih dapat meningkat karena setiap shard memerlukan satu thread untuk melakukan operasi beban batch.

  • Pernyataan INSERT INTO SELECT

    Jika sejumlah besar data ditulis dalam periode waktu yang singkat, pekerjaan BUILD yang terakumulasi di latar belakang dapat menyebabkan peningkatan data real-time. Dalam kasus ini, jika data real-time terlibat dalam query, AnalyticDB for MySQL harus memindai sejumlah besar data real-time yang tidak diindeks. Akibatnya, utilisasi CPU meningkat.

• Pekerjaan BUILD

  Pekerjaan BUILD mencakup operasi seperti pembuatan indeks, pembuatan partisi, dan penghapusan partisi, yang dapat meningkatkan utilisasi CPU di seluruh node penyimpanan. Anda dapat membandingkan utilisasi CPU dan jumlah pekerjaan BUILD di konsol AnalyticDB for MySQL untuk menganalisis korelasi antara kedua metrik tersebut.

  Catatan

  • Untuk informasi lebih lanjut tentang pekerjaan BUILD, lihat BUILD.

  • Untuk informasi tentang cara mengidentifikasi dan menganalisis penyebab peningkatan penggunaan sumber daya terkait pekerjaan BUILD, lihat bagian "Peningkatan Jumlah Pekerjaan BUILD" dari topik ini.

Pencapaian utilisasi CPU yang tidak merata

Metrik utilisasi CPU maksimum menunjukkan nilai tertinggi dari utilisasi CPU di seluruh node pada titik waktu tertentu. Jika terdapat perbedaan signifikan antara utilisasi CPU maksimum dan rata-rata selama periode waktu yang lama, sejumlah besar data diproses pada node tertentu, sementara node lainnya hanya memproses sejumlah kecil data. Hal ini dapat menyebabkan ketidakseimbangan dalam utilisasi CPU. Ketidakseimbangan serius pada utilisasi CPU dapat memengaruhi stabilitas cluster secara signifikan dan menyebabkan pemborosan sumber daya. Sebagai contoh, jika utilisasi CPU maksimum lebih dari dua kali lipat dari rata-rata, kinerja tugas query terdistribusi akan dibatasi oleh utilisasi CPU maksimum dan tidak dapat ditingkatkan. Untuk mengatasi masalah ini, Anda perlu meningkatkan konfigurasi node. Namun, perlu dicatat bahwa utilisasi CPU pada node lainnya tidak tinggi.

Ketidakseimbangan utilisasi CPU dapat disebabkan oleh beberapa alasan berikut:

• Ketidakseimbangan tabel sumber

  Dalam banyak kasus, pemilihan kunci distribusi yang tidak tepat saat membuat tabel dapat menyebabkan distribusi data yang tidak merata di seluruh shard.

  Gambar berikut menunjukkan bahwa data dari tabel besar didistribusikan secara tidak merata. Shard_0 dan Shard_1 pada Storage Node 0 berisi sejumlah besar data, sedangkan Shard_2 dan Shard_3 pada Storage Node 1 berisi sejumlah kecil data. Saat Anda meminta tabel besar, Storage Node 0 harus memproses lebih banyak data dibandingkan Storage Node 1. Dalam situasi ini, utilisasi CPU pada Storage Node 0 secara konsisten lebih tinggi daripada pada Storage Node 1, sehingga menyebabkan ketidakseimbangan dalam utilisasi CPU.

  Untuk informasi tentang cara mendiagnosis ketidakseimbangan tabel sumber, lihat Diagnostik Penyimpanan. Anda juga dapat menggunakan fitur diagnosis di halaman Pemantauan dan Peringatan untuk memeriksa tabel yang tidak seimbang dengan penggunaan ruang penyimpanan disk besar serta menganalisis ketidakseimbangan sumber daya.

• Ketidakseimbangan data perantara

  Ketidakseimbangan data perantara berbeda dari ketidakseimbangan tabel sumber. Dalam skenario ini, meskipun data dari tabel sumber didistribusikan secara merata di seluruh shard, data dari bidang tertentu mungkin terdistribusi secara tidak merata.

  Jika Anda menggunakan bidang yang didistribusikan secara tidak merata dalam klausa GROUP BY, fungsi agregat, atau klausa JOIN, AnalyticDB for MySQL akan mendistribusikan ulang data di seluruh node berdasarkan bidang tersebut. Data dengan nilai bidang yang sama dikirim ke node yang sama, sehingga menyebabkan distribusi data yang tidak merata terkait bidang tersebut.

  Gambar berikut menunjukkan bahwa tabel didistribusikan berdasarkan Field a. Data dari tabel tersebut terdistribusi secara merata di seluruh node penyimpanan karena nilai Field a juga terdistribusi secara merata. Namun, jika Anda menggunakan Field b dalam klausa GROUP BY, Storage Node 1 akan mendistribusikan baris dengan nilai Field b adalah b1 ke Compute Node 1. Untuk memastikan Compute Node 1 memiliki semua baris dengan nilai b1, Storage Node 2 juga mendistribusikan baris dengan nilai Field b adalah b1 ke Compute Node 1, sementara baris dengan nilai Field b adalah b2 dikirim ke Compute Node 2. Akibatnya, Compute Node 1 menerima lebih banyak baris dibandingkan Compute Node 2, sehingga menyebabkan ketidakseimbangan data. Dalam situasi ini, Compute Node 1 memerlukan lebih banyak sumber daya cluster untuk memproses data dibandingkan Compute Node 2.

  Untuk informasi tentang cara mengidentifikasi penyebab ketidakseimbangan utilisasi CPU terkait ketidakseimbangan data perantara, lihat Hasil Diagnostik Tingkat Tahap.

Rata-rata utilisasi CPU moderat tetapi peningkatan utilisasi CPU maksimum

Sejumlah besar data query

Penyebab: Satu query SQL mengembalikan sejumlah besar data, yang mempengaruhi utilisasi CPU di seluruh node akses.

Solusi: Untuk mengurangi jumlah data yang dikembalikan, tambahkan kondisi query yang lebih presisi untuk mempersempit ruang pencarian. Atau, gunakan query paginasi untuk mencegah memuat sejumlah besar data sekaligus. Jika Anda perlu mengekspor sejumlah besar data, Anda juga dapat menggunakan tabel eksternal.

Sejumlah besar sumber daya CPU dikonsumsi oleh optimizer

Penyebab: Jika cluster memiliki QPS tinggi dan query SQL yang kompleks, query optimizer dapat menggunakan sejumlah besar sumber daya CPU.

Solusi: Aktifkan fitur cache rencana. Periksa apakah utilisasi CPU berkurang secara signifikan. Jika tidak, ajukan tiket.

Data lapangan panjang ditulis

Penyebab: Jika data lapangan panjang ditulis ke tabel, node akses mengonsumsi sejumlah besar sumber daya untuk memproses lapangan panjang. Akibatnya, utilisasi CPU meningkat.

Solusi: Jalankan pernyataan berikut untuk memeriksa apakah data lapangan panjang ditulis ke tabel. Jika ya, kami sarankan Anda mengoptimalkan logika bisnis tabel untuk membatasi panjang lapangan atau membagi lapangan panjang.

SELECT *
FROM 
    (SELECT schema_name,
        table_name,
        column_name,
         cast(json_extract(stats,
        '$.avgSize') AS bigint) AS avg_size
    FROM INFORMATION_SCHEMA.COLUMN_STATISTICS ) tmp
ORDER BY  avg_size DESC limit 20;

Metrik baca/tulis disk

Peningkatan penggunaan memori komputasi

AnalyticDB for MySQL menggunakan sejumlah besar sumber daya memori untuk memproses data dalam jumlah besar. Pada umumnya, query SQL yang intensif memori dapat mencakup operator Aggregation, TopN, Window, dan Join.

• Operator Aggregation

  Operator Aggregation mengonsumsi banyak sumber daya memori karena AnalyticDB for MySQL menyimpan informasi pengelompokan sementara di memori. Jika bidang GROUP BY memiliki banyak nilai unik, AnalyticDB for MySQL akan menggunakan banyak sumber daya memori pada tahap akhir agregasi terdistribusi. Sementara itu, tahap agregasi parsial hanya menggunakan sedikit sumber daya memori karena tidak memerlukan agregasi global. Setiap node dapat mengirimkan data ke node hilir setelah menyelesaikan agregasi parsial dari data tersebut.

• Operator TopN

  Operator TopN digunakan untuk melakukan perhitungan TopN. Sebagai contoh, jika Anda menjalankan pernyataan SQL yang berisi klausa ORDER BY id LIMIT m,n di AnalyticDB for MySQL dan nilai m diberi angka besar, operator TopN di AnalyticDB for MySQL menyimpan banyak data di memori untuk melakukan pengurutan global. Proses ini mengonsumsi banyak sumber daya memori.

• Operator Window

  Operator Window digunakan untuk menghitung fungsi jendela. Mirip dengan operator Aggregation, operator Window menyimpan banyak data di memori untuk mencapai hasil semantik akhir.

• Operator Join

  AnalyticDB for MySQL mendukung operasi join standar. Algoritma Hash dan indeks digunakan untuk mengimplementasikan operasi join. Untuk informasi lebih lanjut, lihat bagian "Join" dari topik Operator. Algoritma hash menyimpan tabel kecil (tabel build) di memori dan membangun tabel hash untuk tabel build di memori guna mempercepat proses join. Tabel hash dapat menggunakan banyak sumber daya memori karena alasan berikut:

  • Tabel build besar

    AnalyticDB for MySQL memperkirakan ukuran dua tabel yang ingin digabungkan berdasarkan statistik dan menggunakan tabel yang lebih kecil sebagai tabel build. Namun, tabel build mungkin berisi banyak data.

  • Statistik kedaluwarsa atau tidak akurat

    Jika dua tabel yang ingin digabungkan bukan tabel sumber, tetapi tabel yang telah melalui agregasi, penyaringan, dan operasi join, ukuran kedua tabel dalam statistik berbasis tabel sumber mungkin tidak akurat. Jika statistik kedaluwarsa, AnalyticDB for MySQL mungkin salah memilih tabel yang lebih besar sebagai tabel build dan membangun tabel hash untuk tabel tersebut. Untuk informasi lebih lanjut, lihat Statistik.

  • Tabel kanan besar untuk left join

    Untuk tujuan semantik, tabel kanan dari left join harus digunakan untuk membangun tabel hash. Jika tabel kanan dari left join besar, operasi join akan menggunakan banyak sumber daya memori.

Untuk informasi lebih lanjut tentang operator, lihat Operator.

Jika banyak query SQL yang mencakup operator-operator ini dilakukan secara bersamaan atau satu operator menggunakan banyak sumber daya memori, metrik penggunaan memori komputasi akan meningkat. Akibatnya, stabilitas cluster terpengaruh dan pesan kesalahan dikembalikan. Berikut adalah beberapa pesan kesalahan umum:

• Query exceeded reserved memory limit: Sebuah query menggunakan banyak sumber daya memori pada satu node.

• Query exceeded system memory pool limit: Panjang satu bidang melebihi batas atau banyak kolom terlibat.

• Out of Memory Pool size pre cal. available: Pool memori fisik habis.

• The cluster is out of memory, and your query was killed: Query terbesar yang sedang berjalan dihentikan jika cluster kehabisan memori.

Untuk mengurangi penggunaan memori komputasi, Anda harus mengoptimalkan query SQL yang mencakup operator-operator ini. Untuk informasi lebih lanjut, lihat Hasil Diagnosis Tingkat Operator.

Peningkatan jumlah pekerjaan BUILD

Pekerjaan BUILD digunakan untuk membuat indeks pada data yang ditulis, membersihkan data kedaluwarsa, dan mengeksekusi pernyataan DDL secara asinkron. Hal ini membantu meningkatkan kinerja baca. Dalam skenario tertentu, pekerjaan BUILD dapat mengonsumsi sejumlah besar sumber daya CPU dan disk I/O dari node penyimpanan, yang berpotensi memengaruhi operasi lain dan menyebabkan masalah stabilitas cluster. Tabel berikut menjelaskan metrik terkait BUILD.

Peningkatan jumlah pekerjaan BUILD dalam cluster AnalyticDB for MySQL dapat memengaruhi utilisasi CPU node penyimpanan. Anda dapat mengidentifikasi dan menganalisis penyebabnya dari aspek-aspek berikut:

• Sebuah partisi dari tabel partisi berisi sejumlah besar data. Kemungkinan bahwa partisi besar melibatkan operasi tulis, pembaruan, atau penghapusan tinggi, yang dapat memicu pekerjaan BUILD. Anda dapat menggunakan diagnostik penyimpanan untuk mengidentifikasi jenis tabel ini dan melakukan optimasi skema.

• Tabel non-partisi berisi sejumlah besar data. Kemungkinan bahwa tabel non-partisi besar melibatkan operasi tulis, pembaruan, atau penghapusan tinggi, yang dapat memicu pekerjaan BUILD.

• Sejumlah besar permintaan baca dan tulis menyebabkan utilisasi CPU node penyimpanan tetap tinggi untuk periode waktu yang lama, sehingga memperpanjang durasi eksekusi pekerjaan BUILD.

Peningkatan jumlah node yang tidak tersedia

Node dalam cluster AnalyticDB for MySQL mungkin menjadi tidak tersedia. Peningkatan jumlah node yang tidak tersedia dapat memengaruhi stabilitas cluster, memperlambat query dan penulisan, serta menyebabkan kesalahan. Dalam kasus ini, Anda dapat memeriksa apakah utilisasi CPU terus meningkat dan metrik I/O mencapai batas atas.

Metrik P95

AnalyticDB for MySQL menyediakan metrik P95 yang menunjukkan nilai persentil ke-95 (nilai P95) dari metrik kinerja seperti utilisasi CPU, utilisasi CPU node akses, penggunaan memori komputasi, throughput I/O disk, disk IOPS, penggunaan I/O disk, dan waktu tunggu I/O disk. Nilai P95 adalah nilai yang lebih besar dari 95% dari nilai yang dipantau. Sebagai contoh, jika Anda menggunakan metrik P95 Utilisasi CPU Node Komputasi untuk cluster AnalyticDB for MySQL dengan 100 node komputasi, nilai P95 dari metrik tersebut pada titik waktu tertentu adalah utilisasi CPU dari node komputasi ke-95 dalam daftar utilisasi CPU semua node komputasi yang diurutkan secara menaik.

Nilai maksimum, rata-rata, dan P95 memiliki perbedaan berikut:

• Nilai maksimum menunjukkan batas atas data. Jika dataset berisi pencilan atau nilai ekstrem, nilai maksimum dari metrik mungkin sangat dipengaruhi oleh nilai-nilai tersebut dan mungkin tidak secara akurat mewakili level umum atau tipikal dari data.

• Nilai rata-rata dirancang untuk menunjukkan kecenderungan pusat data. Namun, jika dataset berisi pencilan atau condong, nilai rata-rata tidak dapat secara akurat mencerminkan level umum dari data.

• Nilai P95 berfokus pada kinerja titik data yang berperingkat tinggi dan mengabaikan titik data yang paling ekstrem. Ini cocok untuk menilai kinerja data atau level dalam kebanyakan kasus.

Waktu respons query yang diperpanjang

Metrik waktu respons query menunjukkan periode dari saat query diserahkan hingga diatur dalam antrian dan dieksekusi. Untuk informasi lebih lanjut tentang durasi eksekusi query di AnalyticDB for MySQL, lihat bagian "A large response time is displayed on the Monitoring and Alerts page, but no corresponding time-consuming SQL queries are found on the Diagnostics and Optimization page. Why?" pada topik Pemantauan.

Waktu respons query dapat diperpanjang karena alasan berikut:

• Pernyataan SQL yang buruk

  Pernyataan SQL yang buruk dapat mengonsumsi sejumlah besar sumber daya cluster dan memengaruhi eksekusi pernyataan SQL normal.

• Pola abnormal

  Dalam skenario tertentu, pernyataan SQL dengan pola serupa mengonsumsi sedikit sumber daya tetapi dieksekusi secara berulang, atau pernyataan SQL dengan pola serupa mengonsumsi banyak sumber daya. Hal ini memengaruhi query lainnya dan memperpanjang waktu respons query keseluruhan.

• Peningkatan jumlah data yang ditulis

  Jika jumlah data yang ditulis meningkat, AnalyticDB for MySQL mengonsumsi banyak sumber daya CPU dan disk I/O serta memicu lebih banyak pekerjaan BUILD, sehingga memperpanjang waktu respons query keseluruhan.

Anda dapat mendiagnosis halaman Pemantauan dan Peringatan serta memilih periode ketika waktu respons query diperpanjang untuk menganalisis penyebab berdasarkan hasil diagnosis.

Waktu tunggu query yang diperpanjang

Setelah query diserahkan ke node lapisan akses cluster AnalyticDB for MySQL, cluster memeriksa apakah query harus dimasukkan ke dalam antrian berdasarkan ukuran antrian untuk mencegah terlalu banyak query SQL dieksekusi bersamaan dan memengaruhi stabilitas cluster. Untuk informasi lebih lanjut, lihat Antrian prioritas dan konkurensi grup sumber daya interaktif.

Dalam kebanyakan kasus, waktu tunggu query yang diperpanjang disebabkan oleh penurunan kinerja cluster. Contohnya, pernyataan SQL yang buruk atau pola abnormal mengonsumsi banyak sumber daya cluster. Anda dapat mendiagnosis halaman Pemantauan dan Peringatan serta memeriksa hasil deteksi SQL yang buruk dan pola abnormal. Waktu tunggu query yang diperpanjang juga dapat disebabkan oleh peningkatan jumlah data yang ditulis, yang menyebabkan penggunaan intensif sumber daya CPU dan disk I/O pada node penyimpanan.

Peningkatan tingkat kegagalan query

Metrik tingkat kegagalan query mengukur proporsi query yang gagal, namun tidak menjelaskan penyebab kegagalan. Kegagalan query dapat disebabkan oleh beberapa alasan. Berikut adalah penjelasan alasan umum:

• Kesalahan SQL

  • Kesalahan sintaksis

    Jika pernyataan SQL tidak sesuai dengan sintaksis SQL dari AnalyticDB for MySQL, pesan kesalahan akan dikembalikan pada tahap penguraian sintaksis. Contohnya, pernyataan SQL tidak lengkap, format tidak valid, atau kata kunci atau tanda baca hilang.

  • Kesalahan semantik

    Jika pernyataan SQL sesuai dengan sintaksis SQL dari AnalyticDB for MySQL tetapi objek database salah, pesan kesalahan akan dikembalikan pada tahap penguraian semantik. Contohnya, nama tabel salah, kolom tidak ada, bidang GROUP BY hilang, atau tipe parameter fungsi salah.

• Kesalahan cluster

  • Timeout query

    AnalyticDB for MySQL menyediakan periode timeout query default. Anda dapat mengonfigurasi periode timeout query kustom sesuai kebutuhan bisnis. Jika durasi eksekusi query melebihi periode timeout yang ditentukan, query akan gagal.

    Catatan

    • Untuk informasi tentang periode timeout query default, lihat bagian "Batasan timeout" pada topik Batasan.

    • Untuk informasi tentang cara memodifikasi periode timeout query, lihat Parameter konfigurasi Config dan hint.

  • Beban kerja cluster tinggi

    Jika cluster AnalyticDB for MySQL mengalami beban kerja tinggi, timeout komunikasi node atau kegagalan proses dapat mengakibatkan kegagalan query.

• Status hanya-baca

  Jika terjadi kesalahan log Raft, AnalyticDB for MySQL menetapkan proses saat ini ke status hanya-baca. Dalam kasus ini, pesan kesalahan dikembalikan untuk operasi penulisan.

• Timeout

  Jika AnalyticDB for MySQL tidak dapat langsung mengonsumsi antrian log Raft, tekanan balik terjadi. Contohnya, kunci utama panjang memperlambat operasi penulisan, sehingga mengembalikan pesan kesalahan timeout.

Jumlah data tabel yang dibaca

Di AnalyticDB for MySQL, data disimpan di node penyimpanan yang berbeda. Metrik jumlah data tabel yang dibaca menunjukkan jumlah data yang diambil dari lapisan penyimpanan ke lapisan komputasi menggunakan query SQL pada titik waktu tertentu.

Gambar berikut menunjukkan contoh pembacaan data dalam kueri. Pada titik waktu Time_1, data dibaca dari tabel user, report, customer, test, region, dan partition menggunakan enam kueri SQL berikut: Query 1, Query 2, Query 3, Query 4, Query 5, dan Query 6. Pada titik waktu ini, total jumlah data tabel yang dibaca di semua node penyimpanan adalah 20,1 GB, dihitung dengan rumus: 1,6 + 2 + 3 + 0,7 + 4,8 + 8 = 20,1 GB. Rata-rata jumlah data tabel yang dibaca di semua node penyimpanan adalah 6,7 GB, diperoleh dari total jumlah data tabel yang dibaca di semua node penyimpanan dibagi dengan jumlah node penyimpanan, dengan perhitungan: (1,6 + 2 + 3 + 0,7 + 4,8 + 8)/3 = 6,7 GB. Jumlah maksimum data tabel yang dibaca di semua node penyimpanan adalah 12,8 GB, dihitung menggunakan rumus: 4,8 + 8 = 12,8 GB.

Jumlah total data tabel yang dibaca, jumlah maksimum data tabel yang dibaca, dan jumlah rata-rata data tabel yang dibaca mencerminkan tekanan query SQL pada cluster AnalyticDB for MySQL.

• Peningkatan mendadak dalam jumlah rata-rata data tabel yang dibaca menunjukkan bahwa sejumlah besar data ditransmisikan dari lapisan penyimpanan ke lapisan komputasi untuk diproses. Proses transmisi ini mengonsumsi lebih banyak sumber daya CPU dan memori. Selain itu, jumlah data yang dibaca dari lapisan penyimpanan meningkat, sehingga mengonsumsi lebih banyak sumber daya disk I/O.

• Perbedaan signifikan antara jumlah maksimum dan rata-rata data tabel yang dibaca menunjukkan adanya ketidakseimbangan dalam jumlah data yang dibaca dari node penyimpanan yang berbeda. Node tertentu mencapai batas pemrosesan data lebih awal dari yang diharapkan, memengaruhi kinerja keseluruhan cluster. Dalam kebanyakan kasus, masalah ini terjadi karena desain tabel yang tidak optimal. Contohnya, jika Anda memilih bidang dengan distribusi nilai tidak merata sebagai bidang distribusi, data akan didistribusikan secara tidak merata di beberapa node penyimpanan.

Waktu respons yang diperpanjang untuk penulisan, penghapusan, dan pembaruan

Metrik waktu respons penulisan menunjukkan jumlah waktu yang diperlukan oleh pernyataan INSERT INTO VALUES untuk memproses setiap baris data. Metrik waktu respons penghapusan menunjukkan jumlah waktu yang diperlukan oleh pernyataan DELETE untuk memproses setiap baris data. Metrik waktu respons pembaruan menunjukkan jumlah waktu yang diperlukan oleh pernyataan UPDATE untuk memproses setiap baris data. Dalam kebanyakan kasus, waktu respons dipengaruhi oleh faktor-faktor berikut:

• Peningkatan utilisasi CPU dari node penyimpanan

  Utilisasi CPU dari node penyimpanan dapat meningkat bersamaan dengan metrik lainnya. Contohnya, pernyataan SQL yang buruk menyebabkan metrik tertentu meningkat atau metrik TPS penulisan, penghapusan, atau pembaruan meningkat.

• Peningkatan metrik I/O terkait penulisan dari node penyimpanan

  Metrik I/O terkait penulisan dari node penyimpanan mencakup throughput I/O disk dan disk IOPS. Metrik tersebut dapat meningkat karena alasan berikut:

  • Jumlah pekerjaan BUILD meningkat.

  • Operasi pencadangan atau penskalaan dilakukan.

  Waktu respons dapat terpengaruh karena operasi sebelumnya memerlukan penulisan disk.