Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Beheben von Speicherproblemen bei Aurora-MySQL-Datenbanken
Wenn der Arbeitsspeicher einer Aurora MySQL-DB-Instance kritisch knapp wird, kann das Betriebssystem den Datenbankprozess beenden, was zu einem ungeplanten Neustart führt. Um diese Neustarts zu verhindern, bietet Aurora MySQL Speicherverwaltungsfunktionen, die den Systemspeicher überwachen und automatische Wiederherstellungsmaßnahmen ergreifen, wenn der Arbeitsspeicher knapp wird. Diese Maßnahmen tragen dazu bei, die Nichtverfügbarkeit der Datenbank aufgrund von Speichererschöpfung zu verhindern.
Die folgenden Parameter steuern dieses Verhalten:
-
aurora_enable_memory_management— Nur in Aurora MySQL 8.4 verfügbar.-
Wenn
ON(Standard), verwaltet Aurora automatisch Speicherwiederherstellungsaktionen und deraurora_oom_responseParameter wird ignoriert. -
Stellen Sie diese
OFFOption ein, um Wiederherstellungsaktionen manuell zu steuernaurora_oom_response.
-
-
aurora_oom_response— Eine durch Kommas getrennte Liste von Wiederherstellungsaktionen. Eine leere Zeichenfolge deaktiviert alle Aktionen. Verfügbar in Aurora MySQL Version 3. Auch in Aurora MySQL 8.4 verfügbar, aber nur berücksichtigt, wennaurora_enable_memory_managementes auf gesetzt istOFF.
OOM-Antwortaktionen
Die folgenden Aktionen könnenaurora_oom_response, von der geringsten bis zur aggressivsten, aufgeführt werden.
| Action | Was macht es | Hinweise |
|---|---|---|
print |
Protokolliert speicherintensive Abfragen und Verbindungen im Fehlerprotokoll. Es werden keine Abfragen oder Verbindungen beendet. | Verfügbar in den Aurora MySQL-Versionen 3 und 8.4. |
tune |
Verkleinert die internen Tabellencaches (table_open_cache,table_definition_cache), um Speicherplatz freizugeben. Die Cachegrößen werden wiederhergestellt, wenn der Speicher wieder normal ist. Zuvor zwischengespeicherte Einträge werden nicht wiederhergestellt. Neue Einträge werden nur hinzugefügt, wenn nachfolgende Abfragen darauf zugreifen. |
Verfügbar in den Aurora MySQL-Versionen 3 und 8.4. Nur bereitgestellte Instanzen — auf Serverless v2 nicht unterstützt. |
tune_buffer_pool |
Verkleinert den InnoDB-Pufferpool, um Speicherplatz freizugeben. Die Größe des Pufferpools wird wiederhergestellt, wenn der Speicher wieder normal ist. Zuvor zwischengespeicherte Seiten, die entfernt wurden, werden nicht automatisch neu geladen. Neue Seiten werden nur zwischengespeichert, wenn nachfolgende Abfragen darauf zugreifen. | Nur Aurora MySQL Version 3 (3.06 und höher) und Aurora MySQL 8.4. Wird nur auf bereitgestellten Instanzen mit 2 vCPUs unterstützt. Wird auf Serverless v2 nicht unterstützt. |
decline |
Weist neue Abfragen mit einem Fehler ab, solange der Arbeitsspeicher knapp ist. | Verfügbar in den Aurora MySQL-Versionen 3 und 8.4. |
kill_query |
Beendet laufende SELECT Abfragen, beginnend mit dem höchsten Speicherverbrauch, bis der Arbeitsspeicher wieder normal ist. DDL, andere DML und Transaktionen sind nicht betroffen. |
Verfügbar in den Aurora MySQL-Versionen 3 und 8.4. Schließt sich gegenseitig aus mit kill_connect — wenn beide gesetzt sind, kill_connect wird nur aktiviert. |
kill_connect |
Beendet Benutzerverbindungen, setzt ihre aktiven Transaktionen zurück und beendet DDL-Anweisungen. | Weitere Informationen zum versionsspezifischen Verhalten finden Sie weiter unten. |
Wichtig
Sie müssen tune_buffer_pool entweder mit kill_query oder kill_connect im Parameterwert aurora_oom_response kombinieren. Ohne eine dieser Optionen erfolgt die Größenänderung des Pufferpools nicht, selbst wenn sie enthalten tune_buffer_pool ist.
Versionsspezifisches Verhalten von kill_connect
| Aurora MySQL Version | Behavior |
|---|---|
| Aurora MySQL 3.04 — Aurora MySQL 3.10 | Beendet Benutzerverbindungen, um genügend Speicherplatz freizugeben, damit sich die Datenbank nach der Speicherauslastung erholen kann. |
| Aurora MySQL 3.11+, Aurora MySQL 8.4 | Beendet Benutzerverbindungen, um genügend Speicherplatz freizugeben, damit sich die Datenbank nach der Speicherauslastung erholen kann. Beendet außerdem jede Benutzerverbindung, die versucht, bei Speicherauslastung Speicher zuzuweisen. |
Auf Serverless v2 reagiert Aurora auf den Speicherdruck, indem es zunächst die ACUs hochskaliert, um zusätzlichen Speicher bereitzustellen. Wenn der Speicherdruck während der Skalierung anhält, kann Aurora bestehende Verbindungen beenden, um Speicher wiederherzustellen. Verbindungen, die versuchen, Speicher zuzuweisen, werden erst beendet, wenn die Instance ihr konfiguriertes maximales ACU-Limit erreicht hat und nicht mehr weiter skaliert werden kann.
Standardwerte nach Version
Aurora MySQL konfiguriert automatisch auf der aurora_oom_response Grundlage der Engine-Version, des Instance-Typs und des verfügbaren Speichers.
In Aurora MySQL 8.4, wenn aurora_enable_memory_management dies der Fall ist ON (Standard), verwaltet Aurora automatisch Speicherwiederherstellungsaktionen, und der aurora_oom_response Wert wird nicht verwendet. Wenn auf gesetztOFF, verwendet Aurora den aurora_oom_response Wert direkt, der standardmäßig leer ist. Das bedeutet, dass keine Wiederherstellungsmaßnahmen ergriffen werden, es sei denn, Sie konfigurieren sie explizit. Die folgende Standardtabelle gilt nur für Aurora MySQL Version 3.
Schwellenwert für kleine Instanzen: ≤2 GiB für die Versionen 3.04 und 3.05. ≤4 GiB für Version 3.06 und höher.
Schwellenwert für große Instances: >2 GiB für die Versionen 3.04 und 3.05. >4 GiB für Version 3.06 und höher.
| Version | Instance-Größe | Bereitgestellt | Serverlose Version 2 |
|---|---|---|---|
| Aurora MySQL 3.04—Aurora MySQL 3.05 | Small | print,tune | print |
| Large (Groß) | deaktiviert | behindert | |
| Aurora MySQL 3.06 | Small | print,tune,decline,kill_connect | print |
| Large (Groß) | deaktiviert | behindert | |
| Aurora MySQL 3.07 | Small | print,tune,decline,kill_connect | print |
| Large (Groß) | print | print | |
| Aurora MySQL 3.08 | Small | print,tune,tune_buffer_pool,decline,kill_connect | print |
| Large (Groß) | print | print | |
| Aurora MySQL 3.09—Aurora MySQL 3.10 | Small | print,tune,tune_buffer_pool,decline,kill_connect | print |
| Large (Groß) | print,decline,kill_connect | print,decline,kill_connect | |
| Aurora MySQL 3.11 und höher | Small | print,tune,tune_buffer_pool,decline,kill_connect | print,decline,kill_connect |
| Large (Groß) | print,decline,kill_connect | print,decline,kill_connect |
Aurora Serverless v2
Die tune_buffer_pool Aktionen tune und werden auf Aurora Serverless v2 nicht unterstützt. Alle anderen Aktionen funktionieren genauso wie auf bereitgestellten Instances.
Die Speicher-Schwellenwerte passen sich dynamisch an, wenn die Instance ihre ACUs skaliert. Die Spalte Serverless v2 in der obigen Standardtabelle zeigt die effektiven Standardwerte für jede Version.
Überwachen
Sie können die Aktivitäten zur Vermeidung von OOM mit den folgenden Methoden überwachen.
Fehler-log
Wenn Maßnahmen zur Speicherwiederherstellung ergriffen werden, schreibt Aurora MySQL Meldungen in das Datenbank-Fehlerprotokoll. Das Nachrichtenpräfix variiert je nach Version und kann sich in future Versionen ändern:
Aurora MySQL Version 3: Nachrichten haben das Präfix.
OOM crash avoidance:Aurora MySQL Version 8.4: Nachrichten haben das Präfix.
Aurora memory management:
Zu diesen Nachrichten gehören:
Bei Speicherauslastung wurden Benachrichtigungen mit gesamtem und verfügbarem Speicherplatz erkannt und wiederhergestellt
Einzelheiten zu Abfragen oder Verbindungen, die zur Speicherwiederherstellung beendet wurden
Durch die
printAktion identifizierte Kandidatenanfragen
Informationen zum Anzeigen des Fehlerprotokolls finden Sie unterAurora-MySQL-Fehlerprotokolle.
CloudWatch Amazon-Metriken
Die folgenden CloudWatch Metriken verfolgen Aktivitäten zur Vermeidung von OOM auf Instanzebene.
| Metrik | Description | Verfügbar bei | Einheit |
|---|---|---|---|
AuroraMemoryHealthState | Zeigt den Zustand des Speichers an. 0bedeutet gesund (kein Speicherdruck), 5 bedeutet moderaten Speicherdruck, 10 bedeutet kritischen Speicherdruck. | Aurora MySQL 3.06.1+, Aurora MySQL 8.4 | Messinstrument |
AuroraMemoryNumDeclinedSqlTotal | Die inkrementelle Anzahl von Abfragen ging im Rahmen der OOM-Vermeidung zurück. | Aurora MySQL 3.06.1+, Aurora MySQL 8.4 | Anzahl |
AuroraMemoryNumKillConnTotal | Die inkrementelle Anzahl von Verbindungen, die im Rahmen der Vermeidung von Speichermangel geschlossen wurden. | Aurora MySQL 3.06.1+, Aurora MySQL 8.4 | Anzahl |
AuroraMemoryNumKillQueryTotal | Die inkrementelle Anzahl von Abfragen, die im Rahmen der OOM-Vermeidung beendet wurden. | Aurora MySQL 3.06.1+, Aurora MySQL 8.4 | Anzahl |
AuroraMillisecondsSpentInOomRecovery | Die Zeit, seit die Speicherintegrität unter den Normalwert gefallen ist. | Aurora MySQL 3.08.0+, Aurora MySQL 8.4 | Millisekunden |
AuroraNumOomRecoverySuccessful | Gibt an, wie oft die Speicherintegrität auf den Normalzustand zurückgesetzt wurde. | Aurora MySQL 3.08.0+, Aurora MySQL 8.4 | Anzahl |
AuroraNumOomRecoveryTriggered | Gibt an, wie oft der Zustand des Speichers unter den Normalwert gefallen ist. | Aurora MySQL 3.08.0+, Aurora MySQL 8.4 | Anzahl |
Die folgenden allgemeinen CloudWatch Metriken sind auch für die Überwachung der Speicherauslastung nützlich:
| Metrik | Description | Einheit |
|---|---|---|
FreeableMemory | Die Menge des verfügbaren Speichers. Meldet den MemAvailable Wert von/proc/meminfo. | Bytes |
SwapUsage | Die Größe des verwendeten Auslagerungsbereichs. | Bytes |
Die vollständige Liste der Aurora MySQL-Metriken auf Instanzebene finden Sie unter. Instance-level Metriken für Amazon Aurora
Globale Statusvariablen
Die folgenden Statusvariablen liefern Informationen über den OOM-Status. Verfügbar in Aurora MySQL Version 3.06.0 und höher.
| Variable | Description |
|---|---|
Aurora_oom_response | Die derzeit aktiven OOM-Antwortaktionen für diese DB-Instance. |
aurora_oom_avoidance_recovery_state | Ob OOM-Wiederherstellung ACTIVE oder istINACTIVE. |
aurora_oom_status | Aktueller Speicherintegritätsstatus der Datenbank: gesund (kein Speicherdruck), mäßiger Speicherdruck oder kritischer Speicherdruck. Nur in Version 3 verfügbar. |
Zur Abfrage: SHOW GLOBAL STATUS LIKE 'aurora_oom%';
Die vollständige Liste der globalen Statusvariablen von Aurora MySQL finden Sie unterGlobale Statusvariablen von Aurora MySQL.
Performance Insights
Wenn Performance Insights aktiviert ist, können Sie OS-level Speichermetriken verwenden, um den Speicherdruck zu überwachen und OOM-Ereignisse zu erkennen. Die folgenden Messwerte sind unter den os.swap Zählern os.memory und verfügbar:
| Metrik | Description |
|---|---|
os.memory.outOfMemoryKillCount | Die Anzahl der OOM-Kills im letzten Erfassungsintervall. Ein Wert ungleich Null gibt an, dass das Betriebssystem einen Prozess aufgrund von Speichererschöpfung beendet hat, was in der Regel zu einem Neustart der Datenbank führt. |
os.memory.total | Gesamtumfang des Arbeitsspeichers in Kilobyte. |
os.memory.free | Umfang des nicht zugewiesenen Arbeitsspeichers in Kilobyte. |
os.memory.active | Umfang des zugewiesenen Arbeitsspeichers in Kilobyte. |
os.memory.cached | Die Größe des Speichers, der für das Zwischenspeichern des Dateisystems verwendet wird I/O, in Kilobyte. |
os.memory.dirty | Die Menge der Speicherseiten, die geändert, aber noch nicht in den Speicher geschrieben wurden, in Kilobyte. |
os.memory.inactive | Umfang der am seltensten verwendeten Memory-Pages in Kilobyte. |
os.memory.db.residentSetSize | Die Menge des vom Datenbankprozess verwendeten Speichers (ohne gemeinsam genutzten Speicher), in Byte. |
os.memory.db.cache | Die Menge des Speichers, der vom Datenbankprozess für den Seitencache verwendet wird, in Byte. |
os.memory.db.swap | Die Menge an Swap-Speicher, die vom Datenbankprozess verwendet wird, in Byte. |
os.swap.in | Die Menge des Speichers, der von der Festplatte ausgelagert wurde, in Kilobyte. |
os.swap.out | Die Menge des auf die Festplatte ausgelagerten Speichers in Kilobyte. |
Sie können überwachenos.memory.outOfMemoryKillCount, um festzustellen, wann das Betriebssystem den Datenbankprozess aufgrund von Speichermangel beendet hat. Die vollständige Liste der Betriebssystemindikatoren finden Sie unter Betriebssystemmetriken von Performance Insights.
Leistungsschema
Wenn diese Option aktiviert performance_schema ist, können Sie anhand von Speicherübersichtstabellen ermitteln, welche Komponenten und Verbindungen den meisten Speicher beanspruchen. Weitere Informationen finden Sie unter Beheben von Problemen mit der Speichernutzung bei Aurora-MySQL-Datenbanken.
