Kā uzraudzīt MongoDB datu bāzes veiktspēju

Riks Golba ir Percona risinājumu inženieris.

MongoDB ir iecienīta izstrādātāju datu bāze. Kā NoSQL datu bāzes opciju tas nodrošina izstrādātājus ar datu bāzes vidi, kurai ir elastīgs shēmas dizains, automatizēta kļūmjpārlēce un izstrādātājam pazīstama ievades valoda, proti, JSON.

NoSQL datu bāzēm ir daudz dažādu veidu. Atslēgu vērtību veikali glabā un izgūst katru vienumu, izmantojot tā nosaukumu (pazīstams arī kā atslēga). Plaši kolonnu krājumi ir sava veida atslēgu vērtību krātuve, kas izmanto kolonnas un rindas (līdzīgi kā relāciju datu bāzē), var atšķirties tikai tabulas kolonnu un rindu nosaukumi. Grafiku datu bāzēs datu tīklu glabāšanai izmanto grafu struktūras. Uz dokumentu orientētās datubāzēs dati tiek glabāti kā dokumenti, nodrošinot lielāku strukturālo elastību nekā citās datubāzēs.

MongoDB ir uz dokumentiem orientēta datu bāze. Tā ir starpplatformu datu bāze, kas satur datus dokumentos binārā kodētā JSON formātā (pazīstama kā binārā JSON vai BSON). Binārais formāts palielina gan JSON ātrumu, gan elastību un pievieno vairāk datu veidu.

MongoDB replikācijas mehānismi palīdz nodrošināt augstu pieejamību, un tā sasmalcināšanas mehānisms ļauj veikt horizontālu mērogojamību. Daudzi labākie interneta uzņēmumi, piemēram, Facebook un eBay, savā datu bāzes vidē izmanto MongoDB.

Kāpēc jāuzrauga MongoDB?

Jūsu MongoDB datu bāzes vide var būt vienkārša vai sarežģīta, lokāla vai izplatīta, lokāli vai mākonī. Ja vēlaties nodrošināt izpildītāju un pieejamu datu bāzi, jums jāizseko un jāuzrauga analīze, lai:

• Nosakiet datubāzes pašreizējo stāvokli
• Pārskatiet veiktspējas datus, lai identificētu neparastu uzvedību
• Sniedziet dažus diagnostikas datus, lai atrisinātu identificētās problēmas
• Novērsiet mazus jautājumus, pirms tie kļūst par lielākiem jautājumiem
• Uzturiet savu vidi nevainojami
• Nodrošiniet pastāvīgu pieejamību un panākumus

Mērāmi un regulāri uzraugot datu bāzes vidi, jūs varat pamanīt visas neatbilstības, nepāra uzvedību vai problēmas, pirms tās ietekmē veiktspēju. Pareiza uzraudzība nozīmē, ka jūs varat ātri pamanīt palēninājumus, resursu ierobežojumus vai citu nepareizu rīcību un rīkoties, lai novērstu šīs problēmas, pirms tiekat skarts ar lēnu vietņu un lietojumprogrammu, nepieejamu datu vai neapmierinātu klientu sekām.

Kas mums jāuzrauga?

MongoDB vidē ir daudz lietu, kuras varat uzraudzīt, taču dažas galvenās jomas jūs ātri pamudinās, ja kaut kas nav kārtībā. Jums vajadzētu analizēt šādu metriku:

• Replikācijas kavēšanās. Replikācijas aizture attiecas uz aizkavēšanos datu kopēšanā no primārā mezgla uz sekundāro mezglu.
• Replikas stāvoklis. Replikas stāvoklis ir izsekošanas metode, ja sekundārie mezgli ir miruši un ja tika izvēlēts jauns primārais mezgls.
• Bloķēšanas stāvoklis. Bloķēšanas stāvoklis parāda, kādas datu slēdzenes ir iestatītas, un to, cik ilgi tās ir bijušas.
• Diska izmantošana. Diska izmantošana attiecas uz piekļuvi diskam.
• Atmiņas izmantošana. Atmiņas lietojums attiecas uz to, cik daudz atmiņas tiek izmantots un kā tas tiek izmantots.
• Savienojumu skaits. Datubāzē atvērto savienojumu skaits, lai pēc iespējas ātrāk apkalpotu pieprasījumus.

Iedziļināsimies dažās detaļās.

Replikācijas kavēšanās

MongoDB izmanto replikāciju, lai izpildītu pieejamības problēmas un mērķus. Replikācija ir datu izplatīšana no primārā mezgla uz vairākiem sekundāriem mezgliem, jo ​​darbības ar primāro mezglu maina datus. Šie mezgli var atrasties vienā vietā, dažādās ģeogrāfiskās vietās vai virtuāli.

Ja viss ir vienāds, datu replikācijai vajadzētu notikt ātri un bez problēmām. Var notikt daudzas lietas, kas aptur replikācijas procesa nevainojamu izpildi. Pat vislabākajos apstākļos tīkla fiziskās īpašības ierobežo to, cik ātri dati tiek atkārtoti. Kavēšanos starp replikācijas sākšanu un pabeigšanu sauc par replikācijas kavēšanos.

Vienmērīgi darbojošos primāro un sekundāro mezglu komplektā (saukts par “kopiju kopu”) sekundārie ātri kopē izmaiņas primārajā, atkārtojot katru operāciju grupu no oplog tik ātri, cik tās notiek (vai pēc iespējas tuvāk) . Mērķis ir saglabāt replikācijas nobīdi tuvu nullei. Datu nolasīšanai no jebkura mezgla jābūt konsekventam. Ja ievēlētais primārais mezgls pazeminās vai kļūst citādi nepieejams, sekundārais var pārņemt galveno lomu, neietekmējot datu precizitāti klientiem. Atkārtotajiem datiem ir jāatbilst primārajiem datiem, pirms tie samazinās.

Replikācijas aizkavēšanās ir iemesls, kāpēc primārie un sekundārie mezgli izkļūst no sinhronizācijas. Ja par galveno tiek izvēlēts sekundārais mezgls un replikācijas aizkave ir liela, sekundārā datu versija var būt novecojusi. Paaugstinātas replikācijas aizkavēšanās stāvoklis var notikt vairāku nenoturīgu vai nenoteiktu iemeslu dēļ, un tas var izlaboties. Tomēr, ja replikācijas aizkavēšanās paliek augsta vai sāk pieaugt regulāri, tas liecina par sistēmiskām vai vides problēmām. Jebkurā gadījumā, jo lielāka replikācijas kavēšanās - un jo ilgāk tā saglabājas augsta -, jo vairāk jūsu dati riskē būt novecojuši klientiem.

Ir tikai viens veids, kā analizēt šo metriku: uzraudzīt to! Šī ir metrika, kas jāuzrauga 24x7x365, tāpēc to vislabāk izdarīt, izmantojot automatizāciju un aktivizēt brīdinājumus, lai brīdinātu DBA vai atbildes sistēmas administratorus, tiklīdz tas sasniedz nevēlamu slieksni. Šī sliekšņa konfigurācija ir atkarīga no jūsu lietojumprogrammas pielaides replikācijas aizkavei. Lai noteiktu pareizo slieksni, izmantojiet rīku, kas grafiski attēlo laika aizturi, piemēram, Compass, MongoBooster, Studio 3T vai Percona Monitoring and Management (PMM).

Replikas stāvoklis

Replikācija tiek veikta, izmantojot kopiju komplektus. Replikas kopa ir mezglu kopa ar ievēlētu primāro mezglu un vairākiem sekundārajiem mezgliem. Primārais mezgls ir visjaunāko datu turētājs, un šie dati tiek atkārtoti sekundārajiem datiem, kad tiek veiktas izmaiņas primārajā.

Parasti viens kopiju kopas dalībnieks ir primārais, un visi pārējie dalībnieki ir sekundārie. Piešķirtais statuss reti mainās. Ja tā notiek, mēs vēlamies par to uzzināt (parasti nekavējoties). Lomu maiņa parasti notiek ātri un parasti nevainojami, taču ir svarīgi precīzi saprast, kāpēc mezgla statuss mainījās, jo tas varēja notikt aparatūras vai tīkla kļūmes dēļ. Mainīšana starp primārajiem un sekundārajiem stāvokļiem (pazīstama arī kā plivināšanās) nav normāla parādība, un ideālā pasaulē to vajadzētu notikt tikai zināmu iemeslu dēļ (piemēram, veicot vides uzturēšanu, piemēram, programmatūras vai aparatūras jaunināšanu, vai konkrēta gadījuma laikā, piemēram, kā tīkla pārtraukums).

Bloķēšanas stāvoklis

Datu bāzes ir ļoti vienlaicīgas un nepastāvīgas vides, kurās vairāki klienti iesniedz pieprasījumus un ierosina darījumus, kas tiek veikti ar datiem. Šie pieprasījumi un darījumi nenotiek secīgi vai racionālā secībā. Var rasties konflikti - piemēram, ja darījumi mēģina atjaunināt to pašu ierakstu vai dokumentu, ja datu atjaunināšanas laikā rodas lasīšanas pieprasījums utt. Veids, kā daudzas datu bāzes nodarbojas ar to, lai datiem piekļūtu organizēti, ir “bloķēšana”. ” Bloķēšana notiek, ja darījums neļauj mainīt vai lasīt datu bāzes ierakstu, dokumentu, rindu, tabulu utt., Kamēr pašreizējais darījums nav apstrādāts.

MongoDB bloķēšana tiek veikta kolekcijas vai dokumenta līmenī, lai novērstu konfliktus starp vienlaicīgiem darījumiem. Dažām darbībām var būt nepieciešama arī globāla datu bāzes bloķēšana (piemēram, nometot kolekciju). Ja bloķēšana notiek pārāk bieži, tā ietekmē veiktspēju, liekot darījumiem (ieskaitot lasījumus) gaidīt, kamēr bloķētās datu bāzes daļas būs pieejamas lasīšanai vai modificēšanai. Liels bloķēšanas procents ir pazīme citām datu bāzes problēmām: aparatūras kļūme, slikta shēmas noformēšana, slikti konfigurēti indeksi, indeksu neizmantošana utt.

Ir svarīgi uzraudzīt bloķēšanas procentu. Pirms ietekmējat veiktspēju, jums jāzina, kāds ir pieņemams procentuālais rādītājs attiecībā uz veiktspēju un cik ilgi to var saglabāt. Ja veiktspēja pārāk daudz pasliktinās augsta bloķēšanas procenta dēļ, tas var izraisīt atkārtotu stāvokļa maiņu, reaģējot uz serveri.

Diska izmantošana

Katrai DBA jāuzrauga pieejamā diska vieta datu bāzes serveros. Kad datu bāze izmanto resursdatora vietu diskā, šis serveris pēkšņi apstājas. Proaktīva datu lieluma noteikšana un žurnāla failu izmēru pārraudzība ir lieliskas metodes datu bāzes lieluma noteikšanai.

Bieži vien datu bāzei, iespējams, būs jāaug automātiski. Šādos gadījumos jums jāgarantē, ka tas nepārsniedz aparatūru. Periodiska diska vietas pārskatīšana var palīdzēt novērst negaidītas datu bāzes servera apstāšanās, kā arī atrast sliktas dizaina problēmas (piemēram, vaicājumus, kuriem nepieciešama pilna kolekcijas skenēšana).

Atmiņas izmantošana

Paturot visus datus RAM atmiņā, paātrinās datu bāzes atbildes laiks. Bet ko tas nozīmē, un kā jūs zināt, kad kaut kas ir RAM?

Tas, kā datu bāze izmanto atmiņu, var būt nedaudz neskaidrs. Liela daļa servera izmantotās atmiņas ir paredzēta bufera kopai (datiem). Var būt grūti noskaidrot, kura datu bāze izmanto lielāko bufera kopas atmiņas daļu, un vēl grūtāk uzzināt, kuras kolekcijas vai dokumenti faktiski atrodas bufera kopas atmiņā. Šīs informācijas zināšana ir noderīga, ja līdzsvaro datu bāzes slodzi vairākos serveros (izmantojot sadalīšanu) vai identificē datus, kas ir optimāli apvienošanai vienā servera instancē.

Rīku izmantošana, lai noteiktu, kuri gadījumi visvairāk izmanto atmiņu un kādiem datiem, var palīdzēt optimizēt vidi.

Savienojumu skaits

Datu bāzes darījumus parasti sāk lietojumprogrammas un procesi, izmantojot “savienojumus”. Atvērto savienojumu skaits var ietekmēt datu bāzes veiktspēju. Teorētiski, kad darījums ir pabeigts, savienojums ir jāpārtrauc. Tomēr praksē daudzi savienojumi paliek atvērti. Tas ir normāli, ja datu bāze uztur dažus savienojumus dzīvus, lai atvieglotu noteiktus darījumus, taču, ja pārāk daudz atstāj atvērtu, tas var ierobežot savienojumu pūlā pieejamo skaitu.

Kā labāko praksi datubāzei jāsaglabā savienojumu atvēršana vismazāk laika, kas nepieciešams pieprasījuma izpildei. Tas ļauj nelielam savienojumu kopumam apkalpot lielu skaitu darījumu pieprasījumu. Pretējā gadījumā lietojumprogrammas transakcijas pieprasījumi būs iestrēguši, gaidot atvērtu savienojumu. Jums jāpārrauga atvērto savienojumu skaits datu bāzē, lai pārbaudītu, vai tie tiek slēgti un vai baseinā ir atlicis veselīgs savienojumu skaits ienākošajiem pieprasījumiem.

Rīki, kas nodrošināti ar MongoDB

Tagad, kad mēs zinām, kas mums jāuzrauga, nākamais jautājums ir, kā? Par laimi, MongoDB nāk ar dažiem viegli lietojamiem rīkiem servera statistikas uzraudzībai.

mongostats

Šī utilīta nodrošina globālu statistiku par atmiņas lietojumu, kopiju kopas statusu un citu informāciju, kas tiek atjaunināta katru sekundi (pēc noklusējuma).

The mongostats lietderība sniedz pārskatu par jūsu MongoDB servera instanci. Ja jūs izmantojat vienu “mongoda” gadījumu, tas parāda šī atsevišķā gadījuma statistiku. Ja izmantojat MongoDB klastera vidi, tā atgriež “mongo” instances statistiku. mongostats vislabāk var izmantot, lai skatītos atsevišķu gadījumu konkrētam notikumam (piemēram, kas notiek, kad ienāk konkrēts lietojumprogrammas pieprasījums). Servera pamata statistikas uzraudzībai varat izmantot šo komandu:

• Procesors
• Atmiņa
• Diska IO
• Tīkla trafika

Skatiet MongoDB dokumentāciju vietnē mongostats lietošanas specifikai.

mongotop

Šī utilīta nodrošina kolekcijas līmeņa statistiku par lasīšanas un rakstīšanas darbībām.

The mongotop komanda izseko laiku, kas nepieciešams, lai pabeigtu lasīšanas un rakstīšanas operācijas MongoDB servera instancē. Tas sniedz statistiku katras kolekcijas līmenī. mongotop pēc noklusējuma atgriež vērtības katru sekundi, bet pēc vajadzības varat pielāgot laika periodu.

Visa sekundes metrika ir atkarīga no jūsu servera konfigurācijas, kā arī klastera arhitektūras. Atsevišķiem gadījumiem, kas darbojas lokāli, un, izmantojot noklusējuma portu, viss, kas jums jādara, ir ievadīt mongotop komandu. Ja jūs darbojaties sakopotā vidē ar vairākiem mongodu un mongožu gadījumiem, ar komandu būs jānorāda resursdatora nosaukums un porta numurs.

Skatiet MongoDB dokumentāciju vietnē mongotop lietošanas specifikai.

rs.status ()

Šī komanda nodrošina kopiju kopas statusu.

Jūs varat izmantot rs.status () komandu, lai iegūtu informāciju par darbojošos kopiju kopu. Šo komandu var palaist jebkura kopas jebkura dalībnieka konsolē, un tā atgriezīs kopijas kopijas statusu, kā to redz attiecīgais dalībnieks.

Skatiet MongoDB dokumentāciju vietnē rs.status () lietošanas specifikai.