Ett prestationsfuskblad för MongoDB

Databasprestanda påverkar organisationens prestanda, och vi tenderar att vilja leta efter en snabb lösning. Det finns många olika sätt att förbättra prestandan i MongoDB. I den här bloggen hjälper vi dig att bättre förstå din databas arbetsbelastning och saker som kan skada den. Kunskap om hur man använder begränsade resurser är avgörande för alla som hanterar en produktionsdatabas.

Vi kommer att visa dig hur du identifierar de faktorer som begränsar databasprestanda. För att säkerställa att databasen fungerar som förväntat kommer vi att utgå från det kostnadsfria MongoDB Cloud-övervakningsverktyget. Sedan kommer vi att kontrollera hur man hanterar loggfiler och hur man undersöker frågor. För att kunna uppnå optimal användning av hårdvaruresurser kommer vi att ta en titt på kärnoptimering och andra viktiga OS-inställningar. Slutligen kommer vi att undersöka MongoDB-replikering och hur man undersöker prestanda.

Gratis övervakning av prestanda

MongoDB introducerade ett gratis prestandaövervakningsverktyg i molnet för fristående instanser och replikuppsättningar. När den är aktiverad laddas övervakad data upp regelbundet till leverantörens molntjänst. Det kräver inga ytterligare agenter, funktionaliteten är inbyggd i nya MongoDB 4.0+. Processen är ganska enkel att installera och hantera. Efter aktiveringen av ett enda kommando får du en unik webbadress för att komma åt din senaste prestationsstatistik. Du kan bara komma åt övervakad data som har laddats upp under de senaste 24 timmarna.

Så här aktiverar du den här funktionen. Du kan aktivera/inaktivera gratis övervakning under körning med:

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

Du kan också aktivera eller inaktivera gratis övervakning under mongod-start med antingen konfigurationsfilinställningen cloud.monitoring.free.state eller kommandoradsalternativet --enableFreeMonitoring

db.enableFreeMonitoring()

Efter aktiveringen kommer du att se ett meddelande med den faktiska statusen.

{
    "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
}

Kopiera/klistra bara in URL:en från statusutgången till webbläsaren så kan du börja kontrollera prestandastatistik.

MongoDB Gratis övervakning ger information om följande mätvärden:

• Uppförandetider (LÄS, SKRIVER, KOMMANDO)
• Diskutnyttjande (MAX UTIL % AV NÅGON DISK, GENOMSNITTLIGT UTIL % AV ALLA DISKAR)
• Minne (RESIDENT, VIRTUELLT, MAPPAT)
• Nätverk - Ingång/utgång (BYTES IN, BYTES OUT)
• Nätverk - Antal förfrågningar (NUM REQUESTS)
• Opcounters (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
• Opcounters - Replikering (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
• Frågeinriktning (SCANNADE / RETURNERADE, SKANNADE OBJEKT / RETURNERADE)
• Köer (LÄSARE, SKRIFTARE, TOTALT)
• Användning av systemets CPU (USER, NICE, KERNEL, IOWAIT, IRQ, SOFT IRQ, STEAL, GUEST)

För att se statusen för din kostnadsfria övervakningstjänst, använd följande metod:

db.getFreeMonitoringStatus()

ServerStatus och hjälparen db.serverStatus() inkluderar också gratis övervakningsstatistik i det fria övervakningsfältet.

När du kör med åtkomstkontroll måste användaren ha följande behörigheter för att aktivera gratis övervakning och få status:

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

Det här verktyget kan vara en bra början för dem som har svårt att läsa MongoDB-serverstatusutdata från kommandoraden:

db.serverStatus()

Gratis övervakning är en bra början men den har mycket begränsade alternativ, om du behöver ett mer avancerat verktyg kanske du vill kolla MongoDB Ops Manager eller ClusterControl.

Loggning av databasoperationer

MongoDB-drivrutiner och klientapplikationer kan skicka information till serverloggfilen. Sådan information beror på typen av händelse. För att kontrollera aktuella inställningar, logga in som admin och kör:

db.getLogComponents()

Loggmeddelanden innehåller många komponenter. Detta för att tillhandahålla en funktionell kategorisering av meddelandena. För varje komponent kan du ställa in olika loggspråkighet. Den aktuella listan över komponenter är:

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

Se dokumentationen för mer information om var och en av komponenterna.

Fånga frågor - Databasprofil

MongoDB Database Profiler samlar in information om operationer som körs mot en mongod-instans. Som standard samlar profileraren ingen data. Du kan välja att samla alla operationer (värde 2), eller de som tar längre tid än värdet på slowms . Den senare är en instansparameter som kan kontrolleras genom mongodb-konfigurationsfilen. Så här kontrollerar du den aktuella nivån:

db.getProfilingLevel()

För att fånga alla sökfrågor:

db.setProfilingLevel(2)

I konfigurationsfilen kan du ställa in:

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

Den här inställningen kommer att tillämpas på en enda instans och sprids inte över en replikuppsättning eller delat kluster, så du måste upprepa detta kommando för alla noder om du vill fånga alla aktiviteter. Databasprofilering kan påverka databasens prestanda. Aktivera det här alternativet endast efter noggrant övervägande.

För att sedan lista de 10 senaste:

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

För att lista alla:

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

Och för att lista för en specifik samling:

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

MongoDB-loggning

MongoDB-loggplatsen definieras i din konfigurations loggvägsinställning, och det är vanligtvis /var/log/mongodb/mongod.log. Du kan hitta MongoDB-konfigurationsfilen på /etc/mongod.conf.

Här är exempeldata:

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 modifiera loggens omfattning för komponenten genom att ställa in (frågeexempel):

db.setLogLevel(2, "query")

Loggfilen kan vara betydande, så du kanske vill rensa den innan profilering. Från MongoDBs kommandoradskonsol anger du:

db.runCommand({ logRotate : 1 });

Kontrollerar operativsystemets parametrar

Minnesgränser

För att se gränserna för din inloggning, använd kommandot ulimit -a. Följande trösklar och inställningar är särskilt viktiga för mongod och mongos-distributioner:

-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 nyare versionen av mongods startskript (/etc/init.d/mongod) har standardinställningarna inbyggda i startalternativet:

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 för undersystemet för minneshantering, även kallad virtuell minneshanterare, är att hantera allokeringen av fysiskt minne (RAM) för hela kärnan och användarprogram. Detta styrs av parametrarna vm.*. Det finns två som du bör överväga i första hand för att ställa in MongoDB-prestanda - vm.dirty_ratio och vm.dirty_background_ratio .

vm.dirty_ratio är den absoluta maximala mängden systemminne som kan fyllas med smutsiga sidor innan allt måste sätta sig på disken. När systemet kommer till denna punkt blockeras alla nya I/O tills smutsiga sidor har skrivits till disken. Detta är ofta källan till långa I/O-pauser. Standard är 30, vilket vanligtvis är för högt. vm.dirty_background_ratio är den procentandel av systemminnet som kan fyllas med "smutsiga" sidor - minnessidor som fortfarande behöver skrivas till disken. Den bra början är att gå från 10 och mäta prestanda. För en miljö med lågt minne är 20 en bra början. En rekommenderad inställning för dirty ratios på databasservrar med stort minne är vm.dirty_ratio =15 och vm.dirty_background_ratio =5 eller möjligen mindre.

Så här kontrollerar du smutsförhållandet:

sysctl -a | grep dirty

Du kan ställa in detta genom att lägga till följande rader i "/etc/sysctl.conf":

Swappiness

På servrar där MongoDB är den enda tjänsten som körs är det bra att ställa in vm.swapiness =1. Standardinställningen är inställd på 60 vilket inte är lämpligt för ett databassystem.

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

Transparenta enorma sidor

Om du kör din MongoDB på RedHat, se till att Transparent Huge Pages är inaktiverat.
Detta kan kontrolleras med kommando:

cat /proc/sys/vm/nr_hugepages 
0

0 betyder att genomskinliga enorma sidor är inaktiverade.

Filsystemalternativ

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

NUMA (Non-Uniform Memory Access)

MongoDB stöder inte NUMA, inaktivera det i BIOS.

Nätverksstack

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

För att installera NTP-tidsserverdemon, använd ett av följande systemkommandon.

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

Du kan hitta mer information om OS-prestanda för MongoDB i en annan blogg.

Förklara planen

I likhet med andra populära databassystem tillhandahåller MongoDB en förklarande funktion som avslöjar hur en databasoperation utfördes. Förklaringsresultaten visar frågeplanerna som ett steg med steg. Varje steg skickar sina händelser (d.v.s. dokument eller indexnycklar) till den överordnade noden. Bladnoderna kommer åt samlingen eller indexen. Du kan lägga till explain('executionStats') till en fråga.

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 nycklar vars värden du bör se upp med i utmatningen av kommandot ovan:

• totalKeysExamined:Det totala antalet indexposter som skannats för att returnera fråga.
• totalDocsExamined:Det totala antalet dokument som skannats för att hitta resultaten.
• executionTimeMillis:Total tid i millisekunder som krävs för val av frågeplan och sökexekvering.

Mäta replikeringsfördröjningsprestanda

Replikeringsfördröjning är en fördröjning mellan en operation på den primära och tillämpningen av den operationen från oploggen till den sekundära. Med andra ord definierar den hur långt sekundärn är bakom den primära noden, vilket i bästa fall bör vara så nära 0 som möjligt.

Replikeringsprocessen kan påverkas av flera skäl. En av huvudproblemen kan vara att de sekundära medlemmarna har slut på serverkapacitet. Stora skrivoperationer på den primära medlemmen som leder till att sekundära medlemmar inte kan spela om oplogs, eller att Index bygger på den primära medlemmen.

För att kontrollera den aktuella replikeringsfördröjningen, kör i ett 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)"

Replikeringsstatusutdata kan användas för att bedöma det aktuella tillståndet för replikeringen och avgöra om det finns någon oavsiktlig replikeringsfördröjning.

rs.printSlaveReplicationInfo()

Den visar tidsfördröjningen mellan de sekundära delarna i förhållande till de primära.

rs.status()

Den visar djupgående detaljer för replikering. Vi kan samla tillräckligt med information om replikering genom att använda dessa kommandon. Förhoppningsvis ger dessa tips en snabb översikt över hur man granskar MongoDB-prestanda. Låt oss veta om vi har missat något.