AWS RDS MySQL-Leistungsabfall nach zufälliger Zeitspanne

9

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?

    
konrad_pe 19.12.2016, 09:00
quelle

3 Antworten

4

(Zu lang für nur einen Kommentar) Ich weiß, dass Sie eine Menge Dinge überprüft haben, aber ich würde sie gerne mit anderen Augen betrachten ...

Bitte

angeben %Vor%

(Einige der oben genannten Punkte können helfen, die Frage "Verstopfung im Laufe der Zeit" zu lösen.)

Inzwischen, hier sind ein paar Vermutungen / Fragen / etc ...

  • Ein anderer Kunde, der sich die Hardware teilt, ist beschäftigt.
  • Es könnte ein Netzwerkproblem sein?
  • Schrumpfen Sie long_query_time auf 1, damit Sie langsame Abfragen abfangen können.
  • Wann werden Sicherungen für Ihre Instanz ausgeführt?
  • 4s-18s, um ein Megabyte zu laden - wie viel Prozent davon sind SQL-Anweisungen?
  • Chargen Sie die Einsätze? Ist es eine einzelne Transaktion? Werden langwierige Abfragen gleichzeitig ausgeführt?
  • Was, wenn überhaupt, haben MySQL-Tunables von den AWS-Standardeinstellungen geändert?
  • 6 GB buffer_pool auf einer 7,5 GB Partition? Das klingt gefährlich eng. Kannst du sehen, ob es einen Austausch gab?
  • Beliebige PARTITIONing beteiligt? (Natürlich antwortet das CREATE .)
Rick James 24.01.2017 23:39
quelle
0

In Ihrer Beschreibung fehlt eine sehr wichtige Information: Der insgesamt zugewiesene Speicherplatz für die Datenbank. I / O für RDS ist ungefähr 3x der zugewiesene Speicherplatz, so dass Sie für eine 100 GB-Zuteilung rund 300 IOPS erhalten sollten. Dieser zugewiesene Speicherplatz enthält auch Protokolle.

Da Sie nicht wirklich wissen, was vor sich geht, sollte der erste Schritt darin bestehen, eine detaillierte Überwachung zu aktivieren, die Ihnen einen besseren Überblick über die Vorgänge in der Instanz gibt.

Solange Sie während einer Verlangsamung keine weiteren Statistiken gesammelt haben, können Sie versuchen, den zugewiesenen Speicherplatz zu erhöhen, wodurch die verfügbaren IOPS erhöht werden.

Überprüfen Sie auch die Ereignisse für die db - werden Protokolle regelmäßig gelöscht? Das könnte bedeuten, dass nicht genug Platz ist.

Schließlich können Sie versuchen, mit PIOPS (bereitgestellte IOPS) zu gehen, wenn Sie eine Vorstellung davon haben, was die Anwendung benötigt, obwohl es zu diesem Zeitpunkt so klingt, als wäre das eine Vermutung.

    
chris 29.01.2017 03:16
quelle
0

Vielleicht wird Ihr Burst-Guthaben (langsam) aufgebraucht? Schließlich erhalten Sie eine Grundleistung, die möglicherweise "zu langsam" erscheint.

Dies würde auch erklären, warum das Upgrade auf einen anderen Instanztyp hilfreich war, da Sie dann wieder mit einem vollen Burst-Saldo beginnen.

Ich würde vorschlagen, die Größe des Volume zu erhöhen, auch wenn Sie den zusätzlichen Speicherplatz nicht benötigen, , da die Baseline-Leistung linear mit der Volume-Größe wächst .

    
tlossen 03.02.2017 16:45
quelle