🥇 Plymiwch yn ddwfn i ystadegau mewnol PostgreSQL. Alexey Lesovsky

Trawsgrifiad o adroddiad 2015 gan Alexey Lesovsky "Plymio'n ddwfn i ystadegau mewnol PostgreSQL"

Ymwadiad gan awdur yr adroddiad: Sylwaf fod yr adroddiad hwn yn ddyddiedig Tachwedd 2015 - mae mwy na 4 blynedd wedi mynd heibio ac mae llawer o amser wedi mynd heibio. Nid yw fersiwn 9.4 a drafodir yn yr adroddiad yn cael ei chefnogi mwyach. Dros y 4 blynedd diwethaf, mae 5 datganiad newydd wedi'u rhyddhau lle mae llawer o ddatblygiadau arloesol, gwelliannau a newidiadau o ran ystadegau wedi ymddangos, ac mae peth o'r deunydd yn hen ffasiwn ac nid yw'n berthnasol. Wrth i mi adolygu, ceisiais nodi'r lleoedd hyn er mwyn peidio â'ch camarwain y darllenydd. Ni wnes i ailysgrifennu'r lleoedd hyn, mae yna lawer ohonyn nhw, ac o ganlyniad, bydd adroddiad hollol wahanol yn dod allan.

Mae'r DBMS PostgreSQL yn fecanwaith enfawr, ac mae'r mecanwaith hwn yn cynnwys llawer o is-systemau, y mae eu gwaith cydgysylltiedig yn effeithio'n uniongyrchol ar berfformiad y DBMS. Yn ystod y llawdriniaeth, cesglir ystadegau a gwybodaeth am weithrediad cydrannau, sy'n eich galluogi i werthuso effeithiolrwydd PostgreSQL a chymryd mesurau i wella perfformiad. Fodd bynnag, mae llawer o'r wybodaeth hon ac fe'i cyflwynir ar ffurf eithaf syml. Weithiau mae prosesu'r wybodaeth hon a'i dehongli yn dasg gwbl ddibwys, a gall y "sŵ" o offer a chyfleustodau ddrysu hyd yn oed DBA datblygedig.

Prynhawn Da Fy enw i yw Aleksey. Fel y dywedodd Ilya, siaradaf am ystadegau PostgreSQL.

Ystadegau gweithgaredd PostgreSQL. Mae gan PostgreSQL ddau ystadegau. Ystadegau gweithgaredd, a fydd yn cael eu trafod. Ac ystadegau amserlennydd am ddosbarthu data. Siaradaf yn benodol am ystadegau gweithgarwch PostgreSQL, sy’n caniatáu inni farnu perfformiad a’i wella rywsut.

Dywedaf wrthych sut i ddefnyddio ystadegau yn effeithiol i ddatrys amrywiaeth o broblemau sydd gennych neu a allai fod gennych.

Beth na fydd yn yr adroddiad? Yn yr adroddiad, ni fyddaf yn cyffwrdd ag ystadegau'r amserlennydd, oherwydd. mae hwn yn bwnc ar wahân ar gyfer adroddiad ar wahân ar sut mae data'n cael ei storio yn y gronfa ddata a sut mae'r cynllunydd ymholiad yn cael syniad o nodweddion ansoddol a meintiol y data hwn.

Ac ni fydd unrhyw adolygiadau offer, ni fyddaf yn cymharu un cynnyrch ag un arall. Ni fydd unrhyw hysbysebu. Gadewch i ni ei ollwng.

Rwyf am ddangos i chi fod defnyddio ystadegau yn ddefnyddiol. Mae'n angenrheidiol. Defnyddiwch ef yn ddi-ofn. Y cyfan sydd ei angen arnom yw SQL plaen a gwybodaeth sylfaenol am SQL.

A byddwn yn siarad am ba ystadegau i'w dewis i ddatrys problemau.

Os edrychwn ar PostgreSQL a rhedeg gorchymyn ar y system weithredu i weld y prosesau, fe welwn "blwch du". Byddwn yn gweld rhai prosesau sy'n gwneud rhywbeth, ac yn ôl enw gallwn ddychmygu'n fras yr hyn y maent yn ei wneud yno, yr hyn y maent yn ei wneud. Ond, mewn gwirionedd, blwch du yw hwn, ni allwn edrych y tu mewn.

Gallwn edrych ar y llwyth CPU i mewn top, gallwn weld y defnydd cof gan rai cyfleustodau system, ond ni fyddwn yn gallu edrych y tu mewn i PostgreSQL. Ar gyfer hyn mae angen offer eraill arnom.

Ac yn parhau ymhellach, dywedaf wrthych ymhle y treulir yr amser. Os byddwn yn cynrychioli PostgreSQL ar ffurf cynllun o'r fath, yna bydd modd ateb lle treulir yr amser. Mae'r rhain yn ddau beth: prosesu ceisiadau cleientiaid o geisiadau a'r tasgau cefndir y mae PostgreSQL yn eu cyflawni i'w gadw i redeg.

Os byddwn yn dechrau edrych ar y gornel chwith uchaf, gallwn weld sut mae ceisiadau cleientiaid yn cael eu prosesu. Daw'r cais o'r cais ac agorir sesiwn cleient ar gyfer gwaith pellach. Trosglwyddir y cais i'r trefnydd. Mae'r cynlluniwr yn adeiladu cynllun ymholiad. Yn ei anfon ymhellach i'w ddienyddio. Mae rhyw fath o ddata bloc I / O yn gysylltiedig â thablau a mynegeion. Darllenir y data angenrheidiol o ddisgiau i'r cof mewn ardal arbennig o'r enw "byfferau a rennir". Mae canlyniadau'r ymholiad, os ydynt yn ddiweddariadau, yn dileu, yn cael eu cofnodi yn y log trafodion yn WAL. Mae peth gwybodaeth ystadegol yn mynd i mewn i'r log neu'r casglwr ystadegau. Ac mae canlyniad y cais yn cael ei roi yn ôl i'r cleient. Ar ôl hynny, gall y cleient ailadrodd popeth gyda chais newydd.

Beth sydd gennym gyda thasgau cefndir a phrosesau cefndirol? Mae gennym nifer o brosesau sy'n cadw'r gronfa ddata ar waith mewn modd gweithredu arferol. Ymdrinnir â'r prosesau hyn yn yr adroddiad hefyd: sef autovacuum, checkpointer, prosesau sy'n ymwneud ag atgynhyrchu, ysgrifennwr cefndir. Byddaf yn cyffwrdd â phob un ohonynt wrth i mi adrodd.

Beth yw'r problemau gydag ystadegau?

Llawer o wybodaeth. Mae PostgreSQL 9.4 yn darparu 109 metrig ar gyfer gweld data ystadegau. Fodd bynnag, os yw'r gronfa ddata yn storio llawer o dablau, sgemâu, cronfeydd data, yna bydd yn rhaid lluosi'r holl fetrigau hyn â'r nifer cyfatebol o dablau, cronfeydd data. Hynny yw, mae hyd yn oed mwy o wybodaeth. Ac mae'n hawdd iawn boddi ynddo.
Y broblem nesaf yw bod ystadegau'n cael eu cynrychioli gan gownteri. Os edrychwn ar yr ystadegau hyn, fe welwn nifer gynyddol o gownteri. Ac os oes llawer o amser wedi mynd heibio ers ailosod yr ystadegau, fe welwn ni biliynau o werthoedd. Ac nid ydynt yn dweud dim wrthym.
Nid oes hanes. Os oes gennych ryw fath o fethiant, syrthiodd rhywbeth 15-30 munud yn ôl, ni fyddwch yn gallu defnyddio’r ystadegau a gweld beth ddigwyddodd 15-30 munud yn ôl. Mae hyn yn broblem.
Mae diffyg offeryn wedi'i ymgorffori yn PostgreSQL yn broblem. Nid yw'r datblygwyr cnewyllyn yn darparu unrhyw ddefnyddioldeb. Nid oes ganddynt unrhyw beth felly. Maent yn rhoi ystadegau yn y gronfa ddata yn unig. Defnyddiwch ef, gwnewch gais iddo, beth bynnag y dymunwch, yna gwnewch hynny.
Gan nad oes offeryn wedi'i ymgorffori yn PostgreSQL, mae hyn yn achosi problem arall. Llawer o offer trydydd parti. Mae pob cwmni sydd â dwylo mwy neu lai uniongyrchol yn ceisio ysgrifennu ei raglen ei hun. Ac o ganlyniad, mae gan y gymuned lawer o offer y gallwch eu defnyddio i weithio gydag ystadegau. Ac mewn rhai offer mae rhai nodweddion, mewn offer eraill nid oes unrhyw nodweddion eraill, neu mae rhai nodweddion newydd. Ac mae sefyllfa'n codi bod angen i chi ddefnyddio dau neu dri neu bedwar offer sy'n gorgyffwrdd â'i gilydd ac sydd â swyddogaethau gwahanol. Mae hyn yn annifyr iawn.

Beth sy'n dilyn o hyn? Mae'n bwysig gallu cymryd ystadegau'n uniongyrchol er mwyn peidio â dibynnu ar raglenni, neu wella'r rhaglenni hyn eich hun rywsut: ychwanegwch rai swyddogaethau i gael eich budd-dal.

Ac mae angen gwybodaeth sylfaenol arnoch chi am SQL. I gael rhywfaint o ddata o ystadegau, mae angen i chi wneud ymholiadau SQL, h.y. mae angen i chi wybod sut y gwneir dewis, ymuno.

Mae ystadegau yn dweud sawl peth wrthym. Gellir eu rhannu'n gategorïau.

Y categori cyntaf yw'r digwyddiadau sy'n cael eu cynnal yn y gronfa ddata. Dyma pryd mae rhyw ddigwyddiad yn digwydd yn y gronfa ddata: mae ymholiad, mynediad bwrdd, autovacuum, yn ymrwymo, yna mae'r rhain i gyd yn ddigwyddiadau. Cynyddir y cownteri sy'n cyfateb i'r digwyddiadau hyn. A gallwn olrhain y digwyddiadau hyn.
Yr ail gategori yw priodweddau gwrthrychau megis tablau, cronfeydd data. Mae ganddynt eiddo. Dyma faint y byrddau. Gallwn olrhain twf tablau, twf mynegeion. Gallwn weld newidiadau mewn dynameg.
A'r trydydd categori yw'r amser a dreulir ar y digwyddiad. Mae cais yn ddigwyddiad. Mae ganddo ei fesur hyd penodol ei hun. Dechreuwyd yma, diweddodd yma. Gallwn ei olrhain. Naill ai amser darllen bloc o ddisg neu ysgrifennu. Mae'r pethau hyn hefyd yn cael eu holrhain.

Cyflwynir ffynonellau ystadegau fel a ganlyn:

Mewn cof a rennir (byfferau a rennir) mae segment ar gyfer gosod data statig yno, mae yna hefyd y cownteri hynny sy'n cynyddu'n gyson pan fydd digwyddiadau penodol yn digwydd, neu rai eiliadau'n codi yng ngweithrediad y gronfa ddata.
Nid yw'r holl gownteri hyn ar gael i'r defnyddiwr ac nid ydynt hyd yn oed ar gael i'r gweinyddwr. Mae'r rhain yn bethau lefel isel. Er mwyn cael mynediad iddynt, mae PostgreSQL yn darparu rhyngwyneb ar ffurf swyddogaethau SQL. Gallwn wneud detholiadau dethol gan ddefnyddio'r swyddogaethau hyn a chael rhyw fath o fetrig (neu set o fetrigau).
Fodd bynnag, nid yw bob amser yn gyfleus defnyddio'r swyddogaethau hyn, felly swyddogaethau yw'r sail ar gyfer safbwyntiau (VIEWs). Mae'r rhain yn dablau rhithwir sy'n darparu ystadegau ar is-system benodol, neu ar rai set o ddigwyddiadau yn y gronfa ddata.
Y golygfeydd adeiledig hyn (VIEWs) yw'r prif ryngwyneb defnyddiwr ar gyfer gweithio gydag ystadegau. Maent ar gael yn ddiofyn heb unrhyw osodiadau ychwanegol, gallwch eu defnyddio ar unwaith, gwylio, cymryd gwybodaeth oddi yno. Ac mae yna hefyd gyfraniadau. Mae'r cyfraniadau yn swyddogol. Gallwch chi osod y pecyn postgresql-contrib (er enghraifft, postgresql94-contrib), llwytho'r modiwl angenrheidiol yn y ffurfweddiad, nodi paramedrau ar ei gyfer, ailgychwyn PostgreSQL a gallwch ei ddefnyddio. (Nodyn. Yn dibynnu ar y dosbarthiad, mewn fersiynau diweddar o gyfrannu mae'r pecyn yn rhan o'r prif becyn).
Ac mae yna gyfraniadau answyddogol. Nid ydynt yn cael eu cyflenwi â dosbarthiad safonol PostgreSQL. Rhaid naill ai eu llunio neu eu gosod fel llyfrgell. Gall opsiynau fod yn wahanol iawn, yn dibynnu ar yr hyn a ddatblygodd datblygwr y cyfraniad answyddogol hwn.

Mae'r sleid hon yn dangos yr holl safbwyntiau hynny (VIEWs) a rhai o'r swyddogaethau hynny sydd ar gael yn PostgreSQL 9.4. Fel y gallwn weld, mae yna lawer ohonyn nhw. Ac mae'n eithaf hawdd drysu os ydych chi'n ei brofi am y tro cyntaf.

Fodd bynnag, os cymerwn y darlun blaenorol Как тратится время на PostgreSQL ac yn gydnaws â'r rhestr hon, rydym yn cael y llun hwn. Mae pob golwg (VIEWs), neu bob swyddogaeth, y gallwn eu defnyddio at un diben neu'i gilydd i gael yr ystadegau priodol pan fydd gennym PostgreSQL rhedeg. A gallwn eisoes gael rhywfaint o wybodaeth am weithrediad yr is-system.

Y peth cyntaf y byddwn yn edrych arno yw pg_stat_database. Fel y gallwn weld, mae hwn yn gynrychiolaeth. Mae'n cynnwys llawer o wybodaeth. Y wybodaeth fwyaf amrywiol. Ac mae'n rhoi gwybodaeth ddefnyddiol iawn am yr hyn sydd gennym yn mynd ymlaen yn y gronfa ddata.

Beth allwn ni ei gymryd oddi yno? Gadewch i ni ddechrau gyda'r pethau symlaf.

select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;

Y peth cyntaf y gallwn edrych arno yw canran taro cache. Mae canran taro cache yn fetrig defnyddiol. Mae'n caniatáu ichi amcangyfrif faint o ddata sy'n cael ei gymryd o'r storfa byfferau a rennir, a faint sy'n cael ei ddarllen o ddisg.

Mae'n amlwg bod y mwyaf taro cache sydd gennym, y gorau. Rydym yn gwerthuso'r metrig hwn fel canran. Ac, er enghraifft, os oes gennym ganran o'r trawiadau cache hyn sy'n fwy na 90%, yna mae hyn yn dda. Os yw'n disgyn o dan 90%, yna nid oes gennym ddigon o gof i gadw'r pen poeth o ddata yn y cof. Ac er mwyn defnyddio'r data hwn, mae PostgreSQL yn cael ei orfodi i gael mynediad i'r ddisg ac mae hyn yn arafach na phe bai'r data'n cael ei ddarllen o'r cof. Ac mae angen i chi feddwl am gynyddu cof: naill ai cynyddu byfferau a rennir, neu gynyddu cof haearn (RAM).

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;

Beth arall y gellir ei gymryd o'r perfformiad hwn? Gallwch weld yr anomaleddau sy'n digwydd yn y gronfa ddata. Beth sy'n cael ei ddangos yma? Mae yna ymrwymiadau, dychweliadau, creu ffeiliau dros dro, eu maint, terfynau amser a gwrthdaro.

Gallwn ddefnyddio'r cais hwn. Mae'r SQL hwn yn eithaf syml. A gallwn weld y data hwn drosom ein hunain.

A dyma'r gwerthoedd trothwy. Edrychwn ar gymhareb yr ymrwymiadau a'r treigladau. Mae Commits yn gadarnhad llwyddiannus o'r trafodiad. Dychweliad yw dychweliad, h.y. gwnaeth y trafodiad rywfaint o waith, rhoddodd straen ar y gronfa ddata, ystyriwyd rhywbeth, ac yna bu methiant, a chaiff canlyniadau'r trafodiad eu taflu. h.y. mae nifer y dychweliadau sy'n cynyddu'n gyson yn ddrwg. A dylech rywsut eu hosgoi, a golygu'r cod fel nad yw hyn yn digwydd.

Mae gwrthdaro yn gysylltiedig ag atgynhyrchu. A dylid eu hosgoi hefyd. Os oes gennych rai ymholiadau sy'n cael eu gweithredu ar y replica a bod gwrthdaro'n codi, yna mae angen i chi ddadansoddi'r gwrthdaro hyn a gweld beth sy'n digwydd. Ceir manylion yn y logiau. A datrys gwrthdaro fel bod ceisiadau cais yn gweithio heb wallau.

Mae deadlocks hefyd yn sefyllfa wael. Pan oedd ceisiadau'n cystadlu am adnoddau, roedd un cais yn cyrchu un adnodd ac yn cymryd y clo, roedd yr ail gais yn cyrchu'r ail adnodd a hefyd yn cymryd y clo, ac yna'r ddau gais yn cyrchu adnoddau ei gilydd ac yn rhwystro aros i'r cymydog ryddhau'r clo. Mae hon hefyd yn sefyllfa broblemus. Mae angen rhoi sylw iddynt ar lefel ailysgrifennu cymwysiadau a chyfresi mynediad at adnoddau. Ac os gwelwch fod eich cloeon yn cynyddu'n gyson, mae angen ichi edrych ar y manylion yn y logiau, dadansoddi'r sefyllfaoedd sydd wedi codi a gweld beth yw'r broblem.

Mae ffeiliau dros dro (temp_files) hefyd yn ddrwg. Pan nad oes gan gais defnyddiwr ddigon o gof i gynnwys y data gweithredol, dros dro, mae'n creu ffeil ar ddisg. Ac mae'r holl weithrediadau y gallai eu perfformio mewn byffer dros dro er cof yn dechrau perfformio eisoes ar y ddisg. Mae'n araf. Mae hyn yn cynyddu'r amser cyflawni ymholiad. A bydd y cleient a anfonodd gais at PostgreSQL yn derbyn ymateb ychydig yn ddiweddarach. Os cyflawnir yr holl weithrediadau hyn er cof, bydd Postgres yn ymateb yn gynt o lawer a bydd y cleient yn aros llai.

pg_stat_bwriter - Mae'r farn hon yn disgrifio gweithrediad dwy is-system gefndir PostgreSQL: checkpointer и background writer.

I ddechrau, gadewch i ni ddadansoddi'r pwyntiau rheoli, yr hyn a elwir. checkpoints. Beth yw pwyntiau gwirio? Mae pwynt gwirio yn safle yn y log trafodion sy'n nodi bod yr holl newidiadau data a gyflawnwyd yn y log yn cael eu cysoni'n llwyddiannus â'r data ar ddisg. Gall y broses, yn dibynnu ar y llwyth gwaith a'r gosodiadau, fod yn hir ac yn bennaf mae'n cynnwys cydamseru tudalennau budr mewn byfferau a rennir â ffeiliau data ar ddisg. Beth yw ei ddiben? Pe bai PostgreSQL yn cyrchu'r ddisg trwy'r amser ac yn cymryd data oddi yno, ac yn ysgrifennu data ar bob mynediad, byddai'n araf. Felly, mae gan PostgreSQL segment cof, y mae ei faint yn dibynnu ar y paramedrau yn y cyfluniad. Mae Postgres yn dyrannu data gweithredol yn y cof hwn ar gyfer prosesu neu ymholi pellach. Yn achos ceisiadau newid data, cânt eu newid. Ac rydym yn cael dwy fersiwn o'r data. Mae un yn y cof, mae'r llall ar ddisg. Ac o bryd i'w gilydd mae angen i chi gydamseru'r data hwn. Mae angen i'r hyn sy'n cael ei newid yn y cof gael ei gydamseru â disg. Mae hyn yn gofyn am bwynt gwirio.

Mae Checkpoint yn mynd trwy glustogau a rennir, yn nodi tudalennau budr y mae eu hangen ar gyfer pwynt gwirio. Yna mae'n dechrau'r ail docyn trwy glustogau a rennir. Ac mae'r tudalennau sydd wedi'u marcio ar gyfer pwynt gwirio, mae eisoes yn eu cysoni. Felly, mae'r data eisoes wedi'i gysoni â'r ddisg.

Mae dau fath o bwyntiau rheoli. Gweithredir un pwynt gwirio ar derfyn amser. Mae'r pwynt gwirio hwn yn ddefnyddiol ac yn dda - checkpoint_timed. Ac mae yna bwyntiau gwirio ar alw - checkpoint required. Mae pwynt gwirio o'r fath yn digwydd pan fydd gennym gofnod data mawr iawn. Fe wnaethon ni recordio llawer o logiau trafodion. Ac mae PostgreSQL yn credu bod angen iddo gydamseru hyn i gyd cyn gynted â phosibl, gwneud pwynt gwirio a symud ymlaen.

Ac os edrychwch chi ar yr ystadegau pg_stat_bgwriter a gweld beth sydd gennych chi mae checkpoint_req yn llawer mwy na checkpoint_timed, yna mae hyn yn ddrwg. Pam drwg? Mae hyn yn golygu bod PostgreSQL dan straen cyson pan fydd angen iddo ysgrifennu data i ddisg. Mae pwynt gwirio erbyn terfyn amser yn llai o straen ac yn cael ei weithredu yn unol â'r amserlen fewnol ac, fel petai, yn cael ei ymestyn dros amser. Mae gan PostgreSQL y gallu i oedi yn y gwaith a pheidio â rhoi straen ar yr is-system ddisg. Mae hyn yn ddefnyddiol ar gyfer PostgreSQL. Ac ni fydd ceisiadau sy'n cael eu gweithredu yn ystod pwynt gwirio yn profi straen oherwydd bod yr is-system ddisg yn brysur.

Ac mae yna dri pharamedr i addasu'r pwynt gwirio:

сheckpoint_segments.
сheckpoint_timeout.
сheckpoint_competion_target.

Maent yn caniatáu ichi reoli gweithrediad pwyntiau rheoli. Ond ni fyddaf yn aros arnynt. Mae eu dylanwad yn fater ar wahân.

Rhybudd: Nid yw fersiwn 9.4 a ystyriwyd yn yr adroddiad bellach yn berthnasol. Mewn fersiynau modern o PostgreSQL, y paramedr checkpoint_segments disodli gan baramedrau min_wal_size и max_wal_size.

Yr is-system nesaf yw'r ysgrifennwr cefndir - background writer. Beth mae e'n ei wneud? Mae'n rhedeg yn gyson mewn dolen ddiddiwedd. Mae'n sganio tudalennau yn glustogau a rennir ac yn fflysio'r tudalennau budr y mae'n dod o hyd iddynt i ddisg. Yn y modd hwn, mae'n helpu'r pwyntydd gwirio i wneud llai o waith yn ystod pwyntio siec.

Beth arall sydd ei angen arno? Mae'n darparu ar gyfer yr angen am dudalennau glân mewn byfferau a rennir os oes eu hangen yn sydyn (mewn symiau mawr ac ar unwaith) i gynnwys data. Tybiwch fod sefyllfa wedi codi pan oedd angen tudalennau glân ar y cais a'u bod eisoes mewn byfferau a rennir. Postgres backend mae'n eu cymryd ac yn eu defnyddio, nid oes yn rhaid iddo lanhau unrhyw beth ei hun. Ond os yn sydyn nad oes tudalennau o'r fath, mae'r ôl-wyneb yn oedi ac yn dechrau chwilio am dudalennau i'w fflysio i ddisg a'u cymryd ar gyfer ei anghenion ei hun - sy'n effeithio'n negyddol ar amser gweithredu'r cais ar hyn o bryd. Os gwelwch fod gennych baramedr maxwritten_clean mawr, mae hyn yn golygu nad yw'r awdur cefndir yn gwneud ei waith a bod angen i chi gynyddu'r paramedrau bgwriter_lru_maxpagesfel y gallo wneud mwy o waith mewn un cylch, clirio mwy o dudalennau.

Ac mae dangosydd defnyddiol iawn arall buffers_backend_fsync. Nid yw backends yn gwneud fsync oherwydd ei fod yn araf. Maen nhw'n pasio fsync i fyny pwyntydd gwirio stack IO. Mae gan y pwyntydd siec ei giw ei hun, mae'n prosesu fsync o bryd i'w gilydd ac yn cydamseru tudalennau yn y cof â ffeiliau ar ddisg. Os yw'r ciw pwyntydd yn fawr ac yn llawn, yna mae'r backend yn cael ei orfodi i wneud cydamseru ei hun ac mae hyn yn arafu'r backend, h.y. bydd y cleient yn cael ymateb yn hwyrach nag y gallai. Os gwelwch fod gennych y gwerth hwn yn fwy na sero, yna mae hyn eisoes yn broblem ac mae angen i chi dalu sylw i osodiadau'r ysgrifennwr cefndir a hefyd gwerthuso perfformiad yr is-system ddisg.

Rhybudd: _Mae'r testun canlynol yn disgrifio'r safbwyntiau ystadegol sy'n gysylltiedig ag atgynhyrchu. Mae'r rhan fwyaf o'r enwau golygfa a swyddogaeth wedi'u hail-enwi yn Postgres 10. Hanfod yr ailenwi oedd disodli xlog ar wal и location ar lsn mewn enwau swyddogaeth/gweld, ac ati. Enghraifft arbennig, swyddogaeth pg_xlog_location_diff() ailenwyd i pg_wal_lsn_diff()._

Mae gennym ni lawer yma hefyd. Ond dim ond eitemau sy'n ymwneud â lleoliad sydd eu hangen arnom.

Os gwelwn fod yr holl werthoedd yn gyfartal, yna mae hyn yn ddelfrydol ac nid yw'r replica yn llusgo y tu ôl i'r meistr.

Y sefyllfa hecsadegol yma yw'r safle yn y log trafodion. Mae'n cynyddu'n gyson os oes rhywfaint o weithgarwch yn y gronfa ddata: mewnosod, dileu, ac ati.

сколько записано 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());

Os yw'r pethau hyn yn wahanol, yna mae yna ryw fath o oedi. Lag yw oedi'r atgynhyrchiad o'r meistr, h.y. mae'r data'n wahanol rhwng gweinyddwyr.

Mae tri rheswm am yr oedi:

Dyma'r is-system ddisg sy'n methu ag ymdrin â gwaith cysoni ffeiliau.
Mae'r rhain yn gamgymeriadau rhwydwaith posibl, neu'n orlwytho rhwydwaith, pan nad oes gan y data amser i gyrraedd y replica ac ni all ei atgynhyrchu.
A'r prosesydd. Mae'r prosesydd yn achos prin iawn. Ac rwyf wedi gweld hynny ddwy neu dair gwaith, ond gall hynny ddigwydd hefyd.

A dyma dri ymholiad sy'n ein galluogi i ddefnyddio ystadegau. Gallwn amcangyfrif faint sy'n cael ei gofnodi yn ein log trafodion. Mae swyddogaeth o'r fath pg_xlog_location_diff a gallwn amcangyfrif yr oedi wrth ddyblygu mewn beit ac eiliadau. Rydym hefyd yn defnyddio'r gwerth o'r farn hon (VIEWs) ar gyfer hyn.

Nodyn: _Yn lle pg_xlog_locationswyddogaeth diff(), gallwch ddefnyddio'r gweithredwr tynnu a thynnu un lleoliad o'r llall. Cyfforddus.

Gydag oedi, sydd mewn eiliadau, mae un eiliad. Os nad oes unrhyw weithgaredd ar y meistr, roedd y trafodiad yno tua 15 munud yn ôl ac nid oes unrhyw weithgaredd, ac os edrychwn ar yr oedi hwn ar y replica, byddwn yn gweld oedi o 15 munud. Mae hyn yn werth ei gofio. A gall arwain at stupor pan wnaethoch chi wylio'r oedi hwn.

Mae pg_stat_all_tables yn olygfa ddefnyddiol arall. Mae'n dangos ystadegau ar dablau. Pan fydd gennym dablau yn y gronfa ddata, mae rhywfaint o weithgarwch ag ef, rhai camau gweithredu, gallwn gael y wybodaeth hon o'r farn hon.

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;

Y peth cyntaf y gallwn edrych arno yw sganiau tabl dilyniannol. Nid yw'r rhif ei hun ar ôl y darnau hyn o reidrwydd yn ddrwg ac nid yw'n nodi bod angen i ni wneud rhywbeth eisoes.

Fodd bynnag, mae ail fetrig - seq_tup_read. Dyma nifer y rhesi a ddychwelwyd o'r sgan dilyniannol. Os yw'r nifer cyfartalog yn fwy na 1, 000, 10, 000, yna mae hwn eisoes yn ddangosydd y gallai fod angen i chi adeiladu mynegai yn rhywle fel bod y mynediad yn ôl mynegai, neu mae'n bosibl optimeiddio ymholiadau sy'n defnyddio sganiau dilyniannol o'r fath fel bod nid yw hyn yn digwydd . oedd .

Enghraifft syml - gadewch i ni ddweud bod cais gyda gwrthbwyso mawr a TERFYN yn werth chweil. Er enghraifft, mae 100 o resi mewn tabl yn cael eu sganio ac ar ôl hynny cymerir 000 o resi gofynnol, a chaiff y rhesi blaenorol a sganiwyd eu taflu. Mae hwn hefyd yn achos gwael. Ac mae angen optimeiddio ceisiadau o'r fath. A dyma ymholiad SQL mor syml y gallwch ei weld a gwerthuso'r niferoedd a dderbyniwyd.

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;

Gellir cael meintiau tablau hefyd gan ddefnyddio'r tabl hwn a defnyddio swyddogaethau ychwanegol pg_total_relation_size(), pg_relation_size().

Yn gyffredinol, mae yna fetacommands dt и di, y gallwch ei ddefnyddio yn PSQL a hefyd weld meintiau tabl a mynegai.

Fodd bynnag, mae defnyddio swyddogaethau yn ein helpu i edrych ar feintiau tablau, hyd yn oed gan ystyried mynegeion, neu heb ystyried mynegeion, a gwneud rhai amcangyfrifon eisoes yn seiliedig ar dwf y gronfa ddata, h.y. sut mae’n tyfu gyda ni, gyda pa ddwyster, ac eisoes yn dod i rai casgliadau am optimeiddio maint.

Ysgrifennu gweithgaredd. Beth yw cofnod? Gadewch i ni edrych ar y llawdriniaeth UPDATE – gweithredu diweddaru rhesi yn y tabl. Mewn gwirionedd, mae diweddariad yn ddau weithrediad (neu hyd yn oed mwy). Mae hyn yn mewnosod fersiwn rhes newydd ac yn nodi'r hen fersiwn rhes fel un sydd wedi darfod. Yn ddiweddarach, bydd autovacuum yn dod i lanhau'r fersiynau anarferedig hyn o'r llinellau, gan nodi bod y lle hwn ar gael i'w ailddefnyddio.

Hefyd, nid yw diweddaru yn ymwneud â diweddaru tabl yn unig. Mae'n dal i fod yn ddiweddariad mynegai. Os oes gennych chi lawer o fynegeion ar y bwrdd, yna gyda diweddariad, bydd angen diweddaru'r holl fynegeion y mae'r meysydd a ddiweddarwyd yn yr ymholiad yn cymryd rhan ynddynt hefyd. Bydd gan y mynegeion hyn hefyd fersiynau rhesi anarferedig y bydd angen eu glanhau.

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;

Ac oherwydd ei ddyluniad, mae DIWEDDARIAD yn weithrediad pwysau trwm. Ond gellir eu gwneud yn haws. Bwyta hot updates. Fe wnaethant ymddangos yn fersiwn PostgreSQL 8.3. A beth yw hwn? Mae hwn yn ddiweddariad ysgafn nad yw'n achosi i fynegeion gael eu hailadeiladu. Hynny yw, fe wnaethom ddiweddaru'r cofnod, ond dim ond y cofnod yn y dudalen (sy'n perthyn i'r tabl) a ddiweddarwyd, ac mae'r mynegeion yn dal i bwyntio at yr un cofnod yn y dudalen. Mae yna ychydig o resymeg gwaith mor ddiddorol, pan ddaw gwactod, yna mae ganddo'r cadwyni hyn hot yn ailadeiladu ac mae popeth yn parhau i weithio heb ddiweddaru'r mynegeion, ac mae popeth yn digwydd gyda llai o wastraff adnoddau.

A phan fydd gennych chi n_tup_hot_upd mawr, mae'n dda iawn. Mae hyn yn golygu bod diweddariadau ysgafn yn bodoli ac mae hyn yn rhatach i ni o ran adnoddau ac mae popeth yn iawn.

ALTER TABLE table_name SET (fillfactor = 70);

Sut i gynyddu cyfaint hot updateofv? Gallwn ddefnyddio fillfactor. Mae'n pennu maint y gofod rhydd neilltuedig wrth lenwi tudalen mewn tabl gan ddefnyddio INSERTs. Pan fydd mewnosodiadau yn mynd at y bwrdd, maen nhw'n llenwi'r dudalen yn llwyr, peidiwch â gadael lle gwag ynddi. Yna amlygir tudalen newydd. Mae'r data wedi'i lenwi eto. A dyma'r ymddygiad diofyn, fillfactor = 100%.

Gallwn osod y ffactor llenwi i 70%. Hynny yw, gyda mewnosodiadau, dyrannwyd tudalen newydd, ond dim ond 70% o'r dudalen a lenwyd. Ac mae gennym ni 30% ar ôl wrth gefn. Pan fydd angen i chi wneud diweddariad, mae'n debygol y bydd yn digwydd ar yr un dudalen, a bydd y fersiwn newydd o'r rhes yn ffitio ar yr un dudalen. A bydd hot_update yn cael ei wneud. Mae hyn yn ei gwneud yn haws i ysgrifennu ar dablau.

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));

Ciw gwactod. Mae Autovacuum yn is-system o'r fath ac ychydig iawn o ystadegau sydd ar ei chyfer yn PostgreSQL. Dim ond yn y tablau yn pg_stat_activity y gallwn weld faint o wactod sydd gennym ar hyn o bryd. Fodd bynnag, mae’n anodd iawn deall faint o fyrddau yn y ciw sydd ganddo wrth fynd.

Nodyn: _Since Postgres 10, mae'r sefyllfa o ran olrhain y gwactod gwactod wedi gwella'n fawr - mae'r golwg pg_stat_progress wedi ymddangosgwactod, sy'n symleiddio'r mater o fonitro autovacuum yn fawr.

Gallwn ddefnyddio'r ymholiad symlach hwn. A gallwn weld pryd y dylid gwneud y gwactod. Ond, sut a phryd y dylai'r gwactod ddechrau? Dyma'r hen fersiynau o'r tannau y soniais amdanynt yn gynharach. Mae diweddariad wedi digwydd, mae'r fersiwn newydd o'r rhes wedi'i fewnosod. Mae fersiwn anarferedig o'r llinyn wedi ymddangos. Bwrdd pg_stat_user_tables mae paramedr o'r fath n_dead_tup. Mae'n dangos nifer y rhesi "marw". A chyn gynted ag y bydd nifer y rhesi marw wedi dod yn fwy na throthwy penodol, bydd autovacuum yn dod i'r bwrdd.

A sut mae'r trothwy hwn yn cael ei gyfrifo? Mae hon yn ganran benodol iawn o gyfanswm nifer y rhesi yn y tabl. Mae paramedr autovacuum_vacuum_scale_factor. Mae'n diffinio'r ganran. Gadewch i ni ddweud 10% + mae trothwy sylfaenol ychwanegol o 50 llinell. A beth sy'n digwydd? Pan fydd gennym fwy o resi marw na "10% + 50" o'r holl resi yn y tabl, rydyn ni'n rhoi'r tabl ar autovacuum.

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));

Fodd bynnag, mae un pwynt. Trothwyon sylfaenol ar gyfer paramedrau av_base_thresh и av_scale_factor gellir ei neilltuo'n unigol. Ac, yn unol â hynny, ni fydd y trothwy yn fyd-eang, ond yn unigol ar gyfer y bwrdd. Felly, i gyfrifo, mae angen i chi ddefnyddio triciau a thriciau. Ac os oes gennych ddiddordeb, gallwch edrych ar brofiad ein cydweithwyr o Avito (mae'r ddolen ar y sleid yn annilys ac wedi'i diweddaru yn y testun).

Ysgrifenasant am ategyn muninsy'n cymryd y pethau hyn i ystyriaeth. Mae lliain traed ar ddwy ddalen. Ond mae'n meddwl yn gywir ac yn eithaf effeithiol yn ein galluogi i asesu lle mae angen llawer o wactod ar gyfer byrddau lle nad oes llawer.

Beth allwn ni ei wneud amdano? Os oes gennym giw hir ac na all yr awtocws ymdopi, yna gallwn gynyddu nifer y gweithwyr gwactod, neu wneud y gwactod yn fwy ymosodol.fel ei fod yn sbarduno'n gynharach, yn prosesu'r bwrdd mewn darnau bach. Ac felly bydd y ciw yn lleihau. - Y prif beth yma yw monitro'r llwyth ar y disgiau, oherwydd. Nid yw'r peth gwactod yn rhad ac am ddim, er gyda dyfodiad dyfeisiau SSD / NVMe, mae'r broblem wedi dod yn llai amlwg.

pg_stat_all_indexes yw ystadegau ar fynegeion. Nid yw hi'n fawr. A gallwn gael gwybodaeth am y defnydd o fynegeion ohono. Ac er enghraifft, gallwn benderfynu pa fynegeion sydd gennym yn ychwanegol.

Fel y dywedais eisoes, diweddaru nid yn unig yn diweddaru tablau, mae hefyd yn diweddaru mynegeion. Yn unol â hynny, os oes gennym lawer o fynegeion ar y bwrdd, yna wrth ddiweddaru'r rhesi yn y tabl, mae angen diweddaru mynegeion y meysydd mynegeio hefyd, a os oes gennym fynegeion nas defnyddiwyd ac nad oes sganiau mynegai ar eu cyfer, yna maent yn hongian gyda ni fel balast. Ac mae angen i chi gael gwared arnynt. Ar gyfer hyn mae angen cae idx_scan. Edrychwn ar nifer y sganiau mynegai. Os oes gan y mynegeion sganiau sero dros gyfnod cymharol hir o storio ystadegau (o leiaf 2-3 wythnos), yna'n fwyaf tebygol mai mynegeion gwael yw'r rhain, mae angen i ni gael gwared arnynt.

Nodyn: Wrth chwilio am fynegeion nas defnyddiwyd yn achos ffrydio clystyrau atgynhyrchu, mae angen i chi wirio holl nodau'r clwstwr, oherwydd nid yw ystadegau'n fyd-eang, ac os na ddefnyddir y mynegai ar y meistr, yna gellir ei ddefnyddio ar atgynyrchiadau (os oes llwyth).

Dau ddolen:

https://github.com/dataegret/pg-utils/blob/master/sql/low_used_indexes.sql

http://www.databasesoup.com/2014/05/new-finding-unused-indexes-query.html

Mae'r rhain yn enghreifftiau o ymholiadau mwy datblygedig ar gyfer sut i chwilio am fynegeion nas defnyddiwyd.

Mae'r ail ddolen yn ymholiad digon diddorol. Mae rhesymeg an-ddibwys iawn ynddo. Rwy'n ei argymell ar gyfer adolygiad.

Beth arall ddylai gael ei grynhoi gan fynegeion?

Mae mynegeion nas defnyddiwyd yn ddrwg.
Maen nhw'n cymryd lle.
Arafu gweithrediadau diweddaru.
Gwaith ychwanegol ar gyfer y gwactod.

Os byddwn yn dileu mynegeion nas defnyddiwyd, yna byddwn ond yn gwella'r gronfa ddata.

Yr olygfa nesaf yw pg_stat_activity. Mae hwn yn analog o'r cyfleustodau ps, dim ond yn PostgreSQL. Os ps'Oh, rydych chi'n gwylio'r prosesau yn y system weithredu, felly pg_stat_activity yn dangos y gweithgaredd y tu mewn i PostgreSQL i chi.

Beth allwn ni ei gymryd oddi yno?

select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;

Gallwn weld y gweithgaredd cyffredinol sy'n digwydd yn y gronfa ddata. Gallwn wneud defnydd newydd. Ffrwydrodd popeth yno, ni dderbynnir cysylltiadau newydd, mae gwallau yn arllwys yn y cais.

select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;

Gallwn redeg ymholiad fel hwn a gweld cyfanswm canran y cysylltiadau o'i gymharu â'r terfyn cysylltiad uchaf a gweld pwy sydd â'r nifer fwyaf o gysylltiadau. Ac yn yr achos penodol hwn, gwelwn y defnyddiwr hwnnw cron_role wedi agor 508 o gysylltiadau. A digwyddodd rhywbeth iddo. Mae angen ichi ddelio ag ef a gweld. Ac mae'n eithaf posibl bod hyn yn rhyw fath o nifer anghyson o gysylltiadau.

Os oes gennym lwyth OLTP, dylai ymholiadau fod yn gyflym, yn gyflym iawn, ac ni ddylai fod ymholiadau hir. Fodd bynnag, os oes ceisiadau hir, yna yn y tymor byr nid oes dim i boeni amdano, ond yn y tymor hir, mae ymholiadau hir yn niweidio'r gronfa ddata, maent yn cynyddu effaith chwyddedig tablau pan fydd darnio tabl yn digwydd. Mae angen cael gwared ar ymholiadau chwyddedig a hir.

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;

Sylwch: gyda chais o'r fath, gallwn ddiffinio ceisiadau a thrafodion hir. Rydym yn defnyddio'r swyddogaeth clock_timestamp() i benderfynu ar yr amser gweithio. Ceisiadau maith a ganfuom, gallwn eu cofio, eu gweithredu explain, edrych ar gynlluniau a rhywsut optimeiddio. Rydyn ni'n saethu'r ceisiadau hir presennol ac yn byw ymlaen.

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

Mae trafodion drwg yn segur mewn trafodion ac yn segur mewn trafodion (trafodion a erthylwyd).

Beth mae'n ei olygu? Mae gan drafodion sawl gwladwriaeth. A gall un o'r taleithiau hyn gymryd unrhyw bryd. Mae maes i ddiffinio gwladwriaethau state yn y farn hon. Ac rydym yn ei ddefnyddio i benderfynu ar y wladwriaeth.

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

Ac, fel y dywedais uchod, y ddwy wladwriaeth hyn segur mewn trafodiad a segur yn trafodiad (erthylu) yn ddrwg. Beth yw e? Dyma pan agorodd y cais drafodiad, gwneud rhai gweithredoedd a mynd o gwmpas ei fusnes. Mae'r trafodiad yn parhau i fod ar agor. Mae'n hongian, nid oes dim yn digwydd ynddo, mae'n cymryd cysylltiad, yn cloi ar resi wedi'u newid ac o bosibl hyd yn oed yn cynyddu chwydd y byrddau eraill, oherwydd pensaernïaeth injan drafodion Postrges. A dylid saethu trafodion o'r fath hefyd, oherwydd eu bod yn niweidiol yn gyffredinol, mewn unrhyw achos.

Os gwelwch fod gennych chi fwy na 5-10-20 ohonyn nhw yn eich cronfa ddata, yna mae angen i chi boeni a dechrau gwneud rhywbeth gyda nhw.

Yma rydym hefyd yn defnyddio ar gyfer yr amser cyfrifo clock_timestamp(). Rydym yn saethu trafodion, rydym yn gwneud y gorau o'r cais.

Fel y dywedais uchod, cloeon yw pan fydd dau neu fwy o drafodion yn cystadlu am un neu grŵp o adnoddau. Ar gyfer hyn mae gennym faes waiting gyda gwerth boolaidd true neu false.

Gwir - mae hyn yn golygu bod y broses yn aros, mae angen gwneud rhywbeth. Pan fydd proses yn aros, yna mae'r cleient a gychwynnodd y broses hefyd yn aros. Mae'r cleient yn y porwr yn eistedd a hefyd yn aros.

Rhybudd: _Dechrau o Postgres 9.6, y maes waiting cael ei ddileu a'i ddisodli gan ddau faes mwy addysgiadol wait_event_type и wait_event._

Beth i'w wneud? Os gwelwch yn wir am amser hir, yna dylech gael gwared ar geisiadau o'r fath. Rydym yn unig saethu trafodion o'r fath. Rydym yn ysgrifennu at ddatblygwyr beth sydd angen ei optimeiddio rhywsut fel nad oes ras am adnoddau. Ac yna mae'r datblygwyr yn gwneud y gorau o'r cais fel nad yw hyn yn digwydd.

Ac mae'r achos eithafol, ond ar yr un pryd o bosibl ddim yn angheuol achosion o ddatgloi. Mae dau drafodiad wedi diweddaru dau adnodd, yna maent yn eu cyrchu eto, eisoes i adnoddau gyferbyn. Mae PostgreSQL yn yr achos hwn yn cymryd ac yn saethu oddi ar y trafodiad ei hun fel y gall y llall barhau i weithio. Mae hon yn sefyllfa ddi-ben-draw ac nid yw hi'n deall ei hun. Felly, mae PostgreSQL yn cael ei orfodi i gymryd mesurau eithafol.

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/c4_06_show_locked_queries.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_95.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_96.sql

http://big-elephants.com/2013-09/exploring-query-locks-in-postgres/

A dyma ddau ymholiad sy'n eich galluogi i olrhain cloeon. Rydym yn defnyddio'r olygfa pg_locks, sy'n eich galluogi i olrhain cloeon trwm.

A'r ddolen gyntaf yw testun y cais ei hun. Mae'n eithaf hir.

Ac mae'r ail ddolen yn erthygl ar gloeon. Mae'n ddefnyddiol darllen, mae'n ddiddorol iawn.

Felly beth ydyn ni'n ei weld? Gwelwn ddau gais. Trafodyn gyda ALTER TABLE yn drafodiad blocio. Dechreuodd, ond ni ddaeth i ben, ac mae'r cais a bostiodd y trafodiad hwn yn gwneud pethau eraill yn rhywle. A'r ail gais yw diweddariad. Mae'n aros i'r bwrdd alter orffen cyn parhau â'i waith.

Dyma sut y gallwn ddarganfod pwy sydd wedi cloi pwy, pwy sy'n dal pwy, a gallwn ymdrin â hyn ymhellach.

Y modiwl nesaf yw pg_stat_statements. Fel y dywedais, mae'n fodiwl. Er mwyn ei ddefnyddio, mae angen i chi lwytho ei lyfrgell yn y ffurfweddiad, ailgychwyn PostgreSQL, gosod y modiwl (gydag un gorchymyn), ac yna bydd gennym olwg newydd.

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;

Beth allwn ni ei gymryd oddi yno? Os byddwn yn siarad am bethau syml, gallwn gymryd yr amser cyflawni ymholiad ar gyfartaledd. Mae amser yn tyfu, sy'n golygu bod PostgreSQL yn ymateb yn araf ac mae angen gwneud rhywbeth.

Gallwn weld y trafodion ysgrifennu mwyaf gweithredol yn y gronfa ddata sy'n newid data mewn byfferau a rennir. Gweld pwy sy'n diweddaru neu'n dileu data yno.

A gallwn edrych ar ystadegau gwahanol ar gyfer y ceisiadau hyn.

https://github.com/dataegret/pg-utils/blob/master/sql/global_reports/query_stat_total.sql

Rydym yn pg_stat_statements defnyddio i adeiladu adroddiadau. Rydym yn ailosod yr ystadegau unwaith y dydd. Gadewch i ni ei gronni. Cyn ailosod ystadegau y tro nesaf, rydym yn adeiladu adroddiad. Dyma ddolen i'r adroddiad. Gallwch chi ei wylio.

Beth ydyn ni'n ei wneud? Rydym yn cyfrifo'r ystadegau cyffredinol ar gyfer pob ymholiad. Yna, ar gyfer pob ymholiad, rydym yn cyfrif ei gyfraniad unigol i'r ystadegyn cyffredinol hwn.

A beth allwn ni ei weld? Gallwn weld cyfanswm amser gweithredu pob cais o fath arbennig yn erbyn cefndir pob cais arall. Gallwn edrych ar ddefnydd CPU ac I/O mewn perthynas â'r darlun cyffredinol. Ac yn barod i wneud y gorau o'r ceisiadau hyn. Rydym yn adeiladu prif ymholiadau yn seiliedig ar yr adroddiad hwn ac rydym eisoes yn ystyried beth i'w optimeiddio.

Beth sydd gennym y tu ôl i'r llenni? Mae yna ychydig o gyflwyniadau o hyd na wnes i eu hystyried, oherwydd mae amser yn gyfyngedig.

Mae pgstattuple hefyd yn fodiwl ychwanegol o'r pecyn cyfraniadau safonol. Mae'n caniatáu ichi werthuso bloat byrddau, fel y'u gelwir. darnio tabl. Ac os yw'r darniad yn fawr, mae angen i chi ei dynnu, defnyddio gwahanol offer. A swyddogaeth pgstattuple yn gweithio am amser hir. A pho fwyaf o fyrddau, yr hiraf y bydd yn gweithio.

Y cyfraniad nesaf yw pg_buffercache. Mae'n caniatáu ichi archwilio byfferau a rennir: pa mor ddwys ac ar gyfer pa dablau y defnyddir tudalennau byffer. Ac mae'n caniatáu ichi edrych ar glustogau a rennir a gwerthuso'r hyn sy'n digwydd yno.

Y modiwl nesaf yw pgfincore. Mae'n caniatáu ichi berfformio gweithrediadau bwrdd lefel isel trwy alwad system mincore(), h.y. mae'n caniatáu ichi lwytho'r bwrdd i mewn i glustogau a rennir, neu ei ddadlwytho. Ac mae'n caniatáu, ymhlith pethau eraill, archwilio storfa dudalen y system weithredu, hynny yw, faint y mae'r tabl yn ei feddiannu yn y storfa dudalen, mewn byfferau a rennir, ac yn syml yn caniatáu ichi werthuso'r llwyth ar y bwrdd.

Y modiwl nesaf yw pg_stat_kcache. Mae hefyd yn defnyddio'r alwad system getrusage(). Ac mae'n ei gyflawni cyn ac ar ôl i'r cais gael ei weithredu. Ac yn yr ystadegau a gafwyd, mae'n caniatáu inni amcangyfrif faint y mae ein cais wedi'i wario ar ddisg I / O, h.y., gweithrediadau gyda'r system ffeiliau ac edrych ar ddefnydd y prosesydd. Fodd bynnag, mae'r modiwl yn ifanc (khe-khe) ac ar gyfer ei waith mae angen PostgreSQL 9.4 a pg_stat_statements, a grybwyllais yn gynharach.

Mae'r gallu i ddefnyddio ystadegau yn ddefnyddiol. Nid oes angen meddalwedd trydydd parti arnoch chi. Gallwch edrych, gweld, gwneud rhywbeth, perfformio.
Mae defnyddio ystadegau yn hawdd, mae'n SQL plaen. Fe wnaethoch chi gasglu cais, ei lunio, ei anfon, edrych arno.
Mae ystadegau yn helpu i ateb cwestiynau. Os oes gennych gwestiynau, rydych chi'n troi at ystadegau - edrychwch, dod i gasgliadau, dadansoddi'r canlyniadau.
Ac arbrofi. Llawer o geisiadau, llawer o ddata. Gallwch chi bob amser optimeiddio rhywfaint o ymholiad presennol. Gallwch wneud eich fersiwn eich hun o'r cais sy'n fwy addas i chi na'r gwreiddiol a'i ddefnyddio.