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.
Behebung von Problemen mit der Speichernutzung für Aurora MySQL-Datenbanken
Enhanced Monitoring und Performance Insights bieten zwar CloudWatch einen guten Überblick über die Speichernutzung auf Betriebssystemebene, z. B. wie viel Speicher der Datenbankprozess verwendet, aber sie ermöglichen es Ihnen nicht, aufzuschlüsseln, welche Verbindungen oder Komponenten innerhalb der Engine diese Speicherbelegung verursachen könnten.
Um dieses Problem zu beheben, können Sie das Leistungsschema und das sys Schema verwenden. In Aurora MySQL Version 3 ist die Speicherinstrumentierung standardmäßig aktiviert, wenn das Performance-Schema aktiviert ist. In Aurora MySQL Version 2 ist standardmäßig nur die Speicherinstrumentierung für die Speichernutzung des Performance-Schemas aktiviert. Informationen zu Tabellen, die im Performance-Schema verfügbar sind, um die Speichernutzung nachzuverfolgen und die Performance-Schema-Speicherinstrumentierung zu aktivieren, finden Sie in der MySQL-Dokumentation unter Speicherübersichtstabellen
Im Performance-Schema sind zwar detaillierte Informationen verfügbar, um die aktuelle Speicherauslastung nachzuverfolgen, aber das MySQL-Sys-Schema
Im sys Schema sind die folgenden Ansichten verfügbar, um die Speichernutzung nach Verbindung, Komponente und Abfrage nachzuverfolgen.
| Anzeigen | Beschreibung |
|---|---|
|
Stellt Informationen zur Engine-Speichernutzung durch den Host bereit. Dies kann nützlich sein, um festzustellen, welche Anwendungsserver oder Client-Hosts Speicher verbrauchen. |
|
|
Stellt Informationen zur Engine-Speichernutzung nach Thread-ID bereit. Die Thread-ID in MySQL kann eine Client-Verbindung oder ein Hintergrundthread sein. Sie können einen Thread einer MySQL-Verbindung zuordnen IDs , IDs indem Sie die sys.processlist-Ansicht oder die performance_schema.threads-Tabelle |
|
|
Stellt Informationen zur Engine-Speichernutzung durch den Benutzer bereit. Dies kann nützlich sein, um festzustellen, welche Benutzerkonten oder Clients Speicher verbrauchen. |
|
|
Stellt Informationen zur Engine-Speichernutzung nach Engine-Komponenten bereit. Dies kann nützlich sein, um die Speichernutzung global durch Engine-Puffer oder Komponenten zu ermitteln. Beispielsweise könnten Sie das |
|
|
Bietet einen Überblick über die gesamte verfolgte Speicherauslastung in der Datenbank-Engine. |
In Aurora MySQL Version 3.05 und höher können Sie die maximale Speicherauslastung auch anhand von Statement Digest in den Übersichtstabellen der Performance-Schema-AnweisungenMAX_TOTAL_MEMORY Spalte können Sie ermitteln, wie viel Speicher von Query Digest seit dem letzten Zurücksetzen der Statistiken oder seit dem Neustart der Datenbankinstanz maximal 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 Speicherauslastung auf dem Server und die Höchstwerte für den Speicherverbrauch pro Verbindung und Engine-Komponente. Da das Leistungsschema im Speicher gespeichert wird, werden die Informationen zurückgesetzt, wenn die DB-Instance neu gestartet wird. Um den Verlauf im Laufe der Zeit beizubehalten, empfehlen wir, den Abruf und die Speicherung dieser Daten außerhalb des Performance-Schemas zu konfigurieren.
Themen
Beispiel 1: Kontinuierlich hoher Speicherverbrauch
Wenn wir uns global ansehen FreeableMemory CloudWatch, können wir feststellen, dass die Speichernutzung am 26.03.2024 um 02:59 UTC stark zugenommen hat.
Das sagt uns nicht das ganze Bild. Um festzustellen, welche Komponente den meisten Speicher beansprucht, können Sie sich bei der Datenbank anmelden und Folgendes ansehensys.memory_global_by_current_bytes. Diese Tabelle enthält eine Liste von Speicherereignissen, die MySQL verfolgt, zusammen mit Informationen zur Speicherzuweisung pro Ereignis. Jedes Speicherverfolgungsereignis beginnt mitmemory/%, gefolgt von weiteren Informationen darüber, mit welcher Engine-Komponente/Funktion das Ereignis verknüpft ist.
memory/performance_schema/%Ist zum Beispiel für Speicherereignisse, die sich auf das Leistungsschema beziehen, memory/innodb/% ist für InnoDB und so weiter. Weitere Informationen zu Benennungskonventionen für Ereignisse finden Sie unter Benennungskonventionen für Performance-Schema-Instrumente
Anhand der folgenden Abfrage können wir anhand von Ereignissen den wahrscheinlichen Schuldigen ermittelncurrent_alloc, aber wir können auch viele memory/performance_schema/% Ereignisse 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/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
Wenn Sie feststellen, dass das Leistungsschema viel Speicher beansprucht, und Sie den Speicherverbrauch einschränken möchten, können Sie die Datenbankparameter an Ihre Anforderungen anpassen. Weitere Informationen finden Sie in der MySQL-Dokumentation unter Das Performance-Schema-Speicherzuweisungsmodell
Aus Gründen der besseren Lesbarkeit können Sie dieselbe Abfrage erneut ausführen, aber Performance-Schema-Ereignisse ausschließen. Die Ausgabe zeigt Folgendes:
-
Der Hauptspeicherverbraucher ist
memory/sql/Prepared_statement::main_mem_root. -
Aus der
current_allocSpalte geht hervor, dass MySQL diesem Ereignis derzeit 4,91 GiB zugewiesen hat. -
Das
high_alloc columnsagt uns, dass 4,91 GiB der Höchststandcurrent_allocseit dem letzten Reset der Statistiken oder seit dem Neustart des Servers sind. Das bedeutet, dass dermemory/sql/Prepared_statement::main_mem_roothöchste Wert erreicht ist.
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 sehen möchten, welche Verbindungen diesen Speicher verwenden, können Sie memory_by_thread_by_current_bytes
Im folgenden Beispiel sind jeder Verbindung ungefähr 7 MiB zugewiesen, mit einer Höchstmarke von ungefähr 6,29 MiB (). current_max_alloc Das ist sinnvoll, da im Beispiel 80 Tabellen und 800 Verbindungen sysbench mit vorbereiteten Anweisungen verwendet werden. Wenn Sie in diesem Szenario den Speicherverbrauch reduzieren möchten, können Sie die Verwendung von vorbereiteten Anweisungen durch Ihre Anwendung optimieren, um den Speicherverbrauch zu reduzieren.
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 der Datenbankverbindung zuordnen möchten IDs, können Sie die performance_schema.threads Tabelle oder die sys.processlist Ansicht verwenden, wobei sich die Verbindungs-ID conn_id befindet.
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)
Jetzt beenden wir die sysbench Arbeitslast, wodurch die Verbindungen geschlossen und der Speicher freigegeben wird. Wenn wir die Ereignisse erneut überprüfen, können wir bestätigen, dass der Speicher freigegeben wurde, aber wir wissen high_alloc trotzdem, wo der Höchststand liegt. Die high_alloc Spalte kann sehr nützlich sein, wenn es darum geht, kurze Spitzen bei der Speichernutzung zu identifizieren, bei denen Sie die Auslastung möglicherweise nicht sofort erkennen können. In dieser Spalte wird nur der aktuell zugewiesene Speicher angezeigt. current_alloc
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 einen Reset durchführen möchtenhigh_alloc, können Sie die Tabellen mit der performance_schema Speicherübersicht kürzen. Dadurch wird jedoch die gesamte Speicherausstattung zurückgesetzt. Weitere Informationen finden Sie unter Allgemeine Tabellenmerkmale des Performance-Schemas
Im folgenden Beispiel können wir sehen, dass dies nach der Kürzung zurückgesetzt high_alloc 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 des freien Speichers handeln, current_alloc bei denen es schwierig ist, Fehler zu behebensys.memory_global_by_current_bytes, da der Speicher bereits freigegeben wurde.
Anmerkung
Wenn die Performance-Schema-Statistiken zurückgesetzt oder die Datenbankinstanz neu gestartet wurde, sind diese Informationen in sys oder p nicht verfügbar. erformance_schema Um diese Informationen beizubehalten, empfehlen wir, die Erfassung externer Metriken zu konfigurieren.
Das folgende Diagramm der os.memory.free Metrik in Enhanced Monitoring zeigt kurze Spitzen bei der Speichernutzung von 7 Sekunden. Mit der erweiterten Überwachung können Sie die Überwachung in Intervallen von nur 1 Sekunde durchführen. Dies ist ideal, um vorübergehende Spitzen wie diese abzufangen.
Um hier die Ursache der Speicherauslastung besser zu diagnostizieren, können wir eine Kombination aus den Ansichten mit der Zusammenfassung des high_alloc sys Speichers und den Übersichtstabellen der Leistungsschema-Anweisungen verwenden
Da der Speicherverbrauch derzeit nicht hoch ist, können wir in der sys Schemaansicht unter erwartungsgemäß keine größeren Fehler erkennen. 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)
Wenn wir die Ansicht auf Sortierung nach erweiternhigh_alloc, können wir jetzt sehen, dass die memory/temptable/physical_ram Komponente hier ein sehr guter Kandidat ist. Auf seinem höchsten Stand verbrauchte es 515,00 MiB.
Wie der Name schon sagt, memory/temptable/physical_ram instrumentiert 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 Interne Verwendung temporärer 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: Kontinuierlich hoher Speicherverbrauch haben wir die aktuelle Speichernutzung für jede 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 sinnvoll ist, die Speichernutzung für aktuelle Verbindungen zu überprüfen.
Um tiefer zu graben und die anstößigen Aussagen, Benutzer und Hosts zu finden, verwenden wir das Performance-Schema. Das Leistungsschema enthält mehrere Übersichtstabellen mit Aussagen, die nach verschiedenen Dimensionen wie Ereignisname, Statement 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 daraufMAX_TOTAL_MEMORY, aber weitere Informationen zu allen verfügbaren Spalten finden Sie in der Dokumentation mit den Übersichtstabellen für Performance-Schema-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 schauen wir events_statements_summary_by_digest nachMAX_TOTAL_MEMORY.
Daraus können wir Folgendes erkennen:
-
Die Abfrage mit Digest
20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4ascheint ein guter Kandidat für diese Speichernutzung zu sein. DasMAX_TOTAL_MEMORYist 537450710, was der Hochwassermarke entspricht, die wir bei der Veranstaltung in gesehen haben.memory/temptable/physical_ramsys.x$memory_global_by_current_bytes -
Es wurde viermal (
COUNT_STAR) durchgeführt, zuerst um 2024-03-26 04:08:34.943 256 und zuletzt um 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)
Jetzt, da wir den fraglichen Digest kennen, können wir mehr Details abrufen, z. B. den Abfragetext, den Benutzer, der ihn ausgeführt hat, und den Ort, an dem er ausgeführt wurde. Anhand des zurückgegebenen Digest-Textes können wir erkennen, dass es sich um einen Common Table Expression (CTE) handelt, der vier temporäre Tabellen erstellt und vier 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 Performance-Schema-Anweisungen finden Sie in der MySQL-Dokumentation unter Übersichtstabellen
Sie können auch eine EXPLAIN- oder EXPLAIN
Anmerkung
EXPLAIN ANALYZEkann mehr Informationen liefern alsEXPLAIN, 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 hat es ausgeführt? Wir können im Leistungsschema sehen, dass der destructive_operator Benutzer den Wert 537450710 hatteMAX_TOTAL_MEMORY, was wiederum den vorherigen Ergebnissen entspricht.
Anmerkung
Das Leistungsschema wird im Arbeitsspeicher gespeichert und sollte daher nicht als alleinige Quelle für Prüfungen verwendet werden. Wenn Sie einen Verlauf der ausgeführten Kontoauszüge und der Benutzer verwalten möchten, empfehlen wir Ihnen, Aurora Advanced Auditing zu aktivieren. Wenn Sie auch Informationen zur Speichernutzung verwalten müssen, empfehlen wir Ihnen, die Überwachung so zu 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 zurückgewonnen
Die InnoDB-Datenbank-Engine verwendet eine Reihe spezialisierter Speicherverfolgungsereignisse für verschiedene Komponenten. Diese spezifischen Ereignisse ermöglichen eine detaillierte Verfolgung der Speichernutzung in wichtigen InnoDB-Subsystemen, zum Beispiel:
-
memory/innodb/buf0buf— Dediziert für die Überwachung der Speicherzuweisungen für den InnoDB-Pufferpool. -
memory/innodb/ibuf0ibuf— Verfolgt speziell Speicheränderungen im Zusammenhang mit dem InnoDB-Änderungspuffer.
Um die wichtigsten Speicherverbraucher zu ermitteln, können wir folgende Abfragen sys.memory_global_by_current_bytes durchführen:
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 dies der größte Verbraucher memory/innodb/memory ist und 5,28 GiB des aktuell zugewiesenen Speichers verwendet. Dieses Ereignis dient als Kategorie für Speicherzuweisungen zwischen verschiedenen InnoDB-Komponenten, die nicht mit spezifischeren Warteereignissen verknüpft sind, wie memory/innodb/buf0buf bereits erwähnt.
Nachdem wir festgestellt haben, dass InnoDB-Komponenten die Hauptverbraucher von Speicher sind, können wir uns mit dem folgenden MySQL-Befehl eingehender mit den Einzelheiten befassen:
SHOW ENGINE INNODB STATUS \G;
Der Befehl SHOW ENGINE InnoDB STATUS
Wenn wir den BUFFER POOL AND MEMORY Abschnitt des InnoDB-Statusberichts analysieren, stellen wir fest, dass 5.051.647.748 Byte (4,7 GiB) dem Dictionary-Objekt-Cachememory/innodb/memory
---------------------- 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örterbuch-Objekt-Cache ist ein gemeinsam genutzter globaler Cache, der Datenwörterbuchobjekte, auf die zuvor zugegriffen wurde, im Speicher speichert, 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 Datenwörterbuch-Cache hin.
Da wir nun wissen, dass der Datenwörterbuch-Cache ein Hauptverbraucher ist, untersuchen wir den Datenwörterbuch-Cache auf offene Tabellen. Um die Anzahl der Tabellen im Tabellendefinitions-Cache zu ermitteln, fragen Sie die globale Statusvariable open_table_definitions ab
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 einschränken, indem Sie den Parameter im DB-Cluster oder in der table_definition_cache DB-Instance-Parametergruppe einschränken. Für Aurora MySQL dient dieser Wert als Softlimit für die 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, entfernt ein LRU-Mechanismus (Least Recently Used) Tabellen aus dem Cache und entfernt sie aus dem Cache. 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 mit 5,18 GiB hoch memory/innodb/memory bleibt und der zugewiesene Wörterbuchspeicher ebenfalls unverändert bleibt. 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
Dieser anhaltend hohe Speicherverbrauch 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 Tabellendefinitionscaches hoch bleibt.
So beheben Sie dieses Problem:
-
Überprüfen und optimieren Sie Ihr Datenbankschema, insbesondere 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 verstehen, können Sie die Speichernutzung in Ihrer Aurora MySQL-DB-Instance besser verwalten und potenziellen Leistungsproblemen aufgrund von Speicherdruck vorbeugen.
