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 einer Aurora MySQL-DB-Instance kritisch wenig Arbeitsspeicher zur Verfügung steht, kann das Betriebssystem den Datenbankprozess beenden, was zu einem ungeplanten Neustart führt. Um diese Neustarts zu verhindern, verfügt Aurora MySQL über 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 Aktionen zur Speicherwiederherstellung und deraurora_oom_responseParameter wird ignoriert. -
Stellen Sie ihn auf
OFFein, 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, wird aber nur berücksichtigt, wenn auf gesetztaurora_enable_memory_managementistOFF.
OOM-Antwortaktionen
Die folgenden Aktionen können enthalten sein und sind von der aurora_oom_response geringsten bis zur aggressivsten aufgeführt.
| 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 interne Tabellen-Caches (table_open_cache,table_definition_cache), um Speicherplatz freizugeben. Die Cachegrößen werden wiederhergestellt, wenn der Arbeitsspeicher 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 Instances — wird 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 Arbeitsspeicher 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 Instances mit 2 vCPUs unterstützt. Wird auf Serverless v2 nicht unterstützt. |
decline |
Lehnt neue Abfragen mit einem Fehler ab, wenn 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 Speicher 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, macht ihre aktiven Transaktionen rückgängig und beendet DDL-Anweisungen. | Nachfolgend finden Sie Informationen zum versionsspezifischen Verhalten. |
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, auch 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 Speicherauslastung erholen kann. |
| Aurora MySQL 3.11+, Aurora MySQL 8.4 | Beendet Benutzerverbindungen, um genügend Speicherplatz freizugeben, damit sich die Datenbank nach Speicherauslastung erholen kann. Beendet außerdem alle Benutzerverbindungen, die versuchen, Speicher zuzuweisen, wenn der Arbeitsspeicher überlastet ist. |
Auf Serverless v2 reagiert Aurora auf Speicherauslastung, indem es zunächst die ACUs hochskaliert, um zusätzlichen Speicher bereitzustellen. Wenn der Speicherverbrauch während der Skalierung anhält, kann Aurora bestehende Verbindungen beenden, um Speicher wiederherzustellen. Verbindungen, die versuchen, Speicher zuzuweisen, werden nur beendet, wenn die Instance ihre konfigurierte maximale ACU-Grenze erreicht hat und nicht mehr weiter skalieren kann.
Standardwerte nach Version
Aurora MySQL konfiguriert sich automatisch auf der aurora_oom_response Grundlage der Engine-Version, des Instanztyps und des verfügbaren Speichers.
In Aurora MySQL 8.4, when aurora_enable_memory_management is ON (Standardeinstellung), verwaltet Aurora automatisch Aktionen zur Speicherwiederherstellung, 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 Instances: ≤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 Instanzen: >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 | Serverlos v2 |
|---|---|---|---|
| Aurora MySQL 3.04 — Aurora MySQL 3.05 | Small | print,tune | print |
| Large (Groß) | deaktiviert | deaktiviert | |
| Aurora MySQL 3.06 | Small | print,tune,decline,kill_connect | print |
| Large (Groß) | deaktiviert | deaktiviert | |
| 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+ | 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 Arbeitsspeicher-Schwellenwerte passen sich dynamisch an, wenn die Instanz 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 mithilfe der 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 zukünftigen 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 Meldungen gehören:
Speicherüberlastung erkannt und Benachrichtigungen mit gesamtem und verfügbarem Speicher wiederhergestellt
Einzelheiten zu Abfragen oder Verbindungen, die zur Speicherwiederherstellung beendet wurden
Mögliche Abfragen, die durch die
printAktion identifiziert wurden
Informationen zum Anzeigen des Fehlerprotokolls finden Sie unterAurora-MySQL-Fehlerprotokolle.
CloudWatch Amazon-Metriken
Die folgenden CloudWatch Metriken verfolgen die Aktivitäten zur Vermeidung von OOMs auf Instance-Ebene.
| Metrik | Description | Verfügbar bei | Einheit |
|---|---|---|---|
AuroraMemoryHealthState | Zeigt den Zustand des Speichers an. 0bedeutet gesund (kein Speicherdruck), 5 bedeutet mäßigen Speicherdruck, 10 bedeutet kritischen Speicherdruck. | Aurora MySQL 3.06.1+, Aurora MySQL 8.4 | Messinstrument |
AuroraMemoryNumDeclinedSqlTotal | Die zunehmende 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 Normalzustand gefallen ist. | Aurora MySQL 3.08.0+, Aurora MySQL 8.4 | Millisekunden |
AuroraNumOomRecoverySuccessful | Gibt an, wie oft der Speicherstatus in den Normalzustand zurückversetzt wurde. | Aurora MySQL 3.08.0+, Aurora MySQL 8.4 | Anzahl |
AuroraNumOomRecoveryTriggered | Die Häufigkeit, mit der der Speicherstatus unter den Normalzustand 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 enthalten Informationen zum 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 die OOM-Wiederherstellung ist ACTIVE oderINACTIVE. |
aurora_oom_status | Aktueller Speicherstatus der Datenbank: fehlerfrei (kein Speicherauslastung), mäßiger Speicherauslastung oder kritischer Speicherauslastung. Nur in Version 3 verfügbar. |
Zur Abfrage: SHOW GLOBAL STATUS LIKE 'aurora_oom%';
Die vollständige Liste der globalen Aurora MySQL-Statusvariablen finden Sie unterGlobale Statusvariablen von Aurora MySQL.
Performance Insights
Wenn Performance Insights aktiviert ist, können Sie OS-level Speichermesswerte verwenden, um die Speicherauslastung zu überwachen und OOM-Ereignisse zu erkennen. Die folgenden Metriken 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 Datenbankneustart 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 Menge an Arbeitsspeicher, die für das Zwischenspeichern des Dateisystems verwendet wird I/O, in Kilobyte. |
os.memory.dirty | Die Anzahl 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 an Speicher, die 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 von der Festplatte ausgelagerten Speichers in Kilobyte. |
os.swap.out | Die Menge des Speichers, der auf die Festplatte ausgelagert wurde, in Kilobyte. |
Sie können überwachenos.memory.outOfMemoryKillCount, um festzustellen, wann das Betriebssystem den Datenbankprozess aufgrund von Speichermangel beendet hat. Eine vollständige Liste der Betriebssystem-Leistungsindikatoren finden Sie unter Betriebssystem-Leistungsindikatoren.
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.
