Dull diwydiannol o diwnio PostgreSQL: arbrofion gyda chronfeydd data.” Nikolay Samokhvalov

Awgrymaf ichi ddarllen y trawsgrifiad o adroddiad Nikolai Samokhvalov “Dull diwydiannol o diwnio PostgreSQL: arbrofion ar gronfeydd data”

Shared_buffers = 25% – a yw'n llawer neu ychydig? Neu jyst yn iawn? Sut ydych chi'n gwybod a yw'r argymhelliad hwn - braidd yn hen ffasiwn - yn briodol yn eich achos penodol chi?

Mae'n bryd mynd at y mater o ddewis paramedrau postgresql.conf "fel oedolyn." Nid gyda chymorth "auto tuners" dall neu gyngor hen ffasiwn o erthyglau a blogiau, ond yn seiliedig ar:

1. arbrofion wedi'u gwirio'n llym ar gronfeydd data, yn cael eu cynnal yn awtomatig, mewn symiau mawr ac o dan amodau mor agos â phosibl i "frwydro",
2. dealltwriaeth ddofn o nodweddion y DBMS a'r OS.

Defnyddio Nancy CLI (https://gitlab.com/postgres.ai/nancy), byddwn yn edrych ar enghraifft benodol - y shared_buffers drwg-enwog - mewn gwahanol sefyllfaoedd, mewn gwahanol brosiectau ac yn ceisio darganfod sut i ddewis y lleoliad gorau posibl ar gyfer ein seilwaith, cronfa ddata a llwyth.

Byddwn yn siarad am arbrofion gyda chronfeydd data. Dyma stori sy'n para ychydig dros chwe mis.

Ychydig amdanaf. Profiad gyda Postgres am fwy na 14 mlynedd. Mae nifer o gwmnïau rhwydweithio cymdeithasol wedi sefydlu. Roedd Postgres yn cael ei ddefnyddio ac yn cael ei ddefnyddio ym mhobman.

Hefyd grŵp RuPostgres ar Meetup, 2il safle yn y byd. Yn araf bach rydym yn agosáu at 2 o bobl. RuPostgres.org.

Ac mewn cyfrifiaduron personol o gynadleddau amrywiol, gan gynnwys Highload, rwy'n gyfrifol am gronfeydd data, yn enwedig Postgres o'r cychwyn cyntaf.

Ac yn ystod yr ychydig flynyddoedd diwethaf, rwyf wedi ailgychwyn fy ymarfer ymgynghori Postgres 11 parth amser o'r fan hon.

A phan wnes i hyn rai blynyddoedd yn ôl, cefais rywfaint o seibiant mewn gwaith llaw gweithredol gyda Postgres, ers 2010 yn ôl pob tebyg. Cefais fy synnu cyn lleied y mae trefn waith DBA wedi newid, a faint o lafur llaw sydd angen ei ddefnyddio o hyd. Ac roeddwn i'n meddwl ar unwaith bod rhywbeth o'i le yma, mae angen i mi awtomeiddio mwy o bopeth.

A chan ei fod i gyd yn anghysbell, roedd y rhan fwyaf o'r cleientiaid yn y cymylau. Ac mae llawer eisoes wedi'i awtomeiddio, yn amlwg. Mwy am hyn yn nes ymlaen. Hynny yw, arweiniodd hyn i gyd at y syniad y dylai fod nifer o offer, h.y., rhyw fath o lwyfan a fydd yn awtomeiddio bron pob gweithred DBA fel y gellir rheoli nifer fawr o gronfeydd data.

Ni fydd yr adroddiad hwn yn cynnwys:

• “bwledi arian” a datganiadau fel - gosodwch 8 GB neu 25% shared_buffers a byddwch yn iawn. Ni fydd llawer am byfferau rhannu.
• Hardcore "innards".

Beth fydd yn digwydd?

• Bydd egwyddorion optimeiddio y byddwn yn eu cymhwyso ac yn eu datblygu. Bydd pob math o syniadau yn codi ar hyd y ffordd ac offer amrywiol y byddwn yn eu creu yn bennaf yn Ffynhonnell Agored, h.y. rydym yn gwneud y sail yn Ffynhonnell Agored. Ar ben hynny, mae gennym docynnau, mae'r holl gyfathrebu yn ymarferol Ffynhonnell Agored. Gallwch chi weld beth rydyn ni'n ei wneud nawr, beth fydd yn y datganiad nesaf, ac ati.
• Bydd rhywfaint o brofiad hefyd o ddefnyddio'r egwyddorion hyn, yr offer hyn mewn nifer o gwmnïau: o fusnesau newydd bach i gwmnïau mawr.

Sut mae hyn i gyd yn datblygu?

Yn gyntaf, prif dasg DBA, yn ogystal â sicrhau bod achosion yn cael eu creu, defnyddio copïau wrth gefn, ac ati, yw dod o hyd i dagfeydd a gwneud y gorau o berfformiad.

Nawr mae wedi'i sefydlu fel hyn. Edrychwn ar y monitro, rydym yn gweld rhywbeth, ond rydym yn colli rhai manylion. Rydyn ni'n dechrau cloddio'n fwy gofalus, fel arfer gyda'n dwylo, a deall beth i'w wneud ag ef un ffordd neu'r llall.

Ac mae dwy ymagwedd. Pg_stat_statements yw'r ateb rhagosodedig ar gyfer adnabod ymholiadau araf. A dadansoddi logiau Postgres gan ddefnyddio pgBadger.

Mae anfanteision difrifol i bob dull. Yn y dull cyntaf, rydym wedi taflu'r holl baramedrau allan. Ac os ydym yn gweld y grwpiau SELECT * O'r tabl lle colofn yn hafal i'r "?" neu “$” ers Postgres 10. Nid ydym yn gwybod ai sgan mynegai neu sgan seq yw hwn. Mae'n dibynnu'n fawr ar y paramedr. Os rhoddwch werth anaml iawn yn ei le, bydd yn sgan mynegai. Os rhoddwch werth amnewidiol sy'n meddiannu 90% o'r tabl yno, bydd y sgan seq yn amlwg, oherwydd mae Postgres yn gwybod yr ystadegau. Ac mae hyn yn anfantais fawr o pg_stat_statements, er bod rhywfaint o waith ar y gweill.

Yr anfantais fwyaf o ddadansoddi log yw na allwch fforddio "log_min_duration_statement = 0" fel rheol. A byddwn yn siarad am hyn hefyd. Yn unol â hynny, nid ydych yn gweld y darlun cyfan. Ac efallai y bydd rhywfaint o ymholiad, sy'n gyflym iawn, yn defnyddio llawer iawn o adnoddau, ond ni fyddwch yn ei weld oherwydd ei fod yn is na'ch trothwy.

Sut mae DBAs yn datrys y problemau y maent yn dod o hyd iddynt?

Er enghraifft, canfuwyd rhywfaint o broblem. Beth sy'n cael ei wneud fel arfer? Os ydych chi'n ddatblygwr, yna byddwch chi'n gwneud rhywbeth ar ryw achlysur nad yw'r un maint. Os ydych yn DBA, yna mae gennych lwyfannu. A dim ond un all fod. Ac yr oedd chwe mis ar ei hôl hi. Ac rydych chi'n meddwl y byddwch chi'n mynd i gynhyrchu. Ac yna hyd yn oed DBAs profiadol yna gwirio mewn cynhyrchu, ar replica. Ac mae'n digwydd eu bod yn creu mynegai dros dro, gwnewch yn siŵr ei fod yn helpu, ei ollwng a'i roi i'r datblygwyr fel y gallant ei roi yn y ffeiliau mudo. Dyma'r math o nonsens sy'n digwydd nawr. Ac mae hyn yn broblem.

• Cyfluniadau tiwn.
• Optimeiddio'r set o fynegeion.
• Newidiwch yr ymholiad SQL ei hun (dyma'r ffordd anoddaf).
• Ychwanegu capasiti (y ffordd hawsaf yn y rhan fwyaf o achosion).

Mae llawer yn digwydd gyda'r pethau hyn. Mae llawer o ddolenni yn Postgres. Mae llawer i'w wybod. Mae llawer o fynegeion yn Postgres, diolch hefyd i drefnwyr y gynhadledd hon. Ac mae angen gwybod hyn i gyd, a dyma sy'n gwneud i bobl nad ydynt yn DBA deimlo fel bod DBAs yn ymarfer hud du. Hynny yw, mae angen i chi astudio am 10 mlynedd i ddechrau deall hyn i gyd fel arfer.

Ac yr wyf yn ymladdwr yn erbyn yr hud du hwn. Rwyf am wneud popeth fel bod yna dechnoleg, ac nid oes unrhyw greddf yn hyn i gyd.

Enghreifftiau o fywyd go iawn

Sylwais ar hyn mewn o leiaf ddau brosiect, gan gynnwys fy mhrosiect fy hun. Mae post blog arall yn dweud wrthym fod gwerth o 1 ar gyfer default_statistict_target yn dda. Iawn, gadewch i ni roi cynnig arni wrth gynhyrchu.

A dyma ni, gan ddefnyddio ein hofferyn ddwy flynedd yn ddiweddarach, gyda chymorth arbrofion ar y cronfeydd data yr ydym yn sôn amdanynt heddiw, gallwn gymharu beth oedd a beth sydd wedi dod.

Ac ar gyfer hyn mae angen i ni greu arbrawf. Mae'n cynnwys pedair rhan.

• Y cyntaf yw'r amgylchedd. Mae angen darn o galedwedd arnom. A phan ddof i ryw gwmni a llofnodi contract, dywedaf wrthynt am roi'r un caledwedd i mi ag wrth gynhyrchu. Ar gyfer pob un o'ch Meistr, mae arnaf angen o leiaf un darn o galedwedd fel hyn. Naill ai mae hwn yn beiriant rhithwir enghreifftiol yn Amazon neu Google, neu mae angen yr un darn o galedwedd arnaf yn union. Hynny yw, rydw i eisiau ail-greu'r amgylchedd. Ac yn y cysyniad o amgylchedd rydym yn cynnwys y prif fersiwn o Postgres.
• Yr ail ran yw gwrthrych ein hymchwil. Cronfa ddata yw hon. Gellir ei greu mewn sawl ffordd. Byddaf yn dangos i chi sut.
• Y drydedd ran yw'r llwyth. Dyma'r foment anoddaf.
• A'r bedwaredd ran yw'r hyn rydyn ni'n ei wirio, h.y. beth fyddwn ni'n ei gymharu â beth. Gadewch i ni ddweud y gallwn newid un neu fwy o baramedrau yn y ffurfwedd, neu gallwn greu mynegai, ac ati.

Rydym yn lansio arbrawf. Dyma pg_stat_statements. Ar y chwith mae'r hyn a ddigwyddodd. Ar y dde - beth ddigwyddodd.

Ar y chwith default_statistics_target = 100, ar y dde = 1. Gwelwn fod hyn wedi ein helpu ni. Ar y cyfan, gwellodd popeth 000%.

Ond os byddwn yn sgrolio i lawr, bydd grwpiau o geisiadau gan pgBadger neu o pg_stat_statements. Mae dau opsiwn. Fe welwn fod rhai ceisiadau wedi gostwng 88%. Ac yma daw'r dull peirianneg. Gallwn gloddio ymhellach y tu mewn oherwydd rydym yn meddwl tybed pam y suddodd. Mae angen i chi ddeall beth ddigwyddodd gyda'r ystadegau. Pam mae mwy o fwcedi mewn ystadegau yn arwain at ganlyniadau gwaeth.

Neu ni allwn gloddio, ond gwnewch “ALTER TABL ... ALTER COLUMN” a dychwelyd 100 bwced yn ôl at ystadegau'r golofn hon. Ac yna gydag arbrawf arall gallwn sicrhau bod y darn hwn o gymorth. I gyd. Mae hwn yn ddull peirianneg sy'n ein helpu i weld y darlun mawr a gwneud penderfyniadau ar sail data yn hytrach nag ar reddf.

Cwpl o enghreifftiau o ardaloedd eraill. Bu profion CI mewn profion ers blynyddoedd lawer. Ac ni fyddai unrhyw brosiect yn ei iawn bwyll yn byw heb brofion awtomataidd.

Mewn diwydiannau eraill: mewn hedfan, yn y diwydiant modurol, pan fyddwn yn profi aerodynameg, mae gennym hefyd y cyfle i wneud arbrofion. Ni fyddwn yn lansio rhywbeth o luniad yn uniongyrchol i'r gofod, neu ni fyddwn yn mynd â char ar unwaith ar y trac. Er enghraifft, mae twnnel gwynt.

Gallwn ddod i gasgliadau o arsylwadau o ddiwydiannau eraill.

Yn gyntaf, mae gennym amgylchedd arbennig. Mae'n agos at gynhyrchu, ond nid yn agos. Ei brif nodwedd yw y dylai fod yn rhad, yn ailadroddadwy ac mor awtomataidd â phosibl. Ac mae'n rhaid cael offer arbennig hefyd ar gyfer cynnal dadansoddiad manwl.

Yn fwyaf tebygol, pan fyddwn yn lansio awyren a hedfan, mae gennym lai o gyfle i astudio pob milimedr o wyneb yr adain nag sydd gennym mewn twnnel gwynt. Mae gennym fwy o offer diagnostig. Gallwn fforddio cario mwy o bethau trwm na allwn fforddio eu rhoi ar awyren yn yr awyr. Yr un peth â Postgres. Efallai y byddwn, mewn rhai achosion, yn galluogi logio ymholiad llawn yn ystod arbrofion. Ac nid ydym am wneud hyn wrth gynhyrchu. Efallai y byddwn hyd yn oed yn bwriadu galluogi hyn gan ddefnyddio auto_explain.

Ac fel y dywedais, mae lefel uchel o awtomeiddio yn golygu ein bod yn pwyso'r botwm ac yn ailadrodd. Dyma fel y dylai fod, fel bod llawer o arbrofi, fel ei fod ar y gweill.

Nancy CLI - sylfaen y "labordy cronfa ddata"

Ac felly fe wnaethom y peth hwn. Hynny yw, siaradais am y syniadau hyn ym mis Mehefin, bron i flwyddyn yn ôl. Ac mae gennym eisoes yr hyn a elwir yn Nancy CLI yn Ffynhonnell Agored. Dyma'r sylfaen ar gyfer adeiladu labordy cronfa ddata.

Nancy - Mae mewn Ffynhonnell Agored, ar Gitlab. Gallwch chi ei ddweud, gallwch chi roi cynnig arni. Darparais ddolen yn y sleidiau. Gallwch glicio arno a bydd yno helpu ym mhob ystyr.

Wrth gwrs, mae llawer yn dal i gael ei ddatblygu. Mae yna lawer o syniadau yno. Ond mae hyn yn rhywbeth rydyn ni'n ei ddefnyddio bron bob dydd. A phan fydd gennym syniad - pam pan fyddwn yn dileu 40 o linellau, mae'r cyfan yn dibynnu ar IO, yna gallwn gynnal arbrawf ac edrych yn fanylach i ddeall beth sy'n digwydd ac yna ceisio ei drwsio wrth fynd. Hynny yw, rydym yn gwneud arbrawf. Er enghraifft, rydyn ni'n tweak rhywbeth a gweld beth sy'n digwydd yn y diwedd. Ac nid ydym yn gwneud hyn wrth gynhyrchu. Dyma hanfod y syniad.

Ble gall hyn weithio? Gall hyn weithio'n lleol, h.y. gallwch ei wneud yn unrhyw le, gallwch hyd yn oed ei redeg ar MacBook. Mae angen docwr, gadewch i ni fynd. Dyna i gyd. Gallwch ei redeg mewn rhai achosion ar ddarn o galedwedd, neu mewn peiriant rhithwir, unrhyw le.

Ac mae cyfle hefyd i redeg o bell yn Amazon yn EC2 Instance, mewn mannau. Ac mae hwn yn gyfle cŵl iawn. Er enghraifft, ddoe fe wnaethom gynnal mwy na 500 o arbrofion ar enghraifft i3, gan ddechrau gyda'r ieuengaf a gorffen gyda i3-16-xlarge. Ac fe gostiodd 500 o arbrofion $64 i ni. Roedd pob un yn para 15 munud. Hynny yw, oherwydd y ffaith bod smotiau'n cael eu defnyddio yno, mae'n rhad iawn - gostyngiad o 70%, bilio fesul eiliad Amazon. Gallwch chi wneud llawer. Gallwch chi wneud ymchwil go iawn.

A chefnogir tair fersiwn fawr o Postgres. Nid yw mor anodd gorffen rhai hen rai a'r 12fed fersiwn newydd hefyd.

Gallwn ddiffinio gwrthrych mewn tair ffordd. hwn:

• Ffeil dympio/sql.
• Y brif ffordd yw clonio'r cyfeiriadur PGDATA. Fel rheol, fe'i cymerir o'r gweinydd wrth gefn. Os oes gennych chi gopïau wrth gefn deuaidd arferol, gallwch chi wneud clonau oddi yno. Os oes gennych gymylau, yna bydd swyddfa cwmwl fel Amazon a Google yn gwneud hyn i chi. Dyma'r ffordd bwysicaf o glonio cynhyrchiad go iawn. Dyma sut rydyn ni'n datblygu.
• Ac mae'r dull olaf yn addas ar gyfer ymchwil pan fyddwch chi eisiau deall sut mae rhywbeth yn gweithio yn Postgres. Mae hyn yn pgbench. Gallwch chi gynhyrchu gan ddefnyddio pgbench. Dim ond un opsiwn "db-pgbench" ydyw. Rydych chi'n dweud wrtho pa raddfa. A bydd popeth yn cael ei gynhyrchu yn y cwmwl, fel y dywedwyd.

A llwyth:

• Gallwn weithredu'r llwyth mewn un edefyn SQL. Dyma'r ffordd fwyaf cyntefig.
• A gallwn efelychu'r llwyth. A gallwn ei efelychu yn gyntaf oll yn y modd canlynol. Mae angen i ni gasglu'r holl logiau. Ac mae'n boenus. Byddaf yn dangos i chi pam. A defnyddio pgreplay rydyn ni'n chwarae, sydd wedi'i ymgorffori yn Nancy.
• Neu opsiwn arall. Y llwyth crefft fel y'i gelwir, yr ydym yn ei wneud gyda rhywfaint o ymdrech. Wrth ddadansoddi ein llwyth presennol ar y system frwydro, rydym yn tynnu allan y grwpiau uchaf o geisiadau. A chan ddefnyddio pgbench gallwn efelychu'r llwyth hwn yn y labordy.

• Naill ai mae'n rhaid i ni berfformio rhyw fath o SQL, h.y. rydym yn gwirio rhyw fath o ymfudiad, yn creu mynegai yno, yn gweithredu ANALAZE yno. Ac rydym yn edrych ar yr hyn a ddigwyddodd cyn y gwactod ac ar ôl y gwactod. Yn gyffredinol, unrhyw SQL.
• Naill ai rydym yn newid un neu fwy o baramedrau yn y ffurfwedd. Gallwn ddweud wrthym am wirio, er enghraifft, 100 o werthoedd yn Amazon ar gyfer ein cronfa ddata terabyte. Ac mewn ychydig oriau byddwch yn cael y canlyniad. Fel rheol, bydd yn cymryd sawl awr i chi ddefnyddio cronfa ddata terabyte. Ond mae darn yn cael ei ddatblygu, mae gennym gyfres bosibl, h.y. gallwch ddefnyddio'r un data pgdata yn gyson ar yr un gweinydd a gwirio. Bydd Postgres yn ailgychwyn a bydd caches yn cael eu hailosod. A gallwch chi yrru'r llwyth.

• Mae cyfeiriadur yn cyrraedd gyda chriw o wahanol ffeiliau, gan ddechrau o gipluniau tudstat***. A'r peth mwyaf diddorol sydd yna yw pg_stat_statements, pg_stat_khacke. Mae'r rhain yn ddau estyniad sy'n dadansoddi ceisiadau. Ac mae pg_stat_bwriter yn cynnwys nid yn unig ystadegau pwriter, ond hefyd ar y pwynt gwirio a sut mae'r backends eu hunain yn disodli byfferau budr. Ac mae'r cyfan yn ddiddorol i'w weld. Er enghraifft, pan fyddwn yn sefydlu shared_buffers, mae'n ddiddorol iawn gweld faint mae pawb wedi disodli.
• Mae boncyffion Postgres hefyd yn cyrraedd. Dau log - log paratoi a log chwarae llwyth.
• Nodwedd gymharol newydd yw FlameGraphs.
• Hefyd, os gwnaethoch chi ddefnyddio opsiynau pgreplay neu pgbench ar gyfer chwarae'r llwyth, yna bydd eu hallbwn yn frodorol. Ac fe welwch chi hwyrni a TPS. Bydd yn bosibl deall sut y maent yn ei weld.
• Gwybodaeth system.
• Gwiriadau CPU ac IO sylfaenol. Mae hyn yn fwy ar gyfer enghraifft EC2 yn Amazon, pan fyddwch chi am lansio 100 o achosion union yr un fath mewn edefyn a rhedeg 100 o rediadau gwahanol yno, yna bydd gennych 10 o arbrofion. Ac mae angen i chi wneud yn siŵr nad ydych chi'n dod ar draws achos diffygiol sydd eisoes yn cael ei ormesu gan rywun. Mae eraill yn weithredol ar y darn hwn o galedwedd ac nid oes gennych lawer o adnoddau ar ôl. Mae'n well cael gwared ar ganlyniadau o'r fath. A chyda chymorth sysbench gan Alexey Kopytov, rydym yn gwneud sawl gwiriad byr a ddaw ac y gellir eu cymharu ag eraill, hy byddwch yn deall sut mae'r CPU yn ymddwyn a sut mae'r IO yn ymddwyn.

Beth yw'r anawsterau technegol sy'n seiliedig ar esiampl cwmnïau gwahanol?

Gadewch i ni ddweud ein bod am ailadrodd y llwyth go iawn gan ddefnyddio logiau. Mae'n syniad gwych os yw wedi'i ysgrifennu ar pgreplay Ffynhonnell Agored. Rydyn ni'n ei ddefnyddio. Ond er mwyn iddo weithio'n dda, rhaid i chi alluogi logio ymholiad llawn gyda pharamedrau ac amseriad.

Mae rhai cymhlethdodau gyda hyd a stamp amser. Byddwn yn gwagio'r gegin gyfan hon. Y prif gwestiwn yw a allwch chi ei fforddio ai peidio?

https://gist.github.com/NikolayS/08d9b7b4845371d03e195a8d8df43408

Y broblem yw efallai nad yw ar gael. Yn gyntaf oll, rhaid i chi ddeall pa ffrwd fydd yn cael ei ysgrifennu i'r log. Os oes gennych pg_stat_statements, gallwch ddefnyddio'r ymholiad hwn (bydd y ddolen ar gael yn y sleidiau) i ddeall tua faint o beit a ysgrifennir yr eiliad.

Edrychwn ar hyd y cais. Rydym yn esgeuluso'r ffaith nad oes paramedrau, ond rydym yn gwybod hyd y cais a gwyddom sawl gwaith yr eiliad y cafodd ei weithredu. Fel hyn gallwn amcangyfrif tua faint o beit yr eiliad. Efallai y byddwn yn gwneud camgymeriad ddwywaith cymaint, ond byddwn yn bendant yn deall y drefn yn y modd hwn.

Gallwn weld bod y cais hwn yn cael ei weithredu 802 gwaith yr eiliad. A gwelwn y bydd bytes_per sec - 300 kB/s yn cael ei ysgrifennu plws neu finws. Ac, fel rheol, gallwn fforddio llif o'r fath.

Ond! Y ffaith yw bod yna wahanol systemau cofnodi. A rhagosodiad pobl fel arfer yw "syslog".

Ac os oes gennych chi syslog, yna efallai bod gennych chi lun fel hyn. Byddwn yn cymryd pgbench, yn galluogi logio ymholiad a gweld beth sy'n digwydd.

Heb logio - dyma'r golofn ar y chwith. Cawsom 161 o TPS. Gyda syslog - mae hyn yn Ubuntu 000 ar Amazon, rydyn ni'n cael 16.04 TPS. Ac os byddwn yn newid i ddau ddull logio arall, yna mae'r sefyllfa'n llawer gwell. Hynny yw, roeddem yn disgwyl iddo ostwng, ond nid i'r un graddau.

Ac ar CentOS 7, y mae dyddlyfr hefyd yn cymryd rhan ynddo, gan droi logiau i fformat deuaidd ar gyfer chwilio hawdd, ac ati, yna mae'n hunllef yno, rydyn ni'n gollwng 44 gwaith yn TPS.

A dyma beth mae pobl yn byw ag ef. Ac yn aml mewn cwmnïau, yn enwedig rhai mawr, mae hyn yn anodd iawn ei newid. Os gallwch chi ddianc o syslog, yna ewch i ffwrdd oddi wrtho.

• Gwerthuso IOPS ac ysgrifennu llif.
• Gwiriwch eich system logio.
• Os yw'r llwyth rhagamcanol yn rhy fawr, ystyriwch samplu.

Mae gennym pg_stat_statements. Fel y dywedais, rhaid ei fod yno. A gallwn gymryd a disgrifio pob grŵp o geisiadau mewn ffordd arbennig mewn ffeil. Ac yna gallwn ddefnyddio nodwedd gyfleus iawn yn pgbench - dyma'r gallu i fewnosod sawl ffeil gan ddefnyddio'r opsiwn "-f".

Mae'n deall llawer o "-f". A gallwch chi ddweud gyda chymorth “@” ar y diwedd pa gyfran ddylai fod gan bob ffeil. Hynny yw, gallwn ddweud sy'n gwneud hyn mewn 10% o achosion, a hyn mewn 20%. A bydd hyn yn dod â ni'n agosach at yr hyn a welwn wrth gynhyrchu.

Sut byddwn ni'n deall yr hyn sydd gennym ni wrth gynhyrchu? Pa gyfran a sut? Mae hyn yn dipyn o neilltu. Mae gennym un cynnyrch arall postgres-archwiliad. Hefyd yn ganolfan yn Ffynhonnell Agored. Ac rydym bellach yn ei ddatblygu'n weithredol.

Cafodd ei eni am resymau ychydig yn wahanol. Am resymau nad yw monitro yn ddigon. Hynny yw, rydych chi'n dod, edrychwch ar y sylfaen, edrychwch ar y problemau sy'n bodoli. Ac, fel rheol, rydych chi'n gwneud gwiriad_iechyd. Os ydych chi'n DBA profiadol, yna rydych chi'n gwneud health_check. Edrychom ar y defnydd o fynegeion, ac ati Os oes gennych OKmeter, yna gwych. Mae hwn yn fonitro cŵl ar gyfer Postgres. OKmeter.io - gosodwch ef, mae popeth yn cael ei wneud yn dda iawn yno. Mae'n cael ei dalu.

Os nad oes gennych un, yna fel arfer nid oes gennych lawer. Wrth fonitro, fel arfer mae CPU, IO, ac yna gydag amheuon, a dyna i gyd. Ac mae angen mwy. Mae angen i ni weld sut mae'r autovacuum yn gweithio, sut mae'r pwynt gwirio yn gweithio, yn io mae angen i ni wahanu'r pwynt gwirio oddi wrth y bwriter ac o'r backends, ac ati.

Y broblem yw pan fyddwch chi'n helpu cwmni mawr, ni allant weithredu rhywbeth yn gyflym. Ni allant brynu OKmeter yn gyflym. Efallai y byddant yn ei brynu mewn chwe mis. Ni allant gyflwyno rhai pecynnau yn gyflym.

A chawsom y syniad bod angen teclyn arbennig arnom nad oes angen unrhyw beth i'w osod, h.y. nid oes rhaid i chi osod unrhyw beth o gwbl wrth gynhyrchu. Gosodwch ef ar eich gliniadur, neu ar weinydd arsylwi lle byddwch chi'n ei redeg. A bydd yn dadansoddi llawer o bethau: y system weithredu, y system ffeiliau, a Postgres ei hun, gan wneud rhai ymholiadau ysgafn y gellir eu rhedeg yn uniongyrchol i gynhyrchu ac ni fydd dim yn methu.

Fe wnaethon ni ei alw'n Postgres-checkup. Mewn termau meddygol, mae hwn yn wiriad iechyd rheolaidd. Os yw'n thema modurol, yna mae fel cynnal a chadw. Rydych chi'n gwneud gwaith cynnal a chadw ar eich car bob chwe mis neu flwyddyn, yn dibynnu ar y brand. Ydych chi'n gwneud gwaith cynnal a chadw ar gyfer eich sylfaen? Hynny yw, a ydych chi'n gwneud ymchwil dwfn yn rheolaidd? Rhaid ei wneud. Os ydych chi'n gwneud copïau wrth gefn, yna gwnewch archwiliad, nid yw hyn yn llai pwysig.

Ac mae gennym offeryn o'r fath. Dechreuodd ddod i'r amlwg yn weithredol dim ond tua thri mis yn ôl. Mae'n dal yn ifanc, ond mae llawer yno.

Casglu'r grwpiau mwyaf “dylanwadol” o ymholiadau - adroddwch K003 yn Postgres-checkup

Ac y mae grŵp o adroddiadau K. Tri adroddiad hyd yn hyn. Ac mae adroddiad o'r fath K003. Mae'r brig o pg_stat_statements, wedi'i drefnu yn ôl cyfanswm_amser.

Pan fyddwn yn didoli grwpiau ceisiadau yn ôl cyfanswm_amser, ar y brig rydym yn gweld y grŵp sy'n llwytho ein system fwyaf, h.y. yn defnyddio mwy o adnoddau. Pam ydw i'n enwi grwpiau ymholiadau? Oherwydd inni daflu'r paramedrau allan. Nid ceisiadau yw’r rhain bellach, ond grwpiau o geisiadau, h.y. cânt eu tynnu.

Ac os byddwn yn gwneud y gorau o'r top i'r gwaelod, byddwn yn ysgafnhau ein hadnoddau ac yn gohirio'r eiliad pan fydd angen i ni uwchraddio. Mae hon yn ffordd dda iawn o arbed arian.

Efallai nad yw hon yn ffordd dda iawn o ofalu am ddefnyddwyr, oherwydd efallai na welwn achosion prin, ond annifyr iawn lle arhosodd person am 15 eiliad. Yn gyfan gwbl, maent mor brin fel nad ydym yn eu gweld, ond rydym yn delio ag adnoddau.

Beth ddigwyddodd yn y tabl hwn? Cymerasom ddau giplun. Bydd Postgres_checkup yn rhoi delta i chi ar gyfer pob metrig: cyfanswm amser, galwadau, rhesi, shared_blks_read, ac ati. Dyna ni, mae'r delta wedi'i gyfrifo. Y broblem fawr gyda pg_stat_statements yw nad yw'n cofio pryd y cafodd ei ailosod. Os yw pg_stat_database yn cofio, yna nid yw pg_stat_statements yn cofio. Rydych chi'n gweld bod yna nifer o 1, ond ni wyddom o ble y gwnaethom gyfrif.

A dyma ni'n gwybod, dyma ni ddau gipolwg. Gwyddom mai 56 eiliad oedd y delta yn yr achos hwn. Bwlch byr iawn. Trefnwyd yn ôl cyfanswm_amser. Ac yna gallwn wahaniaethu, h.y. rydym yn rhannu pob metrig yn ôl hyd. Os byddwn yn rhannu pob metrig yn ôl hyd, bydd gennym nifer y galwadau yr eiliad.

Nesaf, total_time yr eiliad yw fy hoff fetrig. Mae'n cael ei fesur mewn eiliadau, yr eiliad, h.y. faint o eiliadau a gymerodd ein system i weithredu'r grŵp hwn o geisiadau yr eiliad. Os gwelwch fwy nag eiliad yr eiliad yno, mae'n golygu bod yn rhaid i chi roi mwy nag un craidd. Mae hwn yn fetrig da iawn. Gallwch chi ddeall bod angen o leiaf dri chraidd ar y ffrind hwn, er enghraifft.

Dyma ein gwybodaeth, nid wyf erioed wedi gweld unrhyw beth tebyg yn unman. Sylwch - mae hyn yn beth syml iawn - eiliad yr eiliad. Weithiau, pan fydd eich CPU yn 100%, yna hanner awr yr eiliad, hynny yw, fe wnaethoch chi dreulio hanner awr yn gwneud y ceisiadau hyn yn unig.

Nesaf gwelwn resi yr eiliad. Gwyddom sawl rhes yr eiliad a ddychwelodd.

Ac yna mae yna beth diddorol hefyd. Sawl byffer Share_buffer rydym yn darllen yr eiliad o'r byffers shared_buffers ei hun. Roedd y trawiadau yno eisoes, a chymerasom y rhesi o storfa'r system weithredu neu o'r ddisg. Mae'r opsiwn cyntaf yn gyflym, a gall yr ail fod yn gyflym neu beidio, yn dibynnu ar y sefyllfa.

A'r ail ffordd o wahaniaethu yw rhannu nifer y ceisiadau yn y grŵp hwn. Yn yr ail golofn bydd gennych bob amser un ymholiad wedi'i rannu fesul ymholiad. Ac yna mae'n ddiddorol - sawl milieiliad oedd yn y cais hwn. Gwyddom sut mae'r ymholiad hwn yn ymddwyn ar gyfartaledd. Roedd angen 101 milieiliad ar gyfer pob cais. Dyma'r metrig traddodiadol y mae angen i ni ei ddeall.

Sawl rhes a ddychwelodd pob ymholiad ar gyfartaledd? Gwelwn 8 y grŵp hwn yn dychwelyd. Ar gyfartaledd, faint a gymerwyd o'r storfa a'i ddarllen. Gwelwn fod popeth wedi'i storio'n dda. Trawiadau solet ar gyfer y grŵp cyntaf.

A'r pedwerydd is-linyn ym mhob llinell yw pa ganran o'r cyfanswm. Mae gennym ni alwadau. Gadewch i ni ddweud 1. A gallwn ddeall pa gyfraniad y mae'r grŵp hwn yn ei wneud. Gwelwn yn yr achos hwn fod y grŵp cyntaf yn cyfrannu llai na 000%. Hynny yw, mae mor araf fel nad ydym yn ei weld yn y darlun cyffredinol. Ac mae'r ail grŵp yn 000% ar alwadau. Hynny yw, yr ail grŵp yw 0,01% o'r holl alwadau.

Mae total_time hefyd yn ddiddorol. Treuliasom 14% o gyfanswm ein hamser gwaith ar y grŵp cyntaf o geisiadau. Ac ar gyfer yr ail - 11%, ac ati.

Nid af i fanylion, ond mae yna gynildeb yno. Rydym yn dangos gwall ar y brig, oherwydd pan fyddwn yn cymharu, gall cipluniau arnofio, hynny yw, gall rhai ceisiadau ddisgyn allan ac ni allant fod yn bresennol yn yr ail un mwyach, tra gall rhai newydd ymddangos. Ac yno rydym yn cyfrifo'r gwall. Os gwelwch 0, yna mae hynny'n dda. Nid oes unrhyw wallau. Os yw'r gyfradd gwallau hyd at 20%, mae'n iawn.

Yna dychwelwn at ein pwnc. Mae angen inni greu'r llwyth gwaith. Rydyn ni'n ei gymryd o'r top i'r gwaelod ac yn mynd nes i ni gyrraedd 80% neu 90%. Fel arfer mae hyn yn 10-20 grŵp. Ac rydym yn gwneud ffeiliau ar gyfer pgbench. Rydyn ni'n defnyddio hap yno. Weithiau, yn anffodus, nid yw hyn yn gweithio allan. Ac yn Postgres 12 bydd mwy o gyfleoedd i ddefnyddio'r dull hwn.

Ac yna rydym yn ennill 80-90% mewn cyfanswm_amser yn y modd hwn. Beth ddylwn i ei roi nesaf ar ôl “@”? Edrychwn ar y galwadau, edrych ar faint o ddiddordeb sydd yna a deall bod arnom ni gymaint o ddiddordeb yma. O'r canrannau hyn gallwn ddeall sut i gydbwyso pob un o'r ffeiliau. Ar ôl hynny rydyn ni'n defnyddio pgbench ac yn mynd i'r gwaith.

Mae gennym hefyd K001 a K002.

Mae K001 yn un llinyn mawr gyda phedwar is-linyn. Mae hyn yn nodweddiadol o'n llwyth cyfan. Gweler yr ail golofn a'r ail subrow. Gwelwn fod tua eiliad a hanner yr eiliad, h.y. os oes dau graidd, yna bydd yn dda. Bydd tua 75% o gapasiti. A bydd yn gweithio fel hyn. Os oes gennym 10 craidd, yna byddwn yn dawel yn gyffredinol. Fel hyn gallwn werthuso adnoddau.

K002 yw'r hyn rwy'n ei alw'n ddosbarthiadau ymholiad, h.y. SELECT, INSERT, Update, DELETE. Ac ar wahân DEWISWCH AM DDIWEDDARIAD, oherwydd ei fod yn glo.

Ac yma gallwn ddod i'r casgliad bod SELECT yn ddarllenwyr cyffredin - 82% o'r holl alwadau, ond ar yr un pryd - 74% mewn total_time. Hynny yw, fe'u gelwir yn llawer, ond yn defnyddio llai o adnoddau.

A dychwelwn at y cwestiwn: “Sut allwn ni ddewis y byfferau rhannu_ cywir?” Sylwaf fod y rhan fwyaf o feincnodau yn seiliedig ar y syniad - gadewch i ni weld beth fydd y trwybwn, h.y. beth fydd y trwybwn. Fel arfer caiff ei fesur mewn TPS neu QPS.

Ac rydym yn ceisio gwasgu cymaint o drafodion yr eiliad â phosibl o'r car gan ddefnyddio paramedrau tiwnio. Dyma union 311 yr eiliad ar gyfer dethol.

Ond does neb yn gyrru i'r gwaith ac yn ôl adref ar gyflymder llawn. Mae hyn yn wirion. Yr un peth â chronfeydd data. Nid oes rhaid i ni yrru ar gyflymder llawn, a does neb yn gwneud hynny. Nid oes neb yn byw mewn cynhyrchu, sydd â 100% CPU. Er, efallai bod rhywun yn byw, ond nid yw hyn yn dda.

Y syniad yw ein bod fel arfer yn gyrru ar 20 y cant o gapasiti, yn ddelfrydol dim mwy na 50%. Ac rydym yn ceisio optimeiddio amser ymateb ar gyfer ein defnyddwyr yn anad dim. Hynny yw, rhaid inni droi ein nobiau fel bod isafswm hwyrni ar gyflymder o 20%, yn amodol. Mae hwn yn syniad rydyn ni hefyd yn ceisio ei ddefnyddio yn ein harbrofion.

Ac yn olaf, argymhellion:

• Byddwch yn siwr i wneud Labordy Cronfa Ddata.
• Os yn bosibl, gwnewch hynny ar alw fel ei fod yn datblygu am ychydig - chwarae a thaflu i ffwrdd. Os oes gennych chi gymylau, yna mae angen dweud hynny, h.y. cael llawer o sefyll.
• Byddwch yn chwilfrydig. Ac os oes rhywbeth o'i le, yna gwiriwch gydag arbrofion sut mae'n ymddwyn. Gellir defnyddio Nancy i hyfforddi eich hun i wirio sut mae'r ganolfan yn gweithio.
• Ac anelwch at yr amser ymateb lleiaf posibl.
• A pheidiwch ag ofni ffynonellau Postgres. Pan fyddwch chi'n gweithio gyda ffynonellau, mae'n rhaid eich bod chi'n gwybod Saesneg. Mae yna lawer o sylwadau yno, mae popeth yn cael ei esbonio yno.
• A gwiriwch iechyd y gronfa ddata yn rheolaidd, o leiaf unwaith bob tri mis, â llaw, neu archwiliad Postgres.

cwestiynau

Diolch yn fawr! Peth diddorol iawn.

Dau ddarn.

Ie, dau ddarn. Dim ond doeddwn i ddim yn deall yn iawn. Pan fydd Nancy a minnau'n gweithio, a allwn ni newid un paramedr yn unig neu grŵp cyfan?

Mae gennym baramedr ffurfweddu delta. Gallwch chi droi yno cymaint ag y dymunwch ar unwaith. Ond mae angen i chi ddeall, pan fyddwch chi'n newid llawer o bethau, y gallwch chi ddod i'r casgliadau anghywir.

Oes. Pam wnes i ofyn? Oherwydd mae'n anodd cynnal arbrofion pan mai dim ond un paramedr sydd gennych. Rydych chi'n ei dynhau, gweld sut mae'n gweithio. Rhoddais ef allan. Yna byddwch chi'n dechrau'r un nesaf.

Gallwch ei dynhau ar yr un pryd, ond mae'n dibynnu ar y sefyllfa, wrth gwrs. Ond mae'n well profi un syniad. Cawsom syniad ddoe. Roedd gennym ni sefyllfa agos iawn. Roedd dau gyfluniad. Ac ni allem ddeall pam fod gwahaniaeth mawr. A chododd y syniad bod angen i chi ddefnyddio deuoliaeth er mwyn deall yn gyson a darganfod beth yw'r gwahaniaeth. Gallwch chi wneud hanner y paramedrau yr un peth ar unwaith, yna chwarter, ac ati Mae popeth yn hyblyg.

Ac mae un cwestiwn arall. Mae'r prosiect yn ifanc ac yn datblygu. Mae'r ddogfennaeth eisoes yn barod, a oes disgrifiad manwl?

Gwneuthum ddolen yn benodol yno i'r disgrifiad o'r paramedrau. Mae yno. Ond nid yw llawer o bethau yno eto. Rwy'n chwilio am bobl o'r un anian. Ac rwy'n dod o hyd iddynt pan fyddaf yn perfformio. Mae hyn yn cŵl iawn. Mae rhywun eisoes yn gweithio gyda mi, helpodd rhywun a gwnaeth rywbeth yno. Ac os oes gennych ddiddordeb yn y pwnc hwn, rhowch adborth ar yr hyn sydd ar goll.

Unwaith y byddwn yn adeiladu'r labordy, efallai y bydd adborth. Gawn ni weld. Diolch!

Helo! Diolch am yr adroddiad! Gwelais fod yna gefnogaeth Amazon. A oes unrhyw gynlluniau i gefnogi GSP?

Cwestiwn da. Dechreuon ni ei wneud. Ac fe wnaethon ni ei rewi am y tro oherwydd ein bod ni eisiau arbed arian. Hynny yw, mae cefnogaeth gan ddefnyddio rhedeg ar localhost. Gallwch greu enghraifft eich hun a gweithio'n lleol. Gyda llaw, dyna beth rydyn ni'n ei wneud. Rwy'n gwneud hyn yn Getlab, yno yn GSP. Ond nid ydym yn gweld pwynt gwneud y fath offeryniaeth eto, oherwydd nid oes gan Google fannau rhad. Mae yna ??? achosion, ond mae ganddynt gyfyngiadau. Yn gyntaf, dim ond gostyngiad o 70% sydd ganddyn nhw bob amser ac ni allwch chi chwarae gyda'r pris yno. Ar smotiau, rydym yn cynyddu'r pris 5-10% i leihau'r tebygolrwydd y cewch eich cicio. Hynny yw, rydych chi'n arbed smotiau, ond gellir eu cymryd oddi wrthych unrhyw bryd. Os byddwch yn cynnig ychydig yn uwch nag eraill, cewch eich lladd yn ddiweddarach. Mae gan Google fanylion hollol wahanol. Ac mae yna gyfyngiad drwg iawn arall - dim ond am 24 awr maen nhw'n byw. Ac weithiau rydyn ni eisiau rhedeg arbrawf am 5 diwrnod. Ond gallwch chi wneud hyn mewn mannau; weithiau mae smotiau'n para am fisoedd.

Helo! Diolch am yr adroddiad! Soniasoch am siec. Sut ydych chi'n cyfrifo gwallau stat_statements?

Cwestiwn da iawn. Gallaf ddangos a dweud wrthych yn fanwl iawn. Yn fyr, edrychwn ar sut mae'r set o grwpiau ceisiadau wedi symud: faint sydd wedi disgyn a faint o rai newydd sydd wedi ymddangos. Ac yna edrychwn ar ddau fetrig: cyfanswm_amser a galwadau, felly mae dau wall. Ac edrychwn ar gyfraniad y grwpiau symudol. Mae dau is-grŵp: y rhai a adawodd a'r rhai a gyrhaeddodd. Gawn ni weld beth yw eu cyfraniad i'r darlun cyffredinol.

Onid ydych yn ofni y bydd yn troi yno ddwy neu dair gwaith yn ystod yr amser rhwng cipluniau?

Hynny yw, a wnaethon nhw gofrestru eto neu beth?

Er enghraifft, mae'r cais hwn eisoes wedi'i ragbrynu unwaith, yna fe ddaeth ac fe'i preempted eto, yna daeth eto ac fe'i preempted eto. Ac fe wnaethoch chi gyfrifo rhywbeth yma, a ble mae'r cyfan?

Cwestiwn da, bydd yn rhaid inni edrych.

Fe wnes i beth tebyg. Roedd yn symlach, wrth gwrs, fe wnes i hynny ar fy mhen fy hun. Ond roedd yn rhaid i mi ailosod, ailosod stat_statements a chyfrifo ar adeg y ciplun bod llai na ffracsiwn penodol, nad oedd yn dal i gyrraedd y nenfwd o faint o stat_statements allai gronni yno. A fy nealltwriaeth i yw, yn fwyaf tebygol, nid oes unrhyw beth wedi'i ddadleoli.

Ydy Ydy.

Ond nid wyf yn deall sut arall i'w wneud yn ddibynadwy.

Yn anffodus, nid wyf yn cofio yn union a ydym yn defnyddio'r testun ymholiad yno neu queryid gyda pg_stat_statements ac yn canolbwyntio arno. Os ydym yn canolbwyntio ar queryid, yna mewn theori rydym yn cymharu pethau cymaradwy.

Na, gall gael ei orfodi allan sawl gwaith rhwng cipluniau a dod eto.

Gyda'r un id?

Ydw.

Byddwn yn astudio hyn. Cwestiwn da. Mae angen inni ei astudio. Ond am y tro, mae'r hyn a welwn naill ai wedi'i ysgrifennu 0 ...

Mae hwn, wrth gwrs, yn achos prin, ond cefais sioc pan wnes i ddarganfod y gall stat_statemetns ddadleoli yno.

Gall fod llawer o bethau yn Pg_stat_statements. Daethom ar draws y ffaith, os oes gennych track_utility = ymlaen, yna caiff eich setiau eu holrhain hefyd.

Ydw wrth gwrs.

Ac os oes gennych chi java gaeafgysgu, sydd ar hap, yna mae'r bwrdd hash yn dechrau cael ei leoli yno. A chyn gynted ag y byddwch yn diffodd cais llawn iawn, byddwch yn y diwedd gyda 50-100 grwpiau. Ac mae popeth yn fwy neu lai sefydlog yno. Un ffordd o frwydro yn erbyn hyn yw cynyddu pg_stat_statements.max.

Oes, ond mae angen i chi wybod faint. A rhywsut mae angen i ni gadw llygad arno. Dyna dwi'n ei wneud. Hynny yw, mae gen i pg_stat_statements.max. A gwelaf nad oeddwn ar adeg y ciplun wedi cyrraedd 70%. Iawn, felly nid ydym wedi colli dim byd. Gadewch i ni ailosod. Ac rydym yn arbed eto. Os yw'r ciplun nesaf yn llai na 70, yna yn fwyaf tebygol nad ydych wedi colli dim eto.

Oes. Y rhagosodiad nawr yw 5. Ac mae hyn yn ddigon i lawer o bobl.

Fel arfer ie.

Fideo:

PS Ar fy rhan fy hun, byddaf yn ychwanegu, os yw Postgres yn cynnwys data cyfrinachol ac na ellir ei gynnwys yn yr amgylchedd prawf, yna gallwch chi ddefnyddio Anonymizer PostgreSQL. Mae’r cynllun yn fras fel a ganlyn:

Ffynhonnell: hab.com