Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Beheben von Problemen mit der Speichernutzung bei Aurora-MySQL-Datenbanken
CloudWatch, Enhanced Monitoring und Performance Insights bieten zwar einen guten Überblick über die Speichernutzung auf Betriebssystemebene, z. B. darüber, wie viel Speicher der Datenbankprozess verbraucht, allerdings können Sie nicht aufschlüsseln, welche Verbindungen oder Komponenten innerhalb der Engine diesen Speichenverbrauch verursachen.
Zur Behebung können Sie das Leistungsschema und das sys-Schema verwenden. In Version 3 von Aurora MySQL ist die Speicherinstrumentierung standardmäßig aktiviert, wenn das Leistungsschema aktiviert ist. In Version 2 von Aurora MySQL ist standardmäßig nur die Speicherinstrumentierung für die Speichernutzung des Leistungsschemas aktiviert. Informationen zu Tabellen, die im Leistungsschema verfügbar sind, um die Speichernutzung nachzuverfolgen und die Speicherinstrumentierung des Leistungsschemas zu aktivieren, finden Sie unter Speicherzusammenfassungstabellen
Das Leistungsschema enthält detaillierte Informationen zur Nachverfolgung der aktuellen Speichernutzung, das sys-Schema
Im sys-Schema sind die folgenden Ansichten verfügbar, mit denen die Speichernutzung nach Verbindung, Komponente und Abfrage nachverfolgt werden kann.
| Anzeigen | Beschreibung |
|---|---|
|
Diese Ansicht stellt Informationen zur Engine-Speichernutzung nach Host bereit. Dies kann nützlich sein, um festzustellen, welche Anwendungsserver oder Client-Hosts Speicher verbrauchen. |
|
|
Diese Ansicht stellt Informationen zur Engine-Speichernutzung nach Thread-ID bereit. Die Thread-ID in MySQL kann eine Client-Verbindung oder ein Hintergrund-Thread sein. Sie können Thread-IDs MySQL-Verbindungs-IDs zuordnen, indem Sie die Ansicht sys.processlist |
|
|
Diese Ansicht stellt Informationen zur Engine-Speichernutzung nach Benutzer bereit. Dies kann nützlich sein, um festzustellen, welche Benutzerkonten oder Clients Speicher verbrauchen. |
|
|
Diese Ansicht stellt Informationen zur Engine-Speichernutzung nach Engine-Komponente bereit. Dies kann nützlich sein, um die Speichernutzung global nach Engine-Puffer oder Komponente zu ermitteln. So werden möglicherweise das |
|
|
Diese Ansicht bietet einen Überblick über die insgesamt nachverfolgte Speichernutzung in der Engine der Datenbank. |
In den Versionen 3.05 und höher von Aurora MySQL können Sie die maximale Speichernutzung auch nach Anweisungs-Digest in den Übersichtstabellen der LeistungsschemaanweisungenMAX_TOTAL_MEMORY-Spalte können Sie ermitteln, wie viel Speicher je nach Abfrage-Digest seit dem letzten Zurücksetzen der Statistiken oder seit dem Neustart der Datenbank-Instance belegt wurde. Dies kann nützlich sein, um bestimmte Abfragen zu identifizieren, die möglicherweise viel Speicher verbrauchen.
Anmerkung
Das Leistungsschema und das sys-Schema zeigen Ihnen die aktuelle Speichernutzung auf dem Server sowie die Höchstwerte für den Speicherverbrauch pro Verbindung und Engine-Komponente. Da das Leistungsschema im Arbeitsspeicher gespeichert wird, werden die Informationen zurückgesetzt, wenn die DB-Instance neu gestartet wird. Zum Verwalten eines chronologischen Verlaufs empfehlen wir, den Abruf und die Speicherung dieser Daten außerhalb des Leistungsschemas zu konfigurieren.
Themen
Beispiel 1: Anhaltend hohe Speichernutzung
Wenn wir uns FreeableMemory in CloudWatch näher ansehen, stellen wir fest, dass die Speichernutzung am 26.03.2024 um 02:59 UTC stark zugenommen hat.
Dies vermittelt uns kein vollständiges Bild. Sie können sich bei der Datenbank anmelden und sich sys.memory_global_by_current_bytes anzeigen lassen, um festzustellen, welche Komponente den meisten Speicher beansprucht. Diese Tabelle enthält eine Liste von Speicherereignissen, die MySQL nachverfolgt, zusammen mit Informationen zur Speicherzuweisung pro Ereignis. Jedes Speicherverfolgungsereignis beginnt mit memory/%, gefolgt von weiteren Informationen darüber, mit welcher Engine-Komponente oder -Funktion das Ereignis verknüpft ist.
memory/performance_schema/% gilt beispielsweise für Speicherereignisse, die sich auf das Leistungsschema beziehen, memory/innodb/% für InnoDB und so weiter. Informationen zu den Benennungskonventionen für Ereignisse finden Sie unter Leistungsschema – Instrument-Benennungskonventionen
Anhand der folgenden Abfrage können wir basierend auf current_alloc den wahrscheinlichen Verursacher ermitteln, sehen aber auch viele memory/performance_schema/%-Ereignisse.
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)
Wir haben bereits erwähnt, dass das Leistungsschema im Arbeitsspeicher gespeichert wird, was bedeutet, dass es auch in der performance_schema-Speicherinstrumentierung nachverfolgt wird.
Anmerkung
Sie können Datenbankparameter an Ihre Anforderungen anpassen, wenn Sie feststellen, dass das Leistungsschema viel Speicher beansprucht und Sie dessen Speichernutzung einschränken möchten. Weitere Informationen finden Sie unter Das Speicherzuweisungsmodell des Leistungsschemas
Zum Zwecke einer besseren Lesbarkeit können Sie dieselbe Abfrage erneut ausführen, dabei aber die Ereignisse des Leistungsschemas ausschließen. Die Ausgabe zeigt:
-
memory/sql/Prepared_statement::main_mem_rootverbraucht am meisten Speicher. -
Aus der
current_alloc-Spalte geht hervor, dass MySQL diesem Ereignis derzeit 4,91 GiB zugewiesen hat. -
high_alloc columngibt an, dass 4,91 GiB den Höchststand voncurrent_allocseit dem letzten Zurücksetzen oder dem Neustart des Servers markieren. Das bedeutet, dassmemory/sql/Prepared_statement::main_mem_rootseinen höchsten Wert erreicht hat.
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)
Am Namen des Ereignisses können wir erkennen, dass dieser Speicher für vorbereitete Anweisungen verwendet wird. Wenn Sie erfahren möchten, welche Verbindungen diesen Speicher verwenden, überprüfen Sie memory_by_thread_by_current_bytes
Im folgenden Beispiel sind jeder Verbindung ungefähr 7 MiB zugewiesen, der Höchststand beträgt ca. 6,29 MiB (current_max_alloc). Dies ergibt Sinn, da in diesem Beispiel sysbench mit 80 Tabellen und 800 Verbindungen mit vorbereiteten Anweisungen verwendet wird. Wenn Sie in diesem Szenario die Speichernutzung reduzieren möchten, können Sie die Verwendung von vorbereiteten Anweisungen in Ihrer Anwendung optimieren, um den Speicherverbrauch zu senken.
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)
Wie bereits erwähnt, kann sich der Wert der Thread-ID (thd_id) hier auf Serverhintergrund-Threads oder Datenbankverbindungen beziehen. Wenn Sie Thread-ID-Werte Datenbankverbindungs-IDs zuordnen möchten, können Sie die performance_schema.threads-Tabelle oder die sys.processlist-Ansicht verwenden, wobei conn_id die Verbindungs-ID darstellt.
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)
Wir beenden jetzt den sysbench-Workload, wodurch die Verbindungen geschlossen und der Speicher freigegeben wird. Wenn wir die Ereignisse erneut überprüfen, können wir bestätigen, dass Speicher freigegeben wurde, aber high_alloc lässt uns nach wie vor wissen, was der Höchststand ist. Die high_alloc-Spalte kann sehr nützlich sein, um kurze Spitzen bei der Speichernutzung zu identifizieren, die Sie möglicherweise nicht sofort anhand von current_alloc ermitteln können, da diese Spalte nur den derzeit zugewiesenen Speicher anzeigt.
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)
Wenn Sie high_alloc zurücksetzen möchten, können Sie die performance_schema-Speicherübersichtstabellen kürzen. Dadurch wird jedoch die gesamte Speicherinstrumentierung zurückgesetzt. Weitere Informationen finden Sie unter Leistungsschema – allgemeine Tabellenmerkmale
Im folgenden Beispiel sehen wir, dass high_alloc nach der Kürzung zurückgesetzt wird.
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)
Beispiel 2: Vorübergehende Speicherspitzen
Ein weiteres häufiges Ereignis sind kurze Spitzen bei der Speichernutzung auf einem Datenbankserver. Dabei kann es sich um periodische Einbrüche beim freigebbaren Speicher handeln, die durch current_alloc in sys.memory_global_by_current_bytes nur schwer zu beheben sind, da der Speicher bereits freigegeben wurde.
Anmerkung
Wurden die Statistiken des Leistungsschemas zurückgesetzt oder wurde die Instance der Datenbank neu gestartet, sind diese Informationen im sys oder erformance_schema nicht verfügbar. Zur Beibehaltung dieser Informationen sollten Sie die Erfassung externer Metriken konfigurieren.
Das folgende Diagramm der os.memory.free-Metrik in Enhanced Monitoring zeigt kurze Spitzen bei der Speichernutzung von 7 Sekunden. Enhanced Monitoring ermöglicht Ihnen eine Überwachung in Intervallen von nur 1 Sekunde. Dies ist ideal, um vorübergehende Spitzen wie diese abzufangen.
Um hier die Ursache der Speichernutzung zu ermitteln, können wir eine Kombination aus high_alloc in den sys-Speicherübersichtsansichten und den Übersichtstabellen der Leistungsschemaanweisungen
Da der Speicherverbrauch derzeit nicht hoch ist, können wir in der sys-Schemaansicht unter current_alloc erwartungsgemäß keine größeren Problemverursacher erkennen.
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)
Wenn wir die Ansicht erweitern, um nach high_alloc zu sortieren, sehen wir, dass die memory/temptable/physical_ram-Komponente hier ein möglicher Kandidat ist. Deren höchster Verbrauch lag bei 515,00 MiB.
Wie der Name schon sagt, instrumentiert memory/temptable/physical_ram die Speichernutzung für die TEMP-Speicher-Engine in MySQL, die in MySQL 8.0 eingeführt wurde. Weitere Informationen darüber, wie MySQL temporäre Tabellen verwendet, finden Sie unter Verwenden von internen temporären Tabellen in MySQL
Anmerkung
In diesem Beispiel verwenden wir die sys.x$memory_global_by_current_bytes-Ansicht.
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)
In Beispiel 1: Anhaltend hohe Speichernutzung haben wir die aktuelle Speichernutzung jeder Verbindung überprüft, um festzustellen, welche Verbindung für die Nutzung des fraglichen Speichers verantwortlich ist. In diesem Beispiel ist der Speicher bereits freigegeben, sodass es nicht hilfreich ist, die Speichernutzung für aktuelle Verbindungen zu überprüfen.
Um tiefer in die Materie einzutauchen und die problematischen Anweisungen, Benutzer und Hosts zu ermitteln, verwenden wir das Leistungsschema. Das Leistungsschema enthält mehrere Übersichtstabellen zu Anweisungen, die in verschiedene Dimensionen wie Ereignisname, Anweisungs-Digest, Host, Thread und Benutzer unterteilt sind. Jede Ansicht ermöglicht es Ihnen, genauer zu untersuchen, wo bestimmte Anweisungen ausgeführt werden und was sie bewirken. Dieser Abschnitt konzentriert sich auf MAX_TOTAL_MEMORY. Weitere Informationen zu allen verfügbaren Spalten finden Sie in der Dokumentation Leistungsschema – Übersichtstabellen für Anweisungen
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)
Zuerst überprüfen wir events_statements_summary_by_digest, um MAX_TOTAL_MEMORY zu sehen.
Aus diesen Daten ergibt sich Folgendes:
-
Die Abfrage mit dem
20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a-Digest scheint ein möglicher Kandidat für diese Speichernutzung zu sein.MAX_TOTAL_MEMORYbeträgt 537 450 710, was dem Höchststand entspricht, den wir bei demmemory/temptable/physical_ram-Ereignis insys.x$memory_global_by_current_bytesgesehen haben. -
Eine Ausführung fand viermal (
COUNT_STAR) statt, zuerst am 26.03.2024 um 04:08:34,943256 und zuletzt um 26.03.2024 um 04:43:06,998310.
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)
Jetzt, da wir den problematischen Digest kennen, können wir mehr Details abrufen, z. B. den Abfragetext, den Benutzer und die Stelle, an der er ausgeführt wurde. Anhand des zurückgegebenen Digest-Texts können wir erkennen, dass es sich um einen allgemeinen Tabellenausdruck (CTE) handelt, der 4 temporäre Tabellen erstellt und 4 Tabellenscans durchführt, was sehr ineffizient ist.
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)
Weitere Informationen zur events_statements_summary_by_digest-Tabelle und zu anderen Übersichtstabellen für Leistungsschemaanweisungen finden Sie unter Übersichtstabellen für Anweisungen
Sie können auch eine EXPLAIN
Anmerkung
EXPLAIN ANALYZE kann mehr Informationen bereitstellen als EXPLAIN, führt aber auch die Abfrage aus. Seien Sie also vorsichtig.
-- 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)
Aber wer ist für die Ausführung verantwortlich? Wir können im Leistungsschema sehen, dass der destructive_operator-Benutzer den MAX_TOTAL_MEMORY-Wert von 537 450 710 hatte, was wiederum den vorherigen Ergebnissen entspricht.
Anmerkung
Das Leistungsschema wird im Arbeitsspeicher gespeichert und sollte daher nicht als alleinige Quelle für Überprüfungen verwendet werden. Wenn Sie einen Verlauf der ausgeführten Anweisungen und der Benutzer, von denen diese stammen, verwalten müssen, sollten Sie das Advanced Auditing von Aurora aktivieren. Wenn Sie auch Informationen zur Speichernutzung verwalten müssen, sollten Sie die Überwachung so konfigurieren, dass diese Werte exportiert und gespeichert werden.
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)
Beispiel 3: Der freie Speicherplatz sinkt kontinuierlich und wird nicht wieder zurückgewonnen
Die InnoDB-Datenbank-Engine verwendet eine Reihe spezialisierter Ereignisse zur Speichernachverfolgung für verschiedene Komponenten. Diese spezifischen Ereignisse ermöglichen eine detaillierte Nachverfolgung der Speichernutzung in wichtigen InnoDB-Subsystemen, zum Beispiel:
-
memory/innodb/buf0buf– Dieses Ereignis dient zur Überwachung der Speicherzuweisungen für den InnoDB-Pufferpool. -
memory/innodb/ibuf0ibuf– Dieses Ereignis verfolgt speziell Speicheränderungen im Zusammenhang mit dem InnoDB-Änderungspuffer nach.
Zum Ermitteln der primären Speicherverbraucher können wir sys.memory_global_by_current_bytes abfragen:
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)
Die Ergebnisse zeigen, dass memory/innodb/memory der primäre Verbraucher ist und 5,28 GiB des aktuell zugewiesenen Speichers nutzt. Dieses Ereignis dient als eine Kategorie für Speicherzuweisungen innerhalb verschiedener InnoDB-Komponenten, die nicht mit spezifischeren Warteereignissen verknüpft sind, wie dem zuvor erwähnten memory/innodb/buf0buf.
Nachdem wir festgestellt haben, dass InnoDB-Komponenten die primären Speicherverbraucher sind, befassen wir uns nun mithilfe des folgenden MySQL-Befehls näher mit den Einzelheiten:
SHOW ENGINE INNODB STATUS \G;
Der Befehl SHOW ENGINE INNODB STATUS
Wenn wir den Abschnitt BUFFER POOL AND MEMORY des InnoDB-Statusberichts analysieren, stellen wir fest, dass 5 051 647 748 Bytes (4,7 GiB) dem Wörterbuchobjekt-Cachememory/innodb/memory nachverfolgten Speichers ausmacht.
---------------------- BUFFER POOL AND MEMORY ---------------------- Total large memory allocated 0Dictionary memory allocated 5051647748Buffer pool size 170512 Free buffers 142568 Database pages 27944 Old database pages 10354 Modified db pages 6 Pending reads 0
Der Wörterbuchobjekt-Cache ist ein gemeinsam genutzter globaler Cache, der Datenwörterbuchobjekte im Arbeitsspeicher speichert, auf die zuvor zugegriffen wurde, um die Wiederverwendung von Objekten zu ermöglichen und die Leistung zu verbessern. Die hohe Speicherzuweisung für den Wörterbuchobjekt-Cache deutet auf eine große Anzahl von Datenbankobjekten im Cache des Datenwörterbuchs hin.
Da wir nun wissen, dass der Datenwörterbuch-Cache ein primärer Verbraucher ist, untersuchen wir diesen nun auf offene Tabellen. Zum Ermitteln der Anzahl der Tabellen im Tabellendefinitions-Cache fragen Sie die globale Statusvariable open_table_definitions
mysql> show global status like 'open_table_definitions'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | Open_table_definitions | 20000 | +------------------------+-------+ 1 row in set (0.00 sec)
Weitere Informationen finden Sie unter How MySQL Opens and Closes Tables
Sie können die Anzahl der Tabellendefinitionen im Datenwörterbuch-Cache begrenzen, indem Sie den table_definition_cache-Parameter im DB-Cluster oder in der DB-Instance-Parametergruppe begrenzen. In Aurora MySQL dient dieser Wert als weicher Grenzwert hinsichtlich der Anzahl der Tabellen im Tabellendefinitions-Cache. Der Standardwert hängt von der Instance-Klasse ab und ist wie folgt festgelegt:
LEAST({DBInstanceClassMemory/393040}, 20000)
Wenn die Anzahl der Tabellen den table_definition_cache-Grenzwert überschreitet, bereinigt ein Least Recently Used (LRU)-Mechanismus Tabellen im Cache und entfernt diese. Tabellen, die an Fremdschlüsselbeziehungen beteiligt sind, werden jedoch nicht in die LRU-Liste aufgenommen, wodurch verhindert wird, dass sie entfernt werden.
In unserem aktuellen Szenario führen wir FLUSH TABLES
mysql> show global status like 'open_table_definitions'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | Open_table_definitions | 12 | +------------------------+-------+ 1 row in set (0.00 sec)
Trotz dieser Reduzierung stellen wir fest, dass die Speicherzuweisung für memory/innodb/memory mit 5,18 GiB hoch bleibt. Auch am zugewiesenen Wörterbuchspeicher ändert sich nichts. Dies geht aus den folgenden Abfrageergebnissen hervor:
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 0Dictionary memory allocated 5001599639Buffer pool size 170512 Free buffers 142568 Database pages 27944 Old database pages 10354 Modified db pages 6 Pending reads 0
Diese anhaltend hohe Speichernutzung kann auf Tabellen zurückgeführt werden, die an Fremdschlüsselbeziehungen beteiligt sind. Diese Tabellen werden nicht zur Entfernung in die LRU-Liste aufgenommen, was erklärt, warum die Speicherzuweisung auch nach dem Leeren des Tabellendefinitions-Cache hoch bleibt.
So beheben Sie dieses Problem:
-
Überprüfen und optimieren Sie Ihr Datenbankschema, insbesondere im Hinblick auf Fremdschlüsselbeziehungen.
-
Erwägen Sie, zu einer größeren DB-Instance-Klasse zu wechseln, die mehr Speicher für Ihre Wörterbuchobjekte bietet.
Wenn Sie diese Schritte befolgen und die Muster der Speicherzuweisung kennen, können Sie die Speichernutzung in Ihrer DB-Instance von Aurora MySQL besser verwalten und potenziellen Leistungsproblemen aufgrund von Speicherknappheit vorbeugen.
