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 Workload-Problemen für Aurora MySQL-Datenbanken
Die Datenbank-Arbeitslast kann als Lese- und Schreibvorgänge betrachtet werden. Wenn Sie sich mit der „normalen“ Datenbank-Arbeitslast auskennen, können Sie Abfragen und den Datenbankserver an die sich ändernde Nachfrage anpassen. Es gibt eine Reihe verschiedener Gründe, warum sich die Leistung ändern kann. Der erste Schritt besteht also darin, zu verstehen, was sich geändert hat.
-
Gab es ein Upgrade der Haupt- oder Nebenversion?
Ein Hauptversionsupgrade beinhaltet Änderungen am Engine-Code, insbesondere am Optimizer, die den Ausführungsplan der Abfrage ändern können. Bei der Aktualisierung von Datenbankversionen, insbesondere von Hauptversionen, ist es sehr wichtig, dass Sie die Datenbank-Arbeitslast analysieren und entsprechend optimieren. Abhängig von den Testergebnissen kann das Optimieren und Neuschreiben von Abfragen oder das Hinzufügen und Aktualisieren von Parametereinstellungen beinhalten. Wenn Sie verstehen, was die Auswirkungen verursacht, können Sie sich auf diesen speziellen Bereich konzentrieren.
Weitere Informationen finden Sie unter Was ist neu in MySQL 8.0
und Server und in MySQL 8.0 hinzugefügte, veraltete oder entfernte Statusvariablen und -optionen in der MySQL-Dokumentation und. Vergleich von Aurora-MySQL-Version 2 und Aurora-MySQL-Version 3 -
Hat die Anzahl der verarbeiteten Daten zugenommen (Zeilenanzahl)?
-
Werden mehr Abfragen gleichzeitig ausgeführt?
-
Gibt es Schema- oder Datenbankänderungen?
-
Gab es Codefehler oder Korrekturen?
Inhalt
Metriken für Instance-Hosts
Überwachen Sie Instance-Host-Metriken wie CPU, Arbeitsspeicher und Netzwerkaktivität, um besser zu verstehen, ob sich die Arbeitslast geändert hat. Es gibt zwei Hauptkonzepte für das Verständnis von Workload-Änderungen:
-
Auslastung — Die Nutzung eines Geräts, z. B. einer CPU oder einer Festplatte. Sie kann zeit- oder kapazitätsbasiert sein.
-
Zeitbasiert — Die Zeit, in der eine Ressource während eines bestimmten Beobachtungszeitraums ausgelastet ist.
-
Kapazitätsbasiert — Der Durchsatz, den ein System oder eine Komponente liefern kann, als Prozentsatz der Kapazität.
-
-
Sättigung — Der Grad, in dem eine Ressource mehr Arbeit benötigt, als sie verarbeiten kann. Wenn die kapazitätsabhängige Nutzung 100% erreicht, kann die zusätzliche Arbeit nicht verarbeitet werden und muss in die Warteschlange gestellt werden.
CPU-Verwendung
Sie können die folgenden Tools verwenden, um die CPU-Auslastung und -Auslastung zu ermitteln:
-
CloudWatch stellt die
CPUUtilizationMetrik bereit. Wenn dieser Wert 100% erreicht, ist die Instanz voll ausgelastet. Die CloudWatch Metriken werden jedoch über einen Zeitraum von 1 Minute gemittelt und es fehlt ihnen an Granularität.Weitere Informationen zu CloudWatch Metriken finden Sie unter. Metriken auf Instance-Ebene für Amazon Aurora
-
Enhanced Monitoring stellt Metriken bereit, die vom
topBetriebssystembefehl zurückgegeben werden. Es zeigt die durchschnittliche Auslastung und die folgenden CPU-Status mit einer Genauigkeit von 1 Sekunde an:-
Idle (%)= Leerlaufzeit -
IRQ (%)= Softwareunterbrechungen -
Nice (%)= Gute Zeit für Prozesse mit einer schönen Priorität. -
Steal (%)= Zeit, die für die Betreuung anderer Mandanten aufgewendet wurde (im Zusammenhang mit Virtualisierung) -
System (%)= Systemzeit -
User (%)= Benutzerzeit -
Wait (%)= I/O warten
Weitere Informationen zu Enhanced Monitoring-Metriken finden Sie unterBetriebssystemmetriken für Aurora.
-
Speicherauslastung
Wenn das System unter Speicherauslastung steht und der Ressourcenverbrauch die Obergrenze erreicht, sollten Sie ein hohes Maß an Seitenscans, Seitenauslagerungen, Auslagerungen und out-of-memory Fehlern beobachten.
Sie können die folgenden Tools verwenden, um den Speicherverbrauch und die Speicherauslastung zu ermitteln:
CloudWatch stellt die FreeableMemory Metrik bereit, die angibt, wie viel Speicher durch Leeren einiger Betriebssystem-Caches und den aktuell freien Speicher zurückgewonnen werden kann.
Weitere Informationen zu CloudWatch Metriken finden Sie unter. Metriken auf Instance-Ebene für Amazon Aurora
Enhanced Monitoring bietet die folgenden Messwerte, anhand derer Sie Probleme mit der Speichernutzung identifizieren können:
-
Buffers (KB)— Die Speichermenge, die für die Pufferung von I/O-Anfragen vor dem Schreiben auf das Speichergerät verwendet wird, in Kilobyte. -
Cached (KB)— Die Speichermenge, die für das Zwischenspeichern dateisystembasierter I/O verwendet wird. -
Free (KB)— Die Menge des nicht zugewiesenen Speichers in Kilobyte. -
Swap— Zwischengespeichert, Kostenlos und Insgesamt.
Wenn Sie beispielsweise feststellen, dass Ihre DB-Instance Swap Arbeitsspeicher verwendet, ist der Gesamtspeicher für Ihren Workload größer, als Ihre Instance derzeit zur Verfügung hat. Wir empfehlen, die Größe Ihrer DB-Instance zu erhöhen oder Ihre Arbeitslast so zu optimieren, dass weniger Speicher verwendet wird.
Weitere Informationen zu Enhanced Monitoring-Metriken finden Sie unterBetriebssystemmetriken für Aurora.
Ausführlichere Informationen zur Verwendung des Leistungsschemas und des sys Schemas zur Bestimmung, welche Verbindungen und Komponenten Speicher verwenden, finden Sie unterBehebung von Problemen mit der Speichernutzung für Aurora MySQL-Datenbanken.
Netzwerkdurchsatz
CloudWatch bietet die folgenden Messwerte für den gesamten Netzwerkdurchsatz, jeweils gemittelt über 1 Minute:
-
NetworkReceiveThroughput— Die Menge des Netzwerkdurchsatzes, den jede Instance im Aurora-DB-Cluster von Clients erhält. -
NetworkTransmitThroughput— Die Menge des Netzwerkdurchsatzes, der von jeder Instance im Aurora-DB-Cluster an Clients gesendet wird. -
NetworkThroughput— Die Menge des Netzwerkdurchsatzes, der von jeder Instance im Aurora-DB-Cluster sowohl von Clients empfangen als auch an diese übertragen wird. -
StorageNetworkReceiveThroughput— Die Menge des Netzwerkdurchsatzes, den jede Instance im DB-Cluster vom Aurora-Speichersubsystem erhält. -
StorageNetworkTransmitThroughput— Die Menge des Netzwerkdurchsatzes, der von jeder Instance im Aurora-DB-Cluster an das Aurora-Speichersubsystem gesendet wird. -
StorageNetworkThroughput— Die Menge des Netzwerkdurchsatzes, der von jeder Instance im Aurora-DB-Cluster vom Aurora-Speichersubsystem empfangen und an dieses gesendet wird.
Weitere Informationen zu CloudWatch Metriken finden Sie unterMetriken auf Instance-Ebene für Amazon Aurora.
Enhanced Monitoring stellt die network empfangenen (RX) und übertragenen (TX) Diagramme mit einer Genauigkeit von bis zu 1 Sekunde bereit.
Weitere Informationen zu Enhanced Monitoring-Metriken finden Sie unter. Betriebssystemmetriken für Aurora
Datenbankmetriken
Untersuchen Sie die folgenden CloudWatch Metriken auf Workload-Änderungen:
-
BlockedTransactions— Die durchschnittliche Anzahl von Transaktionen in der Datenbank, die pro Sekunde blockiert werden. -
BufferCacheHitRatio— Der Prozentsatz der Anfragen, die vom Buffer Cache bedient werden. -
CommitThroughput— Die durchschnittliche Anzahl von Commit-Vorgängen pro Sekunde. -
DatabaseConnections— Die Anzahl der Client-Netzwerkverbindungen zur Datenbank-Instance. -
Deadlocks— Die durchschnittliche Anzahl von Deadlocks in der Datenbank pro Sekunde. -
DMLThroughput— Die durchschnittliche Anzahl von Einfügungen, Aktualisierungen und Löschungen pro Sekunde. -
ResultSetCacheHitRatio— Der Prozentsatz der Anfragen, die vom Abfrage-Cache bedient werden. -
RollbackSegmentHistoryListLength— Die Undo-Logs, in denen festgeschriebene Transaktionen mit mit „Löschen“ markierten Datensätzen aufgezeichnet werden. -
RowLockTime— Die Gesamtzeit, die für den Erwerb von Zeilensperren für InnoDB-Tabellen aufgewendet wurde. -
SelectThroughput— Die durchschnittliche Anzahl von ausgewählten Abfragen pro Sekunde.
Weitere Informationen zu CloudWatch Metriken finden Sie unterMetriken auf Instance-Ebene für Amazon Aurora.
Beachten Sie bei der Untersuchung der Arbeitslast die folgenden Fragen:
-
Gab es kürzlich Änderungen an der DB-Instance-Klasse, z. B. die Reduzierung der Instance-Größe von 8xlarge auf 4xlarge oder die Umstellung von db.r5 auf db.r6?
-
Können Sie einen Clone erstellen und das Problem reproduzieren, oder tritt es nur auf dieser einen Instance auf?
-
Liegt eine Erschöpfung der Serverressourcen, eine hohe CPU- oder Speicherauslastung vor? Falls ja, könnte dies bedeuten, dass zusätzliche Hardware erforderlich ist.
-
Dauern eine oder mehrere Abfragen länger?
-
Werden die Änderungen durch ein Upgrade verursacht, insbesondere durch ein Upgrade einer Hauptversion? Falls ja, vergleichen Sie die Metriken vor und nach dem Upgrade.
-
Gibt es Änderungen in der Anzahl der Reader-DB-Instances?
-
Haben Sie die allgemeine Protokollierung, die Prüfprotokollierung oder die binäre Protokollierung aktiviert? Weitere Informationen finden Sie unter Protokollierung für Aurora MySQL-Datenbanken.
-
Haben Sie Ihre Verwendung der Binärprotokollreplikation (Binlog) aktiviert, deaktiviert oder geändert?
-
Gibt es Transaktionen mit langer Laufzeit, die eine große Anzahl von Zeilensperren enthalten? Untersuchen Sie die Länge der InnoDB-Verlaufsliste (HLL) auf Hinweise auf lang andauernde Transaktionen.
Weitere Informationen finden Sie unter Die Länge der InnoDB-Verlaufsliste wurde deutlich erhöht und im Blogbeitrag Warum läuft meine SELECT-Abfrage langsam auf meinem Amazon Aurora MySQL-DB-Cluster?
. -
Wenn eine große HLL durch eine Schreibtransaktion verursacht wird, bedeutet dies, dass sich
UNDOProtokolle ansammeln (die nicht regelmäßig bereinigt werden). Bei einer großen Schreibtransaktion kann diese Akkumulation schnell zunehmen. In MySQLUNDOist es im SYSTEM-Tablespacegespeichert. Der SYSTEMTablespace ist nicht verkleinerbar. DasUNDOProtokoll kann dazu führen, dass derSYSTEMTablespace auf mehrere GB oder sogar TB anwächst. Geben Sie nach dem Löschen den zugewiesenen Speicherplatz frei, indem Sie ein logisches Backup (Dump) der Daten erstellen und das Speicherabbild anschließend in eine neue DB-Instance importieren. -
Wenn eine große HLL durch eine Lesetransaktion (lang andauernde Abfrage) verursacht wird, kann dies bedeuten, dass die Abfrage eine große Menge an temporärem Speicherplatz belegt. Geben Sie den temporären Speicherplatz durch einen Neustart frei. Untersuchen Sie die Performance Insights DB-Metriken auf Änderungen in
Tempdiesem Abschnitt, z.created_tmp_tablesB. Weitere Informationen finden Sie unter Überwachung mit Performance Insights auf .
-
-
Können Sie Transaktionen mit langer Laufzeit in kleinere Transaktionen aufteilen, bei denen weniger Zeilen geändert werden?
-
Gibt es Änderungen bei blockierten Transaktionen oder eine Zunahme von Deadlocks? Untersuchen Sie die Performance Insights DB-Metriken auf Änderungen der Statusvariablen im
LocksAbschnittinnodb_row_lock_time, wieinnodb_row_lock_waits, undinnodb_dead_locks. Verwenden Sie Intervalle von 1 Minute oder 5 Minuten. -
Gibt es erhöhte Wartezeiten? Untersuchen Sie Performance Insights Warteereignisse und Wartearten in Intervallen von 1 Minute oder 5 Minuten. Analysieren Sie die wichtigsten Warteereignisse und finden Sie heraus, ob sie mit Workload-Änderungen oder Datenbankkonflikten korrelieren. Weist beispielsweise auf einen Konflikt im Pufferpool
buf_pool mutexhin. Weitere Informationen finden Sie unter Optimieren von Aurora MySQL mit Warteereignissen.
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 Thread-IDs MySQL-Verbindungs-IDs zuordnen, 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.
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 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 Datenbankverbindungs-IDs zuordnen möchten, 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 für die Speicherauslastung besser zu diagnostizieren, können wir eine Kombination aus den Ansichten mit der Zusammenfassung des high_alloc sys Speichers und den Übersichtstabellen der Performance-Schema-Anweisungen
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, den Speicherverbrauch 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 Anweisungen und der Benutzer verwalten möchten, empfehlen wir, die Auditprotokollierung zu aktivieren. Wenn Sie auch Informationen zur Speichernutzung verwalten müssen, empfehlen wir, 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)
Behebung von out-of-memory Problemen mit Aurora MySQL-Datenbanken
Mithilfe des Parameters der Instance-Ebene Aurora MySQL aurora_oom_response kann die DB-Instance den Arbeitsspeicher des Systems überwachen und den von verschiedenen Anweisungen und Verbindungen verbrauchten Arbeitsspeicher schätzen. Wenn dem System der Arbeitsspeicher knapp wird, kann es eine Liste von Aktionen ausführen, um zu versuchen, diesen Speicher freizugeben. Dadurch wird versucht, einen Neustart der Datenbank aufgrund von out-of-memory (OOM-) Problemen zu vermeiden. Der Parameter auf Instance-Ebene umfasst eine Reihe von kommagetrennten Aktionen, die eine DB-Instance ausführt, wenn ihr Arbeitsspeicher knapp wird. Der aurora_oom_response Parameter wird für die Aurora MySQL-Versionen 2 und 3 unterstützt.
Die folgenden Werte und deren Kombinationen können für den aurora_oom_response Parameter verwendet werden. Eine leere Zeichenfolge bedeutet, dass keine Aktion ausgeführt wird, und die Funktion wird effektiv ausgeschaltet, sodass die Datenbank anfällig für OOM-Neustarts ist.
-
decline— Lehnt neue Abfragen ab, wenn der Arbeitsspeicher der DB-Instance knapp wird. kill_connect— Schließt Datenbankverbindungen, die viel Speicher verbrauchen, und beendet aktuelle Transaktionen und DDL-Anweisungen (Data Definition Language). Diese Antwort wird für Aurora MySQL Version 2 nicht unterstützt.Weitere Informationen finden Sie unter KILL-Anweisung
in der MySQL-Dokumentation. -
kill_query— Beendet Abfragen in absteigender Reihenfolge des Speicherverbrauchs, bis der Instanzspeicher den unteren Schwellenwert überschreitet. DDL-Anweisungen werden nicht beendet.Weitere Informationen finden Sie unter KILL-Anweisung
in der MySQL-Dokumentation. -
print— Druckt nur die Abfragen, die viel Speicher verbrauchen. -
tune– Stellt die Caches der internen Tabellen so ein, dass etwas Arbeitsspeicher für das System freigegeben wird. Aurora MySQL verringert den Speicherplatz, der für Caches verwendet wird, z.table_open_cacheB.table_definition_cachebei Speichermangel. Schließlich setzt Aurora MySQL ihre Speichernutzung wieder auf den Normalwert zurück, wenn das System nicht mehr zu wenig Arbeitsspeicher hat.Weitere Informationen finden Sie unter table_open_cache und table_definition_cache
in der MySQL-Dokumentation. tune_buffer_pool— Verringert die Größe des Pufferpools, um Speicherplatz freizugeben und ihn dem Datenbankserver zur Verarbeitung von Verbindungen zur Verfügung zu stellen. Diese Antwort wird für Aurora MySQL Version 3.06 und höher unterstützt.Sie müssen das Paar entweder
tune_buffer_poolmitkill_queryoderkill_connectimaurora_oom_responseParameterwert verbinden. Andernfalls erfolgt die Größenänderung des Pufferpools nicht, selbst wenn Sie den Werttune_buffer_poolin den Parameterwert mit einbeziehen.
In Aurora MySQL-Versionen unter 3.06 gehören für DB-Instance-Klassen mit einem Arbeitsspeicher von weniger als oder gleich 4 GiB, wenn die Instance unter Speicherauslastung steht, die Standardaktionenprint, tunedecline, undkill_query. Für DB-Instance-Klassen mit einem Speicher von mehr als 4 GiB ist der Parameterwert standardmäßig leer (deaktiviert).
In Aurora MySQL Version 3.06 und höher schließt Aurora MySQL für DB-Instance-Klassen mit einem Arbeitsspeicher von weniger als oder gleich 4 GiB auch die Verbindungen mit dem höchsten Speicherverbrauch (). kill_connect Für DB-Instance-Klassen mit einem Speicher von mehr als 4 GiB ist der Standardparameterwertprint.
Wenn Sie häufig auf out-of-memory Probleme stoßen, kann die Speichernutzung mithilfe von Speicherübersichtstabellenperformance_schema ist.
