Bazoj pri monitorado de PostgreSQL. Aleksej Lesovskij

Mi sugestas vin legi la transskribon de la raporto de Alexey Lesovsky de Data Egret "Fundamentoj de PostgreSQL-monitorado"

En ĉi tiu raporto, Alexey Lesovsky parolos pri la ĉefaj punktoj de post-gresa statistiko, kion ili signifas, kaj kial ili devus ĉeesti en monitorado; pri kiaj grafikaĵoj estu en la monitorado, kiel aldoni ilin kaj kiel interpreti ilin. La raporto estos utila por administrantoj de datumbazoj, sistemadministrantoj kaj programistoj, kiuj interesiĝas pri solvi problemojn de Postgres.

Mi nomiĝas Alexey Lesovsky, mi reprezentas la kompanion Data Egret.

Kelkajn vortojn pri mi mem. Mi komencis antaŭ longe kiel sistema administranto.

Mi administris ĉiajn malsamajn Linuksajn sistemojn, laboris pri diversaj aferoj rilataj al Linukso, t.e. virtualigo, monitorado, laboris kun prokuriloj, ktp. Sed iam mi eklaboris pli kun datumbazoj, PostgreSQL. Mi tre ŝatis lin. Kaj iam mi komencis labori pri PostgreSQL plejparto de mia labortempo. Kaj tiel iom post iom mi fariĝis PostgreSQL DBA.

Kaj dum mia kariero, mi ĉiam interesiĝis pri la temoj de statistiko, monitorado kaj telemetrio. Kaj kiam mi estis sistemadministranto, mi laboris tre proksime kun Zabbix. Kaj mi skribis malgrandan aron da skriptoj kiel zabbix-etendaĵoj. Li estis tre populara siatempe. Kaj tie eblis monitori tre malsamajn gravajn aferojn, ne nur Linukso, sed ankaŭ diversajn komponantojn.

Nun mi laboras pri PostgreSQL. Mi jam skribas alian aferon, kiu permesas vin labori kun PostgreSQL-statistiko. Ĝi nomiĝas pgCenter (artikolo pri Habré - Post-gresaj statistikoj sen nervoj kaj streĉiteco).

Eta enkonduka noto. Kiajn situaciojn havas niaj klientoj, niaj klientoj? Estas ia akcidento rilata al la datumbazo. Kaj kiam la datumbazo jam estis restarigita, la estro de la fako aŭ la estro de disvolviĝo venas kaj diras: "Amikoj, ni devas kontroli la datumbazon, ĉar io malbona okazis kaj ni devas malhelpi tion okazi estonte." Kaj ĉi tie komenciĝas la interesa procezo elekti monitoran sistemon aŭ adapti ekzistantan monitoran sistemon por ke vi povu monitori vian datumbazon - PostgreSQL, MySQL aŭ iuj aliaj. Kaj kolegoj komencas sugesti: “Mi aŭdis, ke ekzistas tia kaj tia datumbazo. Ni uzu ĝin." Kolegoj komencas kvereli unu kun la alia. Kaj finfine rezultas, ke ni elektas ian datumbazon, sed PostgreSQL-monitorado estas prezentita en ĝi sufiĉe malbone kaj ni ĉiam devas aldoni ion. Prenu kelkajn deponejojn de GitHub, klonu ilin, adaptu skriptojn kaj iel personigu ilin. Kaj finfine ĝi finas esti ia mana laboro.

Tial, en ĉi tiu prelego mi provos doni al vi scion pri kiel elekti monitoradon ne nur por PostgreSQL, sed ankaŭ por la datumbazo. Kaj donu al vi la scion, kiu permesos al vi kompletigi vian monitoradon por akiri iom da profito de ĝi, por ke vi povu monitori vian datumbazon kun profito, por senprokraste malhelpi ajnajn venontajn kriz-situaciojn kiuj povas aperi.

Kaj la ideoj kiuj estos en ĉi tiu raporto povas esti rekte adaptitaj al ajna datumbazo, ĉu ĝi estas DBMS aŭ noSQL. Tial, ekzistas ne nur PostgreSQL, sed estos multaj receptoj pri kiel fari tion en PostgreSQL. Estos ekzemploj de demandoj, ekzemploj de estaĵoj kiujn PostgreSQL havas por monitorado. Kaj se via DBMS havas la samajn aferojn, kiuj permesas vin meti ilin en monitoradon, vi ankaŭ povas adapti ilin, aldoni ilin kaj estos bone.

Mi ne estos en la raporto
parolu pri kiel liveri kaj konservi metrikojn. Mi nenion diros pri post-traktado de la datumoj kaj prezento al la uzanto. Kaj mi diros nenion pri atentigo.
Sed dum la rakonto progresas, mi montros malsamajn ekrankopiojn de ekzistanta monitorado kaj iel kritikos ilin. Sed tamen mi provos ne nomi markojn por ne krei reklamadon aŭ kontraŭreklamon por ĉi tiuj produktoj. Tial, ĉiuj koincidoj estas hazardaj kaj estas lasitaj al via imago.

Unue, ni eltrovu, kio estas monitorado. Monitorado estas tre grava afero por havi. Ĉiuj komprenas ĉi tion. Sed samtempe, monitorado ne rilatas al komerca produkto kaj ne rekte influas la profiton de la firmao, do tempo ĉiam estas asignita al monitorado sur resta bazo. Se ni havas tempon, tiam ni faras monitoradon; se ni ne havas tempon, tiam bone, ni enmetos ĝin en la restaron kaj iam ni revenos al ĉi tiuj taskoj.

Tial, de nia praktiko, kiam ni venas al klientoj, monitorado ofte estas nekompleta kaj ne havas iujn ajn interesajn aferojn, kiuj helpus nin fari pli bonan laboron kun la datumbazo. Kaj tial monitorado ĉiam devas esti kompletigita.

Datumbazoj estas tiaj kompleksaj aferoj, kiuj ankaŭ devas esti monitoritaj, ĉar datumbazoj estas deponejo de informoj. Kaj informoj estas tre gravaj por la kompanio; ĝi neniel perdeblas. Sed samtempe, datumbazoj estas tre kompleksaj programoj. Ili konsistas el granda nombro da komponantoj. Kaj multaj el ĉi tiuj komponantoj devas esti monitoritaj.

Se ni parolas specife pri PostgreSQL, tiam ĝi povas esti reprezentita en formo de skemo, kiu konsistas el granda nombro da komponantoj. Ĉi tiuj komponantoj interagas inter si. Kaj samtempe PostgreSQL havas la tiel nomatan Stats Collector-subsistemon, kiu permesas vin kolekti statistikojn pri la funkciado de ĉi tiuj subsistemoj kaj provizi ian interfacon al la administranto aŭ uzanto por ke li povu vidi ĉi tiujn statistikojn.

Ĉi tiuj statistikoj estas prezentitaj en la formo de certa aro de funkcioj kaj vidoj. Ili ankaŭ povas esti nomitaj tabloj. Tio estas, uzante regulan psql-klienton, vi povas konektiĝi al la datumbazo, elekti ĉi tiujn funkciojn kaj vidojn, kaj akiri iujn specifajn nombrojn pri la funkciado de la subsistemoj PostgreSQL.

Vi povas aldoni ĉi tiujn nombrojn al via plej ŝatata monitora sistemo, desegni grafikaĵojn, aldoni funkciojn kaj akiri analizojn longtempe.

Sed en ĉi tiu raporto mi ne kovros ĉiujn ĉi funkciojn tute, ĉar ĝi povus daŭri la tutan tagon. Mi laŭvorte traktos du, tri aŭ kvar aferojn kaj diros al vi kiel ili helpas plibonigi monitoradon.

Kaj se ni parolas pri datumbaza monitorado, do kio necesas kontroli? Antaŭ ĉio, ni devas monitori haveblecon, ĉar la datumbazo estas servo kiu provizas aliron al datumoj al klientoj kaj ni devas kontroli haveblecon, kaj ankaŭ provizi kelkajn el ĝiaj kvalitaj kaj kvantaj trajtoj.

Ni ankaŭ devas kontroli klientojn, kiuj konektas al nia datumbazo, ĉar ili povas esti kaj normalaj klientoj kaj malutilaj klientoj, kiuj povas damaĝi la datumbazon. Ili ankaŭ devas esti monitoritaj kaj iliaj agadoj spuritaj.

Kiam klientoj konektas al la datumbazo, estas evidente, ke ili komencas labori kun niaj datumoj, do ni devas kontroli kiel klientoj laboras kun la datumoj: kun kiuj tabloj, kaj malpligrade, kun kiuj indeksoj. Tio estas, ni devas taksi la laborkvanton kreitan de niaj klientoj.

Sed laborŝarĝo ankaŭ konsistas, kompreneble, el petoj. Aplikoj konektas al la datumbazo, aliras datumojn per demandoj, do gravas taksi kiajn demandojn ni havas en la datumbazo, kontroli ilian taŭgecon, ke ili ne estas malrekte skribitaj, ke iuj opcioj devas esti reverkitaj kaj faritaj por ke ili funkciu pli rapide. kaj kun pli bona rendimento.

Kaj ĉar ni parolas pri datumbazo, la datumbazo ĉiam estas fonaj procezoj. Fonaj procezoj helpas konservi datumbazan efikecon sur bona nivelo, do ili postulas certan kvanton da rimedoj por si mem funkcii. Kaj samtempe, ili povas interkovri kun klientpetaj rimedoj, do avidaj fonprocezoj povas rekte influi la agadon de klientpetoj. Sekve, ili ankaŭ devas esti monitoritaj kaj spuritaj por ke ne estu distordoj laŭ fonaj procezoj.

Kaj ĉio ĉi laŭ datumbaza monitorado restas en la sistema metriko. Sed konsiderante, ke la plej granda parto de nia infrastrukturo moviĝas al la nuboj, la sistemaj metrikoj de individua gastiganto ĉiam fadas en la fono. Sed en datumbazoj ili ankoraŭ estas gravaj kaj, kompreneble, ankaŭ necesas kontroli sistemajn metrikojn.

Ĉio estas pli-malpli bone kun sistemaj metrikoj, ĉiuj modernaj monitoraj sistemoj jam subtenas ĉi tiujn metrikojn, sed ĝenerale iuj komponantoj ankoraŭ ne sufiĉas kaj kelkaj aferoj devas esti aldonitaj. Mi ankaŭ tuŝos ilin, estos pluraj lumbildoj pri ili.

La unua punkto de la plano estas alirebleco. Kio estas alirebleco? Havebleco laŭ mia kompreno estas la kapablo de la bazo por servi ligojn, t.e. la bazo estas levita, ĝi, kiel servo, akceptas ligojn de klientoj. Kaj ĉi tiu alirebleco povas esti taksata per iuj trajtoj. Estas tre oportune montri ĉi tiujn trajtojn sur paneloj.

Ĉiuj scias kio paneloj estas. Jen kiam vi ekrigardis la ekranon, sur kiu la necesaj informoj estas resumitaj. Kaj vi povas tuj determini ĉu estas problemo en la datumbazo aŭ ne.
Sekve, la havebleco de la datumbazo kaj aliaj ŝlosilaj trajtoj ĉiam devas esti montritaj sur paneloj, por ke ĉi tiuj informoj estu ĉe vi kaj ĉiam disponeblaj por vi. Iuj aldonaj detaloj, kiuj jam helpas en la enketo de incidentoj, kiam oni esploras iujn kriz-situaciojn, ili jam devas esti metitaj sur malĉefajn panelojn, aŭ kaŝitaj en drilldown-ligiloj, kiuj kondukas al triaj monitoraj sistemoj.

Ekzemplo de unu bonkonata monitora sistemo. Ĉi tio estas tre bonega monitora sistemo. Ŝi kolektas multajn datumojn, sed el mia vidpunkto, ŝi havas strangan koncepton de paneloj. Estas ligo por "krei panelon". Sed kiam vi kreas panelon, vi kreas liston de du kolumnoj, liston de grafikaĵoj. Kaj kiam vi bezonas rigardi ion, vi komencas klaki per la muso, rulumi, serĉi la deziratan diagramon. Kaj ĉi tio bezonas tempon, t.e. ne ekzistas paneloj kiel tia. Estas nur listoj de leteroj.

Kion vi aldonu al ĉi tiuj paneloj? Vi povas komenci per tia karakterizaĵo kiel respondtempo. PostgreSQL havas la vidon pg_stat_statements. Ĝi estas malebligita defaŭlte, sed ĝi estas unu el la gravaj sistemaj vidoj, kiuj ĉiam devus esti ebligitaj kaj uzataj. Ĝi stokas informojn pri ĉiuj kurantaj demandoj, kiuj estis efektivigitaj en la datumbazo.

Sekve, ni povas komenci de tio, ke ni povas preni la tutan ekzekuttempon de ĉiuj petoj kaj dividi ĝin per la nombro da petoj uzante la suprajn kampojn. Sed ĉi tio estas la averaĝa temperaturo en la hospitalo. Ni povas komenci de aliaj kampoj - minimuma demanda ekzekuttempo, maksimuma kaj meza. Kaj ni eĉ povas konstrui procentojn; PostgreSQL havas respondajn funkciojn por tio. Kaj ni povas ricevi kelkajn nombrojn, kiuj karakterizas la respondtempon de nia datumbazo por jam plenumitaj petoj, t.e. ni ne plenumas la falsan peton 'elektu 1' kaj rigardas la respondtempon, sed ni analizas la respondtempon por jam finitaj petoj kaj desegnas. aŭ apartan figuron, aŭ ni konstruas grafeon bazitan sur ĝi.

Ankaŭ gravas kontroli la nombron da eraroj, kiuj estas nuntempe generitaj de la sistemo. Kaj por tio vi povas uzi la pg_stat_database-vidon. Ni koncentriĝas pri la kampo xact_rollback. Ĉi tiu kampo montras ne nur la nombron da retrovojoj kiuj okazas en la datumbazo, sed ankaŭ konsideras la nombron da eraroj. Relative parolante, ni povas montri ĉi tiun ciferon en nia panelo kaj vidi kiom da eraroj ni nuntempe havas. Se estas multaj eraroj, tiam ĉi tio estas bona kialo por rigardi la protokolojn kaj vidi kiajn erarojn ili estas kaj kial ili okazas, kaj poste investi kaj solvi ilin.

Vi povas aldoni ion kiel Taĥometron. Ĉi tiuj estas la nombro da transakcioj por sekundo kaj la nombro da petoj por sekundo. Relative parolante, vi povas uzi ĉi tiujn nombrojn kiel la aktualan rendimenton de via datumbazo kaj observi ĉu estas pintoj en petoj, pintoj en transakcioj, aŭ, male, ĉu la datumbazo estas subŝarĝita ĉar iu backend malsukcesis. Gravas ĉiam rigardi ĉi tiun figuron kaj memori, ke por nia projekto ĉi tiu speco de agado estas normala, sed la valoroj supre kaj malsupre jam estas ia problemaj kaj nekompreneblaj, kio signifas, ke ni devas rigardi kial ĉi tiuj nombroj estas. tiel alta.

Por taksi la nombron da transakcioj, ni povas denove raporti al la pg_stat_database-vido. Ni povas aldoni la nombron da transakcioj kaj la nombron da retrovoj kaj akiri la nombron da transakcioj por sekundo.

Ĉu ĉiuj komprenas, ke pluraj petoj povas konveni en unu transakcio? Tial TPS kaj QPS estas iomete malsamaj.

La nombro da petoj por sekundo povas esti akirita de pg_stat_statements kaj simple kalkuli la sumon de ĉiuj kompletigitaj petoj. Estas klare, ke ni komparas la nunan valoron kun la antaŭa, subtrahas ĝin, ricevas la delton kaj ricevas la kvanton.

Vi povas aldoni pliajn metrikojn se vi deziras, kiuj ankaŭ helpas taksi la haveblecon de nia datumbazo kaj kontroli ĉu okazis malfunkcioj.

Unu el ĉi tiuj metrikoj estas funkciada tempo. Sed la funkciado en PostgreSQL estas iom malfacila. Mi diros al vi kial. Kiam PostgreSQL komenciĝis, la funkciado komencas raporti. Sed se en iu momento, ekzemple, iu tasko funkciis nokte, venis OOM-murdinto kaj perforte ĉesigis la postgreSQL-infan procezon, tiam en ĉi tiu kazo PostgreSQL ĉesigas la konekton de ĉiuj klientoj, restarigas la fragmentan memorareon kaj komencas reakiron de la lasta kontrolpunkto. Kaj dum ĉi tiu reakiro de la kontrolpunkto daŭras, la datumbazo ne akceptas konektojn, t.e. ĉi tiu situacio povas esti taksita kiel malfunkcio. Sed la labortempokalkulilo ne estos rekomencigita, ĉar ĝi enkalkulas la poŝtestron de lanĉa tempo ekde la unua momento. Tial tiaj situacioj povas esti preterlasitaj.

Vi ankaŭ devus kontroli la nombron da vakuaj laboristoj. Ĉu ĉiuj scias, kio estas aŭtomata vakuo en PostgreSQL? Ĉi tio estas interesa subsistemo en PostgreSQL. Pri ŝi estis skribitaj multaj artikoloj, multaj raportoj estis faritaj. Estas multaj diskutoj pri vakuo kaj kiel ĝi devus funkcii. Multaj konsideras ĝin necesa malbono. Sed tiel estas. Ĉi tio estas speco de analogo de rubkolektilo, kiu purigas malmodernajn versiojn de vicoj, kiuj ne estas bezonataj de iu ajn transakcio, kaj liberigas spacon en tabeloj kaj indeksoj por novaj vicoj.

Kial vi bezonas kontroli ĝin? Ĉar la vakuo foje multe doloras. Ĝi konsumas grandan kvanton da rimedoj kaj klientpetoj komencas suferi kiel rezulto.

Kaj ĝi devus esti monitorita per la pg_stat_activity-vido, pri kiu mi parolos en la sekva sekcio. Ĉi tiu vido montras la nunan agadon en la datumbazo. Kaj per ĉi tiu agado ni povas spuri la nombron da vakuoj kiuj funkcias ĝuste nun. Ni povas spuri vakuojn kaj vidi, ke se ni superis la limon, tiam ĉi tio estas kialo por rigardi la agordojn de PostgreSQL kaj iel optimumigi la funkciadon de la vakuo.

Alia afero pri PostgreSQL estas, ke PostgreSQL estas tre malsana de longaj transakcioj. Precipe de transakcioj, kiuj longdaŭras kaj faras nenion. Ĉi tio estas la tiel nomata stat idle-in-transaction. Tia transakcio tenas serurojn kaj malhelpas la vakuon funkcii. Kaj kiel rezulto, la tabloj ŝveliĝas kaj pligrandiĝas. Kaj demandoj, kiuj funkcias kun ĉi tiuj tabeloj, komencas funkcii pli malrapide, ĉar vi devas ŝoveli ĉiujn malnovajn versiojn de vicoj de memoro al disko kaj reen. Tial, la tempo, la daŭro de la plej longaj transakcioj, la plej longaj vakuaj petoj ankaŭ devas esti monitoritaj. Kaj se ni vidas iujn procezojn, kiuj funkcias de tre longa tempo, jam pli ol 10-20-30 minutojn por OLTP-ŝarĝo, tiam ni devas atenti ilin kaj perforte ĉesigi ilin aŭ optimumigi la aplikaĵon por ke ili ne estas vokataj kaj ne pendas tiom longe. Por analiza laborkvanto, 10-20-30 minutoj estas normalaj; estas ankaŭ pli longaj.

Poste ni havas la eblon kun konektitaj klientoj. Kiam ni jam kreis panelon kaj afiŝis ŝlosilajn disponeblajn metrikojn sur ĝi, ni ankaŭ povas aldoni pliajn informojn pri konektitaj klientoj tie.

Informoj pri konektitaj klientoj estas gravaj ĉar, de PostgreSQL-perspektivo, klientoj estas malsamaj. Estas bonaj klientoj kaj estas malbonaj klientoj.

Simpla ekzemplo. Per kliento mi komprenas la aplikaĵon. La aplikaĵo konektiĝis al la datumbazo kaj tuj komencas sendi siajn petojn tie, la datumbazo prilaboras kaj plenumas ilin, kaj resendas la rezultojn al la kliento. Ĉi tiuj estas bonaj kaj ĝustaj klientoj.

Estas situacioj kiam la kliento konektis, ĝi tenas la konekton, sed faras nenion. Ĝi estas en neaktiva stato.

Sed estas malbonaj klientoj. Ekzemple, la sama kliento konektis, malfermis transakcion, faris ion en la datumbazo kaj poste eniris la kodon, ekzemple, por aliri eksteran fonton aŭ por prilabori la ricevitajn datumojn tie. Sed li ne fermis la transakcion. Kaj la transakcio pendas en la datumbazo kaj estas tenita en seruro sur la linio. Ĉi tio estas malbona kondiĉo. Kaj se subite aplikaĵo ie en si malsukcesas kun escepto, tiam la transakcio povas resti malfermita dum tre longa tempo. Kaj ĉi tio rekte influas la agadon de PostgreSQL. PostgreSQL estos pli malrapida. Tial gravas spuri tiajn klientojn ĝustatempe kaj perforte ĉesigi ilian laboron. Kaj vi devas optimumigi vian aplikaĵon por ke tiaj situacioj ne okazu.

Aliaj malbonaj klientoj atendas klientojn. Sed ili fariĝas malbonaj pro cirkonstancoj. Ekzemple, simpla neaktiva transakcio: ĝi povas malfermi transakcion, preni serurojn sur iuj linioj, tiam ie en la kodo ĝi malsukcesos, lasante pendantan transakcion. Alia kliento venos kaj petos la samajn datumojn, sed li renkontos seruron, ĉar tiu pendanta transakcio jam tenas serurojn sur iuj postulataj vicoj. Kaj la dua transakcio restos atendante ke la unua transakcio kompletigos aŭ perforte fermos ĝin de la administranto. Sekve, pritraktataj transakcioj povas akumuli kaj plenigi la datumbazan konektolimon. Kaj kiam la limo estas plena, la aplikaĵo ne plu povas funkcii kun la datumbazo. Ĉi tio jam estas kriza situacio por la projekto. Tial malbonaj klientoj devas esti spuritaj kaj responditaj al ĝustatempe.

Alia ekzemplo de monitorado. Kaj jam estas deca instrumentpanelo ĉi tie. Estas informoj pri konektoj supre. DB-konekto - 8 pecoj. Kaj estas ĉio. Ni havas neniujn informojn pri kiuj klientoj estas aktivaj, kiuj klientoj estas simple neaktivaj, farante nenion. Ne ekzistas informoj pri pritraktataj transakcioj kaj pritraktataj konektoj, t.e. ĉi tio estas figuro, kiu montras la nombron da konektoj kaj jen ĝi. Kaj poste divenu mem.

Sekve, por aldoni ĉi tiujn informojn al monitorado, vi devas aliri la pg_stat_activity-sisteman vidon. Se vi pasigas multe da tempo en PostgreSQL, tiam ĉi tio estas tre bona vido, kiu devus fariĝi via amiko, ĉar ĝi montras la nunan agadon en PostgreSQL, t.e. kio okazas en ĝi. Por ĉiu procezo estas aparta linio, kiu montras informojn pri ĉi tiu procezo: de kiu gastiganto estis farita la konekto, sub kia uzanto, sub kia nomo, kiam la transakcio estis komencita, kia peto funkcias, kia peto estis laste efektivigita. Kaj, sekve, ni povas taksi la staton de la kliento uzante la statkampon. Relative parolante, ni povas grupiĝi laŭ ĉi tiu kampo kaj akiri tiujn statistikojn kiuj estas nuntempe en la datumbazo kaj la nombron da konektoj kiuj havas ĉi tiun statistikon en la datumbazo. Kaj ni povas sendi la jam ricevitajn nombrojn al nia monitorado kaj desegni grafikaĵojn bazitajn sur ili.
Ankaŭ gravas taksi la daŭron de la transakcio. Mi jam diris, ke gravas taksi la daŭron de vakuoj, sed transakcioj estas taksitaj same. Estas xact_start kaj query_start kampoj. Ili, relative parolante, montras la komencan tempon de la transakcio kaj la komencan tempon de la peto. Ni prenas la now()-funkcion, kiu montras la nunan tempomarkon, kaj subtrahas la transakcion kaj petan tempomarkon. Kaj ni ricevas la daŭron de la transakcio, la daŭron de la peto.

Se ni vidas longajn transakciojn, ni devas jam plenumi ilin. Por OLTP-ŝarĝo, longaj transakcioj jam estas pli ol 1-2-3 minutoj. Por laborkvanto de OLAP, longaj transakcioj estas normalaj, sed se ili daŭras pli ol du horojn por kompletigi, tiam ĉi tio ankaŭ estas signo, ke ni havas malsukceson ie.

Post kiam klientoj konektiĝis al la datumbazo, ili komencas labori kun niaj datumoj. Ili aliras tabelojn, ili aliras indeksojn por ricevi datumojn de la tabelo. Kaj gravas taksi kiel klientoj interagas kun ĉi tiuj datumoj.

Ĉi tio estas necesa por taksi nian laborŝarĝon kaj proksimume kompreni, kiuj tabloj estas la "plej varmaj" por ni. Ekzemple, ĉi tio necesas en situacioj, kie ni volas meti "varmajn" tablojn sur ia rapida SSD-stokado. Ekzemple, iuj arkivaj tabloj, kiujn ni delonge ne uzis, povas esti movitaj al ia "malvarma" arkivo, al SATA-diskoj kaj lasu ilin vivi tie, ili estos alireblaj laŭbezone.

Ĉi tio ankaŭ estas utila por detekti anomaliojn post iuj eldonoj kaj deplojoj. Ni diru, ke la projekto publikigis iun novan funkcion. Ekzemple, ni aldonis novan funkciojn por labori kun la datumbazo. Kaj se ni reprezentas tabelajn uzajn grafeojn, ni povas facile detekti ĉi tiujn anomaliojn sur ĉi tiuj grafikaĵoj. Ekzemple, ĝisdatigi eksplodojn aŭ forigu eksplodojn. Ĝi estos tre videbla.

Vi ankaŭ povas detekti anomaliojn en "ŝveba" statistiko. Kion ĝi signifas? PostgreSQL havas tre fortan kaj tre bonan serĉplanilon. Kaj la programistoj dediĉas multan tempon al ĝia disvolviĝo. Kiel li laboras? Por fari bonajn planojn, PostgreSQL kolektas statistikojn pri la distribuado de datumoj en tabeloj je certa tempointervalo kaj kun certa frekvenco. Ĉi tiuj estas la plej oftaj valoroj: la nombro da unikaj valoroj, informoj pri NULL en la tabelo, multe da informoj.

Surbaze de ĉi tiuj statistikoj, la planisto konstruas plurajn demandojn, elektas la plej optimuman kaj uzas ĉi tiun demandplanon por efektivigi la demandon mem kaj resendi datumojn.

Kaj okazas, ke la statistikoj "flosas". La kvalitaj kaj kvantaj datumoj iel ŝanĝiĝis en la tabelo, sed la statistikoj ne estis kolektitaj. Kaj la planoj formitaj eble ne estas optimumaj. Kaj se niaj planoj montros suboptimumaj surbaze de la monitorado kolektita, surbaze de la tabeloj, ni povos vidi ĉi tiujn anomaliojn. Ekzemple, ie la datumoj ŝanĝiĝis kvalite kaj anstataŭ la indekso, oni komencis uzi sinsekvan trapason tra la tabelo, t.e. se demando devas resendi nur 100 vicojn (estas limo de 100), tiam kompleta serĉo estos farita por ĉi tiu demando. Kaj ĉi tio ĉiam havas tre malbonan efikon al agado.

Kaj ni povas vidi ĉi tion en monitorado. Kaj jam rigardu ĉi tiun demandon, rulu klarigon por ĝi, kolektu statistikojn, konstruu novan aldonan indekson. Kaj jam respondu al ĉi tiu problemo. Tial ĝi estas grava.

Alia ekzemplo de monitorado. Mi pensas, ke multaj homoj rekonis lin ĉar li estas tre populara. Kiu uzas ĝin en siaj projektoj Prometeo? Kiu uzas ĉi tiun produkton kune kun Prometheus? Fakte, en la norma deponejo de ĉi tiu monitorado estas panelo por labori kun PostgreSQL - postgres_exporter Prometeo. Sed estas unu malbona detalo.

Estas pluraj grafikaĵoj. Kaj bajtoj estas indikitaj kiel unueco, t.e. estas 5 grafeoj. Ĉi tiuj estas Enmetu datumojn, Ĝisdatigu datumojn, Forigi datumojn, Prenu datumojn kaj Redoni datumojn. La unuomezuro estas bajtoj. Sed la afero estas, ke statistiko en PostgreSQL resendas datumojn en opo (vicoj). Kaj, sekve, ĉi tiuj grafikaĵoj estas tre bona maniero por subtaksi vian laborŝarĝon plurajn fojojn, dekojn da fojoj, ĉar opo ne estas bajto, opo estas ĉeno, ĝi estas multaj bajtoj kaj ĝi estas ĉiam de varia longo. Tio estas, kalkuli laborkvanton en bajtoj uzante opoj estas nereala tasko aŭ tre malfacila. Tial, kiam vi uzas panelon aŭ enkonstruitan monitoradon, ĉiam gravas kompreni, ke ĝi funkcias ĝuste kaj redonas al vi ĝuste taksitajn datumojn.

Kiel akiri statistikojn pri ĉi tiuj tabeloj? Por ĉi tiu celo, PostgreSQL havas certan familion de vidoj. Kaj la ĉefa vido estas pg_stat_user_tables. User_tables - tio signifas tabelojn kreitajn nome de la uzanto. Kontraste, ekzistas sistemaj vidoj, kiuj estas uzataj de PostgreSQL mem. Kaj estas resuma tabelo Alltables, kiu inkluzivas ambaŭ sistemojn kaj uzantojn. Vi povas komenci de iu ajn el ili, kiun vi plej ŝatas.

Per la supraj kampoj vi povas taksi la nombron da enmetoj, ĝisdatigoj kaj forigoj. La ekzemplo de panelo, kiun mi uzis, uzas ĉi tiujn kampojn por taksi la karakterizaĵojn de laborŝarĝo. Tial ni ankaŭ povas konstrui sur ili. Sed indas memori, ke ĉi tiuj estas opoj, ne bajtoj, do ni ne povas fari ĝin nur en bajtoj.

Surbaze de ĉi tiuj datumoj, ni povas konstrui tiel nomatajn TopN-tablojn. Ekzemple, Top-5, Top-10. Kaj vi povas spuri tiujn varmajn tablojn, kiuj estas reciklitaj pli ol aliaj. Ekzemple, 5 "varmaj" tabloj por enmeto. Kaj uzante ĉi tiujn TopN-tabelojn ni taksas nian laborŝarĝon kaj povas taksi eksplodojn de laborŝarĝo post iuj eldonoj, ĝisdatigoj kaj deplojoj.

Ankaŭ gravas taksi la grandecon de la tabelo, ĉar foje programistoj disvolvas novan funkcion, kaj niaj tabeloj komencas ŝveli en siaj grandaj grandecoj, ĉar ili decidis aldoni plian kvanton da datumoj, sed ne antaŭdiris kiel ĉi tio estus. influas la grandecon de la datumbazo. Tiaj kazoj ankaŭ surprizas nin.

Kaj nun malgranda demando por vi. Kio demando aperas kiam vi rimarkas la ŝarĝon sur via datumbaza servilo? Kio estas la sekva demando, kiun vi havas?

Sed fakte la demando stariĝas jene. Kiajn petojn kaŭzas la ŝarĝo? Tio estas, ne estas interese rigardi la procezojn, kiuj estas kaŭzitaj de la ŝarĝo. Estas klare, ke se la gastiganto havas datumbazon, tiam la datumbazo funkcias tie kaj estas klare, ke nur la datumbazoj estos forigitaj tie. Se ni malfermas Top, ni vidos tie liston de procezoj en PostgreSQL, kiuj faras ion. Ne estos klare de Top kion ili faras.

Sekve, vi devas trovi tiujn demandojn, kiuj kaŭzas la plej altan ŝarĝon, ĉar agordi demandojn, kiel regulo, donas pli da profito ol agordi la PostgreSQL aŭ agordon de operaciumo, aŭ eĉ agordi la aparataron. Laŭ mia takso, ĉi tio estas proksimume 80-85-90%. Kaj ĉi tio estas farita multe pli rapide. Estas pli rapide korekti peton ol korekti la agordon, plani rekomencon, precipe se la datumbazo ne povas esti rekomencita, aŭ aldoni aparataron. Estas pli facile reverki la demandon ie aŭ aldoni indekson por akiri pli bonan rezulton de ĉi tiu demando.

Sekve, necesas kontroli petojn kaj ilian taŭgecon. Ni prenu alian ekzemplon de monitorado. Kaj ĉi tie ankaŭ ŝajnas esti bonega monitorado. Estas informoj pri reproduktado, estas informoj pri trafluo, blokado, utiligo de rimedoj. Ĉio estas bona, sed ne estas informoj pri petoj. Ne estas klare, kiaj demandoj funkcias en nia datumbazo, kiom longe ili funkcias, kiom da ĉi tiuj demandoj estas. Ni ĉiam bezonas havi ĉi tiun informon en nia monitorado.

Kaj por akiri ĉi tiun informon ni povas uzi la modulon pg_stat_statements. Surbaze de ĝi, vi povas konstrui diversajn grafikaĵojn. Ekzemple, vi povas akiri informojn pri la plej oftaj demandoj, tio estas, pri tiuj demandoj, kiuj plej ofte estas ekzekutitaj. Jes, post deplojoj ankaŭ estas tre utile rigardi ĝin kaj kompreni ĉu estas iu pliiĝo en petoj.

Vi povas kontroli la plej longajn demandojn, tio estas, tiujn demandojn, kiuj daŭras la plej longajn por plenumi. Ili funkcias per la procesoro, ili konsumas I/O. Ni ankaŭ povas taksi ĉi tion uzante la kampojn total_time, mean_time, blk_write_time kaj blk_read_time.

Ni povas taksi kaj kontroli la plej pezajn petojn laŭ rimedo-uzo, tiuj, kiuj legas el disko, kiuj funkcias kun memoro, aŭ, male, kreas ian skribŝarĝon.

Ni povas taksi la plej malavarajn petojn. Ĉi tiuj estas la demandoj, kiuj resendas grandan nombron da vicoj. Ekzemple, ĉi tio povus esti iu peto, kie ili forgesis fiksi limon. Kaj ĝi simple resendas la tutan enhavon de la tabelo aŭ demandon tra la demanditaj tabeloj.

Kaj vi ankaŭ povas kontroli demandojn, kiuj uzas provizorajn dosierojn aŭ provizorajn tabelojn.

Kaj ni ankoraŭ havas fonajn procezojn. Fonaj procezoj estas ĉefe transirejoj aŭ ili ankaŭ estas nomitaj transirejoj, tiuj estas aŭtovakuo kaj reproduktado.

Alia ekzemplo de monitorado. Estas langeto Prizorgado maldekstre, iru al ĝi kaj esperas vidi ion utilan. Sed jen nur la tempo de vakua operacio kaj statistika kolekto, nenio pli. Ĉi tio estas tre malbona informo, do ni ĉiam bezonas havi informojn pri kiel fonaj procezoj funkcias en nia datumbazo kaj ĉu ekzistas problemoj de ilia laboro.

Kiam ni rigardas kontrolpunktojn, ni devas memori, ke kontrolpunktoj fluigas malpurajn paĝojn de la fragmenta memorareo al disko, poste kreas kontrolpunkton. Kaj ĉi tiu kontrolpunkto tiam povas esti uzata kiel loko por reakiro se PostgreSQL estis subite ĉesigita en kriz-okazo.

Sekve, por flui ĉiujn "malpurajn" paĝojn al disko, vi devas fari certan kvanton da skribado. Kaj, kiel regulo, sur sistemoj kun grandaj kvantoj da memoro, ĉi tio estas multe. Kaj se ni faras kontrolpunktojn tre ofte en mallonga intervalo, tiam la rendimento de disko tre grave malpliiĝos. Kaj klientpetoj suferos pro manko de rimedoj. Ili konkuros pri rimedoj kaj mankos produktiveco.

Sekve, per pg_stat_bgwriter uzante la specifitajn kampojn ni povas kontroli la nombron da kontrolpunktoj kiuj okazas. Kaj se ni havas multajn kontrolpunktojn dum certa tempodaŭro (en 10-15-20 minutoj, en duonhoro), ekzemple, 3-4-5, tiam ĉi tio jam povas esti problemo. Kaj vi jam bezonas rigardi en la datumbazo, rigardi en la agordo, kio kaŭzas tian abundon da kontrolpunktoj. Eble okazas ia granda registrado. Ni jam povas taksi la laborŝarĝon, ĉar ni jam aldonis laborŝarĝajn grafikojn. Ni jam povas ĝustigi la kontrolpunktojn parametrojn kaj certigi, ke ili ne multe influas demandan rendimenton.

Mi revenas al aŭtomata vakuo denove ĉar ĝi estas tia afero, kiel mi diris, kiu povas facile aldoni kaj diskon kaj demandan rendimenton, do ĉiam gravas taksi la kvanton de aŭtomalplena.

La nombro da aŭtovakuaj laboristoj en la datumbazo estas limigita. Defaŭlte, estas tri el ili, do se ni ĉiam havas tri laboristojn laborantajn en la datumbazo, tio signifas, ke nia aŭtomata vakuo ne estas agordita, ni devas levi la limojn, revizii la aŭtomatajn agordojn kaj eniri la agordon.
Gravas taksi kiujn vakuajn laboristojn ni havas. Aŭ ĝi estis lanĉita de la uzanto, la DBA venis kaj mane lanĉis ian vakuon, kaj ĉi tio kreis ŝarĝon. Ni havas ian problemon. Aŭ ĉi tio estas la nombro da vakuoj, kiuj malŝraŭbas la transakcian nombrilon. Por iuj versioj de PostgreSQL ĉi tiuj estas tre pezaj vakuoj. Kaj ili povas facile aldoni la agadon ĉar ili legas la tutan tabelon, skanas ĉiujn blokojn en tiu tabelo.

Kaj, kompreneble, la daŭro de vakuoj. Se ni havas longdaŭrajn vakuojn, kiuj funkcias dum tre longa tempo, tiam ĉi tio signifas, ke ni denove devas atenti la vakuan agordon kaj eble rekonsideri ĝiajn agordojn. Ĉar situacio povas aperi, kiam la vakuo funkcias sur la tablo dum longa tempo (3-4 horoj), sed dum la tempo, kiam la vakuo funkciis, granda kvanto da mortaj vicoj sukcesis denove amasiĝi en la tablo. Kaj tuj kiam la vakuo estas finita, li devas denove vakui ĉi tiun tablon. Kaj ni venas al situacio - senfina vakuo. Kaj en ĉi tiu kazo, la vakuo ne traktas sian laboron, kaj la tabloj iom post iom komencas ŝveli en grandeco, kvankam la volumo de utilaj datumoj en ĝi restas la sama. Tial, dum longaj vakuoj, ni ĉiam rigardas la agordon kaj provas optimumigi ĝin, sed samtempe por ke la agado de klientpetoj ne suferu.

Nuntempe ekzistas preskaŭ neniu instalado de PostgreSQL, kiu ne havas reproduktadon de streaming. Reproduktado estas la procezo movi datumojn de majstro al kopio.

Replikado en PostgreSQL estas farita per transakcia protokolo. La sorĉisto generas transakcian protokolon. La transakcia protokolo vojaĝas tra la reto-konekto al la kopio, kaj tiam ĝi estas reproduktita sur la kopio. Ĝi estas simpla.

Sekve, la pg_stat_replication-vido estas uzata por monitori la reproduktan malfruon. Sed ne ĉio estas simpla ĉe ŝi. En versio 10, la vido suferis plurajn ŝanĝojn. Unue, kelkaj kampoj estis renomitaj. Kaj kelkaj kampoj estis aldonitaj. En versio 10 aperis kampoj, kiuj ebligas al vi taksi la reproduktan malfruon en sekundoj. Ĝi estas tre komforta. Antaŭ versio 10, estis eble taksi la reproduktadmalfruon en bajtoj. Ĉi tiu opcio restas en la versio 10, t.e. vi povas elekti kio estas pli oportuna por vi - taksu la malfruon en bajtoj aŭ taksu la malfruon en sekundoj. Multaj homoj faras ambaŭ.

Sed tamen, por taksi la reproduktan malfruon, vi devas scii la pozicion de la ŝtipo en la transakcio. Kaj ĉi tiuj transakciaj protokolaj pozicioj estas ĝuste en la pg_stat_replication-vido. Relative parolante, ni povas preni du punktojn en la transakcia protokolo uzante la funkcion pg_xlog_location_diff(). Kalkulu la delton inter ili kaj ricevu la reproduktan malfruon en bajtoj. Ĝi estas tre oportuna kaj simpla.

En versio 10, ĉi tiu funkcio estis renomita al pg_wal_lsn_diff(). Ĝenerale, en ĉiuj funkcioj, vidoj kaj utilecoj, kie la vorto "xlog" aperis, ĝi estis anstataŭigita per la valoro "wal". Ĉi tio validas por kaj vidoj kaj funkcioj. Ĉi tio estas tia novigo.

Krome, en versio 10, linioj estis aldonitaj kiuj specife montras la malfruon. Ĉi tiuj estas skribmalfruo, flush lag, replay lag. Tio estas, estas grave kontroli ĉi tiujn aferojn. Se ni vidas, ke ni havas reproduktan malfruon, tiam ni devas esplori kial ĝi aperis, de kie ĝi venis kaj ripari la problemon.

Preskaŭ ĉio estas en ordo kun sistemaj metrikoj. Kiam iu ajn monitorado komenciĝas, ĝi komenciĝas per sistemaj metrikoj. Ĉi tio estas la dispono de procesoroj, memoro, interŝanĝo, reto kaj disko. Tamen, multaj parametroj ne estas tie defaŭlte.

Se ĉio estas en ordo kun la reciklada procezo, tiam estas problemoj kun disko reciklado. Kiel regulo, monitoraj programistoj aldonas informojn pri trairo. Ĝi povas esti en iops aŭ bajtoj. Sed ili forgesas pri latencia kaj utiligo de disko-aparatoj. Ĉi tiuj estas pli gravaj parametroj, kiuj permesas al ni taksi kiom ŝarĝitaj estas niaj diskoj kaj kiom malrapidaj ili estas. Se ni havas altan latentecon, tiam ĉi tio signifas, ke estas iuj problemoj kun la diskoj. Se ni havas altan utiligon, tio signifas, ke la diskoj ne eltenas. Ĉi tiuj estas pli bonaj karakterizaĵoj ol trafluo.

Krome, ĉi tiuj statistikoj ankaŭ povas esti akiritaj de la /proc dosiersistemo, kiel estas farita por reciklaj procesoroj. Mi ne scias kial ĉi tiu informo ne estas aldonita al monitorado. Sed tamen gravas havi ĉi tion en via monitorado.

La sama validas por retaj interfacoj. Estas informoj pri reta trafluo en pakaĵoj, en bajtoj, sed tamen mankas informoj pri latencia kaj neniuj informoj pri utiligo, kvankam tio ankaŭ estas utila informo.

Ajna monitorado havas malavantaĝojn. Kaj negrave kian monitoradon vi prenas, ĝi ĉiam ne plenumos iujn kriteriojn. Sed tamen ili disvolviĝas, novaj funkcioj kaj novaj aferoj estas aldonitaj, do elektu ion kaj finu ĝin.

Kaj por fini, vi ĉiam devas havi ideon pri tio, kion signifas la statistikoj provizitaj kaj kiel vi povas uzi ilin por solvi problemojn.

Kaj kelkaj ĉefaj punktoj:

• Vi ĉiam devas kontroli la haveblecon kaj havi panelojn, por ke vi rapide taksu, ke ĉio estas en ordo kun la datumbazo.
• Vi ĉiam devas havi ideon pri kiaj klientoj laboras kun via datumbazo por forigi malbonajn klientojn kaj pafi ilin.
• Gravas taksi kiel ĉi tiuj klientoj laboras kun datumoj. Vi devas havi ideon pri via laborŝarĝo.
• Gravas taksi kiel ĉi tiu laborkvanto estas formita, kun la helpo de kiaj demandoj. Vi povas taksi demandojn, vi povas optimumigi ilin, refaktorigi ilin, konstrui indeksojn por ili. Ĝi estas tre grava.
• Fonaj procezoj povas negative influi klientajn petojn, do gravas kontroli, ke ili ne uzas tro multajn rimedojn.
• Sistemaj metrikoj permesas vin fari planojn por grimpi kaj pliigi la kapablon de viaj serviloj, do gravas ankaŭ spuri kaj taksi ilin.

Se vi interesiĝas pri ĉi tiu temo, tiam vi povas sekvi ĉi tiujn ligilojn.
http://bit.do/stats_collector - ĉi tio estas oficiala dokumentaro de la statistika kolektanto. Estas priskribo de ĉiuj statistikaj vidoj kaj priskribo de ĉiuj kampoj. Vi povas legi, kompreni kaj analizi ilin. Kaj surbaze de ili, konstruu viajn grafikaĵojn kaj aldonu ilin al via monitorado.

Ekzemplaj petoj:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Ĉi tio estas nia kompania deponejo kaj mia propra. Ili enhavas ekzemplajn demandojn. Ne estas demandoj de la elektita* el serio tie. Estas jam pretaj konsultoj kun kuniĝoj, uzante interesajn funkciojn, kiuj ebligas al vi transformi krudajn nombrojn en legeblajn, oportunajn valorojn, t.e. tio estas bajtoj, tempo. Vi povas preni ilin, rigardi ilin, analizi ilin, aldoni ilin al via monitorado, konstrui vian monitoradon surbaze de ili.

Viaj demandoj

Demando: Vi diris, ke vi ne reklamos markojn, sed mi ankoraŭ scivolas - kiajn panelojn vi uzas en viaj projektoj?
Respondo: Ĝi varias. Okazas, ke ni venas al kliento kaj li jam havas sian propran monitoradon. Kaj ni konsilas la klienton pri tio, kion oni devas aldoni al ilia monitorado. La plej malbona situacio estas kun Zabbix. Ĉar ĝi ne havas la kapablon konstrui TopN-grafojn. Ni mem uzas Okmetro, ĉar ni konsiliĝis kun ĉi tiuj uloj pri monitorado. Ili monitoris PostgreSQL surbaze de niaj teknikaj specifoj. Mi skribas mian propran hejmbeston-projekton, kiu kolektas datumojn per Prometheus kaj enigas ĝin grafana. Mia tasko estas krei mian propran eksportilon en Prometheus kaj poste redoni ĉion en Grafana.

Demando: Ĉu ekzistas analogoj de AWR-raportoj aŭ... agregado? Ĉu vi scias pri io tia?
Respondo: Jes, mi scias kio estas AWR, ĝi estas bonega afero. Nuntempe ekzistas diversaj bicikloj, kiuj efektivigas proksimume la sekvan modelon. Je iu intervalo de tempo, iuj bazlinioj estas skribitaj al la sama PostgreSQL aŭ al aparta stokado. Vi povas gugli ilin en la Interreto, ili estas tie. Unu el la programistoj de tia afero sidas sur la forumo sql.ru en la fadeno PostgreSQL. Vi povas kapti lin tie. Jes, ekzistas tiaj aferoj, ili povas esti uzataj. Plie en ĝia pgCenter Mi ankaŭ skribas aferon, kiu permesas al vi fari la samon.

PS1 Se vi uzas postgres_exporter, kian panelon vi uzas? Estas pluraj el ili. Ili jam estas malmodernaj. Eble la komunumo kreos ĝisdatigitan ŝablonon?

PS2 Forigita pganalyze ĉar ĝi estas proprieta SaaS-propono, kiu fokusiĝas pri agado-monitorado kaj aŭtomatigitaj agordaj sugestoj.

Nur registritaj uzantoj povas partopreni la enketon. Ensaluti, bonvolu.

Kiun memgastigita postgresql-monitorado (kun panelo) vi konsideras la plej bona?

• 30,0%Zabbix + aldonoj de Alexey Lesovsky aŭ zabbix 4.4 aŭ 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 estas propra SaaS - mi ne povas forigi ĝin1

• 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

10 uzantoj voĉdonis. 26 uzantoj sindetenis.

fonto: www.habr.com