BA sollte mit InnoDB vertraut sein: Die Semaphor-Wartezeit hat > 600 Sekunden gedauert. Wir haben den Server absichtlich zum Absturz gebracht, weil er scheinbar hängen geblieben ist festgestellt, dass eine Verriegelung vorhanden ist, die seit mehr als 600 Sekunden blockiert ist. Wenn die Sperre nach 10 aufeinanderfolgenden Erkennungen nicht freigegeben wird, wird eine Panik ausgelöst, um zu verhindern, dass der Dienst weiterhin hängt.
Was ist passiert?
Versionsnummer: MySQL 5.5.40
Das Protokoll gibt weiterhin wartende Threads aus Datenwörterbuchsperre, Speicherort ist dict0dict.c Zeile 305, Wartezeit übersteigt 900 Sekunden.
Der Thread, der die Sperre hält, ist 139998697924352, was hexadezimal 7f53fca8a700 ist.
--Thread 139998393616128 hat in Zeile 305 von dict0dict.c 934,00 Sekunden lang auf das Semaphore:X-Lock auf RW-Latch bei 0x105a1b8 gewartet, das in der Datei dict0dict.c, Zeile 748a, erstellt wurde (Thread-ID 1399986979243). 52 ) hat es im exklusiven Modus reserviert, Anzahl der Leser 0, Waiters-Flag 1, lock_word: 0. Letzter Lesevorgang in Datei dict0dict.c, Zeile 302. Letzter Schreibvorgang in Datei /pb2/build/sb_0-13157587-1410170252.03/rpm/BUILD/mysql- gesperrt. 5.5 .40/mysql-5.5.40/storage/innobase/dict/dict0dict.c Zeile 305
Sperren Sie die Transaktionsinformationen von Thread 139998697924352 und fragen Sie den Datenwörterbuchtabellenvorgang ab .
---TRANSACTION 0, nicht mit der Aktualisierung der Tabellenstatistik begonnen: MySQL-Thread-ID 14075, Betriebssystem-Thread-Handle 0x7f53fca8a700, Abfrage-ID 110414021 21.14.5.139 jzjkusrSELECT ROUND(SUM(DATA_LENGTH+INDEX_LENGTH+DATA_FREE. )/102 4 /1024/1024) AS MY_DB_TOTAL_SIZE FROM information_schema.TABLES
Überprüfen Sie, ob der sperrenhaltende Thread 139998697924352 auf andere Sperren wartet.
Thread 139998697924352 gefunden, Selbstsperre befindet sich in btr0sea.c Zeile 1134, diese Sperrstruktur hängt mit AHI zusammen.
--Thread 139998697924352 hat in btr0sea.c Zeile 1134 934,00 Sekunden lang gewartet, das Semaphor: id 139998697924352) hat es im Modus „Warten exklusiv“ reserviert, Anzahl der Leser 1, Kellner-Flag 1, Sperrwort: ffffffffffffffffLetztes Lesen in der Datei btr0sea.c gesperrt, Zeile 1057Letztes Schreiben in der Datei /pb2/build/sb_0-13157587-1410170252.03/rpm/BUILD gesperrt /mysql-5.5.40/mysql-5.5.40/storage/innobase/btr/btr0sea.c Zeile 1134
Schauen Sie sich als nächstes an, in welcher Funktion die beiden Sperrstrukturen sind:
dict0dict.c Zeile 305 in der Funktion dict_table_stats_lock
btr0sea.c Zeile 1134 in der Funktion btr_search_drop_page_hash_index
Unter welchen Umständen werden diese Funktionen aufgerufen?
Innodb_table_monitor aktivieren und dict_table_stats_lock aufrufen, um die X-Sperre bei der Protokollausgabe anzuwenden. Dieser Fall ist nicht aktiviert.
Wenn innodb_stats_on_metadata aktiviert ist, löst die Abfrage der Datenwörterbuchtabelle den Aktualisierungsvorgang für statistische Informationen aus und die X-Sperre für dict_table_stats_lock wird aufgerufen. Dies entspricht den Transaktionsinformationen des Threads, der die Sperre hält.
Adaptive Hash Index (AHI) ist eine Hash-Tabellenstruktur, die von InnoDB verwendet wird, um die Indexseitensuche zu beschleunigen. Wenn die Anzahl der Seitenbesuche bestimmte Bedingungen erfüllt, wird die Adresse dieser Seite in einer Hash-Tabelle gespeichert, um die Kosten für B-Tree-Abfragen zu reduzieren.
MySQL Version 5.5 AHI verwendet die globale Sperre btr_search_latch, um die Konsistenz von Hash-Tabellenänderungen aufrechtzuerhalten.
Der Status des InnoDB-Pufferpools zeigt, dass der freie Puffer grundsätzlich 0 im Leerlauf bleibt. Wenn der InnoDB-Pufferpool eine Datenseite entfernt, ruft er die Funktion btr_search_drop_page_hash_index auf, um die Datenseite aus dem AHI zu löschen.
--------------------------------PUFFERPOOL UND SPEICHER----- --- ------Gesamtspeicher zugewiesen 17582522368 in zusätzlicher Pool zugewiesen 0
Wörterbuchspeicher zugewiesen 4289681
Pufferpoolgröße 1048576
KOSTENLOSE Puffer 0
Datenbankseiten 1040831
Alte Datenbankseiten 384193
Geänderte Datenbankseiten 0
Zusammenfassung
AHIs globale Sperre btr_search_latch ist oft ein Hotspot der Konkurrenz, der sich auf die Leistung auswirkt. Sie wurde nach Version 5.7 verbessert und ist wie der InnoDB-Puffer in mehrere Instanzen aufgeteilt. Wenn in diesem Fall der Parameter Innodb_stats_on_metadata aktiviert ist, werden die statistischen Informationen beim Abfragen von Metadateninformationen aktualisiert und das Datenwörterbuch wird gesperrt, wodurch eine große Anzahl von Geschäftsvorgängen blockiert wird. Außerdem wird die Tabelle aufgrund unzureichenden Pufferpoolspeichers entfernt alte Seiten und löst den btr_search_latch-Sperrwettbewerb von AHI aus, der letztendlich dazu führt, dass das Semaphor eine Zeitüberschreitung erfährt und abstürzt.
>> Mit Hilfe der drei magischen Waffen Sed, Awk und Grep wurde die Effizienz zwar verbessert, ist aber immer noch nicht effizient genug. Um faul zu sein, habe ich ein kleines Programm geschrieben, um dem DBA zu helfen, diese Beziehungen schnell zu klären.
Die Verwendung ist wie folgt:
hongbin@MBP ~>
Zielversion, suchen Sie beim Überprüfen des Codes nach der entsprechenden Version:
MySQL Server-Version: '5.7.16-log'
Die Anzahl der Semaphor-Abstürze die im Protokoll angezeigt werden und die Anzahl der MySQL-Starts größer ist als die Anzahl der Abstürze, kann dies durch einen normalen Start oder andere Abstürze verursacht werden:
***** ******* MySQL-Dienststartanzahl ******* ***
MySQL-Semaphor-Absturz -> 12:18" "2018-08-14 12:13:43" "2018 -08-16 13:42:36"]
MySQL-Dienststart -> 3 Mal [ „2018-08-13 23:12:59“ „2018-08-14 12:15:20“ „2018-08-16 13:46:37“]
Welche RW-Latches Warten die Threads hauptsächlich darauf? Der Inhalt umfasst: Sperrposition, Anzahl der Vorkommen, Thread-ID (Auftrittszeiten), Fokus auf diejenigen, die häufiger erscheinen:
******* ***** Welcher Thread hat auf die Sperre gewartet **********row0purge.cc:861 - > 1)trx0undo.ic:171 –> (57) 140477029533440:(56) 140617407219456:(55 ) 140477035656960:( 52) 140477035124480:(29) 14047702766976 0:(22) 140617634944768:(21) 140617634146048:(21) 140477019948800:(21) 140477026604800:(20 ) 140477022078720:( 18) 140477018883840:(16) 140477038585600:(15) 140477028734720:(10) 140477022877440:(9) 140477034325760 :(1) 140477031663360:(1)srv0srv.cc:1968 -> 140617714235136:(23)ha_innodb.cc:5510 -&g t; :(52) 140617395771136:(50) 140617636275968:(45) 140617632548608:(40) 140617634146048:(33) 1406176396756 48:(32) 140617397102336:(28) 140617639409408:(23) 140617635743488:(21) 140617637811968: (18) 140617638610688:(16) 140617399232256:(12) 140617638344448:(10) 140617638078208:(10 () 3) 140617402693376:(2) 140477037254400:(1)dict0dict.cc:1239 -> 136 140477122623232:(50) 140617392842496:(35) 140202726487808:( 26) 140477123688192:(12) 140477038851840:(5) 1404770300659 20:( 4) 140617634412288:(4)row0trunc.cc:1835 ->
Welche Schreibthreads X-Sperren für die oben genannten Sperren halten, konzentrieren Sie sich auf diejenigen, die häufiger vorkommen:
************ Welche Writer-Threads blockieren bei ************
140616681907968 -> 1 trx0undo.ic:171:(1)140477173069568 -> cc:1968:(185) row0purge.cc:861:(57) row0trunc.cc:1835:(1)140617682765568 -> 29 srv0s rv.cc: 1968:(23) ha_innodb.cc:5510:(5) row0purge .cc:861:(1)
Schreiben Sie die dem Thread entsprechenden Transaktionsinformationen. Es können auch Protokolldatensätze vorhanden sein, die keine Transaktionsinformationen ausgeben:
** ******** Diese Writer-Threads trx-Status **********MySQL-Thread-ID 83874, Betriebssystem-Thread-Handle 140477173069568, Abfrage-ID 13139674 10.0.1.146 AML wird aus Referenztabellen gelöscht
Statistik zur S-Sperre, die von Autoren-Threads gehalten wird:
****Diese Autoren-Threads sind zum letzten Mal gesperrt ****
140477173069568 -> 243 row0purge.cc:861:(243)140617682765568 -> 24 row0purge.cc:861:(24)140616681907968 -> 1 trx0undo.ic:190:(1 )
Statistiken zu Schreibthreads mit X-Sperren:
****Diese Autorenthreads haben beim letzten Mal Schreibsperren ****
140477173069568 -> 243 dict0stats .cc:2366:(243)140617682765568 -> 24 dict0stats.cc:2366:(24)140616681907968 -> 1 b uf0flu.cc:1198:(1)
Bis nach der Veranstaltung Bei der Protokollanalyse ist es möglich, dass die Transaktionsinformationen des Threads nicht im Protokoll ausgegeben werden und es unmöglich ist, die spezifischen Vorgänge zu kennen, die von der Transaktion ausgeführt werden. Als Reaktion auf diese Situation hat das Miniprogramm die Möglichkeit hinzugefügt, Transaktionsinformationen während der Transaktion zu sammeln.
Die Verwendung ist wie folgt:
hongbin@MBP ~> mysqldba -uxxx -pxxx doctor -w
Es überwacht das Ziel-MySQL auf Fehler Wenn im Protokoll das Schlüsselwort „Ein Autor (Thread-ID 140616681907968) hat es im Modus reserviert“ erscheint, fragen Sie die Transaktionsinformationen in ps ab und speichern Sie sie.
Das Obige ist nur eine Verwendung des Miniprogramms, das DBA bedient, es warten noch weitere Funktionen darauf, von Ihnen entdeckt zu werden. Teilen Sie mir gerne Ihre Gedanken mit.
Weitere technische Artikel zu SQL finden Sie in der Spalte SQL-Tutorial.
Das obige ist der detaillierte Inhalt vonErinnern Sie sich an eine Analyse des MySQL-Semaphor-Absturzes. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
