ApsaraDB RDS：Lihat metrik RDS for MySQL

Anda dapat menggunakan tampilan Memory OOM Diagnosis untuk menganalisis masalah kehabisan memori (OOM).

• Memory Usage:

  • Jika penggunaan Buffer Pool InnoDB tetap tidak berubah sementara penggunaan memori meningkat secara perlahan dan terus-menerus selama periode panjang, seperti lebih dari tujuh hari, kemungkinan besar terjadi kebocoran memori.

  • Jika penggunaan memori tiba-tiba meningkat sementara penggunaan Buffer Pool InnoDB tetap tidak berubah, peningkatan tersebut mungkin disebabkan oleh lonjakan lalu lintas.

  • Jika baik memori maupun penggunaan Buffer Pool InnoDB meningkat, Buffer Pool InnoDB sedang diisi secara bertahap, yang merupakan hal normal.

• Resident Memory: Jumlah memori fisik yang digunakan.

• Open files, Temp File Size, Temp Disk Tables, dan Sort Rows adalah metrik umum yang menunjukkan konsumsi memori.

Pertumbuhan memori terkait dengan metrik bisnis. Pernyataan SQL yang menyebabkan lonjakan memori mendadak sering kali tidak dapat dilacak karena OOM. Oleh karena itu, kami sarankan Anda:

• Periksa log bisnis untuk menentukan penyebab peningkatan memori mendadak.

• Tingkatkan spesifikasi memori dan aktifkan SQL Explorer dan Audit. Jika lonjakan memori mendadak terjadi, Anda dapat memeriksa waktu eksekusi kueri SQL untuk menentukan penyebabnya.

Anda dapat menggunakan tampilan Read-only Instance Delay Diagnosis untuk mendiagnosis delay untuk instansi hanya baca.

• Active Session: Periksa adanya pemblokiran dari kunci metadata.

  Secara umum, kueri pada jumlah data yang besar mencegah pernyataan DDL memperoleh kunci metadata. Dalam kasus ini, pernyataan DDL memblokir sesi lain, yang menyebabkan koneksi menumpuk.

• DML Rows Processed, Pages Requested, DML/DDL Operations, dan Temp Disk Space Used: Menampilkan metrik bisnis umum.

• Replication Delay: Metrik latensi.

Anda dapat melihat jenis file yang menempati ruang penyimpanan instans dan tren perubahannya. Metrik berikut biasanya terkait dengan penggunaan penyimpanan:

• File data (user_data_size): Anda dapat menggunakan Analisis Ruang untuk melihat penggunaan ruang setiap database dan tabel, lalu skala keluar atau hapus data yang tidak perlu. Untuk informasi lebih lanjut, lihat Solusi untuk Instans Penuh yang Disebabkan oleh File Data.

• File sementara (temp_file_size): Tabel sementara mungkin dihasilkan saat Anda mengeksekusi pernyataan SQL untuk mengurutkan dan mengelompokkan data atau mengaitkan tabel. File cache log biner dihasilkan sebelum transaksi besar dikomit. Tabel dan file ini menempati ruang penyimpanan. Untuk informasi lebih lanjut, lihat Selesaikan penyimpanan instans penuh yang disebabkan oleh file sementara.

• Log biner (binlog_size): Transaksi besar dapat dengan cepat menghasilkan log biner. Log ini menempati ruang penyimpanan. Untuk informasi lebih lanjut tentang cara mengelola log biner, lihat Selesaikan penyimpanan instans penuh yang disebabkan oleh file log biner MySQL.

  Catatan

  Jika layanan Anda berlangganan log biner database, log tersebut mungkin tidak dibersihkan tepat waktu dan dapat menempati ruang.

• Log undo (undo_log_size): Dalam kebanyakan kasus, kueri yang berjalan lama mencegah log undo dibersihkan. Anda dapat memeriksa kueri yang berjalan lama yang belum selesai.

  Catatan

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

• Log lambat (slowlog_size): Jika log lambat menggunakan terlalu banyak ruang, Anda dapat menggunakan perintah truncate untuk membersihkannya selama jam-jam sepi.

  Catatan

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

• Log umum (general_log_size): Ukuran total log kesalahan, Performance Agent, dan pemulihan instans, yang biasanya stabil dan kurang dari 1 GB. Jika ukurannya signifikan melebihi nilai ini, silakan ajukan tiket untuk menghubungi tim produk. Metrik ini mewakili data yang dihasilkan secara berkala oleh kernel MySQL, bukan ukuran file general_log di MySQL.

Anda dapat menggunakan tampilan CPU Jitter Diagnostics untuk menganalisis masalah jitter CPU. Metrik yang relevan meliputi berikut ini:

• Metrik bisnis:

  • Page Request: Biasanya, permintaan Buffer Pool berfluktuasi seiring dengan pemanfaatan CPU.

  • Rows Processed: Periksa hubungan antara pemanfaatan CPU dan jumlah baris yang diproses untuk menentukan apakah lonjakan dalam jumlah baris sesuai dengan perubahan pemanfaatan CPU.

  • Queries: Lihat jenis utama pernyataan SQL yang dieksekusi saat pemanfaatan CPU berubah.

• Koneksi:

  Thread Running: Konkurensi tinggi dapat menyebabkan pemanfaatan CPU tinggi. Penumpukan MDL atau kunci baris juga dapat menyebabkan penumpukan koneksi, yang meningkatkan pemanfaatan CPU.

Penyebab umum jitter CPU:

• Perubahan dalam metrik bisnis, seperti Page Request atau Rows Processed, dapat memengaruhi pemanfaatan CPU. Jika ini terjadi, Anda dapat memilih rentang waktu perubahan pemanfaatan CPU dan menjalankan Diagnosis untuk mendapatkan analisis penyebab akar yang rinci.

• Peningkatan koneksi aktif menyebabkan konsumsi CPU. Dalam hal ini, Anda harus menyelidiki masalah dari sisi bisnis.

Anda dapat menggunakan tampilan Large Transaction Recognition Diagnosis untuk menganalisis masalah transaksi besar.

• Threads Connected, Temp File Size, dan Binlog Space: Ini adalah tiga metrik inti yang menunjukkan transaksi besar. Transaksi besar ada di database jika salah satu dari peristiwa berikut terjadi:

  • Sesi aktif menumpuk.

  • Ruang sementara pertama kali meningkat lalu menurun.

  • Setelah ruang sementara menurun, ruang Binlog meningkat.

• Rows Processed, Logical Page Write, dan Queries per Second: Metrik ini digunakan untuk menentukan jenis transaksi besar.

  Sebagai contoh, jika ada sedikit kueri tetapi banyak baris dihapus, itu menunjukkan transaksi besar yang menghapus data.

Transaksi besar dapat memblokir penulisan log biner:

• Saat instans memiliki transaksi besar, tablespace sementara (cache binlog) pertama-tama meningkat secara bertahap lalu stabil.

• Saat tablespace sementara stabil, ruang Binlog meningkat. Karena penulisan log biner bersifat serial global, transaksi lain diblokir, yang menyebabkan koneksi menumpuk.

• Jika instans menjalankan Edisi Ketersediaan Tinggi RDS, pernyataan probe dari komponen ketersediaan tinggi (HA) pada instans primer dan sekunder juga diblokir, dan failover primer/sekunder terjadi.