Et præstationssnydeark til MongoDB

Databaseydelse påvirker organisationens ydeevne, og vi har en tendens til at søge efter en hurtig løsning. Der er mange forskellige muligheder for at forbedre ydeevnen i MongoDB. I denne blog hjælper vi dig med bedre at forstå din databasearbejdsbelastning og ting, der kan skade den. Viden om, hvordan man bruger begrænsede ressourcer er afgørende for enhver, der administrerer en produktionsdatabase.

Vi vil vise dig, hvordan du identificerer de faktorer, der begrænser databasens ydeevne. For at sikre, at databasen fungerer som forventet, starter vi fra det gratis MongoDB Cloud-overvågningsværktøj. Derefter vil vi kontrollere, hvordan man administrerer logfiler, og hvordan man undersøger forespørgsler. For at kunne opnå optimal brug af hardwareressourcer vil vi tage et kig på kerneoptimering og andre afgørende OS-indstillinger. Til sidst vil vi se nærmere på MongoDB-replikering og hvordan man undersøger ydeevnen.

Gratis overvågning af ydeevne

MongoDB introducerede et gratis ydelsesovervågningsværktøj i skyen til selvstændige forekomster og replikasæt. Når det er aktiveret, uploades de overvågede data periodisk til leverandørens cloud-tjeneste. Det kræver ingen yderligere agenter, funktionaliteten er indbygget i den nye MongoDB 4.0+. Processen er ret enkel at konfigurere og administrere. Efter aktiveringen af ​​den enkelte kommando får du en unik webadresse for at få adgang til dine seneste præstationsstatistikker. Du kan kun få adgang til overvågede data, der er blevet uploadet inden for de seneste 24 timer.

Sådan aktiverer du denne funktion. Du kan aktivere/deaktivere gratis overvågning under kørsel ved hjælp af:

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

Du kan også aktivere eller deaktivere gratis overvågning under mongod opstart ved at bruge enten konfigurationsfilindstillingen cloud.monitoring.free.state eller kommandolinjeindstillingen --enableFreeMonitoring

db.enableFreeMonitoring()

Efter aktiveringen vil du se en meddelelse med den faktiske 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
}

Du skal blot kopiere/indsætte URL'en fra statusoutputtet til browseren, og du kan begynde at tjekke ydeevnemålinger.

MongoDB Gratis overvågning giver information om følgende metrics:

• Driftsudførelsestider (LÆS, SKRIVER, KOMMANDOER)
• Diskudnyttelse (MAX UTIL % AF ET HVERT DREV, GENNEMSNITLIG UDIL % AF ALLE DREV)
• Hukommelse (RESIDENT, VIRTUAL, MAPPED)
• Netværk - Input/Output (BYTES IN, BYTES OUT)
• Netværk - Antal anmodninger (NUM FORESPØRGSEL)
• Optællere (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
• Optællere - Replikering (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
• Forespørgselsmålretning (SCANNERET/RETURNERET, SCANNEDE OBJEKTER/RETURNERET)
• Køer (læsere, forfattere, TOTAL)
• Anvendelse af systemets CPU (BRUGER, NICE, KERNEL, IOWAIT, IRQ, SOFT IRQ, STJÆL, GÆST)

For at se status for din gratis overvågningstjeneste skal du bruge følgende metode:

db.getFreeMonitoringStatus()

ServerStatus og hjælperen db.serverStatus() inkluderer også gratis overvågningsstatistik i det gratis overvågningsfelt.

Når du kører med adgangskontrol, skal brugeren have følgende privilegier for at aktivere gratis overvågning og få status:

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

Dette værktøj kan være en god start for dem, der har svært ved at læse MongoDB-serverstatusoutput fra kommandolinjen:

db.serverStatus()

Gratis overvågning er en god start, men den har meget begrænsede muligheder, hvis du har brug for et mere avanceret værktøj, kan du tjekke MongoDB Ops Manager eller ClusterControl.

Logføring af databaseoperationer

MongoDB-drivere og klientapplikationer kan sende information til serverlogfilen. Sådanne oplysninger afhænger af arrangementets type. For at kontrollere de aktuelle indstillinger skal du logge ind som admin og udføre:

db.getLogComponents()

Logmeddelelser omfatter mange komponenter. Dette er for at give en funktionel kategorisering af beskederne. For hver komponent kan du indstille forskellig log-omtale. Den aktuelle liste over komponenter er:

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

Se dokumentationen for flere detaljer om hver af komponenterne.

Optagelse af forespørgsler - Database Profiler

MongoDB Database Profiler indsamler oplysninger om operationer, der kører mod en mongod-instans. Profileren indsamler som standard ingen data. Du kan vælge at indsamle alle operationer (værdi 2), eller dem, der tager længere tid end værdien af ​​slowms . Sidstnævnte er en instansparameter, som kan kontrolleres gennem mongodb-konfigurationsfilen. Sådan kontrolleres det aktuelle niveau:

db.getProfilingLevel()

Sådan fanger du alle forespørgselssæt:

db.setProfilingLevel(2)

I konfigurationsfilen kan du indstille:

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

Denne indstilling vil blive anvendt på en enkelt forekomst og spredes ikke på tværs af et replikasæt eller delt klynge, så du skal gentage denne kommando for alle noderne, hvis du vil fange alle aktiviteter. Databaseprofilering kan påvirke databasens ydeevne. Aktiver kun denne mulighed efter nøje overvejelse.

Så for at liste de 10 seneste:

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

Sådan listes alle:

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

Og for at angive en specifik samling:

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

MongoDB-logning

MongoDB-logplacering er defineret i din konfigurations logpath-indstilling, og det er normalt /var/log/mongodb/mongod.log. Du kan finde MongoDB-konfigurationsfilen på /etc/mongod.conf.

Her er eksempeldata:

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

Du kan ændre logistikken for komponenten ved at indstille (eksempel på forespørgsel):

db.setLogLevel(2, "query")

Logfilen kan være betydelig, så du vil måske rydde den før profilering. Fra MongoDB-kommandolinjekonsollen skal du indtaste:

db.runCommand({ logRotate : 1 });

Kontrol af operativsystemparametre

Hukommelsesgrænser

For at se begrænsningerne forbundet med dit login, brug kommandoen ulimit -a. Følgende tærskler og indstillinger er særligt vigtige for mongod- og mongo-implementeringer:

-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

Den nyere version af mongod opstartsscriptet (/etc/init.d/mongod) har standardindstillingerne indbygget i startindstillingen:

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
}

Rollen for undersystemet til hukommelsesstyring, også kaldet den virtuelle hukommelsesstyring, er at styre allokeringen af ​​fysisk hukommelse (RAM) for hele kernen og brugerprogrammer. Dette styres af vm.*-parametrene. Der er to, som du bør overveje i første omgang for at justere MongoDB-ydelsen - vm.dirty_ratio og vm.dirty_background_ratio .

vm.dirty_ratio er den absolutte maksimale mængde systemhukommelse, der kan fyldes med snavsede sider, før alt skal blive forpligtet til disk. Når systemet når til dette punkt, blokeres alle nye I/O-blokke, indtil beskidte sider er blevet skrevet til disken. Dette er ofte kilden til lange I/O-pauser. Standarden er 30, hvilket normalt er for højt. vm.dirty_background_ratio er den procentdel af systemhukommelsen, der kan fyldes med "beskidte" sider - hukommelsessider, der stadig skal skrives til disken. Den gode start er at gå fra 10 og måle præstation. For et miljø med lav hukommelse er 20 en god start. En anbefalet indstilling for dirty-forhold på databaseservere med stor hukommelse er vm.dirty_ratio =15 og vm.dirty_background_ratio =5 eller muligvis mindre.

Sådan kontrolleres snavsforhold:

sysctl -a | grep dirty

Du kan indstille dette ved at tilføje følgende linjer til "/etc/sysctl.conf":

Swappiness

På servere, hvor MongoDB er den eneste tjeneste, der kører, er det en god praksis at indstille vm.swapiness =1. Standardindstillingen er sat til 60, hvilket ikke er passende for et databasesystem.

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

Transparente enorme sider

Hvis du kører din MongoDB på RedHat, skal du sørge for, at Transparent Huge Pages er deaktiveret.
Dette kan kontrolleres af kommandoen:

cat /proc/sys/vm/nr_hugepages 
0

0 betyder, at gennemsigtige enorme sider er deaktiveret.

Filsystemindstillinger

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

NUMA (Non-Uniform Memory Access)

MongoDB understøtter ikke NUMA, deaktiver det i BIOS.

Netværksstak

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

Brug en af ​​følgende systemkommandoer for at installere NTP-tidsserverdæmonen.

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

Du kan finde flere detaljer om OS-ydeevne for MongoDB i en anden blog.

Forklar planen

I lighed med andre populære databasesystemer giver MongoDB en forklarende funktion, som afslører, hvordan en databaseoperation blev udført. Forklaringsresultaterne viser forespørgselsplanerne som et træ af faser. Hvert trin sender sine hændelser (dvs. dokumenter eller indeksnøgler) til den overordnede node. Bladknuderne får adgang til samlingen eller indekserne. Du kan tilføje explain('executionStats') til en forespørgsel.

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 nøgler, hvis værdier du skal være opmærksom på i outputtet af ovenstående kommandoudførelse:

• totalKeysExamined:Det samlede antal indeksposter, der er scannet for at returnere forespørgsel.
• totalDocsExamined:Det samlede antal dokumenter, der er scannet for at finde resultaterne.
• executionTimeMillis:Samlet tid i millisekunder, der kræves til valg af forespørgselsplan og udførelse af forespørgsel.

Måling af replikationsforsinkelsesydelse

Replikationsforsinkelse er en forsinkelse mellem en operation på den primære og anvendelsen af ​​den pågældende operation fra oplog til den sekundære. Med andre ord definerer den, hvor langt den sekundære er bag den primære knude, som i bedste tilfælde skal være så tæt på 0 som muligt.

Replikeringsprocessen kan blive påvirket af flere årsager. Et af hovedproblemerne kunne være, at de sekundære medlemmer løber tør for serverkapacitet. Store skriveoperationer på det primære medlem, hvilket fører til, at sekundære medlemmer ikke er i stand til at afspille oplogs igen, eller indeks bygger på det primære medlem.

For at kontrollere den aktuelle replikeringsforsinkelse skal du køre i en MongoDB-skal:

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

Replikeringsstatusoutput kan bruges til at vurdere den aktuelle replikeringstilstand og bestemme, om der er en utilsigtet replikationsforsinkelse.

rs.printSlaveReplicationInfo()

Den viser tidsforsinkelsen mellem de sekundære medlemmer i forhold til de primære.

rs.status()

Det viser de dybdegående detaljer for replikering. Vi kan indsamle nok information om replikering ved at bruge disse kommandoer. Forhåbentlig giver disse tips et hurtigt overblik over, hvordan man gennemgår MongoDB-ydelse. Fortæl os, hvis vi er gået glip af noget.