PostgreSQL uzraudzības pamati. Aleksejs Ļesovskis

Iesaku izlasīt Alekseja Ļesovska ziņojuma atšifrējumu no Data Egret “PostgreSQL monitoringa pamati”

Šajā ziņojumā Aleksejs Ļesovskis runās par galvenajiem post-sacensību statistikas punktiem, ko tie nozīmē un kāpēc tiem vajadzētu būt klāt monitoringā; par to, kādiem grafikiem jābūt monitoringā, kā tos pievienot un kā tos interpretēt. Pārskats būs noderīgs datu bāzu administratoriem, sistēmu administratoriem un izstrādātājiem, kuri interesējas par Postgres problēmu novēršanu.

Mani sauc Aleksejs Ļesovskis, es pārstāvu uzņēmumu Data Egret.

Daži vārdi par sevi. Es jau sen sāku strādāt kā sistēmas administrators.

Administrēju visdažādākās Linux sistēmas, strādāju pie dažādām ar Linux saistītām lietām, t.i., virtualizācijas, monitoringa, strādāju ar starpniekserveriem utt. Bet kādā brīdī sāku vairāk strādāt ar datu bāzēm, PostgreSQL. Man viņš ļoti patika. Un kādā brīdī es sāku strādāt ar PostgreSQL lielāko daļu sava darba laika. Un tā pakāpeniski es kļuvu par PostgreSQL DBA.

Un visas savas karjeras laikā mani vienmēr ir interesējušas statistikas, monitoringa un telemetrijas tēmas. Un, kad es biju sistēmas administrators, es ļoti cieši sadarbojos ar Zabbix. Un es uzrakstīju nelielu skriptu komplektu, piemēram zabbix-paplašinājumi. Savā laikā viņš bija diezgan populārs. Un tur varēja uzraudzīt ļoti dažādas svarīgas lietas, ne tikai Linux, bet arī dažādus komponentus.

Tagad es strādāju pie PostgreSQL. Es jau rakstu vēl vienu lietu, kas ļauj strādāt ar PostgreSQL statistiku. Tas tiek saukts pgCenter (raksts par Habrē - Statistika pēc progresa bez nerviem un spriedzes).

Neliela ievada piezīme. Kādas situācijas ir mūsu klientiem, mūsu klientiem? Ir kaut kāds negadījums saistībā ar datu bāzi. Un, kad datu bāze jau ir atjaunota, nāk nodaļas vadītājs vai attīstības vadītājs un saka: "Draugi, mums ir jāuzrauga datu bāze, jo ir noticis kaut kas slikts un ir nepieciešams, lai tas nenotiktu nākotnē." Un šeit sākas interesantais process, izvēloties monitoringa sistēmu vai pielāgojot esošo uzraudzības sistēmu, lai jūs varētu uzraudzīt savu datu bāzi - PostgreSQL, MySQL vai dažas citas. Un kolēģi sāk ieteikt: “Es dzirdēju, ka ir tāda un tāda datubāze. Izmantosim." Kolēģi sāk strīdēties savā starpā. Un beigās izrādās, ka mēs atlasām kaut kādu datu bāzi, bet PostgreSQL monitorings tajā ir diezgan vāji attēlots un vienmēr kaut kas jāpievieno. Paņemiet dažas repozitorijas no GitHub, klonējiet tās, pielāgojiet skriptus un kaut kā pielāgojiet tos. Un galu galā tas ir kaut kāds roku darbs.

Tāpēc šajā runā es mēģināšu sniegt jums zināšanas par to, kā izvēlēties monitoringu ne tikai PostgreSQL, bet arī datubāzei. Un dos jums zināšanas, kas ļaus pabeigt uzraudzību, lai no tā gūtu kādu labumu, lai jūs varētu ar labumu uzraudzīt savu datubāzi, lai operatīvi novērstu iespējamās ārkārtas situācijas.

Un idejas, kas būs šajā pārskatā, var tieši pielāgot jebkurai datubāzei, vai tā būtu DBVS vai noSQL. Tāpēc ir ne tikai PostgreSQL, bet būs daudz recepšu, kā to izdarīt PostgreSQL. Būs vaicājumu piemēri, entītiju piemēri, kas PostgreSQL ir paredzētas uzraudzībai. Un, ja jūsu DBVS ir tās pašas lietas, kas ļauj tās ievietot uzraudzībā, varat arī tās pielāgot, pievienot un būs labi.

Es nepiedalīšos ziņojumā
runāt par to, kā piegādāt un uzglabāt metriku. Par datu pēcapstrādi un pasniegšanu lietotājam neko neteikšu. Un es neko neteikšu par brīdināšanu.
Bet stāstam turpinoties, es rādīšu dažādus esošā monitoringa ekrānuzņēmumus un kaut kā tos kritizēšu. Bet tomēr es centīšos nenosaukt zīmolus, lai neradītu šiem produktiem reklāmu vai antireklāmu. Tāpēc visas sakritības ir nejaušas un ir atstātas jūsu iztēlei.

Pirmkārt, izdomāsim, kas ir uzraudzība. Uzraudzība ir ļoti svarīga lieta. Visi to saprot. Taču tajā pašā laikā uzraudzība neattiecas uz biznesa produktu un tieši neietekmē uzņēmuma peļņu, tāpēc uzraudzībai laiks vienmēr tiek atvēlēts uz atlikumu. Ja mums ir laiks, tad veicam uzraudzību; ja nav laika, tad labi, iekļausim to atlikumos un kādreiz atgriezīsimies pie šiem uzdevumiem.

Tāpēc no mūsu prakses, kad mēs nonākam pie klientiem, uzraudzība bieži ir nepilnīga un tajā nav nekādu interesantu lietu, kas palīdzētu mums labāk strādāt ar datu bāzi. Un tāpēc uzraudzība vienmēr ir jāpabeidz.

Datu bāzes ir tik sarežģītas lietas, kas arī jāuzrauga, jo datu bāzes ir informācijas krātuve. Un informācija uzņēmumam ir ļoti svarīga, to nekādā veidā nevar pazaudēt. Taču tajā pašā laikā datu bāzes ir ļoti sarežģītas programmatūras daļas. Tie sastāv no liela skaita sastāvdaļu. Un daudzas no šīm sastāvdaļām ir jāuzrauga.

Ja mēs runājam tieši par PostgreSQL, tad to var attēlot shēmas veidā, kas sastāv no liela skaita komponentu. Šīs sastāvdaļas mijiedarbojas viena ar otru. Un tajā pašā laikā PostgreSQL ir tā saucamā Stats Collector apakšsistēma, kas ļauj apkopot statistiku par šo apakšsistēmu darbību un nodrošināt kaut kādu saskarni administratoram vai lietotājam, lai viņš varētu apskatīt šo statistiku.

Šī statistika tiek parādīta noteikta funkciju un skatu veidā. Tos var saukt arī par galdiem. Tas ir, izmantojot parasto psql klientu, varat izveidot savienojumu ar datu bāzi, atlasīt šīs funkcijas un skatus un iegūt dažus konkrētus skaitļus par PostgreSQL apakšsistēmu darbību.

Varat pievienot šos skaitļus savai iecienītajai uzraudzības sistēmai, zīmēt grafikus, pievienot funkcijas un iegūt analīzi ilgtermiņā.

Bet šajā ziņojumā es neaptvēru visas šīs funkcijas pilnībā, jo tas varētu aizņemt visu dienu. Es burtiski pievērsīšos divām, trim vai četrām lietām un pastāstīšu, kā tās palīdz uzlabot uzraudzību.

Un, ja mēs runājam par datu bāzes uzraudzību, tad kas ir jāuzrauga? Pirmkārt, mums ir jāuzrauga pieejamība, jo datubāze ir pakalpojums, kas nodrošina piekļuvi datiem klientiem, un mums ir jāuzrauga pieejamība, kā arī jānodrošina daži tās kvalitatīvie un kvantitatīvie raksturlielumi.

Mums ir arī jāuzrauga klienti, kas pieslēdzas mūsu datubāzei, jo tie var būt gan parasti klienti, gan kaitīgi klienti, kas var kaitēt datubāzei. Viņi arī ir jāuzrauga un jāseko viņu darbībai.

Kad klienti pieslēdzas datu bāzei, ir acīmredzams, ka viņi sāk strādāt ar mūsu datiem, tāpēc mums ir jāuzrauga, kā klienti strādā ar datiem: ar kādām tabulām un mazākā mērā ar kādiem indeksiem. Tas ir, mums ir jāizvērtē mūsu klientu radītā darba slodze.

Taču darba slodzi, protams, veido arī pieprasījumi. Lietojumprogrammas pieslēdzas datu bāzei, piekļūst datiem, izmantojot vaicājumus, tāpēc ir svarīgi izvērtēt, kādi vaicājumi mums ir datu bāzē, sekot līdzi to atbilstībai, lai tie nebūtu rakstīti greizi, ka dažas opcijas ir jāpārraksta un jāpadara tā, lai tās strādātu ātrāk un ar labāku veiktspēju.

Un tā kā mēs runājam par datu bāzi, datu bāze vienmēr ir fona procesi. Fona procesi palīdz uzturēt datu bāzes veiktspēju labā līmenī, tāpēc to darbībai ir nepieciešams noteikts resursu daudzums. Un tajā pašā laikā tie var pārklāties ar klientu pieprasījumu resursiem, tāpēc mantkārīgi fona procesi var tieši ietekmēt klientu pieprasījumu izpildi. Tāpēc arī tie ir jāuzrauga un jāseko līdzi, lai nebūtu nekādu traucējumu fona procesos.

Un tas viss datu bāzes uzraudzības ziņā paliek sistēmas metrikā. Taču, ņemot vērā, ka lielākā daļa mūsu infrastruktūras tiek pārvietota uz mākoņiem, atsevišķa resursdatora sistēmas rādītāji vienmēr izgaist fonā. Bet datu bāzēs tie joprojām ir aktuāli, un, protams, ir arī jāuzrauga sistēmas rādītāji.

Ar sistēmas metriku viss ir vairāk vai mazāk kārtībā, visas mūsdienu uzraudzības sistēmas jau atbalsta šos rādītājus, bet kopumā ar dažiem komponentiem joprojām nepietiek un dažas lietas ir jāpievieno. Pieskaršos arī tiem, par tiem būs vairāki slaidi.

Pirmais plāna punkts ir pieejamība. Kas ir pieejamība? Pieejamība manā izpratnē ir bāzes spēja apkalpot savienojumus, t.i., bāze ir pacelta, tā kā pakalpojums pieņem pieslēgumus no klientiem. Un šo pieejamību var novērtēt pēc noteiktiem raksturlielumiem. Šos raksturlielumus ir ļoti ērti parādīt informācijas paneļos.

Ikviens zina, kas ir informācijas paneļi. Tas ir tad, kad vienu reizi apskatījāt ekrānu, kurā ir apkopota nepieciešamā informācija. Un jūs varat uzreiz noteikt, vai datu bāzē ir problēma vai nē.
Attiecīgi informācijas paneļos vienmēr ir jāparāda datu bāzes pieejamība un citi galvenie raksturlielumi, lai šī informācija būtu jums vienmēr pieejama un pieejama. Dažas papildu detaļas, kas jau palīdz incidentu izmeklēšanā, izmeklējot dažas ārkārtas situācijas, tās jau ir jāievieto sekundārajos informācijas paneļos vai jāpaslēpj detalizētajās saitēs, kas ved uz trešo pušu uzraudzības sistēmām.

Vienas labi zināmas uzraudzības sistēmas piemērs. Šī ir ļoti forša uzraudzības sistēma. Viņa vāc daudz datu, taču no mana viedokļa viņai ir dīvains informācijas paneļu jēdziens. Ir saite uz "izveidot informācijas paneli". Bet, veidojot informācijas paneli, tiek izveidots divu kolonnu saraksts, grafiku saraksts. Un, kad vajag kaut ko apskatīt, sāc klikšķināt ar peli, ritināt, meklēt vajadzīgo diagrammu. Un tas prasa laiku, t.i., nav informācijas paneļu kā tādu. Ir tikai diagrammu saraksti.

Kas jums jāpievieno šiem informācijas paneļiem? Varat sākt ar tādu raksturlielumu kā reakcijas laiks. PostgreSQL ir pg_stat_statements skats. Pēc noklusējuma tas ir atspējots, taču tas ir viens no svarīgajiem sistēmas skatiem, kas vienmēr ir jāiespējo un jāizmanto. Tas saglabā informāciju par visiem esošajiem vaicājumiem, kas ir izpildīti datu bāzē.

Attiecīgi mēs varam sākt no tā, ka mēs varam ņemt visu pieprasījumu kopējo izpildes laiku un dalīt to ar pieprasījumu skaitu, izmantojot iepriekš minētos laukus. Bet tāda ir vidējā temperatūra slimnīcā. Varam sākt no citiem laukiem – minimālais vaicājuma izpildes laiks, maksimālais un mediāna. Un mēs pat varam izveidot procentiles; PostgreSQL šim nolūkam ir atbilstošas ​​funkcijas. Un mēs varam iegūt dažus skaitļus, kas raksturo mūsu datubāzes atbildes laiku jau izpildītiem pieprasījumiem, t.i., mēs neizpildām viltus pieprasījumu 'izvēlēties 1' un neskatāmies atbildes laiku, bet mēs analizējam atbildes laiku jau izpildītiem pieprasījumiem un izlozējam vai nu atsevišķu figūru, vai arī veidojam grafiku, pamatojoties uz to.

Ir arī svarīgi uzraudzīt sistēmas pašlaik ģenerēto kļūdu skaitu. Un šim nolūkam varat izmantot pg_stat_database skatu. Mēs koncentrējamies uz lauku xact_rollback. Šajā laukā tiek parādīts ne tikai datubāzē notikušo atcelšanas gadījumu skaits, bet arī tiek ņemts vērā kļūdu skaits. Relatīvi runājot, mēs varam parādīt šo skaitli mūsu informācijas panelī un redzēt, cik daudz kļūdu mums pašlaik ir. Ja kļūdu ir daudz, tas ir labs iemesls, lai izpētītu žurnālus un noskaidrotu, kāda veida kļūdas tās ir un kāpēc tās rodas, un pēc tam ieguldīt un atrisināt tās.

Varat pievienot tādu lietu kā tahometrs. Tie ir darījumu skaits sekundē un pieprasījumu skaits sekundē. Nosacīti runājot, varat izmantot šos skaitļus kā savas datubāzes pašreizējo veiktspēju un novērot, vai ir pieprasījumu maksimumi, darījumu maksimumi vai, gluži pretēji, vai datu bāze ir nepietiekami noslogota, jo kāda aizmugursistēma ir neizdevusies. Ir svarīgi vienmēr skatīties uz šo skaitli un atcerēties, ka mūsu projektam šāda veida veiktspēja ir normāla, taču vērtības virs un zemāk jau ir kaut kādas problemātiskas un nesaprotamas, kas nozīmē, ka mums ir jāskatās, kāpēc šie skaitļi ir tik augstu.

Lai novērtētu darījumu skaitu, mēs atkal varam atsaukties uz pg_stat_database skatu. Mēs varam pievienot apņemšanos skaitu un atcelšanu skaitu un iegūt darījumu skaitu sekundē.

Vai visi saprot, ka vienā darījumā var ietilpt vairāki pieprasījumi? Tāpēc TPS un QPS nedaudz atšķiras.

Pieprasījumu skaitu sekundē var iegūt no pg_stat_statements un vienkārši aprēķināt visu izpildīto pieprasījumu summu. Ir skaidrs, ka mēs salīdzinām pašreizējo vērtību ar iepriekšējo, atņemam to, iegūstam delta un iegūstam daudzumu.

Ja vēlaties, varat pievienot papildu rādītājus, kas arī palīdz novērtēt mūsu datu bāzes pieejamību un pārraudzīt, vai nav bijušas dīkstāves.

Viens no šiem rādītājiem ir darbspējas laiks. Taču PostgreSQL darbspējas laiks ir nedaudz grūts. Es jums pastāstīšu, kāpēc. Kad PostgreSQL ir palaists, darbspējas laiks sāk ziņot. Bet, ja kādā brīdī, piemēram, kāds uzdevums darbojās naktī, atnāca OOM-killer un piespiedu kārtā pārtrauca PostgreSQL bērnprocesu, tad šajā gadījumā PostgreSQL pārtrauc visu klientu savienojumu, atiestata šķelto atmiņas apgabalu un sāk atkopšanu no pēdējais kontrolpunkts. Un, kamēr šī atkopšanās no kontrolpunkta ilgst, datu bāze savienojumus nepieņem, t.i., šī situācija ir vērtējama kā dīkstāve. Bet darbības laika skaitītājs netiks atiestatīts, jo tas ņem vērā postmaster palaišanas laiku no paša pirmā brīža. Tāpēc šādas situācijas var izlaist.

Jums arī jāuzrauga vakuuma darbinieku skaits. Vai visi zina, kas ir autovakuums programmā PostgreSQL? Šī ir interesanta PostgreSQL apakšsistēma. Par viņu ir rakstīti daudzi raksti, tapuši daudzi ziņojumi. Ir daudz diskusiju par vakuumu un to, kā tam vajadzētu darboties. Daudzi to uzskata par nepieciešamu ļaunumu. Bet tā tas ir. Šis ir sava veida atkritumu savācēja analogs, kas attīra novecojušas rindu versijas, kuras nav vajadzīgas nevienam darījumam, un atbrīvo vietu tabulās un indeksos jaunām rindām.

Kāpēc jums tas jāuzrauga? Jo vakuums dažreiz ļoti sāp. Tas patērē lielu daudzumu resursu, un rezultātā sāk ciest klientu pieprasījumi.

Un tas jāuzrauga caur pg_stat_activity skatu, par kuru es runāšu nākamajā sadaļā. Šis skats parāda pašreizējo darbību datu bāzē. Izmantojot šo darbību, mēs varam izsekot pašlaik strādājošo putekļu sūcēju skaitam. Mēs varam izsekot vakuumiem un redzēt, ka, ja esam pārsnieguši limitu, tad tas ir iemesls ieskatīties PostgreSQL iestatījumos un kaut kā optimizēt vakuuma darbību.

Vēl viena lieta saistībā ar PostgreSQL ir tāda, ka PostgreSQL ir ļoti slims ar garām transakcijām. Īpaši no darījumiem, kas ilgi klīst un neko nedara. Tas ir tā sauktais stat dīkstāves darījums. Šāds darījums notur slēdzenes un neļauj vakuumam darboties. Un tā rezultātā galdi uzbriest un palielinās. Un vaicājumi, kas darbojas ar šīm tabulām, sāk darboties lēnāk, jo jums ir jāsavāc visas vecās rindu versijas no atmiņas uz disku un atpakaļ. Tāpēc ir jāuzrauga arī laiks, ilgāko darījumu ilgums, visilgākie vakuuma pieprasījumi. Un, ja mēs redzam dažus procesus, kas darbojas ļoti ilgu laiku, jau vairāk nekā 10-20-30 minūtes OLTP slodzei, tad mums ir jāpievērš tiem uzmanība un jāpiespiež tie jāpārtrauc vai jāoptimizē lietojumprogramma, lai tie netiek saukti un tik ilgi nekarājas. Analītiskajai slodzei 10-20-30 minūtes ir normālas, ir arī garākas.

Tālāk mums ir iespēja ar savienotiem klientiem. Kad esam jau izveidojuši informācijas paneli un ievietojuši tajā galvenos pieejamības rādītājus, varam tajā pievienot arī papildu informāciju par saistītajiem klientiem.

Informācija par savienotajiem klientiem ir svarīga, jo no PostgreSQL viedokļa klienti ir atšķirīgi. Ir labi klienti un ir slikti klienti.

Vienkāršs piemērs. Pēc klienta vārdiem es saprotu pieteikumu. Lietojumprogramma ir izveidojusi savienojumu ar datu bāzi un nekavējoties sāk sūtīt uz turieni savus pieprasījumus, datu bāze tos apstrādā un izpilda, un rezultātus atgriež klientam. Tie ir labi un pareizi klienti.

Ir situācijas, kad klients ir pieslēdzies, tas notur savienojumu, bet neko nedara. Tas ir dīkstāves stāvoklī.

Bet ir slikti klienti. Piemēram, tas pats klients pieslēdzās, atvēra darījumu, izdarīja kaut ko datu bāzē un pēc tam iegāja kodā, piemēram, lai piekļūtu ārējam avotam vai apstrādātu tur saņemtos datus. Bet viņš darījumu nenoslēdza. Un darījums karājas datu bāzē un tiek turēts līnijas slēdzenē. Tas ir slikts stāvoklis. Un, ja pēkšņi kāda lietojumprogramma kaut kur sevī neizdodas ar izņēmumu, tad darījums var palikt atvērts ļoti ilgu laiku. Un tas tieši ietekmē PostgreSQL veiktspēju. PostgreSQL būs lēnāks. Tāpēc ir svarīgi šādus klientus savlaicīgi izsekot un piespiedu kārtā pārtraukt viņu darbu. Un jums ir jāoptimizē sava lietojumprogramma, lai šādas situācijas nerastos.

Citi slikti klienti gaida klientus. Bet viņi kļūst slikti apstākļu dēļ. Piemēram, vienkāršs dīkstāves darījums: tas var atvērt darījumu, bloķēt dažas rindas, tad kaut kur kodā tas neizdosies, atstājot karājošu darījumu. Cits klients atnāks un pieprasīs tos pašus datus, taču viņš saskarsies ar bloķēšanu, jo šajā pakarinātajā darījumā jau ir bloķējumi dažās nepieciešamajās rindās. Un otrais darījums turpināsies, gaidot, kad pirmais darījums tiks pabeigts vai administrators to piespiedu kārtā aizvērs. Tāpēc neapstiprinātie darījumi var uzkrāties un aizpildīt datu bāzes savienojuma ierobežojumu. Un, kad limits ir pilns, lietojumprogramma vairs nevar strādāt ar datu bāzi. Tā jau ir projekta ārkārtas situācija. Tāpēc sliktie klienti ir jāseko līdzi un uz tiem ir jāreaģē savlaicīgi.

Vēl viens uzraudzības piemērs. Un šeit jau ir pienācīgs informācijas panelis. Iepriekš ir informācija par savienojumiem. DB pieslēgums – 8gab. Un viss. Mums nav informācijas par to, kuri klienti ir aktīvi, kuri ir tikai dīkā, neko nedarot. Nav informācijas par nepabeigtajiem darījumiem un neapstiprinātajiem savienojumiem, t.i., šis ir skaitlis, kas parāda savienojumu skaitu, un tas arī viss. Un tad uzminiet paši.

Attiecīgi, lai pievienotu šo informāciju uzraudzībai, jums ir jāpiekļūst pg_stat_activity sistēmas skatam. Ja jūs pavadāt daudz laika PostgreSQL, tad šis ir ļoti labs skats, kam vajadzētu kļūt par jūsu draugu, jo tas parāda pašreizējo darbību PostgreSQL, t.i., kas tajā notiek. Katram procesam ir atsevišķa rindiņa, kas parāda informāciju par šo procesu: no kura resursdatora tika izveidots savienojums, ar kādu lietotāju, ar kādu vārdu, kad transakcija tika sākta, kāds pieprasījums pašlaik tiek izpildīts, kāds pieprasījums tika izpildīts pēdējo reizi. Un attiecīgi varam novērtēt klienta stāvokli, izmantojot stat lauku. Relatīvi runājot, mēs varam grupēt pēc šī lauka un iegūt to statistiku, kas pašlaik ir datu bāzē, un savienojumu skaitu, kuriem šī statistika ir datu bāzē. Un jau saņemtos skaitļus varam nosūtīt uz mūsu monitoringu un pēc tiem uzzīmēt grafikus.
Svarīgi ir arī izvērtēt darījuma ilgumu. Jau teicu, ka svarīgi ir izvērtēt vakuumu ilgumu, bet darījumus vērtē tāpat. Ir lauki xact_start un query_start. Tie, nosacīti runājot, parāda darījuma sākuma laiku un pieprasījuma sākuma laiku. Mēs ņemam funkciju now(), kas parāda pašreizējo laikspiedolu, un atņemam darījumu un pieprasām laikspiedolu. Un mēs iegūstam darījuma ilgumu, pieprasījuma ilgumu.

Ja mēs redzam ilgus darījumus, mums tie jau jāpabeidz. OLTP slodzei ilgi darījumi jau ir vairāk nekā 1-2-3 minūtes. OLAP darba slodzei ilgstošas ​​transakcijas ir normāla parādība, taču, ja to pabeigšana prasa vairāk nekā divas stundas, tas arī liecina, ka mums kaut kur ir šķībs.

Kad klienti ir izveidojuši savienojumu ar datu bāzi, viņi sāk strādāt ar mūsu datiem. Viņi piekļūst tabulām, viņi piekļūst indeksiem, lai iegūtu datus no tabulas. Un ir svarīgi novērtēt, kā klienti mijiedarbojas ar šiem datiem.

Tas ir nepieciešams, lai novērtētu mūsu darba slodzi un aptuveni saprastu, kuras tabulas mums ir “karstākās”. Piemēram, tas ir nepieciešams situācijās, kad mēs vēlamies novietot “karstās” tabulas uz kāda veida ātras SSD atmiņas. Piemēram, dažas sen neizmantotas arhīva tabulas var pārvietot uz kaut kādu “auksto” arhīvu, uz SATA diskdziņiem un ļaut viņiem tur dzīvot, tām piekļūs pēc vajadzības.

Tas ir noderīgi arī, lai noteiktu anomālijas pēc izlaidumiem un izvietošanas. Pieņemsim, ka projekts ir izlaidis kādu jaunu funkciju. Piemēram, mēs pievienojām jaunu funkcionalitāti darbam ar datu bāzi. Un, ja mēs uzzīmējam tabulu lietojuma grafikus, mēs varam viegli noteikt šīs anomālijas šajos grafikos. Piemēram, atjauniniet sērijveidu vai dzēsiet sērijas. Tas būs ļoti redzams.

Varat arī atklāt anomālijas “peldošajā” statistikā. Ko tas nozīmē? PostgreSQL ir ļoti spēcīgs un ļoti labs vaicājumu plānotājs. Un izstrādātāji velta daudz laika tā izstrādei. Kā viņš strādā? Lai izveidotu labus plānus, PostgreSQL apkopo statistiku par datu sadalījumu tabulās noteiktā laika intervālā un ar noteiktu biežumu. Šīs ir visizplatītākās vērtības: unikālo vērtību skaits, informācija par NULL tabulā, daudz informācijas.

Pamatojoties uz šo statistiku, plānotājs konstruē vairākus vaicājumus, izvēlas optimālāko un izmanto šo vaicājumu plānu, lai izpildītu pašu vaicājumu un atgrieztu datus.

Un gadās, ka statistika “uzpeld”. Kvalitātes un kvantitātes dati tabulā kaut kā mainījās, bet statistika netika apkopota. Un izveidotie plāni var nebūt optimāli. Un, ja mūsu plāni izrādīsies neoptimāli, pamatojoties uz savākto monitoringu, pamatojoties uz tabulām, mēs varēsim redzēt šīs anomālijas. Piemēram, kaut kur dati mainījās kvalitatīvi un indeksa vietā sāka izmantot secīgu izeju caur tabulu, t.i. ja vaicājumam ir jāatgriež tikai 100 rindas (ir ierobežojums 100), tad šim vaicājumam tiks veikta pilnīga meklēšana. Un tas vienmēr ļoti slikti ietekmē veiktspēju.

Un mēs to varam redzēt monitoringā. Un jau apskatiet šo vaicājumu, palaidiet paskaidrojumu, apkopojiet statistiku, izveidojiet jaunu papildu indeksu. Un jau reaģē uz šo problēmu. Tāpēc tas ir svarīgi.

Vēl viens uzraudzības piemērs. Domāju, ka daudzi viņu atpazina, jo viņš ir ļoti populārs. Kas to izmanto savos projektos Prometejs? Kas lieto šo produktu kopā ar Prometheus? Fakts ir tāds, ka šī uzraudzības standarta repozitorijā ir informācijas panelis darbam ar PostgreSQL - postgres_eksportētājs Prometejs. Bet ir viena slikta detaļa.

Ir vairāki grafiki. Un baiti ir norādīti kā vienotība, t.i., ir 5 grafiki. Tie ir datu ievietošana, datu atjaunināšana, datu dzēšana, datu iegūšana un datu atgriešana. Mērvienība ir baiti. Bet lieta ir tāda, ka PostgreSQL statistika atgriež datus korejā (rindās). Un attiecīgi šie grafiki ir ļoti labs veids, kā vairākas reizes, desmitiem reižu nenovērtēt savu darba slodzi, jo kortežs nav baits, kortežs ir virkne, tas ir daudz baitu un vienmēr ir mainīga garuma. Tas ir, darba slodzes aprēķināšana baitos, izmantojot korešus, ir nereāls vai ļoti grūts uzdevums. Tāpēc, izmantojot informācijas paneli vai iebūvēto uzraudzību, vienmēr ir svarīgi saprast, ka tas darbojas pareizi un atgriež jums pareizi novērtētus datus.

Kā iegūt statistiku par šīm tabulām? Šim nolūkam PostgreSQL ir noteikta uzskatu saime. Un galvenais skats ir pg_stat_user_tables. User_tables - tas nozīmē tabulas, kas izveidotas lietotāja vārdā. Turpretim ir sistēmas skati, kurus izmanto pati PostgreSQL. Un ir kopsavilkuma tabula Alltables, kas ietver gan sistēmas, gan lietotāju. Varat sākt ar jebkuru no tiem, kas jums patīk vislabāk.

Izmantojot iepriekš minētos laukus, varat novērtēt ievietošanas, atjauninājumu un dzēšanas skaitu. Manis izmantotā informācijas paneļa piemērā šie lauki tiek izmantoti, lai novērtētu darba slodzes raksturlielumus. Tāpēc mēs varam arī uz tiem balstīties. Bet ir vērts atcerēties, ka tie ir korteži, nevis baiti, tāpēc mēs nevaram to darīt tikai baitos.

Balstoties uz šiem datiem, mēs varam izveidot tā sauktās TopN tabulas. Piemēram, Top-5, Top-10. Un jūs varat izsekot tiem karstajiem galdiem, kas tiek pārstrādāti vairāk nekā citi. Piemēram, 5 “karstās” tabulas ievietošanai. Izmantojot šīs TopN tabulas, mēs novērtējam savu darba slodzi un varam novērtēt darba slodzes uzliesmojumus pēc izlaidumiem, atjauninājumiem un izvietošanas.

Svarīgi ir arī novērtēt tabulas lielumu, jo dažreiz izstrādātāji ievieš jaunu funkciju, un mūsu tabulas sāk uzbriest lielos izmēros, jo viņi nolēma pievienot papildu datu apjomu, bet neparedzēja, kā tas notiks. ietekmēt datu bāzes lielumu. Šādi gadījumi arī mums ir pārsteigumi.

Un tagad neliels jautājums jums. Kāds jautājums rodas, pamanot datu bāzes servera slodzi? Kāds jums ir nākamais jautājums?

Bet patiesībā jautājums rodas šādi. Kādus pieprasījumus izraisa slodze? Tas ir, nav interesanti skatīties uz procesiem, ko izraisa slodze. Skaidrs, ka ja saimniekam ir datu bāze, tad datubāze tur darbojas un skaidrs, ka tur tiks iznīcinātas tikai datu bāzes. Ja mēs atveram Top, mēs redzēsim PostgreSQL procesu sarakstu, kas kaut ko dara. No Top nebūs skaidrs, ko viņi dara.

Attiecīgi ir jāatrod tie vaicājumi, kas rada vislielāko slodzi, jo skaņošanas vaicājumi, kā likums, dod lielāku peļņu nekā PostgreSQL vai operētājsistēmas konfigurācijas noregulēšana vai pat aparatūras noregulēšana. Pēc manām aplēsēm, tas ir aptuveni 80-85-90%. Un tas tiek darīts daudz ātrāk. Ātrāk ir labot pieprasījumu nekā labot konfigurāciju, ieplānot restartēšanu, it īpaši, ja datu bāzi nevar restartēt, vai pievienot aparatūru. Vienkāršāk ir kaut kur pārrakstīt vaicājumu vai pievienot indeksu, lai iegūtu labāku šī vaicājuma rezultātu.

Attiecīgi ir jāuzrauga pieprasījumi un to atbilstība. Ņemsim vēl vienu uzraudzības piemēru. Un arī šeit, šķiet, ir lieliska uzraudzība. Ir informācija par replikāciju, ir informācija par caurlaidspēju, bloķēšanu, resursu izmantošanu. Viss ir kārtībā, bet nav informācijas par pieprasījumiem. Nav skaidrs, kādi vaicājumi darbojas mūsu datubāzē, cik ilgi tie darbojas, cik no šiem vaicājumiem ir. Mums vienmēr ir jābūt šai informācijai mūsu uzraudzībā.

Un, lai iegūtu šo informāciju, mēs varam izmantot moduli pg_stat_statements. Pamatojoties uz to, jūs varat izveidot dažādus grafikus. Piemēram, jūs varat iegūt informāciju par visbiežāk veiktajiem vaicājumiem, tas ir, par tiem vaicājumiem, kas tiek izpildīti visbiežāk. Jā, pēc izvietošanas ir arī ļoti noderīgi to aplūkot un saprast, vai ir kāds pieprasījumu pieaugums.

Varat pārraudzīt garākos vaicājumus, tas ir, tos vaicājumus, kuru aizpildīšana prasa visilgāk. Tie darbojas ar procesoru, tie patērē I/O. Mēs to varam arī novērtēt, izmantojot laukus total_time, mean_time, blk_write_time un blk_read_time.

Mēs varam novērtēt un uzraudzīt smagākos pieprasījumus resursu izmantošanas ziņā, tos, kas lasa no diska, kas darbojas ar atmiņu vai, gluži pretēji, rada kādu rakstīšanas slodzi.

Varam izvērtēt dāsnākos lūgumus. Šie ir vaicājumi, kas atgriež lielu skaitu rindu. Piemēram, tas varētu būt kāds pieprasījums, kurā viņi ir aizmirsuši iestatīt ierobežojumu. Un tas vienkārši atgriež visu tabulas saturu vai vaicājumu pāri vaicātajām tabulām.

Varat arī pārraudzīt vaicājumus, kuros tiek izmantoti pagaidu faili vai pagaidu tabulas.

Un mums joprojām ir fona procesi. Fona procesi galvenokārt ir kontrolpunkti vai arī tos sauc par kontrolpunktiem, tie ir autovakuums un replikācija.

Vēl viens uzraudzības piemērs. Kreisajā pusē ir cilne Apkope, dodieties uz to un ceriet ieraudzīt kaut ko noderīgu. Bet šeit ir tikai vakuuma darbības un statistikas vākšanas laiks, nekas vairāk. Šī ir ļoti slikta informācija, tāpēc mums vienmēr ir jābūt informācijai par to, kā mūsu datubāzē darbojas fona procesi un vai to darbā nav radušās problēmas.

Aplūkojot kontrolpunktus, mums jāatceras, ka kontrolpunkti izskalo netīrās lapas no šķelto atmiņas apgabala diskā, pēc tam izveido kontrolpunktu. Un šo kontrolpunktu var izmantot kā atkopšanas vietu, ja PostgreSQL pēkšņi tika pārtraukts ārkārtas situācijā.

Attiecīgi, lai visas “netīrās” lapas izskalotu diskā, jums ir jāveic noteikts rakstīšanas apjoms. Un, kā likums, sistēmās ar lielu atmiņas apjomu tas ir daudz. Un, ja mēs ļoti bieži veicam kontrolpunktus īsā intervālā, diska veiktspēja ļoti ievērojami samazināsies. Un klientu pieprasījumi cietīs no resursu trūkuma. Viņi sacentīsies par resursiem un trūks produktivitātes.

Attiecīgi, izmantojot pg_stat_bgwriter, izmantojot norādītos laukus, mēs varam uzraudzīt notiekošo kontrolpunktu skaitu. Un, ja mums ir daudz kontrolpunktu noteiktā laika periodā (10-15-20 minūtēs, pusstundā), piemēram, 3-4-5, tad tā jau var būt problēma. Un jau vajag paskatīties datu bāzē, paskatīties konfigurācijā, kas izraisa tādu kontrolpunktu pārpilnību. Varbūt notiek kāds liels ieraksts. Noslodzi jau varam izvērtēt, jo esam jau pievienojuši slodzes grafikus. Mēs jau varam pielāgot kontrolpunkta parametrus un pārliecināties, ka tie būtiski neietekmē vaicājuma veiktspēju.

Es atkal atgriežos pie autovakuuma, jo, kā jau teicu, tā ir tāda lieta, kas var viegli saskaitīt gan diska, gan vaicājuma veiktspēju, tāpēc vienmēr ir svarīgi novērtēt autovakuuma daudzumu.

Autovakuuma darbinieku skaits datu bāzē ir ierobežots. Pēc noklusējuma tie ir trīs, tāpēc, ja datu bāzē vienmēr strādā trīs darbinieki, tas nozīmē, ka mūsu autovakuums nav konfigurēts, mums ir jāpalielina ierobežojumi, jāpārskata autovakuuma iestatījumi un jāiekļūst konfigurācijā.
Ir svarīgi izvērtēt, kādi vakuuma darbinieki mums ir. Vai nu tas tika palaists no lietotāja, atnāca DBA un manuāli palaida kaut kādu vakuumu, un tas radīja slodzi. Mums ir sava veida problēma. Vai arī tas ir vakuumu skaits, kas atskrūvē darījumu skaitītāju. Dažām PostgreSQL versijām tie ir ļoti smagi vakuumi. Viņi var viegli saskaitīt veiktspēju, jo viņi lasa visu tabulu, skenē visus blokus šajā tabulā.

Un, protams, vakuuma ilgums. Ja mums ir ilgstoši putekļsūcēji, kas darbojas ļoti ilgu laiku, tas nozīmē, ka mums atkal ir jāpievērš uzmanība vakuuma konfigurācijai un, iespējams, jāpārskata tā iestatījumi. Jo var rasties situācija, kad vakuums uz galda strādā ilgstoši (3-4 stundas), bet laikā, kad darbojās vakuums, tabulā atkal izdevās uzkrāties liels daudzums mirušo rindu. Un, tiklīdz vakuums ir pabeigts, viņam atkal ir jāizsūc šis galds. Un mēs nonākam pie situācijas – bezgalīgā vakuumā. Un šajā gadījumā vakuums netiek galā ar savu darbu, un tabulas pamazām sāk uzbriest, lai gan noderīgo datu apjoms tajā paliek nemainīgs. Tāpēc ilgstošos vakuumos vienmēr skatāmies uz konfigurāciju un cenšamies to optimizēt, bet tajā pašā laikā, lai neciestu klientu pieprasījumu izpilde.

Mūsdienās praktiski nav nevienas PostgreSQL instalācijas, kurai nebūtu straumēšanas replikācijas. Replikācija ir datu pārvietošanas process no galvenā uz kopiju.

Replikācija programmā PostgreSQL tiek veikta, izmantojot darījumu žurnālu. Vednis ģenerē darījumu žurnālu. Darījumu žurnāls tiek pārsūtīts pa tīkla savienojumu uz repliku, un pēc tam tas tiek reproducēts replikā. Tas ir vienkārši.

Attiecīgi pg_stat_replication skats tiek izmantots, lai pārraudzītu replikācijas kavēšanos. Bet ar viņu ne viss ir vienkārši. 10. versijā skatā ir veiktas vairākas izmaiņas. Pirmkārt, daži lauki ir pārdēvēti. Un daži lauki ir pievienoti. 10. versijā tika parādīti lauki, kas ļauj novērtēt replikācijas kavēšanos sekundēs. Tas ir ļoti ērti. Pirms 10. versijas bija iespējams novērtēt replikācijas nobīdi baitos. Šī opcija paliek 10. versijā, t.i., jūs varat izvēlēties, kas jums ir ērtāk - novērtēt nobīdi baitos vai novērtēt kavēšanos sekundēs. Daudzi cilvēki dara abus.

Tomēr, lai novērtētu replikācijas kavēšanos, jums jāzina žurnāla atrašanās vieta darījumā. Un šīs darījumu žurnāla pozīcijas ir tieši pg_stat_replication skatā. Relatīvi runājot, mēs varam ņemt divus punktus darījumu žurnālā, izmantojot funkciju pg_xlog_location_diff(). Aprēķiniet delta starp tām un iegūstiet replikācijas nobīdi baitos. Tas ir ļoti ērti un vienkārši.

10. versijā šī funkcija tika pārdēvēta par pg_wal_lsn_diff(). Kopumā visās funkcijās, skatos un utilītprogrammās, kur parādījās vārds “xlog”, tas tika aizstāts ar vērtību “wal”. Tas attiecas gan uz skatiem, gan funkcijām. Tas ir tāds jauninājums.

Turklāt 10. versijā tika pievienotas rindas, kas īpaši parāda kavēšanos. Tie ir rakstīšanas aizkave, skalošanas aizkave, atkārtošanas aizkave. Tas ir, ir svarīgi uzraudzīt šīs lietas. Ja mēs redzam, ka mums ir replikācijas aizkave, mums ir jāizpēta, kāpēc tā parādījās, no kurienes tā radās, un jānovērš problēma.

Ar sistēmas metriku gandrīz viss ir kārtībā. Kad sākas jebkura uzraudzība, tā sākas ar sistēmas metriku. Tas ir procesoru, atmiņas, mijmaiņas, tīkla un diska iznīcināšana. Tomēr daudzi parametri pēc noklusējuma nav pieejami.

Ja ar pārstrādes procesu viss ir kārtībā, tad ir problēmas ar disku pārstrādi. Parasti uzraudzības izstrādātāji pievieno informāciju par caurlaidspēju. Tas var būt iops vai baitos. Bet viņi aizmirst par latentumu un diska ierīču izmantošanu. Šie ir svarīgāki parametri, kas ļauj novērtēt, cik noslogoti ir mūsu diski un cik tie ir lēni. Ja mums ir augsts latentums, tas nozīmē, ka ir dažas problēmas ar diskiem. Ja mums ir augsta noslodze, tas nozīmē, ka diski netiek galā. Tās ir labākas īpašības nekā caurlaidspēja.

Turklāt šo statistiku var iegūt arī no /proc failu sistēmas, kā tas tiek darīts pārstrādes procesoriem. Es nezinu, kāpēc šī informācija netiek pievienota uzraudzībai. Tomēr ir svarīgi, lai tas būtu jūsu uzraudzībā.

Tas pats attiecas uz tīkla saskarnēm. Informācija par tīkla caurlaidspēju ir paketēs, baitos, bet tomēr nav informācijas par latentumu un nav informācijas par izmantošanu, lai gan arī šī ir noderīga informācija.

Jebkurai uzraudzībai ir trūkumi. Un neatkarīgi no tā, kāda veida uzraudzību jūs veicat, tas vienmēr neatbildīs dažiem kritērijiem. Tomēr tie attīstās, tiek pievienotas jaunas funkcijas un jaunas lietas, tāpēc izvēlieties kaut ko un pabeidziet to.

Un, lai pabeigtu, jums vienmēr ir jābūt priekšstatam par to, ko nozīmē sniegtā statistika un kā jūs varat to izmantot problēmu risināšanai.

Un daži galvenie punkti:

• Jums vienmēr jāuzrauga pieejamība un jābūt informācijas paneļiem, lai varētu ātri novērtēt, vai ar datu bāzi viss ir kārtībā.
• Jums vienmēr ir jābūt priekšstatam par to, kādi klienti strādā ar jūsu datu bāzi, lai atsijātu sliktos klientus un tos notriektu.
• Ir svarīgi novērtēt, kā šie klienti strādā ar datiem. Jums ir jābūt priekšstatam par savu darba slodzi.
• Svarīgi izvērtēt, kā šī slodze veidojas, ar kādu vaicājumu palīdzību. Jūs varat novērtēt vaicājumus, varat tos optimizēt, pārveidot, veidot tiem indeksus. Tas ir ļoti svarīgi.
• Fona procesi var negatīvi ietekmēt klientu pieprasījumus, tāpēc ir svarīgi uzraudzīt, lai viņi neizmantotu pārāk daudz resursu.
• Sistēmas metrika ļauj plānot serveru mērogošanas un jaudas palielināšanas plānus, tāpēc ir svarīgi arī tos izsekot un novērtēt.

Ja jūs interesē šī tēma, varat sekot šīm saitēm.
http://bit.do/stats_collector - šī ir oficiālā statistikas apkopotāja dokumentācija. Ir visu statistikas skatījumu apraksts un visu lauku apraksts. Jūs varat tos lasīt, saprast un analizēt. Un, pamatojoties uz tiem, izveidojiet savus grafikus un pievienojiet tos savam monitoringam.

Pieprasījuma piemēri:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Šī ir mūsu un mana korporatīvā repozitorija. Tie satur vaicājumu piemērus. Tur nav vaicājumu no atlasītās* sērijas. Jau ir gatavi vaicājumi ar savienojumiem, izmantojot interesantas funkcijas, kas ļauj neapstrādātus skaitļus pārvērst par lasāmām, ērtām vērtībām, t.i., tie ir baiti, laiks. Varat tos paņemt, apskatīt, analizēt, pievienot savam monitoringam, izveidot uzraudzību, pamatojoties uz tiem.

jautājumi

Jautājums: Jūs teicāt, ka nereklamēsiet zīmolus, bet man joprojām ir interese - kādus informācijas paneļus izmantojat savos projektos?
Atbilde: Tas atšķiras. Gadās, ka nonākam pie klienta un viņam jau ir savs monitorings. Un mēs konsultējam klientu par to, kas jāpievieno viņa uzraudzībai. Sliktākā situācija ir ar Zabbix. Jo tai nav iespēju izveidot TopN grafikus. Mēs paši lietojam Okmeter, jo mēs konsultējāmies ar šiem puišiem par uzraudzību. Viņi uzraudzīja PostgreSQL, pamatojoties uz mūsu tehniskajām specifikācijām. Es rakstu pats savu mājdzīvnieku projektu, kas apkopo datus, izmantojot Prometheus, un atveido tos grafana. Mans uzdevums ir izveidot savu eksportētāju programmā Prometheus un pēc tam visu atveidot Grafānā.

Jautājums: Vai ir kādi analogi AWR ziņojumiem vai... apkopojumam? Vai jūs zināt par kaut ko līdzīgu?
Atbilde: Jā, es zinu, kas ir AWR, tā ir forša lieta. Šobrīd ir pieejami dažādi velosipēdi, kas realizē aptuveni šādu modeli. Ar noteiktu laika intervālu dažas bāzes līnijas tiek ierakstītas tajā pašā PostgreSQL vai atsevišķā krātuvē. Jūs varat tos google meklēt internetā, viņi tur ir. Viens no šādas lietas izstrādātājiem sēž sql.ru forumā PostgreSQL pavedienā. Tur jūs varat viņu noķert. Jā, tādas lietas ir, tās var izmantot. Plus tajā pgCenter Es arī rakstu lietu, kas ļauj jums darīt to pašu.

PS1 Ja izmantojat postgres_exporter, kādu informācijas paneli izmantojat? Tādas ir vairākas. Tie jau ir novecojuši. Varbūt kopiena izveidos atjauninātu veidni?

PS2 ir noņemts pganalyze, jo tas ir patentēts SaaS piedāvājums, kas koncentrējas uz veiktspējas uzraudzību un automatizētiem regulēšanas ieteikumiem.

Aptaujā var piedalīties tikai reģistrēti lietotāji. Ielogoties, lūdzu.

Kuru pašmitinātu postgresql uzraudzību (ar informācijas paneli) uzskatāt par labāko?

• 30,0%Zabbix + papildinājumi no Alekseja Lesovska vai zabbix 4.4 vai libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze ir patentēta SaaS — es to nevaru izdzēst1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

Nobalsoja 10 lietotāji. 26 lietotāji atturējās.

Avots: www.habr.com