Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Menyesuaikan Aurora MySQL
Peristiwa tunggu dan status thread adalah alat penyesuaian penting untuk Aurora MySQL. Jika Anda dapat mengetahui alasan mengapa sesi menunggu sumber daya dan operasi yang sedang dilakukannya, Anda akan lebih mampu mengurangi bottleneck. Anda dapat menggunakan informasi di bagian ini untuk menemukan kemungkinan penyebab dan tindakan korektif.
Amazon DevOps Guru untuk RDS dapat secara proaktif menentukan apakah basis data Aurora MySQL Anda mengalami kondisi bermasalah yang dapat menyebabkan masalah yang lebih besar nantinya. Amazon DevOps Guru for RDS menerbitkan penjelasan dan rekomendasi untuk tindakan korektif dalam wawasan proaktif. Bagian ini berisi wawasan untuk masalah umum.
**penting**
Peristiwa tunggu dan status thread di bagian ini dikhususkan untuk Aurora MySQL. Gunakan informasi di bagian ini untuk menyesuaikan Amazon Aurora saja, bukan Amazon RDS for MySQL.
Beberapa peristiwa tunggu di bagian ini tidak memiliki padanan di versi sumber terbuka dari mesin basis data ini. Peristiwa tunggu lainnya memiliki nama yang sama dengan peristiwa di mesin sumber terbuka, tetapi berperilaku berbeda. Misalnya, penyimpanan Amazon Aurora berfungsi secara berbeda dari penyimpanan sumber terbuka, sehingga peristiwa tunggu terkait penyimpanan menunjukkan kondisi sumber daya yang berbeda.
**Topics**
+ [Konsep penting untuk penyesuaian Aurora MySQL](AuroraMySQL.Managing.Tuning.concepts.md)
+ [Menyesuaikan Aurora MySQL dengan peristiwa tunggu](AuroraMySQL.Managing.Tuning.wait-events.md)
+ [Menyesuaikan Aurora MySQL dengan status thread](AuroraMySQL.Managing.Tuning.thread-states.md)
+ [Menyesuaikan Aurora MySQL dengan wawasan proaktif Amazon DevOps Guru](MySQL.Tuning.proactive-insights.md)
# Konsep penting untuk penyesuaian Aurora MySQL
Sebelum Anda menyesuaikan basis data Aurora MySQL Anda, pastikan untuk mempelajari peristiwa tunggu dan status thread dan mengapa itu terjadi. Tinjau juga arsitektur memori dan disk dasar Aurora MySQL saat menggunakan mesin penyimpanan InnoDB. Untuk diagram arsitektur yang bermanfaat, lihat [Panduan Referensi MySQL](https://dev.mysql.com/doc/refman/8.0/en/innodb-architecture.html).
**Topics**
+ [Peristiwa tunggu Aurora MySQL](#AuroraMySQL.Managing.Tuning.concepts.waits)
+ [Status thread Aurora MySQL](#AuroraMySQL.Managing.Tuning.concepts.thread-states)
+ [Memori Aurora MySQL](#AuroraMySQL.Managing.Tuning.concepts.memory)
+ [Proses Aurora MySQL](#AuroraMySQL.Managing.Tuning.concepts.processes)
## Peristiwa tunggu Aurora MySQL
*Peristiwa tunggu* menunjukkan sumber daya yang sedang ditunggu oleh sesi. Misalnya, peristiwa tunggu `io/socket/sql/client_connection` menunjukkan bahwa thread sedang dalam proses untuk menangani koneksi baru. Sumber daya biasa yang ditunggu oleh sesi meliputi yang berikut:
+ Akses thread tunggal ke buffer, misalnya, saat sesi mencoba memodifikasi buffer
+ Baris yang saat ini dikunci oleh sesi lain
+ Pembacaan file data
+ Penulisan file data
Misalnya, untuk memenuhi kueri, sesi mungkin melakukan pemindaian tabel lengkap. Jika data belum ada dalam memori, sesi akan menunggu I/O disk selesai. Ketika buffer dibaca ke dalam memori, sesi mungkin perlu menunggu karena sesi lain mengakses buffer yang sama. Basis data mencatat peristiwa tunggu dengan menggunakan peristiwa tunggu standar. Peristiwa tersebut dikelompokkan ke dalam kategori.
Peristiwa tunggu tidak dengan sendirinya menunjukkan masalah performa. Misalnya, jika data yang diminta tidak ada dalam memori, data perlu dibaca dari disk. Jika satu sesi mengunci baris untuk pembaruan, sesi lain akan menunggu baris tersebut dibuka sehingga dapat memperbaruinya. Commit perlu menunggu penulisan ke file log selesai. Peristiwa tunggu merupakan bagian integral dari fungsi normal basis data.
Sejumlah besar peristiwa tunggu biasanya menunjukkan masalah performa. Dalam kasus seperti itu, Anda dapat menggunakan data peristiwa tunggu untuk menentukan tempat sesi menghabiskan waktu. Misalnya, jika laporan yang biasanya berjalan dalam hitungan menit sekarang berjalan selama berjam-jam, Anda dapat mengidentifikasi peristiwa tunggu yang berkontribusi paling besar terhadap total waktu tunggu. Jika Anda dapat menentukan penyebab peristiwa tunggu teratas, terkadang Anda dapat membuat perubahan yang meningkatkan performa. Misalnya, jika sesi Anda menunggu baris yang telah dikunci oleh sesi lain, Anda dapat mengakhiri sesi penguncian ini.
## Status thread Aurora MySQL
*Status thread umum* adalah nilai `State` yang terkait dengan pemrosesan kueri umum. Misalnya, status thread `sending data` menunjukkan bahwa thread membaca dan memfilter baris untuk kueri guna menentukan set hasil yang benar.
Anda dapat menggunakan status thread untuk menyesuaikan Aurora MySQL dengan cara yang mirip dengan cara Anda menggunakan peristiwa tunggu. Misalnya, kemunculan `sending data` yang sering biasanya menunjukkan bahwa kueri tidak menggunakan indeks. Untuk informasi selengkapnya tentang status thread, lihat [General Thread States](https://dev.mysql.com/doc/refman/5.7/en/general-thread-states.html) dalam *Panduan Referensi MySQL*.
Saat Anda menggunakan Wawasan Performa, salah satu kondisi berikut ini akan berlaku:
+ Skema Performa diaktifkan – Aurora MySQL menunjukkan peristiwa tunggu, bukan status thread.
+ Skema Performa tidak diaktifkan – Aurora MySQL menunjukkan status thread.
Sebaiknya konfigurasikan Skema Performa untuk manajemen otomatis. Skema Performa memberikan wawasan tambahan dan alat yang lebih baik untuk menyelidiki potensi masalah performa. Untuk informasi selengkapnya, lihat [Ikhtisar Skema Kinerja untuk Performance Insights di Aurora ](USER_PerfInsights.EnableMySQL.md).
## Memori Aurora MySQL
Di Aurora MySQL, area memori yang paling penting adalah pool buffer dan log buffer.
**Topics**
+ [Pool buffer](#AuroraMySQL.Managing.Tuning.concepts.memory.buffer-pool)
### Pool buffer
*Pool buffer* adalah area memori bersama tempat Aurora MySQL menyimpan tabel dan data indeks. Kueri dapat mengakses data yang sering digunakan langsung dari memori tanpa membaca dari disk.
Pool buffer disusun sebagai daftar halaman yang ditautkan. *Halaman* dapat menyimpan beberapa baris. Aurora MySQL menggunakan algoritma least recently used (LRU) untuk mengeluarkan halaman dari pool berdasarkan umurnya.
Untuk informasi selengkapnya, lihat [Buffer Pool](https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html) dalam *Panduan Referensi MySQL*.
## Proses Aurora MySQL
Aurora MySQL menggunakan model proses yang sangat berbeda dari Aurora PostgreSQL.
**Topics**
+ [Server MySQL (mysqld)](#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld)
+ [Thread](#AuroraMySQL.Managing.Tuning.concepts.processes.threads)
+ [Pool thread](#AuroraMySQL.Managing.Tuning.concepts.processes.pool)
### Server MySQL (mysqld)
Server MySQL adalah proses sistem operasi tunggal bernama mysqld. Server MySQL tidak memunculkan proses tambahan. Dengan demikian, basis data Aurora MySQL menggunakan mysqld untuk melakukan sebagian besar pekerjaannya.
Ketika server MySQL dimulai, server tersebut akan mendengarkan koneksi jaringan dari klien MySQL. Ketika klien terhubung ke basis data, mysqld membuka thread.
### Thread
Thread pengelola koneksi mengaitkan setiap koneksi klien dengan thread khusus. Thread ini mengelola autentikasi, menjalankan pernyataan, dan memberikan hasil ke klien. Pengelola koneksi membuat thread baru jika diperlukan.
*Cache thread* adalah kumpulan thread yang tersedia. Ketika koneksi berakhir, MySQL mengembalikan thread ke cache thread jika cache tidak penuh. Variabel sistem `thread_cache_size` menentukan ukuran cache thread.
### Pool thread
*Pool thread* terdiri dari sejumlah grup thread. Setiap grup mengelola satu set koneksi klien. Ketika klien terhubung ke basis data, pool thread menetapkan koneksi ke grup thread dengan cara round-robin. Pool thread memisahkan koneksi dan thread. Tidak ada relasi tetap antara koneksi dan thread yang menjalankan pernyataan yang diterima dari koneksi tersebut.
# Menyesuaikan Aurora MySQL dengan peristiwa tunggu
Tabel berikut merangkum peristiwa tunggu Aurora MySQL yang paling sering menunjukkan masalah performa. Peristiwa tunggu berikut adalah bagian dari daftar dalam [Peristiwa tunggu Aurora MySQL](AuroraMySQL.Reference.Waitevents.md).
| Peristiwa tunggu | Deskripsi |
| --- | --- |
| [cpu](ams-waits.cpu.md) | Peristiwa ini terjadi ketika thread aktif di CPU atau sedang menunggu CPU. |
| [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md) | Peristiwa ini terjadi ketika sesi akan menulis data yang persisten ke penyimpanan Aurora. |
| [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md) | Peristiwa ini terjadi ketika thread menunggu untuk memberikan set hasil ke klien. |
| [io/redo\$1log\$1flush](ams-waits.io-redologflush.md) | Peristiwa ini terjadi ketika sesi akan menulis data yang persisten ke penyimpanan Aurora. |
| [io/socket/sql/client\$1koneksi](ams-waits.client-connection.md) | Peristiwa ini terjadi ketika thread sedang dalam proses untuk menangani koneksi baru. |
| [io/table/sql/handler](ams-waits.waitio.md) | Peristiwa ini terjadi ketika pekerjaan telah didelegasikan ke mesin penyimpanan. |
| [synch/cond/innodb/row\$1lock\$1tunggu](ams-waits.row-lock-wait.md) | Peristiwa ini terjadi ketika satu sesi telah mengunci baris untuk pembaruan, dan sesi lain mencoba memperbarui baris yang sama. |
| [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md) | Peristiwa ini terjadi ketika satu sesi telah mengunci baris untuk pembaruan, dan sesi lain mencoba memperbarui baris yang sama. |
| [synch/cond/sql/MDL\$1konteks: :cond\$1wait\$1status](ams-waits.cond-wait-status.md) | Peristiwa ini terjadi ketika ada thread yang menunggu kunci metadata tabel. |
| [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md) | Peristiwa ini terjadi ketika satu sesi telah mengunci baris untuk pembaruan, dan sesi lain mencoba memperbarui baris yang sama. |
| [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md) | Peristiwa ini terjadi ketika thread telah mendapat kunci pada pool buffer InnoDB untuk mengakses halaman dalam memori. |
| [synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md) | Peristiwa ini terjadi ketika sesi menunggu untuk mengakses cache memori ruang tabel. |
| [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md) | Peristiwa ini terjadi ketika ada aktivitas basis data tinggi dengan sejumlah besar transaksi. |
| [synch/sxlock/innodb/hash\$1table\$1locks](ams-waits.sx-lock-hash-table-locks.md) | Peristiwa ini terjadi ketika halaman yang tidak ditemukan di pool buffer harus dibaca dari file. |
| [synch/mutex/innodb/temp\$1pool\$1manager\$1mutex](ams-waits.io-temppoolmanager.md) | Peristiwa ini terjadi ketika sesi sedang menunggu untuk memperoleh mutex untuk mengelola kumpulan ruang tabel sementara sesi. |
# cpu
Peristiwa tunggu `cpu` terjadi saat thread aktif di CPU atau sedang menunggu CPU.
**Topics**
+ [Versi mesin yang didukung](#ams-waits.cpu.context.supported)
+ [Konteks](#ams-waits.cpu.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.cpu.causes)
+ [Tindakan](#ams-waits.cpu.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 2 dan 3
## Konteks
Untuk setiap vCPU, koneksi dapat berjalan bekerja pada CPU ini. Dalam beberapa situasi, jumlah koneksi aktif yang siap dijalankan lebih tinggi dari jumlah vCPUs. Ketidakseimbangan ini mengakibatkan koneksi menunggu sumber daya CPU. Jika jumlah koneksi aktif tetap lebih tinggi secara konsisten daripada jumlah vCPUs, maka instans Anda mengalami pertengkaran CPU. Pertentangan tersebut menyebabkan peristiwa tunggu `cpu` terjadi.
**catatan**
Metrik Wawasan Performa untuk CPU adalah `DBLoadCPU`. Nilai untuk `DBLoadCPU` dapat berbeda dari nilai untuk CloudWatch metrik`CPUUtilization`. Metrik terakhir dikumpulkan dari HyperVisor untuk instance database.
Metrik OS Wawasan Performa memberikan informasi terperinci tentang pemanfaatan CPU. Misalnya, Anda dapat menampilkan metrik berikut:
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
Wawasan Performa melaporkan penggunaan CPU oleh mesin basis data sebagai `os.cpuUtilization.nice.avg`.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa ini terjadi lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, berikut adalah penyebab umumnya:
+ Kueri analitik
+ Transaksi bersamaan yang tinggi
+ Transaksi yang berjalan lama
+ Peningkatan mendadak dalam jumlah koneksi, yang dikenal sebagai *login storm*
+ Peningkatan peralihan konteks
## Tindakan
Jika peristiwa tunggu `cpu` mendominasi aktivitas basis data, hal tersebut tidak selalu menunjukkan adanya masalah performa. Tanggapi peristiwa ini hanya saat performa menurun.
Tergantung pada penyebab peningkatan pemanfaatan CPU, pertimbangkan strategi berikut:
+ Tingkatkan kapasitas CPU host. Pendekatan ini biasanya hanya memberikan bantuan sementara.
+ Identifikasi kueri teratas untuk pengoptimalan potensial.
+ Arahkan ulang sebagian beban kerja hanya-baca ke simpul pembaca jika berlaku.
**Topics**
+ [Mengidentifikasi sesi atau kueri yang menyebabkan masalah](#ams-waits.cpu.actions.az-vpc-subnet)
+ [Menganalisis dan mengoptimalkan beban kerja CPU yang tinggi](#ams-waits.cpu.actions.db-instance-class)
### Mengidentifikasi sesi atau kueri yang menyebabkan masalah
Untuk menemukan sesi dan kueri tersebut, lihat tabel **SQL Teratas** dalam Wawasan Performa untuk pernyataan SQL yang memiliki beban CPU tertinggi. Untuk informasi selengkapnya, lihat [Menganalisis metrik dengan dasbor Wawasan Performa](USER_PerfInsights.UsingDashboard.md).
Biasanya, satu atau dua pernyataan SQL mengonsumsi sebagian besar siklus CPU. Konsentrasikan upaya Anda pada pernyataan ini. Misalkan instans DB Anda memiliki 2 v CPUs dengan beban DB 3,1 sesi aktif rata-rata (AAS), semuanya dalam status CPU. Dalam hal ini, instans Anda terikat dengan CPU. Pertimbangkan strategi berikut:
+ Tingkatkan ke kelas instance yang lebih besar dengan lebih banyak vCPUs.
+ Sesuaikan kueri Anda untuk memiliki beban CPU yang lebih rendah.
Dalam contoh ini, kueri SQL teratas memiliki beban DB 1,5 AAS, yang semuanya dalam status CPU. Pernyataan SQL lain memiliki beban 0,1 dalam status CPU. Dalam contoh ini, jika menghentikan pernyataan SQL dengan beban terendah, Anda tidak akan mengurangi beban basis data secara signifikan. Namun, jika mengoptimalkan dua kueri beban tinggi menjadi dua kali lebih efisien, Anda menghilangkan kemacetan CPU. Jika Anda mengurangi beban CPU 1,5 AAS sebesar 50%, AAS untuk setiap pernyataan akan berkurang menjadi 0,75. Total beban DB yang dihabiskan untuk CPU sekarang adalah 1,6 AAS. Nilai ini berada di bawah baris vCPU maksimum 2.0.
Untuk ikhtisar pemecahan masalah yang berguna menggunakan Wawasan Performa, lihat postingan blog [Menganalisis Beban Kerja Amazon Aurora MySQL dengan Wawasan Performa](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/). Lihat juga artikel AWS Support [Bagaimana cara memecahkan masalah dan mengatasi pemanfaatan CPU yang tinggi pada instans Amazon RDS for MySQL saya](https://aws.amazon.com/premiumsupport/knowledge-center/rds-instance-high-cpu/)? .
### Menganalisis dan mengoptimalkan beban kerja CPU yang tinggi
Setelah mengidentifikasi kueri atau sejumlah kueri yang meningkatkan penggunaan CPU, Anda dapat mengoptimalkannya atau mengakhiri koneksi. Contoh berikut menunjukkan cara mengakhiri koneksi.
```
CALL mysql.rds_kill(processID);
```
Untuk informasi selengkapnya, lihat [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill).
Jika Anda mengakhiri sesi, tindakan tersebut dapat memicu rollback yang panjang.
#### Mengikuti panduan untuk mengoptimalkan kueri
Untuk mengoptimalkan kueri, pertimbangkan panduan berikut:
+ Jalankan pernyataan `EXPLAIN`.
Perintah ini menunjukkan setiap langkah yang terlibat dalam menjalankan kueri. Untuk informasi selengkapnya, lihat [Optimizing Queries with EXPLAIN](https://dev.mysql.com/doc/refman/5.7/en/using-explain.html) dalam dokumentasi MySQL.
+ Jalankan pernyataan `SHOW PROFILE`.
Gunakan pernyataan ini untuk meninjau detail profil yang dapat menunjukkan penggunaan sumber daya untuk pernyataan yang dijalankan selama sesi saat ini. Untuk informasi selengkapnya, lihat [SHOW PROFILE Statement](https://dev.mysql.com/doc/refman/5.7/en/show-profile.html) dalam dokumentasi MySQL.
+ Jalankan pernyataan `ANALYZE TABLE`.
Gunakan pernyataan ini untuk menyegarkan statistik indeks untuk tabel yang diakses oleh kueri dengan konsumsi CPU tinggi. Dengan menganalisis pernyataan, Anda dapat membantu pengoptimal memilih rencana eksekusi yang sesuai. Untuk informasi selengkapnya, lihat [ANALYZE TABLE Statement](https://dev.mysql.com/doc/refman/5.7/en/analyze-table.html) dalam dokumentasi MySQL.
#### Mengikuti panduan untuk meningkatkan penggunaan CPU
Untuk meningkatkan penggunaan CPU dalam instans basis data, ikuti panduan berikut:
+ Pastikan semua kueri telah menggunakan indeks yang tepat.
+ Cari tahu apakah Anda dapat menggunakan kueri paralel Aurora. Anda dapat menggunakan teknik ini untuk mengurangi penggunaan CPU pada simpul kepala dengan menekan pemrosesan fungsi, pemfilteran baris, dan proyeksi kolom untuk klausa `WHERE`.
+ Cari tahu apakah jumlah eksekusi SQL per detik memenuhi ambang batas yang diharapkan.
+ Cari tahu apakah pemeliharaan indeks atau pembuatan indeks baru membutuhkan siklus CPU yang diperlukan oleh beban kerja produksi Anda. Jadwalkan aktivitas pemeliharaan di luar waktu aktivitas puncak.
+ Cari tahu apakah Anda dapat menggunakan partisi untuk membantu mengurangi set data kueri. Untuk informasi selengkapnya, lihat postingan blog [Cara merencanakan dan mengoptimalkan Amazon Aurora dengan kompatibilitas MySQL untuk beban kerja terkonsolidasi](https://aws.amazon.com/blogs/database/planning-and-optimizing-amazon-aurora-with-mysql-compatibility-for-consolidated-workloads/).
#### Memeriksa connection storm
Jika metrik `DBLoadCPU` tidak terlalu tinggi, tetapi metrik `CPUUtilization` tinggi, penyebab pemanfaatan CPU yang tinggi berasal dari luar mesin basis data. Contoh klasik adalah connection storm.
Periksa apakah kondisi berikut benar:
+ Ada peningkatan dalam metrik Performance Insights dan `CPUUtilization` metrik Amazon CloudWatch`DatabaseConnections`.
+ Jumlah thread dalam CPU lebih besar dari jumlah vCPUs.
Jika kondisi di atas benar, coba kurangi jumlah koneksi basis data. Misalnya, Anda dapat menggunakan kumpulan koneksi, seperti Proksi RDS. Untuk mempelajari praktik terbaik penskalaan dan manajemen koneksi yang efektif, lihat laporan resmi [Buku Panduan DBA Amazon Aurora MySQL untuk Manajemen Koneksi](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
# io/aurora\$1redo\$1log\$1flush
Peristiwa `io/aurora_redo_log_flush` terjadi ketika sesi menulis data persisten ke penyimpanan Amazon Aurora.
**Topics**
+ [Versi mesin yang didukung](#ams-waits.io-auredologflush.context.supported)
+ [Konteks](#ams-waits.io-auredologflush.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.io-auredologflush.causes)
+ [Tindakan](#ams-waits.io-auredologflush.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 2
## Konteks
`io/aurora_redo_log_flush`Acara ini untuk operasi tulis input/output (I/O) di Aurora MySQL.
**catatan**
Di Aurora MySQL versi 3, peristiwa tunggu ini disebut [io/redo\$1log\$1flush](ams-waits.io-redologflush.md).
## Kemungkinan penyebab peningkatan peristiwa tunggu
Untuk persistensi data, commit memerlukan penulisan durabel ke penyimpanan yang stabil. Jika database melakukan terlalu banyak komit, ada acara tunggu pada I/O operasi tulis, acara `io/aurora_redo_log_flush` tunggu.
Dalam contoh berikut, sebanyak 50.000 catatan dimasukkan ke dalam klaster DB Aurora MySQL menggunakan kelas instans DB db.r5.xlarge:
+ Pada contoh pertama, setiap sesi menyisipkan 10.000 catatan baris demi baris. Secara default, jika perintah bahasa manipulasi data (DML) tidak berada dalam transaksi, Aurora MySQL akan menggunakan commit implisit. Autocommit diaktifkan. Ini berarti terdapat commit untuk setiap penyisipan baris. Wawasan Performa menunjukkan bahwa koneksi menghabiskan sebagian besar waktunya menunggu peristiwa tunggu `io/aurora_redo_log_flush`.
![\[Contoh Wawasan Performa peristiwa tunggu\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example1.png)
Hal ini disebabkan oleh pernyataan sisipan sederhana yang digunakan.
![\[Menyisipkan pernyataan di SQL Teratas\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_top_SQL1.png)
Diperlukan waktu 3,5 menit untuk menyisipkan 50.000 catatan.
+ Dalam contoh kedua, sisipan dibuat dalam 1.000 batch, yakni setiap koneksi melakukan 10 commit, bukan 10.000. Wawasan Performa menunjukkan bahwa koneksi tidak menghabiskan sebagian besar waktunya untuk peristiwa tunggu `io/aurora_redo_log_flush`.
![\[Contoh Wawasan Performa peristiwa tunggu yang memiliki dampak lebih sedikit\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example2.png)
Diperlukan waktu 4 detik untuk menyisipkan 50.000 catatan.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Mengidentifikasi sesi dan kueri yang bermasalah](#ams-waits.io-auredologflush.actions.identify-queries)
+ [Mengelompokkan operasi tulis](#ams-waits.io-auredologflush.actions.action0)
+ [Menonaktifkan autocommit](#ams-waits.io-auredologflush.actions.action1)
+ [Menggunakan transaksi](#ams-waits.io-auredologflush.action2)
+ [Menggunakan batch](#ams-waits.io-auredologflush.action3)
### Mengidentifikasi sesi dan kueri yang bermasalah
Jika instans DB Anda mengalami kemacetan, langkah pertama adalah menemukan sesi dan kueri yang menjadi penyebabnya. Untuk posting Blog AWS Database yang berguna, lihat [Menganalisis Beban Kerja MySQL Amazon Aurora](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) dengan Performance Insights.
**Untuk mengidentifikasi sesi dan kueri yang menyebabkan kemacetan:**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih instans DB Anda.
1. Di **Beban basis data**, pilih **Potong berdasarkan masa tunggu**.
1. Di bagian bawah halaman, pilih **SQL Teratas**.
Kueri di bagian atas daftar adalah penyebab beban tertinggi pada basis data.
### Mengelompokkan operasi tulis
Contoh berikut memicu peristiwa tunggu `io/aurora_redo_log_flush`. (Autocommit diaktifkan.)
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
Dalam upaya mengurangi waktu yang dihabiskan untuk menunggu peristiwa tunggu `io/aurora_redo_log_flush`, kelompokkan operasi tulis secara logis ke dalam satu commit guna mengurangi panggilan persisten ke penyimpanan.
### Menonaktifkan autocommit
Nonaktifkan autocommit sebelum membuat perubahan besar yang tidak ada dalam transaksi, seperti yang ditunjukkan pada contoh berikut.
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### Menggunakan transaksi
Anda dapat menggunakan transaksi, seperti yang ditunjukkan pada contoh berikut.
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### Menggunakan batch
Anda dapat membuat perubahan dalam batch, seperti yang ditunjukkan pada contoh berikut. Namun, menggunakan batch yang terlalu besar dapat menyebabkan masalah kinerja, terutama pada replika baca atau saat melakukan point-in-time pemulihan (PITR).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
Peristiwa `io/aurora_respond_to_client` terjadi ketika thread menunggu untuk mengembalikan set hasil ke klien.
**Topics**
+ [Versi mesin yang didukung](#ams-waits.respond-to-client.context.supported)
+ [Konteks](#ams-waits.respond-to-client.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.respond-to-client.causes)
+ [Tindakan](#ams-waits.respond-to-client.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 2
## Konteks
Peristiwa `io/aurora_respond_to_client` menunjukkan bahwa thread menunggu untuk mengembalikan set hasil ke klien.
Pemrosesan kueri selesai, dan hasilnya dikembalikan ke klien aplikasi. Namun, karena bandwidth jaringan pada klaster DB tidak cukup, thread menunggu untuk mengembalikan set hasil.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa `io/aurora_respond_to_client` muncul lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, berikut adalah penyebab umumnya:
**Kelas instans DB tidak cukup untuk beban kerja**
Kelas instans DB yang digunakan oleh klaster DB tidak memiliki bandwidth jaringan yang diperlukan untuk memproses beban kerja secara efisien.
**Set hasil besar**
Terjadi peningkatan ukuran set hasil yang dikembalikan karena kueri mengembalikan jumlah baris yang lebih tinggi. Set hasil yang lebih besar menghabiskan lebih banyak bandwidth jaringan.
**Peningkatan beban pada klien**
Mungkin terdapat tekanan CPU, tekanan memori, atau saturasi jaringan pada klien. Peningkatan beban pada klien menunda penerimaan data dari klaster DB Aurora MySQL.
**Peningkatan latensi jaringan**
Mungkin terdapat peningkatan latensi jaringan antara klaster DB Aurora MySQL dan klien. Latensi jaringan yang lebih tinggi akan menambah waktu yang diperlukan klien untuk menerima data.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Mengidentifikasi sesi dan kueri penyebab peristiwa](#ams-waits.respond-to-client.actions.identify)
+ [Menskalakan kelas instans DB](#ams-waits.respond-to-client.actions.scale-db-instance-class)
+ [Memeriksa beban kerja untuk hasil yang tidak terduga](#ams-waits.respond-to-client.actions.workload)
+ [Mendistribusikan beban kerja dengan instans pembaca](#ams-waits.respond-to-client.actions.balance)
+ [Menggunakan pengubah SQL\$1BUFFER\$1RESULT](#ams-waits.respond-to-client.actions.sql-buffer-result)
### Mengidentifikasi sesi dan kueri penyebab peristiwa
Anda dapat menggunakan Wawasan Performa untuk menampilkan kueri yang diblokir oleh peristiwa tunggu `io/aurora_respond_to_client`. Biasanya, basis data dengan beban sedang hingga signifikan memiliki peristiwa tunggu. Peristiwa tunggu ini mungkin dapat diterima jika basis data berperforma optimal. Jika tidak, periksa di mana basis data tersebut menghabiskan waktu terbanyak. Lihat peristiwa tunggu yang berkontribusi ke beban tertinggi, lalu cari tahu apakah Anda dapat mengoptimalkan basis data dan aplikasi untuk mengurangi peristiwa tersebut.
**Untuk menemukan kueri SQL yang bertanggung jawab atas beban tinggi:**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih instans DB. Dasbor Wawasan Performa ditampilkan untuk instans DB tersebut.
1. Dalam bagan **Beban basis data**, pilih **Potong berdasarkan masa tunggu**.
1. Di bagian bawah halaman, pilih **SQL Teratas**.
Bagan ini mencantumkan kueri SQL yang bertanggung jawab atas beban. Kueri di bagian atas daftar memiliki tanggung jawab terbesar. Untuk mengatasi kemacetan, fokus pada pernyataan tersebut.
Untuk ikhtisar berguna tentang pemecahan masalah menggunakan Performance Insights, lihat Posting Blog Database Menganalisis Beban AWS Kerja [MySQL Amazon Aurora](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) dengan Performance Insights.
### Menskalakan kelas instans DB
Periksa peningkatan nilai CloudWatch metrik Amazon yang terkait dengan throughput jaringan, seperti `NetworkReceiveThroughput` dan. `NetworkTransmitThroughput` Jika bandwidth jaringan kelas instans DB tercapai, Anda dapat menskalakan kelas instans DB yang digunakan oleh klaster DB dengan memodifikasi klaster DB tersebut. Kelas instans DB dengan bandwidth jaringan yang lebih besar mengembalikan data ke klien secara lebih efisien.
Untuk informasi tentang memantau CloudWatch metrik Amazon, lihat[Melihat metrik di konsol Amazon RDS](USER_Monitoring.md). Untuk informasi tentang kelas instans DB, lihat [Kelas instans Amazon Aurora DB](Concepts.DBInstanceClass.md). Untuk informasi tentang mengubah klaster DB, lihat [Memodifikasi klaster DB Amazon Aurora](Aurora.Modifying.md).
### Memeriksa beban kerja untuk hasil yang tidak terduga
Periksa beban kerja pada klaster DB dan pastikan beban kerja tidak memberikan hasil yang tidak terduga. Misalnya, mungkin terdapat kueri yang mengembalikan jumlah baris lebih tinggi dari yang diperkirakan. Dalam hal ini, Anda dapat menggunakan metrik penghitung Wawasan Performa seperti `Innodb_rows_read`. Untuk informasi selengkapnya, lihat [Metrik penghitung Wawasan Performa](USER_PerfInsights_Counters.md).
### Mendistribusikan beban kerja dengan instans pembaca
Anda dapat mendistribusikan beban kerja hanya-baca dengan Aurora Replicas. Anda dapat menskalakan secara horizontal dengan menambahkan lebih banyak Aurora Replicas. Dengan demikian, Anda dapat memperoleh peningkatan batas throttling untuk bandwidth jaringan. Untuk informasi selengkapnya, lihat [Klaster DB Amazon Aurora](Aurora.Overview.md).
### Menggunakan pengubah SQL\$1BUFFER\$1RESULT
Anda dapat menambahkan pengubah `SQL_BUFFER_RESULT` ke pernyataan `SELECT` untuk memaksakan hasilnya ke tabel sementara sebelum dikembalikan ke klien. Pengubah ini dapat membantu mengatasi masalah performa saat kunci InnoDB tidak dibebaskan karena kueri berada dalam status tunggu `io/aurora_respond_to_client`. Untuk informasi selengkapnya, lihat [SELECT Statement](https://dev.mysql.com/doc/refman/5.7/en/select.html) dalam dokumentasi MySQL.
# io/redo\$1log\$1flush
Peristiwa `io/redo_log_flush` terjadi ketika sesi menulis data persisten ke penyimpanan Amazon Aurora.
**Topics**
+ [Versi mesin yang didukung](#ams-waits.io-redologflush.context.supported)
+ [Konteks](#ams-waits.io-redologflush.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.io-redologflush.causes)
+ [Tindakan](#ams-waits.io-redologflush.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 3
## Konteks
`io/redo_log_flush`Acara ini untuk operasi tulis input/output (I/O) di Aurora MySQL.
**catatan**
Di Aurora MySQL versi 2, peristiwa tunggu ini disebut [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
## Kemungkinan penyebab peningkatan peristiwa tunggu
Untuk persistensi data, commit memerlukan penulisan durabel ke penyimpanan yang stabil. Jika database melakukan terlalu banyak komit, ada acara tunggu pada I/O operasi tulis, acara `io/redo_log_flush` tunggu.
Untuk contoh perilaku peristiwa tunggu ini, lihat [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Mengidentifikasi sesi dan kueri yang bermasalah](#ams-waits.io-redologflush.actions.identify-queries)
+ [Mengelompokkan operasi tulis](#ams-waits.io-redologflush.actions.action0)
+ [Menonaktifkan autocommit](#ams-waits.io-redologflush.actions.action1)
+ [Menggunakan transaksi](#ams-waits.io-redologflush.action2)
+ [Menggunakan batch](#ams-waits.io-redologflush.action3)
### Mengidentifikasi sesi dan kueri yang bermasalah
Jika instans DB Anda mengalami kemacetan, langkah pertama adalah menemukan sesi dan kueri yang menjadi penyebabnya. Untuk posting Blog AWS Database yang berguna, lihat [Menganalisis Beban Kerja MySQL Amazon Aurora](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) dengan Performance Insights.
**Untuk mengidentifikasi sesi dan kueri yang menyebabkan kemacetan:**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih instans DB Anda.
1. Di **Beban basis data**, pilih **Potong berdasarkan masa tunggu**.
1. Di bagian bawah halaman, pilih **SQL Teratas**.
Kueri di bagian atas daftar adalah penyebab beban tertinggi pada basis data.
### Mengelompokkan operasi tulis
Contoh berikut memicu peristiwa tunggu `io/redo_log_flush`. (Autocommit diaktifkan.)
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
Dalam upaya mengurangi waktu yang dihabiskan untuk menunggu peristiwa tunggu `io/redo_log_flush`, kelompokkan operasi tulis secara logis ke dalam satu commit guna mengurangi panggilan persisten ke penyimpanan.
### Menonaktifkan autocommit
Nonaktifkan autocommit sebelum membuat perubahan besar yang tidak ada dalam transaksi, seperti yang ditunjukkan pada contoh berikut.
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### Menggunakan transaksi
Anda dapat menggunakan transaksi, seperti yang ditunjukkan pada contoh berikut.
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### Menggunakan batch
Anda dapat membuat perubahan dalam batch, seperti yang ditunjukkan pada contoh berikut. Namun, menggunakan batch yang terlalu besar dapat menyebabkan masalah kinerja, terutama pada replika baca atau saat melakukan point-in-time pemulihan (PITR).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
Peristiwa `io/socket/sql/client_connection` terjadi saat thread sedang dalam proses penanganan koneksi baru.
**Topics**
+ [Versi mesin yang didukung](#ams-waits.client-connection.context.supported)
+ [Konteks](#ams-waits.client-connection.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.client-connection.causes)
+ [Tindakan](#ams-waits.client-connection.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 2 dan 3
## Konteks
Peristiwa `io/socket/sql/client_connection` menunjukkan bahwa mysqld sibuk membuat thread untuk menangani koneksi klien baru yang masuk. Dalam skenario ini, pemrosesan layanan permintaan koneksi klien baru melambat, sementara koneksi menunggu agar thread ditetapkan. Untuk informasi selengkapnya, lihat [Server MySQL (mysqld)](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld).
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa ini muncul lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, berikut adalah penyebab umumnya:
+ Terdapat peningkatan mendadak dalam koneksi pengguna baru dari aplikasi ke instans Amazon RDS Anda.
+ Instans DB Anda tidak dapat memproses koneksi baru karena jaringan, CPU, atau memori sedang dibatasi.
## Tindakan
Jika `io/socket/sql/client_connection` mendominasi aktivitas basis data, hal tersebut tidak selalu menunjukkan adanya masalah performa. Dalam basis data yang tidak idle, peristiwa tunggu selalu berada di atas. Lakukan tindakan hanya bila performa menurun. Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Mengidentifikasi sesi dan kueri yang bermasalah](#ams-waits.client-connection.actions.identify-queries)
+ [Mengikuti praktik terbaik untuk manajemen koneksi](#ams-waits.client-connection.actions.manage-connections)
+ [Menskalakan instans jika sumber daya sedang dibatasi](#ams-waits.client-connection.upgrade)
+ [Memeriksa host teratas dan pengguna teratas](#ams-waits.client-connection.top-hosts)
+ [Membuat kueri tabel performance\$1schema](#ams-waits.client-connection.perf-schema)
+ [Memeriksa status thread kueri](#ams-waits.client-connection.thread-states)
+ [Mengaudit permintaan dan kueri](#ams-waits.client-connection.auditing)
+ [Menggabungkan koneksi basis data](#ams-waits.client-connection.pooling)
### Mengidentifikasi sesi dan kueri yang bermasalah
Jika instans DB Anda mengalami kemacetan, langkah pertama adalah menemukan sesi dan kueri yang menjadi penyebabnya. Untuk postingan blog yang berguna, lihat [Menganalisis Beban Kerja Amazon Aurora MySQL dengan Wawasan Performa](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
**Untuk mengidentifikasi sesi dan kueri yang menyebabkan kemacetan:**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih instans DB Anda.
1. Di **Beban basis data**, pilih **Potong berdasarkan masa tunggu**.
1. Di bagian bawah halaman, pilih **SQL Teratas**.
Kueri di bagian atas daftar adalah penyebab beban tertinggi pada basis data.
### Mengikuti praktik terbaik untuk manajemen koneksi
Untuk mengelola koneksi Anda, pertimbangkan strategi berikut:
+ Gunakan penggabungan koneksi.
Anda dapat secara bertahap meningkatkan jumlah koneksi sesuai yang diperlukan. Untuk informasi selengkapnya, lihat laporan resmi [Buku Panduan Administrator Basis Data Amazon Aurora MySQL](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
+ Gunakan simpul pembaca untuk mendistribusikan kembali lalu lintas hanya-baca.
Untuk informasi selengkapnya, lihat [Replika Aurora](Aurora.Replication.md#Aurora.Replication.Replicas) dan [Koneksi titik akhir Amazon Aurora](Aurora.Overview.Endpoints.md).
### Menskalakan instans jika sumber daya sedang dibatasi
Cari contoh throttling dalam sumber daya berikut:
+ CPU
Periksa CloudWatch metrik Amazon Anda untuk penggunaan CPU yang tinggi.
+ Jaringan
Periksa peningkatan nilai CloudWatch metrik `network receive throughput` dan`network transmit throughput`. Jika instans Anda telah mencapai batas bandwidth jaringan untuk kelas instans, pertimbangkan untuk menskalakan instans RDS ke jenis kelas instans yang lebih tinggi. Untuk informasi selengkapnya, lihat [Kelas instans Amazon Aurora DB](Concepts.DBInstanceClass.md).
+ Memori yang dapat dibebaskan
Periksa penurunan CloudWatch metrik`FreeableMemory`. Pertimbangkan juga untuk mengaktifkan Peningkatan Pemantauan. Untuk informasi selengkapnya, lihat [Memantau metrik OS dengan Pemantauan yang Ditingkatkan](USER_Monitoring.OS.md).
### Memeriksa host teratas dan pengguna teratas
Gunakan Wawasan Performa untuk memeriksa host teratas dan pengguna teratas. Untuk informasi selengkapnya, lihat [Menganalisis metrik dengan dasbor Wawasan Performa](USER_PerfInsights.UsingDashboard.md).
### Membuat kueri tabel performance\$1schema
Untuk mendapatkan jumlah koneksi total dan saat ini yang akurat, buat kueri tabel `performance_schema`. Dengan teknik ini, Anda mengidentifikasi pengguna sumber atau host yang bertanggung jawab untuk membuat koneksi dalam jumlah besar. Misalnya, buat kueri tabel `performance_schema` sebagai berikut:
```
SELECT * FROM performance_schema.accounts;
SELECT * FROM performance_schema.users;
SELECT * FROM performance_schema.hosts;
```
### Memeriksa status thread kueri
Jika masalah performa terus berlanjut, periksa status thread kueri. Di klien `mysql`, keluarkan perintah berikut.
```
show processlist;
```
### Mengaudit permintaan dan kueri
Untuk memeriksa sifat permintaan dan kueri dari akun pengguna, gunakan AuroraAurora MySQL Advanced Auditing. Untuk mempelajari cara mengaktifkan audit, lihat [Menggunakan Audit Lanjutan dengan klaster Amazon Aurora My DB SQL](AuroraMySQL.Auditing.md).
### Menggabungkan koneksi basis data
Pertimbangkan untuk menggunakan Proksi Amazon RDS untuk manajemen koneksi. Dengan menggunakan Proksi RDS, Anda dapat mengizinkan aplikasi untuk menggabungkan dan berbagi koneksi basis data guna meningkatkan kemampuan penskalaannya. Proksi RDS membuat aplikasi lebih tangguh terhadap kegagalan basis data dengan secara otomatis terhubung ke sebuah instans DB siaga sekaligus menjaga koneksi aplikasi. Lihat informasi yang lebih lengkap di [Proksi Amazon RDS untuk Aurora](rds-proxy.md).
# io/table/sql/handler
Peristiwa `io/table/sql/handler` terjadi ketika pekerjaan telah didelegasikan ke mesin penyimpanan.
**Topics**
+ [Versi mesin yang didukung](#ams-waits.waitio.context.supported)
+ [Konteks](#ams-waits.waitio.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.waitio.causes)
+ [Tindakan](#ams-waits.waitio.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 2 dan 3
## Konteks
Peristiwa `io/table` menunjukkan peristiwa tunggu untuk akses ke tabel. Peristiwa ini terjadi terlepas dari apakah data di-cache di pool buffer atau diakses pada disk. Peristiwa `io/table/sql/handler` menunjukkan peningkatan aktivitas beban kerja.
*Handler* adalah rutinitas yang berspesialisasi dalam jenis data tertentu atau berfokus pada tugas khusus tertentu. Misalnya, handler peristiwa menerima dan mencerna peristiwa serta sinyal dari sistem operasi atau antarmuka pengguna. Handler memori melakukan tugas-tugas yang berkaitan dengan memori. Handler input file adalah fungsi yang menerima input file dan melakukan tugas khusus pada data, sesuai dengan konteksnya.
Tampilan seperti `performance_schema.events_waits_current` sering kali menunjukkan `io/table/sql/handler` ketika peristiwa tunggu sebenarnya adalah peristiwa tunggu bersarang seperti penguncian. Jika peristiwa tunggu sebenarnya bukan `io/table/sql/handler`, Wawasan Performa akan melaporkan peristiwa tunggu bersarang. Saat Performance Insights melaporkan`io/table/sql/handler`, ini mewakili pemrosesan I/O permintaan InnoDB dan bukan peristiwa tunggu bersarang yang tersembunyi. Untuk informasi selengkapnya, lihat [Peristiwa Atom dan Molekul Skema Performa](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) dalam *Panduan Referensi MySQL*.
`io/table/sql/handler`Acara ini sering muncul di acara tunggu teratas dengan I/O menunggu seperti`io/aurora_redo_log_flush`.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Dalam Wawasan Performa, lonjakan mendadak dalam peristiwa `io/table/sql/handler` menunjukkan adanya peningkatan aktivitas beban kerja. Peningkatan aktivitas berarti peningkatan I/O.
Performance Insights memfilter peristiwa bersarang IDs dan tidak melaporkan `io/table/sql/handler` penantian saat peristiwa bersarang yang mendasarinya adalah menunggu kunci. Misalnya, jika peristiwa akar penyebabnya adalah [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md), Wawasan Performa akan menampilkan peristiwa tunggu ini dalam peristiwa tunggu teratas, bukan `io/table/sql/handler`.
Dalam tampilan seperti `performance_schema.events_waits_current`, peristiwa tunggu untuk `io/table/sql/handler` sering kali muncul ketika peristiwa tunggu sebenarnya adalah peristiwa tunggu bersarang seperti penguncian. Jika peristiwa tunggu sebenarnya berbeda dengan `io/table/sql/handler`, Wawasan Performa akan mencari peristiwa tunggu bersarang dan melaporkan peristiwa tunggu sebenarnya, bukan `io/table/sql/handler`. Saat Wawasan Performa melaporkan `io/table/sql/handler`, peristiwa tunggu sebenarnya adalah `io/table/sql/handler`, bukan peristiwa tunggu bersarang yang tersembunyi. Untuk informasi selengkapnya, lihat [Peristiwa Atom dan Molekul Skema Performa](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) dalam *Panduan Referensi MySQL 5.7*.
## Tindakan
Jika peristiwa tunggu ini mendominasi aktivitas basis data, hal tersebut tidak selalu menunjukkan adanya masalah performa. Peristiwa tunggu selalu berada di atas saat basis data aktif. Anda perlu melakukan tindakan hanya bila performa menurun.
Kami merekomendasikan berbagai tindakan, tergantung pada peristiwa tunggu lain yang Anda lihat.
**Topics**
+ [Mengidentifikasi sesi dan kueri penyebab peristiwa](#ams-waits.waitio.actions.identify)
+ [Memeriksa korelasi dengan metrik penghitung Wawasan Performa](#ams-waits.waitio.actions.filters)
+ [Memeriksa peristiwa tunggu berkorelasi lainnya](#ams-waits.waitio.actions.maintenance)
### Mengidentifikasi sesi dan kueri penyebab peristiwa
Biasanya, basis data dengan beban sedang hingga signifikan memiliki peristiwa tunggu. Peristiwa tunggu ini mungkin dapat diterima jika basis data berperforma optimal. Jika tidak, periksa di mana basis data tersebut menghabiskan waktu terbanyak. Lihat peristiwa tunggu yang berkontribusi ke beban tertinggi, lalu cari tahu apakah Anda dapat mengoptimalkan basis data dan aplikasi untuk mengurangi peristiwa tersebut.
**Untuk menemukan kueri SQL yang bertanggung jawab atas beban tinggi:**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih instans DB. Dasbor Wawasan Performa ditampilkan untuk instans DB tersebut.
1. Dalam bagan **Beban basis data**, pilih **Potong berdasarkan masa tunggu**.
1. Di bagian bawah halaman, pilih **SQL Teratas**.
Bagan ini mencantumkan kueri SQL yang bertanggung jawab atas beban. Kueri di bagian atas daftar memiliki tanggung jawab terbesar. Untuk mengatasi kemacetan, fokus pada pernyataan tersebut.
Untuk ikhtisar pemecahan masalah yang berguna menggunakan Wawasan Performa, lihat postingan blog [Menganalisis Beban Kerja Amazon Aurora MySQL dengan Wawasan Performa](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Memeriksa korelasi dengan metrik penghitung Wawasan Performa
Periksa metrik penghitung Wawasan Performa seperti `Innodb_rows_changed`. Jika metrik penghitung berkorelasi dengan `io/table/sql/handler`, ikuti langkah-langkah berikut:
1. Dalam Wawasan Performa, cari pernyataan SQL yang memperhitungkan peristiwa tunggu teratas `io/table/sql/handler`. Jika memungkinkan, optimalkan pernyataan ini sehingga mengembalikan lebih sedikit baris.
1. Ambil tabel teratas dari tampilan `schema_table_statistics` dan `x$schema_table_statistics`. Tampilan ini menunjukkan jumlah waktu yang dihabiskan per tabel. Untuk informasi selengkapnya, lihat [Tampilan schema\$1table\$1statistics dan x\$1schema\$1table\$1statistics](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html) dalam *Panduan Referensi MySQL*.
Secara default, baris diurutkan berdasarkan total waktu tunggu menurun. Tabel dengan pertentangan terbanyak ditampilkan terlebih dahulu. Output menunjukkan apakah waktu dihabiskan untuk membaca, menulis, mengambil, menyisipkan, memperbarui, atau menghapus.
```
mysql> select * from sys.schema_table_statistics limit 1\G
*************************** 1. row ***************************
table_schema: read_only_db
table_name: sbtest41
total_latency: 54.11 m
rows_fetched: 6001557
fetch_latency: 39.14 m
rows_inserted: 14833
insert_latency: 5.78 m
rows_updated: 30470
update_latency: 5.39 m
rows_deleted: 14833
delete_latency: 3.81 m
io_read_requests: NULL
io_read: NULL
io_read_latency: NULL
io_write_requests: NULL
io_write: NULL
io_write_latency: NULL
io_misc_requests: NULL
io_misc_latency: NULL
1 row in set (0.11 sec)
```
### Memeriksa peristiwa tunggu berkorelasi lainnya
Jika `synch/sxlock/innodb/btr_search_latch` dan `io/table/sql/handler` bersama-sama berkontribusi paling besar terhadap anomali beban DB, periksa apakah variabel `innodb_adaptive_hash_index` diaktifkan. Jika ya, coba tingkatkan nilai parameter `innodb_adaptive_hash_index_parts`.
Jika Adaptive Hash Index dinonaktifkan, coba untuk mengaktifkannya. Untuk mempelajari selengkapnya tentang Adaptive Hash Index MySQL, lihat sumber daya berikut:
+ Artikel [Is Adaptive Hash Index in InnoDB right for my workload?](https://www.percona.com/blog/2016/04/12/is-adaptive-hash-index-in-innodb-right-for-my-workload) di situs web Percona
+ [Adaptive Hash Index](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html) dalam *Panduan Referensi MySQL*
+ Artikel [Contention in MySQL InnoDB: Useful Info From the Semaphores Section](https://www.percona.com/blog/2019/12/20/contention-in-mysql-innodb-useful-info-from-the-semaphores-section/) di situs web Percona
**catatan**
Adaptive Hash Index tidak didukung pada instans DB pembaca Aurora.
Dalam kasus tertentu, performa mungkin buruk pada instans pembaca saat `synch/sxlock/innodb/btr_search_latch` dan `io/table/sql/handler` bersifat dominan. Jika demikian, coba alihkan beban kerja sementara ke instans DB penulis dan aktifkan Adaptive Hash Index.
# synch/cond/innodb/row\$1lock\$1tunggu
Peristiwa `synch/cond/innodb/row_lock_wait` terjadi ketika satu sesi telah mengunci baris untuk pembaruan dan sesi lain mencoba memperbarui baris yang sama. Untuk informasi selengkapnya, lihat [penguncian InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html) di dokumentasi MySQL.
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 3
## Kemungkinan penyebab peningkatan peristiwa tunggu
Beberapa pernyataan bahasa manipulasi data (DML) mengakses baris atau sejumlah baris yang sama secara serentak.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada peristiwa tunggu lain yang Anda lihat.
**Topics**
+ [Menemukan dan merespons pernyataan SQL yang bertanggung jawab atas peristiwa tunggu ini](#ams-waits.row-lock-wait.actions.id)
+ [Menemukan dan merespons sesi pemblokiran](#ams-waits.row-lock-wait.actions.blocker)
### Menemukan dan merespons pernyataan SQL yang bertanggung jawab atas peristiwa tunggu ini
Gunakan Wawasan Performa untuk mengidentifikasi pernyataan SQL yang bertanggung jawab atas peristiwa tunggu ini. Pertimbangkan strategi berikut:
+ Jika kunci baris merupakan masalah yang terus-menerus, coba tulis ulang aplikasi untuk menggunakan penguncian optimis.
+ Gunakan pernyataan multibaris.
+ Bagikan beban kerja ke objek basis data yang berbeda-beda. Anda dapat melakukannya melalui partisi.
+ Periksa nilai parameter `innodb_lock_wait_timeout`. Parameter ini mengontrol durasi transaksi menunggu sebelum menghasilkan kesalahan batas waktu.
Untuk ikhtisar pemecahan masalah yang berguna menggunakan Wawasan Performa, lihat postingan blog [Menganalisis Beban Kerja Amazon Aurora MySQL dengan Wawasan Performa](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Menemukan dan merespons sesi pemblokiran
Cari tahu apakah sesi pemblokiran idle atau aktif. Cari tahu juga apakah sesi tersebut berasal dari aplikasi atau pengguna aktif.
Untuk mengidentifikasi sesi yang memegang kunci, Anda dapat menjalankan `SHOW ENGINE INNODB STATUS`. Contoh berikut menunjukkan output sampel.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 1688153, ACTIVE 82 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 4244, OS thread handle 70369524330224, query id 4020834 172.31.14.179 reinvent executing
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 24 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 4 n bits 72 index GEN_CLUST_INDEX of table test.t1 trx id 1688153 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
Sebagai alternatif, Anda dapat menggunakan kueri berikut untuk mengekstrak detail tentang kunci saat ini.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_engine_transaction_id waiting_transaction,
ilw.blocking_engine_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_engine_transaction_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state end blocker_state,
concat(il.object_schema,'.', il.object_name) as locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM performance_schema.data_lock_waits ilw
JOIN performance_schema.data_locks il
ON ilw.blocking_engine_lock_id = il.engine_lock_id
AND ilw.blocking_engine_transaction_id = il.engine_transaction_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_engine_transaction_id = it.trx_id join information_schema.processlist p
ON it.trx_mysql_thread_id = p.id join information_schema.innodb_trx it1
ON ilw.requesting_engine_transaction_id = it1.trx_id join information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 4244
waiting_user: reinvent
waiting_host: 123.456.789.012:18158
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 1688153
blocking_lock: 70369562074216:11:4:2:70369549808672
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 1688142
blocker_state: User sleep
locked_table: test.t1
blocker_thread: 4243
blocker_user: reinvent
blocker_host: 123.456.789.012:18156
1 row in set (0.00 sec)
```
Saat mengidentifikasi sesi, opsi Anda mencakup yang berikut:
+ Menghubungi pemilik aplikasi atau pengguna.
+ Jika sesi pemblokiran idle, coba akhiri sesi pemblokiran. Tindakan ini dapat memicu rollback yang panjang. Untuk mempelajari cara mengakhiri sesi, lihat [Mengakhiri sesi atau kueri](mysql-stored-proc-ending.md).
Untuk informasi selengkapnya tentang mengidentifikasi transaksi pemblokiran, lihat [Menggunakan transaksi InnoDB dan mengunci informasi dalam dokumentasi](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html) MySQL.
# synch/cond/innodb/row\$1lock\$1wait\$1cond
Peristiwa `synch/cond/innodb/row_lock_wait_cond` terjadi ketika satu sesi telah mengunci baris untuk pembaruan dan sesi lain mencoba memperbarui baris yang sama. Untuk informasi selengkapnya, lihat [penguncian InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) di dokumentasi MySQL.
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 2
## Kemungkinan penyebab peningkatan peristiwa tunggu
Beberapa pernyataan bahasa manipulasi data (DML) mengakses baris atau sejumlah baris yang sama secara serentak.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada peristiwa tunggu lain yang Anda lihat.
**Topics**
+ [Menemukan dan merespons pernyataan SQL yang bertanggung jawab atas peristiwa tunggu ini](#ams-waits.row-lock-wait-cond.actions.id)
+ [Menemukan dan merespons sesi pemblokiran](#ams-waits.row-lock-wait-cond.actions.blocker)
### Menemukan dan merespons pernyataan SQL yang bertanggung jawab atas peristiwa tunggu ini
Gunakan Wawasan Performa untuk mengidentifikasi pernyataan SQL yang bertanggung jawab atas peristiwa tunggu ini. Pertimbangkan strategi berikut:
+ Jika kunci baris merupakan masalah yang terus-menerus, coba tulis ulang aplikasi untuk menggunakan penguncian optimis.
+ Gunakan pernyataan multibaris.
+ Bagikan beban kerja ke objek basis data yang berbeda-beda. Anda dapat melakukannya melalui partisi.
+ Periksa nilai parameter `innodb_lock_wait_timeout`. Parameter ini mengontrol durasi transaksi menunggu sebelum menghasilkan kesalahan batas waktu.
Untuk ikhtisar pemecahan masalah yang berguna menggunakan Wawasan Performa, lihat postingan blog [Menganalisis Beban Kerja Amazon Aurora MySQL dengan Wawasan Performa](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Menemukan dan merespons sesi pemblokiran
Cari tahu apakah sesi pemblokiran idle atau aktif. Cari tahu juga apakah sesi tersebut berasal dari aplikasi atau pengguna aktif.
Untuk mengidentifikasi sesi yang memegang kunci, Anda dapat menjalankan `SHOW ENGINE INNODB STATUS`. Contoh berikut menunjukkan output sampel.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 2771110, ACTIVE 112 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 24, OS thread handle 70369573642160, query id 13271336 172.31.14.179 reinvent Sending data
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 43 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 3 n bits 0 index GEN_CLUST_INDEX of table test.t1 trx id 2771110 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
Sebagai alternatif, Anda dapat menggunakan kueri berikut untuk mengekstrak detail tentang kunci saat ini.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Saat mengidentifikasi sesi, opsi Anda mencakup yang berikut:
+ Menghubungi pemilik aplikasi atau pengguna.
+ Jika sesi pemblokiran idle, coba akhiri sesi pemblokiran. Tindakan ini dapat memicu rollback yang panjang. Untuk mempelajari cara mengakhiri sesi, lihat [Mengakhiri sesi atau kueri](mysql-stored-proc-ending.md).
Untuk informasi selengkapnya tentang mengidentifikasi transaksi pemblokiran, lihat [Menggunakan transaksi InnoDB dan mengunci informasi dalam dokumentasi](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) MySQL.
# synch/cond/sql/MDL\$1konteks: :cond\$1wait\$1status
Peristiwa `synch/cond/sql/MDL_context::COND_wait_status` terjadi saat terdapat thread yang menunggu pada kunci metadata tabel.
**Topics**
+ [Versi mesin yang didukung](#ams-waits.cond-wait-status.context.supported)
+ [Konteks](#ams-waits.cond-wait-status.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.cond-wait-status.causes)
+ [Tindakan](#ams-waits.cond-wait-status.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 2 dan 3
## Konteks
Peristiwa `synch/cond/sql/MDL_context::COND_wait_status` menunjukkan bahwa terdapat thread yang menunggu pada kunci metadata tabel. Dalam kasus tertentu, satu sesi mempertahankan kunci metadata pada tabel, sementara sesi lainnya mencoba mendapatkan kunci yang sama pada tabel yang sama. Jika demikian, sesi kedua akan menunggu pada peristiwa tunggu `synch/cond/sql/MDL_context::COND_wait_status`.
MySQL menggunakan penguncian metadata untuk mengelola akses bersamaan ke objek basis data dan memastikan konsistensi data. Penguncian metadata berlaku untuk tabel, skema, acara terjadwal, tablespace, dan penguncian pengguna yang diperoleh dengan fungsi `get_lock`, serta program yang disimpan. Program yang disimpan mencakup prosedur, fungsi, dan pemicu. Untuk informasi selengkapnya, lihat [Metadata locking](https://dev.mysql.com/doc/refman/5.7/en/metadata-locking.html) dalam dokumentasi MySQL.
Daftar proses MySQL menunjukkan sesi ini dalam status `waiting for metadata lock`. Dalam Wawasan Performa, jika `Performance_schema` diaktifkan, maka peristiwa `synch/cond/sql/MDL_context::COND_wait_status` akan muncul.
Batas waktu default untuk kueri yang menunggu pada penguncian metadata didasarkan pada nilai parameter `lock_wait_timeout`, dengan nilai default 31.536.000 detik (365 hari).
Untuk detail selengkapnya tentang berbagai kunci InnoDB dan jenis kunci yang dapat menyebabkan konflik, lihat [InnoDB Locking](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) dalam dokumentasi MySQL.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa `synch/cond/sql/MDL_context::COND_wait_status` muncul lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, berikut adalah penyebab umumnya:
**Transaksi yang berjalan lama**
Satu atau lebih transaksi mengubah data dalam jumlah besar data dan menahan kunci pada tabel untuk waktu yang sangat lama.
**Transaksi idle**
Satu atau lebih transaksi tetap terbuka untuk waktu yang lama, tanpa di-commit atau di-roll back.
**Pernyataan DDL pada tabel besar**
Satu atau lebih pernyataan definisi data (DDL), seperti perintah `ALTER TABLE`, dijalankan pada tabel yang sangat besar.
**Kunci tabel eksplisit**
Terdapat kunci eksplisit pada tabel yang tidak dirilis tepat waktu. Misalnya, sebuah aplikasi mungkin menjalankan pernyataan `LOCK TABLE` secara salah.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda dan versi klaster DB Aurora MySQL.
**Topics**
+ [Mengidentifikasi sesi dan kueri penyebab peristiwa](#ams-waits.cond-wait-status.actions.identify)
+ [Memeriksa peristiwa masa lalu](#ams-waits.cond-wait-status.actions.past-events)
+ [Menjalankan kueri pada Aurora MySQL versi 2](#ams-waits.cond-wait-status.actions.run-queries-aurora-mysql-57)
+ [Merespons sesi pemblokiran](#ams-waits.cond-wait-status.actions.blocker)
### Mengidentifikasi sesi dan kueri penyebab peristiwa
Anda dapat menggunakan Wawasan Performa untuk menampilkan kueri yang diblokir oleh peristiwa tunggu `synch/cond/sql/MDL_context::COND_wait_status`. Namun, untuk mengidentifikasi sesi pemblokiran, buat kueri tabel metadata dari `performance_schema` dan `information_schema` di klaster DB.
Biasanya, basis data dengan beban sedang hingga signifikan memiliki peristiwa tunggu. Peristiwa tunggu ini mungkin dapat diterima jika basis data berperforma optimal. Jika tidak, periksa di mana basis data tersebut menghabiskan waktu terbanyak. Lihat peristiwa tunggu yang berkontribusi ke beban tertinggi, lalu cari tahu apakah Anda dapat mengoptimalkan basis data dan aplikasi untuk mengurangi peristiwa tersebut.
**Untuk menemukan kueri SQL yang bertanggung jawab atas beban tinggi:**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih instans DB. Dasbor Wawasan Performa untuk instans DB tersebut akan muncul.
1. Dalam bagan **Beban basis data**, pilih **Potong berdasarkan masa tunggu**.
1. Di bagian bawah halaman, pilih **SQL Teratas**.
Bagan ini mencantumkan kueri SQL yang bertanggung jawab atas beban. Kueri di bagian atas daftar memiliki tanggung jawab terbesar. Untuk mengatasi kemacetan, fokus pada pernyataan tersebut.
Untuk ikhtisar berguna tentang pemecahan masalah menggunakan Performance Insights, lihat Posting Blog Database Menganalisis Beban AWS Kerja [MySQL Amazon Aurora](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) dengan Performance Insights.
### Memeriksa peristiwa masa lalu
Anda dapat memperoleh wawasan tentang peristiwa tunggu ini untuk memeriksa peristiwa di masa lalu. Untuk melakukannya, selesaikan tindakan berikut:
+ Periksa bahasa manipulasi data (DML) dan throughput serta latensi DDL untuk mengetahui apakah terdapat perubahan pada beban kerja.
Anda dapat menggunakan Wawasan Performa untuk menemukan kueri yang menunggu pada peristiwa ini saat masalah terjadi. Anda juga dapat melihat inti sari kueri yang berjalan menjelang waktu masalah terjadi.
+ Jika log audit atau log umum diaktifkan untuk klaster DB, Anda dapat memeriksa semua kueri yang berjalan pada objek (schema.table) yang terlibat dalam transaksi tunggu. Anda juga dapat memeriksa kueri yang selesai berjalan sebelum transaksi.
Informasi yang tersedia untuk memecahkan masalah peristiwa masa lalu terbatas. Melakukan pemeriksaan ini tidak menunjukkan objek yang menunggu informasi. Namun, Anda dapat mengidentifikasi tabel dengan beban berat saat peristiwa terjadi dan kumpulan baris yang sering dioperasikan yang menyebabkan konflik pada saat masalah terjadi. Anda kemudian dapat menggunakan informasi ini untuk mereproduksi masalah di lingkungan pengujian dan memberikan wawasan tentang penyebabnya.
### Menjalankan kueri pada Aurora MySQL versi 2
Di Aurora MySQL versi 2, Anda dapat mengidentifikasi sesi yang diblokir secara langsung dengan membuat kueri tabel `performance_schema` atau tampilan skema `sys`. Sebuah contoh dapat mengilustrasikan cara membuat kueri tabel untuk mengidentifikasi kueri dan sesi pemblokiran.
Dalam output daftar proses berikut, ID koneksi `89` sedang menunggu pada kunci metadata, dan menjalankan perintah `TRUNCATE TABLE`. Dalam kueri pada tabel `performance_schema` atau tampilan skema `sys`, output menunjukkan bahwa sesi pemblokiran adalah `76`.
```
MySQL [(none)]> select @@version, @@aurora_version;
+-----------+------------------+
| @@version | @@aurora_version |
+-----------+------------------+
| 5.7.12 | 2.11.5 |
+-----------+------------------+
1 row in set (0.01 sec)
MySQL [(none)]> show processlist;
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL |
| 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL |
| 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL |
| 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL |
| 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL |
| 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL |
| 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL |
| 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL |
| 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL |
| 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL |
| 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL |
| 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL |
| 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL |
| 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist |
| 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) |
| 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
18 rows in set (0.00 sec)
```
Selanjutnya, sebuah kueri pada tabel `performance_schema` atau tampilan skema `sys` menunjukkan bahwa sesi pemblokiran adalah `76`.
```
MySQL [(none)]> select * from sys.schema_table_lock_waits;
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
1 row in set (0.00 sec)
```
### Merespons sesi pemblokiran
Saat mengidentifikasi sesi, opsi Anda mencakup yang berikut:
+ Menghubungi pemilik aplikasi atau pengguna.
+ Jika sesi pemblokiran idle, coba akhiri sesi pemblokiran. Tindakan ini dapat memicu rollback yang panjang. Untuk mempelajari cara mengakhiri sesi, lihat [Mengakhiri sesi atau kueri](mysql-stored-proc-ending.md).
Untuk informasi selengkapnya tentang cara mengidentifikasi transaksi pemblokiran, lihat [Using InnoDB Transaction and Locking Information](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) dalam dokumentasi MySQL.
# synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex
Peristiwa `synch/mutex/innodb/aurora_lock_thread_slot_futex` terjadi ketika satu sesi telah mengunci baris untuk pembaruan dan sesi lain mencoba memperbarui baris yang sama. Untuk informasi selengkapnya, lihat [Penguncian InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) dalam *Referensi MySQL*.
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 2
## Kemungkinan penyebab peningkatan peristiwa tunggu
Beberapa pernyataan bahasa manipulasi data (DML) mengakses baris atau sejumlah baris yang sama secara serentak.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada peristiwa tunggu lain yang Anda lihat.
**Topics**
+ [Menemukan dan merespons pernyataan SQL yang bertanggung jawab atas peristiwa tunggu ini](#ams-waits.waitsynch.actions.id)
+ [Menemukan dan merespons sesi pemblokiran](#ams-waits.waitsynch.actions.blocker)
### Menemukan dan merespons pernyataan SQL yang bertanggung jawab atas peristiwa tunggu ini
Gunakan Wawasan Performa untuk mengidentifikasi pernyataan SQL yang bertanggung jawab atas peristiwa tunggu ini. Pertimbangkan strategi berikut:
+ Jika kunci baris merupakan masalah yang terus-menerus, coba tulis ulang aplikasi untuk menggunakan penguncian optimis.
+ Gunakan pernyataan multibaris.
+ Bagikan beban kerja ke objek basis data yang berbeda-beda. Anda dapat melakukannya melalui partisi.
+ Periksa nilai parameter `innodb_lock_wait_timeout`. Parameter ini mengontrol durasi transaksi menunggu sebelum menghasilkan kesalahan batas waktu.
Untuk ikhtisar pemecahan masalah yang berguna menggunakan Wawasan Performa, lihat postingan blog [Menganalisis Beban Kerja Amazon Aurora MySQL dengan Wawasan Performa](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Menemukan dan merespons sesi pemblokiran
Cari tahu apakah sesi pemblokiran idle atau aktif. Cari tahu juga apakah sesi tersebut berasal dari aplikasi atau pengguna aktif.
Untuk mengidentifikasi sesi yang memegang kunci, Anda dapat menjalankan `SHOW ENGINE INNODB STATUS`. Contoh berikut menunjukkan output sampel.
```
mysql> SHOW ENGINE INNODB STATUS;
---------------------TRANSACTION 302631452, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 80109, OS thread handle 0x2ae915060700, query id 938819 10.0.4.12 reinvent updating
UPDATE sbtest1 SET k=k+1 WHERE id=503
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 148 page no 11 n bits 30 index `PRIMARY` of table `sysbench2`.`sbtest1` trx id 302631452 lock_mode X locks rec but not gap waiting
Record lock, heap no 30 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
```
Sebagai alternatif, Anda dapat menggunakan kueri berikut untuk mengekstrak detail tentang kunci saat ini.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Saat mengidentifikasi sesi, opsi Anda mencakup yang berikut:
+ Menghubungi pemilik aplikasi atau pengguna.
+ Jika sesi pemblokiran idle, coba akhiri sesi pemblokiran. Tindakan ini dapat memicu rollback yang panjang. Untuk mempelajari cara mengakhiri sesi, lihat [Mengakhiri sesi atau kueri](mysql-stored-proc-ending.md).
Untuk informasi selengkapnya tentang cara mengidentifikasi transaksi pemblokiran, lihat [Menggunakan Informasi Penguncian dan Transaksi InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) dalam *Panduan Referensi MySQL*.
# synch/mutex/innodb/buf\$1pool\$1mutex
Peristiwa `synch/mutex/innodb/buf_pool_mutex` terjadi saat thread telah mendapat kunci pada kumpulan buffer InnoDB untuk mengakses halaman dalam memori.
**Topics**
+ [Versi mesin yang relevan](#ams-waits.bufpoolmutex.context.supported)
+ [Konteks](#ams-waits.bufpoolmutex.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.bufpoolmutex.causes)
+ [Tindakan](#ams-waits.bufpoolmutex.actions)
## Versi mesin yang relevan
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora Versi saya 2 SQL
## Konteks
Mutex `buf_pool` adalah mutex tunggal yang melindungi struktur data kontrol dari pool buffer.
Untuk informasi selengkapnya, lihat [Memantau InnoDB Mutex Waits Using Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) di dokumentasi Saya. SQL
## Kemungkinan penyebab peningkatan peristiwa tunggu
Ini adalah peristiwa tunggu khusus beban kerja. Penyebab umum `synch/mutex/innodb/buf_pool_mutex` muncul di antara peristiwa tunggu teratas mencakup yang berikut:
+ Ukuran pool buffer tidak cukup besar untuk menampung set data kerja.
+ Beban kerja lebih spesifik untuk halaman tertentu dari tabel tertentu dalam basis data, yang mengarah ke pertentangan dalam pool buffer.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Mengidentifikasi sesi dan kueri penyebab peristiwa](#ams-waits.bufpoolmutex.actions.identify)
+ [Menggunakan Wawasan Performa](#ams-waits.bufpoolmutex.actions.action1)
+ [Membuat Aurora Replicas](#ams-waits.bufpoolmutex.actions.action2)
+ [Memeriksa ukuran pool buffer](#ams-waits.bufpoolmutex.actions.action3)
+ [Memantau riwayat status global](#ams-waits.bufpoolmutex.actions.action4)
### Mengidentifikasi sesi dan kueri penyebab peristiwa
Biasanya, basis data dengan beban sedang hingga signifikan memiliki peristiwa tunggu. Peristiwa tunggu ini mungkin dapat diterima jika basis data berperforma optimal. Jika tidak, periksa di mana basis data tersebut menghabiskan waktu terbanyak. Lihat peristiwa tunggu yang berkontribusi ke beban tertinggi, lalu cari tahu apakah Anda dapat mengoptimalkan basis data dan aplikasi untuk mengurangi peristiwa tersebut.
**Untuk melihat SQL bagan Teratas di Konsol AWS Manajemen**
1. Buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih instans DB. Dasbor Wawasan Performa ditampilkan untuk instans DB tersebut.
1. Dalam bagan **Beban basis data**, pilih **Potong berdasarkan masa tunggu**.
1. **Di bawah bagan **beban Database**, pilih Top. SQL**
Bagan mencantumkan SQL kueri yang bertanggung jawab atas pemuatan. Kueri di bagian atas daftar memiliki tanggung jawab terbesar. Untuk mengatasi kemacetan, fokus pada pernyataan tersebut.
Untuk ikhtisar berguna tentang pemecahan masalah menggunakan Performance Insights, lihat posting blog Menganalisis Beban [Kerja SQL Saya Amazon Aurora](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) dengan Performance Insights.
### Menggunakan Wawasan Performa
Peristiwa ini terkait dengan beban kerja. Anda dapat menggunakan Wawasan Performa untuk melakukan hal berikut:
+ Mengidentifikasi kapan peristiwa tunggu dimulai dan apakah ada perubahan beban kerja pada saat itu dari log aplikasi atau sumber terkait.
+ Identifikasi SQL pernyataan yang bertanggung jawab atas acara tunggu ini. Periksa rencana eksekusi kueri untuk memastikan bahwa kueri ini dioptimalkan dan menggunakan indeks yang sesuai.
Jika kueri teratas yang bertanggung jawab atas peristiwa tunggu berkaitan dengan objek atau tabel basis data yang sama, coba buat partisi untuk objek atau tabel tersebut.
### Membuat Aurora Replicas
Anda dapat membuat Aurora Replicas untuk menyajikan lalu lintas hanya-baca. Anda juga dapat menggunakan Aurora Auto Scaling untuk menangani lonjakan lalu lintas baca. Pastikan untuk menjalankan tugas hanya-baca terjadwal dan pencadangan logis pada Aurora Replicas.
Untuk informasi selengkapnya, lihat [Auto Scaling Amazon Aurora dengan Replika Aurora](Aurora.Integrating.AutoScaling.md).
### Memeriksa ukuran pool buffer
Periksa apakah ukuran pool buffer cukup untuk beban kerja dengan melihat metrik `innodb_buffer_pool_wait_free`. Jika nilai metrik ini tinggi dan terus bertambah, berarti ukuran pool buffer tidak cukup untuk menangani beban kerja. Jika `innodb_buffer_pool_size` telah diatur dengan benar, nilai `innodb_buffer_pool_wait_free` pasti kecil. Untuk informasi selengkapnya, lihat [InnodB\$1Buffer\$1POOL\$1WAIT\$1FREE](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Innodb_buffer_pool_wait_free) di dokumentasi Saya. SQL
Tingkatkan ukuran pool buffer jika instans DB memiliki cukup memori untuk buffer sesi dan tugas sistem operasi. Jika tidak, ubah instans DB ke kelas instans DB yang lebih besar untuk memperoleh memori tambahan yang dapat dialokasikan ke pool buffer.
**catatan**
Aurora My SQL secara otomatis menyesuaikan nilai `innodb_buffer_pool_instances` berdasarkan konfigurasi. `innodb_buffer_pool_size`
### Memantau riwayat status global
Dengan memantau tingkat perubahan variabel status, Anda dapat mendeteksi masalah penguncian atau memori pada instans DB Anda. Aktifkan Global Status History (GoSH) jika belum diaktifkan. Untuk informasi selengkapnya tentang GoSH, lihat [Mengelola riwayat status global](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH).
Anda juga dapat membuat CloudWatch metrik Amazon khusus untuk memantau variabel status. Untuk informasi selengkapnya, lihat [Memublikasikan metrik kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html).
# synch/mutex/innodb/fil\$1system\$1mutex
Peristiwa `synch/mutex/innodb/fil_system_mutex` terjadi ketika sesi menunggu untuk mengakses cache memori tablespace.
**Topics**
+ [Versi mesin yang didukung](#ams-waits.innodb-fil-system-mutex.context.supported)
+ [Konteks](#ams-waits.innodb-fil-system-mutex.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.innodb-fil-system-mutex.causes)
+ [Tindakan](#ams-waits.innodb-fil-system-mutex.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 2 dan 3
## Konteks
InnoDB menggunakan tablespace untuk mengelola area penyimpanan untuk tabel dan file log. *Cache memori tablespace* adalah struktur memori global yang memelihara informasi tentang tablespace. MySQL menggunakan peristiwa tunggu `synch/mutex/innodb/fil_system_mutex` untuk mengontrol akses bersamaan ke cache memori tablespace.
Peristiwa `synch/mutex/innodb/fil_system_mutex` menunjukkan bahwa saat ini ada lebih dari satu operasi yang perlu mengambil dan memanipulasi informasi dalam cache memori tablespace untuk tablespace yang sama.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa `synch/mutex/innodb/fil_system_mutex` muncul lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, hal ini biasanya terjadi ketika terdapat semua kondisi berikut:
+ Peningkatan operasi bahasa manipulasi data (DML) bersamaan yang memperbarui atau menghapus data dalam tabel yang sama.
+ Tablespace untuk tabel ini sangat besar dan memiliki banyak halaman data.
+ Faktor pengisian untuk halaman data ini rendah.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Mengidentifikasi sesi dan kueri penyebab peristiwa](#ams-waits.innodb-fil-system-mutex.actions.identify)
+ [Mengatur ulang tabel besar di luar jam sibuk](#ams-waits.innodb-fil-system-mutex.actions.reorganize)
### Mengidentifikasi sesi dan kueri penyebab peristiwa
Biasanya, basis data dengan beban sedang hingga signifikan memiliki peristiwa tunggu. Peristiwa tunggu ini mungkin dapat diterima jika basis data berperforma optimal. Jika tidak, periksa di mana basis data tersebut menghabiskan waktu terbanyak. Lihat peristiwa tunggu yang berkontribusi ke beban tertinggi, lalu cari tahu apakah Anda dapat mengoptimalkan basis data dan aplikasi untuk mengurangi peristiwa tersebut.
**Untuk menemukan kueri SQL yang bertanggung jawab atas beban tinggi:**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih instans DB. Dasbor Wawasan Performa untuk instans DB tersebut akan muncul.
1. Dalam bagan **Beban basis data**, pilih **Potong berdasarkan masa tunggu**.
1. Di bagian bawah halaman, pilih **SQL Teratas**.
Bagan ini mencantumkan kueri SQL yang bertanggung jawab atas beban. Kueri di bagian atas daftar memiliki tanggung jawab terbesar. Untuk mengatasi kemacetan, fokus pada pernyataan tersebut.
Untuk ikhtisar pemecahan masalah yang berguna menggunakan Wawasan Performa, lihat postingan blog [Menganalisis Beban Kerja Amazon Aurora MySQL dengan Wawasan Performa](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
Cara lain untuk mengetahui kueri yang menyebabkan tingginya jumlah peristiwa tunggu `synch/mutex/innodb/fil_system_mutex` adalah dengan memeriksa `performance_schema`, seperti pada contoh berikut.
```
mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G
*************************** 1. row ***************************
THREAD_ID: 19
EVENT_ID: 195057
END_EVENT_ID: 195057
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:6700
TIMER_START: 1010146190118400
TIMER_END: 1010146196524000
TIMER_WAIT: 6405600
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 2. row ***************************
THREAD_ID: 23
EVENT_ID: 5480
END_EVENT_ID: 5480
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:5906
TIMER_START: 995269979908800
TIMER_END: 995269980159200
TIMER_WAIT: 250400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 3. row ***************************
THREAD_ID: 55
EVENT_ID: 23233794
END_EVENT_ID: NULL
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:449
TIMER_START: 1010492125341600
TIMER_END: 1010494304900000
TIMER_WAIT: 2179558400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: 23233786
NESTING_EVENT_TYPE: WAIT
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
```
### Mengatur ulang tabel besar di luar jam sibuk
Atur ulang tabel besar yang Anda identifikasi sebagai sumber tingginya jumlah peristiwa tunggu `synch/mutex/innodb/fil_system_mutex` selama periode pemeliharaan di luar jam produksi. Dengan melakukannya, Anda akan memastikan bahwa pembersihan peta tablespace internal tidak terjadi saat akses cepat ke tabel sangat penting. Untuk informasi tentang cara mengatur ulang tabel, lihat [Pernyataan OPTIMIZE TABLE](https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html) dalam *Referensi MySQL*.
# synch/mutex/innodb/trx\$1sys\$1mutex
Peristiwa `synch/mutex/innodb/trx_sys_mutex` terjadi ketika terdapat aktivitas basis data tinggi dengan transaksi dalam jumlah besar.
**Topics**
+ [Versi mesin yang relevan](#ams-waits.trxsysmutex.context.supported)
+ [Konteks](#ams-waits.trxsysmutex.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.trxsysmutex.causes)
+ [Tindakan](#ams-waits.trxsysmutex.actions)
## Versi mesin yang relevan
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora SQL Versi saya 2 dan 3
## Konteks
Secara internal, mesin basis data InnoDB menggunakan tingkat isolasi baca berulang dengan snapshot untuk menghadirkan konsistensi baca. Ini memberi Anda point-in-time tampilan database pada saat snapshot dibuat.
Di InnoDB, semua perubahan diterapkan ke basis data segera setelah tersedia, terlepas dari apakah perubahan tersebut di-commit. Pendekatan ini berarti bahwa tanpa kontrol konkurensi multiversi (MVCC), semua pengguna yang terhubung ke database melihat semua perubahan dan baris terbaru. Karena itu, InnoDB memerlukan cara untuk melacak perubahan guna memahami strategi rollback bila diperlukan.
Untuk melakukannya, InnoDB menggunakan sistem transaksi (`trx_sys`) untuk melacak snapshot. Sistem transaksi melakukan hal berikut:
+ Melacak ID transaksi untuk setiap baris dalam log pembatalan.
+ Menggunakan struktur InnoDB internal `ReadView` yang disebut yang membantu mengidentifikasi transaksi mana IDs yang terlihat untuk snapshot.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Setiap operasi database yang memerlukan penanganan yang konsisten dan terkontrol (membuat, membaca, memperbarui, dan menghapus) transaksi IDs menghasilkan panggilan dari `trx_sys` mutex.
Panggilan ini terjadi di dalam tiga fungsi:
+ `trx_sys_mutex_enter` – Menciptakan mutex.
+ `trx_sys_mutex_exit` – Melepaskan mutex.
+ `trx_sys_mutex_own` – Menguji apakah mutex dimiliki.
Instrumentasi Skema Performa InnoDB melacak semua panggilan mutex `trx_sys`. Pelacakan mencakup, tetapi tidak terbatas pada, manajemen `trx_sys` pada pengaktifan atau penonaktifan basis data, operasi rollback, pembersihan pembatalan, akses baca baris, dan pemuatan pool buffer. Aktivitas basis data yang tinggi dengan transaksi dalam jumlah besar mengakibatkan kemunculan `synch/mutex/innodb/trx_sys_mutex` di antara peristiwa tunggu teratas.
Untuk informasi selengkapnya, lihat [Memantau InnoDB Mutex Waits Using Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) di dokumentasi Saya. SQL
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Mengidentifikasi sesi dan kueri penyebab peristiwa](#ams-waits.trxsysmutex.actions.identify)
+ [Memeriksa peristiwa tunggu lainnya](#ams-waits.trxsysmutex.actions.action1)
### Mengidentifikasi sesi dan kueri penyebab peristiwa
Biasanya, basis data dengan beban sedang hingga signifikan memiliki peristiwa tunggu. Peristiwa tunggu ini mungkin dapat diterima jika basis data berperforma optimal. Jika tidak, periksa di mana basis data tersebut menghabiskan waktu terbanyak. Lihat peristiwa tunggu yang berkontribusi terhadap beban tertinggi. Cari tahu apakah Anda dapat mengoptimalkan basis data dan aplikasi untuk mengurangi peristiwa tersebut.
**Untuk melihat SQL grafik Teratas di Konsol Manajemen AWS**
1. Buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih instans DB. Dasbor Wawasan Performa ditampilkan untuk instans DB tersebut.
1. Dalam bagan **Beban basis data**, pilih **Potong berdasarkan masa tunggu**.
1. Di bawah Bagan **beban database**, pilih **Top SQL**.
Bagan mencantumkan SQL kueri yang bertanggung jawab atas pemuatan. Kueri di bagian atas daftar memiliki tanggung jawab terbesar. Untuk mengatasi kemacetan, fokus pada pernyataan tersebut.
Untuk ikhtisar berguna tentang pemecahan masalah menggunakan Performance Insights, lihat posting blog Menganalisis Beban [Kerja SQL Saya Amazon Aurora](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) dengan Performance Insights.
### Memeriksa peristiwa tunggu lainnya
Periksa peristiwa tunggu lain yang terkait dengan peristiwa tunggu `synch/mutex/innodb/trx_sys_mutex`. Dengan melakukannya, Anda dapat memperoleh informasi selengkapnya tentang sifat beban kerja. Sejumlah besar transaksi dapat mengurangi throughput, tetapi beban kerja mungkin juga mengharuskannya.
Untuk informasi selengkapnya tentang cara mengoptimalkan transaksi, lihat [Mengoptimalkan Manajemen Transaksi InnoDB](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html) di dokumentasi Saya. SQL
# synch/sxlock/innodb/hash\$1table\$1locks
Peristiwa `synch/sxlock/innodb/hash_table_locks` terjadi ketika halaman yang tidak ditemukan di pool buffer harus dibaca dari penyimpanan.
**Topics**
+ [Versi mesin yang didukung](#ams-waits.sx-lock-hash-table-locks.context.supported)
+ [Konteks](#ams-waits.sx-lock-hash-table-locks.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.sx-lock-hash-table-locks.causes)
+ [Tindakan](#ams-waits.sx-lock-hash-table-locks.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi berikut:
+ Aurora SQL Versi saya 2 dan 3
## Konteks
Peristiwa `synch/sxlock/innodb/hash_table_locks` menunjukkan bahwa beban kerja sering kali mengakses data yang tidak disimpan dalam pool buffer. Peristiwa tunggu ini dikaitkan dengan penambahan halaman baru dan pengosongan data lama dari pool buffer. Data yang disimpan dalam pool buffer usang dan data baru harus di-cache, jadi halaman usang dikosongkan untuk memungkinkan caching halaman baru. Saya SQL menggunakan algoritma (LRU) yang paling jarang digunakan untuk mengusir halaman dari kumpulan buffer. Beban kerja mencoba mengakses data yang belum dimuat ke dalam pool buffer atau data yang telah dikosongkan dari pool buffer.
Peristiwa tunggu ini terjadi ketika beban kerja harus mengakses data dalam file pada disk atau ketika blok dibebaskan dari atau ditambahkan ke daftar kumpulan buffer. LRU Operasi ini menunggu untuk memperoleh kunci yang dikecualikan bersama (SX-lock). SX-lock ini digunakan untuk sinkronisasi melalui *tabel hash*, yakni tabel dalam memori yang dirancang untuk meningkatkan performa akses pool buffer.
Untuk informasi selengkapnya, lihat [Buffer Pool](https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html) di SQL dokumentasi Saya.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa tunggu `synch/sxlock/innodb/hash_table_locks` muncul lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, berikut adalah penyebab umumnya:
**Pool buffer berukuran sangat kecil**
Ukuran pool buffer terlalu kecil untuk menyimpan semua halaman yang sering diakses dalam memori.
**Beban kerja berat**
Beban kerja menyebabkan seringnya pengosongan dan halaman data dimuat ulang di cache buffer.
**Kesalahan membaca halaman**
Terjadi kesalahan saat membaca halaman di pool buffer, yang mungkin mengindikasikan adanya kerusakan data.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Meningkatkan ukuran pool buffer](#ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size)
+ [Meningkatkan pola akses data](#ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns)
+ [Mengurangi atau mencegah pemindaian tabel penuh](#ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans)
+ [Memeriksa log kesalahan untuk kerusakan halaman](#ams-waits.sx-lock-hash-table-locks.actions.check-error-logs)
### Meningkatkan ukuran pool buffer
Pastikan pool buffer memiliki ukuran yang sesuai untuk beban kerja. Untuk melakukannya, Anda dapat memeriksa laju hit cache pool buffer. Biasanya, jika nilainya turun di bawah 95%, coba tingkatkan ukuran pool buffer. Pool buffer yang lebih besar dapat lebih lama menyimpan halaman yang sering diakses dalam memori. Untuk meningkatkan ukuran pool buffer, ubah nilai parameter `innodb_buffer_pool_size`. Nilai default parameter ini didasarkan pada ukuran kelas instans DB. Untuk informasi selengkapnya, lihat [Praktik terbaik untuk konfigurasi SQL database Amazon Aurora Saya](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/).
### Meningkatkan pola akses data
Periksa kueri yang terpengaruh oleh peristiwa tunggu ini dan rencana eksekusinya. Coba tingkatkan pola akses data. Misalnya, jika menggunakan [mysqli\$1result::fetch\$1array](https://www.php.net/manual/en/mysqli-result.fetch-array.php), Anda dapat mencoba meningkatkan ukuran pengambilan array.
Anda dapat menggunakan Wawasan Performa untuk menampilkan kueri dan sesi yang mungkin menyebabkan peristiwa tunggu `synch/sxlock/innodb/hash_table_locks`.
**Untuk menemukan SQL kueri yang bertanggung jawab atas beban tinggi**
1. Masuk ke Konsol Manajemen AWS dan buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih instans DB. Dasbor Wawasan Performa ditampilkan untuk instans DB tersebut.
1. Dalam bagan **Beban basis data**, pilih **Potong berdasarkan masa tunggu**.
1. Di bagian bawah halaman, pilih **Top SQL**.
Bagan mencantumkan SQL kueri yang bertanggung jawab atas pemuatan. Kueri di bagian atas daftar memiliki tanggung jawab terbesar. Untuk mengatasi kemacetan, fokus pada pernyataan tersebut.
Untuk ikhtisar berguna tentang pemecahan masalah menggunakan Performance Insights, lihat posting Blog Database Menganalisis AWS Beban [Kerja SQL Saya Amazon Aurora](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) dengan Performance Insights.
### Mengurangi atau mencegah pemindaian tabel penuh
Pantau beban kerja untuk melihat apakah pemindaian tabel penuh dijalankan, dan jika ya, kurangi atau cegah pemindaian tersebut. Misalnya, Anda dapat memantau variabel status seperti `Handler_read_rnd_next`. Untuk informasi selengkapnya, lihat [Variabel Status Server](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Handler_read_rnd_next) dalam SQL dokumentasi Saya.
### Memeriksa log kesalahan untuk kerusakan halaman
Anda dapat memeriksa mysql-error.log untuk pesan terkait kerusakan yang terdeteksi menjelang waktu terjadinya masalah. Pesan yang dapat Anda tangani untuk menyelesaikan masalah terdapat di log kesalahan. Anda mungkin perlu membuat ulang objek yang dilaporkan rusak.
# synch/mutex/innodb/temp\$1pool\$1manager\$1mutex
Peristiwa `synch/mutex/innodb/temp_pool_manager_mutex` tunggu terjadi ketika sesi menunggu untuk memperoleh mutex untuk mengelola kumpulan ruang tabel sementara sesi.
**Topics**
+ [Versi mesin yang didukung](#ams-waits.io-temppoolmanager.context.supported)
+ [Konteks](#ams-waits.io-temppoolmanager.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.io-temppoolmanager.causes)
+ [Tindakan](#ams-waits.io-temppoolmanager.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 3
## Konteks
Aurora MySQL versi 3.x dan yang lebih tinggi digunakan `temp_pool_manager_mutex` untuk mengontrol beberapa sesi mengakses kolam tablespace sementara pada saat yang bersamaan. Aurora MySQL mengelola penyimpanan melalui volume cluster Aurora untuk data persisten dan penyimpanan lokal untuk file sementara. Sebuah tablespace sementara diperlukan ketika sesi membuat tabel sementara pada volume cluster Aurora.
Saat sesi pertama kali meminta tablespace sementara, MySQL mengalokasikan ruang tabel sementara sesi dari kolam bersama. Sesi dapat menampung hingga 2 ruang tabel sementara sekaligus untuk jenis tabel berikut:
+ Tabel sementara yang dibuat pengguna
+ Tabel sementara internal yang dihasilkan pengoptimal
`TempTable`Mesin default menggunakan mekanisme overflow berikut untuk menangani tabel sementara:
+ Menyimpan tabel dalam RAM hingga [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram)batasnya.
+ Pindah ke file yang dipetakan memori di penyimpanan lokal saat RAM penuh.
+ Menggunakan volume cluster bersama saat file yang dipetakan memori mencapai batasnya. [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap)
Setelah tabel sementara melebihi RAM dan batas penyimpanan lokal, MySQL mengelolanya menggunakan tablespace on-disk.
Ketika sesi membutuhkan tabel sementara pada disk, MySQL:
+ Mencari `INACTIVE` ruang meja yang tersedia di kolam untuk digunakan kembali.
+ Membuat 10 ruang tabel baru jika tidak ada `INACTIVE` spasi.
Ketika sesi terputus, MySQL:
+ Memangkas ruang tabel sementara sesi.
+ Tandai mereka sebagai TIDAK AKTIF di kolam untuk digunakan kembali.
+ Mempertahankan ukuran pool saat ini sampai server restart.
+ Kembali ke ukuran kolam default (10 tablespaces) setelah restart.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Situasi umum yang menyebabkan acara tunggu ini:
+ Sesi bersamaan membuat tabel sementara internal pada volume cluster.
+ Sesi bersamaan membuat tabel sementara pengguna pada volume cluster.
+ Penghentian sesi secara tiba-tiba menggunakan ruang tabel aktif.
+ Ekspansi kolam tablespace selama beban kerja tulis berat.
+ Kueri bersamaan mengakses `INFORMATION_SCHEMA.`
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Pantau dan optimalkan penggunaan tabel sementara](#ams-waits.io-temppoolmanager.actions.monitor)
+ [Tinjau kueri menggunakan INFORMATION\$1SCHEMA](#ams-waits.io-temppoolmanager.actions.schema-queries)
+ [Meningkatkan parameter innodb\$1sync\$1array\$1size](#ams-waits.io-temppoolmanager.actions.sync_array)
+ [Menerapkan penyatuan koneksi](#ams-waits.io-temppoolmanager.actions.connection_pooling)
### Pantau dan optimalkan penggunaan tabel sementara
Untuk memantau dan mengoptimalkan penggunaan tabel sementara, gunakan salah satu metode berikut:
+ Periksa `Created_tmp_disk_tables` penghitung di Performance Insights untuk melacak pembuatan tabel sementara di disk di seluruh klaster Aurora Anda.
+ Jalankan perintah ini di database Anda untuk secara langsung memonitor pembuatan tabel sementara:`mysql> show status like '%created_tmp_disk%'`.
**catatan**
Perilaku tabel sementara berbeda antara node pembaca MySQL Aurora dan node penulis. Untuk informasi selengkapnya, lihat [Perilaku tabel sementara baru di Aurora MySQL versi 3](ams3-temptable-behavior.md).
Setelah mengidentifikasi kueri yang membuat tabel sementara, lakukan langkah-langkah pengoptimalan ini:
+ Gunakan `EXPLAIN` untuk memeriksa rencana eksekusi kueri dan mengidentifikasi di mana dan mengapa tabel sementara sedang dibuat.
+ Ubah kueri untuk mengurangi penggunaan tabel sementara jika memungkinkan.
Jika optimasi kueri saja tidak menyelesaikan masalah kinerja, pertimbangkan untuk menyesuaikan parameter konfigurasi ini:
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram)- Mengontrol penggunaan RAM maksimum untuk tabel sementara.
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap)- Menetapkan batas untuk penyimpanan file yang dipetakan memori.
+ [https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size)- Berlaku saat `aurora_tmptable_enable_per_table_limit` diaktifkan (dinonaktifkan secara default).
**penting**
Perhatikan bahwa kondisi kueri tertentu akan selalu memerlukan tabel sementara pada disk, terlepas dari pengaturan konfigurasi. Untuk informasi selengkapnya mesin `TempTable` penyimpanan, lihat [Menggunakan mesin TempTable penyimpanan di Amazon RDS for MySQL dan Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
### Tinjau kueri menggunakan INFORMATION\$1SCHEMA
Saat Anda menanyakan `INFORMATION_SCHEMA` tabel, MySQL membuat tabel sementara InnoDB pada volume cluster. Setiap sesi membutuhkan ruang meja sementara untuk tabel ini, yang dapat menyebabkan masalah kinerja selama akses bersamaan yang tinggi.
Untuk meningkatkan kinerja:
+ Gunakan `PERFORMANCE_SCHEMA` alih-alih `INFORMATION_SCHEMA` jika memungkinkan.
+ Jika Anda harus menggunakan`INFORMATION_SCHEMA`, kurangi seberapa sering Anda menjalankan kueri ini.
### Meningkatkan parameter innodb\$1sync\$1array\$1size
`innodb_sync_array_size`Parameter mengontrol ukuran array mutex/lock tunggu di MySQL. Nilai default `1` karya untuk beban kerja umum, tetapi meningkatkannya dapat mengurangi pertentangan utas selama konkurensi tinggi.
Saat beban kerja Anda menunjukkan peningkatan jumlah utas tunggu:
+ Pantau jumlah utas tunggu di beban kerja Anda.
+ Tetapkan `innodb_sync_array_size` sama dengan atau lebih tinggi dari jumlah vCPU instans Anda untuk membagi struktur koordinasi utas dan mengurangi pertengkaran.
**catatan**
Untuk menentukan jumlah v yang CPUs tersedia pada instans RDS Anda, lihat spesifikasi vCPU di jenis instans [Amazon RDS](https://aws.amazon.com/rds/instance-types/).
### Menerapkan penyatuan koneksi
MySQL menetapkan tablespace khusus untuk setiap sesi yang membuat tabel sementara. Tablespace ini tetap aktif sampai koneksi database berakhir. Untuk mengelola sumber daya Anda dengan lebih efisien:
+ Menerapkan penyatuan koneksi untuk membatasi jumlah ruang meja sementara yang aktif.
+ Gunakan kembali koneksi yang ada alih-alih membuat yang baru untuk setiap operasi.
# Menyesuaikan Aurora MySQL dengan status thread
Tabel berikut merangkum status thread paling umum untuk Aurora MySQL.
| Status thread umum | Deskripsi |
| --- | --- |
| [creating sort index](ams-states.sort-index.md) | Status thread ini menunjukkan bahwa sebuah thread sedang memproses pernyataan `SELECT` yang memerlukan penggunaan tabel sementara internal untuk mengurutkan data. |
| [sending data](ams-states.sending-data.md) | Status thread ini menunjukkan bahwa sebuah thread sedang membaca dan memfilter baris untuk kueri guna menentukan set hasil yang benar. |
# creating sort index
Status thread `creating sort index` menunjukkan bahwa thread sedang memproses pernyataan `SELECT` yang memerlukan penggunaan tabel sementara internal untuk mengurutkan data.
**Topics**
+ [Versi mesin yang didukung](#ams-states.sort-index.context.supported)
+ [Konteks](#ams-states.sort-index.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-states.sort-index.causes)
+ [Tindakan](#ams-states.sort-index.actions)
## Versi mesin yang didukung
Informasi status thread ini didukung untuk versi berikut:
+ Aurora MySQL versi 2 hingga 2.09.2
## Konteks
Status `creating sort index` muncul saat kueri dengan klausa `ORDER BY` atau `GROUP BY` tidak dapat menggunakan indeks yang ada untuk melakukan operasi. Dalam hal ini, MySQL perlu melakukan operasi `filesort` yang lebih mahal. Operasi ini biasanya dilakukan dalam memori jika set hasil tidak terlalu besar. Jika set hasil besar, operasi akan melibatkan pembuatan file pada disk.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Kemunculan `creating sort index` tidak dengan sendirinya menunjukkan adanya suatu masalah. Jika performa buruk, dan Anda sering melihat instans `creating sort index`, penyebab yang paling mungkin adalah kueri lambat dengan operator `ORDER BY` atau `GROUP BY`.
## Tindakan
Pedoman umumnya adalah menemukan kueri dengan klausa `ORDER BY` atau `GROUP BY` yang terkait dengan peningkatan dalam status `creating sort index`. Lalu, lihat apakah menambahkan indeks atau meningkatkan ukuran buffer urutan akan memecahkan masalah.
**Topics**
+ [Mengaktifkan Skema Performa jika tidak aktif](#ams-states.sort-index.actions.enable-pfs)
+ [Mengidentifikasi kueri masalah](#ams-states.sort-index.actions.identify)
+ [Memeriksa "jelaskan rencana" untuk penggunaan filesort](#ams-states.sort-index.actions.plan)
+ [Meningkatkan ukuran buffer urutan](#ams-states.sort-index.actions.increasebuffersize)
### Mengaktifkan Skema Performa jika tidak aktif
Wawasan Performa akan melaporkan status thread hanya jika instrumen Skema Performa tidak aktif. Bila instrumen Skema Performa diaktifkan, Wawasan Performa akan melaporkan peristiwa tunggu. Instrumen Skema Performa memberikan wawasan tambahan dan alat yang lebih baik untuk menyelidiki potensi masalah performa. Oleh karena itu, sebaiknya Anda mengaktifkan Skema Performa. Untuk informasi selengkapnya, lihat [Ikhtisar Skema Kinerja untuk Performance Insights di Aurora ](USER_PerfInsights.EnableMySQL.md).
### Mengidentifikasi kueri masalah
Untuk mengidentifikasi kueri saat ini yang menyebabkan peningkatan dalam status `creating sort index`, jalankan `show processlist` dan lihat apakah kueri memiliki `ORDER BY` atau `GROUP BY`. Cara lainnya, jalankan `explain for connection N`, dengan `N` adalah ID daftar proses kueri dengan `filesort`.
Untuk mengidentifikasi kueri sebelumnya yang menyebabkan peningkatan ini, aktifkan log kueri lambat dan temukan kueri dengan `ORDER BY`. Jalankan `EXPLAIN` pada kueri lambat dan cari "menggunakan filesort". Untuk informasi selengkapnya, lihat [Memeriksa "jelaskan rencana" untuk penggunaan filesort](#ams-states.sort-index.actions.plan).
### Memeriksa "jelaskan rencana" untuk penggunaan filesort
Identifikasi pernyataan dengan klausa `ORDER BY` atau `GROUP BY` yang menghasilkan status `creating sort index`.
Contoh berikut menunjukkan cara menjalankan `explain` pada kueri. Kolom `Extra` menunjukkan bahwa kueri ini menggunakan `filesort`.
```
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: mytable
partitions: NULL
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 2064548
filtered: 100.00
Extra: Using filesort
1 row in set, 1 warning (0.01 sec)
```
Contoh berikut menunjukkan hasil menjalankan `EXPLAIN` pada kueri yang sama setelah indeks dibuat pada kolom `c1`.
```
mysql> alter table mytable add index (c1);
```
```
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: mytable
partitions: NULL
type: index
possible_keys: NULL
key: c1
key_len: 1023
ref: NULL
rows: 10
filtered: 100.00
Extra: Using index
1 row in set, 1 warning (0.01 sec)
```
Untuk informasi tentang penggunaan indeks pada pengoptimalan tata urutan, lihat [ORDER BY Optimization](https://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html) dalam dokumentasi MySQL.
### Meningkatkan ukuran buffer urutan
Untuk mengetahui apakah kueri tertentu memerlukan proses `filesort` yang membuat file pada disk, periksa nilai variabel `sort_merge_passes` setelah menjalankan kueri. Berikut adalah contohnya.
```
mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.01 sec)
--- run query
mysql> select * from mytable order by u limit 10;
--- run status again:
mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.01 sec)
```
Jika nilai `sort_merge_passes` tinggi, coba tingkatkan ukuran buffer urutan. Terapkan peningkatan tersebut pada tahap sesi. Menerapkannya secara global dapat secara signifikan meningkatkan jumlah penggunaan RAM MySQL. Contoh berikut menunjukkan cara mengubah ukuran buffer urutan sebelum menjalankan kueri.
```
mysql> set session sort_buffer_size=10*1024*1024;
Query OK, 0 rows affected (0.00 sec)
-- run query
```
# sending data
Status thread `sending data` menunjukkan bahwa thread membaca dan memfilter baris untuk kueri guna menentukan set hasil yang benar. Namanya agak membingungkan karena menyiratkan status mentransfer data, bukan mengumpulkan dan menyiapkan data untuk dikirim nanti.
**Topics**
+ [Versi mesin yang didukung](#ams-states.sending-data.context.supported)
+ [Konteks](#ams-states.sending-data.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-states.sending-data.causes)
+ [Tindakan](#ams-states.sending-data.actions)
## Versi mesin yang didukung
Informasi status thread ini didukung untuk versi berikut:
+ Aurora MySQL versi 2 hingga 2.09.2
## Konteks
Banyak status thread tidak bertahan lama. Operasi yang terjadi selama `sending data` cenderung melakukan pembacaan disk atau cache dalam jumlah besar. Oleh karena itu, `sending data` sering kali merupakan status yang paling lama berjalan selama masa kueri tertentu. Status ini muncul saat Aurora MySQL melakukan hal berikut:
+ Membaca dan memproses baris untuk pernyataan `SELECT`
+ Menjalankan pembacaan dalam jumlah besar baik dari disk atau memori
+ Menyelesaikan pembacaan lengkap semua data dari kueri tertentu
+ Membaca data dari tabel, indeks, atau pekerjaan prosedur yang disimpan
+ Menyortir, mengelompokkan, atau menyusun data
Setelah status `sending data` selesai menyiapkan data, status thread `writing to net` akan menunjukkan pengembalian data ke klien. Biasanya, `writing to net` diambil hanya ketika set hasil sangat besar atau latensi jaringan yang parah memperlambat transfer.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Kemunculan `sending data` tidak dengan sendirinya menunjukkan adanya suatu masalah. Jika performa buruk, dan Anda sering melihat instans `sending data`, berikut adalah penyebab yang paling memungkinkan.
**Topics**
+ [Kueri yang tidak efisien](#ams-states.sending-data.causes.structure)
+ [Konfigurasi server suboptimal](#ams-states.sending-data.causes.server)
### Kueri yang tidak efisien
Dalam sebagian besar kasus, status ini terutama disebabkan oleh kueri yang tidak menggunakan indeks yang sesuai untuk menemukan set hasil kueri tertentu. Sebagai contoh, pertimbangkan kueri yang membaca tabel berisi 10 juta data untuk semua pesanan yang ditempatkan di California, dengan kolom status tidak diindeks atau diindeks dengan buruk. Pada contoh terakhir, indeks mungkin ada, tetapi pengoptimal mengabaikannya karena kardinalitas rendah.
### Konfigurasi server suboptimal
Jika beberapa kueri muncul dalam status `sending data`, server basis data mungkin dikonfigurasi dengan buruk. Secara khusus, server mungkin memiliki masalah berikut:
+ Server database tidak memiliki kapasitas komputasi yang cukup: disk I/O, jenis dan kecepatan disk, CPU, atau jumlah. CPUs
+ Server kekurangan sumber daya yang dialokasikan, seperti kumpulan buffer InnoDB untuk tabel InnoDB atau buffer kunci untuk tabel. MyIsam
+ Pengaturan memori per-thread seperti `sort_buffer`, `read_buffer`, dan `join_buffer` menghabiskan lebih banyak RAM dari yang dibutuhkan, sehingga membuat server fisik kekurangan sumber daya memori.
## Tindakan
Pedoman umumnya adalah menemukan kueri yang mengembalikan baris dalam jumlah besar dengan memeriksa Skema Performa. Jika pencatatan kueri yang tidak menggunakan indeks diaktifkan, Anda juga dapat memeriksa hasil dari log lambat.
**Topics**
+ [Mengaktifkan Skema Performa jika tidak aktif](#ams-states.sending-data.actions.enable-pfs)
+ [Memeriksa pengaturan memori](#ams-states.sending-data.actions.memory)
+ [Memeriksa "jelaskan rencana" untuk penggunaan indeks](#ams-states.sending-data.actions.plans)
+ [Memeriksa volume data yang dikembalikan](#ams-states.sending-data.actions.maintenance)
+ [Memeriksa masalah konkurensi](#ams-states.sending-data.actions.concurrent-queries)
+ [Memeriksa struktur kueri](#ams-states.sending-data.actions.subqueries)
### Mengaktifkan Skema Performa jika tidak aktif
Wawasan Performa akan melaporkan status thread hanya jika instrumen Skema Performa tidak aktif. Bila instrumen Skema Performa diaktifkan, Wawasan Performa akan melaporkan peristiwa tunggu. Instrumen Skema Performa memberikan wawasan tambahan dan alat yang lebih baik untuk menyelidiki potensi masalah performa. Oleh karena itu, sebaiknya Anda mengaktifkan Skema Performa. Untuk informasi selengkapnya, lihat [Ikhtisar Skema Kinerja untuk Performance Insights di Aurora ](USER_PerfInsights.EnableMySQL.md).
### Memeriksa pengaturan memori
Periksa pengaturan memori untuk pool buffer utama. Pastikan pool ini memiliki ukuran yang sesuai untuk beban kerja. Jika basis data Anda menggunakan beberapa instans pool buffer, pastikan instans tersebut tidak dibagi menjadi banyak pool buffer kecil. Thread hanya dapat menggunakan satu pool buffer pada satu waktu.
Pastikan pengaturan memori berikut yang digunakan untuk setiap thread memiliki ukuran yang benar:
+ read\$1buffer
+ read\$1rnd\$1buffer
+ sort\$1buffer
+ join\$1buffer
+ binlog\$1cache
Gunakan nilai default, kecuali jika Anda memiliki alasan khusus untuk mengubah pengaturan.
### Memeriksa "jelaskan rencana" untuk penggunaan indeks
Untuk kueri dalam status thread `sending data`, periksa rencana untuk mengetahui apakah indeks yang sesuai telah digunakan. Jika kueri tidak menggunakan indeks yang berguna, coba tambahkan petunjuk seperti `USE INDEX` atau `FORCE INDEX`. Petunjuk dapat menambah atau mengurangi banyak waktu yang diperlukan untuk menjalankan kueri, jadi berhati-hatilah sebelum menambahkannya.
### Memeriksa volume data yang dikembalikan
Periksa tabel yang ditanyakan dan jumlah data yang ada di dalamnya. Apakah data ini dapat diarsipkan? Dalam banyak kasus, penyebab waktu eksekusi kueri yang buruk bukanlah hasil dari rencana kueri, tetapi volume data yang akan diproses. Banyak developer sangat efisien dalam menambahkan data ke basis data, tetapi jarang mempertimbangkan siklus proses set data dalam fase desain dan pengembangan.
Cari kueri yang berperforma baik dalam basis data volume rendah, tetapi berperforma buruk di sistem Anda saat ini. Terkadang, developer yang mendesain kueri tertentu mungkin tidak menyadari bahwa kueri tersebut mengembalikan 350.000 baris. Developer mungkin telah mengembangkan kueri di lingkungan volume yang lebih rendah, dengan set data lebih kecil dari yang dimiliki lingkungan produksi.
### Memeriksa masalah konkurensi
Periksa apakah beberapa kueri dari jenis yang sama berjalan pada waktu yang sama. Format kueri tertentu berjalan secara efisien bila dijalankan sendiri. Namun, jika format kueri serupa berjalan bersama, atau dalam volume tinggi, hal tersebut dapat menimbulkan masalah konkurensi. Masalah ini sering kali muncul bila basis data menggunakan tabel sementara untuk merender hasil. Tingkat isolasi transaksi yang ketat juga dapat menyebabkan masalah konkurensi.
Jika tabel dibaca dan ditulis secara bersamaan, basis data mungkin menggunakan kunci. Untuk membantu mengidentifikasi periode performa yang buruk, periksa penggunaan basis data melalui proses batch skala besar. Untuk melihat kunci dan rollback terbaru, periksa output dari perintah `SHOW ENGINE INNODB STATUS`.
### Memeriksa struktur kueri
Periksa apakah kueri yang diambil dari status ini menggunakan subkueri. Jenis kueri ini sering kali menimbulkan performa yang buruk karena basis data mengompilasi hasil secara internal, lalu menggantinya kembali ke kueri untuk merender data. Proses ini merupakan langkah ekstra untuk basis data. Dalam banyak kasus, langkah ini dapat menimbulkan performa yang buruk pada kondisi pemuatan yang sangat bersamaan.
Periksa juga apakah kueri Anda menggunakan klausa `ORDER BY` dan `GROUP BY` dalam jumlah besar. Dalam operasi semacam ini, sering kali basis data harus terlebih dahulu membentuk set data secara keseluruhan dalam memori. Selanjutnya, basis data harus menyusun atau mengelompokkannya secara khusus sebelum mengembalikannya ke klien.
# Menyesuaikan Aurora MySQL dengan wawasan proaktif Amazon DevOps Guru
Wawasan proaktif DevOps Guru mendeteksi kondisi bermasalah yang diketahui pada klaster DB Aurora MySQL sebelum masalah tersebut terjadi. DevOps Guru dapat melakukan hal berikut:
+ Mencegah banyak masalah umum pada basis data dengan memeriksa silang konfigurasi basis data terhadap pengaturan umum yang direkomendasikan.
+ Memberi tahu Anda tentang masalah kritis dalam armada yang, jika dibiarkan tanpa diperiksa, dapat menyebabkan masalah yang lebih besar di kemudian hari.
+ Memberi tahu Anda tentang masalah yang baru ditemukan.
Setiap wawasan proaktif berisi analisis penyebab masalah dan rekomendasi untuk tindakan korektif.
**Topics**
+ [Panjang daftar riwayat InnoDB meningkat secara signifikan](proactive-insights.history-list.md)
+ [Basis data membuat tabel sementara pada disk](proactive-insights.temp-tables.md)
# Panjang daftar riwayat InnoDB meningkat secara signifikan
Mulai dari*date*, daftar riwayat Anda untuk perubahan baris meningkat secara signifikan, hingga *length* aktif*db-instance*. Peningkatan ini memengaruhi performa penonaktifan kueri dan basis data.
**Topics**
+ [Versi mesin yang didukung](#proactive-insights.history-list.context.supported)
+ [Konteks](#proactive-insights.history-list.context)
+ [Kemungkinan penyebab masalah ini](#proactive-insights.history-list.causes)
+ [Tindakan](#proactive-insights.history-list.actions)
+ [Metrik terkait](#proactive-insights.history-list.metrics)
## Versi mesin yang didukung
Informasi wawasan ini didukung untuk semua versi Aurora MySQL.
## Konteks
Sistem transaksi InnoDB mempertahankan kontrol konkurensi multiversi (MVCC). Ketika baris diubah, versi pra-modifikasi dari data yang diubah disimpan sebagai catatan undo dalam log undo. Setiap data undo memiliki referensi ke data redo sebelumnya, yang membentuk daftar tertaut.
Daftar riwayat InnoDB adalah daftar global log undo untuk transaksi yang dilakukan. MySQL menggunakan daftar riwayat untuk membersihkan data dan halaman log saat transaksi tidak lagi memerlukan riwayat. Panjang daftar riwayat adalah jumlah total log undo yang berisi perubahan dalam daftar riwayat. Setiap log berisi satu atau beberapa modifikasi. Jika panjang daftar riwayat InnoDB bertambah terlalu besar, yang menunjukkan sejumlah besar versi baris lama, kueri dan penonaktifan basis data menjadi lebih lambat.
## Kemungkinan penyebab masalah ini
Penyebab umum dari daftar riwayat panjang meliputi:
+ Transaksi yang berjalan lama, baik baca atau tulis
+ Beban tulis yang berat
## Tindakan
Kami merekomendasikan tindakan yang berbeda bergantung pada penyebab wawasan Anda.
**Topics**
+ [Jangan memulai operasi apa pun yang melibatkan penonaktifan basis data hingga daftar riwayat InnoDB berkurang](#proactive-insights.history-list.actions.no-shutdown)
+ [Mengidentifikasi dan mengakhiri transaksi yang berjalan lama](#proactive-insights.history-list.actions.long-txn)
+ [Mengidentifikasi host teratas dan pengguna teratas dengan menggunakan Wawasan Performa.](#proactive-insights.history-list.actions.top-PI)
### Jangan memulai operasi apa pun yang melibatkan penonaktifan basis data hingga daftar riwayat InnoDB berkurang
Karena daftar riwayat InnoDB yang panjang memperlambat penonaktifan basis data, kurangi ukuran daftar sebelum memulai operasi yang melibatkan penonaktifan basis data. Operasi ini meliputi peningkatan basis data versi utama.
### Mengidentifikasi dan mengakhiri transaksi yang berjalan lama
Anda dapat menemukan transaksi yang berjalan lama dengan mengueri `information_schema.innodb_trx`.
**catatan**
Pastikan juga untuk mencari transaksi jangka panjang pada replika baca.
**Untuk mengidentifikasi dan mengakhiri transaksi yang berjalan lama**
1. Di klien SQL Anda, jalankan kueri berikut:
```
SELECT a.trx_id,
a.trx_state,
a.trx_started,
TIMESTAMPDIFF(SECOND,a.trx_started, now()) as "Seconds Transaction Has Been Open",
a.trx_rows_modified,
b.USER,
b.host,
b.db,
b.command,
b.time,
b.state
FROM information_schema.innodb_trx a,
information_schema.processlist b
WHERE a.trx_mysql_thread_id=b.id
AND TIMESTAMPDIFF(SECOND,a.trx_started, now()) > 10
ORDER BY trx_started
```
1. Akhiri setiap transaksi yang berjalan lama dengan prosedur [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill) yang disimpan.
### Mengidentifikasi host teratas dan pengguna teratas dengan menggunakan Wawasan Performa.
Optimalkan transaksi agar sejumlah besar baris yang dimodifikasi segera dilakukan.
## Metrik terkait
Metrik berikut terkait dengan wawasan ini:
+ `trx_rseg_history_len`— Metrik penghitung ini dapat dilihat di Performance Insights, serta tabel. `INFORMATION_SCHEMA.INNODB_METRICS` Untuk informasi selengkapnya, lihat tabel [metrik InnoDB INFORMATION\$1SCHEMA](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-metrics-table.html) dalam dokumentasi MySQL.
+ `RollbackSegmentHistoryListLength`— CloudWatch Metrik Amazon ini mengukur log pembatalan yang mencatat transaksi yang dilakukan dengan catatan yang ditandai hapus. Catatan ini dijadwalkan untuk diproses oleh operasi purge InnoDB. Metrik `trx_rseg_history_len` memiliki nilai yang sama dengan`RollbackSegmentHistoryListLength`.
+ `PurgeBoundary`— Nomor transaksi yang memungkinkan pembersihan InnoDB. Jika CloudWatch metrik ini tidak maju untuk jangka waktu yang lama, ini merupakan indikasi yang baik bahwa pembersihan InnoDB diblokir oleh transaksi yang berjalan lama. Untuk menyelidiki, periksa transaksi aktif pada cluster DB MySQL Aurora Anda. Metrik ini hanya tersedia untuk Aurora MySQL versi 2.11 dan lebih tinggi, dan versi 3.08 dan lebih tinggi.
+ `PurgeFinishedPoint`— Nomor transaksi hingga pembersihan InnoDB dilakukan. CloudWatch Metrik ini dapat membantu Anda memeriksa seberapa cepat proses pembersihan InnoDB. Metrik ini hanya tersedia untuk Aurora MySQL versi 2.11 dan lebih tinggi, dan versi 3.08 dan lebih tinggi.
+ `TransactionAgeMaximum`— Usia transaksi berjalan aktif tertua. CloudWatch Metrik ini hanya tersedia untuk Aurora MySQL versi 3.08 dan lebih tinggi.
+ `TruncateFinishedPoint`— Nomor transaksi hingga pemotongan undo dilakukan. CloudWatch Metrik ini hanya tersedia untuk Aurora MySQL versi 2.11 dan lebih tinggi, dan versi 3.08 dan lebih tinggi.
Untuk informasi selengkapnya tentang CloudWatch metrik, lihat[Metrik tingkat instans untuk Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
# Basis data membuat tabel sementara pada disk
Penggunaan tabel sementara on-disk Anda baru-baru ini meningkat secara signifikan, hingga*percentage*. Database membuat sekitar tabel *number* sementara per detik. Ini dapat memengaruhi kinerja dan meningkatkan operasi disk*db-instance*.
**Topics**
+ [Versi mesin yang didukung](#proactive-insights.temp-tables.context.supported)
+ [Konteks](#proactive-insights.temp-tables.context)
+ [Kemungkinan penyebab masalah ini](#proactive-insights.temp-tables.causes)
+ [Tindakan](#proactive-insights.temp-tables.actions)
+ [Metrik terkait](#proactive-insights.temp-tables.metrics)
## Versi mesin yang didukung
Informasi wawasan ini didukung untuk semua versi Aurora MySQL.
## Konteks
Terkadang server MySQL perlu membuat tabel sementara internal saat memproses kueri. Aurora MySQL dapat menyimpan tabel sementara internal dalam memori, di mana ia dapat diproses TempTable oleh atau mesin penyimpanan MEMORY, atau disimpan pada disk oleh InnoDB. Untuk informasi selengkapnya, lihat [Penggunaan Tabel Sementara Internal di MySQL](https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html) di *Panduan Referensi MySQL*.
## Kemungkinan penyebab masalah ini
Peningkatan tabel sementara pada disk menunjukkan penggunaan kueri yang kompleks. Jika memori yang dikonfigurasi tidak cukup untuk menyimpan tabel sementara dalam memori, Aurora MySQL akan membuat tabel pada disk. Hal ini dapat memengaruhi performa dan meningkatkan operasi disk.
## Tindakan
Kami merekomendasikan tindakan yang berbeda bergantung pada penyebab wawasan Anda.
+ Untuk Aurora MySQL versi 3, kami sarankan Anda menggunakan mesin penyimpanan. TempTable
+ Optimalkan kueri Anda untuk menampilkan lebih sedikit data dengan memilih kolom yang diperlukan saja.
Jika Anda mengaktifkan Skema Performa dengan semua `statement` instrumen diaktifkan dan waktunya diatur, Anda dapat mengueri `SYS.statements_with_temp_tables` untuk mengambil daftar kueri yang menggunakan tabel sementara. Untuk informasi selengkapnya, lihat [Prerequisites for Using the sys Schema](https://dev.mysql.com/doc/refman/8.0/en/sys-schema-prerequisites.html) dalam dokumentasi MySQL.
+ Pertimbangkan untuk mengindeks kolom yang digunakan dalam operasi pengurutan dan pengelompokan.
+ Tulis ulang kueri Anda untuk menghindari kolom `BLOB` dan `TEXT`. Kolom ini selalu menggunakan disk.
+ Setel parameter basis data berikut: `tmp_table_size` dan`max_heap_table_size`.
Nilai default untuk parameter ini adalah 16 MiB. Saat menggunakan mesin penyimpanan MEMORY untuk tabel sementara dalam memori, ukuran maksimumnya ditentukan oleh nilai `tmp_table_size` atau `max_heap_table_size`, mana yang lebih kecil. Jika ukuran maksimum ini tercapai, MySQL secara otomatis mengubah tabel sementara internal dalam memori ke tabel sementara internal pada disk InnoDB. Untuk informasi selengkapnya, lihat [Menggunakan mesin TempTable penyimpanan di Amazon RDS for MySQL dan Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
**catatan**
Jika tabel MEMORY dibuat secara eksplisit dengan CREATE TABLE, hanya variabel `max_heap_table_size` yang menentukan seberapa besar tabel bisa berkembang. Konversi ke format pada disk juga tidak terjadi.
## Metrik terkait
Metrik Wawasan Performa berikut terkait dengan wawasan ini:
+ Created\$1tmp\$1disk\$1tables
+ Created\$1tmp\$1tables
Untuk informasi selengkapnya, lihat [Created\$1tmp\$1disk\$1tables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Created_tmp_disk_tables) dalam dokumentasi MySQL.