Ez ji we re pêşniyar dikim ku hûn nusxeya rapora Alexey Lesovsky ji Data Egret "Bingehên çavdêriya PostgreSQL" bixwînin.
Di vê raporê de, Alexey Lesovsky dê li ser xalên sereke yên statîstîkên piştî pêşkeftinê biaxive, wateya wan çi ye, û çima divê ew di çavdêriyê de amade bin; li ser kîjan grafîkan divê di çavdêriyê de bin, meriv çawa wan lê zêde bike û çawa wan şîrove bike. Rapor dê ji rêveberên databasê, rêvebirên pergalê û pêşdebirên ku bi çareserkirina pirsgirêka Postgres re eleqedar in kêrhatî be.
Navê min Alexey Lesovsky e, ez nûnertiya pargîdaniya Data Egret dikim.
Çend gotin li ser xwe. Min demek dirêj berê wekî rêveberê pergalê dest pê kir.
Min her cûre pergalên Linux-ê yên cihêreng bi rê ve bir, li ser tiştên cûrbecûr yên girêdayî Linux-ê xebitîm, ango virtualîzasyon, çavdêrîkirin, bi proxies re xebitîm, hwd. Lê di demekê de min dest pê kir ku bêtir bi databasan, PostgreSQL bixebitim. Min pir jê hez kir. Û di demekê de min dest pê kir ku piraniya dema xebata xwe li ser PostgreSQL bixebitim. Û bi vî awayî hêdî hêdî ez bûm PostgreSQL DBA.
Û di seranserê kariyera xwe de, ez her gav bi mijarên statîstîk, şopandin, û telemetrîyê re eleqedar bûm. Û dema ku ez rêveberê pergalê bûm, min ji nêz ve bi Zabbix re xebitî. Û min komek piçûk ji senaryoyên mîna nivîsand . Ew di dema xwe de pir populer bû. Û li wir gengaz bû ku çavdêriya tiştên pir cûda yên girîng, ne tenê Linux, lê di heman demê de pêkhateyên cihêreng.
Niha ez li ser PostgreSQL dixebitim. Ez jixwe tiştek din dinivîsim ku dihêle hûn bi statîstîkên PostgreSQL re bixebitin. Tê gotin (gotara li ser Habré - ).
A note destpêkê de biçûk. Kîjan rewşên xerîdarên me, xerîdarên me hene? Bi databasê ve girêdayî qezayek heye. Û dema ku databas ji berê ve hat vegerandin, serokê beşê an jî serokê pêşveçûnê tê û dibêje: "Hevalno, divê em çavdêriya databasê bikin, ji ber ku tiştekî xirab qewimî û divê em rê li ber vê yekê bigirin ku di paşerojê de çênebe." Û li vir pêvajoyek balkêş a hilbijartina pergalek çavdêriyê an adaptasyona pergalek çavdêriya heyî dest pê dike da ku hûn databasa xwe bişopînin - PostgreSQL, MySQL an hinên din. Û hevkar dest pê dikin ku pêşniyar bikin: "Min bihîst ku databasek wusa û wusa heye. Werin em bikar bînin." Heval bi hev re dest bi nîqaşê dikin. Û di dawiyê de derdikeve holê ku em celebek databasê hilbijêrin, lê çavdêriya PostgreSQL di wê de pir kêm tê pêşkêş kirin û divê em her gav tiştek lê zêde bikin. Ji GitHub hin depoyan bigirin, wan klon bikin, skrîptan biguhezînin, û bi rengek wan xweş bikin. Û di dawiyê de ew diqewime ku cûreyek karê destan e.
Ji ber vê yekê, di vê axaftinê de ez ê hewl bidim ku hin zanyariyan bidim we ka meriv çawa çavdêriyê ne tenê ji bo PostgreSQL, lê ji bo databasê jî hilbijêrin. Û zanyariyê bide we ku dê rê bide we ku hûn çavdêriya xwe temam bikin da ku hûn ji wê sûd werbigirin, da ku hûn databasa xwe bi feydeyê bişopînin, da ku di demek zû de pêşî li rewşên awarte yên pêşerojê bigirin ku dibe ku derkevin.
Û ramanên ku dê di vê raporê de bin dikarin rasterast bi her databasê re bêne adaptekirin, ew DBMS an noSQL be. Ji ber vê yekê, ne tenê PostgreSQL heye, lê dê di PostgreSQL-ê de meriv çawa vê yekê bike, gelek reçete jî hene. Dê mînakên pirsan hebin, mînakên saziyên ku PostgreSQL ji bo çavdêriyê hene. Û heke DBMS-ya we heman tiştan heye ku dihêle hûn wan di çavdêriyê de bihêlin, hûn jî dikarin wan biguhezînin, lê zêde bikin û ew ê baş be.
Ez ê di raporê de nebim
biaxivin ka meriv çawa metrîkan radest dike û hilîne. Ez ê di derbarê paş-pêvajoya daneyê û pêşkêşkirina wê ji bikarhêner re tiştek nebêjim. Û ez ê di derbarê hişyarkirinê de tiştek nebêjim.
Lê her ku çîrok pêşve diçe, ez ê dîmenên cihêreng ên çavdêriya heyî nîşan bidim û bi rengekî wan rexne bikim. Lê dîsa jî, ez ê hewl bidim ku navên marqeyan nekim da ku ji bo van hilberan reklam û antî-reklam nekim. Ji ber vê yekê, hemî tesadufî rasthatî ne û ji xeyala we re têne hiştin.
Pêşîn, em fêr bibin ka çavdêrî çi ye. Şopandin tiştekî pir girîng e. Her kes vê fêm dike. Lê di heman demê de, çavdêrî bi hilberek karsaziyê re têkildar nabe û rasterast bandorê li qezenca pargîdanî nake, ji ber vê yekê dem her gav ji çavdêriyê re li ser bingehek mayî tê veqetandin. Ger wextê me hebe, wê hingê em çavdêriyê dikin; ger wextê me tune be, wê hingê baş e, em ê wê têxin nav paşverû û rojekê em ê vegerin van karan.
Ji ber vê yekê, ji pratîka me, gava ku em têne ser xerîdaran, çavdêrî bi gelemperî ne temam e û ti tiştên balkêş tune ku ji me re bibe alîkar ku em bi databasê re karekî çêtir bikin. Û ji ber vê yekê çavdêrî her dem pêdivî ye ku were qedandin.
Danegeh tiştên wusa tevlihev in ku divê werin şopandin jî, ji ber ku databas depoyek agahdarî ne. Û agahdarî ji bo pargîdaniyê pir girîng e; ew bi tu awayî nayê winda kirin. Lê di heman demê de, databas perçeyên nermalava pir tevlihev in. Ew ji hejmareke mezin a pêkhateyan pêk tên. Û gelek ji van pêkhateyan divê bêne şopandin.
Ger em bi taybetî li ser PostgreSQL diaxivin, wê hingê ew dikare di forma nexşeyek ku ji hejmareke mezin a pêkhateyan pêk tê were temsîl kirin. Ev pêkhate bi hevûdu re tevdigerin. Û di heman demê de, PostgreSQL xwedan binavpergala Stats Collector-ê ye, ku dihêle hûn statîstîkên di derbarê xebata van bine-pergalan de berhev bikin û cûreyek navbeynkariyê ji rêveber an bikarhêner re peyda bikin da ku ew van statîstîkan bibîne.
Ev statîstîk di forma hin fonksiyon û nêrînan de têne pêşkêş kirin. Ji wan re jî tê gotin tablo. Ango, bi karanîna xerîdarek psql ya birêkûpêk, hûn dikarin bi databasê ve girêbidin, li ser van fonksiyon û dîtinan hilbijêrin, û di derbarê xebata binepergalên PostgreSQL de hin hejmarên taybetî bistînin.
Hûn dikarin van hejmaran li pergala şopandina xweya bijare zêde bikin, grafîkan xêz bikin, fonksiyonan zêde bikin û di demek dirêj de analîtîk bistînin.
Lê di vê raporê de ez ê van hemî fonksiyonan bi tevahî venekim, ji ber ku ew dikare tevahiya rojê bigire. Ez ê bi rastî du, sê an çar tiştan destnîşan bikim û ji we re vebêjim ka ew çawa dibin alîkar ku çavdêrî çêtir bikin.
Û heke em li ser çavdêriya databasê biaxivin, wê hingê çi hewce ye ku were şopandin? Berî her tiştî, pêdivî ye ku em peydabûnê bişopînin, ji ber ku databas karûbarek e ku gihîştina daneyan ji xerîdaran re peyda dike û pêdivî ye ku em peydabûnê bişopînin, û hin taybetmendiyên wê yên kalîteyî û hejmarî jî peyda bikin.
Di heman demê de pêdivî ye ku em xerîdarên ku bi databasa me ve girêdayî ne bişopînin, ji ber ku ew dikarin hem xerîdarên normal û hem jî xerîdarên zirardar bin ku dikarin zirarê bidin databasê. Her wiha divê bên şopandin û çalakiyên wan bên şopandin.
Dema ku xerîdar bi databasê ve girêdidin, diyar e ku ew dest bi xebata bi daneyên me dikin, ji ber vê yekê divê em bişopînin ka xerîdar çawa bi daneyan re dixebitin: bi kîjan tabloyan, û bi kêmasî, bi kîjan indexan re. Ango pêdivî ye ku em barê xebata ku ji hêla xerîdarên me ve hatî afirandin binirxînin.
Lê giraniya kar jî, bê guman, ji daxwazan pêk tê. Serlêdan bi databasê ve girêdidin, bi karanîna pirsan digihîjin daneyan, ji ber vê yekê girîng e ku em binirxînin ka kîjan pirsên me di databasê de hene, têra wan bişopînin, ku ew bi xeletî ne hatine nivîsandin, ku hin vebijark pêdivî ye ku ji nû ve werin nivîsandin û çêkirin da ku ew zûtir bixebitin. û bi performansa çêtir.
Û ji ber ku em li ser databasek dipeyivin, databas her gav pêvajoyên paşîn e. Pêvajoyên paşîn arîkar dikin ku performansa databasê di astek baş de bidomînin, ji ber vê yekê ew ji bo xebatê hin çavkaniyan hewce dikin. Di heman demê de, ew dikarin bi çavkaniyên daxwaziya xerîdar re hevûdu bikin, ji ber vê yekê pêvajoyên paşerojê yên çavbirçî dikarin rasterast bandorê li performansa daxwazên xerîdar bikin. Ji ber vê yekê, ew jî hewce ne ku bêne şopandin û şopandin da ku di warê pêvajoyên paşerojê de tehlûk nebin.
Û ev hemî di warê çavdêriya databasê de di pîvana pergalê de dimîne. Lê nihêrîn ku piraniya binesaziya me ber bi ewran ve diçe, metrîkên pergalê yên mêvandarek kesane her gav di paşde diçin. Lê di databasan de ew hîn jî têkildar in û, bê guman, pêdivî ye ku meriv pîvanên pergalê jî bişopîne.
Bi metrîkên pergalê re her tişt kêm-zêde baş e, hemî pergalên şopandina nûjen jixwe van pîvanan piştgirî dikin, lê bi gelemperî, hin pêkhate hîn jî têrê nakin û hin tişt hewce ne ku werin zêdekirin. Ez ê dest li wan jî bikim, dê li ser wan çend slayt hebin.
Xala yekem a planê gihîştinê ye. Gihîştin çi ye? Hebûna di têgihîştina min de şiyana bingehê ye ji bo girêdanên karûbarê, ango bingeh bilind dibe, ew wekî karûbar, girêdanên ji xerîdaran qebûl dike. Û ev gihîştin dikare ji hêla hin taybetmendiyan ve were nirxandin. Nîşandana van taybetmendiyan li ser tabloyan pir hêsan e.
Her kes dizane ku dashboard çi ne. Ev gava ku we yek mêze kir li ser ekrana ku tê de agahdariya pêwîst tê kurt kirin. Û hûn dikarin tavilê diyar bikin ka di databasê de pirsgirêk heye an na.
Li gorî vê yekê, hebûna databasê û taybetmendiyên din ên sereke divê her gav li ser tabloyan werin xuyang kirin da ku ev agahdarî li ber destê we be û her dem ji we re peyda bibe. Hin hûrguliyên din ên ku jixwe di vekolîna bûyeran de dibin alîkar, dema ku hin rewşên acîl lêkolîn dikin, ew jixwe hewce ne ku ew li ser tabloyên duyemîn werin danîn, an jî di girêdanên drilldown de ku rê li pergalên çavdêriya sêyemîn-sêyem vedigirin veşêrin.
Mînakek yek pergala çavdêriyê ya naskirî. Ev pergalek çavdêriyê ya pir xweş e. Ew gelek daneyan berhev dike, lê ji nêrîna min, wê têgehek xerîb a dashboardan heye. Zencîreyek ji bo "çêkirina dashboardê" heye. Lê gava ku hûn dashboardek diafirînin, hûn navnîşek du stûnan, navnîşek grafikan diafirînin. Û gava ku hûn hewce ne ku li tiştek dinêrin, hûn dest pê dikin bi mişkê bikirtînin, bizivirin, li nexşeya xwestî digerin. Û ev dem digire, ango dashboardên weha tune. Tenê navnîşên nexşeyan hene.
Divê hûn çi li van dashboardan zêde bikin? Hûn dikarin bi taybetmendiyek wusa wekî dema bersivê dest pê bikin. PostgreSQL dîtina pg_stat_statements heye. Ew ji hêla xwerû ve neçalak e, lê ew yek ji nêrînên pergalê yên girîng e ku divê her gav were çalak kirin û bikar anîn. Ew agahdariya li ser hemî pirsên xebitandinê yên ku di databasê de hatine bicîh kirin hilîne.
Li gorî vê yekê, em dikarin ji vê rastiyê dest pê bikin ku em dikarin dema pêkanîna tevahî ya hemî daxwazan bigirin û bi karanîna qadên jorîn bi hejmara daxwaznameyên xwe ve parve bikin. Lê ev germahiya navîn li nexweşxaneyê ye. Em dikarin ji qadên din dest pê bikin - dema darvekirina pirsê ya herî kêm, herî zêde û navîn. Û em dikarin ji sedî jî ava bikin; PostgreSQL ji bo vê fonksiyonên têkildar hene. Û em dikarin hin hejmarên ku dema bersivdana databasa me ya ji bo daxwazên jixwe hatine qedandin diyar dikin bistînin, ango em daxwaza derewîn 'hilbijêre 1' pêk naynin û li dema bersivê dinêrin, lê em dema bersivê ji bo daxwazên jixwe qedandî analîz dikin û xêz dikin. yan jimareke cuda, yan jî em li ser wê grafîkê ava dikin.
Her weha girîng e ku meriv hejmara xeletiyên ku niha ji hêla pergalê ve têne çêkirin bişopînin. Û ji bo vê yekê hûn dikarin dîtina pg_stat_database bikar bînin. Em balê dikişînin ser qada xact_rollback. Ev qad ne tenê hejmara paşveçûnên ku di databasê de çêdibin nîşan dide, lê di heman demê de hejmara xeletiyan jî dihesibîne. Bi nisbetî ve, em dikarin vê hejmarê di dashboarda xwe de nîşan bidin û bibînin ka niha çend xeletiyên me hene. Ger gelek xeletî hebin, wê hingê ev sedemek baş e ku hûn li têketinan binihêrin û bibînin ka ew çi celeb xelet in û çima çêdibin, û dûv re veberhênan bikin û wan çareser bikin.
Hûn dikarin tiştek wekî Tachometer zêde bikin. Ev hejmara danûstendinên di çirkeyê de û hejmara daxwazên her çirke ne. Bi nisbî dipeyivî, hûn dikarin van hejmaran wekî performansa heyî ya databasa xwe bikar bînin û binihêrin ka di daxwaziyan de lûtk hene, di danûstendinan de lûtk hene, an, berevajî vê, gelo databas kêm e ji ber ku hin paşnav têk çûye. Girîng e ku em her gav li vê hejmarê mêze bikin û ji bîr mekin ku ji bo projeya me ev celeb performans normal e, lê nirxên jor û jêrîn jixwe cûreyek pirsgirêk û nefêm in, ev tê vê wateyê ku divê em lê binihêrin ka çima ev hejmar in. ewqas bilind.
Ji bo ku em hejmara danûstendinan texmîn bikin, em dikarin dîsa serî li dîtina pg_stat_database bidin. Em dikarin hejmara peywiran û hejmara paşvekêşan lê zêde bikin û hejmara danûstendinan her çirkeyê bistînin.
Ma her kes fêm dike ku çend daxwaz dikarin di yek danûstendinê de cih bigirin? Ji ber vê yekê TPS û QPS hinekî cuda ne.
Hejmara daxwazan di çirkeyê de dikare ji pg_stat_statements were wergirtin û bi tenê berhevoka hemî daxwazên qedandî hesab bike. Eşkere ye ku em nirxa heyî bi ya berê re didin ber hev, jê jê dikin, deltayê digirin û mîqdarê digirin.
Ger bixwaze hûn dikarin metrîkên din lê zêde bikin, ku ev jî dibe alîkar ku hebûna databasa me binirxîne û bişopîne ka çu demên daketinê hene.
Yek ji van metrîkan dema xebatê ye. Lê uptime di PostgreSQL de hinekî dijwar e. Ez ê ji te re bêjim çima. Dema ku PostgreSQL dest pê kir, uptime dest bi raporkirinê dike. Lê heke di demekê de, mînakî, hin peywir bi şev dimeşiya, OOM-kujer hat û bi darê zorê pêvajoya zarokan a PostgreSQL rawestand, wê hingê di vê rewşê de PostgreSQL girêdana hemî xerîdar qut dike, qada bîranîna şikestî ji nû ve vedike û dest bi başbûnê dike. xala kontrolê ya dawî. Û dema ku ev vegerandina ji nuqteya kontrolê dom dike, databas girêdanan qebûl nake, ango ev rewş dikare wekî demdirêj were nirxandin. Lê jimarvana uptime dê ji nû ve neyê vegerandin, ji ber ku ew ji gava yekem ve dema destpêkirina postmaster dihesibîne. Ji ber vê yekê, rewşên weha dikarin werin paşguh kirin.
Her weha divê hûn hejmara karkerên valahiya çavdêriyê bikin. Ma her kes dizane ku otovacuum di PostgreSQL de çi ye? Ev di PostgreSQL de binepergalek balkêş e. Li ser wê gelek gotar hatine nivîsandin, gelek rapor hatine çêkirin. Li ser valahiya û çawa divê kar bike gelek nîqaş hene. Pir kes wê wekî xirabiyek pêdivî dibînin. Lê wisa ye. Ev celebek analoga berhevkarek çopê ye ku guhertoyên kevnar ên rêzikên ku ji hêla ti danûstendinê ve ne hewce ne paqij dike û cîhê di tablo û navnîşan de ji bo rêzikên nû azad dike.
Çima hûn hewce ne ku çavdêriya wê bikin? Ji ber ku valahiya carna gelek diêşe. Ew gelek çavkaniyan dixwe û daxwazên xerîdar di encamê de dest pê dikin.
Û divê ew bi riya dîtina pg_stat_activity, ya ku ez ê di beşa pêş de li ser biaxivim, were şopandin. Ev nêrîn çalakiya heyî ya di databasê de nîşan dide. Û bi rêya vê çalakiyê em dikarin hejmara valahiya ku niha dixebitin bişopînin. Em dikarin valahiyan bişopînin û bibînin ku heke me ji sînor derbas kiriye, wê hingê ev sedemek e ku em li mîhengên PostgreSQL binihêrin û bi rengekî operasyona valahiya xweştir bikin.
Tiştek din di derbarê PostgreSQL de ev e ku PostgreSQL ji danûstandinên dirêj pir nexweş e. Bi taybetî ji danûstendinên ku demek dirêj li dora xwe disekinin û tiştek nakin. Ev bi navê stat idle-in-transaction e. Danûstandinek wusa qefleyan digire û nahêle ku valahiya bixebite. Û ji ber vê yekê, tabloyên mezin dibin û mezin dibin. Û pirsên ku bi van tabloyan re dixebitin, hêdî hêdî dest bi xebatê dikin, ji ber ku hûn hewce ne ku hemî guhertoyên kevin ên rêzan ji bîrê berbi dîskê û paş ve bişopînin. Ji ber vê yekê, dem, dema danûstendinên herî dirêj, daxwazên valahiya herî dirêj jî pêdivî ye ku were şopandin. Û heke em hin pêvajoyên ku ji bo demek pir dirêj dimeşînin, jixwe ji 10-20-30 hûrdeman zêdetir ji bo barkirina OLTP-ê bibînin, wê hingê pêdivî ye ku em bala xwe bidin wan û bi zorê wan biqedînin, an serîlêdanê xweşbîn bikin da ku ew nayên gazîkirin û ewqas dirêj nayên darvekirin. Ji bo xebatek analîtîk, 10-20-30 hûrdem normal e; yên dirêjtir jî hene.
Dûv re vebijarka me bi xerîdarên girêdayî re heye. Gava ku me berê dashboardek çêkir û metrîkên hebûna sereke li ser wê şandin, em dikarin di derheqê xerîdarên girêdayî de jî agahdariya zêde li wir zêde bikin.
Agahdariya li ser xerîdarên girêdayî girîng e ji ber ku, ji perspektîfek PostgreSQL, xerîdar cûda ne. Mişteriyên baş hene û mişteriyên xerab jî hene.
Mînakek hêsan. Ji hêla xerîdar ve ez serîlêdanê fêm dikim. Serlêdan bi databasê ve girêdaye û tavilê dest bi şandina daxwazên xwe dike li wir, databas wan pêvajoyê dike û dimeşîne, û encaman li xerîdar vedigerîne. Ev xerîdarên baş û rast in.
Rewş hene ku xerîdar pê ve girêdayî ye, ew pêwendiyê digire, lê tiştek nake. Di rewşa bêkar de ye.
Lê mişteriyên xerab hene. Mînakî, heman xerîdar ve girêdayî bû, danûstendinek vekir, tiştek di databasê de kir û dûv re çû nav kodê, mînakî, da ku xwe bigihîne çavkaniyek derveyî an jî daneyên wergirtî li wir pêvajoyê bike. Lê ew danûstandin negirt. Û danûstendin di databasê de dimîne û li ser xetê di kilîtekê de tê girtin. Ev rewşek xirab e. Û heke ji nişka ve serîlêdanek li cîhek di hundurê xwe de bi îstîsnayek têk diçe, wê hingê danûstendin dikare ji bo demek pir dirêj vekirî bimîne. Û ev rasterast li ser performansa PostgreSQL bandor dike. PostgreSQL dê hêdîtir be. Ji ber vê yekê, girîng e ku meriv xerîdarên weha di wextê xwe de bişopîne û bi zorê xebata wan biqedîne. Û hûn hewce ne ku serîlêdana xwe xweş bikin da ku rewşên weha çênebin.
Xerîdarên din ên xirab li benda xerîdarên ne. Lê ji ber şert û mercan xerab dibin. Mînakî, danûstendinek betal a hêsan: ew dikare danûstendinek veke, li ser hin rêzan qefle bigire, dûv re li cîhek kodê ew ê têk biçe, danûstendinek daleqandî bihêle. Dê xerîdarek din were û heman daneyê bixwaze, lê ew ê bi qeflekê re rû bi rû bimîne, ji ber ku ew danûstendina daleqandî berê li ser hin rêzên pêwîst kilît digire. Û danûstendina duyemîn dê li bendê bimîne ku danûstendina yekem biqede an bi zorê wê ji hêla rêveber ve bigire. Ji ber vê yekê, danûstendinên li bendê dikarin sînorê girêdana databasê berhev bikin û tijî bikin. Û gava ku sînor tije ye, serîlêdan êdî nikare bi databasê re bixebite. Jixwe ev ji bo projeyê rewşeke awarte ye. Ji ber vê yekê, xerîdarên xirab hewce ne ku di wextê xwe de werin şopandin û bersivandin.
Nimûneyek din a çavdêriyê. Û jixwe li vir tabloyek maqûl heye. Li ser girêdanên jorîn agahdarî hene. Girêdana DB - 8 perçe. Û ev hemû. Agahdariya me tune ku kîjan xerîdar çalak in, kîjan xerîdar tenê bêkar in, tiştek nakin. Li ser danûstendinên li bendê û girêdanên li bendê agahiyek tune, ango ev jimarek e ku hejmara pêwendiyan nîşan dide û ew e. Û paşê ji bo xwe texmîn bikin.
Li gorî vê yekê, ji bo ku hûn vê agahiyê li çavdêriyê zêde bikin, hûn hewce ne ku bigihîjin dîtina pergala pg_stat_activity. Ger hûn gelek wext li PostgreSQL derbas dikin, wê hingê ev nêrînek pir baş e ku divê bibe hevalê we, ji ber ku ew çalakiya heyî ya li PostgreSQL nîşan dide, ango tiştê ku tê de diqewime. Ji bo her pêvajoyê xêzek cihêreng heye ku agahdariya di derbarê vê pêvajoyê de nîşan dide: girêdan ji kîjan mêvandar ve hatî çêkirin, di bin kîjan bikarhêner de, di bin kîjan navî de, kengê danûstendinê dest pê kir, kîjan daxwaz niha dimeşe, kîjan daxwaz herî dawî hate pêkanîn. Û, li gorî vê yekê, em dikarin bi karanîna qada statûyê rewşa xerîdar binirxînin. Bi nîsbet, em dikarin li gorî vê qadê kom bikin û wan statîstikên ku niha di databasê de ne û hejmara girêdanên ku ev statû di databasê de hene bistînin. Û em dikarin hejmarên ku berê hatine wergirtin bişînin çavdêriya xwe û li ser bingeha wan grafîkan xêz bikin.
Her weha girîng e ku meriv dirêjahiya danûstendinê binirxîne. Min berê jî got ku girîng e ku meriv dirêjahiya valahiyan binirxîne, lê danûstandin bi heman rengî têne nirxandin. Zeviyên xact_start û query_start hene. Ew, bi nisbî diaxivin, dema destpêkirina danûstendinê û dema destpêkirina daxwazê nîşan didin. Em fonksiyona niha() digirin, ku nîşana demjimêra heyî nîşan dide, û danûstendinê jêdikin û mohra demjimêrê daxwaz dikin. Û em heyama danûstendinê, dema daxwazê digirin.
Ger em danûstandinên dirêj bibînin, divê em berê wan temam bikin. Ji bo barkirina OLTP, danûstendinên dirêj berê ji 1-2-3 hûrdeman zêdetir in. Ji bo bargiraniyek OLAP-ê, danûstendinên dirêj normal in, lê heke ew ji du demjimêran zêdetir biqedînin, wê hingê ev jî nîşanek e ku li cîhek me şikestinek heye.
Gava ku xerîdar bi databasê ve girêdayî ne, ew bi daneyên me re dest bi xebatê dikin. Ew digihîjin tabloyan, ew digihîjin navnîşan ku daneyan ji tabloyê bistînin. Û girîng e ku meriv binirxîne ka xerîdar çawa bi vê daneyê re têkilî daynin.
Ev pêdivî ye ku em barê xebata xwe binirxînin û bi qasî têgihîştin ka kîjan tablo ji bo me "herîtirîn" in. Mînakî, ev di rewşên ku em dixwazin tabloyên "germ" li ser cûreyek hilanîna bilez a SSD-ê bicîh bikin de ev hewce ye. Mînakî, hin tabloyên arşîv ên ku me demek dirêj bikar neaniye, dikarin werin veguheztin celebek arşîvek "sar", li ajokarên SATA-yê û bihêlin ku ew li wir bijîn, li gorî hewcedariyê dê werin gihîştin.
Ev di heman demê de ji bo tespîtkirina anomaliyan piştî her berdan û bicîhkirinê jî bikêr e. Em bêjin ku proje hin taybetmendiyek nû derxistiye. Mînakî, me ji bo xebata bi databasê re fonksiyonek nû lê zêde kir. Û heke em grafikên karanîna tabloyê xêz bikin, em dikarin bi hêsanî van anomaliyan li ser van grafikan tespît bikin. Mînakî, teqînan nûve bikin an teqînan jêbirin. Ew ê pir xuya bibe.
Her weha hûn dikarin di statîstîkên "hilweşîn" de anomaliyan tespît bikin. Poldayî? PostgreSQL xwedan plansaziyek pirsê pir xurt û pir baş e. Û pêşdebiran gelek dem didin pêşkeftina wê. Ew çawa dixebite? Ji bo ku plansaziyên baş çêbike, PostgreSQL statîstîkên li ser belavkirina daneyan di tabloyan de di navberek demkî û bi frekansa diyarkirî de berhev dike. Nirxên herî gelemperî ev in: hejmara nirxên bêhempa, agahdariya li ser NULL di tabloyê de, gelek agahdarî.
Li ser bingeha van statîstîkan, planner gelek pirsan çêdike, ya herî çêtirîn hildibijêre, û vê pilana pirsê bikar tîne da ku pirsê bixwe bicîh bîne û daneyan vegerîne.
Û diqewime ku îstatîstîk "diherike". Daneyên kalîte û hejmar bi rengekî di tabloyê de guherî, lê statîstîk nehatin berhev kirin. Û planên hatine çêkirin dibe ku ne çêtirîn be. Û heke planên me li gorî çavdêriya ku hatine berhev kirin, li gorî tabloyan nebaş bin, em ê karibin van anomaliyan bibînin. Mînakî, li cîhek dane bi kalîte guheztin û li şûna pêvekê, derbasbûnek rêzdar di tabloyê de dest pê kir ku were bikar anîn, ango. heke pirsek hewce bike ku tenê 100 rêzan vegerîne (sînorek 100 heye), wê hingê dê ji bo vê pirsê lêgerînek bêkêmasî were kirin. Û ev her tim bandorek pir xirab li ser performansê dike.
Û em dikarin vê di çavdêriyê de bibînin. Û jixwe li vê pirsê mêze bikin, jê re ravekirinek bimeşînin, statîstîk berhev bikin, pêvek nû ya nû ava bikin. Û jixwe bersiva vê pirsgirêkê bide. Ji ber vê yekê girîng e.
Nimûneyek din a çavdêriyê. Ez difikirim ku gelek kesan ew nas kirin ji ber ku ew pir populer e. Kî di projeyên xwe de bikar tîne ? Kî vê hilberê bi Prometheus re bi kar tîne? Rastî ev e ku di depoya standard a vê çavdêriyê de tabloyek ji bo xebata bi PostgreSQL re heye - Prometheus. Lê detayek xirab heye.
Gelek grafîk hene. Û byte wekî yekîtiyê têne destnîşan kirin, ango 5 graf hene. Vana daneyan têxin, Daneyên nûve bikin, daneyan jêbirin, daneyan hilînin û daneyan vegerînin. Pîvana yekîneyê byte ye. Lê tişt ev e ku statîstîkên di PostgreSQL de daneyan di nav rêzan de vedigerînin. Û, li gorî vê yekê, ev graf rêyek pir baş e ku hûn barê xebata xwe çend caran, bi dehan carî kêm binirxînin, ji ber ku tuple ne bayt e, titek rêzek e, ew gelek bayt e û her gav bi dirêjahiya guhêrbar e. Ango, hesabkirina barê xebatê di byteyan de bi karanîna tûtan karekî nerealîst e an jî pir dijwar e. Ji ber vê yekê, gava ku hûn dashboardek an çavdêriyek çêkirî bikar tînin, her gav girîng e ku hûn fêm bikin ku ew bi rengek rast dixebite û daneyên rast nirxandina we vedigerîne.
Meriv çawa statîstîkên li ser van tabloyan digire? Ji bo vê armancê, PostgreSQL xwedan malbatek dîtinan e. Û nêrîna sereke ye . User_tables - ev tê wateya tabloyên ku li ser navê bikarhêner hatine afirandin. Berevajî vê, nêrînên pergalê hene ku ji hêla PostgreSQL bixwe ve têne bikar anîn. Û tabloyek kurteya Alltables heye, ku hem pergalê û hem jî yên bikarhêner tê de hene. Hûn dikarin ji yek ji wan ku hûn çêtirîn jê hez dikin dest pê bikin.
Bi karanîna zeviyên jorîn hûn dikarin hejmara têketin, nûvekirin û jêbirinan texmîn bikin. Mînaka dashboardek ku min bikar anî van qadan bikar tîne da ku taybetmendiyên bargiraniyek kar binirxîne. Ji ber vê yekê, em dikarin li ser wan jî ava bikin. Lê hêjayî bibîrxistinê ye ku ev qertaf in, ne bayt in, ji ber vê yekê em nekarin wê tenê bi bîtan bikin.
Li ser bingeha van daneyan, em dikarin tabloyên bi navê TopN ava bikin. Mînakî, Top-5, Top-10. Û hûn dikarin wan maseyên germ ên ku ji yên din bêtir têne vezîvirandin bişopînin. Mînakî, 5 tabloyên "germ" ji bo têxê. Û bi karanîna van tabloyên TopN-ê em barê xebata xwe dinirxînin û dikarin piştî her serbestberdan, nûvekirin û bicîhkirinê teqînên bargiraniyê binirxînin.
Di heman demê de girîng e ku meriv mezinahiya tabloyê jî binirxîne, ji ber ku carinan pêşdebiran taybetmendiyek nû derdixin, û tabloyên me dest pê dikin di mezinahiyên xwe yên mezin de mezin dibin, ji ber ku wan biryar da ku hêjmarek daneyê lê zêde bikin, lê pêşbîn nekir ku ev ê çawa mezinahiya databasê bandor dike. Bûyerên wiha jî ji me re sosret in.
Û niha pirsek piçûk ji we re. Dema ku hûn barkirina servera databasa xwe dibînin çi pirs derdikeve? Pirsa te ya din çi ye?
Lê di rastiyê de pirs wiha derdikeve pêş. Çi daxwazan dibe sedema barkirinê? Ango ne balkêş e ku meriv li pêvajoyên ku ji hêla barkirinê ve têne çêkirin binêrin. Eşkere ye ku heke mazûvan xwedî databasek be, wê hingê databas li wir tê xebitandin û diyar e ku tenê databas dê li wir werin avêtin. Ger em Top vekin, em ê li wir navnîşek pêvajoyên di PostgreSQL de bibînin ku tiştek dikin. Dê ji Topê diyar nebe ka ew çi dikin.
Li gorî vê yekê, hûn hewce ne ku wan pirsan bibînin ku dibe sedema bargiraniya herî bilind, ji ber ku lêpirsînên birêkûpêk, wekî qaîdeyek, ji guheztina PostgreSQL an veavakirina pergala xebitandinê, an tewra guheztina hardware bêtir sûdê dide. Li gorî texmîna min, ev bi qasî 80-85-90%. Û ev pir zûtir tê kirin. Rastkirina daxwazek ji rastkirina veavakirinê, ji nû ve destpêkirinê bernamesazkirin zûtir e, nemaze heke databas ji nû ve neyê destpêkirin, an jî hardware lê zêde bike. Ew hêsantir e ku meriv pirsê li cîhek ji nû ve binivîsîne an pêvekek lê zêde bike da ku ji vê pirsê encamek çêtir bistîne.
Li gorî vê yekê, pêdivî ye ku çavdêriya daxwaz û têra wan were kirin. Werin em mînakek din a çavdêriyê bigirin. Û li vir jî, xuya ye ku çavdêriyek hêja heye. Agahiyên li ser dubarekirinê hene, agahdarî li ser rêgirtin, astengkirin, karanîna çavkaniyê hene. Her tişt baş e, lê li ser daxwazan tu agahî tune. Ne diyar e ku di databasa me de kîjan pirs têne xebitandin, çiqas diqewimin, çend ji van pirsan in. Divê em her dem di çavdêriya xwe de ev agahdarî hebin.
Û ji bo bidestxistina vê agahiyê em dikarin modula pg_stat_statements bikar bînin. Li ser bingeha wê, hûn dikarin cûrbecûr grafikan ava bikin. Mînakî, hûn dikarin li ser pirsên herî pir caran agahdarî bistînin, ango li ser wan pirsên ku pir caran têne darve kirin. Erê, piştî bicîhkirinê jî pir bikêr e ku meriv lê binêre û fam bike ka di daxwaziyan de zêdebûnek heye.
Hûn dikarin lêpirsînên herî dirêj, ango, wan pirsên ku temamkirina herî dirêj digirin bişopînin. Ew li ser pêvajoyê dixebitin, ew I/O vedixwin. Em dikarin vê jî bi karanîna zeviyên total_time, mean_time, blk_write_time û blk_read_time binirxînin.
Em dikarin daxwazên herî giran di warê karanîna çavkaniyê de binirxînin û bişopînin, yên ku ji dîskê dixwînin, ku bi bîranînê re dixebitin, an, berevajî, cûreyek barkirina nivîsandinê diafirînin.
Em dikarin daxwazên herî bi comerdî binirxînin. Ev pirs in ku hejmareke mezin ji rêzan vedigerînin. Mînakî, ev dibe ku hin daxwazek be ku wan ji bîr kiriye ku sînorek destnîşan bikin. Û ew bi tenê tevahiya naveroka tabloyê an lêpirsînê li seranserê tabloyên pirsîn vedigerîne.
Û hûn dikarin pirsên ku pelên demkî an tabloyên demkî bikar tînin jî bişopînin.
Û em hîn jî pêvajoyên paşerojê hene. Pêvajoyên paşîn di serî de nuqteyên kontrolê ne an jî ji wan re xalên kontrolê jî tê gotin, ev otovacuum û dubarekirin in.
Nimûneyek din a çavdêriyê. Li milê çepê tabloyek Maintenance heye, biçin wê û hêvî bikin ku hûn tiştek kêrhatî bibînin. Lê li vir tenê dema operasyona valahiya û berhevkirina statîstîkan e, ne tiştek din. Ev agahdariya pir qels e, ji ber vê yekê em her gav hewce ne ku agahdarî li ser ka pêvajoyên paşerojê di databasa me de çawa dixebitin û gelo ji xebata wan pirsgirêk hene hene.
Dema ku em li nuqteyên kontrolê dinêrin, divê em ji bîr mekin ku xalên kontrolê rûpelên qirêj ji qada bîranîna şikestî ber bi dîskê ve diherikînin, dûv re nuqteyek kontrolê ava dikin. Û ev nuqteya kontrolê wê hingê dikare wekî cîhek ji bo başbûnê were bikar anîn heke PostgreSQL ji nişka ve di rewşek acîl de hate qedandin.
Li gorî vê yekê, ji bo ku hûn hemî rûpelên "pîs" li ser dîskê bişewitînin, hûn hewce ne ku hin nivîsandinê bikin. Û, wekî qaîdeyek, li ser pergalên bi mîqdarên mezin ên bîranînê, ev pir e. Û heke em pir caran di navberek kurt de xalên kontrolê bikin, wê hingê performansa dîskê dê pir girîng dakeve. Û daxwazên xerîdar dê ji kêmbûna çavkaniyan cefayê bikişînin. Ew ê ji bo çavkaniyan pêşbaziyê bikin û nebûna hilberînê.
Li gorî vê yekê, bi navgîniya pg_stat_bgwriter bi karanîna qadên diyarkirî em dikarin hejmara nuqteyên kontrolê yên ku diqewimin bişopînin. Û heke di heyamek diyarkirî de (di 10-15-20 hûrdeman de, di nîv saetê de) gelek nuqteyên kontrolê hebin, mînakî 3-4-5, wê hingê ev jixwe dikare pirsgirêkek be. Û hûn jixwe hewce ne ku li databasê bigerin, li veavakirinê binihêrin, ka çi dibe sedema pirbûna nuqteyên kontrolê. Dibe ku celebek tomarek mezin hebe. Em jixwe dikarin barkêşiya xebatê binirxînin, ji ber ku me berê grafikên barkêşiya xebatê zêde kirine. Em jixwe dikarin parametreyên xala kontrolê biguhezînin û pê ewle bin ku ew pir bandorê li performansa pirsê nakin.
Ez dîsa vedigerim otovacuumê ji ber ku ew tiştek wusa ye, wekî min got, ku dikare bi hêsanî hem performansa dîskê û hem jî pirsê zêde bike, ji ber vê yekê her gav girîng e ku meriv mîqdara otovacuumê texmîn bike.
Hejmara xebatkarên otovacuumê di databasê de sînordar e. Ji hêla xwerû, sê ji wan hene, ji ber vê yekê heke em her gav sê xebatkarên me di databasê de dixebitin, ev tê vê wateyê ku otovacuuma me nehatiye mîheng kirin, pêdivî ye ku em sînoran bilind bikin, mîhengên otovacuumê ji nû ve bikin û bikevin nav mîhengê.
Girîng e ku em binirxînin ka kîjan karkerên valahiya me hene. An ew ji bikarhêner hate destpêkirin, DBA hat û bi destan cûreyek valahiya dest pê kir, û vê yekê barek çêkir. Pirsgirêkek me heye. An jî ev hejmara valahiyan e ku jimareya danûstendinê vedike. Ji bo hin guhertoyên PostgreSQL ev valahiya pir giran in. Û ew dikarin bi hêsanî performansê zêde bikin ji ber ku ew tevahiya tabloyê dixwînin, hemî blokên di wê tabloyê de dişoxilînin.
Û, bê guman, dirêjahiya valahiyan. Ger valahiya me ya demdirêj hebe ku ji bo demek pir dirêj dimeşîne, wê hingê ev tê vê wateyê ku em dîsa hewce ne ku bala xwe bidin veavakirina valahiya û dibe ku mîhengên wê ji nû ve binirxînin. Ji ber ku dibe ku rewşek derkeve holê dema ku valahiya demek dirêj (3-4 demjimêran) li ser masê bixebite, lê di dema ku valahiya kar dikir de, hejmareke mezin ji rêzên mirî dîsa di tabloyê de kom bûn. Û gava ku valahiya qediya, ew hewce dike ku vê tabloyê dîsa vala bike. Û em hatin rewşek - valahiyek bêdawî. Û di vê rewşê de, valahî bi karê xwe re mijûl nabe, û tablo hêdî hêdî dest bi mezinbûnê dikin, her çend hêjeya daneyên bikêr tê de heman dimîne. Ji ber vê yekê, di dema valahiyên dirêj de, em her gav li veavakirinê dinêrin û hewl didin ku wê xweştir bikin, lê di heman demê de da ku performansa daxwazên xerîdar zirarê neke.
Naha di pratîkê de sazkirina PostgreSQL-ya ku xwedan dubarekirina streaming tune ye tune. Replicasyon pêvajoyek veguhastina daneyan ji masterek berbi kopiyek e.
Repplication di PostgreSQL de bi riya têketinek danûstendinê tê kirin. Wizard têketinek danûstendinê çêdike. Daxuyaniya danûstendinê li ser pêwendiya torê ya bi replikayê re derbas dibe, û dûv re ew li ser replikayê tê hilberandin. Ew hêsan e.
Li gorî vê yekê, dîtina pg_stat_replication ji bo şopandina derengiya dubarekirinê tê bikar anîn. Lê her tişt bi wê re ne hêsan e. Di guhertoya 10-an de, nêrîn çend guhertin derbas kirin. Ya yekem, hin qadan hatine guhertin. Û hin zevî hatine zêdekirin. Di guhertoya 10-an de, zeviyên ku dihêle hûn di çirkeyan de derengiya dubarekirinê texmîn bikin xuya bûn. Pir rehet e. Beriya guhertoya 10-an, gengaz bû ku derengiya dubarekirinê di byteyan de were texmîn kirin. Ev vebijark di guhertoya 10-an de dimîne, ango hûn dikarin tiştê ku ji we re hêsantir e hilbijêrin - derengiyê bi bîtan texmîn bikin an derengiyê di çirkeyan de texmîn bikin. Gelek kes herduyan dikin.
Lê dîsa jî, ji bo ku hûn derengiya dubarekirinê binirxînin, hûn hewce ne ku pozîsyona têketinê di danûstendinê de zanibin. Û ev helwestên têketinê yên danûstendinê tam di dîtina pg_stat_replication de ne. Wekî din, em dikarin du xalan di têketina danûstendinê de bi karanîna fonksiyona pg_xlog_location_diff() bigirin. Deltaya di navbera wan de hesab bikin û derengiya dubarekirinê di byteyan de bistînin. Ew pir hêsan û hêsan e.
Di guhertoya 10-an de, navê vê fonksiyonê wekî pg_wal_lsn_diff (). Bi gelemperî, di hemî fonksiyon, dîtin û karûbarên ku peyva "xlog" lê xuya bû de, ew bi nirxa "wal" hate guheztin. Ev hem ji bo dîtin û fonksiyonan derbas dibe. Ev nûbûnek wisa ye.
Zêdeyî, di guhertoya 10-an de, rêzikên ku bi taybetî derengiyê destnîşan dikin hatin zêdekirin. Vana derengiya nivîsandinê, derengiya rijandinê, derengiya dubarekirinê ne. Ango çavdêriya van tiştan girîng e. Ger em bibînin ku me derengek dubarekirinê heye, wê hingê pêdivî ye ku em lêkolîn bikin ka çima ew xuya bû, ji ku derê hat û pirsgirêkê rast bikin.
Hema hema her tişt bi pîvanên pergalê re rêkûpêk e. Dema ku çavdêriyek dest pê dike, ew bi metrîkên pergalê dest pê dike. Ev avêtina pêvajoker, bîranîn, swap, torê û dîskê ye. Lêbelê, gelek pîvan bi xwerû ne li wir in.
Ger di pêvajoya vezîvirandinê de her tişt bi rêkûpêk be, wê hingê di vezîvirandina dîskê de pirsgirêk hene. Wekî qaîdeyek, pêşdebirên çavdêriyê agahdarî li ser rêgezê zêde dikin. Ew dikare di iops an bytes de be. Lê ew dereng û karanîna amûrên dîskê ji bîr dikin. Ev parametreyên girîngtir in ku dihêle em binirxînin ka dîskên me çiqas barkirî ne û ew çiqas hêdî ne. Ger derengiya me ya bilind hebe, wê hingê ev tê vê wateyê ku bi dîskan re hin pirsgirêk hene. Ger karanîna me ya zêde hebe, ev tê vê wateyê ku dîskê nagirin. Ev taybetmendî ji hilberan çêtir in.
Wekî din, ev statîstîk ji pergala pelê /proc jî têne wergirtin, wekî ku ji bo pêvajoyên vezîvirandinê tê kirin. Ez nizanim çima ev agahî li çavdêriyê nayê zêdekirin. Lê dîsa jî, girîng e ku ev di çavdêriya we de hebe.
Heman tişt ji bo navberên torê jî derbas dibe. Di pakêtan de, di bîtan de agahdarî li ser rêgirtina torê heye, lê dîsa jî di derheqê derengbûnê de agahdarî tune û di derheqê karanîna de jî agahdarî tune, her çend ev jî agahdariya kêrhatî ye.
Her çavdêrî kêmasiyên xwe hene. Û hûn çi cûre çavdêriyê bikin jî, ew ê her gav hin pîvanan bicîh neke. Lê dîsa jî, ew pêşve diçin, taybetmendiyên nû û tiştên nû têne zêdekirin, ji ber vê yekê tiştek hilbijêrin û biqedînin.
Û ji bo ku biqedînin, divê hûn her gav ramanek we hebe ka statîstîkên pêşkêşkirî tê çi wateyê û hûn çawa dikarin wan bikar bînin da ku pirsgirêkan çareser bikin.
Û çend xalên sereke:
- Pêdivî ye ku hûn her gav hebûnan bişopînin û tabloyên wan hebin, da ku hûn zû binirxînin ku her tişt bi databasê re li rê ye.
- Hûn her gav hewce ne ku ramanek li ser çi xerîdar bi databasa we re dixebitin hebe da ku xerîdarên xirab ji holê rakin û wan bikujin.
- Girîng e ku meriv binirxîne ka van xerîdar çawa bi daneyan re dixebitin. Pêdivî ye ku hûn li ser barê xebata xwe xwedî ramanek bin.
- Girîng e ku mirov binirxîne ka ev bargiraniya kar çawa pêk tê, bi alîkariya kîjan pirsan. Hûn dikarin pirsan binirxînin, hûn dikarin wan xweşbîn bikin, wan nûve bikin, ji wan re indexan ava bikin. Pir girîng e.
- Pêvajoyên paşîn dikare bandorek neyînî li daxwazên xerîdar bike, ji ber vê yekê girîng e ku meriv çavdêriyê bike ku ew pir çavkaniyan bikar neynin.
- Metrîkên pergalê dihêle hûn ji bo pîvandin û zêdekirina kapasîteya serverên xwe plansaz bikin, ji ber vê yekê girîng e ku hûn wan jî bişopînin û binirxînin.
Heke hûn bi vê mijarê re eleqedar dibin, wê hingê hûn dikarin van girêdanan bişopînin.
- ev belgeya fermî ya berhevkarê statîstîkê ye. Danasîna hemû dîtinên îstatîstîkî û danasîna hemû qadan heye. Hûn dikarin wan bixwînin, fêm bikin û analîz bikin. Û li ser bingeha wan, grafikên xwe ava bikin û wan li çavdêriya xwe zêde bikin.
Daxwazên Nimûne:
Ev depoya pargîdaniya me û ya min e. Ew pirsên nimûne hene. Tu pirs ji hilbijartî * ji rêze li wir. Jixwe bi tevlêbûnê ve lêpirsînên amade hene, bi karanîna fonksiyonên balkêş ên ku dihêle hûn jimareyên xav veguherînin nirxên xwendî, hêsan, ango ev byte, dem in. Hûn dikarin wan hildin, li wan binihêrin, wan analîz bikin, wan li çavdêriya xwe zêde bikin, çavdêriya xwe li ser wan ava bikin.
Pirsên
Pirs: We got ku hûn ê markayan reklam nekin, lê ez hîn jî meraq dikim - hûn di projeyên xwe de çi celeb dashboardan bikar tînin?
Bersiv: Ew diguhere. Diqewime ku em têne ba xerîdarek û ew jixwe çavdêriya xwe heye. Û em xerîdar şîret dikin ka çi hewce dike ku li çavdêriya wan were zêdekirin. Rewşa herî xirab bi Zabbix re ye. Ji ber ku şiyana avakirina grafikên TopN tune ye. Em bi xwe bikar tînin , ji ber ku em bi van kesan re li ser çavdêriyê şêwirîn. Wan PostgreSQL li ser bingeha taybetmendiyên teknîkî yên me şopandin. Ez projeya xweya heywanan dinivîsim, ku daneyan bi Prometheus berhev dike û di nav de dide . Karê min ew e ku ez di Prometheus de hinardekarê xwe biafirînim û dûv re her tiştî li Grafana pêşkêş bikim.
Pirs: Gelo analogên raporên AWR an ... hevgirtinê hene? Ma tu ji tiştekî wiha dizanî?
Bersiv: Erê, ez dizanim AWR çi ye, ew tiştek xweş e. Vê gavê cûrbecûr bisîklet hene ku bi qasî modela jêrîn bicîh dikin. Di navberek demê de, hin rêzikên bingehîn li heman PostgreSQL an li depoyek cihê têne nivîsandin. Hûn dikarin wan li ser Înternetê google bikin, ew li wir in. Yek ji pêşdebirên tiştek wusa li ser forumê sql.ru di mijara PostgreSQL de rûniştiye. Hûn dikarin wî li wir bigirin. Belê, tiştên wisa hene, dikarin bên bikaranîn. Zêdetir di wê de Ez jî tiştekî dinivîsim ku destûrê dide te ku hûn heman tiştî bikin.
PS1 Heke hûn postgres_exporter bikar tînin, hûn kîjan dashboard bikar tînin? Çend ji wan hene. Jixwe kevn bûne. Dibe ku civak şablonek nûvekirî biafirîne?
PS2 Pganalyze hate rakirin ji ber ku ew pêşkêşiyek SaaS-ya xwedan e ku balê dikişîne ser çavdêriya performansê û pêşniyarên guheztina otomatîkî.
Tenê bikarhênerên qeydkirî dikarin beşdarî anketê bibin. ji kerema xwe.
Hûn kîjan çavdêriya postgresql-ya xwe-mêvandar (bi dashboardê) çêtirîn dibînin?
-
30,0%Zabbix + zêdekirinên ji Alexey Lesovsky an zabbix 4.4 an 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 SaaSek xwedan e - Ez nikarim wê jêbikim1
-
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 bikarhêneran deng dan. 26 bikarhêner jî betal bûn.
Source: www.habr.com