AWS RDS MySQL-Leistungsabfall nach zufälliger Zeitspanne

FRAGEÜBERSICHT Unsere AWS RDS-Instanz beginnt nach ca. 7-14 Tagen mit einem ziemlich großen Faktor zu verlangsamen (ca. 400% Ladezeiten für einen bestimmten Satz von Abfragen). RDS-Monitoring zeigt keine Anzeichen von Ressourcenknappheit. (Siehe die Frage Update für detaillierte Problembeschreibung)

Frage aktualisieren

Nach mehr als einem Monat der Untersuchung und einiger Entwicklerunterstützung durch AWS bin ich also einer Lösung nicht näher gekommen.

Hier sind ein paar Schritte, die ich mehr oder weniger ohne weitere Hinweise auf die Liste abgehakt habe:

• Index / Fragmentierung (alle Tabellen haben korrekte Indizes / Schlüssel und haben keine Fragmentierung)
• MySQL Stats Update (manuelle Aktualisierung der Statistiken Quelle )
• Thread-Concurrency (Änderung von innodb_thread_concurrency zu verschiedenen Parametern)
• Query Cache Hit Ratio zeigt keine Probleme
• EXPLAIN, um zu sehen, ob SELECTs tatsächlich langsam sind oder keine Indizes / Schlüssel verwenden
• SLOW QUERY LOG (gibt keine Ergebnisse zurück, denn siehe Abschnitt unten, es ist eine Anzahl von vorbereiteten SELECTs)
• RDS und EC2 befinden sich in einer VPC

Zur Erklärung: Das verwendete PlayFramework (2.3.8) enthält BoneCP und wir verwenden eBeans, um unsere Daten auszuwählen. Im Grunde laufe ich durch ein verschachteltes Objekt und all diese untergeordneten Objekte, dies erzeugt ein paar hundert vorbereitete SELECTs für den betreffenden API-Aufruf. Dies sollte grundsätzlich auch für die verwendete Hardware in Ordnung sein, weder CPU noch RAM werden von diesen Operationen ausgiebig genutzt.

Ich habe auch NewRelic für weitere Informationen zu diesem Thema mit einbezogen und einige JVM-Profile erstellt. Offensichtlich wird die meiste Zeit von NETTY / eBeans verbraucht?

Kann jemand daraus einen Sinn machen?

ORIGINAL FRAGE: Problembeschreibung

Unsere AWS RDS-Instanz beginnt nach etwa 7-14 Tagen mit einem ziemlich großen Faktor zu verlangsamen (ca. 400% Ladezeiten für eine bestimmte Gruppe von Abfragen). RDS-Monitoring zeigt keine Anzeichen von Ressourcenknappheit.

Infrastruktur

Wir führen ein PlayFramework-Backend für eine mobile App auf AWS EC2-Instanzen aus, die mit AWS RDS MySQL-Instanzen, einer PROD-Umgebung und einer DEV-Umgebung verbunden sind. Normalerweise zeigt die PROD EC2-Instanz auf die PROD RDS-Instanz, und die DEV EC2 zeigt auf die DEV RDS (Hi vom Captain offensichtlich!); Manchmal lassen wir aber auch den DEV EC2 für einige Testzwecke auf die PROD DB zeigen. Das verwendete PlayFramework arbeitet mit BoneCP.

Detaillierte Beschreibung des Problems

In einem sehr wichtigen Synchronisierungsprozess führt unsere App täglich mehrere API-Aufrufe pro Nutzer durch. Ich habe die Hintergründe der Funktionalität in dieser SO-Frage besprochen, wo dank der Kommentare, Ich könnte das Problem auf ein MySQL-Problem nageln.

Kurz gesagt, der API-Aufruf lädt eine Reihe von Daten, das Maximum ist etwa 1 MB JSON-Daten, die derzeit etwa 18 Sekunden zum Laden benötigt. Wenn alles perfekt läuft, dauert das Laden etwa 4 Sekunden.

Neugierig genug, was das Problem beim letzten Mal "gelöst" hat, war das Upgrade der RDS-Instanz auf einen anderen Instanztyp (von db.m3.large auf db.m4.large, was nur ein sehr marginaler Schritt ist). Jetzt, nach ungefähr 2-3 Wochen, arbeitet die RDS-Instanz wieder langsam wie zuvor. Der Neustart der RDS-Instanz zeigte keine Wirkung. Auch das erneute Starten der EC2-Instanz zeigt keine Wirkung.

Ich habe auch überprüft, ob die Indizes der betroffenen mySQL-Tabellen korrekt gesetzt sind, was der Fall ist. Der API-Aufruf selbst lädt keine BLOB-Felder oder ähnliches, ich habe dies überprüft. Die CPU-Auslastung der RDS-Instanzen liegt die meiste Zeit unter 1%, als ich es mit 100 simultanen API-Aufrufen getestet habe, ging es auf ~ 5%, also ist das nicht der Flaschenhals. Der Speicher ist auch in Ordnung, also denke ich, dass die RDS-Instanz nicht mit dem Austausch beginnt, was den gesamten Prozess verlangsamen könnte.

Es gibt harte Beweise, ein (kleinerer) öffentlicher API-Aufruf in der DEV-Umgebung dauert derzeit 2,30 Sekunden, in der PROD-Umgebung dauert es 4,86 ​​Sekunden. Das ist interessant, weil die DEV-Umgebung sowohl in EC2 als auch in RDS einen wesentlich kleineren Instanztyp hat. Im Grunde gewinnt die Schildkröte das Rennen hier. (Wenn Sie an diesem API-Aufruf interessiert sind, teile ich ihn gerne mit PN mit, aber ich möchte nicht wirklich Links zu API-Aufrufen veröffentlichen, auch wenn sie im Grunde öffentlich sind.)

Fazit

Abschließend fühlt es sich an (ich sage wörtlich "fühlt"), wie die DB nach x Tagen der Nutzung / nach einer gewissen Anzahl von API-Aufrufen verstopft ist. Nicht sicher, ob dies ein RDS-spezifisches Problem ist, sobald ich die DB-Instanz durch Ändern des Instanztyps "weitgehend" zurücksetze, laufen die Dinge schnell und reibungslos ab. Aber meine DB-Instanz aus einem Snapshot alle zwei Wochen neu zu erstellen ist keine Option, besonders wenn ich nicht verstehe, warum das passiert.

Haben Sie irgendwelche Ideen, welche weiteren Schritte ich unternehmen könnte, um diese Angelegenheit zu untersuchen?