Ich versuche, einige Mongo-Protokolle zu durchsuchen, um langsame Vorgänge zu finden, die ich optimieren muss. Die langsame Abfrageprotokollierung ist die Standardeinstellung und protokolliert Vorgänge über 100 ms.
Anstatt MongoDB-Protokolle zu durchsuchen, würde ich dringend empfehlen, die Skripte aus dem Open Source- mtoolsProjekt zu verwenden . HINWEIS: Ich bin nicht der ursprüngliche mtoolsAutor, aber ich bin ein Mitwirkender.
mtools ist eine Sammlung von Python-Skripten, die von dem Schmerz inspiriert wurde, GBs von Protokollen zu durchsuchen, um Informationen zu finden, die für MongoDB-Produktionsbereitstellungen von Interesse sind. Schlüsselskripte sollen in den typischen Befehlszeilen-Workflow der Rohrleitungsausgabe durch aufeinanderfolgende Filter (z. B. mlogfilter --scan | mplotqueries) passen .
Zum Beispiel:
mloginfo --queries ist ein guter Ausgangspunkt: Es aggregiert Abfragemuster, sodass Sie sich auf Abfragen konzentrieren können, die häufig ausgeführt werden und insgesamt mehr Einfluss auf Ihre Bereitstellung haben.mlogfilterist im Wesentlichen ein Grep für MongoDB-Protokolle: Sie können Protokollzeilen nach Namespace, Dauer, Verbindung, Muster und anderen Kriterien filtern. Die --scanOption ist hilfreich , um ineffiziente Abfragen zu identifizieren , die nicht unbedingt eine Sammlung Scan sind.mplotqueries ist ein Tool zur Visualisierung von Protokollen, das sehr hilfreich sein kann, um Muster und Ausreißer zu identifizieren.
Ich denke, man kann mit Sicherheit sagen, dass eine Suche nach COLLSCANS im Allgemeinen Fragen aufzeigt, die Aufmerksamkeit erfordern. Weniger klar ist, dass ich suchen sollte, wenn IXSCANS ein Detail ist.
Sammlungsscans sind im Allgemeinen von Interesse, können aber auch das Ergebnis einmaliger Abfragen oder der erwarteten Verwendung für eine kleine Sammlung sein. Anstatt mich auf den Abfragetyp zu konzentrieren, würde ich langsame Abfragen (oder langsame Vorgänge im Allgemeinen) für Ihre Bereitstellung überprüfen, um ein besseres Verständnis dafür zu erhalten, was Sie möglicherweise verbessern können. Die Verwendung eines Index ist normalerweise gut, aber es gibt ineffiziente Indexverwendungen (z. B. In-Memory-Sortierung oder Regexes ohne Berücksichtigung der Groß- und Kleinschreibung ), die es wert sein können, angesprochen zu werden.
Mein Verständnis ist, dass dies eine binäre Situation ist, eine Abfrage ist entweder ein COLLSCAN oder ein IXSCAN. Wenn ich also nach IXSCAN greife, werde ich ALLE langsamen Abfragen betrachten, die keine COLLSCANS sind. Ist das wahr?
Wenn Sie nach IXSCANsuchen, werden Sie alle Protokollzeilen finden, die erwähnt werden IXSCAN, aber das Ergebnis der langsamen Abfrageprotokollierung ist definitiv nicht binär und variiert auch je nach MongoDB-Serverversion. Während eine effiziente Indexnutzung eine offensichtliche Optimierung darstellt, gibt es eine Reihe interner Abfrageplanerstufen , die für das Verständnis der Abfrageleistung relevant sein können.
Wenn Sie in den Protokollen eine interessante langsame Abfrage finden, wird im nächsten Schritt in der Regel eine detailliertere Überprüfung durchgeführt explain output. Ich verwende explain(true)(auch bekannt als allPlansExecutionModus), da hier Details zu Abfrageplänen angezeigt werden, die berücksichtigt wurden, sowie der Gewinnerplan. Wenn Sie nicht sicher sind, wie Sie die EXPLAIN-Ausgabe für eine langsame Abfrage interpretieren sollen, würde ich empfehlen, sie auf DBA StackExchange zu veröffentlichen .
Es ist erwähnenswert, dass das Erklären einer Abfrage kein Maß für die tatsächliche Leistung bei einer Arbeitslast ist. Im normalen Betrieb werden Abfragepläne zwischengespeichert, während die detaillierte explainAusgabe die Kandidatenindizes und den Abfrageplan speziell neu bewertet. Weitere Informationen finden Sie unter Abfragepläne im MongoDB-Handbuch.
