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 MySQL
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 MySQL
8.0 dan Server dan variabel status serta opsi ditambahkan, tidak digunakan lagi, atau dihapus di MySQL 8.0 dalam dokumentasi MySQL, dan. Perbandingan Aurora MySQL versi 2 dan Aurora MySQL versi 3 -
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 seperti CPU, 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.
Penggunaan CPU
Anda dapat menggunakan alat berikut untuk mengidentifikasi penggunaan dan saturasi CPU:
-
CloudWatch menyediakan
CPUUtilizationmetrik. 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
topperintah sistem operasi. Ini menunjukkan rata-rata beban dan status CPU berikut, dengan perincian 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 berikut untuk mengidentifikasi penggunaan dan saturasi memori:
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 MySQL
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, CPU tinggi 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 kueri SELECT saya berjalan lambat di cluster DB Amazon Aurora MySQL saya
? . -
Jika HLL besar disebabkan oleh transaksi tulis, itu berarti
UNDOlog terakumulasi (tidak dibersihkan secara teratur). Dalam transaksi tulis besar, akumulasi ini dapat tumbuh dengan cepat. Di MySQLUNDO, disimpan di tablespace SYSTEM.SYSTEMRuang meja tidak dapat menyusut.UNDOLog dapat menyebabkanSYSTEMtablespace 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 HLL besar 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
Tempbagian, seperti.created_tmp_tablesUntuk informasi selengkapnya, lihat Memantau muatan DB dengan Wawasan Performa di Amazon Aurora.
-
-
Bisakah Anda membagi transaksi yang berjalan lama menjadi 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
Locksbagian, sepertiinnodb_row_lock_time,innodb_row_lock_waitsdan.innodb_dead_locksGunakan 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 mutexmenunjukkan pertentangan kumpulan buffer. Untuk informasi selengkapnya, lihat Menyesuaikan Aurora MySQL dengan peristiwa tunggu.
Memecahkan masalah penggunaan memori untuk database Aurora MySQL
Sementara CloudWatch, Enhanced Monitoring, dan Performance Insights memberikan gambaran yang baik tentang penggunaan memori di tingkat sistem operasi, seperti berapa banyak memori yang digunakan oleh proses database, mereka tidak memungkinkan Anda untuk memecah koneksi atau komponen apa di dalam mesin yang mungkin menyebabkan penggunaan memori ini.
Untuk memecahkan masalah ini, Anda dapat menggunakan skema kinerja dan skema. sys Di Aurora MySQL versi 3, instrumentasi memori diaktifkan secara default saat Skema Kinerja diaktifkan. Di Aurora MySQL versi 2, hanya instrumentasi memori untuk penggunaan memori Skema Kinerja yang diaktifkan secara default. Untuk informasi tentang tabel yang tersedia di Skema Kinerja untuk melacak penggunaan memori dan mengaktifkan instrumentasi memori Skema Kinerja, lihat Tabel ringkasan memori dalam
Meskipun informasi terperinci tersedia di Skema Kinerja untuk melacak penggunaan memori saat ini, skema sys MySQL
Dalam sys skema, tampilan berikut tersedia untuk melacak penggunaan memori dengan koneksi, komponen, dan kueri.
| Tayang | Deskripsi |
|---|---|
|
Memberikan informasi tentang penggunaan memori mesin oleh host. Ini dapat berguna untuk mengidentifikasi server aplikasi atau host klien mana yang menghabiskan memori. |
|
|
Memberikan informasi tentang penggunaan memori mesin dengan ID utas. ID thread di MySQL dapat berupa koneksi klien atau thread latar belakang. Anda dapat memetakan ID thread ke ID koneksi MySQL dengan menggunakan tampilan sys.processlist atau tabel performance_schema.threads |
|
|
Memberikan informasi tentang penggunaan memori mesin oleh pengguna. Ini dapat berguna untuk mengidentifikasi akun pengguna atau klien mana yang menghabiskan memori. |
|
|
Memberikan informasi tentang penggunaan memori mesin oleh komponen mesin. Ini dapat berguna untuk mengidentifikasi penggunaan memori secara global oleh buffer atau komponen mesin. Misalnya, Anda mungkin melihat |
|
|
Memberikan gambaran umum total penggunaan memori yang dilacak di mesin database. |
Di Aurora MySQL versi 3.05 dan lebih tinggi, Anda juga dapat melacak penggunaan memori maksimum dengan intisari pernyataan di tabel ringkasan pernyataan Skema Kinerja.MAX_TOTAL_MEMORYKolom dapat membantu Anda mengidentifikasi memori maksimum yang digunakan oleh intisari kueri sejak statistik terakhir disetel ulang, atau karena instance database dimulai ulang. Ini dapat berguna dalam mengidentifikasi kueri tertentu yang mungkin menghabiskan banyak memori.
catatan
Skema dan sys skema Kinerja menunjukkan kepada Anda penggunaan memori saat ini di server, dan tanda air tinggi untuk memori yang dikonsumsi per koneksi dan komponen mesin. Karena Skema Kinerja dipertahankan dalam memori, informasi diatur ulang ketika instans DB dimulai ulang. Untuk mempertahankan riwayat dari waktu ke waktu, sebaiknya Anda mengonfigurasi pengambilan dan penyimpanan data ini di luar Skema Kinerja.
Contoh 1: Penggunaan memori tinggi terus menerus
Melihat FreeableMemory secara global CloudWatch, kita dapat melihat bahwa penggunaan memori sangat meningkat pada 2024-03-26 02:59 UTC.
Ini tidak memberi tahu kita keseluruhan gambar. Untuk menentukan komponen mana yang paling banyak menggunakan memori, Anda dapat masuk ke database dan melihatnyasys.memory_global_by_current_bytes. Tabel ini berisi daftar peristiwa memori yang dilacak MySQL, bersama dengan informasi tentang alokasi memori per peristiwa. Setiap peristiwa pelacakan memori dimulai denganmemory/%, diikuti oleh informasi lain tentang komponen/fitur mesin mana yang terkait dengan peristiwa tersebut.
Misalnya, memory/performance_schema/% adalah untuk peristiwa memori yang terkait dengan Skema Kinerja, memory/innodb/% adalah untuk InnoDB, dan sebagainya. Untuk informasi selengkapnya tentang konvensi penamaan acara, lihat konvensi penamaan instrumen Skema Kinerja dalam dokumentasi
Dari kueri berikut, kita dapat menemukan kemungkinan pelakunya berdasarkancurrent_alloc, tetapi kita juga dapat melihat banyak memory/performance_schema/% peristiwa.
mysql> SELECT * FROM sys.memory_global_by_current_bytes LIMIT 10; +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/sql/Prepared_statement::main_mem_root | 512817 | 4.91 GiB | 10.04 KiB | 512823 | 4.91 GiB | 10.04 KiB | | memory/performance_schema/prepared_statements_instances | 252 | 488.25 MiB | 1.94 MiB | 252 | 488.25 MiB | 1.94 MiB | | memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB | | memory/performance_schema/events_errors_summary_by_thread_by_error | 1028 | 52.27 MiB | 52.06 KiB | 1028 | 52.27 MiB | 52.06 KiB | | memory/performance_schema/events_statements_summary_by_thread_by_event_name | 4 | 47.25 MiB | 11.81 MiB | 4 | 47.25 MiB | 11.81 MiB | | memory/performance_schema/events_statements_summary_by_digest | 1 | 40.28 MiB | 40.28 MiB | 1 | 40.28 MiB | 40.28 MiB | | memory/performance_schema/memory_summary_by_thread_by_event_name | 4 | 31.64 MiB | 7.91 MiB | 4 | 31.64 MiB | 7.91 MiB | | memory/innodb/memory | 15227 | 27.44 MiB | 1.85 KiB | 20619 | 33.33 MiB | 1.66 KiB | | memory/sql/String::value | 74411 | 21.85 MiB | 307 bytes | 76867 | 25.54 MiB | 348 bytes | | memory/sql/TABLE | 8381 | 21.03 MiB | 2.57 KiB | 8381 | 21.03 MiB | 2.57 KiB | +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 10 rows in set (0.02 sec)
Kami menyebutkan sebelumnya bahwa Skema Kinerja disimpan dalam memori, yang berarti bahwa itu juga dilacak dalam instrumentasi performance_schema memori.
catatan
Jika Anda menemukan bahwa Skema Kinerja menggunakan banyak memori, dan ingin membatasi penggunaan memorinya, Anda dapat menyetel parameter database berdasarkan kebutuhan Anda. Untuk informasi selengkapnya, lihat Model alokasi memori Skema Kinerja dalam
Untuk keterbacaan, Anda dapat menjalankan kembali kueri yang sama tetapi mengecualikan peristiwa Skema Kinerja. Outputnya menunjukkan hal berikut:
-
Konsumen memori utama adalah
memory/sql/Prepared_statement::main_mem_root. -
current_allocKolom memberitahu kita bahwa MySQL memiliki 4,91 GiB saat ini dialokasikan untuk acara ini. -
Ini
high_alloc columnmemberi tahu kita bahwa 4,91 GiB adalah tandacurrent_allocair tinggi sejak statistik terakhir diatur ulang atau sejak server dimulai ulang. Ini berartimemory/sql/Prepared_statement::main_mem_rootitu pada nilai tertinggi.
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name NOT LIKE 'memory/performance_schema/%' LIMIT 10; +-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/sql/Prepared_statement::main_mem_root | 512817 | 4.91 GiB | 10.04 KiB | 512823 | 4.91 GiB | 10.04 KiB | | memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB | | memory/innodb/memory | 17096 | 31.68 MiB | 1.90 KiB | 22498 | 37.60 MiB | 1.71 KiB | | memory/sql/String::value | 122277 | 27.94 MiB | 239 bytes | 124699 | 29.47 MiB | 247 bytes | | memory/sql/TABLE | 9927 | 24.67 MiB | 2.55 KiB | 9929 | 24.68 MiB | 2.55 KiB | | memory/innodb/lock0lock | 8888 | 19.71 MiB | 2.27 KiB | 8888 | 19.71 MiB | 2.27 KiB | | memory/sql/Prepared_statement::infrastructure | 257623 | 16.24 MiB | 66 bytes | 257631 | 16.24 MiB | 66 bytes | | memory/mysys/KEY_CACHE | 3 | 16.00 MiB | 5.33 MiB | 3 | 16.00 MiB | 5.33 MiB | | memory/innodb/sync0arr | 3 | 7.03 MiB | 2.34 MiB | 3 | 7.03 MiB | 2.34 MiB | | memory/sql/THD::main_mem_root | 815 | 6.56 MiB | 8.24 KiB | 849 | 7.19 MiB | 8.67 KiB | +-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 10 rows in set (0.06 sec)
Dari nama acara, kita dapat mengetahui bahwa memori ini digunakan untuk pernyataan yang disiapkan. Jika Anda ingin melihat koneksi mana yang menggunakan memori ini, Anda dapat memeriksa memory_by_thread_by_current_bytes
Dalam contoh berikut, setiap sambungan memiliki sekitar 7 MiB yang dialokasikan, dengan tanda air tinggi sekitar 6,29 MiB (). current_max_alloc Ini masuk akal, karena contohnya menggunakan sysbench dengan 80 tabel dan 800 koneksi dengan pernyataan yang disiapkan. Jika Anda ingin mengurangi penggunaan memori dalam skenario ini, Anda dapat mengoptimalkan penggunaan aplikasi Anda dari pernyataan yang disiapkan untuk mengurangi konsumsi memori.
mysql> SELECT * FROM sys.memory_by_thread_by_current_bytes; +-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+ | thread_id | user | current_count_used | current_allocated | current_avg_alloc | current_max_alloc | total_allocated | +-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+ | 46 | rdsadmin@localhost | 405 | 8.47 MiB | 21.42 KiB | 8.00 MiB | 155.86 MiB | | 61 | reinvent@10.0.4.4 | 1749 | 6.72 MiB | 3.93 KiB | 6.29 MiB | 14.24 MiB | | 101 | reinvent@10.0.4.4 | 1845 | 6.71 MiB | 3.72 KiB | 6.29 MiB | 14.50 MiB | | 55 | reinvent@10.0.4.4 | 1674 | 6.68 MiB | 4.09 KiB | 6.29 MiB | 14.13 MiB | | 57 | reinvent@10.0.4.4 | 1416 | 6.66 MiB | 4.82 KiB | 6.29 MiB | 13.52 MiB | | 112 | reinvent@10.0.4.4 | 1759 | 6.66 MiB | 3.88 KiB | 6.29 MiB | 14.17 MiB | | 66 | reinvent@10.0.4.4 | 1428 | 6.64 MiB | 4.76 KiB | 6.29 MiB | 13.47 MiB | | 75 | reinvent@10.0.4.4 | 1389 | 6.62 MiB | 4.88 KiB | 6.29 MiB | 13.40 MiB | | 116 | reinvent@10.0.4.4 | 1333 | 6.61 MiB | 5.08 KiB | 6.29 MiB | 13.21 MiB | | 90 | reinvent@10.0.4.4 | 1448 | 6.59 MiB | 4.66 KiB | 6.29 MiB | 13.58 MiB | | 98 | reinvent@10.0.4.4 | 1440 | 6.57 MiB | 4.67 KiB | 6.29 MiB | 13.52 MiB | | 94 | reinvent@10.0.4.4 | 1433 | 6.57 MiB | 4.69 KiB | 6.29 MiB | 13.49 MiB | | 62 | reinvent@10.0.4.4 | 1323 | 6.55 MiB | 5.07 KiB | 6.29 MiB | 13.48 MiB | | 87 | reinvent@10.0.4.4 | 1323 | 6.55 MiB | 5.07 KiB | 6.29 MiB | 13.25 MiB | | 99 | reinvent@10.0.4.4 | 1346 | 6.54 MiB | 4.98 KiB | 6.29 MiB | 13.24 MiB | | 105 | reinvent@10.0.4.4 | 1347 | 6.54 MiB | 4.97 KiB | 6.29 MiB | 13.34 MiB | | 73 | reinvent@10.0.4.4 | 1335 | 6.54 MiB | 5.02 KiB | 6.29 MiB | 13.23 MiB | | 54 | reinvent@10.0.4.4 | 1510 | 6.53 MiB | 4.43 KiB | 6.29 MiB | 13.49 MiB | . . . . . . | 812 | reinvent@10.0.4.4 | 1259 | 6.38 MiB | 5.19 KiB | 6.29 MiB | 13.05 MiB | | 214 | reinvent@10.0.4.4 | 1279 | 6.38 MiB | 5.10 KiB | 6.29 MiB | 12.90 MiB | | 325 | reinvent@10.0.4.4 | 1254 | 6.38 MiB | 5.21 KiB | 6.29 MiB | 12.99 MiB | | 705 | reinvent@10.0.4.4 | 1273 | 6.37 MiB | 5.13 KiB | 6.29 MiB | 13.03 MiB | | 530 | reinvent@10.0.4.4 | 1268 | 6.37 MiB | 5.15 KiB | 6.29 MiB | 12.92 MiB | | 307 | reinvent@10.0.4.4 | 1263 | 6.37 MiB | 5.17 KiB | 6.29 MiB | 12.87 MiB | | 738 | reinvent@10.0.4.4 | 1260 | 6.37 MiB | 5.18 KiB | 6.29 MiB | 13.00 MiB | | 819 | reinvent@10.0.4.4 | 1252 | 6.37 MiB | 5.21 KiB | 6.29 MiB | 13.01 MiB | | 31 | innodb/srv_purge_thread | 17810 | 3.14 MiB | 184 bytes | 2.40 MiB | 205.69 MiB | | 38 | rdsadmin@localhost | 599 | 1.76 MiB | 3.01 KiB | 1.00 MiB | 25.58 MiB | | 1 | sql/main | 3756 | 1.32 MiB | 367 bytes | 355.78 KiB | 6.19 MiB | | 854 | rdsadmin@localhost | 46 | 1.08 MiB | 23.98 KiB | 1.00 MiB | 5.10 MiB | | 30 | innodb/clone_gtid_thread | 1596 | 573.14 KiB | 367 bytes | 254.91 KiB | 970.69 KiB | | 40 | rdsadmin@localhost | 235 | 245.19 KiB | 1.04 KiB | 128.88 KiB | 808.64 KiB | | 853 | rdsadmin@localhost | 96 | 94.63 KiB | 1009 bytes | 29.73 KiB | 422.45 KiB | | 36 | rdsadmin@localhost | 33 | 36.29 KiB | 1.10 KiB | 16.08 KiB | 74.15 MiB | | 33 | sql/event_scheduler | 3 | 16.27 KiB | 5.42 KiB | 16.04 KiB | 16.27 KiB | | 35 | sql/compress_gtid_table | 8 | 14.20 KiB | 1.77 KiB | 8.05 KiB | 18.62 KiB | | 25 | innodb/fts_optimize_thread | 12 | 1.86 KiB | 158 bytes | 648 bytes | 1.98 KiB | | 23 | innodb/srv_master_thread | 11 | 1.23 KiB | 114 bytes | 361 bytes | 24.40 KiB | | 24 | innodb/dict_stats_thread | 11 | 1.23 KiB | 114 bytes | 361 bytes | 1.35 KiB | | 5 | innodb/io_read_thread | 1 | 144 bytes | 144 bytes | 144 bytes | 144 bytes | | 6 | innodb/io_read_thread | 1 | 144 bytes | 144 bytes | 144 bytes | 144 bytes | | 2 | sql/aws_oscar_log_level_monitor | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 4 | innodb/io_ibuf_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 7 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 8 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 9 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 10 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 11 | innodb/srv_lra_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 12 | innodb/srv_akp_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 18 | innodb/srv_lock_timeout_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 248 bytes | | 19 | innodb/srv_error_monitor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 20 | innodb/srv_monitor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 21 | innodb/buf_resize_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 22 | innodb/btr_search_sys_toggle_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 32 | innodb/dict_persist_metadata_table_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 34 | sql/signal_handler | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | +-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+ 831 rows in set (2.48 sec)
Seperti disebutkan sebelumnya, nilai thread ID (thd_id) di sini dapat merujuk ke thread latar belakang server atau koneksi database. Jika Anda ingin memetakan nilai ID thread ke ID koneksi database, Anda dapat menggunakan performance_schema.threads tabel atau sys.processlist tampilan, di conn_id mana ID koneksi.
mysql> SELECT thd_id,conn_id,user,db,command,state,time,last_wait FROM sys.processlist WHERE user='reinvent@10.0.4.4'; +--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+ | thd_id | conn_id | user | db | command | state | time | last_wait | +--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+ | 590 | 562 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | | 578 | 550 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle | | 579 | 551 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | | 580 | 552 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 581 | 553 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 582 | 554 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle | | 583 | 555 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle | | 584 | 556 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 585 | 557 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | | 586 | 558 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 587 | 559 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | . . . . . . | 323 | 295 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle | | 324 | 296 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 325 | 297 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | | 326 | 298 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 438 | 410 | reinvent@10.0.4.4 | sysbench | Execute | System lock | 0 | wait/lock/table/sql/handler | | 280 | 252 | reinvent@10.0.4.4 | sysbench | Sleep | starting | 0 | wait/io/socket/sql/client_connection | | 98 | 70 | reinvent@10.0.4.4 | sysbench | Query | freeing items | 0 | NULL | +--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+ 804 rows in set (5.51 sec)
Sekarang kita menghentikan sysbench beban kerja, yang menutup koneksi dan melepaskan memori. Memeriksa peristiwa lagi, kami dapat mengonfirmasi bahwa memori dilepaskan, tetapi high_alloc masih memberi tahu kami apa tanda air tinggi itu. high_allocKolom dapat sangat berguna dalam mengidentifikasi lonjakan singkat dalam penggunaan memori, di mana Anda mungkin tidak dapat segera mengidentifikasi penggunaancurrent_alloc, yang hanya menampilkan memori yang dialokasikan saat ini.
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/Prepared_statement::main_mem_root' LIMIT 10; +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/sql/Prepared_statement::main_mem_root | 17 | 253.80 KiB | 14.93 KiB | 512823 | 4.91 GiB | 10.04 KiB | +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 1 row in set (0.00 sec)
Jika Anda ingin mengatur ulanghigh_alloc, Anda dapat memotong tabel ringkasan performance_schema memori, tetapi ini mengatur ulang semua instrumentasi memori. Untuk informasi selengkapnya, lihat Karakteristik tabel umum Skema Kinerja
Dalam contoh berikut, kita dapat melihat high_alloc bahwa reset setelah pemotongan.
mysql> TRUNCATE `performance_schema`.`memory_summary_global_by_event_name`; Query OK, 0 rows affected (0.00 sec) mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/Prepared_statement::main_mem_root' LIMIT 10; +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/sql/Prepared_statement::main_mem_root | 17 | 253.80 KiB | 14.93 KiB | 17 | 253.80 KiB | 14.93 KiB | +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 1 row in set (0.00 sec)
Contoh 2: Lonjakan memori transien
Kejadian umum lainnya adalah lonjakan pendek dalam penggunaan memori pada server database. Ini bisa berupa penurunan periodik dalam memori yang dapat dibebaskan yang sulit dipecahkan masalah saat digunakan current_allocsys.memory_global_by_current_bytes, karena memori telah dibebaskan.
catatan
Jika statistik Skema Kinerja telah disetel ulang, atau instance database telah dimulai ulang, informasi ini tidak akan tersedia di sys atau p. erformance_schema Untuk menyimpan informasi ini, sebaiknya Anda mengonfigurasi pengumpulan metrik eksternal.
Grafik os.memory.free metrik berikut di Enhanced Monitoring menunjukkan lonjakan singkat 7 detik dalam penggunaan memori. Enhanced Monitoring memungkinkan Anda untuk memantau pada interval sesingkat 1 detik, yang sempurna untuk menangkap lonjakan sementara seperti ini.
Untuk membantu mendiagnosis penyebab penggunaan memori di sini, kita dapat menggunakan kombinasi tampilan ringkasan sys memori dan tabel ringkasan pernyataan Skema Kinerjahigh_alloc
Seperti yang diharapkan, karena penggunaan memori saat ini tidak tinggi, kami tidak dapat melihat pelanggar utama dalam tampilan sys skema di bawah. current_alloc
mysql> SELECT * FROM sys.memory_global_by_current_bytes LIMIT 10; +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB | | memory/innodb/os0event | 439372 | 60.34 MiB | 144 bytes | 439372 | 60.34 MiB | 144 bytes | | memory/performance_schema/events_statements_summary_by_digest | 1 | 40.28 MiB | 40.28 MiB | 1 | 40.28 MiB | 40.28 MiB | | memory/mysys/KEY_CACHE | 3 | 16.00 MiB | 5.33 MiB | 3 | 16.00 MiB | 5.33 MiB | | memory/performance_schema/events_statements_history_long | 1 | 14.34 MiB | 14.34 MiB | 1 | 14.34 MiB | 14.34 MiB | | memory/performance_schema/events_errors_summary_by_thread_by_error | 257 | 13.07 MiB | 52.06 KiB | 257 | 13.07 MiB | 52.06 KiB | | memory/performance_schema/events_statements_summary_by_thread_by_event_name | 1 | 11.81 MiB | 11.81 MiB | 1 | 11.81 MiB | 11.81 MiB | | memory/performance_schema/events_statements_summary_by_digest.digest_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB | | memory/performance_schema/events_statements_history_long.digest_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB | | memory/performance_schema/events_statements_history_long.sql_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB | +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 10 rows in set (0.01 sec)
Memperluas tampilan ke order byhigh_alloc, sekarang kita dapat melihat bahwa memory/temptable/physical_ram komponen tersebut adalah kandidat yang sangat baik di sini. Pada level tertinggi, ia mengkonsumsi 515,00 MiB.
Seperti namanya, memory/temptable/physical_ram instrumen penggunaan memori untuk mesin TEMP penyimpanan di MySQL, yang diperkenalkan di MySQL 8.0. Untuk informasi selengkapnya tentang cara MySQL menggunakan tabel sementara, lihat Penggunaan tabel sementara internal di MySQL dalam dokumentasi MySQL
catatan
Kami menggunakan sys.x$memory_global_by_current_bytes tampilan dalam contoh ini.
mysql> SELECT event_name, format_bytes(current_alloc) AS "currently allocated", sys.format_bytes(high_alloc) AS "high-water mark" FROM sys.x$memory_global_by_current_bytes ORDER BY high_alloc DESC LIMIT 10; +-----------------------------------------------------------------------------+---------------------+-----------------+ | event_name | currently allocated | high-water mark | +-----------------------------------------------------------------------------+---------------------+-----------------+ | memory/temptable/physical_ram | 4.00 MiB | 515.00 MiB | | memory/innodb/hash0hash | 79.07 MiB | 79.07 MiB | | memory/innodb/os0event | 63.95 MiB | 63.95 MiB | | memory/performance_schema/events_statements_summary_by_digest | 40.28 MiB | 40.28 MiB | | memory/mysys/KEY_CACHE | 16.00 MiB | 16.00 MiB | | memory/performance_schema/events_statements_history_long | 14.34 MiB | 14.34 MiB | | memory/performance_schema/events_errors_summary_by_thread_by_error | 13.07 MiB | 13.07 MiB | | memory/performance_schema/events_statements_summary_by_thread_by_event_name | 11.81 MiB | 11.81 MiB | | memory/performance_schema/events_statements_summary_by_digest.digest_text | 9.77 MiB | 9.77 MiB | | memory/performance_schema/events_statements_history_long.sql_text | 9.77 MiB | 9.77 MiB | +-----------------------------------------------------------------------------+---------------------+-----------------+ 10 rows in set (0.00 sec)
DiContoh 1: Penggunaan memori tinggi terus menerus, kami memeriksa penggunaan memori saat ini untuk setiap koneksi untuk menentukan koneksi mana yang bertanggung jawab untuk menggunakan memori yang dimaksud. Dalam contoh ini, memori sudah dibebaskan, jadi memeriksa penggunaan memori untuk koneksi saat ini tidak berguna.
Untuk menggali lebih dalam dan menemukan pernyataan yang menyinggung, pengguna, dan host, kami menggunakan Skema Kinerja. Skema Kinerja berisi beberapa tabel ringkasan pernyataan yang diiris oleh dimensi yang berbeda seperti nama acara, intisari pernyataan, host, utas, dan pengguna. Setiap tampilan akan memungkinkan Anda menggali lebih dalam di mana pernyataan tertentu dijalankan dan apa yang mereka lakukan. Bagian ini difokuskanMAX_TOTAL_MEMORY, tetapi Anda dapat menemukan informasi lebih lanjut tentang semua kolom yang tersedia dalam dokumentasi tabel ringkasan pernyataan Skema Kinerja
mysql> SHOW TABLES IN performance_schema LIKE 'events_statements_summary_%'; +------------------------------------------------------------+ | Tables_in_performance_schema (events_statements_summary_%) | +------------------------------------------------------------+ | events_statements_summary_by_account_by_event_name | | events_statements_summary_by_digest | | events_statements_summary_by_host_by_event_name | | events_statements_summary_by_program | | events_statements_summary_by_thread_by_event_name | | events_statements_summary_by_user_by_event_name | | events_statements_summary_global_by_event_name | +------------------------------------------------------------+ 7 rows in set (0.00 sec)
Pertama kita periksa events_statements_summary_by_digest untuk melihatMAX_TOTAL_MEMORY.
Dari sini kita dapat melihat yang berikut:
-
Kueri dengan intisari
20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4atampaknya menjadi kandidat yang baik untuk penggunaan memori ini.MAX_TOTAL_MEMORYItu adalah 537450710, yang cocok dengan tanda air tinggi yang kami lihat untuk acara tersebut.memory/temptable/physical_ramsys.x$memory_global_by_current_bytes -
Telah dijalankan empat kali (
COUNT_STAR), pertama pada 2024-03-26 04:08:34.943 256, dan terakhir pada 2024-03-26 04:43:06.998 310.
mysql> SELECT SCHEMA_NAME,DIGEST,COUNT_STAR,MAX_TOTAL_MEMORY,FIRST_SEEN,LAST_SEEN FROM performance_schema.events_statements_summary_by_digest ORDER BY MAX_TOTAL_MEMORY DESC LIMIT 5; +-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+ | SCHEMA_NAME | DIGEST | COUNT_STAR | MAX_TOTAL_MEMORY | FIRST_SEEN | LAST_SEEN | +-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+ | sysbench | 20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a | 4 | 537450710 | 2024-03-26 04:08:34.943256 | 2024-03-26 04:43:06.998310 | | NULL | f158282ea0313fefd0a4778f6e9b92fc7d1e839af59ebd8c5eea35e12732c45d | 4 | 3636413 | 2024-03-26 04:29:32.712348 | 2024-03-26 04:36:26.269329 | | NULL | 0046bc5f642c586b8a9afd6ce1ab70612dc5b1fd2408fa8677f370c1b0ca3213 | 2 | 3459965 | 2024-03-26 04:31:37.674008 | 2024-03-26 04:32:09.410718 | | NULL | 8924f01bba3c55324701716c7b50071a60b9ceaf17108c71fd064c20c4ab14db | 1 | 3290981 | 2024-03-26 04:31:49.751506 | 2024-03-26 04:31:49.751506 | | NULL | 90142bbcb50a744fcec03a1aa336b2169761597ea06d85c7f6ab03b5a4e1d841 | 1 | 3131729 | 2024-03-26 04:15:09.719557 | 2024-03-26 04:15:09.719557 | +-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+ 5 rows in set (0.00 sec)
Sekarang kita tahu intisari yang menyinggung, kita bisa mendapatkan detail lebih lanjut seperti teks kueri, pengguna yang menjalankannya, dan di mana itu dijalankan. Berdasarkan teks intisari yang dikembalikan, kita dapat melihat bahwa ini adalah ekspresi tabel umum (CTE) yang membuat empat tabel sementara dan melakukan empat pemindaian tabel, yang sangat tidak efisien.
mysql> SELECT SCHEMA_NAME,DIGEST_TEXT,QUERY_SAMPLE_TEXT,MAX_TOTAL_MEMORY,SUM_ROWS_SENT,SUM_ROWS_EXAMINED,SUM_CREATED_TMP_TABLES,SUM_NO_INDEX_USED FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST='20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a'\G; *************************** 1. row *************************** SCHEMA_NAME: sysbench DIGEST_TEXT: WITH RECURSIVE `cte` ( `n` ) AS ( SELECT ? FROM `sbtest1` UNION ALL SELECT `id` + ? FROM `sbtest1` ) SELECT * FROM `cte` QUERY_SAMPLE_TEXT: WITH RECURSIVE cte (n) AS ( SELECT 1 from sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte MAX_TOTAL_MEMORY: 537450710 SUM_ROWS_SENT: 80000000 SUM_ROWS_EXAMINED: 80000000 SUM_CREATED_TMP_TABLES: 4 SUM_NO_INDEX_USED: 4 1 row in set (0.01 sec)
Untuk informasi selengkapnya tentang events_statements_summary_by_digest tabel dan tabel ringkasan pernyataan Skema Kinerja lainnya, lihat tabel ringkasan pernyataan
Anda juga dapat menjalankan pernyataan EXPLORE atau EXPLORE ANALYSIS
catatan
EXPLAIN ANALYZEdapat memberikan lebih banyak informasi daripadaEXPLAIN, tetapi juga menjalankan kueri, jadi berhati-hatilah.
-- EXPLAIN mysql> EXPLAIN WITH RECURSIVE cte (n) AS (SELECT 1 FROM sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte; +----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+ | 1 | PRIMARY | <derived2> | NULL | ALL | NULL | NULL | NULL | NULL | 19221520 | 100.00 | NULL | | 2 | DERIVED | sbtest1 | NULL | index | NULL | k_1 | 4 | NULL | 9610760 | 100.00 | Using index | | 3 | UNION | sbtest1 | NULL | index | NULL | k_1 | 4 | NULL | 9610760 | 100.00 | Using index | +----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+ 3 rows in set, 1 warning (0.00 sec) -- EXPLAIN format=tree mysql> EXPLAIN format=tree WITH RECURSIVE cte (n) AS (SELECT 1 FROM sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte\G; *************************** 1. row *************************** EXPLAIN: -> Table scan on cte (cost=4.11e+6..4.35e+6 rows=19.2e+6) -> Materialize union CTE cte (cost=4.11e+6..4.11e+6 rows=19.2e+6) -> Index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) -> Index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) 1 row in set (0.00 sec) -- EXPLAIN ANALYZE mysql> EXPLAIN ANALYZE WITH RECURSIVE cte (n) AS (SELECT 1 from sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte\G; *************************** 1. row *************************** EXPLAIN: -> Table scan on cte (cost=4.11e+6..4.35e+6 rows=19.2e+6) (actual time=6666..9201 rows=20e+6 loops=1) -> Materialize union CTE cte (cost=4.11e+6..4.11e+6 rows=19.2e+6) (actual time=6666..6666 rows=20e+6 loops=1) -> Covering index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) (actual time=0.0365..2006 rows=10e+6 loops=1) -> Covering index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) (actual time=0.0311..2494 rows=10e+6 loops=1) 1 row in set (10.53 sec)
Tapi siapa yang menjalankannya? Kita dapat melihat di Skema Kinerja yang dimiliki destructive_operator MAX_TOTAL_MEMORY pengguna 537450710, yang lagi-lagi cocok dengan hasil sebelumnya.
catatan
Skema Kinerja disimpan dalam memori, jadi tidak boleh diandalkan sebagai satu-satunya sumber untuk audit. Jika Anda perlu mempertahankan riwayat pernyataan yang dijalankan, dan dari mana pengguna, sebaiknya aktifkan pencatatan audit. Jika Anda juga perlu menyimpan informasi tentang penggunaan memori, kami sarankan Anda mengonfigurasi pemantauan untuk mengekspor dan menyimpan nilai-nilai ini.
mysql> SELECT USER,EVENT_NAME,COUNT_STAR,MAX_TOTAL_MEMORY FROM performance_schema.events_statements_summary_by_user_by_event_name ORDER BY MAX_CONTROLLED_MEMORY DESC LIMIT 5; +----------------------+---------------------------+------------+------------------+ | USER | EVENT_NAME | COUNT_STAR | MAX_TOTAL_MEMORY | +----------------------+---------------------------+------------+------------------+ | destructive_operator | statement/sql/select | 4 | 537450710 | | rdsadmin | statement/sql/select | 4172 | 3290981 | | rdsadmin | statement/sql/show_tables | 2 | 3615821 | | rdsadmin | statement/sql/show_fields | 2 | 3459965 | | rdsadmin | statement/sql/show_status | 75 | 1914976 | +----------------------+---------------------------+------------+------------------+ 5 rows in set (0.00 sec) mysql> SELECT HOST,EVENT_NAME,COUNT_STAR,MAX_TOTAL_MEMORY FROM performance_schema.events_statements_summary_by_host_by_event_name WHERE HOST != 'localhost' AND COUNT_STAR>0 ORDER BY MAX_CONTROLLED_MEMORY DESC LIMIT 5; +------------+----------------------+------------+------------------+ | HOST | EVENT_NAME | COUNT_STAR | MAX_TOTAL_MEMORY | +------------+----------------------+------------+------------------+ | 10.0.8.231 | statement/sql/select | 4 | 537450710 | +------------+----------------------+------------+------------------+ 1 row in set (0.00 sec)
Memecahkan out-of-memory masalah untuk database Aurora MySQL
Parameter tingkat instans aurora_oom_response Aurora MySQL dapat memungkinkan instans DB untuk memantau memori sistem dan memperkirakan memori yang digunakan oleh berbagai pernyataan dan koneksi. Jika sistem kehabisan memori, ia dapat melakukan daftar tindakan untuk mencoba melepaskan memori itu. Ia melakukannya dalam upaya untuk menghindari restart database karena masalah out-of-memory (OOM). Parameter tingkat instance mengambil serangkaian tindakan yang dipisahkan koma yang dilakukan instance DB saat memorinya rendah. aurora_oom_responseParameter ini didukung untuk Aurora MySQL versi 2 dan 3.
Nilai-nilai berikut, dan kombinasinya, dapat digunakan untuk aurora_oom_response parameter. String kosong berarti tidak ada tindakan yang diambil, dan secara efektif mematikan fitur, membuat database rentan terhadap restart OOM.
-
decline— Menolak kueri baru ketika instans DB rendah pada memori. kill_connectMenutup koneksi database yang menghabiskan sejumlah besar memori, dan mengakhiri transaksi saat ini dan pernyataan Data Definition Language (DDL). Respons ini tidak didukung untuk Aurora MySQL versi 2.Untuk informasi selengkapnya, lihat pernyataan KILL
dalam dokumentasi MySQL. -
kill_query— Mengakhiri kueri dalam urutan konsumsi memori yang menurun hingga memori instance muncul di atas ambang batas rendah. Pernyataan DDL tidak berakhir.Untuk informasi selengkapnya, lihat pernyataan KILL
dalam dokumentasi MySQL. -
print— Hanya mencetak kueri yang menghabiskan sejumlah besar memori. -
tune– Menyesuaikan cache tabel internal untuk melepas sebagian memori kembali ke sistem. Aurora MySQL mengurangi memori yang digunakan untuk cache seperti dan dalam kondisi memori rendah.table_open_cachetable_definition_cacheAkhirnya, Aurora MySQL mengatur penggunaan memorinya kembali normal ketika memori sistem tidak lagi rendah.Untuk informasi selengkapnya, lihat table_open_cache dan table_definition_cache
dalam dokumentasi MySQL . tune_buffer_pool— Mengurangi ukuran kolam buffer untuk melepaskan beberapa memori dan membuatnya tersedia untuk server database untuk memproses koneksi. Respons ini didukung untuk Aurora MySQL versi 3.06 dan lebih tinggi.Anda harus memasangkan
tune_buffer_pooldengan salah satukill_queryataukill_connectdalam nilaiaurora_oom_responseparameter. Jika tidak, pengubahan ukuran kumpulan buffer tidak akan terjadi, bahkan ketika Anda memasukkantune_buffer_pooldalam nilai parameter.
Dalam versi MySQL Aurora lebih rendah dari 3,06, untuk kelas instans DB dengan memori kurang dari atau sama dengan 4 GiB, ketika instance berada di bawah tekanan memori, tindakan default mencakup,,, dan. print tune decline kill_query Untuk kelas instance DB dengan memori lebih besar dari 4 GiB, nilai parameter kosong secara default (dinonaktifkan).
Di Aurora MySQL versi 3.06 dan lebih tinggi, untuk kelas instans DB dengan memori kurang dari atau sama dengan 4 GiB, Aurora MySQL juga menutup koneksi yang memakan memori teratas (). kill_connect Untuk kelas instance DB dengan memori lebih besar dari 4 GiB, nilai parameter default adalah. print
Jika Anda sering mengalami out-of-memory masalah, penggunaan memori dapat dipantau menggunakan tabel ringkasan memoriperformance_schema diaktifkan.
