Memecahkan masalah penggunaan memori untuk database Aurora My SQL - Amazon Aurora

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memecahkan masalah penggunaan memori untuk database Aurora My SQL

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 My SQL versi 3, instrumentasi memori diaktifkan secara default saat Skema Kinerja diaktifkan. Di Aurora My SQL 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 dokumentasi Saya. SQL Untuk informasi selengkapnya tentang penggunaan Skema Kinerja dengan Performance Insights, lihat. Ikhtisar Skema Kinerja untuk Performance Insights di Aurora

Meskipun informasi terperinci tersedia di Skema Kinerja untuk melacak penggunaan memori saat ini, skema My SQL sys memiliki tampilan di atas tabel Skema Kinerja yang dapat Anda gunakan untuk menentukan dengan cepat di mana memori digunakan.

Dalam sys skema, tampilan berikut tersedia untuk melacak penggunaan memori dengan koneksi, komponen, dan kueri.

Tayang Deskripsi

memory_by_host_by_current_bytes

Memberikan informasi tentang penggunaan memori mesin oleh host. Ini dapat berguna untuk mengidentifikasi server aplikasi atau host klien mana yang menghabiskan memori.

memory_by_thread_by_current_bytes

Memberikan informasi tentang penggunaan memori mesin dengan ID utas. ID utas di My SQL dapat berupa koneksi klien atau utas latar belakang. Anda dapat memetakan utas IDs ke SQL Koneksi saya IDs dengan menggunakan tampilan sys.processlist atau tabel performance_schema.threads.

memory_by_user_by_current_bytes

Memberikan informasi tentang penggunaan memori mesin oleh pengguna. Ini dapat berguna untuk mengidentifikasi akun pengguna atau klien mana yang menghabiskan memori.

memory_global_by_current_bytes

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 memory/innodb/buf_buf_pool acara untuk kumpulan buffer InnoDB, atau memory/sql/Prepared_statement::main_mem_root acara untuk pernyataan yang disiapkan.

memory_global_total

Memberikan gambaran umum total penggunaan memori yang dilacak di mesin database.

Di Aurora My SQL versi 3.05 dan yang lebih tinggi, Anda juga dapat melacak penggunaan memori maksimum dengan intisari pernyataan di tabel ringkasan pernyataan Skema Kinerja. Tabel ringkasan pernyataan berisi intisari pernyataan yang dinormalisasi dan statistik agregat pada pelaksanaannya. 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

FreeableMemory grafik yang menunjukkan penggunaan memori yang tinggi.

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 SQL dilacak Saya, 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 Saya. SQL

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 di dokumentasi Saya. SQL

Untuk keterbacaan, Anda dapat menjalankan kembali kueri yang sama tetapi mengecualikan peristiwa Skema Kinerja. Outputnya menunjukkan hal berikut:

  • Konsumen memori utama adalahmemory/sql/Prepared_statement::main_mem_root.

  • current_allocKolom memberi tahu kita bahwa My SQL memiliki 4,91 GiB yang saat ini dialokasikan untuk acara ini.

  • Ini high_alloc column memberi tahu kita bahwa 4,91 GiB adalah tanda current_alloc air tinggi sejak statistik terakhir disetel ulang atau sejak server dimulai ulang. Ini berarti memory/sql/Prepared_statement::main_mem_root itu 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 koneksi databaseIDs, 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 SQL dokumentasi Saya.

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.

Lonjakan memori sementara.

Untuk membantu mendiagnosis penyebab penggunaan memori di sini, kita dapat menggunakan kombinasi tampilan ringkasan sys memori dan tabel ringkasan pernyataan Skema Kinerja untuk mencoba mengidentifikasi sesi dan koneksi yang menyinggung. high_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, penggunaan memori memory/temptable/physical_ram instrumen untuk mesin TEMP penyimpanan di MySQL, yang diperkenalkan di My SQL 8.0. Untuk informasi selengkapnya tentang cara Saya SQL menggunakan tabel sementara, lihat Penggunaan tabel sementara internal di Saya SQL dalam SQL dokumentasi Saya.

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 20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a tampaknya 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_ram sys.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 dalam SQL dokumentasi Saya.

Anda juga dapat menjalankan EXPLAINANALYZEpernyataan EXPLAINatau untuk melihat detail lebih lanjut.

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, kami sarankan Anda mengaktifkan Audit Lanjutan Aurora. 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)

Contoh 3: Memori yang dapat dibebaskan turun terus menerus dan tidak direklamasi

Mesin database InnoDB menggunakan berbagai peristiwa pelacakan memori khusus untuk komponen yang berbeda. Peristiwa spesifik ini memungkinkan pelacakan granular penggunaan memori di subsistem InnoDB utama, misalnya:

  • memory/innodb/buf0buf— Didedikasikan untuk memantau alokasi memori untuk kolam buffer InnoDB.

  • memory/innodb/ibuf0ibuf— Secara khusus melacak perubahan memori yang terkait dengan buffer perubahan InnoDB.

Untuk mengidentifikasi konsumen memori teratas, kami dapat menanyakansys.memory_global_by_current_bytes:

mysql> SELECT event_name,current_alloc FROM sys.memory_global_by_current_bytes LIMIT 10; +-----------------------------------------------------------------+---------------+ | event_name | current_alloc | +-----------------------------------------------------------------+---------------+ | memory/innodb/memory | 5.28 GiB | | memory/performance_schema/table_io_waits_summary_by_index_usage | 495.00 MiB | | memory/performance_schema/table_shares | 488.00 MiB | | memory/sql/TABLE_SHARE::mem_root | 388.95 MiB | | memory/innodb/std | 226.88 MiB | | memory/innodb/fil0fil | 198.49 MiB | | memory/sql/binlog_io_cache | 128.00 MiB | | memory/innodb/mem0mem | 96.82 MiB | | memory/innodb/dict0dict | 96.76 MiB | | memory/performance_schema/rwlock_instances | 88.00 MiB | +-----------------------------------------------------------------+---------------+ 10 rows in set (0.00 sec)

Hasilnya menunjukkan bahwa itu memory/innodb/memory adalah konsumen teratas, menggunakan 5,28 GiB memori yang saat ini dialokasikan. Acara ini berfungsi sebagai kategori untuk alokasi memori di berbagai komponen InnoDB yang tidak terkait dengan peristiwa tunggu yang lebih spesifik, memory/innodb/buf0buf seperti yang disebutkan sebelumnya.

Setelah menetapkan bahwa komponen InnoDB adalah konsumen utama memori, kita dapat menyelam lebih dalam ke spesifik menggunakan perintah Saya berikut: SQL

SHOW ENGINE INNODB STATUS \G;

SHOWENGINEINNODBSTATUSPerintah ini menyediakan laporan status komprehensif untuk mesin penyimpanan InnoDB, termasuk statistik penggunaan memori terperinci untuk komponen InnoDB yang berbeda. Ini dapat membantu mengidentifikasi struktur atau operasi InnoDB spesifik mana yang paling banyak menghabiskan memori. Untuk informasi selengkapnya, lihat struktur dalam memori InnoDB di dokumentasi Saya. SQL

Menganalisis BUFFER POOL AND MEMORY bagian dari laporan status InnoDB, kita melihat bahwa 5.051.647.748 byte (4,7 GiB) dialokasikan ke cache objek kamus, yang menyumbang 89% dari memori yang dilacak oleh. memory/innodb/memory

---------------------- BUFFER POOL AND MEMORY ---------------------- Total large memory allocated 0 Dictionary memory allocated 5051647748 Buffer pool size 170512 Free buffers 142568 Database pages 27944 Old database pages 10354 Modified db pages 6 Pending reads 0

Cache objek kamus adalah cache global bersama yang menyimpan objek kamus data yang diakses sebelumnya dalam memori untuk mengaktifkan penggunaan kembali objek dan meningkatkan kinerja. Alokasi memori yang tinggi ke cache objek kamus menunjukkan sejumlah besar objek database dalam cache kamus data.

Sekarang kita tahu bahwa cache kamus data adalah konsumen utama, kita lanjutkan untuk memeriksa cache kamus data untuk tabel terbuka. Untuk menemukan jumlah tabel dalam cache definisi tabel, kueri variabel status global open_table_definition.

mysql> show global status like 'open_table_definitions'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | Open_table_definitions | 20000 | +------------------------+-------+ 1 row in set (0.00 sec)

Untuk informasi selengkapnya, lihat Cara Saya SQL membuka dan menutup tabel di SQL dokumentasi Saya.

Anda dapat membatasi jumlah definisi tabel dalam cache kamus data dengan membatasi table_definition_cache parameter di cluster DB atau grup parameter instans DB. Untuk Aurora MySQL, nilai ini berfungsi sebagai batas lunak untuk jumlah tabel dalam cache definisi tabel. Nilai default tergantung pada kelas instance dan diatur sebagai berikut:

LEAST({DBInstanceClassMemory/393040}, 20000)

Ketika jumlah tabel melebihi table_definition_cache batas, mekanisme (LRU) yang paling tidak baru digunakan mengusir dan menghapus tabel dari cache. Namun, tabel yang terlibat dalam hubungan kunci asing tidak ditempatkan dalam LRU daftar, mencegah penghapusannya.

Dalam skenario kami saat ini, kami menjalankan FLUSHTABLESuntuk menghapus cache definisi tabel. Tindakan ini menghasilkan penurunan signifikan dalam variabel status global Open_TABLE_DEFINITIONS, dari 20.000 menjadi 12, seperti yang ditunjukkan di sini:

mysql> show global status like 'open_table_definitions'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | Open_table_definitions | 12 | +------------------------+-------+ 1 row in set (0.00 sec)

Meskipun pengurangan ini, kami mengamati bahwa alokasi memori untuk memory/innodb/memory tetap tinggi pada 5,18 GiB, dan memori kamus yang dialokasikan juga tetap tidak berubah. Hal ini terbukti dari hasil query berikut:

mysql> SELECT event_name,current_alloc FROM sys.memory_global_by_current_bytes LIMIT 10; +-----------------------------------------------------------------+---------------+ | event_name | current_alloc | +-----------------------------------------------------------------+---------------+ | memory/innodb/memory | 5.18 GiB | | memory/performance_schema/table_io_waits_summary_by_index_usage | 495.00 MiB | | memory/performance_schema/table_shares | 488.00 MiB | | memory/sql/TABLE_SHARE::mem_root | 388.95 MiB | | memory/innodb/std | 226.88 MiB | | memory/innodb/fil0fil | 198.49 MiB | | memory/sql/binlog_io_cache | 128.00 MiB | | memory/innodb/mem0mem | 96.82 MiB | | memory/innodb/dict0dict | 96.76 MiB | | memory/performance_schema/rwlock_instances | 88.00 MiB | +-----------------------------------------------------------------+---------------+ 10 rows in set (0.00 sec)
---------------------- BUFFER POOL AND MEMORY ---------------------- Total large memory allocated 0 Dictionary memory allocated 5001599639 Buffer pool size 170512 Free buffers 142568 Database pages 27944 Old database pages 10354 Modified db pages 6 Pending reads 0

Penggunaan memori yang terus-menerus tinggi ini dapat dikaitkan dengan tabel yang terlibat dalam hubungan kunci asing. Tabel ini tidak ditempatkan dalam LRU daftar untuk dihapus, menjelaskan mengapa alokasi memori tetap tinggi bahkan setelah pembilasan cache definisi tabel.

Untuk mengatasi masalah ini:

  1. Tinjau dan optimalkan skema database Anda, terutama hubungan kunci asing.

  2. Pertimbangkan untuk pindah ke kelas instans DB yang lebih besar yang memiliki lebih banyak memori untuk mengakomodasi objek kamus Anda.

Dengan mengikuti langkah-langkah ini dan memahami pola alokasi memori, Anda dapat mengelola penggunaan memori dengan lebih baik di instans Aurora SQL My DB Anda dan mencegah potensi masalah kinerja karena tekanan memori.