Een prestatie-spiekbriefje voor MongoDB

Databaseprestaties zijn van invloed op de prestaties van de organisatie en we hebben de neiging om op zoek te gaan naar een snelle oplossing. Er zijn veel verschillende manieren om de prestaties in MongoDB te verbeteren. In deze blog helpen we je om de werkbelasting van je database beter te begrijpen, en dingen die daar schade aan kunnen toebrengen. Kennis van het gebruik van beperkte middelen is essentieel voor iedereen die een productiedatabase beheert.

We laten u zien hoe u de factoren kunt identificeren die de databaseprestaties beperken. Om ervoor te zorgen dat de database naar verwachting presteert, gaan we uit van de gratis MongoDB Cloud-monitoringtool. Daarna gaan we na hoe logbestanden beheerd moeten worden en hoe vragen onderzocht kunnen worden. Om optimaal gebruik te kunnen maken van hardwarebronnen, zullen we kijken naar kerneloptimalisatie en andere cruciale OS-instellingen. Ten slotte zullen we kijken naar MongoDB-replicatie en hoe we de prestaties kunnen onderzoeken.

Gratis monitoring van prestaties

MongoDB heeft een gratis tool voor prestatiebewaking in de cloud geïntroduceerd voor zelfstandige instanties en replicasets. Indien ingeschakeld, worden de bewaakte gegevens periodiek geüpload naar de cloudservice van de leverancier. Dat vereist geen extra agents, de functionaliteit is ingebouwd in de nieuwe MongoDB 4.0+. Het proces is vrij eenvoudig in te stellen en te beheren. Na de activering van de enkele opdracht krijgt u een uniek webadres om toegang te krijgen tot uw recente prestatiestatistieken. U heeft alleen toegang tot gecontroleerde gegevens die in de afgelopen 24 uur zijn geüpload.

Hier leest u hoe u deze functie kunt activeren. U kunt gratis monitoring tijdens runtime in-/uitschakelen met:

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

U kunt ook gratis monitoring in- of uitschakelen tijdens het opstarten van mongod met behulp van de configuratiebestandsinstelling cloud.monitoring.free.state of de opdrachtregeloptie --enableFreeMonitoring

db.enableFreeMonitoring()

Na de activering ziet u een bericht met de actuele 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
}

Kopieer/plak de URL van de statusuitvoer naar de browser en u kunt beginnen met het controleren van prestatiestatistieken.

MongoDB Gratis monitoring biedt informatie over de volgende statistieken:

• Uitvoeringstijden bewerking (LEZEN, SCHRIJVEN, COMMANDO'S)
• Schijfgebruik (MAX UTIL % VAN ELKE SCHIJF, GEMIDDELDE UTIL % VAN ALLE SCHIJVEN)
• Geheugen (RESIDENT, VIRTUEEL, IN KAART)
• Netwerk - Ingang / Uitgang (BYTES IN, BYTES OUT)
• Netwerk - Num Requests (NUM REQUESTS)
• Optellers (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
• Opcounters - Replicatie (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
• Querytargeting (GESCAND / GERETOURNEERD, GESCANDE OBJECTEN / GERETOURNEERD)
• Wachtrijen (LEZERS, SCHRIJVERS, TOTAAL)
• Gebruik van systeem-Cpu (USER, NICE, KERNEL, IOWAIT, IRQ, SOFT IRQ, STEAL, GUEST)

Gebruik de volgende methode om de status van uw gratis monitoringservice te bekijken:

db.getFreeMonitoringStatus()

De serverStatus en de helper db.serverStatus() bevatten ook gratis monitoringstatistieken in het gratis veld Monitoring.

Bij gebruik met toegangscontrole moet de gebruiker de volgende privileges hebben om gratis monitoring mogelijk te maken en de status te krijgen:

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

Deze tool kan een goed begin zijn voor degenen die het moeilijk vinden om de MongoDB-serverstatusuitvoer vanaf de opdrachtregel te lezen:

db.serverStatus()

Gratis monitoring is een goed begin, maar het heeft zeer beperkte opties. Als je een meer geavanceerde tool nodig hebt, kun je MongoDB Ops Manager of ClusterControl eens bekijken.

Databasebewerkingen loggen

MongoDB-stuurprogramma's en clienttoepassingen kunnen informatie naar het serverlogbestand verzenden. Dergelijke informatie is afhankelijk van het type evenement. Om de huidige instellingen te controleren, logt u in als admin en voert u het volgende uit:

db.getLogComponents()

Logberichten bevatten veel componenten. Dit is om een ​​functionele categorisering van de berichten te bieden. Voor elk van de componenten kunt u een andere breedsprakigheid van het logboek instellen. De huidige lijst met componenten is:

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

Raadpleeg de documentatie voor meer informatie over elk van de componenten.

Vragen vastleggen - Database Profiler

MongoDB Database Profiler verzamelt informatie over bewerkingen die worden uitgevoerd tegen een mongod-instantie. Standaard verzamelt de profiler geen gegevens. U kunt ervoor kiezen om alle bewerkingen (waarde 2) te verzamelen, of bewerkingen die langer duren dan de waarde van slowms . De laatste is een instantieparameter die kan worden beheerd via het mongodb-configuratiebestand. Om het huidige niveau te controleren:

db.getProfilingLevel()

Om alle ingestelde zoekopdrachten vast te leggen:

db.setProfilingLevel(2)

In het configuratiebestand kunt u instellen:

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

Deze instelling wordt toegepast op één exemplaar en wordt niet verspreid over een replicaset of gedeeld cluster, dus u moet deze opdracht van alle knooppunten herhalen als u alle activiteiten wilt vastleggen. Databaseprofilering kan van invloed zijn op de databaseprestaties. Schakel deze optie alleen in na zorgvuldige overweging.

Om vervolgens de 10 meest recente op te sommen:

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

Om alles op te sommen:

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

En om te vermelden voor een specifieke collectie:

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

MongoDB-logboekregistratie

De MongoDB-loglocatie wordt gedefinieerd in de logpath-instelling van uw configuratie en is meestal /var/log/mongodb/mongod.log. U kunt het MongoDB-configuratiebestand vinden op /etc/mongod.conf.

Hier zijn voorbeeldgegevens:

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

U kunt de breedsprakigheid van het logboek van de component wijzigen door in te stellen (vraagvoorbeeld):

db.setLogLevel(2, "query")

Het logbestand kan aanzienlijk zijn, dus misschien wilt u het wissen voordat u gaat profileren. Voer vanaf de MongoDB-opdrachtregelconsole het volgende in:

db.runCommand({ logRotate : 1 });

Besturingssysteemparameters controleren

Geheugenlimieten

Gebruik het commando ulimit -a om de limieten te zien die aan uw login zijn gekoppeld. De volgende drempels en instellingen zijn met name belangrijk voor implementaties van mongod en mongos:

-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

De nieuwere versie van het opstartscript van mongod (/etc/init.d/mongod) heeft de standaardinstellingen ingebouwd in de startoptie:

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
}

De rol van het geheugenbeheersubsysteem, ook wel virtueel geheugenbeheer genoemd, is het beheren van de toewijzing van fysiek geheugen (RAM) voor de hele kernel en gebruikersprogramma's. Dit wordt geregeld door de vm.*-parameters. Er zijn er twee die u in de eerste plaats moet overwegen om de MongoDB-prestaties af te stemmen - vm.dirty_ratio en vm.dirty_background_ratio .

vm.dirty_ratio is de absolute maximale hoeveelheid systeemgeheugen die kan worden gevuld met vuile pagina's voordat alles op schijf moet worden vastgelegd. Wanneer het systeem dit punt bereikt, worden alle nieuwe I/O-blokken geblokkeerd totdat de vuile pagina's naar de schijf zijn geschreven. Dit is vaak de oorzaak van lange I/O-pauzes. De standaardwaarde is 30, wat meestal te hoog is. vm.dirty_background_ratio is het percentage van het systeemgeheugen dat kan worden gevuld met "vuile" pagina's - geheugenpagina's die nog naar de schijf moeten worden geschreven. Het goede begin is om vanaf 10 te gaan en de prestaties te meten. Voor een omgeving met weinig geheugen is 20 een goed begin. Een aanbevolen instelling voor vuile ratio's op databaseservers met een groot geheugen is vm.dirty_ratio =15 en vm.dirty_background_ratio =5 of mogelijk minder.

Om de vuile verhouding te controleren:

sysctl -a | grep dirty

U kunt dit instellen door de volgende regels toe te voegen aan "/etc/sysctl.conf":

Swappiness

Op servers waar MongoDB de enige service is die draait, is het een goede gewoonte om vm.swapiness =1 in te stellen. De standaardinstelling is ingesteld op 60, wat niet geschikt is voor een databasesysteem.

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

Transparante grote pagina's

Als je je MongoDB op RedHat draait, zorg er dan voor dat Transparent Huge Pages is uitgeschakeld.
Dit kan worden gecontroleerd door commnad:

cat /proc/sys/vm/nr_hugepages 
0

0 betekent dat transparante grote pagina's zijn uitgeschakeld.

Bestandssysteemopties

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

NUMA (niet-uniforme geheugentoegang)

MongoDB ondersteunt NUMA niet, schakel het uit in BIOS.

Netwerkstack

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-deamon

Gebruik een van de volgende systeemopdrachten om NTP time server demon te installeren.

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

U kunt meer details over de prestaties van het besturingssysteem voor MongoDB vinden in een andere blog.

Leg plan uit

Net als bij andere populaire databasesystemen, biedt MongoDB een uitlegfunctie die onthult hoe een databasebewerking werd uitgevoerd. De Explain-resultaten geven de queryplannen weer als een boomstructuur met fasen. Elke fase geeft zijn gebeurtenissen (d.w.z. documenten of indexsleutels) door aan het bovenliggende knooppunt. De bladknooppunten hebben toegang tot de verzameling of de indices. U kunt explain('executionStats') aan een query toevoegen.

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/ } ]
} );

De toetsen waarvan u op moet letten bij het uitvoeren van de bovenstaande opdracht:

• totalKeysExamined:het totale aantal indexitems dat is gescand om de zoekopdracht te retourneren.
• totalDocsExamined:het totale aantal gescande documenten om de resultaten te vinden.
• executionTimeMillis:totale tijd in milliseconden die nodig is voor het selecteren van het queryplan en het uitvoeren van de query.

Replicatievertraging meten

Replicatievertraging is een vertraging tussen een bewerking op de primaire en de toepassing van die bewerking van de oplog naar de secundaire. Met andere woorden, het definieert hoe ver het secundaire knooppunt zich achter het primaire knooppunt bevindt, wat in het beste geval zo dicht mogelijk bij 0 moet zijn.

Het replicatieproces kan om meerdere redenen worden beïnvloed. Een van de belangrijkste problemen kan zijn dat de secundaire leden bijna geen servercapaciteit meer hebben. Grote schrijfbewerkingen op het primaire lid, waardoor secundaire leden de oplogs niet opnieuw kunnen afspelen, of indexopbouw op het primaire lid.

Voer in een MongoDB-shell uit om de huidige replicatievertraging te controleren:

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)"

De uitvoer van de replicatiestatus kan worden gebruikt om de huidige replicatiestatus te beoordelen en te bepalen of er sprake is van onbedoelde replicatievertraging.

rs.printSlaveReplicationInfo()

Het toont de tijdsvertraging tussen de secundaire leden ten opzichte van de primaire.

rs.status()

Het toont de diepgaande details voor replicatie. Met deze commando's kunnen we voldoende informatie over replicatie verzamelen. Hopelijk geven deze tips een snel overzicht van hoe u de MongoDB-prestaties kunt beoordelen. Laat het ons weten als we iets hebben gemist.