Danûstendina rapora Alexey Lesovsky ya 2015-an "Kûr di nav statîstîkên hundurîn ên PostgreSQL de"
Daxuyaniya nivîskarê raporê: Ez bala xwe didim ku ev rapor di Mijdara 2015-an de ye - bêtirî 4 sal derbas bûne û gelek dem derbas bûye. Guhertoya 9.4 ya ku di raporê de hatî nîqaş kirin êdî nayê piştgirî kirin. Di nav 4 salên borî de, 5 weşanên nû derketine ku tê de gelek nûbûn, pêşkeftin û guhertin di derbarê statîstîkê de hene, û hin ji wan materyalên kevnar û ne têkildar in. Dema ku ez dinirxînim, min hewl da ku van deran nîşan bikim da ku xwendevan nexapin. Min ev beş ji nû ve nenivîsand, gelek hene û encam dê bibe raporek bi tevahî cûda.
PostgreSQL DBMS mekanîzmayek pir mezin e, û ev mekanîzma ji gelek binepergalan pêk tê, ku operasyona hevrêziya wan rasterast bandorê li performansa DBMS dike. Di dema xebatê de, statîstîk û agahdariya di derbarê xebata pêkhateyan de têne berhev kirin, ku dihêle hûn bandora PostgreSQL binirxînin û ji bo baştirkirina performansê tedbîran bigirin. Lêbelê, gelek ji van agahdarî hene û ew bi rengek pir hêsan têne pêşkêş kirin. Pêvajoya vê agahiyê û şîrovekirina wê carinan karekî bi tevahî ne-tewre ye, û "zoo" alav û amûran dikare bi hêsanî DBA-ya pêşkeftî jî tevlihev bike.
Paş nîvro Navê min Aleksey e. Wekî ku Ilya got, ez ê li ser statîstîkên PostgreSQL biaxivim.
Statîstîkên çalakiya PostgreSQL. PostgreSQL du statîstîk hene. Statîstîkên çalakiya ku dê bêne nîqaş kirin. Û statîstîkên plansazker di derbarê belavkirina daneyê de. Ez ê bi taybetî li ser statîstîkên çalakiya PostgreSQL biaxivim, ku dihêlin em performansê dadbar bikin û bi rengek wê baştir bikin.
Ez ê ji we re vebêjim ka meriv çawa statîstîkan bi bandor bikar tîne da ku cûrbecûr pirsgirêkên ku we hene an dibe ku hebin çareser bikin.
Dê di raporê de çi nebe? Di raporê de ez ê dest li ser statîstîkên plansaziyê nekim, ji ber ku ... Ev mijarek veqetandî ye ji bo raporek veqetandî li ser ka dane çawa di databasê de têne hilanîn û plansazkerê pirsê çawa li ser taybetmendiyên kalîte û mîqdar ên vê daneyê ramanek digire.
Û dê nirxandinên amûran tune be, ez ê hilberek bi ya din re hevber nekim. Dê reklam neyê kirin. Em vê yekê bidin aliyekî.
Ez dixwazim nîşanî we bidim ku karanîna statîstîk bikêr e. Pêdivî ye. Bikaranîna wê ewle ye. Tişta ku em hewce ne SQL-ya birêkûpêk û zanîna bingehîn a SQL ye.
Û em biaxivin ka kîjan statîstîk hilbijêrin ku pirsgirêkan çareser bikin.
Ger em li PostgreSQL mêze bikin û ji bo dîtina pêvajoyan fermanek li ser pergala xebitandinê bimeşînin, em ê "qutiyek reş" bibînin. Em ê hin pêvajoyên ku tiştek dikin bibînin, û ji navê xwe em dikarin bi qasî xeyal bikin ka ew li wir çi dikin, çi dikin. Lê, di eslê xwe de, ew qutiyek reş e; em nikarin hundurê xwe binihêrin.
Em dikarin barkirina CPU-yê tê de bibînin top, em dikarin ji hêla hin karûbarên pergalê ve li karanîna bîranînê binêrin, lê em ê nikaribin li hundurê PostgreSQL binihêrin. Ji bo vê em amûrên din hewce ne.
Û bêtir berdewam bikim, ez ê ji we re vebêjim ku dem li ku derê derbas dibe. Ger em PostgreSQL di forma diagramek weha de xeyal bikin, wê hingê em dikarin bersivê bidin ku dem li ku derê derbas dibe. Ev du tişt in: ew daxwazên xerîdar ji serîlêdanan û karên paşîn ên ku PostgreSQL pêk tîne da ku xwe bixebitîne.
Ger em dest bi nihêrîna li quncika çepê ya jorîn bikin, em dikarin bibînin ka daxwazên xerîdar çawa têne pêvajoyê. Daxwaz ji serîlêdanê tê û danişînek xerîdar ji bo xebata din tê vekirin. Daxwaz ji planker re tê şandin. Plansaz planek lêpirsînê ava dike. Ji bo darvekirinê bêtir dişîne. Cûreyek têketin/derketina daneya blokê heye ku bi tablo û nîşanan ve girêdayî ye. Daneyên pêwîst ji dîskan di nav bîranînê de li deverek taybetî "buferên hevbeş" têne xwendin. Encamên daxwazê, heke ew nûvekirin, jêbirin, di têketina danûstandinê ya WAL de têne tomar kirin. Hin agahdariya statîstîkî di têketin an berhevkarê statîstîkê de diqede. Û encama daxwazê ji xerîdar re tê şandin. Piştî ku xerîdar dikare her tiştî bi daxwazek nû dubare bike.
Karên paşerojê û pêvajoyên paşîn çi dikin? Gelek pêvajoyên me hene ku databasê di moda xebitandina normal de diparêze û dimeşîne. Dê di raporê de li ser van pêvajoyên jî werin destgirtin: otovacuum, xala kontrolê, pêvajoyên têkildar-rêveberiyê, nivîskarê paşîn. Dema ku ez rapor dikim ez ê li ser her yek ji wan bisekinim.
Di statîstîkê de çi pirsgirêk hene?
- Gelek agahî hene. PostgreSQL 9.4 ji bo dîtina daneyên statîstîkê 109 metrîkan peyda dike. Lêbelê, heke databas gelek tablo, şema, databas hilîne, wê hingê pêdivî ye ku hemî van metrîkan bi hejmara têkildar a tabloyan, databasan ve werin zêdekirin. Yanî hîn zêdetir agahî hene. Û pir hêsan e ku meriv tê de xeniqîne.
- Pirsgirêka din ev e ku statîstîkan bi jimarvanan têne destnîşan kirin. Ger em li van statîstîkan binerin, em ê bibînin ku her gav jimarvan zêde dibin. Û ger ji nûvekirina statîstîkan re gelek dem derbas bibe, em ê nirxan bi mîlyaran bibînin. Û tiştek ji me re nabêjin.
- Çîrok tune. Ger we cûreyek têkçûnek hebû, tiştek 15-30 hûrdem berê ket, hûn ê nikaribin statîstîkan bikar bînin û bibînin ka 15-30 hûrdem berê çi bûye. Ev pirsgirêk e.
- Nebûna amûrek ku di PostgreSQL de hatî çêkirin pirsgirêkek e. Pêşdebirên kernel tu karûbar peyda nakin. Tiştekî wan ê wisa nîne. Ew tenê di databasê de statîstîkan peyda dikin. Wê bikar bînin, daxwazek jê re bikin, tiştê ku hûn dixwazin bikin.
- Ji ber ku amûrek di PostgreSQL de hatî çêkirin tune, ev dibe sedema pirsgirêkek din. Gelek amûrên partiya sêyemîn. Her pargîdaniya ku destên wan kêm an zêde rasterast hene hewl dide ku bernameya xwe binivîsîne. Û di encamê de, civakê gelek amûrên ku dikarin bikar bînin ku bi statîstîkan re bixebitin hene. Û hin alav xwedî hin îmkan in, amûrên din ne xwediyê şiyanên din in, an jî hin şiyanên nû hene. Û rewşek derdikeve ku hûn hewce ne ku du, sê an çar amûrên ku hevûdu li hev dikin û fonksiyonên cûda hene bikar bînin. Ev pir ne xweş e.
Ji vê yekê çi derdikeve? Girîng e ku meriv bikaribe rasterast statîstîkan bigire, da ku bi bernameyan ve girêdayî nemîne, an jî bi rengekî van bernameyan bixwe çêtir bikin: hin fonksiyonan zêde bikin da ku hûn berjewendiya xwe bistînin.
Û hûn hewceyê zanîna bingehîn a SQL. Ji bo ku hûn hin daneyan ji îstatîstîkê bistînin, hûn hewce ne ku pirsên SQL biafirînin, ango hûn hewce ne ku hûn zanibin ka hilbijartin û tevlêbûn çawa têne berhev kirin.
Statîstîk gelek tiştan ji me re vedibêje. Ew dikarin di kategoriyan de bêne dabeş kirin.
- Kategoriya yekem bûyerên di databasê de diqewimin e. Ev gava ku hin bûyer di databasê de çêdibin: daxwazek, gihîştina tabloyek, otovacuum, commits, wê hingê ev hemî bûyer in. Hejmarên li gorî van bûyeran zêde dibin. Û em dikarin van bûyeran bişopînin.
- Kategoriya duyemîn taybetmendiyên tiştên wekî tablo û databasan e. Taybetmendiyên wan hene. Ev mezinahiya tabloyan e. Em dikarin mezinbûna tabloyan û mezinbûna nîşanan bişopînin. Em dikarin guhertinên di dînamîk de bibînin.
- Û kategoriya sêyemîn dema ku li ser bûyerê derbas dibe. Daxwazek bûyerek e. Ew pîvana xweya taybetî ya dirêjbûnê heye. Li vir dest pê kir, li vir qediya. Em dikarin wê bişopînin. Wextê ku meriv blokê ji dîskê dixwîne an jî wê binivîse. Tiştên wiha jî tên şopandin.
Çavkaniyên statîstîkan wiha tên pêşkêşkirin:
- Di bîranîna hevpar (temponên hevpar) de beşek ji bo hilanîna daneyên statîk heye, di heman demê de ew jimarvan jî hene ku dema ku hin bûyer diqewimin, an hin deq di xebata databasê de derdikevin holê, bi domdarî zêde dibin.
- Hemî van jimarvan ne ji bikarhêner re ne û ne jî ji rêveberê re ne. Ev tiştên kêm in. Ji bo gihîştina wan, PostgreSQL di forma fonksiyonên SQL de navbeynkariyek peyda dike. Em dikarin bi karanîna van fonksîyonan avêtinên bijartî çêbikin û celebek metrîk (an komek metrikan) bistînin.
- Lêbelê, karanîna van fonksiyonan her gav ne hêsan e, ji ber vê yekê fonksiyonên bingehîn ji bo dîtinan in (VIEWs). Van tabloyên virtual in ku statîstîkên li ser binepergalek taybetî, an li ser komek bûyeran di databasê de peyda dikin.
- Van dîtinên pêvekirî (VIEW) ji bo xebata bi statîstîkan re navbeynkariya bikarhêner a bingehîn in. Ew ji hêla xwerû ve bêyî mîhengên zêde hene, hûn dikarin tavilê wan bikar bînin, li wan binihêrin, û ji wan agahdarî bistînin. Û paşê beşdarî hene. Beşdariyên fermî ne. Hûn dikarin pakêta postgresql-contrib saz bikin (mînak, postgresql94-contrib), modulaya pêwîst di veavakirinê de bar bikin, pîvanên wê diyar bikin, PostgreSQL ji nû ve bidin destpêkirin û hûn dikarin wê bikar bînin. (Not. Bi dabeşkirinê ve girêdayî, di guhertoyên dawî de pakêta tevkariyê beşek ji pakêta sereke ye).
- Û alîkariyên nefermî hene. Ew di belavkirina standard PostgreSQL de nabin. Divê ew an bêne berhev kirin an jî wekî pirtûkxaneyek bêne saz kirin. Vebijark dikarin pir cûda bin, li gorî ka pêşdebirê vê tevkariya nefermî çi derketiye.
Ev slide hemî wan NÎMAN û hin fonksiyonên ku di PostgreSQL 9.4 de hene pêşkêşî dike. Wekî ku em dibînin, gelek ji wan hene. Û heke hûn yekem car pê re rû bi rû bimînin pir hêsan e ku hûn tevlihev bibin.
Lêbelê, heke em wêneyê berê bigirin Как тратится время на PostgreSQL û bi vê navnîşê re hevaheng e, em vê wêneyê digirin. Em dikarin her dîtinê (VIEW) an her fonksiyonek ji bo armancek an yekê din bikar bînin da ku dema PostgreSQL dimeşîne statîstîkên têkildar bistînin. Û em jixwe dikarin di derbarê xebata jêrpergalê de hin agahdarî bistînin.
Yekem tiştê ku em ê lê binêrin ev e pg_stat_database. Wekî ku em dibînin, ev performansek e. Di wê de gelek agahî hene. Agahiyên herî cihêreng. Û ew zanyariyên pir bikêr dide tiştê ku di databasa me de diqewime.
Çi tiştên kêrhatî em dikarin ji wir bistînin? Ka em bi tiştên herî hêsan dest pê bikin.
select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;Yekem tiştê ku em dikarin lê binerin rêjeya lêdana cache ye. Rêjeya lêdana cache metrîkek kêrhatî ye. Ew dihêle hûn texmîn bikin ka çiqas dane ji cache tamponên hevpar têne girtin û çiqas ji dîskê têne xwendin.
Diyar e ku hits cache zêdetir em hene, baştir. Em vê metrikê wekî sedî dipîvin. Û, wek nimûne, heger rêjeya me ya van cache-ê ji% 90 zêdetir e, wê hingê ev baş e. Ger ew dakeve binê %90, ev tê vê wateyê ku têra bîra me tune ku em serê germ a daneyê di bîrê de bigirin. Û ji bo ku van daneyan bikar bîne, PostgreSQL neçar e ku bigihîje dîskê û ev ji ya ku dane ji bîrê were xwendin hêdîtir e. Û hûn hewce ne ku li ser zêdekirina bîranînê bifikirin: an tamponên hevpar zêde bikin, an jî bîranîna hardware (RAM) zêde bikin.
select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;Hûn dikarin çi ji vê performansê bistînin? Hûn dikarin anomaliyên ku di databasê de çêdibin bibînin. Li vir çi tê nîşandan? Lihevkirin, paşveçûn, afirandina pelên demkî, mezinahiya wan, xitimandin û nakokî hene.
Em dikarin vê daxwazê bikar bînin. Ev SQL pir hêsan e. Û em dikarin li vir li van daneyan binêrin.
Û li vir nirxên sînor hene. Em li rêjeya pabendbûn û paşveçûnê dinêrin. Commits pejirandina serketî ya danûstendinê ye. Vegerandin paşveçûnek e, ango danûstendinek hin kar kir, databasê teng kir, tiştek hesab kir, û paşê têkçûnek çêbû û encamên danûstendinê têne avêtin. Ku heye hejmara paşveçûnên ku her gav zêde dibin xirab e. Û divê hûn bi rengek ji wan dûr bixin, û kodê biguherînin da ku ev nebe.
Pevçûn bi dubarekirinê ve girêdayî ne. Û divê ji wan jî dûr bikevin. Ger hin pirsên we hene ku li ser kopiyek têne darve kirin û nakokî çêdibin, wê hingê hûn hewce ne ku van nakokiyan ji hev vekin û bibînin ka çi diqewime. Agahdariyên di têketinê de têne dîtin. Û rewşên pevçûnê ji holê rakin da ku daxwazên serîlêdanê bêyî xeletî bixebitin.
Girtî jî rewşeke xerab e. Dema ku daxwaz ji bo çavkaniyan şer dikin, daxwazek xwe gihandiye çavkaniyekê û qeflê girt, daxwazek duyemîn xwe gihandiye çavkaniya duyemîn û di heman demê de qeflê jî girt, û dûv re her du daxwaz xwe gihandin çavkaniyên hev û dema ku li bendê bûn cîranê qeflê berde. Ev jî rewşeke bi pirsgirêk e. Pêdivî ye ku ew di asta ji nû ve nivîsandina serîlêdanan û serialîzekirina gihîştina çavkaniyan de bêne çareser kirin. Û heger hûn dibînin ku xitimîna we her gav zêde dibin, hûn hewce ne ku hûn hûrguliyên di têketinê de binihêrin, rewşên ku derdikevin analîz bikin û bibînin ka pirsgirêk çi ye.
Pelên demkî (temp_files) jî xirab in. Dema ku daxwazek bikarhêner têra bîranîna xwe nebe ku daneyên xebitandinê, demkî bicîh bîne, ew pelek li ser dîskê diafirîne. Û hemî operasyonên ku ew dikaribû di nav tamponek demkî ya bîranînê de pêk bîne, li ser dîskê dest pê dike. Hêdî ye. Ev dema pêkanîna pirsê zêde dike. Û xerîdarê ku daxwazek ji PostgreSQL re şandiye dê piçek paşê bersivek bistîne. Ger van hemî operasyonan di bîranînê de bêne kirin, Postgres dê pir zûtir bersivê bide û xerîdar dê kêmtir li bendê bimîne.
Pg_stat_bgwriter - Ev nêrîn xebata du bine pergalên paşperdeya PostgreSQL diyar dike: ev checkpointer и background writer.
Pêşîn, em li xalên kontrolê, yên ku jê re tê gotin, binêrin. checkpoints. xalên kontrolê çi ne? Xalek kontrolê di têketina danûstendinê de cîhek e ku destnîşan dike ku hemî guhertinên daneya ku di têketinê de hatine tomar kirin bi serfirazî bi daneyên li ser dîskê re hatine hevdeng kirin. Pêvajo, li gorî barkêş û mîhengan ve girêdayî, dikare dirêj be û bi piranî ji hevdengkirina rûpelên qirêj ên di tamponên hevpar de bi pelên daneya li ser dîskê re pêk tê. Ji bo çi ye? Ger PostgreSQL bi berdewamî xwe bigihîne dîskê û daneyan ji wir bigire, û li ser her gihîştinê daneyan binivîsîne, dê hêdî be. Ji ber vê yekê, PostgreSQL xwedan perçeyek bîranînê ye ku mezinahiya wê bi mîhengên di veavakirinê de ve girêdayî ye. Postgres daneyên zindî di vê bîranînê de ji bo pêvajoyê an lêpirsîna paşê hilîne. Di doza daxwazên guhertina daneyê de, ew tê guhertin. Û em du guhertoyên daneyê digirin. Yek di bîra me de ye, ya din li ser dîskê ye. Û dem bi dem hûn hewce ne ku van daneyan hevdeng bikin. Pêdivî ye ku em tiştê ku di bîranînê de hatî guhertin bi dîskê re hevdeng bikin. Ji bo vê yekê hûn hewceyê nuqteyên kontrolê ne.
Xala kontrolê di nav tamponên hevpar re derbas dibe, rûpelên qirêj ên ku ew ji bo nuqteya kontrolê hewce ne destnîşan dike. Dûv re ew derbasbûnek duyemîn di nav tamponên hevbeş de dest pê dike. Û rûpelên ku ji bo xala kontrolê têne nîşankirin, ew jixwe wan hevdem dike. Bi vî awayî dane bi dîskê re hevdem dibe.
Du celeb xalên kontrolê hene. Yek nuqteya kontrolê bi demajoyê tê înfazkirin. Ev xala kontrolê kêrhatî û baş e - checkpoint_timed. Û li ser daxwazê xalên kontrolê hene - checkpoint required. Ev xala kontrolê dema ku me tomarek daneya pir mezin heye pêk tê. Me gelek têketinên danûstendinê tomar kirin. Û PostgreSQL bawer dike ku ew hewce dike ku bi lez û bez van hemîyan hevdeng bike, nuqteyek kontrolê çêbike û bimeşe.
Û eger hûn li statîstîkên xwe binêrin pg_stat_bgwriter û tiştê ku we heye dît checkpoint_req ji checkpoint_timed pir mezintir e, wê hingê ev xirab e. Çima xerab? Ev tê vê wateyê ku PostgreSQL dema ku hewce dike ku daneyan li ser dîskê binivîsîne di bin stresek domdar de ye. Nuqteya kontrolê ya demdirêj kêmtir stres e û li gorî nexşeya hundurîn tête kirin û bi demê re bi rengek belav dibe. PostgreSQL xwedan şiyana sekinandina xebatê ye û binepergala dîskê teng nake. Ev ji bo PostgreSQL bikêr e. Û pirsên ku di dema nuqteya kontrolê de têne kirin dê ji rastiya ku bine-pergala dîskê mijûl e stresê nebînin.
Û ji bo eyarkirina xala kontrolê sê parameter hene:
-
сheckpoint_segments. -
сheckpoint_timeout. -
сheckpoint_competion_target.
Ew dihêlin ku hûn xebata xalên kontrolê birêkûpêk bikin. Lê ez ê li ser wan nesekinim. Bandora wan mijareke cuda ye.
Şaş Guhertoya 9.4 ya ku di raporê de hatî nîqaş kirin êdî ne têkildar e. Di guhertoyên nûjen ên PostgreSQL de parametre checkpoint_segments li şûna parametre min_wal_size и max_wal_size.
Binepergala paşîn nivîskarê paşerojê ye - background writer. Ew çi dike? Ew bi berdewamî di xelekek bêdawî de dimeşe. Rûpelên di tamponên hevpar de dişoxilîne û rûpelên qirêj ên ku dibîne li dîskê davêje. Bi vî rengî, ew ji nuqteya kontrolê re dibe alîkar ku di dema darvekirina xala kontrolê de kêmtir kar bike.
Wekî din ji bo çi hewce ye? Ger ew ji nişkê ve (bi mîqdarên mezin û tavilê) hewce bibin ku daneyan bi cih bikin, ew hewcedariya rûpelên vala di tamponên hevpar de peyda dike. Bifikirin ku rewşek derket holê dema ku rûpelên vala ji bo temamkirina daxwazek hewce bû û ew jixwe di tamponên hevpar de bûn. Postgresive backend tenê wan hildide û bi kar tîne, ne hewce ye ku bi xwe tiştekî paqij bike. Lê heke ji nişka ve rûpelên weha tunebin, paşperdeya paşîn xebatê disekine û dest bi lêgerîna rûpelan dike da ku wan biavêje ser dîskê û wan ji bo hewcedariyên xwe bigire - ku ev yek bandorek neyînî li ser dema daxwaziya ku niha pêk tê dike. Ger hûn bibînin ku we pîvanek heye maxwritten_clean mezin, ev tê vê wateyê ku nivîskarê paşîn karê xwe nake û hûn hewce ne ku pîvanan zêde bikin bgwriter_lru_maxpages, da ku ew di yek çerxê de bêtir kar bike, bêtir rûpelan paqij bike.
Û nîşanek din a pir bikêr e buffers_backend_fsync. Backends fsync nakin ji ber ku ew hêdî ye. Ew fsync-ê xala kontrolê ya stackê ya IO derbas dikin. Noqteya kontrolê rêza xwe heye, ew dem bi dem fsyncê pêvajoyê dike û rûpelên di bîranînê de bi pelên li ser dîskê re hevdeng dike. Ger dorê li nuqteya kontrolê mezin û tije be, wê gavê paşverû neçar dibe ku xwe fsync bike û ev yek karê paşînê hêdî dike., ango xerîdar dê ji ya ku dikaribû dereng bersivek werbigire. Ger hûn dibînin ku nirxa we ji sifirê mezintir e, wê hingê ev jixwe pirsgirêkek e û Pêdivî ye ku hûn bala xwe bidin mîhengên nivîskarê paşîn û performansa binpergala dîskê jî binirxînin.
Şaş _Nivîsa jêrîn nêrînên statîstîkî yên ku bi dubarekirinê ve girêdayî ne diyar dike. Piraniya navên dîtin û fonksiyonan di Postgres 10 de hatin guheztin. Esasê veguheztinê ew bû ku li şûna xlog li ser wal и location li ser lsn di navên fonksiyon / dîtinê de, hwd. Mînakek taybetî, fonksiyon pg_xlog_location_diff() hate binavkirin pg_wal_lsn_diff()._
Li vir jî gelek tiştên me hene. Lê em tenê tiştên girêdayî cîhê hewce ne.
Ger em dibînin ku hemî nirx wekhev in, wê hingê ev vebijarkek îdeal e û kopiyek li paş masterê namîne.
Ev pozîsyona hexadecimal li vir pozîsyona di têketina danûstendinê de ye. Ger di databasê de çalakiyek hebe ew bi domdarî zêde dibe: têxe, jêbirin, hwd.
сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());Ger ev tişt ji hev cuda bin, hingî hindek derengmayîn heye. Lag derengiya di navbera replica û masterê de ye, ango daneyên di navbera serveran de cûda dibe.
Sê sedemên kêmbûnê hene:
- Ev binepergala dîskê nikare bi hevdemkirina pelê tomarkirinê re mijûl bibe.
- Vana xeletiyên torê yên mimkun in, an zêdebarkirina torê ne, dema ku dane wext tune ku bigihîje replikayê û ew nikare wê dubare bike.
- Û pêvajoyê. Prosesor bûyerek pir kêm e. Û min ev du sê caran dît, lê ev jî dikare bibe.
Û li vir sê pirs hene ku destûrê didin me ku em statîstîk bikar bînin. Em dikarin texmîn bikin ka me çiqas di têketina danûstendinê de tomar kiriye. Fonksiyonek wisa heye pg_xlog_location_diff û em dikarin derengiya dubarekirinê di byte û çirkeyan de texmîn bikin. Em ji bo vê yekê jî nirxa ji vê dîtinê (DÎMEN) bikar tînin.
Têbînî: _Li şûna pg_xlog_locationFonksîyona diff() dikare operatorê jêbirinê bikar bîne û cîhek ji cîhek din jê bike. Rehet.
Yek xalek bi derengiyê heye, ku di saniyeyan de ye. Ger li ser masterê çalakî tunebe, danûstendin 15 hûrdem berê li wir bû û çalakiyek tune, û heke em li vê derengiya li ser replikayê binêrin, em ê derengiya 15 hûrdeman bibînin. Ev hêjayî bîranînê ye. Û dema ku hûn li vê derengiyê temaşe dikin ev dikare tevlihev be.
Pg_stat_all_tables nêrînek din a kêrhatî ye. Ew statîstîkên li ser tabloyan nîşan dide. Dema ku di databasê de tabloyên me hebin, hin çalakî pê re hebin, hin kiryar hebin, em dikarin ji vê dîtinê van agahiyan bigirin.
select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;Yekem tiştê ku em dikarin lê binihêrin şaneyên rêzdar ên li seranserê tabloyê ye. Hejmar bi xwe piştî van derbasbûnê ne hewce ye ku ne xirab e û ne nîşanek e ku pêdivî ye ku em tiştek bikin.
Lêbelê, metrîka duyemîn heye - seq_tup_read. Ev hejmara rêzên ku ji şopandina rêzdar vegerî ye. Ger jimareya navîn ji 1, 000, 10, 000 derbas bibe, wê hingê ev jixwe nîşanek e ku dibe ku hûn hewce ne ku li cîhek navnîşek ava bikin da ku pirs li ser bingeha îndeksê bin, an jî mimkun e ku pirsên ku bi vî rengî şopandinên rêzdar bikar tînin xweş bikin. ku ev yek çênebe bû.
Mînakek hêsan - em bibêjin daxwazek bi lêçûnek mezin OFFSET û LIMIT. Mînakî, di tabloyekê de 100 rêz têne şelandin û piştî wê 000 rêzên pêwîst têne girtin, û rêzikên berê yên hatine şopandin têne avêtin. Ev jî rewşeke xerab e. Û pirsên weha hewce ne ku bêne xweşbîn kirin. Û li vir pirsek SQL-ya hêsan heye ku hûn dikarin li vê binêrin û hejmarên encam binirxînin.
select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;Mezinahiyên tabloyê jî bi karanîna vê tabloyê û bi karanîna fonksiyonên zêde têne wergirtin pg_total_relation_size(), pg_relation_size().
Bi gelemperî, metaferman hene dt и di, ku dikare di PSQL-ê de were bikar anîn û her weha mezinahiyên tablo û navnîşan jî bibîne.
Lêbelê, karanîna fonksiyonan ji me re dibe alîkar ku em li mezinahiya tabloyan binihêrin, tewra bi îndeksan re, an jî bêyî hesabkirina nîşanan, û berê xwe bidin hin texmînan li ser bingeha mezinbûna databasê, ango ew çawa mezin dibe, bi çi tundî, û di derbarê xweşbînkirina mezinbûnê de hin encaman derxînin.
Çalakiya tomarkirinê. Tomar çi ye? Ka em li operasyonê binêrin UPDATE - operasyona nûvekirina rêzan di tabloyê de. Bi rastî, nûvekirin du operasyon e (an hêj bêtir). Ev guhertoyek nû ya rêzê têxe nav rêzê û guhertoya rêzê ya kevn wekî kevin nîşan dide. Dûv re, otovacuum dê were û van guhertoyên kevnar ên rêzan paqij bike, vê cîhê wekî ji bo ji nû ve karanîna berdest nîşan bide.
Wekî din, nûvekirin ne tenê nûvekirina tabloyek e. Ev jî nûvekirinek index e. Ger li ser sifrê gelek indexên we hebin, wê hingê di dema nûvekirinê de hemî navnîşên ku zeviyên ku di pirsnameyê de hatine nûve kirin jî vedihewînin jî dê bêne nûve kirin. Dê di van navnîşan de guhertoyên kevin ên rêzan jî hebin ku dê bêne paqij kirin.
select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;Û ji ber sêwirana wê ya nû, UPDATE operasyonek giran e. Lê ew dikarin hêsantir bibin. Xwarin hot updates. Ew di guhertoya PostgreSQL 8.3 de xuya bûn. Û ev çi ye? Ev nûvekirinek sivik e ku nahêle ku pêdekek ji nû ve were çêkirin. Ango, me tomar nû kir, lê tenê qeyda di rûpelê de (ku girêdayî tabloyê ye) hate nûve kirin, û îndeks hîn jî heman tomarê di rûpelê de destnîşan dikin. Piçek mantiqek xebitandinê ya balkêş heye: dema valahiyek tê, ew van zincîran diafirîne hot ji nû ve ava dike û her tişt bêyî nûvekirina navnîşan xebata xwe didomîne, û her tişt bi kêm windakirina çavkaniyan diqewime.
Û kengê hûn n_tup_hot_upd mezin, hingê ew pir baş e. Ev tê vê wateyê ku nûvekirinên sivik serdest in û ev ji hêla çavkaniyan ve ji me re erzantir e û her tişt baş e.
ALTER TABLE table_name SET (fillfactor = 70);Meriv çawa voluman zêde dike hot updateov? Em dikarin bikar bînin fillfactor. Dema ku rûpelek di tabloyekê de bi karanîna INSERT-an dagirtin mezinahiya cîhê belaş a veqetandî diyar dike. Dema ku têkel li tabloyek têne zêdekirin, ew rûpelê bi tevahî tije dikin û cîhek vala nahêlin. Piştre rûpelek nû tê ronî kirin. Daneyên dîsa tê dagirtin. Û ev tevgera xwerû ye, dagirtina faktor = 100%.
Em dikarin dagirtina faktora 70% bikin. Ango, di dema têketinê de, rûpelek nû hate ronî kirin, lê tenê% 70 ji rûpelê hate dagirtin. Û 30% ji me re wekî rezervê maye. Gava ku hûn hewce ne ku nûvekirinek çêbikin, ew ê bi îhtîmalek mezin di heman rûpelê de çêbibe, û guhertoya nû ya rêzê dê di heman rûpelê de cîh bigire. Û hot_update dê were kirin. Ev yek nivîsandina li ser maseyan hêsantir dike.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));Dora Autovacuum. Autovacuum binepergalek e ku di PostgreSQL de statîstîkên wê pir hindik in. Em tenê dikarin di tabloyên di pg_stat_activity de bibînin ka niha çend valahiyên me hene. Lêbelê, pir dijwar e ku meriv di cih de fêm bike ka çend tablo di rêzê de ne.
Têbînî: _Ji Postgres 10-ê dest pê kir, rewşa şopandina Vatovac pir baştir bûye - dîtina pg_stat_progress xuya bûvalahiya, ku bi girîngî mijara şopandina valahiya gerîdeyê hêsan dike.
Em dikarin vê pirsê sadekirî bikar bînin. Û em dikarin bibînin ka dê kengê valahî were çêkirin. Lê divê valahiya çawa û kengê dest pê bike? Ev guhertoyên mîras ên rêzikên ku min berê behs dikir ev in. Nûvekirin çêbû, guhertoyek nû ya rêzê hate danîn. Guhertoyek kevnar a rêzê derketiye. Di sifrê de pg_stat_user_tables parametreyek wisa heye n_dead_tup. Ew hejmara xetên "mirî" nîşan dide. Û gava ku hejmara rêzên mirî ji bendek diyarkirî mezintir bibe, dê otovacuumek were ser maseyê.
Û ev bend çawa tê hesibandin? Ev rêjeyek pir taybetî ya jimara giştî ya rêzikên di tabloyê de ye. Parametreyek heye autovacuum_vacuum_scale_factor. Ew ji sedî diyar dike. Em bibêjin 10% + 50 xêzek bendek bingehîn a zêde heye. Û çi dibe? Gava ku em ji "10% + 50" ji hemî rêzên di tabloyê de bêtir rêzên mirî hebin, wê hingê em tabloyê datînin ser otovacuumê.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));Lêbelê, xalek heye. Bendavên bingehîn ji bo parametreyan av_base_thresh и av_scale_factor dikare bi ferdî were destnîşankirin. Û, li gorî vê, bend dê ji bo sifrê ne gerdûnî be, lê ferdî be. Ji ber vê yekê, ji bo hesabkirinê, hûn hewce ne ku hûn hîle û hîleyan bikar bînin. Û heke hûn eleqedar in, wê hingê hûn dikarin li ezmûna hevkarên me yên Avito binêrin (girêdana li ser slidê nederbasdar e û di nivîsê de hatî nûve kirin).
Wan ji bo nivîsand , ku van tiştan li ber çavan digire. Li wê derê lingê du pelan heye. Lê ew rast hesab dike û pir bi bandor rê dide me ku em binirxînin li ku derê ji bo tabloyên ku lê hindik e ji me re pir valahiya hewce ne.
Em dikarin çi bikin? Ger dorek me ya mezin hebe û otovakûm nikaribe bi ser keve, wê hingê em dikarin hejmara xebatkarên valahiya zêde bikin, an jî bi tenê valahiya hovtir bikin., da ku ew berê dest pê bike, sifrê di perçeyên piçûk de pêvajoyê dike. Û bi vî awayî rêz dê kêm bibe. - Ya sereke li vir çavdêriya barkirina li ser dîskan e, ji ber ku ... valahiya ne tiştek belaş e, her çend bi hatina cîhazên SSD/NVMe re pirsgirêk kêm xuya bûye.
Pg_stat_all_indexes statîstîkên li ser indexan e. Ew ne mezin e. Û em dikarin wê bikar bînin ku agahdariya li ser karanîna navnîşan bistînin. Û wek nimûne, em dikarin diyar bikin ka kîjan indexên me yên zêde hene.
Wekî ku min berê jî got, nûvekirin ne tenê nûvekirina tabloyan e, di heman demê de nûvekirina indexan e jî. Li gorî vê yekê, heke li ser tabloyê gelek îndeksên me hebin, wê hingê dema ku rêzikên di tabloyê de têne nûve kirin, pêdivî ye ku îndeksên qadên pêvekirî jî bêne nûve kirin, û heke me îndeksên ku nehatine bikar anîn hebin ku ji bo wan îşaretên îndeksê tune ne, wê hingê ew wekî balast têne daliqandin. Û divê em ji wan xilas bibin. Ji bo vê jî qada me lazim e idx_scan. Em bi tenê li hejmara şaneyên îndeksê dinêrin. Ger navnîşan di heyamek dirêj a hilanîna statîstîkê de (kêmtirîn 2-3 hefte) şaneyên sifir hebin, wê hingê bi îhtîmalek mezin ev indexên xirab in, divê em ji wan xilas bibin.
Têbînî: Dema ku di doza komikên replikasyonê yên rijandinê de li indexên nebikaranîn digerin, hûn hewce ne ku hemî girêkên komê kontrol bikin, ji ber ku statîstîk ne gerdûnî ne, û heke index li ser masterê neyê bikar anîn, wê hingê ew dikare li ser kopiyan were bikar anîn (heke li wir barek hebe).
Du girêdan:
Vana mînakên lêpirsînê yên pêşkeftî ne li ser meriv çawa li navnîşên nekaranîn digerin.
Girêdana duyemîn daxwazek balkêş e. Li wir mantiqeke pir ne-pîvan heye. Ez wê ji bo referansê pêşniyar dikim.
Ya din çi hêja ye ku meriv bi karanîna nîşanan berhev bike?
-
Indeksên ku nehatine bikaranîn xirab in.
-
Ew cih digirin.
-
Operasyonên nûvekirinê hêdî bikin.
-
Karê zêde ji bo valahiya.
Ger em navnîşên neyên bikar anîn rakin, em ê tenê databasê çêtir bikin.
Pêşkêşiya paşîn e pg_stat_activity. Ev analogek karûbar e ps, tenê di PostgreSQL de. Ger ps'Om hûn li pêvajoyên di pergala xebitandinê de binêrin, wê hingê pg_stat_activity Ew ê çalakiya hundurê PostgreSQL nîşanî we bide.
Çi tiştên kêrhatî em dikarin ji wir bistînin?
select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;Em dikarin çalakiya gelemperî bibînin, ka di databasê de çi diqewime. Em dikarin bişaftina nû bikin. Li vir her tişt teqiyaye, girêdanên nû nayên pejirandin, xeletî di serîlêdanê de diherike.
select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;Em dikarin pirsek bi vî rengî bimeşînin û rêjeya giştî ya girêdanan li gorî sînorê herî zêde yê girêdanê bibînin û bibînin ka kê herî zêde girêdan heye. Û di vê rewşê de em wê bikarhênerê dibînin cron_role 508 girêdan vekirin. Û li wir tiştek hat serê wî. Divê em pê re mijûl bibin û lê binêrin. Û pir mimkun e ku ev celebek hejmarek anormal a girêdanê ye.
Ger bargiraniyek me ya OLTP hebe, divê pirs zû, pir bilez bin û pirsên dirêj nebin. Lêbelê, heke pirsên dirêj çêbibin, wê hingê di demek kurt de tiştek ku meriv pê xemgîn bibe tune, lê Di demek dirêj de, pirsên dirêj zirarê didin databasê; gava ku perçebûna tabloyê çêdibe, ew bandora blota tabloyan zêde dikin. Pêdivî ye ku hûn hem ji qulp û hem jî ji pirsên dirêj xilas bibin.
select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;Ji kerema xwe not: bi vê daxwazê em dikarin pirs û danûstandinên dirêj nas bikin. Em fonksiyonê bikar tînin clock_timestamp() ji bo destnîşankirina dema xebatê. Pirsên dirêj ên ku me dîtin, em dikarin wan bi bîr bînin, wan pêk bînin explain, li planan binihêrin û bi rengek xweşbîn bikin. Em daxwazên dirêj ên heyî radikin û jiyana xwe dimeşînin.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';Danûstandinên xirab kirinên di halên danûstendinê de yên bêkar û di dewletên danûstendinê yên bêkar de (berbiçav) de ne.
Poldayî? Danûstandinên gelek dewletan hene. Û yek ji van dewletan di her kêliyê de dikare were hesibandin. Qadeke diyarkirina dewletan heye state di vê pêşkêşiyê de. Û em ji bo diyarkirina dewletê bi kar tînin.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';Û, wek ku min li jor jî got, ev her du dewlet betal di danûstandinê de û bêkar di danûstandinê de (berbiçav) xirab in. Ew çi ye? Ev gava ku serîlêdanê danûstendinek vekir, hin kiryar kir û çû ser karê xwe. Danûstandin vekirî dimîne. Ew daleqandî ye, tiştek tê de çênabe, ji ber mîmariya motora danûstendinê ya Postrges, ew pêwendiyê digire, li ser rêzên guhezbar kilît dike û potansiyel behna tabloyên din zêde dike. Û danûstendinên weha jî divê werin avêtin, ji ber ku ew bi gelemperî di her rewşê de zirarê ne.
Ger hûn dibînin ku di databasa we de ji 5-10-20 zêdetir ji wan hene, wê hingê hûn hewce ne ku bitirsin û bi wan re tiştek bikin.
Li vir em ji bo dema hesabkirinê jî bikar tînin clock_timestamp(). Em danûstendinan diavêjin û serîlêdanê xweştir dikin.
Wekî ku min li jor got, astengkirin dema ku du an bêtir danûstendin ji bo yek an komek çavkaniyan şer dikin. Ji bo vê qada me heye waiting bi nirxa boolean true an false.
Rast - ev tê vê wateyê ku pêvajo li bendê ye, divê tiştek were kirin. Dema ku pêvajoyek li bendê ye, ev tê vê wateyê ku xerîdarê ku vê pêvajoyê daye destpêkirin jî li bendê ye. Xerîdar di gerokê de rûniştiye û di heman demê de li bendê ye.
Şaş _Ji qada Postgres guhertoya 9.6 dest pê dike waiting rakirin û li şûna wê du qadên din ên agahdar lê zêde kirin wait_event_type и wait_event._
Ez çi bikim? Ger hûn ji bo demek dirêj rast dibînin, ev tê vê wateyê ku hûn hewce ne ku ji daxwazên weha xilas bibin. Em tenê danûstendinên bi vî rengî hilweşînin. Em ji pêşdebiran re dinivîsin ku ew hewce ne ku bi rengek xweş bikin da ku ji bo çavkaniyan pêşbaziyek tune. Û dûv re pêşdebir serîlêdanê xweşbîn dikin da ku ev nebe.
Û doza tund, lê potansiyel ne-kujer e rûdana xitimiyan. Du danûstendinan du çavkaniyan nûve kirin, dûv re dîsa gihîştin wan, vê carê çavkaniyên dijber. Di vê rewşê de, PostgreSQL danûstendinê bixwe dikuje da ku yekî din karibe xebata xwe bidomîne. Ev rewşek xitimî ye û ew bi serê xwe nikare jê derbikeve. Ji ber vê yekê, PostgreSQL neçar e ku tedbîrên tund bigire.
Û li vir du pirs hene ku dihêle hûn astengkirinê bişopînin. Em dîtinê bikar tînin pg_locks, ku destûrê dide te ku hûn kilîdên giran bişopînin.
Û girêdana yekem nivîsa daxwazê bixwe ye. Ew pir dirêj e.
Û lînka duyemîn gotarek li ser qefleyan e. Ji bo xwendinê kêrhatî ye, pir balkêş e.
Ji ber vê yekê em çi dibînin? Em du daxwazan dibînin. Transaction bi ALTER TABLE danûstendineke astengkirinê ye. Dest pê kir, lê neqediya, û serîlêdana ku ev danûstendin tomar kir li cîhek tiştên din dike. Û daxwaza duyemîn nûvekirin e. Ew li bendê ye ku maseya alter biqede berî ku ew karibe karê xwe bidomîne.
Bi vî rengî em dikarin fêr bibin ka kê kê kilît kiriye, kê digire û em dikarin hîn bêtir pê re mijûl bibin.
Modula din e pg_stat_statements. Wekî ku min got, ev modulek e. Ji bo ku hûn bikar bînin, hûn hewce ne ku pirtûkxaneya wê di veavakirinê de bar bikin, PostgreSQL ji nû ve bidin destpêkirin, modulê (bi yek fermanê) saz bikin û dûv re em ê dîmenek nû hebin.
Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;
Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;Em dikarin çi ji wir bistînin? Ger em li ser tiştên hêsan biaxivin, em dikarin dema darvekirina pirsê ya navîn bigirin. Dem mezin dibe, ku tê vê wateyê ku PostgreSQL hêdî hêdî bersivê dide û pêdivî ye ku em tiştek bikin.
Em dikarin li danûstendinên nivîsandinê yên herî çalak ên di databasê de ku daneyan di tamponên hevpar de diguhezînin binihêrin. Binêrin ka kî li wir daneyan nûve dike an jê dike.
Û em dikarin tenê ji bo van daxwazan li statîstîkên cihêreng binêrin.
Em in pg_stat_statements Em wê ji bo çêkirina raporan bikar tînin. Em rojê carekê îstatîstîkê vedikin. Werin em wê berhev bikin. Berî ku carek din statîstîkê ji nû ve saz bikin, werin em raporek çêbikin. Li vir lînka raporê heye. Hûn dikarin lê temaşe bikin.
Em çi dikin? Em ji bo hemî daxwazan statîstîkên gelemperî hesab dikin. Dûv re, ji bo her daxwazek, em beşdariya wê ya kesane ji van statîstîkên giştî re hesab dikin.
Û em dikarin çi temaşe bikin? Em dikarin li tevahiya dema pêkanîna hemî daxwazên celebek taybetî li hember paşxaneya hemî daxwazên din binêrin. Em dikarin li karanîna çavkaniya CPU û I/O li gorî wêneya giştî binêrin. Û jixwe van pirsan xweşbîn bikin. Em li ser bingeha vê raporê pirsên sereke ava dikin û jixwe ji bo ramanê xwarinê distînin ka çi xweşbîn bikin.
Me li pişt perdeyê çi hiştiye? Hîn çend pêşkêşî mane ku min guh nedaye wan ji ber ku dem kêm e.
Ð • n, Nûh * de pgstattuple di heman demê de modulek zêde ye ji pakêta tevkariyên standard. Ew dihêle hûn binirxînin bloat maseyên, bi navê perçebûna sifrê. Û heke pir perçebûn hebe, hûn hewce ne ku wê jêbirin û amûrên cûda bikar bînin. Û fonksiyonê pgstattuple demeke dirêj dixebite. Û çiqas bêtir tablo hene, ew ê dirêjtir bixebite.
Alîkariya din ev e pg_buffercache. Ew dihêle hûn tamponên hevpar teftîş bikin: rûpelên tamponê çiqasî bi giranî û ji bo kîjan tabloyan têne bikar anîn. Û ew bi tenê dihêle hûn li tamponên hevpar binihêrin û tiştê ku li wir diqewime binirxînin.
Modula din e pgfincore. Ew bi bangek pergalê destûrê dide operasyonên tabloya asta nizm mincore(), ango destûrê dide te ku hûn tabloyek li tamponên hevpar bar bikin, an jî jê bar bikin. Û ew dihêle, di nav tiştên din de, kaşê rûpela pergala xebitandinê venêre, ango, tablo çiqas cîh di cacheya rûpelê de, di tamponên hevpar de digire, û bi tenê dihêle ku em barê xebata tabloyê binirxînin.
Modula paşîn - pg_stat_kcache. Ew jî bangek pergalê bikar tîne getrusage(). Û ew berî û piştî ku daxwaz tê îdam kirin, wê dike. Û di statîstîkên encam de, ew dihêle ku em texmîn bikin ka çiqas daxwaza me li ser I/O dîskê xerc kiriye, ango operasyonên bi pergala pelan re û li karanîna pêvajoyê dinêre. Lêbelê, modul ciwan e (kuxikê) û ji bo xebitandina wê PostgreSQL 9.4 û pg_stat_statements, ku min berê behs kiribû, hewce dike.
-
Dizanin ka meriv çawa statîstîk bikar tîne kêrhatî ye. Hûn ne hewce ne bernameyên partiya sêyemîn. Hûn dikarin werin hundur, bibînin, tiştek bikin, tiştek pêk bînin.
-
Bikaranîna statîstîkan ne dijwar e, ew tenê SQL-ya birêkûpêk e. Te daxwaz berhev kir, berhev kir, şand, lê nihêrî.
-
Statîstîk alîkariya bersiva pirsan dikin. Ger pirsên we hebin, hûn berê xwe didin statîstîkê - binihêrin, encaman derxînin, encaman analîz bikin.
-
Û ceribandin. Gelek daxwaz hene, gelek dane hene. Hûn dikarin her gav pirsek heyî xweşbîn bikin. Hûn dikarin guhertoya xweya daxwazê ya ku ji orîjînalê bêtir li gorî we ye çêbikin û wê bikar bînin.
references
Girêdanên guncan ên ku di gotarê de hatine dîtin, li ser bingeha materyalan, di raporê de bûn.
Nivîskar bêtir dinivîse
(eng)
The Statistics Collector
Fonksiyonên Rêveberiya Sîstemê
Modulên tevkariyê bikin
Bikaranîna SQL û nimûneyên koda sql
Spas ji bo bala we hemûyan!
Source: www.habr.com