Perekaman performa Cloud SQL untuk MySQL membantu Anda mendiagnosis dan menyelesaikan masalah performa yang kompleks dan sementara di database MySQL yang disebabkan oleh permintaan sistem yang terus berubah. Seiring dengan bertambahnya skala workload aplikasi dan semakin kompleksnya infrastruktur di sekitarnya, database akan mengalami peningkatan permintaan yang tidak dapat diprediksi. Tekanan sistem eksternal ini dapat menyebabkan database melambat atau terhenti.
Saat database Anda mengalami penurunan performa, metrik standar mungkin tidak cukup untuk mengidentifikasi penyebab utama dalam konteks infrastruktur Anda yang lebih besar. Pengambilan performa mengatasi masalah ini dengan mengambil snapshot database yang mendetail dan tepat waktu pada saat masalah terdeteksi. Anda dapat menggunakan pemicu yang dapat dikonfigurasi untuk mengambil snapshot di seluruh sistem saat terjadi masalah sementara. Pemicu juga dapat mendeteksi transaksi yang berjalan lama, yang dapat menjadi penyebab utama masalah performa. Anda dapat mengonfigurasi pemicu untuk mengakhiri transaksi yang berjalan lama secara otomatis.
Contoh kasus penggunaan
Bagian ini mencantumkan contoh kasus penggunaan tentang cara menggunakan perekaman performa setelah Anda mengaktifkannya untuk instance Anda.
| Kasus penggunaan | Kondisi pemicu | Insight diagnostik |
|---|---|---|
| Perlambatan di seluruh sistem karena penumpukan log urungkan | Panjang daftar histori | Mengidentifikasi kapan proses penghapusan InnoDB tertinggal karena operasi baca yang berjalan lama atau operasi bahasa manipulasi data (DML) yang besar. Penundaan dapat menyebabkan peningkatan tekanan penyimpanan dan penurunan performa. |
| Database terhenti karena persaingan mesin internal | Semaphore menunggu | Berguna untuk mendiagnosis database yang tidak responsif. Pemicu ini dapat mendeteksi pertentangan kunci baca-tulis atau mutex dalam mesin penyimpanan InnoDB, seperti pertentangan kumpulan buffer atau Adaptive Hash Index (AHI). |
| Perselisihan kunci tingkat aplikasi atau kueri yang tidak diindeks | Penantian penguncian transaksi | Dipicu saat sejumlah besar
transaksi berada dalam status
LOCK WAIT, yang menunjukkan pertentangan
tingkat baris atau transaksi
idle yang berjalan lama. |
| Overload instance dari pengurutan atau penggabungan yang kompleks | Penggunaan CPU yang tinggi | Mencatat status selama penggunaan CPU container yang tinggi, sering kali disebabkan oleh kueri yang tidak efisien atau lonjakan serentak yang besar. |
| Risiko memulai ulang karena Out-of-Memory (OOM) | Penggunaan memori yang tinggi | Membantu Anda mendiagnosis masalah seperti buffer per-thread yang terlalu besar atau kebocoran memori sebelum menyebabkan instance error. |
| Lonjakan traffic tiba-tiba atau aplikasi klien yang mengalami hambatan | Menjalankan thread | Indikator umum beban instance, berguna untuk mengidentifikasi lonjakan tiba-tiba dalam koneksi aktif serentak. |
| Data usang di replika karena beban kerja penulisan yang berat | Beberapa detik di belakang sumber | Memantau keterlambatan replikasi pada replika baca untuk membantu mendiagnosis keterlambatan dalam menyinkronkan data dari instance utama. |
| Kueri yang berjalan lama memblokir penghapusan | Transaksi yang berjalan lama | Mengidentifikasi transaksi yang telah terbuka terlalu lama dan yang mungkin menahan kunci penting. Selain itu, Anda dapat mengakhiri transaksi yang berjalan lama secara otomatis. |
Cara data performa dicatat
Perekaman performa beroperasi sebagai layanan berbasis agen yang memantau instance Anda. Saat Anda mengaktifkan pengambilan performa, instance Cloud SQL Anda akan melakukan hal berikut untuk mengambil data performa:
Agen menyelidiki konfigurasi instance Anda untuk membaca pemicu berbasis nilai minimum yang telah Anda tentukan. Kemudian, agen akan menyelidiki metrik instance Anda pada interval yang dapat dikonfigurasi,
probingIntervalSeconds, yang secara default disetel ke 30 detik.Jika masalah terdeteksi dan nilai minimum pemicu telah terlampaui, agen akan terus membandingkan status aktif instance dengan aturan Anda. Untuk mencegah alarm palsu dari lonjakan sementara, agen akan memicu pengambilan performa penuh. Pengambilan dipicu hanya jika kondisi terpenuhi selama pemeriksaan berturut-turut untuk
probeThresholdyang dikonfigurasi, yang secara default adalah3. Nilai minimum berturut-turut ini mencegah pengambilan karena lonjakan sementara.Misalnya, agen dapat memicu perekaman performa jika mendeteksi bahwa jumlah thread tinggi untuk tiga probe berturut-turut.
Jika beberapa kondisi pemicu dikonfigurasi, Cloud SQL akan memulai pengambilan jika salah satu kondisi terpenuhi.
Saat pengambilan dipicu, pengambilan performa akan terhubung ke database dan menjalankan serangkaian perintah diagnostik untuk mengambil snapshot mendetail.
Informasi yang diambil diformat menjadi entri log dan dikirim langsung ke Cloud Logging project untuk instance Cloud SQL di bawah aliran log tertentu yang bernama
mysql-performance-capture.log.
Periode tunggu dan penundaan adaptif
Untuk mencegah logging yang berlebihan dan overhead sistem, pengambilan performa menerapkan periode pendinginan setelah pengambilan.
Pengurangan suara dan getaran standar
Setelah perekaman berhasil, perekaman performa akan memulai pendinginan standar 30 menit. Selama waktu ini, agen tidak memicu perekaman baru meskipun instance berada dalam status masalah yang diperpanjang.
Penundaan dan penghentian adaptif
Jika instance berulang kali memicu pengambilan untuk pelanggaran yang sama, maka pengambilan performa akan menggunakan mekanisme penundaan adaptif. Mekanisme ini membantu membatasi volume logging dan biaya untuk nilai minimum yang salah dikonfigurasi.
Dalam mekanisme ini:
- Waktu tunggu diperpanjang hingga 24 jam.
- Perekaman performa memasuki mode tidur, yang menangguhkan semua pemeriksaan pemicu dan perekaman diagnostik.
- Instance dibatasi untuk satu pengambilan performa per hari.
Pemicu pengambilan performa
Bagian ini mencantumkan pemicu yang tersedia untuk pengambilan performa MySQL. Semua pemicu yang tercantum dalam tabel, kecuali jika dinyatakan lain, menggunakan nilai konfigurasi probe probingIntervalSeconds dan probeThreshold untuk memvalidasi kondisi pemicu berkelanjutan.
| Kondisi pemicu nama | Nama API | Deskripsi | Nilai default | Konfigurasi rentang |
|---|---|---|---|---|
| Penggunaan CPU yang tinggi |
cpuUtilizationThresholdPercent
|
Memicu pengambilan saat penggunaan CPU keseluruhan instance database secara konsisten melebihi persentase ini. Hal ini membantu mendeteksi kelebihan beban instance, yang sering kali disebabkan oleh kueri yang tidak efisien dengan pengurutan dan agregasi yang besar, pengindeksan yang tidak memadai, atau konkurensi yang sangat tinggi. Untuk menghindari pengambilan pada lonjakan kecil, konfigurasi default agar berada dalam rentang persentase yang lebih tinggi untuk instance Anda. | 0 (nonaktif)
|
0, atau 10-99 (%)
|
| Penggunaan memori tinggi |
memoryUsageThresholdPercent
|
Memicu pengambilan saat penggunaan memori penampung database secara konsisten melebihi persentase memori yang dialokasikan instance ini. Pemicu ini dapat membantu mendiagnosis potensi masalah kehabisan memori, kebocoran memori, atau konfigurasi memori yang tidak efisien. Untuk menghindari penangkapan lonjakan kecil, tetapkan default di ujung atas rentang untuk instance Anda. | 0 (nonaktif)
|
0, atau 10-99 (%)
|
| Penggunaan file temp yang tinggi |
Tidak dapat dikonfigurasi Pemicu ini diaktifkan secara otomatis untuk MySQL 8.0 dan yang lebih baru. | Secara otomatis memicu pengambilan saat ada peningkatan signifikan dalam penggunaan disk dari file sementara yang dibuat oleh proses MySQL.
Sering kali file sementara dihapus, tetapi masih
dibuka oleh proses MySQL. Ambang batas untuk pemicu ini menggunakan model eskalasi progresif untuk perbedaan ambang batas. Dimulai dari 100 GB dan berlipat ganda secara berurutan menjadi 200 GB, 400 GB, hingga 1,6 TB setelah setiap periode jeda. Dengan menggunakan model eskalasi progresif, pengambilan performa hanya terjadi jika perbedaan penggunaan file sementara meningkat pada tingkat yang tinggi. |
Aktif | t/a |
| Panjang daftar histori |
historyListLengthThresholdCount
|
Memicu pengambilan saat Panjang Daftar Histori (HLL) InnoDB melampaui nilai yang dikonfigurasi. HLL yang terus-menerus tinggi menunjukkan bahwa proses penghapusan InnoDB tidak dapat mengimbangi dan jumlah transaksi yang belum dihapus meningkat, sering kali karena transaksi yang berjalan lama. Jumlah
yang tinggi ini dapat menyebabkan peningkatan konsumsi penyimpanan dan masalah performa. Nilai minimum ini bergantung pada beban kerja. Beberapa instance dapat beroperasi dengan cukup baik meskipun dengan HLL yang selalu tinggi. Namun, Anda tetap dapat menggunakan pemicu ini untuk menandai potensi masalah seperti pembacaan yang berjalan lama, pernyataan bahasa pengolahan data (DML) yang besar, atau hambatan thread penghapusan permanen. |
0 (nonaktif)
|
0, atau 10000-10000000
|
| Transaksi yang berjalan lama |
transactionDurationThreshold
|
Transaksi dicatat ke dalam log jika transaksi berjalan lebih lama dari durasi yang dikonfigurasi dalam detik. Pemicu ini berguna untuk mengidentifikasi
operasi yang mungkin menahan kunci selama
periode yang berlebihan atau menggunakan resource
terlalu lama. Transaksi yang melebihi transactionDurationThreshold dievaluasi
setelah setiap interval yang ditentukan dalam
konfigurasi probingIntervalSeconds
(default 30 detik). Namun, untuk mengelola volume log, detail hingga 10 transaksi yang berjalan lama ini dikirim ke Cloud Logging paling banyak sekali setiap periode tunggu (30 menit).
Teks kueri lengkap hingga 1024 byte
dari INFORMATION_SCHEMA.INNODB_TRX disertakan dalam setiap entri log untuk 10 transaksi teratas. |
3600 (detik)
|
60 atau lebih
|
| Error thread SQL/IO replika |
Tidak dapat dikonfigurasi Pemicu ini diaktifkan secara default dan otomatis di semua instance replika dan tidak dapat dinonaktifkan. | Memicu pengambilan segera jika
thread SQL atau thread IO replikasi
pada instance replika mengalami error
dan berhenti. Pemicu ini sangat penting untuk
mempertahankan integritas replika dan
mengidentifikasi kegagalan replikasi. Pemicu ini tidak menggunakan setelan konfigurasi probe apa pun seperti probingIntervalseconds atau
probeThreshold untuk memvalidasi kondisi pengambilan
performa. |
Aktif | t/a |
| Menjalankan thread | runningThreadsThreshold
|
Memicu pengambilan saat jumlah thread aktif yang berjalan berdasarkan variabel status threads_running melebihi nilai yang ditentukan. Misalnya, Anda dapat mengonfigurasi nilai minimum untuk menjalankan pengambilan performa jika jumlah thread yang berjalan aktif lebih tinggi dari 100.Pemicu ini diperlukan untuk pengambilan performa. Jika Anda tidak mengonfigurasi pemicu ini secara eksplisit, nilai default akan dihitung berdasarkan jumlah vCPU yang termasuk dalam instance. |
MIN(600,
cpuCount * 20)
|
10 atau lebih
|
| Detik di belakang sumber |
secondsBehindSourceThreshold
|
Memicu pengambilan saat jeda replikasi pada instance replika baca, yang diukur dalam detik, melebihi nilai yang ditentukan. Anda dapat menggunakan pemicu ini untuk memantau dan mendiagnosis keterlambatan dalam replikasi. Pemicu ini diaktifkan secara otomatis untuk instance replika. Jika Anda tidak mengonfigurasi pemicu secara eksplisit, defaultnya adalah 900 detik. Sebaiknya konfigurasikan nilai yang lebih tinggi untuk menghindari pengambilan data yang berlebihan dan jeda yang terlalu sering. | 900 (detik)
|
1 atau lebih
|
| Semaphore menunggu | semaphoreWaitThresholdCount
|
Memicu pengambilan saat jumlah thread yang menunggu semafor InnoDB internal melebihi nilai pemicu ini yang dikonfigurasi. Metrik lanjutan ini menunjukkan pertentangan, menggunakan mutex atau kunci baca-tulis, dalam mesin penyimpanan InnoDB itu sendiri.
Perselisihan yang biasanya diamati adalah perselisihan Adaptive Hash Index (AHI), perselisihan kumpulan buffer, dan perselisihan IO disk. Perekaman juga dipicu jika waktu tunggu maksimum untuk satu semaphore melebihi 200 detik, terlepas dari nilai pemicu yang dikonfigurasi ini. |
0 (nonaktif)
|
0, atau 10-10000
|
| Penantian penguncian transaksi |
transactionLockWaitThresholdCount
|
Memicu pengambilan saat jumlah
transaksi dalam status LOCK WAIT
melebihi jumlah yang dikonfigurasi. Sejumlah kecil transaksi dalam status menunggu penguncian dapat menjadi hal yang normal dalam sistem yang sibuk, tetapi sejumlah besar penantian penguncian yang konsisten merupakan indikator kuat persaingan penguncian tingkat aplikasi, DML yang tidak diindeks, transaksi tidak aktif yang lama, dan persaingan konten baris konkurensi tinggi yang dapat menurunkan performa dan throughput secara signifikan. |
0 (nonaktif)
|
0, atau 10-10000
|
Harga
Perekaman performa tersedia di semua region Cloud SQL tanpa biaya tambahan. Biaya standar hanya berlaku untuk resource database pokok. Perekaman performa menyimpan log di Cloud Logging, yang dapat menimbulkan biaya penyimpanan Cloud Logging tambahan.
Untuk mengetahui informasi selengkapnya tentang harga penyimpanan log di Logging, lihat Harga.
Batasan
- Anda harus mengaktifkan insight kueri untuk menggunakan pengambilan performa. Jika Anda menonaktifkan insight kueri, pengambilan performa juga akan dinonaktifkan.
- Perekaman performa hanya tersedia untuk Cloud SQL untuk MySQL 5.7 dan yang lebih baru.