Klíčové věci ke sledování v MongoDB

Zvýšení výkonu systému, zejména u počítačových struktur, vyžaduje proces získání dobrého přehledu o výkonu. Tento proces se obecně nazývá monitorování. Monitorování je nezbytnou součástí správy databáze a podrobné informace o výkonu vašeho MongoDB vám nejen pomohou změřit jeho funkční stav; ale také poskytnout vodítko o anomáliích, což je užitečné při provádění údržby. Je nezbytné identifikovat neobvyklé chování a opravit je dříve, než eskaluje do závažnějších selhání.

Některé z typů selhání, které by mohly nastat, jsou...

• Prodleva nebo zpomalení
• Nepřiměřenost zdrojů
• Systémové škytavka

Monitorování je často zaměřeno na analýzu metrik. Některé z klíčových metrik, které budete chtít sledovat, zahrnují...

• Výkon databáze
• Využití zdrojů (využití CPU, dostupná paměť a využití sítě)
• Nové neúspěchy
• Nasycení a omezení zdrojů
• Propustnost operací

V tomto blogu podrobně probereme tyto metriky a podíváme se na dostupné nástroje z MongoDB (jako jsou nástroje a příkazy). Podíváme se také na další softwarové nástroje, jako je Pandora, FMS Open Source a Robo 3T. Pro jednoduchost použijeme v tomto článku software Robo 3T k demonstraci metrik.

Výkon databáze

První a nejdůležitější věcí, kterou je třeba zkontrolovat na databázi, je její obecný výkon, například zda je server aktivní nebo ne. Pokud spustíte tento příkaz db.serverStatus() na databázi v Robo 3T, zobrazí se vám tato informace zobrazující stav vašeho serveru.

Sady replik

Sada replik je skupina procesů mongodů, které udržují stejnou sadu dat. Pokud používáte sady replik zejména v produkčním režimu, provozní protokoly poskytnou základ pro proces replikace. Všechny operace zápisu jsou sledovány pomocí uzlů, což je primární uzel a sekundární uzel, které ukládají kolekci omezené velikosti. Na primárním uzlu se aplikují a zpracují operace zápisu. Pokud však primární uzel selže před zkopírováním do provozních protokolů, provede se sekundární zápis, ale v tomto případě nemusí být data replikována.

Klíčové metriky, které je třeba sledovat...

Prodleva replikace

Toto definuje, jak daleko je sekundární uzel za primárním uzlem. Optimální stav vyžaduje, aby mezera byla co nejmenší. Na normálním operačním systému se toto zpoždění odhaduje na 0. Pokud je mezera příliš velká, bude integrita dat narušena, jakmile bude sekundární uzel povýšen na primární. V tomto případě můžete nastavit práh, například 1 minutu, a v případě jeho překročení se nastaví výstraha. Mezi běžné příčiny velkého zpoždění replikace patří...

1. Shardy, které mohou mít nedostatečnou kapacitu pro zápis, což je často spojeno se saturací zdrojů.
2. Sekundární uzel poskytuje data pomaleji než primární uzel.
3. Uzly mohou být také nějakým způsobem bráněny v komunikaci, pravděpodobně kvůli špatné síti.
4. Operace na primárním uzlu mohou být také pomalejší, a tím blokovat replikaci. Pokud k tomu dojde, můžete spustit následující příkazy:
   1. db.getProfilingLevel():pokud získáte hodnotu 0, pak jsou vaše operace db optimální.
      Pokud je hodnota 1, pak to odpovídá pomalým operacím, které mohou být následně způsobeny pomalými dotazy.
   2. db.getProfilingStatus():v tomto případě kontrolujeme hodnotu slowms, standardně je to 100ms. Pokud je hodnota větší než tato, můžete mít náročné operace zápisu na primární nebo nedostatečné prostředky na sekundární. Abyste to vyřešili, můžete škálovat sekundární, takže má tolik zdrojů jako primární.

Kurzory

Pokud zadáte požadavek na čtení, například find, budete mít k dispozici kurzor, který je ukazatelem na datovou sadu výsledku. Pokud spustíte tento příkaz db.serverStatus() a přejdete na objekt metrics a poté kurzor, uvidíte toto…

V tomto případě byla vlastnost kurzor.timeOut přírůstkově aktualizována na 9, protože došlo k 9 připojení, která zemřela bez zavření kurzoru. Důsledkem je, že zůstane otevřená na serveru, a tedy spotřebovává paměť, pokud není sklizena podle výchozího nastavení MongoDB. Upozornění pro vás by měla být identifikace neaktivních kurzorů a jejich sklízení, abyste ušetřili paměť. Můžete se také vyhnout kurzorům bez časového limitu, protože často zadržují prostředky, čímž zpomalují výkon vnitřního systému. Toho lze dosáhnout nastavením hodnoty vlastnosti kurzor.open.noTimeout na hodnotu 0.

Ukládání deníků

S ohledem na WiredTiger Storage Engine jsou data před zaznamenáním nejprve zapsána do souborů na disku. Toto se nazývá žurnálování. Žurnálování zajišťuje dostupnost a trvanlivost dat v případě selhání, ze kterého lze provést obnovu.

Pro účely obnovy často používáme kontrolní body (zejména pro úložný systém WiredTiger) k obnově z posledního kontrolního bodu. Pokud se však MongoDB neočekávaně vypne, pak použijeme techniku ​​žurnálování k obnovení všech dat, která byla zpracována nebo poskytnuta po posledním kontrolním bodu.

Žurnálování by nemělo být v prvním případě vypnuto, protože vytvoření nového kontrolního bodu trvá pouze 60 sekund. Pokud tedy dojde k selhání, MongoDB může přehrát žurnál a obnovit data ztracená během těchto sekund.

Žurnálování obecně zužuje časový interval od okamžiku, kdy jsou data aplikována do paměti, až do doby, kdy jsou trvanlivá na disku. Objekt storage.journal má vlastnost, která popisuje frekvenci odevzdání, tj. commitIntervalMs, která je pro WiredTiger často nastavena na hodnotu 100 ms. Vyladěním na nižší hodnotu zlepšíte časté nahrávání zápisů, a tím omezíte případy ztráty dat.

Zamykání výkonu

To může být způsobeno vícenásobnými požadavky na čtení a zápis od mnoha klientů. Když k tomu dojde, je potřeba zachovat konzistenci a vyhnout se konfliktům při zápisu. Aby toho bylo dosaženo, MongoDB používá zamykání s více granularitami, které umožňuje, aby operace zamykání probíhaly na různých úrovních, jako je globální úroveň, úroveň databáze nebo kolekce.

Pokud máte špatné vzory návrhu schématu, budete zranitelní vůči zámkům, které budou drženy po dlouhou dobu. K tomu často dochází při provádění dvou nebo více různých operací zápisu do jednoho dokumentu ve stejné kolekci, což má za následek vzájemné blokování. Pro úložiště WiredTiger můžeme použít lístkový systém, kde požadavky na čtení nebo zápis přicházejí z něčeho jako fronta nebo vlákno.

Ve výchozím nastavení je počet souběžných operací čtení a zápisu definován parametry wiredTigerConcurrentWriteTransactions a wiredTigerConcurrentReadTransactions, které jsou oba nastaveny na hodnotu 128.

Pokud tuto hodnotu změníte příliš vysoko, budete nakonec omezeni prostředky CPU. Pro zvýšení propustnosti operací by bylo vhodné horizontálně škálovat poskytnutím více útržků.

Využití zdrojů

To obecně popisuje využití dostupných zdrojů, jako je kapacita CPU/rychlost zpracování a RAM. Výkon, zejména pro CPU, se může drasticky měnit v souladu s neobvyklým provozním zatížením. Mezi věci, které je třeba zkontrolovat, patří...

1. Počet připojení
2. Úložiště
3. Mezipaměť

Počet připojení

Pokud je počet připojení vyšší, než kolik dokáže databázový systém zpracovat, bude vznikat mnoho front. V důsledku toho dojde k přetížení výkonu databáze a nastavení bude probíhat pomalu. Toto číslo může způsobit problémy s ovladačem nebo dokonce komplikace s vaší aplikací.

Pokud po určitou dobu sledujete určitý počet připojení a pak si všimnete, že tato hodnota dosáhla vrcholu, je vždy dobré nastavit upozornění, pokud připojení překročí tento počet.

Pokud je číslo příliš vysoké, můžete jej zvýšit, abyste tomuto nárůstu vyhověli. Chcete-li to provést, musíte znát počet dostupných připojení v daném období, jinak, pokud nebudou dostupná připojení dostatečná, nebudou požadavky vyřizovány včas.

Ve výchozím nastavení MongoDB poskytuje podporu až pro 1 milion připojení. Při sledování vždy zajistěte, aby se aktuální připojení nikdy příliš nepřiblížilo této hodnotě. Hodnotu můžete zkontrolovat v objektu připojení.

Úložiště

Každý řádek a datový záznam v MongoDB je označován jako dokument. Data dokumentu jsou ve formátu BSON. Pokud v dané databázi spustíte příkaz db.stats(), zobrazí se vám tato data.

• StorageSize definuje velikost všech datových rozsahů v databázi.
• Velikost indexu uvádí velikost všech indexů vytvořených v této databázi.
• dataSize je míra celkového prostoru, který zabírají dokumenty v databázi.

Někdy můžete vidět změnu v paměti, zejména pokud bylo odstraněno velké množství dat. V tomto případě byste měli nastavit upozornění, abyste se ujistili, že to nebylo způsobeno škodlivou aktivitou.

Někdy se může celková velikost úložiště vystřelit, když je graf provozu databáze konstantní, a v tomto případě byste měli zkontrolovat strukturu vaší aplikace nebo databáze, abyste se vyhnuli duplicitám, pokud to není potřeba.

Stejně jako obecná paměť počítače má MongoDB také mezipaměti, ve kterých jsou dočasně uložena aktivní data. Operace si však může vyžádat data, která nejsou v této aktivní paměti, a proto může vyvolat požadavek z úložiště hlavního disku. Tento požadavek nebo situace se nazývá chyba stránky. Požadavky na chyby stránky přicházejí s omezením, které trvá delší dobu, a mohou být škodlivé, když se vyskytují často. Abyste se tomuto scénáři vyhnuli, ujistěte se, že velikost vaší paměti RAM je vždy dostatečná k pokrytí datových sad, se kterými pracujete. Měli byste se také ujistit, že nemáte žádnou nadbytečnost schématu nebo zbytečné indexy.

Cache

Cache je dočasné úložiště dat pro často používaná data. V WiredTiger se často používá mezipaměť systému souborů a mezipaměť úložiště. Vždy zajistěte, aby se vaše pracovní sada nezvětšila za dostupnou mezipaměť, jinak se počet chyb stránek zvýší a způsobí problémy s výkonem.

V určitém okamžiku se můžete rozhodnout upravit své časté operace, ale změny se někdy neprojeví v mezipaměti. Tato nezměněná data se označují jako „špinavá data“. Existuje, protože ještě nebyl vyprázdněn na disk. Pokud množství „špinavých dat“ naroste na nějakou průměrnou hodnotu definovanou pomalým zápisem na disk, dojde k úzkým místům. Přidání dalších úlomků pomůže toto číslo snížit.

Využití CPU

Nesprávné indexování, špatná struktura schématu a nepřívětivě navržené dotazy budou vyžadovat větší pozornost CPU, a proto samozřejmě zvýší jeho využití.

Operace s propustností

Dostatek informací o těchto operacích může do značné míry umožnit vyhnout se následným neúspěchům, jako jsou chyby, saturace zdrojů a funkční komplikace.

Vždy byste si měli poznamenat počet operací čtení a zápisu do databáze, tedy celkový pohled na aktivity clusteru. Znalost počtu operací generovaných pro požadavky vám umožní vypočítat zatížení, které má databáze zvládnout. Zátěž pak může být řešena buď zvětšením vaší databáze, nebo zmenšením; v závislosti na typu zdrojů, které máte. To vám umožní snadno změřit poměr podílu, ve kterém se požadavky hromadí, k rychlosti, jakou jsou zpracovávány. Kromě toho můžete své dotazy vhodně optimalizovat, abyste zlepšili výkon.

Chcete-li zkontrolovat počet operací čtení a zápisu, spusťte tento příkaz db.serverStatus(), poté přejděte k objektu locks.global, hodnota pro vlastnost r představuje počet požadavků na čtení a w počet zápisů.

Operace čtení jsou častěji více než operace zápisu. Metriky aktivních klientů jsou hlášeny pod globalLock.

Nasycení a omezení zdrojů

Někdy databáze nemusí držet krok s rychlostí zápisu a čtení, jak ukazuje rostoucí počet požadavků ve frontě. V tomto případě musíte svou databázi zvětšit poskytnutím více fragmentů, aby MongoDB mohl reagovat dostatečně rychle.

Vznikající neúspěchy

Soubory protokolu MongoDB vždy poskytují obecný přehled o vrácených výjimkách pro potvrzení. Tento výsledek vám poskytne vodítko k možným příčinám chyb. Pokud spustíte příkaz db.serverStatus(), některá chybová upozornění, která si všimnete, zahrnují:

1. Pravidelná tvrzení:jsou výsledkem selhání operace. Například ve schématu, pokud je do celočíselného pole poskytnuta řetězcová hodnota, což má za následek selhání při čtení dokumentu BSON.
2. Upozornění:toto jsou často upozornění na nějaký problém, ale nemají velký vliv na jeho fungování. Když například upgradujete MongoDB, můžete být upozorněni pomocí zastaralých funkcí.
3. Potvrzení zprávy:jsou výsledkem výjimek interního serveru, jako je pomalá síť nebo pokud server není aktivní.
4. Uživatelská tvrzení:stejně jako běžná tvrzení vznikají tyto chyby při provádění příkazu, ale často jsou vráceny klientovi. Například pokud existují duplicitní klíče, nedostatečný prostor na disku nebo žádný přístup k zápisu do databáze. Chcete-li tyto chyby opravit, rozhodnete se zkontrolovat svou aplikaci.