Rwy'n bwriadu darllen trawsgrifiad adroddiad dechrau 2016 gan Andrey Salnikov "Gwallau nodweddiadol mewn ceisiadau sy'n arwain at bloat yn postgresql"
Yn yr adroddiad hwn, byddaf yn dadansoddi'r prif wallau mewn cymwysiadau sy'n digwydd yn ystod y cam dylunio ac ysgrifennu cod cais. A dim ond y gwallau hynny sy'n arwain at bloat yn Postgresql y byddaf yn eu cymryd. Fel rheol, dyma ddechrau diwedd perfformiad eich system gyfan, er i ddechrau ni welwyd unrhyw ragofynion ar gyfer hyn.
Falch i groesawu pawb! Nid yw’r adroddiad hwn mor dechnegol â’r un blaenorol gan fy nghyd-Aelod. Mae'r sgwrs hon wedi'i hanelu at ddatblygwyr systemau pen ôl yn bennaf oherwydd bod gennym nifer eithaf mawr o gleientiaid. Ac maen nhw i gyd yn gwneud yr un camgymeriadau. Dywedaf wrthych amdanynt. Byddaf yn esbonio i'r hyn angheuol a drwg y gwallau hyn yn arwain.
Pam mae camgymeriadau yn cael eu gwneud? Fe'u perfformir am ddau reswm: ar hap, efallai y bydd yn gweithio allan o anwybodaeth o rai mecanweithiau sy'n digwydd ar y lefel rhwng y sylfaen a'r cais, yn ogystal ag yn y sylfaen ei hun.
Rhoddaf dair enghraifft ichi gyda lluniau ofnadwy o sut aeth pethau’n ddrwg. Disgrifiaf yn fyr y mecanwaith sy'n digwydd yno. A sut i ddelio â nhw, pryd y digwyddon nhw, a pha ddulliau ataliol i'w defnyddio i atal camgymeriadau. Byddaf yn dweud wrthych am offer ategol ac yn rhoi dolenni defnyddiol.
Defnyddiais gronfa ddata prawf lle roedd gen i ddau dabl. Un plât gyda chyfrifon cwsmeriaid, a'r llall gyda gweithrediadau ar y cyfrifon hyn. A chyda pheth cyfnodoldeb, rydym yn diweddaru'r balansau ar y cyfrifon hyn.
Data cychwynnol y plât: mae'n eithaf bach, 2 MB. Mae'r amser ymateb ar gyfer y gronfa ddata ac yn benodol ar gyfer y plât hefyd yn dda iawn. A llwyth gweddol dda - 2 o lawdriniaethau yr eiliad ar y plât.
A thrwy'r adroddiad hwn, byddaf yn dangos graffiau i chi fel ei bod yn glir beth sy'n digwydd. Bydd 2 sleid gyda graffiau bob amser. Y sleid gyntaf yw'r hyn sy'n digwydd yn gyffredinol ar y gweinydd.
Ac yn y sefyllfa hon, gwelwn fod gennym blât bach mewn gwirionedd. Mae'r mynegai yn fach ar 2 MB. Dyma'r siart cyntaf ar y chwith.
Mae'r amser ymateb cyfartalog ar draws y gweinydd hefyd yn sefydlog, yn fach. Dyma'r graff uchaf ar y dde.
Y graff chwith isaf yw'r trafodion hiraf. Gallwn weld bod trafodion yn cael eu cwblhau'n gyflym. Ac nid yw'r autovacuum yn gweithio yma eto, oherwydd - roedd yn brawf cychwyn. Yna bydd yn gweithio ac yn ddefnyddiol i ni.
Bydd yr ail sleid bob amser yn cael ei neilltuo i'r plât prawf. Yn y sefyllfa hon, rydym yn diweddaru balansau cyfrif y cleient yn gyson. A gwelwn fod yr amser ymateb cyfartalog ar gyfer y llawdriniaeth ddiweddaru yn eithaf da, yn llai na milieiliad. Gwelwn fod adnoddau'r prosesydd (dyma'r graff uchaf ar y dde) hefyd yn cael eu defnyddio'n gyfartal ac yn eithaf bach.
Mae'r graff isaf ar y dde yn dangos faint o gof gweithredu a disg rydyn ni'n mynd drwyddo i chwilio am ein llinell ddymunol cyn ei diweddaru. Ac mae nifer y llawdriniaethau ar y plât yn 2 yr eiliad, fel y dywedais ar y dechrau.
Ac yn awr mae gennym drasiedi. Am ryw reswm, mae trafodiad hir anghofiedig yn digwydd. Mae'r rhesymau fel arfer yn waharddol:
- Un o'r rhai mwyaf cyffredin yw ein bod wedi dechrau cael mynediad at wasanaeth allanol yn y cod cais. Ac nid yw'r gwasanaeth hwn yn ein hateb. Hynny yw, fe wnaethom agor trafodiad, gwneud newid yn y gronfa ddata a mynd o'r cais i ddarllen post neu i wasanaeth arall o fewn ein seilwaith, ac am ryw reswm nid yw'n ein hateb. Ac mae ein sesiwn hongian mewn cyflwr - nid yw'n hysbys pryd y bydd yn cael ei datrys.
- Yr ail sefyllfa yw pan ddigwyddodd eithriad yn ein cod am ryw reswm. Ac ni wnaethom brosesu cau'r trafodiad yn yr eithriad. A chawsom sesiwn hongian gyda thrafodiad agored.
- Ac mae'r olaf hefyd yn eithaf cyffredin. Cod o ansawdd gwael yw hwn. Mae rhai fframweithiau yn agor trafodiad. Mae'n hongian, ac efallai na fyddwch chi'n gwybod yn y cais bod gennych chi ef yn hongian.
I ble mae pethau o'r fath yn arwain?
I'r ffaith bod ein tablau a mynegeion yn dechrau chwyddo'n aruthrol. Mae hyn yn union yr un effaith bloat. Ar gyfer y gronfa ddata, bydd hyn yn cael ei fynegi yn y ffaith y bydd gennym gynnydd sydyn iawn yn amser ymateb y gronfa ddata, bydd y llwyth ar weinydd y gronfa ddata yn cynyddu. Ac o ganlyniad, bydd ein cais yn dioddef. Oherwydd os gwnaethoch wario 10 milieiliad yn eich cod ar gais i'r gronfa ddata, 10 milieiliad ar eich rhesymeg, yna fe weithiodd eich swyddogaeth 20 milieiliad allan. Ac yn awr bydd eich sefyllfa yn drist iawn.
A gadewch i ni weld beth sy'n digwydd. Mae'r graff chwith isaf yn dangos bod gennym drafodiad hir hir. Ac os edrychwn ar y graff chwith uchaf, gwelwn fod maint y tabl wedi neidio o ddau megabeit i 300 megabeit. Ar yr un pryd, nid yw swm y data yn y tabl wedi newid, hynny yw, mae yna lawer iawn o garbage.
Mae'r sefyllfa gyffredinol o ran amser ymateb cyfartalog gweinyddwyr hefyd wedi newid yn ôl nifer o orchmynion maint. Hynny yw, dechreuodd pob cais ar y gweinydd ysigo'n llwyr. Ac ar yr un pryd, lansiwyd prosesau mewnol Postgres yn wyneb autovacuum, sy'n ceisio gwneud rhywbeth a defnyddio adnoddau.
Beth sy'n digwydd i'n plât? Yr un. Neidiodd yr amser ymateb cyfartalog ar y dabled i fyny sawl gorchymyn maint. Os yn benodol o ran adnoddau a ddefnyddir, yna gwelwn fod y llwyth ar y prosesydd wedi cynyddu'n fawr. Dyma'r graff uchaf ar y dde. Ac mae wedi cynyddu oherwydd bod yn rhaid i'r prosesydd fynd trwy griw o linellau diwerth i chwilio am yr un sydd ei angen arnoch chi. Dyma'r graff isaf ar y dde. Ac o ganlyniad, dechreuodd nifer y galwadau yr eiliad ostwng yn fawr, oherwydd nid oes gan y gronfa ddata amser i brosesu'r un nifer o geisiadau.
Mae angen inni fynd yn ôl yn fyw. Rydyn ni'n dringo i'r Rhyngrwyd ac yn darganfod bod trafodion hir yn arwain at broblem. Rydym yn darganfod ac yn lladd y trafodiad hwn. Ac mae popeth yn mynd yn dda i ni. Mae popeth yn gweithio fel y dylai.
Fe wnaethon ni dawelu, ond ar ôl ychydig rydyn ni'n dechrau sylwi nad yw'r cais yn gweithio fel y gwnaeth cyn yr argyfwng. Mae ceisiadau'n cael eu prosesu i gyd yr un peth yn arafach, ac yn llawer arafach. Un a hanner i ddwywaith yn arafach yn benodol yn fy enghraifft i. Mae'r llwyth ar y gweinydd hefyd yn uwch nag yr oedd cyn y ddamwain.
A'r cwestiwn: "Beth sy'n digwydd i'r ganolfan ar hyn o bryd?". A chyda sail mae sefyllfa ganlynol. Ar y siart trafodion, gallwch weld ei fod wedi dod i ben ac nid oes unrhyw drafodion hirdymor mewn gwirionedd. Ond tyfodd dimensiynau'r plât yn ystod y ddamwain yn angheuol. Ac nid yw wedi gostwng ers hynny. Mae'r amser cyfartalog ar y sylfaen wedi sefydlogi. Ac mae'n ymddangos bod yr atebion yn mynd yn ddigonol gyda chyflymder derbyniol i ni. Daeth Autovacuum yn fwy egnïol a dechreuodd wneud rhywbeth gyda'r dabled, oherwydd mae angen iddo rhawio mwy o ddata.
Yn benodol, ar fwrdd sgôr y prawf, lle rydyn ni'n newid y balansau: mae'n ymddangos bod yr amser ymateb ar gyfer y cais wedi dychwelyd i normal. Ond mewn gwirionedd mae'n un a hanner gwaith yn uwch.
Ac erbyn y llwyth ar y prosesydd, gwelwn na ddychwelodd y llwyth ar y prosesydd i'r gwerth a ddymunir cyn y ddamwain. Ac mae'r rhesymau yno yn gorwedd yn y graff isaf ar y dde. Gwelir fod chwil- iad o ryw faint o gof. Hynny yw, i chwilio am y llinell a ddymunir, rydym yn gwario adnoddau gweinydd y gronfa ddata wrth ddidoli trwy ddata diwerth. Mae nifer y trafodion yr eiliad wedi sefydlogi.
Yn gyffredinol, yn dda, ond mae'r sefyllfa yn waeth nag yr oedd. Diraddio amlwg i'r gronfa ddata o ganlyniad i'n cymhwysiad sy'n gweithio gyda'r gronfa ddata hon.
Ac er mwyn deall beth sy'n digwydd yno, os nad oeddech yn yr adroddiad blaenorol, yna nawr ychydig bach o theori. Theori am y broses fewnol. Pam autovacuum a beth mae'n ei wneud?
Yn llythrennol yn gryno er mwyn deall. Ar ryw adeg, mae gennym fwrdd. Mae gennym ni resi yn y tabl. Gall y llinellau hyn fod yn weithredol, yn fyw, mae angen inni nawr. Maent wedi'u nodi mewn gwyrdd yn y llun. Ac mae yna linellau cau sydd eisoes wedi gweithio allan, wedi'u diweddaru, cofnodion newydd wedi ymddangos arnynt. Ac maent wedi'u nodi nad ydynt bellach yn ddiddorol i'r gronfa ddata. Ond maent yn gorwedd yn y bwrdd oherwydd hynodrwydd Postgres.
Pam mae angen gwactod arnoch chi? Mae Autovacuum yn dod ar ryw adeg, yn galw'r gronfa ddata ac yn gofyn iddo: "Rhowch id y trafodiad hynaf sydd ar agor yn y gronfa ddata ar hyn o bryd i mi." Mae'r gronfa ddata yn dychwelyd yr id hwn. Ac mae'r autovacuum, gan ddibynnu arno, yn mynd trwy'r llinellau yn y tabl. Ac os yw'n gweld bod rhai llinellau wedi'u newid gan drafodion llawer hŷn, yna mae ganddo'r hawl i'w nodi fel llinellau y gallwn eu hailddefnyddio yn y dyfodol trwy ysgrifennu data newydd yno. Mae hon yn broses gefndir.
Ar hyn o bryd, rydym yn parhau i weithio gyda'r gronfa ddata, rydym yn parhau i wneud rhai newidiadau yn y tabl. Ac ar y llinellau hyn, y gallwn eu hailddefnyddio, rydym yn ysgrifennu data newydd. Ac fel hyn cawn gylchred, hyny yw, y mae rhai hen linellau marw yn ymddangos yno drwy'r amser, yn lle hwynt ysgrifenwn linellau newydd sydd eu hangen arnom. A dyma'r cyflwr arferol i PostgreSQL weithio.
Beth ddigwyddodd yn ystod y ddamwain? Sut digwyddodd y broses hon?
Roedd gennym blât mewn rhyw gyflwr, rhai yn fyw, rhai llinellau marw. Mae'r autovacuum wedi cyrraedd. Gofynnodd i'r gronfa ddata beth yw ein trafodiad hynaf, beth yw ei id. Cefais yr id hwn, a all fod yn oriau lawer oed, efallai yn ddeg munud oed. Mae'n dibynnu ar ba mor drwm yw'r llwyth sydd gennych ar y gronfa ddata. Ac aeth i chwilio am linellau y gall eu nodi fel rhai wedi'u hailddefnyddio. Ac ni chefais y fath linellau yn ein bwrdd.
Ond ar hyn o bryd rydym yn parhau i weithio gyda'r bwrdd. Rydyn ni'n gwneud rhywbeth ynddo, yn ei ddiweddaru, yn newid y data. Beth ddylai'r gronfa ddata ei wneud ar hyn o bryd? Nid oes ganddi ddewis ond ychwanegu llinellau newydd at ddiwedd y tabl presennol. Ac felly atom ni mae maint y bwrdd yn dechrau chwyddo.
Mae gwir angen llinellau gwyrdd arnom i weithio. Ond yn ystod problem o'r fath, mae'n ymddangos bod canran y llinellau gwyrdd yn hynod o isel yng nghyfaint cyfan y tabl.
A phan fyddwn yn gweithredu ymholiad, mae'n rhaid i'r gronfa ddata fynd trwy'r holl linellau, yn goch a gwyrdd, i ddod o hyd i'r llinell gywir. A gelwir effaith chwyddo'r bwrdd â data diwerth yn "bloat", sydd hefyd yn bwyta ein gofod disg. Cofiwch, roedd yn 2 MB, nawr mae'n 300 MB? Nawr newidiwch megabeit i gigabeit a byddwch yn colli'ch holl adnoddau disg yn eithaf cyflym.
Beth yw'r goblygiadau i ni?
- Yn fy enghraifft i, mae'r tabl a'r mynegai wedi tyfu 150 o weithiau. Mae rhai o'n cleientiaid wedi cael mwy o achosion angheuol pan ddechreuodd gofod disg ddod i ben.
- Ni fydd byrddau byth yn crebachu ar eu pen eu hunain. Mewn rhai achosion, gall Autovacuum dorri cynffon y bwrdd i ffwrdd os mai dim ond llinellau marw sydd. Ond gan fod cylchdro cyson, gall un llinell werdd hongian ar y diwedd a pheidio â chael ei diweddaru, a bydd y gweddill i gyd yn rhywle ar ddechrau'r plât yn cael ei gofnodi. Ond mae hwn yn ddigwyddiad mor annhebygol y bydd eich bwrdd ei hun yn lleihau mewn maint, felly ni ddylech obeithio amdano.
- Mae angen i'r gronfa ddata ddidoli trwy'r pentwr cyfan o linellau diwerth. Ac rydym yn gwastraffu adnoddau disg, yn gwastraffu adnoddau prosesydd a thrydan.
- Ac mae hyn yn effeithio'n uniongyrchol ar ein cais, oherwydd pe baem ar y dechrau yn gwario 10 milieiliad ar gais, 10 milieiliad ar ein cod, yna yn ystod y ddamwain fe ddechreuon ni wario eiliad ar gais a 10 milieiliad ar god, h.y., gorchymyn o gostyngodd perfformiad cais maint. A phan gafodd y ddamwain ei datrys, dechreuon ni wario 20 milieiliad fesul cais, 10 milieiliad fesul cod. Mae hyn yn golygu ein bod yn dal i suddo unwaith a hanner o ran perfformiad. Ac mae hyn i gyd oherwydd un trafodiad a oedd yn hongian, ac, efallai, trwy ein bai ni.
- A’r cwestiwn: “Sut alla i gael popeth yn ôl?” Fel bod popeth yn iawn gyda ni a cheisiadau’n rhedeg mor gyflym â chyn y ddamwain.
Ar gyfer hyn, mae cylch penodol o waith yn cael ei wneud.
Yn gyntaf mae angen i ni ddod o hyd i'r tablau problemus sydd wedi chwyddo. Rydym yn deall bod rhai tablau yn cofnodi'n fwy gweithredol, rhai yn llai gweithredol. Ac ar gyfer hyn rydym yn defnyddio'r estyniad . Trwy osod yr estyniad hwn, gallwch ysgrifennu ymholiadau i'ch helpu i ddod o hyd i dablau sy'n ddigon chwyddedig.
Unwaith y byddwch wedi dod o hyd i'r tablau hyn, mae angen eu cywasgu. Mae yna offer ar gyfer hyn eisoes. Yn ein cwmni, rydym yn defnyddio tri offer. Y cyntaf yw'r VACUUM LLAWN adeiledig. Mae'n greulon, llym a didrugaredd, ond weithiau mae'n ddefnyddiol iawn. и yn gyfleustodau trydydd parti ar gyfer cywasgu tablau. Ac maen nhw'n fwy gofalus am y gronfa ddata.
Fe'u defnyddir yn dibynnu ar yr hyn sy'n fwy cyfleus i chi. Ond byddaf yn siarad am hyn o'r diwedd. Y prif beth yw bod tri offeryn. Mae digon i ddewis ohonynt.
Ar ôl i ni gywiro popeth, gan sicrhau bod popeth yn iawn, dylem wybod sut i atal y sefyllfa hon yn y dyfodol:
- Mae'n weddol hawdd ei atal. Mae angen i chi fonitro hyd y sesiynau ar y gweinydd Meistr. Sesiynau arbennig o beryglus yn y segur mewn cyflwr trafodiad. Dyma'r rhai sydd newydd agor trafodiad, gwneud rhywbeth a gadael, neu hongian yn syml, wedi mynd ar goll yn y cod.
- Ac i chi, fel datblygwyr, mae'n bwysig profi'r cod ar yr adeg y mae'r sefyllfaoedd hyn yn codi. Nid yw'n anodd ei wneud. Bydd hwn yn wiriad defnyddiol. Byddwch yn osgoi llawer o broblemau "plentynaidd" sy'n gysylltiedig â thrafodion hir.
Ar y graffiau hyn, roeddwn i eisiau dangos i chi sut y newidiodd y tabl ac ymddygiad y gronfa ddata ar ôl i mi basio VACUUM LLAWN ar y bwrdd yn yr achos hwn. Nid fy nghynhyrchiad i yw hwn.
Dychwelodd maint y bwrdd ar unwaith i'w gyflwr gweithio arferol o ychydig megabeit. Ni effeithiodd hyn yn fawr ar yr amser ymateb cyfartalog ar draws y gweinydd.
Ond yn benodol yn ein tabl prawf, lle gwnaethom ddiweddaru balansau'r cyfrif, gwelwn fod yr amser ymateb cyfartalog i gais i ddiweddaru'r data yn y dabled wedi'i leihau i lefelau cyn damwain. Gostyngodd yr adnoddau a ddefnyddiwyd gan y prosesydd i gyflawni'r cais hwn i lefelau cyn y ddamwain hefyd. Ac mae'r graff isaf ar y dde yn dangos ein bod nawr yn dod o hyd i'r union linell sydd ei hangen arnom ar unwaith, heb fynd trwy'r pentwr o linellau marw a oedd cyn i'r bwrdd gael ei gywasgu. Ac arhosodd yr amser ymholi ar gyfartaledd tua'r un lefel. Ond yma mae gennyf, yn hytrach, wall fy nghaledwedd.
Dyma lle mae'r stori gyntaf yn gorffen. Hi yw'r mwyaf cyffredin. Ac mae'n digwydd i bawb, waeth beth fo profiad y cleient, pa mor gymwys yw rhaglenwyr. Yn hwyr neu'n hwyrach mae'n digwydd.
Yr ail stori, lle rydym yn dosbarthu'r llwyth ac yn gwneud y gorau o adnoddau gweinydd
- Rydyn ni wedi tyfu i fyny ac wedi dod yn fechgyn difrifol. Ac rydym yn deall bod gennym atgynhyrchiad a byddai'n dda inni gydbwyso'r llwyth: ysgrifennwch at y Meistr, a darllenwch o'r replica. Ac fel arfer mae'r sefyllfa hon yn codi pan fyddwn am baratoi rhyw fath o adroddiadau neu ETL. Ac mae busnes yn hapus iawn amdano. Mae wir eisiau amrywiaeth o adroddiadau gyda chriw o ddadansoddeg gymhleth.
- Mae adroddiadau'n para am oriau lawer, oherwydd ni ellir cyfrifo dadansoddeg gymhleth mewn milieiliadau. Rydyn ni, fel bois dewr, yn ysgrifennu cod. Rydyn ni'n ei wneud yn y cais mewnosod rydyn ni'n ei gofnodi ar y Meistr, rydyn ni'n perfformio adroddiadau ar y replica.
- Rydym yn dosbarthu'r llwyth.
- Mae popeth yn gweithio'n berffaith. Rydym yn wych.
A sut olwg sydd ar y sefyllfa hon? Yn benodol, ar y siartiau hyn, ychwanegais hefyd hyd y trafodion o'r replica trwy gydol y trafodiad. Mae pob graff arall yn cyfeirio at y Prif Weinyddwr yn unig.
Erbyn hyn, roedd fy mwrdd adrodd wedi tyfu. Mae mwy ohonyn nhw. Gallwn weld bod amser ymateb y gweinydd ar gyfartaledd yn sefydlog. Gallwn weld bod gennym drafodiad hirsefydlog ar y replica sy'n rhedeg am 2 awr. Gwelwn waith tawel y autovacuum, sy'n prosesu llinellau marw. Ac rydyn ni i gyd yn dda.
Yn benodol, yn ôl y dabled prawf, rydym yn parhau i ddiweddaru'r balansau ar y cyfrifon yno. Ac mae gennym hefyd amser ymateb sefydlog ar gais, defnydd sefydlog o adnoddau. Mae popeth yn iawn gyda ni.
Mae popeth yn iawn tan yr eiliad pan fydd yr adroddiadau hyn yn dechrau tanio'n ôl atom ar wrthdaro ag atgynhyrchu. Ac maen nhw'n saethu'n ôl yn rheolaidd.
Rydyn ni'n mynd ar-lein ac yn dechrau darllen pam mae hyn yn digwydd. Ac rydym yn dod o hyd i ateb.
Yr ateb cyntaf yw cynyddu'r hwyrni atgynhyrchu. Gwyddom fod ein hadroddiad yn rhedeg am 3 awr. Gosodwch yr oedi wrth ddyblygu i 3 awr. Dechreuwn bopeth, ond rydym yn dal i gael problemau gyda'r ffaith bod adroddiadau weithiau'n cael eu saethu'n ôl.
Rydyn ni eisiau i bopeth fod yn berffaith. Gadewch i ni fynd ymhellach. Ac rydym yn dod o hyd i leoliad cŵl ar y Rhyngrwyd - hot_standby_feedback. Rydyn ni'n ei droi ymlaen. Mae Hot_standby_feedback yn ein galluogi i ddal yr awtocws i redeg ar y Meistr. Felly, rydym yn cael gwared yn llwyr ar wrthdaro dyblygu. Ac rydym i gyd yn gweithio'n dda gydag adroddiadau.
A beth sy'n digwydd gyda'r gweinydd Meistr ar hyn o bryd? A chyda'r gweinydd Meistr, mae gennym drychineb llwyr. Rydyn ni nawr yn gweld siartiau gyda'r ddau leoliad hyn ymlaen. A gwelwn fod y sesiwn ar y replica rywsut wedi dechrau dylanwadu ar y sefyllfa ar y gweinydd Meistr. Mae'n cael effaith oherwydd ei fod wedi atal y autovacuum sy'n glanhau'r llinellau marw. Mae maint ein bwrdd wedi cynyddu eto. Roedd yr amser cyflawni ymholiad ar gyfartaledd ar draws y gronfa ddata gyfan hefyd wedi cynyddu'n aruthrol. Mae'r autovacuums tynhau i fyny ychydig.
Yn benodol, ar ein plât, gwelwn fod y diweddariad data arno hefyd wedi neidio i'r awyr. Yn yr un modd, mae'r defnydd o adnoddau prosesydd wedi cynyddu'n fawr. Ailadroddwn eto dros nifer fawr o linellau marw diwerth. A'r amser ymateb ar y dabled hon, mae nifer y trafodion wedi gostwng.
Sut olwg fydd arno os na wyddom am beth yr oeddwn yn siarad o'r blaen?
- Rydym yn dechrau chwilio am broblemau. Pe baem yn dod ar draws problemau yn y rhan gyntaf, rydym yn gwybod efallai mai dyma'r rheswm dros drafodiad hir ac rydym yn dringo ar y Meistr. Mae'r broblem gyda'r Meistr. Selsig iddo. Mae'n cynhesu, mae ganddo Gyfartaledd Llwyth o dan gant.
- Mae ceisiadau yn arafu yno, ond nid ydym yn gweld unrhyw drafodion hirdymor yno. Ac nid ydym yn deall beth sy'n digwydd. Nid ydym yn gwybod ble i edrych.
- Gwirio caledwedd gweinydd. Efallai bod ein cyrch wedi dymchwel. Efallai inni losgi'r bar cof. Oes, gall unrhyw beth fod. Ond na, mae'r gweinyddwyr yn newydd, mae popeth yn gweithio'n iawn.
- Mae pawb yn rhedeg: gweinyddwyr, datblygwyr a'r cyfarwyddwr. Does dim byd yn helpu.
- Ac ar ryw adeg, mae popeth yn sydyn yn dechrau cywiro ei hun.
Ar y replica, ar y pryd, roedd y cais yn gweithio allan ac yn gadael. Rydym wedi derbyn adroddiad. Mae'r busnes yn dal yn hapus. Fel y gallwch weld, mae ein tabl wedi tyfu eto ac nid yw'n mynd i leihau. Ar y siart gyda sesiynau, gadewais ddarn o'r trafodiad hir hwn o'r replica, fel y gallwch werthuso pa mor hir y mae'n ei gymryd nes bod y sefyllfa'n sefydlogi.
Mae'r sesiwn wedi mynd. A dim ond ar ôl peth amser y gweinydd yn dod fwy neu lai mewn trefn. Ac mae'r amser ymateb cyfartalog ar gyfer ceisiadau ar y gweinydd Meistr yn dychwelyd i normal. Oherwydd, yn olaf, cafodd yr autovacuum gyfle i lanhau, nodi'r llinellau marw hyn. A dechreuodd wneud ei waith. A pha mor gyflym y mae'n ei wneud, mor gyflym byddwn mewn trefn.
Ar y bwrdd prawf, lle rydyn ni'n diweddaru balansau'r cyfrif, rydyn ni'n gweld yr un llun yn union. Mae'r amser diweddaru cyfrif cyfartalog hefyd yn normaleiddio'n raddol. Mae'r adnoddau a ddefnyddir gan y prosesydd hefyd yn cael eu lleihau. Ac mae nifer y trafodion yr eiliad yn ôl i normal. Ond eto, yn ôl i normal, nid yr un peth ag oedd gennym ni cyn y ddamwain.
Mewn unrhyw achos, rydym yn cael gostyngiad mewn perfformiad, fel yn yr achos cyntaf, un a hanner i ddwywaith, ac weithiau hyd yn oed yn fwy.
Mae'n ymddangos ein bod ni wedi gwneud popeth yn iawn. Dosbarthwch y llwyth. Nid yw'r offer yn segur. Yn ôl y meddwl, maent yn torri y ceisiadau, ond yn dal i fod popeth yn troi allan yn wael.
- Peidio â galluogi hot_standby_feedback? Ydy, ni argymhellir ei droi ymlaen heb resymau arbennig o gryf. Oherwydd bod y tro hwn yn effeithio'n uniongyrchol ar y Prif Weinyddwr ac yn atal gwaith yr autovacuum yno. Trwy ei droi ymlaen ar rai replica ac anghofio amdano, gallwch ladd y Meistr a chael problemau mawr gyda'r cais.
- Cynyddu max_standby_streaming_delay? Ydy, ar gyfer adroddiadau y mae. Os oes gennych adroddiad tair awr ac nad ydych am iddo chwalu oherwydd gwrthdaro atgynhyrchu, yna cynyddwch yr oedi. Nid yw adroddiad hir byth yn gofyn am ddata sydd wedi mynd i mewn i'r gronfa ddata ar hyn o bryd. Os oes gennych chi am dair awr, yna rydych chi'n ei redeg am ryw hen gyfnod data. A chi, bod tair awr o oedi, y chwe awr o oedi - ni fydd yn chwarae unrhyw rôl, ond byddwch yn derbyn adroddiadau yn gyson ac nid yn gwybod y problemau gyda'u cwymp.
- Yn naturiol, mae angen i chi reoli sesiynau hir ar atgynyrchiadau, yn enwedig os penderfynwch alluogi hot_standby_feedback ar replica. Oherwydd gallai fod yn unrhyw beth. Rhoesom y sylw hwn i'r datblygwr fel y byddai'n profi'r ceisiadau. Ysgrifennodd gais gwallgof. Dechreuodd ac aeth i yfed te, a chawsom y Meistr sefydledig. Neu fe wnaethom lansio'r cais anghywir yno. Mae'r sefyllfaoedd yn amrywiol. Mae angen rheoli sesiynau ar gopïau mor ofalus ag ar y Meistr.
- Ac os oes gennych ymholiadau cyflym a hir ar atgynyrchiadau, yna yn yr achos hwn mae'n well eu rhannu i ddosbarthu'r llwyth. Mae hwn yn ddolen i streaming_delay. Am gyflym i gael un replica gydag ychydig o oedi wrth ddyblygu. Ar gyfer ceisiadau adrodd hirdymor, mae gennych atgynhyrchiad a all fod ar ei hôl hi o 6 awr, fesul diwrnod. Mae hon yn sefyllfa gwbl normal.
Rydym yn dileu'r canlyniadau yn yr un modd:
- Rydym yn dod o hyd i fyrddau chwyddedig.
- Ac rydym yn cywasgu gyda'r offeryn mwyaf cyfleus sy'n addas i ni.
Daw'r ail stori i ben yma. Symudwn ymlaen at y drydedd stori.
Hefyd yn bur gyffredin i ni, yn yr hwn yr ydym yn gwneyd yr ymfudiad.
- Mae unrhyw gynnyrch meddalwedd yn tyfu. Mae gofynion yn newid. Beth bynnag, rydym am ddatblygu. Ac mae'n digwydd bod angen inni ddiweddaru'r data yn y tabl, sef rhedeg y diweddariad o ran ein mudo i'r swyddogaeth newydd yr ydym yn ei rhoi ar waith fel rhan o'n datblygiad.
- Nid yw'r hen fformat data yn addas. Gadewch i ni ddweud ein bod yn troi yn awr at yr ail dabl, lle mae gennyf weithrediadau ar y cyfrifon hyn. Ac, gadewch i ni ddweud eu bod mewn rubles, a phenderfynwyd cynyddu cywirdeb a'i wneud mewn kopecks. Ac ar gyfer hyn mae angen i ni wneud diweddariad: lluoswch y maes gyda swm y llawdriniaeth gan gant.
- Yn y byd sydd ohoni, rydym yn defnyddio offer fersiwn cronfa ddata awtomataidd. Gadewch i ni ddweud . Rydym yn cofrestru ein mudo yno. Rydyn ni'n ei brofi ar ein sylfaen prawf. Mae popeth yn iawn. Mae'r diweddariad yn rhedeg. Mae blociau'n gweithio am ychydig, ond rydyn ni'n cael data wedi'i ddiweddaru. A gallwn lansio swyddogaeth newydd ar hyn. Pob un wedi'i brofi a'i wirio. Cadarnhawyd y cyfan.
- Wedi gwneud gwaith wedi'i gynllunio, gwneud mudo.
Dyma'r mudo gyda'r diweddariad a gyflwynwyd o'ch blaen. Gan fod gen i weithrediadau ar gyfrifon, roedd y plât yn 15 GB. A chan ein bod ni'n diweddaru pob llinell, rydyn ni wedi dyblu'r plât gyda'r diweddariad, oherwydd rydyn ni wedi trosysgrifo pob llinell.
Yn ystod y mudo, ni allem wneud unrhyw beth gyda'r label hwn, oherwydd roedd yr holl geisiadau amdano wedi'u ciwio ac yn aros i'r diweddariad hwn ddod i ben. Ond yma rwyf am dynnu eich sylw at y niferoedd sydd ar yr echelin fertigol. Hynny yw, mae gennym amser cais cyfartalog cyn mudo tua 5 milieiliad a llwyth ar y prosesydd, mae nifer y gweithrediadau bloc ar gyfer darllen cof disg yn llai na 7,5.
Fe wnaethon ni fudo a chael problemau eto.
Roedd y mudo yn llwyddiannus, ond:
- Dechreuodd yr hen swyddogaeth redeg yn hirach.
- Mae'r tabl wedi cynyddu mewn maint eto.
- Mae'r llwyth ar y gweinydd eto wedi dod yn fwy nag yr oedd.
- Ac, wrth gwrs, rydym yn dal i fod yn ffidlan gyda'r ymarferoldeb a weithiodd yn dda, fe wnaethom ei wella ychydig.
Ac mae hyn eto yn bloat, sydd eto yn difetha ein bywydau.
Yma rwy'n dangos nad yw'r tabl, fel y ddau achos blaenorol, yn mynd i ddychwelyd i'r meintiau blaenorol. Mae'n ymddangos bod y llwyth cyfartalog ar y gweinydd yn ddigonol.
Ac os trown at y bwrdd gyda chyfrifon, yna fe welwn fod yr amser ymgeisio cyfartalog wedi dyblu ar gyfer y tabl hwn. Neidiodd y llwyth ar y prosesydd a'r nifer o linellau i'w datrys er cof yn uwch na 7,5, ond roedd yn is. A neidiodd yn achos proseswyr 2 waith, yn achos gweithrediadau bloc 1,5 gwaith, h.y. cawsom ddiraddiad ym mherfformiad y gweinydd. Ac o ganlyniad - diraddio perfformiad ein cais. Ar yr un pryd, arhosodd nifer y galwadau tua'r un lefel.
Ac yma y prif beth yw deall sut i wneud mudo o'r fath yn gywir. Ac mae angen eu gwneud. Rydyn ni'n gwneud y mudo hyn yn eithaf rheolaidd.
- Nid yw mudo mawr o'r fath yn cael ei wneud yn awtomatig. Rhaid eu rheoli bob amser.
- Angen goruchwyliaeth gan berson gwybodus. Os oes gennych DBA ar y tîm, gadewch i'r DBA ei wneud. Ei swydd ef ydyw. Os na, gadewch i'r person mwyaf profiadol ei wneud, pwy a ŵyr sut i weithio gyda chronfeydd data.
- Y sgema cronfa ddata newydd, hyd yn oed os byddwn yn diweddaru un golofn, rydym bob amser yn paratoi fesul cam, h.y. ymlaen llaw cyn i fersiwn newydd y cais gael ei gyflwyno:
- Ychwanegir meysydd newydd lle byddwn yn ysgrifennu'r data diweddaraf yn unig.
- Rydym yn trosglwyddo data o'r hen faes i'r maes newydd mewn rhannau bach. Pam ydym ni'n gwneud hyn? Yn gyntaf, rydym bob amser yn rheoli proses y broses hon. Gwyddom ein bod eisoes wedi trosglwyddo cymaint o sypiau ac mae gennym gymaint ar ôl.
- A'r ail effaith gadarnhaol yw ein bod yn cau trafodiad rhwng pob swp o'r fath, yn agor un newydd, ac mae hyn yn ei gwneud hi'n bosibl i'r autovacuum weithio yn ôl y plât, i nodi llinellau marw i'w hailddefnyddio.
- Ar gyfer y llinellau a fydd yn ymddangos yn ystod gweithrediad y cais (mae gennym yr hen gais o hyd), rydym yn ychwanegu sbardun sy'n ysgrifennu gwerthoedd newydd i feysydd newydd. Yn ein hachos ni, mae hwn yn lluosiad â chant o'r hen werth.
- Os ydym yn gwbl ystyfnig ac eisiau'r un maes, yna ar ôl cwblhau'r holl fudiadau a chyn treiglo'r fersiwn newydd o'r cais, rydym yn syml ailenwi'r meysydd. Yr hen rai i ryw enw dyfeisiedig, ac ailenwir y meysydd newydd i'r hen rai.
- A dim ond ar ôl hynny rydyn ni'n lansio fersiwn newydd o'r cais.
Ac ar yr un pryd, ni fyddwn yn cael bloat ac ni fyddwn yn sag mewn perfformiad.
Dyma ddiwedd y drydedd stori.
Ac yn awr ychydig mwy am yr offer y soniais amdanynt yn y stori gyntaf un.
Cyn chwilio am bloat, rhaid i chi osod yr estyniad .
Er mwyn i chi beidio â dyfeisio ceisiadau, rydym eisoes wedi ysgrifennu'r ceisiadau hyn yn ein gwaith. Gallwch eu defnyddio. Mae dau gais yma.
- Mae'r un cyntaf yn cymryd amser eithaf hir, ond bydd yn dangos union werthoedd bloat i chi yn ôl y tabl.
- Mae'r ail un yn gweithio'n gyflymach ac yn effeithiol iawn pan fydd angen i chi werthuso'n gyflym a oes bloat ai peidio yn y tabl. A dylech chi hefyd ddeall bod yna chwythiad mewn bwrdd Postgres bob amser. Mae hyn yn nodwedd o'i fodel MVCC.
- Ac mae bloat 20% yn iawn ar gyfer tablau yn y rhan fwyaf o achosion. Hynny yw, ni ddylech boeni a chywasgu'r tabl hwn.
Fe wnaethom gyfrifo sut i nodi tablau sydd wedi chwyddo gyda ni, ar ben hynny, pan fyddant wedi chwyddo gan ddata diwerth.
Nawr am sut i drwsio bloat:
- Os oes gennym blât bach a disgiau da, h.y. ar blât hyd at gigabeit, mae’n ddigon posibl defnyddio VACUUM LLAWN. Bydd yn cymryd clo unigryw oddi wrthych am ychydig eiliadau, ac yn iawn, ond bydd yn gwneud popeth yn gyflym ac yn llym. Beth mae VACUUM FULL yn ei wneud? Mae'n cymryd clo unigryw ar y bwrdd ac yn ailysgrifennu'r rhesi byw o'r hen fyrddau i'r bwrdd newydd. Ac ar y diwedd mae'n cymryd eu lle. Yn dileu hen ffeiliau, yn rhoi rhai newydd yn lle hen rai. Ond am gyfnod ei waith, mae'n cymryd clo unigryw ar y bwrdd. Mae hyn yn golygu na allwch chi wneud dim â'r tabl hwn: nac ysgrifennu ato, na darllen i mewn iddo, na'i addasu. Ac mae VACUUM LLAWN angen lle disg ychwanegol i ysgrifennu data.
- Offeryn nesaf . Yn ôl ei egwyddor, mae'n debyg iawn i VACUUM LLAWN, oherwydd mae hefyd yn trosysgrifo data o hen ffeiliau i rai newydd ac yn eu disodli yn y tabl. Ond ar yr un pryd, nid yw'n cymryd clo unigryw ar y bwrdd ar ddechrau ei waith, ond dim ond ar hyn o bryd y mae'n ei gymryd pan fydd ganddo ddata parod er mwyn disodli'r ffeiliau. Mae ganddo'r un gofynion adnoddau disg â VACUUM LLAWN. Mae angen lle disg ychwanegol arnoch, ac mae hyn weithiau'n hollbwysig os oes gennych dablau terabyte. Ac mae'n eithaf ffyrnig ar y prosesydd, oherwydd ei fod yn gweithio'n weithredol gydag I / O.
- Y trydydd cyfleustodau yw . Mae’n trin adnoddau’n fwy gofalus, oherwydd mae’n gweithio ar egwyddorion ychydig yn wahanol. Prif hanfod pgcompacttable yw ei fod yn symud pob rhes fyw i ddechrau'r tabl gyda diweddariadau yn y tabl. Ac yna mae'n cychwyn y gwactod ar y bwrdd hwn, oherwydd rydyn ni'n gwybod bod gennym ni resi byw ar y dechrau a rhesi marw ar y diwedd. Ac mae'r gwactod ei hun yn torri'r gynffon hon i ffwrdd, hynny yw, nid oes angen llawer o le disg ychwanegol arno. Ac ar yr un pryd, gall adnoddau gael eu gwasgu o hyd.
Popeth gydag offer.
Os yw'r pwnc bloat yn ddiddorol i chi o ran cloddio ymhellach i mewn, dyma rai dolenni defnyddiol i chi:
- yw adroddiad fy nghyd-Aelod. Mae'n gyffredinol am ble mae lle Postgres yn mynd yng nghwrs ei waith a'i fywyd. Ac mae darn technegol mawr a manwl iawn ar gyfer DBAs am bloat.
- yn ddolen i'n cadwrfa, lle rydym yn storio criw o sgriptiau defnyddiol ar gyfer gwirio statws y gronfa ddata. Yno gallwch ddod o hyd i sgriptiau chwilio bloat.
- и dolenni i offer a fydd yn eich helpu i gywasgu'r platiau.
- Dyma bost gan fy nghydweithiwr. Yno mae'n dadansoddi bloat yn fanwl ac yn dechnegol yn eithaf manwl sydd eisoes ar lefel sy'n agos at weinyddwyr.
Yma ceisiais ddangos stori arswyd i ddatblygwyr, oherwydd nhw yw ein cleientiaid uniongyrchol o gronfeydd data a rhaid iddynt ddeall beth a pha gamau sy'n arwain at. Rwy'n gobeithio fy mod wedi llwyddo. Diolch am eich sylw!
cwestiynau
Diolch am yr adroddiad! Soniasoch am sut y gellir nodi problemau. Sut y gellir eu rhybuddio? Hynny yw, roedd gennyf sefyllfa lle'r oedd ceisiadau'n hongian nid yn unig oherwydd eu bod yn troi at rai gwasanaethau allanol. Dim ond ambell uniad gwyllt ydoedd. Roedd rhai ceisiadau bach, diniwed a oedd yn hongian o gwmpas am ddiwrnod, ac yna'n dechrau gwneud rhyw fath o nonsens. Hynny yw, mae'n debyg iawn i'r hyn rydych chi'n ei ddisgrifio. Sut i'w olrhain? Eisteddwch a gwyliwch yn gyson, pa gais sy'n sownd? Sut y gellir atal hyn?
Yn yr achos hwn, mae hon yn dasg i weinyddwyr eich cwmni, nid o reidrwydd ar gyfer y DBA.
Rwy'n weinyddwr.
Mae gan PostgreSQL olwg o'r enw pg_stat_activity sy'n dangos ymholiadau sydd ar y gweill. A gallwch weld pa mor hir y mae'n hongian yno.
Rhaid i mi ddod i mewn bob 5 munud ac edrych?
Sefydlu cron a gwirio. Os oes gennych gais hir, ysgrifennwch lythyr a dyna ni. Hynny yw, nid oes angen i chi edrych â'ch llygaid, gall hyn fod yn awtomataidd. Byddwch yn derbyn llythyr, byddwch yn ymateb iddo. Neu gallwch chi saethu'n awtomatig.
A oes rhesymau clir pam fod hyn yn digwydd?
Rwyf wedi rhestru rhai. Enghreifftiau eraill mwy cymhleth. A gall fod sgwrs hir.
Diolch am yr adroddiad! Roeddwn i eisiau egluro'r cyfleustodau pg_repack. Os nad yw'n cymryd clo unigryw, yna ...
Mae hi'n gwneud clo unigryw.
... yna gallwn o bosibl golli data. Oni ddylai fy app fod yn recordio unrhyw beth ar hyn o bryd?
Na, mae'n gweithio'n dawel gyda'r bwrdd, h.y. mae pg_repack yn trosglwyddo'r holl linellau byw sydd yno yn gyntaf. Yn naturiol, mae rhyw fath o gofnod yn y tabl yn mynd ymlaen. Mae'n taflu'r ponytail hwn.
Hynny yw, a yw'n dal i wneud hynny ar y diwedd?
Ar y diwedd, mae'n cymryd clo unigryw ar gyfnewid y ffeiliau hyn.
A fydd yn gyflymach na VACUUM LLAWN?
WACUUM LLAWN, fel y dechreuodd, ar unwaith cymerodd clo unigryw. A hyd nes y bydd yn gwneud popeth, ni fydd yn gadael iddi fynd. Ac mae pg_repack yn cymryd clo unigryw yn unig ar adeg ailosod ffeiliau. Ar y pwynt hwn, nid ydych yn ysgrifennu yno, ond ni fydd y data yn cael ei golli, bydd popeth mewn trefn.
Helo! Soniasoch am waith autovacuum. Roedd graff gyda chelloedd coch, melyn a gwyrdd o'r cofnod. Hynny yw, rhai melyn - nododd eu bod wedi'u dileu. Ac o ganlyniad, gallwch chi ysgrifennu rhywbeth newydd ynddynt?
Oes. Nid yw Postgres yn tynnu rhesi. Mae ganddo'r fath benodolrwydd. Pe baem yn diweddaru'r llinell, fe wnaethom farcio bod yr hen un wedi'i dileu. Mae'r id trafodiad a newidiodd y llinell hon yn codi yno, ac rydym yn ysgrifennu llinell newydd. Ac mae gennym ni sesiynau a all o bosibl eu darllen. Ar ryw adeg, maen nhw'n mynd yn eithaf hen. A hanfod y autovacuum yw ei fod yn rhedeg trwy'r llinellau hyn ac yn eu nodi fel rhai diangen. Ac yno gallwch chi drosysgrifo'r data.
Rwy'n deall. Ond nid yw'r cwestiwn yn ymwneud â hynny. Doeddwn i ddim yn cytuno. Gadewch i ni ddweud bod gennym fwrdd. Mae ganddo feysydd maint amrywiol. Ac os ceisiaf fewnosod rhywbeth newydd, yna efallai na fydd yn ffitio i'r hen gell.
Na, mae yna beth bynnag y llinell gyfan yn cael ei diweddaru. Mae gan Postgres ddau fodel storio. Mae'n dewis o'r math o ddata. Mae yna ddata sy'n cael ei storio'n uniongyrchol yn y tabl, ac mae data tos hefyd. Mae'r rhain yn symiau mawr o ddata: testun, json. Maent yn cael eu storio mewn tabledi ar wahân. Ac yn ôl y tabledi hyn, mae'r un stori â bloat yn digwydd, hynny yw, mae popeth yr un peth. Maent newydd gael eu rhestru ar wahân.
Diolch am yr adroddiad! Pa mor dderbyniol yw defnyddio ceisiadau terfyn amser datganiadau i gyfyngu ar yr hyd?
Derbyniol iawn. Rydyn ni'n ei ddefnyddio ym mhobman. A chan nad oes gennym ein gwasanaethau ein hunain, rydym yn darparu cymorth o bell, mae yna lawer iawn o amrywiaeth o gleientiaid. Ac mae pawb yn eithaf bodlon â hyn. Hynny yw, mae gennym swyddi yn cron sy'n gwirio. Dim ond bod hyd y sesiynau yn cael ei drafod gyda'r cleient, ac nid ydym yn hoelio cyn hynny. Gallai fod yn funud, gallai fod yn 10 munud. Mae'n dibynnu ar y llwyth ar y sylfaen a'i bwrpas. Ond rydyn ni i gyd yn defnyddio pg_stat_activity.
Diolch am yr adroddiad! Rwy'n ceisio rhoi cynnig ar eich adroddiad ar gyfer fy ngheisiadau. Ac mae'n ymddangos ein bod ni'n dechrau trafodiad ym mhobman, ac rydyn ni'n ei gwblhau'n benodol ym mhobman. Os yw'n eithriad, yna mae'r un treigl yn ôl yn digwydd. Ac yna meddyliais. Wedi'r cyfan, ni all y trafodiad ddechrau yn benodol. Mae hyn yn awgrym i'r ferch, mae'n debyg. Os byddaf yn gwneud diweddariad cofnod yn unig, a fydd y trafodiad yn cychwyn yn PostgreSQL a dim ond yn dod i ben pan fydd y cysylltiad wedi'i ddatgysylltu?
Os ydych chi'n siarad nawr am lefel y cais, yna mae'n dibynnu ar y gyrrwr rydych chi'n ei ddefnyddio, ar yr ORM sy'n cael ei ddefnyddio. Mae yna lawer o leoliadau yno. Os oes gennych chi ymrwymiad awtomatig wedi'i alluogi, yna mae trafodiad yn dechrau yno ac yn cau ar unwaith.
Hynny yw, mae'n cau yn syth ar ôl y diweddariad?
Mae'n dibynnu ar y gosodiadau. Enwais un gosodiad. Ymrwymiad awtomatig yw hwn. Mae hi'n eithaf cyffredin. Os yw wedi'i alluogi, yna agorwyd a chaewyd y trafodiad. Oni bai eich bod wedi dweud yn benodol “dechrau trafodiad” a “trafodiad terfynu”, ond yn syml wedi lansio cais i mewn i'r sesiwn.
Helo! Diolch am yr adroddiad! Dychmygwch fod gennym gronfa ddata sy'n chwyddo ac yn chwyddo ac yna mae'r gweinydd yn rhedeg allan o ofod. A oes unrhyw offer i ddatrys y sefyllfa hon?
Mae angen monitro'r lle ar y gweinydd mewn ffordd dda.
Er enghraifft, aeth DBA i yfed te, roedd mewn cyrchfan, ac ati.
Pan fydd system ffeiliau yn cael ei chreu, mae o leiaf rhywfaint o le wrth gefn yn cael ei greu lle nad yw data'n cael ei ysgrifennu.
Beth os yw'n gwbl sero?
Yno fe'i gelwir yn ofod neilltuedig, hynny yw, gellir ei ryddhau, ac yn dibynnu ar ba mor fawr y cafodd ei greu, cawsoch le am ddim. Yn ddiofyn, nid wyf yn gwybod faint sydd yno. Ac mewn achos arall, danfonwch ddisgiau fel bod gennych chi le i gynnal llawdriniaeth adfer. Gallwch ddileu rhai tabl rydych yn sicr o beidio â bod angen.
Onid oes offer eraill?
Mae bob amser wedi'i wneud â llaw. Ac yn y lle datgelir beth sy'n well i'w wneud yno, oherwydd mae data sy'n hollbwysig, nid yw'n hanfodol. Ac ar gyfer pob cronfa ddata a chymhwysiad sy'n gweithio gydag ef, mae'n dibynnu ar y busnes. Mae bob amser yn cael ei benderfynu yn y fan a'r lle.
Diolch am yr adroddiad! Mae gennyf ddau gwestiwn. Yn gyntaf, dangosasoch sleidiau lle dangoswyd yn achos trafodion hongian, bod maint y gofod bwrdd a maint y mynegai yn tyfu. Ac ymhellach ar yr adroddiad roedd yna griw o gyfleustodau sy'n pacio'r dabled. A beth am y mynegai?
Maen nhw'n eu pacio hefyd.
Ond nid yw'r gwactod yn effeithio ar y mynegai?
Mae rhai yn gweithio gyda mynegai. Er enghraifft pg_rapack, pgcompacttable. Mae gwactod yn ail-greu mynegeion, yn effeithio arnynt. Mae gan VACUUM LLAW hanfod trosysgrifo popeth, h.y. mae'n gweithio gyda phawb.
A'r ail gwestiwn. Nid oeddwn yn deall pam mae adroddiadau ar atgynyrchiadau yn dibynnu cymaint ar atgynhyrchu ei hun. Roedd yn ymddangos i mi fod adroddiadau'n cael eu darllen, ac atgynhyrchu yn ysgrifennu.
Beth sy'n achosi gwrthdaro atgynhyrchu? Mae gennym Feistr ar ba brosesau sy'n digwydd. Mae gennym wactod ceir. Autovacuum mewn gwirionedd, beth mae'n ei wneud? Mae'n torri allan rhai hen linellau. Os oes gennym ar hyn o bryd gais ar yr atgynhyrchiad sy'n darllen yr hen linellau hyn, a bod sefyllfa ar y Meistr bod yr autovacuum yn nodi'r llinellau hyn ag y bo modd i'w hailysgrifennu, yna fe wnaethom eu trosysgrifo. A chawsom becyn data, pan fydd yn rhaid i ni ailysgrifennu'r llinellau sydd eu hangen ar y cais ar y replica, yna bydd y broses atgynhyrchu yn aros am y terfyn amser a ffurfweddu gennych. Ac yna bydd PostgreSQL yn penderfynu beth sy'n bwysicach iddo. Ac mae atgynhyrchu yn bwysicach iddo na chais, a bydd yn saethu'r cais i wneud y newidiadau hyn ar y replica.
Andrew, mae gennyf gwestiwn. Y graffeg wych hyn a ddangoswyd gennych yn ystod y cyflwyniad, a yw hyn yn ganlyniad rhywfaint o waith o'ch defnyddioldeb? Sut cafodd y siartiau eu gwneud?
Mae hwn yn wasanaeth .
A yw hwn yn gynnyrch masnachol?
Oes. Mae hwn yn gynnyrch masnachol.
Ffynhonnell: hab.com