AnalyticDB:Optimalkan performa kluster dengan informasi pemantauan

Utilisasi CPU rata-rata tinggi

Metrik utilisasi CPU rata-rata menunjukkan penggunaan CPU rata-rata di beberapa node pada titik waktu tertentu. Utilisasi CPU rata-rata yang tinggi dapat memengaruhi stabilitas kluster serta memperlambat kueri dan operasi write. Jika utilisasi CPU rata-rata tetap tinggi, hal ini menimbulkan risiko signifikan bagi kluster Anda dan memerlukan optimasi segera.

Penyebab umum utilisasi CPU rata-rata tinggi meliputi:

• Kueri

  Utilisasi CPU tinggi akibat kueri dapat disebabkan oleh SQL buruk, seperti kueri dengan logika komputasi kompleks, volume pemrosesan data besar, atau operasi JOIN tanpa kondisi yang menghasilkan Produk Kartesius. Anda dapat menggunakan fitur diagnostics untuk menemukan kueri bermasalah:

  • Dalam hasil deteksi SQL buruk, kueri yang berjalan lama, membaca volume data besar, memiliki banyak stage, atau bersifat intensif CPU dapat menyebabkan utilisasi CPU kluster tinggi. Kueri-kueri ini memerlukan analisis lebih lanjut berdasarkan hasil diagnosis atau rencana eksekusi.

  • Fitur deteksi pola abnormal mengidentifikasi pola pengiriman yang tidak biasa dari perspektif templat SQL. Mirip dengan SQL buruk, pola yang menyebabkan utilisasi CPU tinggi perlu dianalisis berdasarkan faktor-faktor seperti volume pembacaan data abnormal, konsumsi CPU tinggi, dan durasi kueri tidak wajar. Pola abnormal ini dapat meningkatkan utilisasi CPU.

  • Jika Anda mengamati utilisasi CPU tinggi pada node komputasi atau penyimpanan, Anda dapat menganalisis masalah tersebut menggunakan hasil deteksi lapisan komputasi dan lapisan penyimpanan dari fitur diagnostics. Fitur deteksi operator abnormal menggunakan detail dan ringkasan operator untuk menyaring serta mengidentifikasi operator abnormal berdasarkan konsumsi CPU-nya.

• Menulis

  Operasi write (termasuk INSERT, UPDATE, DELETE, REPLACE, INSERT OVERWRITE, dan INSERT INTO SELECT) juga mengonsumsi resource CPU dan dapat menyebabkan utilisasi CPU tinggi pada node penyimpanan. Dalam kasus ini, periksa apakah metrik pemantauan seperti delete TPS, write TPS, update TPS, dan load TPS juga menunjukkan peningkatan mendadak.

  Penyebab umum utilisasi CPU tinggi akibat operasi write meliputi:

  • Kunci primer panjang

    Saat kunci primer sangat panjang, indeks kunci primer menjadi besar dan mengonsumsi lebih banyak resource CPU selama pemrosesan kueri.

  • SQL DELETE

    Jika satu pernyataan DELETE WHERE mencocokkan banyak baris, mesin komputasi harus menghitung kunci primer untuk semua baris yang cocok, lalu mengirimkannya satu per satu ke node penyimpanan untuk dihapus. Satu operasi DELETE SQL dapat diperbesar secara signifikan, sehingga menyebabkan utilisasi CPU tinggi.

  • SQL UPDATE

    Jika satu pernyataan UPDATE WHERE mencocokkan banyak baris, mesin komputasi harus menemukan kunci primer semua baris yang cocok, memperbarui nilai field yang sesuai, lalu mengirim perubahan tersebut ke node penyimpanan untuk menandai baris lama sebagai dihapus dan menambahkan baris baru. Satu operasi UPDATE SQL dapat diperbesar secara signifikan, sehingga menghasilkan utilisasi CPU tinggi.

  • INSERT OVERWRITE

    Batch load melakukan operasi intensif CPU seperti penguraian data, pengurutan berdasarkan field indeks terkluster (jika indeks terkluster ada), dan pembuatan indeks kunci primer serta indeks biasa, dengan setiap shard memerlukan satu thread untuk pekerjaan ini. Meskipun terdapat batasan jumlah operasi batch load konkuren (misalnya, maksimal dua kueri SQL batch load secara bersamaan), utilisasi CPU tetap bisa tinggi karena setiap shard membutuhkan thread khusus untuk tugas-tugas tersebut.

  • INSERT INTO SELECT

    Saat sejumlah besar data ditulis dalam waktu singkat, pekerjaan BUILD latar belakang dapat menumpuk, menyebabkan peningkatan data real-time. Jika suatu kueri melibatkan data real-time ini, database harus memindai volume data yang besar karena data real-time tidak diindeks. Hal ini menyebabkan utilisasi CPU tinggi.

• BUILD

  Pekerjaan BUILD melakukan tugas seperti membangun indeks dan membuat atau membersihkan partisi. Tugas-tugas ini dapat menyebabkan utilisasi CPU tinggi pada node penyimpanan. Anda dapat membandingkan utilisasi CPU dan jumlah pekerjaan BUILD di Konsol untuk mengidentifikasi korelasi antara kedua metrik ini.

  Catatan

  • Untuk informasi lebih lanjut tentang BUILD, lihat BUILD.

  • Untuk mempelajari cara menemukan dan menganalisis penggunaan resource tinggi akibat pekerjaan BUILD, lihat Peningkatan jumlah pekerjaan BUILD.

Kesenjangan utilisasi CPU

Metrik utilisasi CPU maksimum merepresentasikan utilisasi CPU pada node paling sibuk pada titik waktu tertentu. Selisih besar dan persisten antara utilisasi CPU maksimum dan rata-rata menunjukkan distribusi tugas yang tidak merata dalam kluster, yang menyebabkan kesenjangan utilisasi CPU. Artinya, beberapa node sangat terbebani sementara yang lain hanya ringan bebannya. Kesenjangan parah (misalnya, perbedaan lebih dari 2x) dapat secara signifikan memengaruhi stabilitas kluster dan membuang resource. Hal ini terjadi karena subtask kueri terdistribusi dibatasi oleh node dengan utilisasi CPU tertinggi, sehingga mencegah peningkatan performa lebih lanjut. Sering kali, satu-satunya solusi adalah melakukan scale up kluster, meskipun node lain tidak terlalu terbebani.

Kemungkinan penyebab kesenjangan utilisasi CPU:

• Kesenjangan tabel sumber

  Hal ini biasanya terjadi ketika kunci distribusi yang dipilih saat pembuatan tabel tidak seragam, menyebabkan perbedaan signifikan dalam jumlah data di berbagai shard.

  Seperti ditunjukkan pada gambar berikut, sebuah tabel besar didistribusikan secara tidak merata. Shard_0 dan Shard_1 pada Storage Node 0 berisi banyak data, sedangkan Shard_2 dan Shard_3 pada Storage Node 1 memiliki lebih sedikit data. Saat Anda melakukan kueri pada tabel ini, Storage Node 0 kemungkinan besar akan memproses lebih banyak data daripada Storage Node 1. Hal ini menyebabkan utilisasi CPU Storage Node 0 secara konsisten lebih tinggi daripada Storage Node 1, sehingga terjadi kesenjangan utilisasi CPU.

  Untuk informasi tentang cara mendiagnosis kesenjangan tabel sumber, lihat Storage diagnostics. Fitur diagnostics juga mendeteksi tabel miring yang menempati ruang disk besar untuk membantu Anda menganalisis kesenjangan resource.

• Kesenjangan data antara

  Kesenjangan data berbeda dari kesenjangan tabel sumber. Dalam skenario ini, data tabel sumber mungkin didistribusikan secara merata di seluruh shard, tetapi distribusi nilai untuk bidang tertentu tidak seragam.

  Saat Anda melakukan kueri agregasi group-by atau menggunakan field yang tidak merata sebagai kondisi JOIN, AnalyticDB for MySQL mendistribusikan ulang data di berbagai node berdasarkan field tersebut. Setelah redistribusi, data dengan nilai field yang sama dikirim ke node yang sama, yang dapat menyebabkan kesenjangan data.

  Seperti ditunjukkan pada gambar berikut, sebuah tabel didistribusikan berdasarkan field 'a'. Karena field 'a' memiliki nilai seragam, data terdistribusi merata di node penyimpanan. Namun, saat Anda melakukan group by berdasarkan field 'b' (group by b), Storage Node 1 mengirim baris dengan nilai 'b1' ke Compute Node 1. Untuk memastikan Compute Node 1 memiliki semua baris dengan nilai 'b1', Storage Node 2 juga mengirim baris 'b1'-nya ke Compute Node 1, sementara mengirim baris 'b2' ke Compute Node 2. Akibatnya, Compute Node 1 menerima jauh lebih banyak baris daripada Compute Node 2, sehingga terjadi kesenjangan data. Untuk komputasi selanjutnya, Compute Node 1 akan mengonsumsi lebih banyak resource kluster.

  Untuk memecahkan masalah utilisasi CPU tidak merata akibat kesenjangan data antara, Anda dapat menganalisis hasil diagnosis tingkat stage kueri untuk mengidentifikasi akar masalah.

Utilisasi CPU maksimum tinggi dan rata-rata moderat

Ukuran hasil kueri besar

Penyebab: Satu kueri SQL yang mengembalikan data dalam jumlah sangat besar dapat meningkatkan utilisasi CPU node akses.

Solusi: Tambahkan kondisi kueri yang lebih spesifik untuk mempersempit cakupan pencarian dan mengurangi jumlah data yang dikembalikan. Atau, gunakan kueri terpaginasi untuk menghindari pemuatan konten berlebihan sekaligus. Jika Anda perlu mengekspor data dalam jumlah besar, Anda dapat menggunakan tabel eksternal.

Penggunaan CPU tinggi oleh pengoptimal

Penyebab: Saat permintaan per detik (QPS) kluster tinggi dan SQL kompleks, pengoptimal dapat mengonsumsi resource CPU dalam jumlah besar.

Solusi: Mulailah dengan mengaktifkan cache rencana. Setelah diaktifkan, amati apakah utilisasi CPU menurun secara signifikan. Jika tidak, kirim tiket untuk dukungan teknis.

Penulisan yang melibatkan bidang panjang

Penyebab: Saat sebuah tabel memiliki operasi write yang melibatkan field panjang, node akses mengonsumsi lebih banyak resource untuk memproses field tersebut, sehingga menyebabkan utilisasi CPU tinggi.

Solusi: Jalankan pernyataan berikut untuk memeriksa tabel dengan operasi write field panjang. Jika ditemukan, optimalkan logika bisnis untuk tabel tersebut dengan membatasi panjang field-nya atau membagi field panjang tersebut.

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;

Throughput I/O disk tinggi

Throughput I/O disk menunjukkan throughput media penyimpanan dasar, diukur dalam MB/s. Untuk nilai maksimumnya, lihat ESSD. Batas atas ini merupakan nilai teoretis yang diperoleh dari pengujian dalam kondisi ideal dan mungkin tidak mencerminkan beban kluster aktual. Biasanya, beban aktual dapat mencapai sekitar 80% dari nilai nominal tersebut.

IOPS disk tinggi

IOPS disk menunjukkan jumlah operasi I/O per detik pada media penyimpanan dasar. Untuk nilai IOPS disk maksimum, lihat ESSD. Batas atas ini merupakan nilai teoretis yang diperoleh dari pengujian dalam kondisi ideal dan mungkin tidak mencerminkan beban kluster aktual. Biasanya, beban aktual dapat mencapai sekitar 80% dari nilai nominal tersebut.

Utilisasi memori komputasi tinggi

Database analitik mengonsumsi resource memori dalam jumlah besar saat melakukan komputasi data skala besar. Kueri SQL yang intensif memori biasanya melibatkan operator agregasi, topN, window, dan join:

• Operator agregasi

  Operator agregasi mengonsumsi memori tinggi terutama karena AnalyticDB for MySQL menyimpan sementara informasi pengelompokan di memori. Jika field pengelompokan memiliki banyak nilai unik, sejumlah besar memori dikonsumsi di tahap akhir agregasi terdistribusi. Tahap parsial mengonsumsi lebih sedikit memori karena tidak memerlukan agregasi global; setiap node dapat mengirim data ke node downstream setelah menyelesaikan agregasi lokal pada subset data.

• Operator TopN

  Saat AnalyticDB for MySQL melakukan perhitungan TopN (misalnya, dalam kueri SQL dengan ORDER BY id LIMIT m,n), operator TopN di AnalyticDB for MySQL menyimpan cache sejumlah besar data di memori untuk menyelesaikan pengurutan global akhir jika nilai m besar. Proses ini mengonsumsi resource memori dalam jumlah besar.

• Operator jendela

  Operator window digunakan untuk menghitung fungsi jendela. Mirip dengan operator agregasi, operator ini perlu menyimpan sementara sejumlah besar data di memori untuk mencapai hasil semantik akhir.

• Operator join

  AnalyticDB for MySQL mendukung operasi kueri JOIN standar. Sistem biasanya menggunakan algoritma hash dan indeks untuk mengimplementasikan proses join. Untuk informasi lebih lanjut, lihat Operators. Algoritma hash menyimpan cache tabel yang lebih kecil (tabel build) di memori dan membangun tabel hash untuk mempercepat proses join. Faktor-faktor berikut dapat menyebabkan tabel hash menempati memori dalam jumlah besar:

  • Tabel build itu sendiri besar:

    AnalyticDB for MySQL menggunakan statistik untuk memperkirakan ukuran tabel di kedua sisi operasi JOIN dan memilih yang lebih kecil sebagai tabel build. Namun, masih mungkin tabel build tersebut besar.

  • Statistik usang atau tidak akurat:

    Jika tabel dalam operasi JOIN bukan tabel sumber tetapi merupakan hasil dari beberapa agregasi, filter, atau join lain, sulit untuk memperkirakan ukurannya secara akurat berdasarkan statistik tabel sumber. Selain itu, jika statistik usang, tabel yang lebih besar mungkin salah dipilih sebagai tabel build dan digunakan untuk membangun tabel hash. Untuk informasi lebih lanjut, lihat Statistics.

  • Left Join:

    Karena persyaratan semantik, tabel kanan LEFT JOIN harus digunakan untuk membangun tabel hash guna memastikan hasil yang benar. Jika tabel kanan LEFT JOIN besar, operasi join akan mengonsumsi memori dalam jumlah besar.

Untuk informasi lebih lanjut tentang operator-operator ini, lihat Operators.

Saat terdapat konkurensi tinggi kueri SQL yang mengandung operator-operator ini, atau saat satu operator mengonsumsi memori dalam jumlah besar, metrik utilisasi memori komputasi meningkat. Hal ini dapat memengaruhi stabilitas kluster dan menyebabkan error kueri. Error umum meliputi:

• Query exceeded reserved memory limit: Suatu kueri menggunakan lebih banyak memori daripada batasnya pada satu node.

• Query exceeded system memory pool limit: Satu field terlalu panjang, atau terlalu banyak kolom yang terlibat dalam komputasi.

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

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

Untuk mengurangi utilisasi memori komputasi, setel kueri SQL yang mengandung jenis operator ini. Untuk petunjuk terperinci, lihat Operator-level diagnostic results.

Peningkatan jumlah pekerjaan BUILD

Pekerjaan BUILD terutama membangun indeks untuk data yang ditulis, membersihkan data kadaluarsa, dan mengeksekusi tugas DDL Asinkron. Proses ini mengubah data dari keadaan yang dioptimalkan untuk write menjadi keadaan yang dioptimalkan untuk read. Dalam beberapa kasus, pekerjaan BUILD dapat mengonsumsi resource CPU dan I/O disk tinggi pada node penyimpanan, yang dapat memengaruhi operasi lain dan menyebabkan masalah stabilitas kluster. Tabel berikut menjelaskan metrik BUILD.

Jika peningkatan jumlah pekerjaan BUILD memengaruhi utilisasi CPU node baca/tulis, Anda dapat menyelidiki dan menganalisis masalah tersebut dari perspektif berikut:

• Partisi tunggal besar dalam tabel partisi. Saat satu partisi besar, partisi tersebut lebih mungkin ditulis, diperbarui, atau dihapus, sehingga lebih mudah memicu BUILD pada partisi tersebut. Anda dapat menggunakan Storage diagnostics untuk menemukan tabel jenis ini dan mengoptimalkan strukturnya.

• Tabel non-partisi yang sangat besar juga merupakan penyebab umum. Saat tabel non-partisi besar, tabel tersebut juga lebih mungkin terlibat dalam operasi write, update, atau delete, yang dapat dengan mudah memicu BUILD tabel penuh.

• Jumlah besar permintaan baca dan tulis menyebabkan utilisasi CPU tinggi yang berkelanjutan pada node penyimpanan, yang pada gilirannya memperlambat eksekusi pekerjaan BUILD.

Peningkatan jumlah node offline

Saat node dalam kluster AnalyticDB for MySQL menjadi tidak tersedia, node tersebut offline. Kegagalan node menurunkan stabilitas kluster, menyebabkan kueri dan write lebih lambat, serta error kueri. Saat node offline, analisis apakah utilisasi CPU tinggi secara persisten atau metrik terkait I/O secara konsisten mencapai batasnya.

Kurva P95

AnalyticDB for MySQL menyediakan kurva pemantauan P95 untuk metrik seperti utilisasi CPU, utilisasi CPU node akses, utilisasi memori komputasi, throughput I/O disk, IOPS disk, utilisasi I/O disk, dan waktu tunggu I/O disk. Metrik P95 merepresentasikan nilai di atau di bawah mana 95% observasi berada. Misalnya, ambil utilisasi CPU node komputasi. Jika kluster memiliki 100 node komputasi, utilisasi CPU semua node diurutkan secara menaik pada titik waktu tertentu. Utilisasi CPU node ke-95 adalah utilisasi CPU P95 untuk node komputasi.

Perbedaan antara nilai maksimum, rata-rata, dan P95 adalah sebagai berikut:

• Nilai maksimum hanya menunjukkan batas atas data. Dalam keberadaan pencilan atau nilai ekstrem, nilai maksimum metrik pemantauan dapat dipengaruhi oleh titik-titik individual ini dan mungkin tidak secara akurat merepresentasikan kondisi umum atau tipikal dataset.

• Nilai rata-rata dimaksudkan untuk menggambarkan kecenderungan pusat data, tetapi mungkin tidak secara akurat mencerminkan kondisi umum jika dataset mengandung pencilan atau memiliki distribusi miring.

• Nilai P95 berfokus pada performa bagian atas data sambil mengabaikan titik data paling ekstrem. Nilai ini cocok untuk mengevaluasi performa atau tingkat dalam sebagian besar situasi.

Peningkatan waktu respons kueri

Metrik waktu respons kueri merepresentasikan waktu dari saat kueri diajukan, melalui antrian, hingga selesai dieksekusi. Untuk informasi lebih lanjut tentang waktu eksekusi di AnalyticDB for MySQL, lihat Monitoring FAQ.

Peningkatan mendadak waktu respons kueri kluster mungkin disebabkan oleh faktor-faktor berikut:

• SQL buruk

  SQL buruk mengonsumsi resource kluster dalam jumlah besar, memengaruhi eksekusi kueri SQL lainnya.

• Pola abnormal

  Pola abnormal dapat muncul dalam dua cara: kueri berresource rendah dieksekusi dengan frekuensi sangat tinggi, atau kueri berresource tinggi menciptakan bottleneck performa bagi seluruh kluster. Hal ini pada akhirnya memengaruhi kueri lain dan meningkatkan waktu respons kueri secara keseluruhan.

• Peningkatan volume write

  Peningkatan volume write mengonsumsi lebih banyak resource CPU dan I/O disk, memicu lebih banyak pekerjaan BUILD, dan pada akhirnya menyebabkan peningkatan waktu respons kueri secara keseluruhan.

Di halaman Informasi Pemantauan di Konsol, Anda dapat memilih rentang waktu saat waktu respons kueri meningkat dan menjalankan diagnostics untuk menganalisis penyebab spesifik berdasarkan berbagai hasil diagnosis.

Peningkatan waktu tunggu kueri

Saat kueri diajukan ke node akses, kluster menentukan apakah akan mengantrikan kueri berdasarkan pengaturan ukuran antrian lapisan akses. Hal ini mencegah terlalu banyak kueri SQL berjalan secara konkuren, yang dapat meningkatkan tekanan kluster dan memengaruhi stabilitas keseluruhan. Untuk informasi lebih lanjut, lihat Concurrency control.

Peningkatan mendadak waktu tunggu kueri biasanya disebabkan oleh penurunan efisiensi eksekusi internal kluster. Hal ini dapat disebabkan oleh SQL buruk atau pola abnormal yang mengonsumsi resource kluster dalam jumlah besar. Anda dapat menggunakan diagnostics untuk memeriksa hasil deteksi SQL buruk multidimensi dan hasil deteksi pola abnormal. Peningkatan jumlah data yang ditulis, yang mengonsumsi lebih banyak resource CPU dan I/O pada node penyimpanan, juga dapat menyebabkan waktu tunggu kueri lebih lama.

Peningkatan tingkat kegagalan kueri

Metrik tingkat kegagalan kueri hanya menghitung proporsi kueri yang gagal dan tidak memberikan alasan kegagalannya. Kegagalan kueri dapat memiliki berbagai penyebab. Penyebab umum dan solusinya adalah sebagai berikut:

• Kegagalan kueri akibat masalah pernyataan SQL

  • Error sintaksis

    Pernyataan SQL tidak sesuai dengan sintaksis SQL yang ditentukan oleh AnalyticDB for MySQL. Error biasanya dilaporkan selama tahap penguraian SQL. Contohnya termasuk pernyataan SQL tidak lengkap, format salah, dan kata kunci atau tanda baca yang hilang.

  • Error semantik

    Pernyataan SQL sesuai dengan sintaksis SQL yang ditentukan oleh AnalyticDB for MySQL, tetapi ditemukan error pada objek basis data selama pemeriksaan semantik. Error dilaporkan selama tahap analisis semantik. Contohnya termasuk nama tabel salah, kolom tidak ada, field GROUP BY hilang, atau tipe parameter fungsi salah.

• Kegagalan kueri akibat masalah internal kluster

  • Timeout kueri

    AnalyticDB for MySQL memiliki timeout kueri default. Anda juga dapat mengonfigurasi timeout kueri sesuai kebutuhan bisnis Anda. Jika waktu eksekusi kueri melebihi batas ini, kueri gagal.

    Catatan

    • Untuk informasi tentang timeout kueri default, lihat Limits.

    • Untuk mempelajari cara mengubah timeout kueri, lihat Config and Hint configuration parameters.

  • Tekanan kluster tinggi

    Saat kluster mengalami tekanan tinggi, timeout komunikasi node internal atau kegagalan proses internal dapat menyebabkan kegagalan kueri.

• Read-only

  Saat sistem mendeteksi masalah pada log Raft, sistem segera mengatur status proses menjadi read-only. Dalam keadaan ini, operasi write akan gagal.

• Timeout

  Jika sistem tidak dapat mengonsumsi antrian log Raft tepat waktu (misalnya, karena write lambat akibat kunci primer panjang), tekanan balik terjadi, yang pada akhirnya memperlambat kecepatan write dan menyebabkan error timeout.

Jumlah data yang dibaca dari tabel

Di AnalyticDB for MySQL, data disimpan di berbagai node penyimpanan. Metrik Jumlah data yang dibaca dari tabel menunjukkan total data yang dikembalikan dari lapisan penyimpanan ke lapisan komputasi oleh semua kueri SQL pada titik waktu tertentu.

Seperti ditunjukkan pada gambar berikut, pada titik waktu tertentu (Time_1), 6 kueri SQL (query1, query2, query3, query4, query5, dan query6) membaca data dari 6 tabel (user, report, customer, test, region, dan partition). Pada titik waktu ini, total data yang dibaca dari tabel adalah 20,1 GB (dihitung sebagai 1,6 + 2 + 3 + 0,7 + 4,8 + 8 = 20,1 GB). Rata-rata data yang dibaca dari tabel adalah 6,7 GB (dihitung sebagai total data yang dibaca dari semua node penyimpanan / jumlah node penyimpanan, yaitu (1,6 + 2 + 3 + 0,7 + 4,8 + 8) / 3 = 6,7 GB). Jumlah maksimum data yang dibaca dari tabel adalah 12,8 GB (dihitung sebagai 4,8 + 8 = 12,8 GB).

Total, maksimum, dan rata-rata jumlah data yang dibaca dari tabel dapat mencerminkan tekanan kueri SQL terhadap kluster sampai batas tertentu.

• Saat rata-rata jumlah data yang dibaca dari tabel meningkat secara mendadak, hal ini menunjukkan bahwa sejumlah besar data dikirim dari lapisan penyimpanan ke lapisan komputasi untuk diproses, yang mengonsumsi lebih banyak resource CPU dan memori. Secara bersamaan, peningkatan jumlah data yang dibaca dari lapisan penyimpanan juga mengonsumsi lebih banyak resource I/O disk.

• Saat terdapat perbedaan besar antara jumlah maksimum dan rata-rata data yang dibaca dari tabel, hal ini menunjukkan bahwa jumlah data yang dibaca dari berbagai node penyimpanan berbeda-beda. Perbedaan beban pemrosesan data ini dapat menyebabkan beberapa node mencapai bottleneck resource lebih awal, yang pada gilirannya memengaruhi performa keseluruhan kluster. Situasi ini sering disebabkan oleh desain tabel yang tidak optimal, seperti memilih kunci distribusi tidak merata untuk beberapa tabel, sehingga menyebabkan distribusi data tidak merata di berbagai node penyimpanan.

Peningkatan waktu respons write, delete, dan update

Metrik waktu respons write, waktu respons delete, dan waktu respons update menunjukkan waktu yang diperlukan untuk memproses setiap baris untuk operasi INSERT INTO VALUES, DELETE, dan UPDATE, masing-masing. Waktu respons umumnya dipengaruhi oleh faktor-faktor berikut:

• Utilisasi CPU tinggi pada node penyimpanan

  Hal ini dapat disebabkan oleh faktor lain, seperti SQL buruk atau peningkatan TPS write, delete, atau update.

• Metrik I/O terkait write tinggi pada node penyimpanan

  Metrik I/O terkait write pada node penyimpanan meliputi throughput I/O disk dan IOPS disk. Metrik ini dapat meningkat karena alasan berikut:

  • Peningkatan jumlah pekerjaan BUILD.

  • Sistem melakukan operasi backup atau scaling.

  Karena operasi-operasi ini semua memerlukan write disk, mereka dapat memengaruhi waktu respons terkait.

  Jika waktu respons write terus meningkat selama pemrosesan data, kami menyarankan Anda menjadwalkan pekerjaan pemrosesan data skala besar selama jam sepi dan membatasi jumlah pekerjaan write konkuren untuk mengurangi tekanan I/O disk.