Senden von Daten - Amazon Aurora
Unterstützte Engine-VersionenContextWahrscheinliche Ursachen für erhöhte WartezeitenAktionen

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.

Senden von Daten

Dieser sending data-Thread-Zustand zeigt an, dass ein Thread Zeilen für eine Abfrage liest und filtert, um die richtige Ergebnismenge zu ermitteln. Der Name ist irreführend, da er andeutet, dass der Zustand Daten überträgt, nicht sammelt und vorbereitet, um später gesendet zu werden.

Unterstützte Engine-Versionen

Diese Thread-Statusinformationen werden für die folgenden Versionen unterstützt:

  • Aurora MySQL Version 2 bis 2.09.2

Context

Viele Thread-Zustände sind kurzlebig. Operationen, die während sending data auftreten, führen in der Regel eine große Anzahl von Platten- oder Cache-Lesevorgängen durch. Daher ist sending data häufig der am längsten ausgeführte Zustand während der Lebensdauer einer bestimmten Abfrage. Dieser Status wird angezeigt, wenn Aurora MySQL Folgendes tut:

  • Lesen und Verarbeiten von Zeilen für eine SELECT-Anweisung

  • Durchführen einer großen Anzahl von Lesevorgängen von der Festplatte oder vom Speicher

  • Vollständiges Lesen aller Daten aus einer bestimmten Abfrage durchführen

  • Lesen von Daten aus einer Tabelle, einem Index oder der Arbeit einer gespeicherten Prozedur

  • Daten sortieren, gruppieren oder bestellen

Nachdem der sending data-Zustand die Vorbereitung der Daten abgeschlossen hat, zeigt der Thread-Zustand writing to net die Rückgabe der Daten an den Client an. Normalerweise wird writing to net nur erfasst, wenn die Ergebnismenge sehr groß ist oder eine starke Netzwerklatenz die Übertragung verlangsamt.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Das Auftreten von sending data deutet nicht allein auf ein Problem hin. Wenn die Leistung schlecht ist und Sie häufige Instances von sending data sehen, sind die wahrscheinlichsten Ursachen wie folgt.

Ineffiziente Abfrage

In den meisten Fällen ist für diesen Status eine Abfrage verantwortlich, die keinen geeigneten Index verwendet, um die Ergebnismenge einer bestimmten Abfrage zu finden. Betrachten Sie beispielsweise eine Abfrage, die eine 10-Millionen-Datensatztabelle für alle Bestellungen in Kalifornien liest, wobei die Bundesstaatsspalte nicht indiziert oder schlecht indiziert ist. Im letzteren Fall könnte der Index existieren, aber der Optimierer ignoriert ihn aufgrund der geringen Kardinalität.

Suboptimale Serverkonfiguration

Wenn im Zustand sending data mehrere Abfragen erscheinen, ist der Datenbankserver möglicherweise schlecht konfiguriert. Insbesondere könnte der Server die folgenden Probleme haben:

  • Der Datenbankserver verfügt nicht über genügend Rechenkapazität: Festplatten-I/O, Festplattentyp und Geschwindigkeit, CPU oder Anzahl der CPUs.

  • Der Server sortiert nach allokierten Ressourcen, wie dem InnoDB-Pufferpool für InnoDB-Tabellen oder dem Schlüsselpuffer für MyIsam-Tabellen.

  • Arbeitsspeichereinstellungen pro Thread wie sort_buffer, read_buffer und join_buffer verbrauchen mehr RAM als erforderlich, wodurch der physische Server an Speicherressourcen mangelt.

Aktionen

Die allgemeine Richtlinie besteht darin, Abfragen zu finden, die eine große Anzahl von Zeilen zurückgeben, indem Sie das Leistungsschema überprüfen. Wenn die Protokollierung von Abfragen aktiviert ist, die keine Indizes verwenden, können Sie auch die Ergebnisse der langsamen Protokolle untersuchen.

Schalten Sie das Leistungsschema ein, wenn es nicht aktiviert ist

Performance Insights meldet Thread-Status nur, wenn Leistungsschema-Instrumente nicht aktiviert sind. Wenn Leistungsschema-Instrumente aktiviert sind, meldet Performance Insights stattdessen Warteereignisse. Leistungsschema-Instrumente bieten zusätzliche Erkenntnisse und bessere Tools, wenn Sie potenzielle Leistungsprobleme untersuchen. Daher wird empfohlen, dass Sie das Leistungsschema aktivieren. Weitere Informationen finden Sie unter Überblick über das Leistungsschema für Performance Insights auf Aurora My SQL My SQL.

Prüfen Sie die Speichereinstellungen

Untersuchen Sie die Speichereinstellungen für die primären Pufferpools. Stellen Sie sicher, dass diese Pools für die Workload entsprechend dimensioniert sind. Wenn Ihre Datenbank mehrere Pufferpool-Instances verwendet, stellen Sie sicher, dass sie nicht in viele kleine Pufferpools unterteilt sind. Threads können jeweils nur einen Pufferpool verwenden.

Stellen Sie sicher, dass die folgenden Speichereinstellungen, die für jeden Thread verwendet werden, richtig dimensioniert sind:

  • read_buffer

  • read_rnd_buffer

  • sort_buffer

  • join_buffer

  • binlog_cache

Wenn Sie keinen bestimmten Grund haben, die Einstellungen zu ändern, verwenden Sie die Standardwerte.

Untersuchen Sie die Erklärungspläne zur Indexverwendung

Überprüfen Sie bei Abfragen im sending data-Thread-Zustand den Plan, um festzustellen, ob geeignete Indizes verwendet werden. Wenn eine Abfrage keinen nützlichen Index verwendet, sollten Sie Hinweise wie USE INDEX oder FORCE INDEX hinzufügen. Hinweise können die Zeit zum Ausführen einer Abfrage erheblich verlängern oder verkürzen, seien Sie also vorsichtig, bevor Sie sie hinzufügen.

Überprüfen Sie das Volume der zurückgegebenen Daten

Überprüfen Sie die abgefragten Tabellen und die Menge der Daten, die sie enthalten. Kann irgendeine dieser Daten archiviert werden? In vielen Fällen ist die Ursache für schlechte Ausführungszeiten der Abfragen nicht das Ergebnis des Abfrageplans, sondern das Datenvolumen, das verarbeitet werden soll. Viele Entwickler fügen einer Datenbank sehr effizient Daten hinzu, berücksichtigen jedoch selten den Lebenszyklus von Datensätzen in den Entwurfs- und Entwicklungsphasen.

Suchen Sie nach Abfragen, die in Datenbanken mit geringem Volume gut funktionieren, aber in Ihrem aktuellen System schlecht funktionieren. Manchmal erkennen Entwickler, die bestimmte Abfragen entwerfen, möglicherweise nicht, dass diese Abfragen 350.000 Zeilen zurückgeben. Die Entwickler haben die Abfragen möglicherweise in einer Umgebung mit geringerem Volumen und kleineren Datensätzen entwickelt als in Produktionsumgebungen.

Auf Parallelitätsprobleme prüfen

Überprüfen Sie, ob mehrere Abfragen desselben Typs gleichzeitig ausgeführt werden. Einige Formen von Abfragen werden effizient ausgeführt, wenn sie alleine laufen. Wenn jedoch ähnliche Abfrageformen zusammen oder in hohem Volumen ausgeführt werden, können sie Parallelitätsprobleme verursachen. Oft werden diese Probleme verursacht, wenn die Datenbank temporäre Tabellen verwendet, um Ergebnisse zu rendern. Eine restriktive Transaktionsisolationsstufe kann auch Parallelitätsprobleme verursachen.

Wenn Tabellen gleichzeitig gelesen und geschrieben werden, verwendet die Datenbank möglicherweise Sperren. Um Perioden schlechter Leistung zu identifizieren, untersuchen Sie die Verwendung von Datenbanken durch umfangreiche Batch-Prozesse. Um die letzten Sperren und Rollbacks anzuzeigen, überprüfen Sie die Ausgabe des SHOW ENGINE INNODB STATUS-Befehls.

Überprüfen der Struktur Ihrer Abfrage

Prüfen Sie, ob erfasste Abfragen aus diesen Status Unterabfragen verwenden. Diese Art von Abfrage führt häufig zu einer schlechten Leistung, da die Datenbank die Ergebnisse intern kompiliert und sie dann wieder in die Abfrage einfügt, um Daten zu rendern. Dieser Prozess ist ein zusätzlicher Schritt für die Datenbank. In vielen Fällen kann dieser Schritt zu einer schlechten Leistung in einem stark gleichzeitigen Ladezustand führen.

Überprüfen Sie auch, ob Ihre Abfragen eine große Anzahl von ORDER BY- und GROUP BY-Klauseln verwenden. Bei solchen Operationen muss die Datenbank oft zuerst den gesamten Datensatz im Speicher bilden. Dann muss es auf eine bestimmte Weise bestellen oder gruppieren, bevor es an den Kunden zurückgegeben wird.