Das Upgrade von verwalteten Datenbank-Engines sollte eigentlich eine Routineaufgabe sein. Doch manchmal führen subtile Konfigurationsänderungen zu unerwarteten Performance-Einbußen. Kürzlich zeigte ein Fall mit Amazon Aurora MySQL 3.08.2 (basierend auf MySQL 8.0.39), wie eine kleine Änderung im Zusammenspiel von Performance Insights und Performance Schema Symptome eines Memory Leaks hervorrufen kann – insbesondere bei kleineren Instanzklassen.
In diesem Artikel gehe ich auf die Symptome, die eigentliche Ursache sowie mögliche Maßnahmen ein, mit denen Entwickler das Problem beheben können.
Die Symptome: Verhalten wie bei einem Memory Leak
Nach dem Upgrade eines Aurora-Clusters von Version 3.05.2 auf 3.08.2 stellte ein Kunde fest, dass seine Writer-Instanz kontinuierlich den verfügbaren Speicher ausschöpfte.
Wesentliche Fakten:
- Instanztyp:
db.t4g.medium(4 GB Arbeitsspeicher) - Freier Speicher sank nach dem Upgrade kontinuierlich ab.
- Workload: moderat und unverändert.
Für den ungeübten Beobachter sah dies wie ein klassisches Memory Leak aus – doch die tatsächliche Ursache war eine andere.
Die eigentliche Ursache: Wie sich das Verhalten des Performance Schema verändert hat
Vor Version 3.08.2 war auf t4g.medium-Instanzen mit aktivierten Performance Insights das Performance Schema standardmäßig deaktiviert. Dies war eine dokumentierte Einschränkung:
„Automatische Verwaltung des Performance Schema wird für die Instanzklasse t4g.medium nicht unterstützt.“
Nach dem Upgrade auf 3.08.2 änderte sich dieses Verhalten: Das Performance Schema wurde aktiviert und von Performance Insights gesteuert. Dadurch begannen sich die ausschließlich im Speicher gehaltenen Tabellen des Performance Schema zu füllen.
Folge: Der verfügbare Arbeitsspeicher wurde nach und nach aufgebraucht – und das Bild erinnerte stark an ein klassisches Memory Leak.
Zur Bestätigung kann man folgenden Befehl ausführen:
SHOW GLOBAL VARIABLES LIKE 'performance_schema';
SELECT * FROM sys.memory_global_by_current_bytes LIMIT 10;Lösungen
Es gibt zwei Hauptansätze zur Behebung:
1. Performance Schema deaktivieren
Falls du es nicht benötigst: Setze performance_schema=0 in der Parametergruppe. Achtung: erfordert einen Neustart.
2. Instanz hochskalieren
Falls du auf das Performance Schema angewiesen bist:
Wechsle von t4g.medium auf eine größere Instanzklasse (z. B. db.r6g.large). So stellst du sicher, dass genügend Spielraum für Workload plus Schema-Tabellen vorhanden ist.
Lessons Learned
- Nicht jeder Speicherverlust ist ein echtes Memory Leak – manchmal ist es nur der Overhead durch Instrumentierung.
- Aurora-Upgrades können Standardwerte ändern. Prüfe die Konfiguration nach jedem Upgrade sorgfältig.
- Kleine Instanzklassen + Performance Schema = Problematische Kombination.
Fazit
Wenn du kürzlich auf Aurora MySQL 3.08.2 upgegradet hast und deine Writer-Instanz aussieht, als hätte sie ein Memory Leak: Überprüfe, ob performance_schema unbemerkt aktiviert wurde.
- Deaktiviere es, wenn du es nicht brauchst.
- Skaliere hoch, wenn du darauf angewiesen bist.
Das Problem lag nicht an deinem Workload – sondern an den geänderten Defaults.
Leave a Reply