Výkonný Cheat Sheet pro MongoDB

Výkon databáze ovlivňuje výkon organizace a my máme tendenci hledat rychlé řešení. Existuje mnoho různých způsobů, jak zlepšit výkon v MongoDB. V tomto blogu vám pomůžeme lépe porozumět vytížení vaší databáze a věcem, které ji mohou poškodit. Znalost toho, jak používat omezené zdroje, je nezbytná pro každého, kdo spravuje produkční databázi.

Ukážeme vám, jak identifikovat faktory, které omezují výkon databáze. Abychom zajistili, že databáze bude fungovat podle očekávání, začneme od bezplatného monitorovacího nástroje MongoDB Cloud. Poté zkontrolujeme, jak spravovat soubory protokolu a jak zkoumat dotazy. Abychom byli schopni dosáhnout optimálního využití hardwarových prostředků, podíváme se na optimalizaci jádra a další důležitá nastavení OS. Nakonec se podíváme na replikaci MongoDB a na to, jak zkoumat výkon.

Bezplatné sledování výkonu

MongoDB představilo bezplatný nástroj pro monitorování výkonu v cloudu pro samostatné instance a sady replik. Je-li povoleno, monitorovaná data se pravidelně nahrávají do cloudové služby dodavatele. To nevyžaduje žádné další agenty, funkce jsou zabudovány do nového MongoDB 4.0+. Proces je poměrně jednoduchý na nastavení a správu. Po aktivaci jediným příkazem získáte jedinečnou webovou adresu pro přístup k vašim aktuálním statistikám výkonu. Máte přístup pouze ke sledovaným datům, která byla nahrána během posledních 24 hodin.

Zde je návod, jak tuto funkci aktivovat. Bezplatné sledování za běhu můžete povolit/zakázat pomocí:

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

Můžete také povolit nebo zakázat bezplatné monitorování během spouštění mongodu pomocí nastavení konfiguračního souboru cloud.monitoring.free.state nebo pomocí možnosti příkazového řádku --enableFreeMonitoring

db.enableFreeMonitoring()

Po aktivaci se zobrazí zpráva s aktuálním stavem.

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

Jednoduše zkopírujte/vložte adresu URL z výstupu stavu do prohlížeče a můžete začít kontrolovat metriky výkonu.

MongoDB Free monitoring poskytuje informace o následujících metrikách:

• Doby provádění operací (ČTENÍ, ZÁPIS, PŘÍKAZY)
• Využití disku (MAX. UTIL % JAKÉKOLI JEDNOTKY, PRŮMĚRNÉ VYUŽITÍ % VŠECH JEDNOTEK)
• Paměť (RESIDENTNÍ, VIRTUÁLNÍ, MAPOVANÁ)
• Síť – vstup/výstup (BYTES IN, BYTES OUT)
• Síť – počet požadavků (NUM REQUESTS)
• Opcounters (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
• Opcounters – Replikace (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
• Cílení na dotazy (SKENOVANÉ / VRÁCENÉ, NASKENOVANÉ OBJEKTY / VRÁCENÉ)
• Fronty (ČTENÁŘI, SPISOVATELÉ, TOTAL)
• Využití systémového CPU (USER, NICE, KERNEL, IOWAIT, IRQ, SOFT IRQ, STEAL, GUEST)

Chcete-li zobrazit stav vaší bezplatné monitorovací služby, použijte následující metodu:

db.getFreeMonitoringStatus()

ServerStatus a pomocník db.serverStatus() také zahrnují bezplatné statistiky monitorování ve volném poli Monitoring.

Při spuštění s řízením přístupu musí mít uživatel následující oprávnění, aby mohl povolit bezplatné sledování a získat stav:

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

Tento nástroj může být dobrým začátkem pro ty, pro které je obtížné číst výstup stavu serveru MongoDB z příkazového řádku:

db.serverStatus()

Free Monitoring je dobrý začátek, ale má velmi omezené možnosti. Pokud potřebujete pokročilejší nástroj, možná budete chtít zkontrolovat MongoDB Ops Manager nebo ClusterControl.

Protokolování databázových operací

Ovladače MongoDB a klientské aplikace mohou odesílat informace do souboru protokolu serveru. Tyto informace závisí na typu události. Chcete-li zkontrolovat aktuální nastavení, přihlaste se jako správce a spusťte:

db.getLogComponents()

Zprávy protokolu obsahují mnoho komponent. Účelem je poskytnout funkční kategorizaci zpráv. Pro každou komponentu můžete nastavit jinou podrobnost protokolu. Aktuální seznam součástí je:

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

Další podrobnosti o každé z komponent naleznete v dokumentaci.

Zachycování dotazů – Database Profiler

MongoDB Database Profiler shromažďuje informace o operacích, které běží proti instanci mongoda. Ve výchozím nastavení profiler neshromažďuje žádná data. Můžete si vybrat, zda chcete shromáždit všechny operace (hodnota 2) nebo ty, které trvají déle než hodnota slowms . Posledně jmenovaný je parametr instance, který lze ovládat prostřednictvím konfiguračního souboru mongodb. Chcete-li zkontrolovat aktuální úroveň:

db.getProfilingLevel()

Chcete-li zachytit všechny sady dotazů:

db.setProfilingLevel(2)

V konfiguračním souboru můžete nastavit:

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

Toto nastavení bude použito na jednu instanci a nebude se šířit přes sadu replik nebo sdílený klastr, takže pokud chcete zachytit všechny aktivity, musíte tento příkaz opakovat u všech uzlů. Profilování databáze může ovlivnit výkon databáze. Tuto možnost povolte pouze po pečlivém zvážení.

Poté vypíšete 10 nejnovějších:

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

Seznam všech:

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

A seznam pro konkrétní sbírku:

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

Protokolování MongoDB

Umístění protokolu MongoDB je definováno v nastavení cesty protokolu vaší konfigurace a obvykle je to /var/log/mongodb/mongod.log. Konfigurační soubor MongoDB najdete na /etc/mongod.conf.

Zde jsou ukázková data:

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

Podrobnost protokolu komponenty můžete upravit nastavením (příklad dotazu):

db.setLogLevel(2, "query")

Soubor protokolu může být významný, takže jej před profilováním možná budete chtít vymazat. Z konzoly příkazového řádku MongoDB zadejte:

db.runCommand({ logRotate : 1 });

Kontrola parametrů operačního systému

Omezení paměti

Chcete-li zobrazit limity spojené s vaším přihlášením, použijte příkaz ulimit -a. Následující prahové hodnoty a nastavení jsou zvláště důležité pro nasazení mongod a 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

Novější verze spouštěcího skriptu mongod (/etc/init.d/mongod) má výchozí nastavení zabudované do možnosti start:

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
}

Úlohou podsystému správy paměti, také nazývaného správce virtuální paměti, je řídit alokaci fyzické paměti (RAM) pro celé jádro a uživatelské programy. To je řízeno parametry vm.*. Existují dva, které byste měli zvážit na prvním místě, abyste mohli vyladit výkon MongoDB – vm.dirty_ratio a vm.dirty_background_ratio .

vm.dirty_ratio je absolutní maximální množství systémové paměti, které lze zaplnit špinavými stránkami, než se vše musí uložit na disk. Když se systém dostane do tohoto bodu, všechny nové I/O bloky, dokud nebudou na disk zapsány špinavé stránky. To je často zdrojem dlouhých I/O pauz. Výchozí hodnota je 30, což je obvykle příliš vysoká hodnota. vm.dirty_background_ratio je procento systémové paměti, které lze zaplnit „špinavými“ stránkami – paměťovými stránkami, které je ještě třeba zapsat na disk. Dobrým začátkem je přejít od 10 a měřit výkon. Pro prostředí s nízkou pamětí je 20 dobrý začátek. Doporučené nastavení pro nečisté poměry na databázových serverech s velkou pamětí je vm.dirty_ratio =15 a vm.dirty_background_ratio =5 nebo možná méně.

Chcete-li zkontrolovat poměr znečištění, spusťte:

sysctl -a | grep dirty

Můžete to nastavit přidáním následujících řádků do „/etc/sysctl.conf“:

Výměnnost

Na serverech, kde je MongoDB jedinou spuštěnou službou, je dobrým zvykem nastavit vm.swapiness =1. Výchozí nastavení je 60, což není vhodné pro databázový systém.

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

Transparentní velké stránky

Pokud provozujete MongoDB na RedHatu, ujistěte se, že je zakázáno Transparent Huge Pages.
To lze zkontrolovat příkazem:

cat /proc/sys/vm/nr_hugepages 
0

0 znamená, že průhledné velké stránky jsou zakázány.

Možnosti systému souborů

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

NUMA (Nejednotný přístup do paměti)

MongoDB nepodporuje NUMA, vypněte ji v BIOSu.

Síťový zásobník

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

K instalaci démona časového serveru NTP použijte jeden z následujících systémových příkazů.

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

Další podrobnosti o výkonu operačního systému pro MongoDB najdete v jiném blogu.

Vysvětlete plán

Podobně jako jiné populární databázové systémy, MongoDB poskytuje vysvětlení, které odhaluje, jak byla databázová operace provedena. Výsledky vysvětlení zobrazí plány dotazů jako strom fází. Každá fáze předává své události (tj. dokumenty nebo indexové klíče) nadřazenému uzlu. Listové uzly přistupují ke kolekci nebo indexům. K dotazu můžete přidat vysvětlení('executionStats').

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

Klíče, na jejichž hodnoty byste si měli dávat pozor ve výstupu výše uvedeného provádění příkazu:

• totalKeysExamined:Celkový počet položek rejstříku prohledaných za účelem vrácení dotazu.
• totalDocsExamined:Celkový počet dokumentů naskenovaných za účelem nalezení výsledků.
• executionTimeMillis:Celkový čas v milisekundách potřebný pro výběr plánu dotazů a provedení dotazu.

Měření výkonu zpoždění replikace

Prodleva replikace je prodleva mezi operací na primární a aplikací této operace z oplogu na sekundární. Jinými slovy, definuje, jak daleko je sekundární uzel za primárním uzlem, což by v nejlepším případě mělo být co nejblíže 0.

Proces replikace může být ovlivněn z několika důvodů. Jedním z hlavních problémů může být, že sekundárním členům dochází kapacita serveru. Velké operace zápisu na primárním členu, které vedly k tomu, že sekundární členové nemohli znovu přehrát oplogy, nebo sestavení indexu na primárním členu.

Chcete-li zkontrolovat aktuální zpoždění replikace, spusťte v prostředí MongoDB:

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

Výstup stavu replikace lze použít k posouzení aktuálního stavu replikace a určení, zda nedošlo k nezamýšlenému zpoždění replikace.

rs.printSlaveReplicationInfo()

Zobrazuje časové zpoždění mezi sekundárními členy vzhledem k primárnímu.

rs.status()

Zobrazuje podrobné podrobnosti pro replikaci. Pomocí těchto příkazů můžeme získat dostatek informací o replikaci. Doufejme, že tyto tipy poskytují rychlý přehled o tom, jak zkontrolovat výkon MongoDB. Dejte nám vědět, pokud jsme něco přehlédli.