Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Memecahkan masalah beban kerja untuk database Aurora My SQL
Beban kerja database dapat dilihat sebagai membaca dan menulis. Dengan pemahaman tentang beban kerja database “normal”, Anda dapat menyetel kueri dan server database untuk memenuhi permintaan saat berubah. Ada sejumlah alasan berbeda mengapa kinerja dapat berubah, jadi langkah pertama adalah memahami apa yang telah berubah.
-
Apakah ada peningkatan versi mayor atau minor?
Peningkatan versi utama mencakup perubahan pada kode mesin, terutama di pengoptimal, yang dapat mengubah rencana eksekusi kueri. Saat memutakhirkan versi basis data, terutama versi utama, sangat penting bagi Anda untuk menganalisis beban kerja database dan menyetelnya. Tuning dapat melibatkan mengoptimalkan dan menulis ulang kueri, atau menambahkan dan memperbarui pengaturan parameter, tergantung pada hasil pengujian. Memahami apa yang menyebabkan dampak akan memungkinkan Anda untuk mulai fokus pada area spesifik itu.
Untuk informasi selengkapnya, lihat Apa yang baru di My SQL 8.0
dan Server serta variabel status dan opsi ditambahkan, tidak digunakan lagi, atau dihapus di My SQL 8.0 dalam dokumentasi Saya, dan. SQL Membandingkan Aurora SQL Versi saya 2 dan Aurora Versi saya 3 SQL -
Apakah ada peningkatan data yang sedang diproses (jumlah baris)?
-
Apakah ada lebih banyak kueri yang berjalan secara bersamaan?
-
Apakah ada perubahan skema atau database?
-
Apakah ada cacat atau perbaikan kode?
Daftar Isi
Metrik host instance
Pantau metrik host instans sepertiCPU, memori, dan aktivitas jaringan untuk membantu memahami apakah telah terjadi perubahan beban kerja. Ada dua konsep utama untuk memahami perubahan beban kerja:
-
Pemanfaatan — Penggunaan perangkat, seperti CPU atau disk. Ini bisa berbasis waktu atau berbasis kapasitas.
-
Berbasis waktu — Jumlah waktu sumber daya sibuk selama periode pengamatan tertentu.
-
Berbasis kapasitas — Jumlah throughput yang dapat diberikan oleh sistem atau komponen, sebagai persentase dari kapasitasnya.
-
-
Saturasi — Sejauh mana lebih banyak pekerjaan dibutuhkan dari sumber daya daripada yang dapat diproses. Ketika penggunaan berbasis kapasitas mencapai 100%, pekerjaan ekstra tidak dapat diproses dan harus antri.
CPUpenggunaan
Anda dapat menggunakan alat berikut untuk mengidentifikasi CPU penggunaan dan saturasi:
-
CloudWatch menyediakan
CPUUtilization
metrik. Jika ini mencapai 100%, maka instance jenuh. Namun, CloudWatch metrik dirata-ratakan lebih dari 1 menit, dan tidak memiliki perincian.Untuk informasi selengkapnya tentang CloudWatch metrik, lihatMetrik tingkat instans untuk Amazon Aurora.
-
Enhanced Monitoring menyediakan metrik yang dikembalikan oleh
top
perintah sistem operasi. Ini menunjukkan rata-rata beban dan CPU status berikut, dengan granularitas 1 detik:-
Idle (%)
= Waktu idle -
IRQ (%)
= Perangkat lunak menyela -
Nice (%)
= Waktu yang tepat untuk proses dengan prioritas yang baik. -
Steal (%)
= Waktu yang dihabiskan untuk melayani penyewa lain (terkait virtualisasi) -
System (%)
= Waktu sistem -
User (%)
= Waktu pengguna -
Wait (%)
= I/O tunggu
Untuk informasi selengkapnya tentang metrik Pemantauan yang Ditingkatkan, lihatMetrik OS untuk Aurora.
-
Penggunaan memori
Jika sistem berada di bawah tekanan memori, dan konsumsi sumber daya mencapai saturasi, Anda harus mengamati pemindaian halaman, paging, pertukaran, dan kesalahan tingkat tinggi. out-of-memory
Anda dapat menggunakan alat-alat berikut untuk mengidentifikasi penggunaan memori dan saturasi:
CloudWatch menyediakan FreeableMemory
metrik, yang menunjukkan berapa banyak memori yang dapat direklamasi dengan membilas beberapa cache OS dan memori bebas saat ini.
Untuk informasi selengkapnya tentang CloudWatch metrik, lihatMetrik tingkat instans untuk Amazon Aurora.
Enhanced Monitoring menyediakan metrik berikut yang dapat membantu Anda mengidentifikasi masalah penggunaan memori:
-
Buffers (KB)
— Jumlah memori yang digunakan untuk buffering permintaan I/O sebelum menulis ke perangkat penyimpanan, dalam kilobyte. -
Cached (KB)
— Jumlah memori yang digunakan untuk caching file system berbasis I/O. -
Free (KB)
— Jumlah memori yang tidak ditetapkan, dalam kilobyte. -
Swap
— Cached, Gratis, dan Total.
Misalnya, jika Anda melihat bahwa instans DB Anda menggunakan Swap
memori, maka jumlah total memori untuk beban kerja Anda lebih besar daripada instans Anda saat ini tersedia. Kami merekomendasikan untuk meningkatkan ukuran instans DB Anda atau menyetel beban kerja Anda untuk menggunakan lebih sedikit memori.
Untuk informasi selengkapnya tentang metrik Pemantauan yang Ditingkatkan, lihatMetrik OS untuk Aurora.
Untuk informasi lebih rinci tentang penggunaan Skema Kinerja dan sys
skema untuk menentukan koneksi dan komponen mana yang menggunakan memori, lihat. Memecahkan masalah penggunaan memori untuk database Aurora My SQL
Throughput jaringan
CloudWatch menyediakan metrik berikut untuk total throughput jaringan, semuanya rata-rata lebih dari 1 menit:
-
NetworkReceiveThroughput
— Jumlah throughput jaringan yang diterima dari klien oleh setiap instance di cluster Aurora DB. -
NetworkTransmitThroughput
— Jumlah throughput jaringan yang dikirim ke klien oleh setiap instance di cluster Aurora DB. -
NetworkThroughput
— Jumlah throughput jaringan yang diterima dari dan ditransmisikan ke klien oleh setiap instance di cluster Aurora DB. -
StorageNetworkReceiveThroughput
— Jumlah throughput jaringan yang diterima dari subsistem penyimpanan Aurora oleh setiap instance di cluster DB. -
StorageNetworkTransmitThroughput
— Jumlah throughput jaringan yang dikirim ke subsistem penyimpanan Aurora oleh setiap instance di cluster Aurora DB. -
StorageNetworkThroughput
— Jumlah throughput jaringan yang diterima dari dan dikirim ke subsistem penyimpanan Aurora oleh setiap instance di cluster Aurora DB.
Untuk informasi selengkapnya tentang CloudWatch metrik, lihatMetrik tingkat instans untuk Amazon Aurora.
Enhanced Monitoring menyediakan grafik yang network
diterima (RX) dan ditransmisikan (TX), dengan granularitas hingga 1 detik.
Untuk informasi selengkapnya tentang metrik Pemantauan yang Ditingkatkan, lihatMetrik OS untuk Aurora.
Metrik basis data
Periksa CloudWatch metrik berikut untuk perubahan beban kerja:
-
BlockedTransactions
— Rata-rata jumlah transaksi dalam database yang diblokir per detik. -
BufferCacheHitRatio
— Persentase permintaan yang dilayani oleh cache buffer. -
CommitThroughput
— Jumlah rata-rata operasi komit per detik. -
DatabaseConnections
— Jumlah koneksi jaringan klien ke instance database. -
Deadlocks
— Jumlah rata-rata kebuntuan dalam database per detik. -
DMLThroughput
— Jumlah rata-rata sisipan, pembaruan, dan penghapusan per detik. -
ResultSetCacheHitRatio
— Persentase permintaan yang dilayani oleh cache kueri. -
RollbackSegmentHistoryListLength
— Log batalkan yang mencatat transaksi yang dilakukan dengan catatan yang ditandai hapus. -
RowLockTime
— Total waktu yang dihabiskan untuk memperoleh kunci baris untuk tabel InnoDB. -
SelectThroughput
— Jumlah rata-rata kueri pilih per detik.
Untuk informasi selengkapnya tentang CloudWatch metrik, lihatMetrik tingkat instans untuk Amazon Aurora.
Pertimbangkan pertanyaan-pertanyaan berikut saat memeriksa beban kerja:
-
Apakah ada perubahan terbaru di kelas instans DB, misalnya mengurangi ukuran instance dari 8xlarge menjadi 4xlarge, atau mengubah dari db.r5 ke db.r6?
-
Bisakah Anda membuat klon dan mereproduksi masalah, atau apakah itu hanya terjadi pada satu contoh itu?
-
Apakah ada kelelahan sumber daya server, tinggi CPU atau kelelahan memori? Jika ya, ini bisa berarti bahwa perangkat keras tambahan diperlukan.
-
Apakah satu atau lebih pertanyaan membutuhkan waktu lebih lama?
-
Apakah perubahan disebabkan oleh peningkatan, terutama peningkatan versi utama? Jika ya, bandingkan metrik sebelum dan sesudah peningkatan.
-
Apakah ada perubahan dalam jumlah instans DB pembaca?
-
Sudahkah Anda mengaktifkan pencatatan umum, audit, atau biner? Untuk informasi selengkapnya, lihat Logging untuk database MySQL Aurora.
-
Apakah Anda mengaktifkan, menonaktifkan, atau mengubah penggunaan replikasi log biner (binlog) Anda?
-
Apakah ada transaksi jangka panjang yang memegang sejumlah besar kunci baris? Periksa panjang daftar riwayat InnoDB (HLL) untuk indikasi transaksi yang berjalan lama.
Untuk informasi lebih lanjut, lihat Panjang daftar riwayat InnoDB meningkat secara signifikan dan posting blog Mengapa SELECT kueri saya berjalan lambat di cluster Amazon Aurora My SQL DB saya
? . -
Jika besar HLL disebabkan oleh transaksi tulis, itu berarti
UNDO
log terakumulasi (tidak dibersihkan secara teratur). Dalam transaksi tulis besar, akumulasi ini dapat tumbuh dengan cepat. Di MySQL,UNDO
disimpan di SYSTEMtablespace. SYSTEM
Ruang meja tidak dapat menyusut.UNDO
Log dapat menyebabkanSYSTEM
tablespace tumbuh menjadi beberapa GB, atau bahkan TB. Setelah pembersihan, lepaskan ruang yang dialokasikan dengan mengambil cadangan logis (dump) data, lalu impor dump ke instance DB baru. -
Jika besar HLL disebabkan oleh transaksi baca (kueri yang berjalan lama), itu bisa berarti bahwa kueri menggunakan sejumlah besar ruang sementara. Lepaskan ruang sementara dengan me-reboot. Periksa metrik DB Performance Insights untuk setiap perubahan di
Temp
bagian, seperti.created_tmp_tables
Untuk informasi selengkapnya, lihat Memantau beban DB dengan Performance Insights di Amazon Aurora.
-
-
Bisakah Anda membagi transaksi yang berjalan lama menjadi transaksi yang lebih kecil yang memodifikasi lebih sedikit baris?
-
Apakah ada perubahan dalam transaksi yang diblokir atau peningkatan kebuntuan? Periksa metrik DB Performance Insights untuk setiap perubahan variabel status di
Locks
bagian, sepertiinnodb_row_lock_time
,innodb_row_lock_waits
dan.innodb_dead_locks
Gunakan interval 1 menit atau 5 menit. -
Apakah ada peningkatan acara menunggu? Periksa Performance Insights acara tunggu dan jenis tunggu menggunakan interval 1 menit atau 5 menit. Analisis peristiwa tunggu teratas dan lihat apakah mereka berkorelasi dengan perubahan beban kerja atau pertentangan database. Misalnya,
buf_pool mutex
menunjukkan pertentangan kumpulan buffer. Untuk informasi selengkapnya, lihat Menyesuaikan Aurora MySQL dengan peristiwa tunggu.