Ein Performance-Spickzettel für MongoDB

Die Datenbankleistung wirkt sich auf die Unternehmensleistung aus, und wir neigen dazu, nach einer schnellen Lösung zu suchen. Es gibt viele verschiedene Möglichkeiten, die Leistung in MongoDB zu verbessern. In diesem Blog helfen wir Ihnen, Ihre Datenbankarbeitslast und Dinge, die ihr schaden können, besser zu verstehen. Das Wissen darüber, wie begrenzte Ressourcen verwendet werden, ist für jeden, der eine Produktionsdatenbank verwaltet, unerlässlich.

Wir zeigen Ihnen, wie Sie die Faktoren identifizieren, die die Datenbankleistung einschränken. Um sicherzustellen, dass die Datenbank wie erwartet funktioniert, beginnen wir mit dem kostenlosen Monitoring-Tool MongoDB Cloud. Anschließend prüfen wir, wie Logdateien verwaltet und Abfragen untersucht werden. Um eine optimale Nutzung der Hardware-Ressourcen erreichen zu können, werfen wir einen Blick auf die Kernel-Optimierung und andere wichtige Betriebssystemeinstellungen. Abschließend werden wir uns mit der MongoDB-Replikation und der Untersuchung der Leistung befassen.

Kostenlose Leistungsüberwachung

MongoDB hat ein kostenloses Leistungsüberwachungstool in der Cloud für eigenständige Instanzen und Replikatsätze eingeführt. Wenn aktiviert, werden die überwachten Daten regelmäßig in den Cloud-Dienst des Anbieters hochgeladen. Dafür sind keine zusätzlichen Agenten erforderlich, die Funktionalität ist in die neue MongoDB 4.0+ integriert. Der Prozess ist ziemlich einfach einzurichten und zu verwalten. Nach der Aktivierung mit einem einzigen Befehl erhalten Sie eine eindeutige Webadresse, um auf Ihre aktuellen Leistungsstatistiken zuzugreifen. Sie können nur auf überwachte Daten zugreifen, die innerhalb der letzten 24 Stunden hochgeladen wurden.

So aktivieren Sie diese Funktion. Sie können die kostenlose Überwachung während der Laufzeit aktivieren/deaktivieren mit:

-- Enable Free Monitoring
db.enableFreeMonitoring()
-- Disable Free Monitoring
db.disableFreeMonitoring()

Sie können die kostenlose Überwachung auch während des Starts von Mongod aktivieren oder deaktivieren, indem Sie entweder die Konfigurationsdateieinstellung cloud.monitoring.free.state oder die Befehlszeilenoption --enableFreeMonitoring

db.enableFreeMonitoring()

Nach der Aktivierung sehen Sie eine Meldung mit dem aktuellen Status.

{
    "state" : "enabled",
    "message" : "To see your monitoring data, navigate to the unique URL below. Anyone you share the URL with will also be able to view this page. You can disable monitoring at any time by running db.disableFreeMonitoring().",
    "url" : "https://cloud.mongodb.com/freemonitoring/cluster/XEARVO6RB2OTXEAHKHLKJ5V6KV3FAM6B",
    "userReminder" : "",
    "ok" : 1
}

Kopieren Sie einfach die URL aus der Statusausgabe und fügen Sie sie in den Browser ein, und Sie können mit der Überprüfung der Leistungsmetriken beginnen.

MongoDB Free Monitoring bietet Informationen zu den folgenden Metriken:

• Operationsausführungszeiten (LESEN, SCHREIBEN, BEFEHLE)
• Festplattenauslastung (MAX UTIL % ALLER LAUFWERKE, DURCHSCHNITTLICHE UTIL % ALLER LAUFWERKE)
• Speicher (RESIDENT, VIRTUELL, ZUGEORDNET)
• Netzwerk - Eingabe / Ausgabe (BYTES IN, BYTES OUT)
• Netzwerk – Anzahl Anfragen (NUM REQUESTS)
• Opcounter (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
• Opcounter - Replikation (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
• Suchanfragen-Targeting (GESCANNT/ZURÜCKGEGEBEN, GESCANNTE OBJEKTE/ZURÜCKGEGEBEN)
• Warteschlangen (LESER, SCHREIBER, GESAMT)
• System-CPU-Nutzung (USER, NICE, KERNEL, IOWAIT, IRQ, SOFT IRQ, STEAL, GUEST)

Verwenden Sie die folgende Methode, um den Status Ihres kostenlosen Überwachungsdienstes anzuzeigen:

db.getFreeMonitoringStatus()

Der serverStatus und der Helfer db.serverStatus() enthalten auch kostenlose Monitoring-Statistiken im freien Monitoring-Feld.

Bei der Ausführung mit Zugriffskontrolle muss der Benutzer über die folgenden Berechtigungen verfügen, um die kostenlose Überwachung zu aktivieren und den Status abzurufen:

{ resource: { cluster : true }, actions: [ "setFreeMonitoring", "checkFreeMonitoringStatus" ] }

Dieses Tool kann ein guter Anfang für diejenigen sein, die es schwierig finden, die Statusausgabe des MongoDB-Servers über die Befehlszeile zu lesen:

db.serverStatus()

Free Monitoring ist ein guter Anfang, aber es hat sehr begrenzte Optionen, wenn Sie ein fortgeschritteneres Tool benötigen, sollten Sie MongoDB Ops Manager oder ClusterControl ausprobieren.

Datenbankoperationen protokollieren

MongoDB-Treiber und Clientanwendungen können Informationen an die Serverprotokolldatei senden. Diese Informationen hängen von der Art der Veranstaltung ab. Um die aktuellen Einstellungen zu überprüfen, melden Sie sich als Administrator an und führen Sie Folgendes aus:

db.getLogComponents()

Protokollnachrichten enthalten viele Komponenten. Damit soll eine funktionale Kategorisierung der Meldungen erfolgen. Für jede Komponente können Sie eine andere Protokollausführlichkeit festlegen. Die aktuelle Liste der Komponenten ist:

ACCESS, COMMAND, CONTROL, FTD, GEO, INDEX, NETWORK, QUERY, REPL_HB, REPL, ROLLBACK, REPL, SHARDING, STORAGE, RECOVERY, JOURNAL, STORAGE, WRITE.

Weitere Einzelheiten zu den einzelnen Komponenten finden Sie in der Dokumentation.

Abfragen erfassen - Datenbank-Profiler

Der MongoDB Database Profiler sammelt Informationen zu Vorgängen, die für eine Mongod-Instanz ausgeführt werden. Standardmäßig erhebt der Profiler keine Daten. Sie können wählen, ob Sie alle Vorgänge (Wert 2) erfassen möchten oder diejenigen, die länger als der Wert von slowms dauern . Letzteres ist ein Instanzparameter, der über die mongodb-Konfigurationsdatei gesteuert werden kann. So prüfen Sie den aktuellen Stand:

db.getProfilingLevel()

So erfassen Sie alle Abfragen:

db.setProfilingLevel(2)

In der Konfigurationsdatei können Sie Folgendes festlegen:

profile = <0/1/2>
slowms = <value>

Diese Einstellung wird auf eine einzelne Instanz angewendet und nicht über einen Replikatsatz oder einen gemeinsam genutzten Cluster weitergegeben. Sie müssen diesen Befehl also für alle Knoten wiederholen, wenn Sie alle Aktivitäten erfassen möchten. Die Datenbankprofilerstellung kann sich auf die Datenbankleistung auswirken. Aktivieren Sie diese Option nur nach sorgfältiger Überlegung.

Um dann die 10 neuesten aufzulisten:

db.system.profile.find().limit(10).sort(
{ ts : -1 }
).pretty()

Um alle aufzulisten:

db.system.profile.find( { op:
{ $ne : 'command' }
} ).pretty()

Und für eine bestimmte Sammlung auflisten:

db.system.profile.find(
{ ns : 'mydb.test' }
).pretty()

MongoDB-Protokollierung

Der Speicherort des MongoDB-Protokolls wird in der Protokollpfadeinstellung Ihrer Konfiguration definiert und ist normalerweise /var/log/mongodb/mongod.log. Sie finden die MongoDB-Konfigurationsdatei unter /etc/mongod.conf.

Hier sind Beispieldaten:

2018-07-01T23:09:27.101+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Connecting to node1:27017
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Failed to connect to node1:27017 - HostUnreachable: Connection refused
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Dropping all pooled connections to node1:27017 due to failed operation on a connection
2018-07-01T23:09:27.102+0000 I REPL_HB  [replexec-2] Error in heartbeat (requestId: 21589) to node1:27017, response status: HostUnreachable: Connection refused
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Connecting to node1:27017

Sie können die Protokollausführlichkeit der Komponente ändern, indem Sie Folgendes festlegen (Abfragebeispiel):

db.setLogLevel(2, "query")

Die Protokolldatei kann sehr umfangreich sein, daher sollten Sie sie vor der Profilerstellung löschen. Geben Sie in der MongoDB-Befehlszeilenkonsole Folgendes ein:

db.runCommand({ logRotate : 1 });

Überprüfen der Betriebssystemparameter

Speichergrenzen

Verwenden Sie den Befehl ulimit -a, um die Ihrer Anmeldung zugeordneten Limits anzuzeigen. Die folgenden Schwellenwerte und Einstellungen sind besonders wichtig für Mongod- und Mongos-Bereitstellungen:

-f (file size): unlimited
-t (cpu time): unlimited
-v (virtual memory): unlimited
-n (open files): 64000
-m (memory size): unlimited [1]
-u (processes/threads): 32000

Die neuere Version des Mongod-Startskripts (/etc/init.d/mongod) hat die Standardeinstellungen in die Startoption eingebaut:

start()
{
  # Make sure the default pidfile directory exists
  if [ ! -d $PIDDIR ]; then
    install -d -m 0755 -o $MONGO_USER -g $MONGO_GROUP $PIDDIR
  fi

  # Make sure the pidfile does not exist
  if [ -f "$PIDFILEPATH" ]; then
      echo "Error starting mongod. $PIDFILEPATH exists."
      RETVAL=1
      return
  fi

  # Recommended ulimit values for mongod or mongos
  # See http://docs.mongodb.org/manual/reference/ulimit/#recommended-settings
  #
  ulimit -f unlimited
  ulimit -t unlimited
  ulimit -v unlimited
  ulimit -n 64000
  ulimit -m unlimited
  ulimit -u 64000
  ulimit -l unlimited

  echo -n $"Starting mongod: "
  daemon --user "$MONGO_USER" --check $mongod "$NUMACTL $mongod $OPTIONS >/dev/null 2>&1"
  RETVAL=$?
  echo
  [ $RETVAL -eq 0 ] && touch /var/lock/subsys/mongod
}

Die Rolle des Speicherverwaltungs-Subsystems, auch Virtual Memory Manager genannt, besteht darin, die Zuordnung von physischem Speicher (RAM) für den gesamten Kernel und die Benutzerprogramme zu verwalten. Dies wird durch die vm.*-Parameter gesteuert. Es gibt zwei, die Sie in erster Linie berücksichtigen sollten, um die MongoDB-Leistung zu optimieren – vm.dirty_ratio und vm.dirty_background_ratio .

vm.dirty_ratio ist die absolute maximale Menge an Systemspeicher, die mit schmutzigen Seiten gefüllt werden kann, bevor alles auf die Festplatte geschrieben werden muss. Wenn das System an diesem Punkt angelangt ist, werden alle neuen I/O-Blöcke bis zu den schmutzigen Seiten auf die Festplatte geschrieben. Dies ist oft die Ursache für lange I/O-Pausen. Der Standardwert ist 30, was normalerweise zu hoch ist. vm.dirty_background_ratio ist der Prozentsatz des Systemspeichers, der mit „schmutzigen“ Seiten gefüllt werden kann – Speicherseiten, die noch auf die Festplatte geschrieben werden müssen. Der gute Anfang ist, von 10 auszugehen und die Leistung zu messen. Für eine Umgebung mit wenig Arbeitsspeicher ist 20 ein guter Anfang. Eine empfohlene Einstellung für Dirty Ratios auf Datenbankservern mit großem Speicher ist vm.dirty_ratio =15 und vm.dirty_background_ratio =5 oder möglicherweise weniger.

So prüfen Sie den Dirty-Ratio-Lauf:

sysctl -a | grep dirty

Sie können dies einstellen, indem Sie die folgenden Zeilen zu „/etc/sysctl.conf“ hinzufügen:

Wechsel

Auf Servern, auf denen MongoDB der einzige laufende Dienst ist, empfiehlt es sich, vm.swapiness =1 festzulegen. Die Standardeinstellung ist 60, was für ein Datenbanksystem nicht geeignet ist.

vi /etc/sysctl.conf
vm.swappiness = 1

Transparente riesige Seiten

Wenn Sie Ihre MongoDB auf RedHat ausführen, vergewissern Sie sich, dass Transparent Huge Pages deaktiviert ist.
Dies kann mit dem Befehl überprüft werden:

cat /proc/sys/vm/nr_hugepages 
0

0 bedeutet, dass transparente riesige Seiten deaktiviert sind.

Dateisystemoptionen

ext4 rw,seclabel,noatime,data=ordered 0 0

NUMA (Non-Uniform Memory Access)

MongoDB unterstützt NUMA nicht, deaktivieren Sie es im BIOS.

Netzwerkstack

net.core.somaxconn = 4096
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_time = 120
net.ipv4.tcp_max_syn_backlog = 4096

NTP-Dämon

Um den NTP-Zeitserver-Dämon zu installieren, verwenden Sie einen der folgenden Systembefehle.

#Red Hat
sudo yum install ntp
#Debian
sudo apt-get install ntp

Weitere Details zur Betriebssystemleistung für MongoDB finden Sie in einem anderen Blog.

Plan erklären

Ähnlich wie andere beliebte Datenbanksysteme bietet MongoDB eine Erklärungsfunktion, die zeigt, wie eine Datenbankoperation ausgeführt wurde. Die EXPLAIN-Ergebnisse zeigen die Abfragepläne als Stufenbaum an. Jede Stufe übergibt ihre Ereignisse (d. h. Dokumente oder Indexschlüssel) an den übergeordneten Knoten. Die Blattknoten greifen auf die Sammlung oder die Indizes zu. Sie können einer Abfrage EXPLAIN('executionStats') hinzufügen.

db.inventory.find( {
     status: "A",
     $or: [ { qty: { $lt: 30 } }, { item: /^p/ } ]
} ).explain('executionStats');
or append it to the collection:
db.inventory.explain('executionStats').find( {
     status: "A",
     $or: [ { qty: { $lt: 30 } }, { item: /^p/ } ]
} );

Die Schlüssel, auf deren Werte Sie bei der Ausgabe obiger Befehlsausführung achten sollten:

• totalKeysExamined:Die Gesamtzahl der gescannten Indexeinträge, um die Abfrage zurückzugeben.
• totalDocsExamined:Die Gesamtzahl der gescannten Dokumente, um die Ergebnisse zu finden.
• executionTimeMillis:Gesamtzeit in Millisekunden, die für die Auswahl des Abfrageplans und die Ausführung der Abfrage erforderlich ist.

Messen der Replikationsverzögerungsleistung

Die Replikationsverzögerung ist eine Verzögerung zwischen einem Vorgang auf dem Primärserver und der Anwendung dieses Vorgangs vom Oplog auf den Sekundärserver. Mit anderen Worten, es definiert, wie weit der sekundäre Knoten hinter dem primären Knoten liegt, der im besten Fall so nahe wie möglich an 0 liegen sollte.

Der Replikationsprozess kann aus mehreren Gründen beeinträchtigt werden. Eines der Hauptprobleme könnte sein, dass den sekundären Mitgliedern die Serverkapazität ausgeht. Große Schreiboperationen auf dem primären Mitglied, die dazu führen, dass sekundäre Mitglieder die Oplogs nicht wiedergeben können, oder Indexaufbau auf dem primären Mitglied.

Um die aktuelle Replikationsverzögerung zu überprüfen, führen Sie Folgendes in einer MongoDB-Shell aus:

db.getReplicationInfo()
db.getReplicationInfo() 
{
    "logSizeMB" : 2157.1845703125,
    "usedMB" : 0.05,
    "timeDiff" : 4787,
    "timeDiffHours" : 1.33,
    "tFirst" : "Sun Jul 01 2018 21:40:32 GMT+0000 (UTC)",
    "tLast" : "Sun Jul 01 2018 23:00:19 GMT+0000 (UTC)",
    "now" : "Sun Jul 01 2018 23:00:26 GMT+0000 (UTC)"

Die Ausgabe des Replikationsstatus kann verwendet werden, um den aktuellen Status der Replikation zu beurteilen und festzustellen, ob eine unbeabsichtigte Replikationsverzögerung vorliegt.

rs.printSlaveReplicationInfo()

Es zeigt die Zeitverzögerung zwischen den sekundären Mitgliedern in Bezug auf die primären.

rs.status()

Es zeigt die detaillierten Details für die Replikation. Mit diesen Befehlen können wir genügend Informationen über die Replikation sammeln. Hoffentlich geben diese Tipps einen schnellen Überblick darüber, wie Sie die MongoDB-Leistung überprüfen können. Lassen Sie uns wissen, wenn wir etwas verpasst haben.