Lassen Sie mich emotional aufatmen: DBA ist wirklich nicht abgedeckt

3.3.3 Nutzungsleistungsanalyse: begrenzt

3.4 Diagnose zeitweiliger Probleme

Wenn das System gelegentlich pausiert, Abfragen verlangsamt oder Shadowing-Probleme verursacht, versuchen Sie, das Problem nicht durch Versuch und Irrtum zu lösen: Das Risiko ist hoch

3.4.1 Problem mit einer einzelnen Abfrage oder einem Dienstproblem

Verwenden Sie SHOW GLOBAL STATUS

Höhere Häufigkeit: 1s/Zeit Führen Sie diesen Befehl aus, um Daten abzurufen. Das Problem tritt durch den Zähler auf

Verwenden Sie SHOW PROCESSLIST [Referenz] Zeigen Sie an, welche Threads ausgeführt werden

[MySQL-Datenbank] Interpretation von Kapitel 3: Serverleistungsanalyse (Teil 2)

Verwenden Sie das Abfrageprotokoll

, um langsame Abfragen zu aktivieren, legen Sie die globale long_query_time=0 fest und bestätigen Sie, dass alle Verbindungen die neuen Einstellungen übernehmen (möglicherweise müssen Sie sie zurücksetzen). Alle Verbindungen werden wirksam)

Achten Sie auf die Protokolle während des Zeitraums, in dem der Durchsatz plötzlich abfällt. Die Abfrage wird während der Abschlussphase in das langsame Abfrageprotokoll geschrieben

Gute Tools erhalten das Doppelte Ergebnis mit halbem Aufwand: tcpdump, pt-query-digest, Percona Server

Die gefundenen Probleme verstehen

Daten visualisieren: gnuplot /R (Zeichenwerkzeug)

gnuplot:

Installation Einige Befehle: Allgemeine Tipps Erste Schritte Tutorial 2 Gnuplot-Datenvisualisierung

Empfehlung: Verwenden Sie zuerst die ersten beiden Methoden, die kostengünstig sind und interaktiv Daten über einfache Shell-Skripte sammeln oder wiederholt ausgeführt werden Abfragen

3.4.2 Diagnosedaten abrufen

Intermittierendes Problem, versuchen Sie, so viele Daten wie möglich zu sammeln (nicht nur, wenn das Problem auftritt)

Klar: 1. Es gibt Möglichkeiten zur Unterscheidung, wann Probleme auftreten: Auslöser; 2. Tools zum Sammeln von Diagnosedaten

Diagnoseauslöser

Fehler: In dem Zeitraum, in dem kein Problem auftritt, werden viele Diagnosedaten erfasst Zeitverschwendung (dies steht nicht im Widerspruch zum vorherigen, lesen Sie es sorgfältig durch)

Fehlende Erkennung: Wenn das Problem auftritt Es wurden keine Daten erfasst, eine Gelegenheit wurde verpasst. Stellen Sie sicher, dass der Auslöser das Problem vorher wirklich identifizieren kann Beginn der Sammlung

Gute Auslöser:

Finden Sie einige, die mit normalen Zeiten gut funktionieren. Vergleichen Sie Indikatoren mit Schwellenwerten.

Wählen Sie einen geeigneten Schwellenwert: hoch genug (nicht ausgelöst, wenn normal), nicht zu hoch (wird nicht übersehen, wenn Probleme auftreten)

Empfohlenes Tool pt-stalk【Referenz】【2】Trigger, auf eine bestimmte Bedingung eingestellt, um die Häufigkeit der Schwellenwertprüfung von Variablen aufzuzeichnen und zu konfigurieren überwacht werden

Welche Art von Daten werden gesammelt?

Ausführungszeit: Arbeitszeit und Wartezeit

Alle Daten sammeln, die möglich sind innerhalb des erforderlichen Zeitraums erfasst werden

Der Grund für das unbekannte Problem : 1 , der Server muss viel Arbeit leisten, was zu einer hohen CPU-Verbrauchsrate führt 2 . Warten auf Ressourcenfreigabe

Erfassen Sie Diagnosedaten mit verschiedenen Methoden, um den Grund zu bestätigen:

1. Analysebericht: Bestätigen Sie, ob zu viele Arbeiten vorhanden sind, Tool: tcpdump überwacht das Öffnen des TCP-Verkehrsmodus und Schließen, langsames Abfrageprotokoll

2. Warteanalyse: Bestätigen Sie, ob eine große Anzahl von Wartezeiten vorliegt, GDB-Stack-Trace-Informationen, zeigen Sie die Prozessliste an, zeigen Sie den Innodb-Status an, um Threads und den Transaktionsstatus zu beobachten

Interpretieren die Ergebnisdaten

Zweck: 1. Ob das Problem wirklich aufgetreten ist; 2. Ob es eine offensichtliche Sprungänderung gibt

Tools:

oprofile verwendet den auf CPU-Hardwareebene bereitgestellten Leistungsindikator (Leistungszähler), um uns durch Zählen von Stichproben dabei zu helfen, den „Schuldigen“ zu finden, der die CPU auf Prozess-, Funktions- und Codeebene belegt. Beispiel [Referenz]

Der Befehl opreport ist eine Möglichkeit, die CPU-Nutzung auf der Prozess- bzw. Funktionsebene anzuzeigen

 samples |                            %|
-----------------------------------------------------
     镜像内发生的采样次数     采样次数所占总采样次数的百分比      镜像名称

Nach dem Login kopieren

Der Befehl opannotate kann die statistischen Informationen der CPU-Nutzung auf Codeebene anzeigen

GDB:In der Linux-Anwendungsentwicklung ist GDB der am häufigsten verwendete Debugger (das debuggte Objekt ist eine ausführbare Datei). Es kann Haltepunkte im Programm festlegen, Variablenwerte anzeigen und verfolgen Ausführungsprozess des Programms Schritt für Schritt (Daten, Quellcode), Speicher- und Stapelinformationen anzeigen. Mit diesen Funktionen des Debuggers lassen sich nicht-grammatikalische Fehler im Programm leicht finden. [Referenz] [Referenz] Syntax und Beispiele

3.4.3 Ein Diagnosefall

Intermittierendes Leistungsproblem, mit relevanten Kenntnissen von MySQL, innodb, GNU/Linux

Eindeutig: 1. Was ist das Problem, beschreiben Sie es klar 2. Welche Maßnahmen wurden ergriffen, um das Problem zu lösen?

Start: 1. Verstehen Sie das Verhalten des Servers. 2. Sortieren Sie die Statusparameter des Servers und konfigurieren Sie die Software- und Hardwareumgebung (pt-summary pt-mysql -Zusammenfassung)

Lassen Sie sich nicht von verschiedenen Situationen ablenken, die zu unangebracht sind. Schreiben Sie die Fragen auf Zettel und kreuzen Sie sie an.

Handelt es sich um eine Ursache oder ein Ergebnis ? ? ?

Mögliche Gründe, warum Ressourcen ineffizient geworden sind:

1. Ressourcen werden nicht ausreichend genutzt; 2. Ressourcen werden nicht richtig zugeordnet; Ressourcen Schaden oder Ausfall

3.5 Andere Analysetools

USER_STATISTICS: Einige Tabellen messen und prüfen Datenbankaktivitäten

strace: Systemaufrufe untersuchen, tatsächliche Zeit verwenden , Unvorhersehbarkeit, Overhead, oprofile Nutzungskosten CPU-Zyklen

Zusammenfassung:

Die effektivste Art, Leistung zu definieren, ist die Reaktionszeit
Sie können nicht effektiv optimieren, wenn Sie sie nicht messen können. Die Arbeit zur Leistungsoptimierung muss auf einer qualitativ hochwertigen, umfassenden und vollständigen Reaktionszeitmessung basieren.
Die Der beste Ausgangspunkt für die Messung ist eine Anwendung. Auch wenn das Problem in der zugrunde liegenden Datenbank liegt, ist es mit guten Messungen einfacher, das Problem zu finden
Die meisten Systeme können nicht vollständig messen, und manchmal können Messungen durchgeführt werden falsche Ergebnisse haben. Finden Sie Wege, einige Einschränkungen zu umgehen und sich der Mängel und Unsicherheiten der Methode bewusst zu sein
Eine vollständige Messung erzeugt eine große Datenmenge, die analysiert werden muss Sie müssen einen Profiler verwenden (bestes Tool)
Profiling-Bericht: fasst Informationen zusammen, beschönigt und wirft viele Details weg, sagt Ihnen nicht, was fehlt, kann nicht sein völlig verlassen
Zwei zeitraubende Vorgänge: Arbeit oder Warten Der Profiler kann fast nur die für die Arbeit aufgewendete Zeit messen, daher ist das Warten auf das Teilen manchmal eine nützliche Ergänzung, insbesondere wenn die Die CPU-Auslastung ist gering, aber die Arbeit wurde nie abgeschlossen.
Optimierung und Verbesserung sind zwei verschiedene Dinge. Wenn die Kosten einer kontinuierlichen Verbesserung den Nutzen übersteigen, sollte die Optimierung gestoppt werden 🎜>

in einem Wort:

Erst klären Sie die Problem, wählen Sie die geeignete Technologie, nutzen Sie die Tools gut, seien Sie vorsichtig genug, haben Sie eine klare Logik und bleiben Sie dabei, nennen Sie nicht die Gründe und Ergebnisse. Verwirrung, nehmen Sie keine Änderungen am System vor, bevor Sie das Problem festgestellt haben Verwandte Artikel:

[MySQL-Datenbank] Kapitel 2 Interpretation: MySQL-Benchmark-Test

[MySQL-Datenbank] Interpretation von Kapitel 3: Server-Leistungsanalyse (Teil 1)

Das obige ist der detaillierte Inhalt von[MySQL-Datenbank] Interpretation von Kapitel 3: Serverleistungsanalyse (Teil 2). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!