ApsaraDB RDS:Lihat metrik RDS for MySQL

Lihat performance events

Area statistik event menampilkan jumlah event berdasarkan jenis dalam rentang waktu yang dipilih. Klik View Details untuk membuka halaman View Performance Events, tempat Anda dapat melihat aktivitas anomali dan event optimasi—yang dijadwalkan, sedang berjalan, atau telah selesai.

Lihat performance metrics

Dalam Classic View bawaan:

• Klik More Metrics untuk memilih metrik tambahan dan melihat tren kinerjanya.

• Klik setelah nama metrik untuk melihat sub-metrik yang dikandungnya.

• Klik Details pada grafik tren apa pun untuk memperbesar dan menyesuaikan rentang waktu.

• Klik Add Trend Comparison untuk membandingkan metrik yang sama di periode waktu berbeda.

Analisis event pada grafik metrik

Dalam Classic View, pilih tingkat event untuk menampilkan event terkait secara overlay pada grafik tren MySQL CPU/Memory Utilization dan Session Connections. Klik penanda event apa pun untuk melihat hasil diagnosanya.

Jalankan diagnosis pada rentang waktu

Pada grafik tren metrik apa pun, seret untuk memilih rentang waktu, lalu klik Diagnose untuk mendapatkan analisis akar penyebab terperinci untuk periode tersebut.

Gunakan diagnostic views

Klik salah satu dari lima tampilan diagnostik berikut untuk menyelidiki jenis masalah tertentu:

• Memory OOM Diagnosis

• Read-only Instance Delay Diagnosis

• Full Disk Space Diagnosis

• CPU Jitter Diagnosis

• Large Transaction Recognition Diagnosis

Untuk interpretasi metrik dan langkah selanjutnya untuk setiap tampilan, lihat Diagnostic views.

Memory OOM diagnosis

Tampilan Memory OOM Diagnosis membantu Anda menganalisis masalah kehabisan memori (OOM). Metrik utama dan indikasinya:

Memory Usage — interpretasikan trennya terhadap penggunaan InnoDB Buffer Pool:

Resident Memory menunjukkan jumlah memori fisik yang digunakan. Open files, Temp File Size, Temp Disk Tables, dan Sort Rows adalah indikator umum tekanan memori.

Karena event OOM sering kali menghentikan proses yang menyebabkan lonjakan tersebut, mengidentifikasi pernyataan SQL yang tepat setelah kejadian menjadi sulit. Untuk antisipasi:

• Periksa log bisnis saat lonjakan memori terjadi untuk melacak penyebabnya.

• Tingkatkan spesifikasi memori dan aktifkan SQL Explorer and Audit sehingga ketika lonjakan terjadi, Anda dapat memeriksa waktu eksekusi kueri untuk mengidentifikasi penyebabnya.

Read-only instance delay diagnosis

Tampilan Read-only Instance Delay Diagnosis membantu mendiagnosis latensi replikasi pada instans hanya baca. Metrik utama:

• Active Session: Mengindikasikan pemblokiran oleh kunci metadata. Kueri yang memindai data dalam jumlah besar mencegah pernyataan DDL mendapatkan kunci metadata, menyebabkan DDL memblokir sesi lain dan koneksi menumpuk.

• DML Rows Processed, Pages Requested, DML/DDL Operations, Temp Disk Space Used: Metrik workload bisnis umum.

• Replication Delay: Indikator latensi utama.

Full disk space diagnosis

Tampilan Full Disk Space Diagnosis menunjukkan jenis file yang mengonsumsi penyimpanan dan bagaimana ukurannya berubah seiring waktu. Kategori penyimpanan berikut dilacak:

• Data files (user_data_size): Gunakan Space Analysis untuk mengidentifikasi penggunaan ruang berdasarkan database dan tabel, lalu lakukan scale out atau hapus data yang tidak diperlukan. Lihat Solusi untuk instans penuh yang disebabkan oleh file data.

• Temporary files (temp_file_size): Dihasilkan selama operasi sort, group, dan join SQL, serta sebagai file cache log biner sebelum transaksi besar dikomit. Lihat Atasi penyimpanan instans penuh yang disebabkan oleh file sementara.

• Binary logs (binlog_size): Transaksi besar dapat menghasilkan log biner dengan cepat. Jika layanan Anda berlangganan log biner instans tersebut, log mungkin tidak segera dibersihkan. Lihat Atasi penyimpanan instans penuh yang disebabkan oleh file log biner.

• Undo logs (undo_log_size): Kueri yang berjalan lama mencegah undo log dibersihkan. Periksa adanya kueri yang telah berjalan tanpa selesai.

  Catatan

  Di MySQL 5.6 dan versi sebelumnya, undo log tidak memiliki ruang tabel terpisah.

• Slow log (slowlog_size): Jalankan perintah truncate selama jam sepi untuk membersihkan slow log jika mengonsumsi ruang berlebihan.

  Catatan

  Dukungan untuk perintah truncate ditambahkan di MySQL 5.7 versi 20210630 dan MySQL 8.0 versi 20210930.

• General logs (general_log_size): Ukuran gabungan log error, Performance Agent, dan recovery instans. Nilai ini biasanya stabil dan di bawah 1 GB. Jika jauh melebihi ambang batas ini, submit a ticket untuk menghubungi tim produk.

  Catatan

  general_log_size merepresentasikan data yang dihasilkan secara berkala oleh kernel MySQL—bukan ukuran file general_log MySQL.

CPU jitter diagnosis

Tampilan CPU Jitter Diagnosis membantu Anda mengidentifikasi penyebab fluktuasi utilisasi CPU. Lacak metrik berikut:

Business metrics:

• Page Request: Permintaan Buffer Pool biasanya berfluktuasi sejalan dengan utilisasi CPU.

• Rows Processed: Bandingkan dengan utilisasi CPU untuk menentukan apakah perubahan volume baris berkorelasi dengan lonjakan CPU.

• Queries: Identifikasi jenis pernyataan SQL yang dieksekusi selama perubahan utilisasi CPU.

Connections:

• Thread Running: Konkurensi tinggi meningkatkan utilisasi CPU. Penumpukan MDL dan kunci baris juga dapat menyebabkan penumpukan koneksi, yang meningkatkan beban CPU.

Penyebab umum dan langkah selanjutnya:

• Jika Page Request atau Rows Processed berubah saat CPU melonjak, seret untuk memilih rentang waktu yang terpengaruh lalu klik Diagnose untuk mendapatkan analisis akar penyebab terperinci.

• Jika koneksi aktif meningkat, selidiki dari sisi aplikasi untuk menentukan penyebab lonjakan koneksi tersebut.

Large transaction diagnosis

Tampilan Large Transaction Recognition Diagnosis membantu mengidentifikasi transaksi besar dan dampaknya. Tiga metrik inti menandakan adanya transaksi besar:

Rows Processed, Logical Page Write, dan Queries per Second mengindikasikan jenis transaksi. Misalnya, sedikit kueri dikombinasikan dengan jumlah penghapusan baris tinggi menunjukkan operasi DELETE besar.

Dampak transaksi besar terhadap instans:

1. Saat transaksi besar berjalan, ruang tabel sementara (cache log biner) meningkat secara bertahap, lalu stabil.

2. Begitu ruang tabel sementara stabil, ruang log biner meningkat. Karena penulisan log biner bersifat serial global, transaksi lain diblokir dan koneksi menumpuk.

3. Pada instans Edisi Ketersediaan Tinggi, pernyataan probe komponen HA pada instans primer dan sekunder juga diblokir, dan terjadi failover primer/sekunder.

Untuk mencegah masalah ini, pecah transaksi besar menjadi transaksi yang lebih kecil. Untuk pernyataan DELETE, tambahkan klausa WHERE yang membatasi jumlah baris yang dihapus per operasi, sehingga mengubah satu operasi penghapusan besar menjadi beberapa operasi penghapusan kecil.