io/table/sql/handler - Amazon Aurora
Unterstützte Engine-VersionenKontextWahrscheinliche 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.

io/table/sql/handler

Dieses io/table/sql/handler-Ereignis tritt ein, wenn Arbeit an eine Speicher-Engine delegiert wurde.

Unterstützte Engine-Versionen

Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:

  • Aurora Meine SQL Version 3:3.01.0 und 3.01.1

  • Aurora Meine SQL Version 2

Kontext

Das io/table-Ereignis zeigt ein Warten auf den Zugriff auf eine Tabelle an. Dieses Ereignis tritt unabhängig davon auf, ob die Daten im Pufferpool zwischengespeichert werden oder über die Festplatte darauf zugegriffen wird. Das io/table/sql/handler-Ereignis weist auf eine Zunahme der Workload-Aktivität hin.

Ein Handler ist eine Routine, die auf eine bestimmte Art von Daten spezialisiert ist oder sich auf bestimmte spezielle Aufgaben konzentriert. Beispielsweise empfängt und verdaut ein Ereignis-Handler Ereignisse und Signale vom Betriebssystem oder von einer Benutzeroberfläche. Ein Speicherhandler führt Aufgaben im Zusammenhang mit dem Speicher aus. Ein Dateieingabe-Handler ist eine Funktion, die Dateieingaben empfängt und je nach Kontext spezielle Aufgaben für die Daten ausführt.

Ansichten wie performance_schema.events_waits_current zeigen oft io/table/sql/handler an, wenn das eigentliche Warten ein verschachteltes Warteereignis wie eine Sperre ist. Wenn das tatsächliche Warten nicht io/table/sql/handler ist, meldet Performance Insights das verschachtelte Warteereignis. Wenn Performance Insights berichtetio/table/sql/handler, handelt es sich dabei um eine InnoDB-Verarbeitung der I/O-Anfrage und nicht um ein verstecktes verschachteltes Warteereignis. Weitere Informationen finden Sie unter Performance Schema Atom and Molecule Events im My SQL Reference Manual.

Anmerkung

In den SQL Versionen 3.01.0 und 3.01.1 von Aurora My synch/mutex/innodb/aurora_lock_thread_slot_futex wird dies jedoch als gemeldet. io/table/sql/handler

Das io/table/sql/handler-Ereignis erscheint oft in Top-Warteereignissen mit I/O-Wartezeiten wie io/aurora_redo_log_flush und io/file/innodb/innodb_data_file.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

In Performance Insights weisen plötzliche Spitzen im io/table/sql/handler-Ereignis auf eine Zunahme der Workload-Aktivität hin. Erhöhte Aktivität bedeutet eine erhöhte I/O.

Performance Insights filtert das Verschachtelungsereignis IDs und meldet keine io/table/sql/handler Wartezeit, wenn es sich bei dem zugrunde liegenden verschachtelten Ereignis um ein Lock-Wait handelt. Wenn beispielsweise das Grundursachenereignis synch/mutex/innodb/aurora_lock_thread_slot_futex ist, zeigt Performance Insights diese Wartezeit in den Top-Warteereignissen an und nicht io/table/sql/handler.

In Ansichten wie performance_schema.events_waits_current werden Wartezeiten für io/table/sql/handler oft angezeigt, wenn das eigentliche Warten ein verschachteltes Warteereignis wie eine Sperre ist. Wenn die tatsächliche Wartezeit von io/table/sql/handler abweicht, schlägt Performance Insights die verschachtelte Wartezeit nach und meldet die tatsächliche Wartezeit anstelle von io/table/sql/handler. Wenn Performance Insights io/table/sql/handler meldet, ist die tatsächliche Wartezeit io/table/sql/handler und kein verstecktes verschachteltes Warteereignis. Weitere Informationen finden Sie unter Performance Schema Atom and Molecule Events im My SQL 5.7-Referenzhandbuch.

Anmerkung

In den SQL Versionen 3.01.0 und 3.01.1 von Aurora My synch/mutex/innodb/aurora_lock_thread_slot_futex wird dies jedoch als gemeldet. io/table/sql/handler

Aktionen

Wenn das Warteereignis die Datenbankaktivität dominiert, weist dies nicht unbedingt auf ein Leistungsproblem hin. Ein Warteereignis ist immer im Vordergrund, wenn die Datenbank aktiv ist. Sie müssen nur handeln, wenn sich die Leistung verschlechtert.

Abhängig von den anderen angezeigten Warteereignissen empfehlen wir unterschiedliche Aktionen.

Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen

Normalerweise weisen Datenbanken mit mäßiger bis erheblicher Last Warteereignisse auf. Die Warteereignisse sind möglicherweise akzeptabel, wenn die Leistung optimal ist. Wenn die Leistung nicht optimal ist, untersuchen Sie, wo die Datenbank die meiste Zeit verbringt. Schauen Sie sich die Warteereignisse an, die zur höchsten Belastung beitragen und finden Sie heraus, ob Sie die Datenbank und die Anwendung optimieren können, um diese Ereignisse zu reduzieren.

Um SQL Abfragen zu finden, die für eine hohe Auslastung verantwortlich sind

  1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die RDS Amazon-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Performance-Insights aus.

  3. Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt.

  4. Wählen Sie im Diagramm zur Datenbanklast die Option Nach Wartezeit aufteilen.

  5. Wählen Sie unten auf der Seite Top ausSQL.

    In der Tabelle sind die SQL Abfragen aufgeführt, die für den Ladevorgang verantwortlich sind. Diejenigen, die an der Spitze der Liste stehen, sind am meisten verantwortlich. Konzentrieren Sie sich auf diese Aussagen, um einen Engpass zu beheben.

Einen nützlichen Überblick über die Fehlerbehebung mit Performance Insights finden Sie im Blogbeitrag Analysieren Sie Amazon Aurora My SQL Workloads with Performance Insights.

Überprüfen Sie, ob eine Korrelation mit den Performance-Insights-Zählermetriken vorliegt

Suchen Sie nach Performance-Insights-Zählermetriken wie Innodb_rows_changed. Wenn Zählermetriken mit io/table/sql/handler korreliert sind, gehen Sie folgendermaßen vor:

  1. Suchen Sie in Performance Insights nach den SQL Kontoauszügen, in denen das Ereignis mit der io/table/sql/handler höchsten Wartezeit berücksichtigt wurde. Optimieren Sie diese Anweisung, wenn möglich, damit sie weniger Zeilen zurückgibt.

  2. Rufen Sie die obersten Tabellen aus den schema_table_statistics- und x$schema_table_statistics-Ansichten ab. Diese Ansichten zeigen den Zeitaufwand pro Tabelle an. Weitere Informationen finden Sie unter Die Ansichten schema_table_statistics und x$schema_table_statistics im My Reference Manual. SQL

    Standardmäßig werden Zeilen nach absteigender Gesamtwartezeit sortiert. Tabellen mit dem größten Streit erscheinen zuerst. Die Ausgabe gibt an, ob Zeit für Lese-, Schreibvorgänge, Abrufe, Einfügungen, Aktualisierungen oder Löschungen aufgewendet wird. Das folgende Beispiel wurde auf einer Aurora My SQL 2.09.1-Instance ausgeführt.

    mysql> select * from sys.schema_table_statistics limit 1\G

*************************** 1. row ***************************
     table_schema: read_only_db
       table_name: sbtest41
    total_latency: 54.11 m
     rows_fetched: 6001557
    fetch_latency: 39.14 m
    rows_inserted: 14833
   insert_latency: 5.78 m
     rows_updated: 30470
   update_latency: 5.39 m
     rows_deleted: 14833
   delete_latency: 3.81 m
 io_read_requests: NULL
          io_read: NULL
  io_read_latency: NULL
io_write_requests: NULL
         io_write: NULL
 io_write_latency: NULL
 io_misc_requests: NULL
  io_misc_latency: NULL
1 row in set (0.11 sec)

Nach anderen korrelierten Warteereignissen suchen

Wenn synch/sxlock/innodb/btr_search_latch und io/table/sql/handler zusammen am meisten zur DB-Ladeanomalie beitragen, prüfen Sie, ob die Variable innodb_adaptive_hash_index aktiviert ist. Wenn dies der Fall ist, sollten Sie den innodb_adaptive_hash_index_parts-Parameterwert erhöhen.

Wenn der Adaptive-Hash-Index ausgeschaltet, erwägen Sie, ihn einzuschalten. Weitere Informationen zum My SQL Adaptive Hash Index finden Sie in den folgenden Ressourcen:

Anmerkung

Der Adaptive-Hash-Index wird auf Aurora-Reader-DB-Instances nicht unterstützt.

In einigen Fällen kann die Leistung auf einer Reader-Instance schwach sein, wenn synch/sxlock/innodb/btr_search_latch und io/table/sql/handler dominant sind. Wenn ja, erwägen Sie, die Workload vorübergehend auf die Writer-DB-Instance umzuleiten und den Adaptive-Hash-Index zu aktivieren.