Tiwnio Linux i wella perfformiad PostgreSQL. Ilya Kosmodemyansky

Trawsgrifiad o adroddiad 2015 gan Ilya Kosmodemyansky "Tiwnio Linux i wella perfformiad PostgreSQL"

Ymwadiad: Nodaf 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, bu 5 datganiad newydd o PostgreSQL a 15 fersiwn o'r cnewyllyn Linux. Os byddwch chi'n ailysgrifennu'r lleoedd hyn, fe gewch chi adroddiad gwahanol yn y pen draw. Ond dyma diwnio Linux sylfaenol ar gyfer PostgreSQL, sy'n dal yn berthnasol heddiw.

Fy enw i yw Ilya Kosmodemyansky. Rwy'n gweithio i gwmni PostgreSQL-Consulting. Ac yn awr byddaf yn siarad ychydig am beth i'w wneud â Linux mewn perthynas â chronfeydd data yn gyffredinol a PostgreSQL yn arbennig, oherwydd bod yr egwyddorion yn eithaf tebyg.

Beth fydd yn cael ei drafod? Os ydych chi'n delio â PostgreSQL, yna mae angen i chi fod yn weinyddwr UNIX i ryw raddau. Beth mae'n ei olygu? Os ydym yn cymharu Oracle a PostgreSQL, yna yn Oracle mae angen i chi fod yn weinyddwr cronfa ddata 80% DBA a 20% yn weinyddwr Linux.

Mae PostgreSQL ychydig yn anoddach. Gyda PostgreSQL, mae angen i chi gael syniad llawer gwell o sut mae Linux yn gweithio. Ac ar yr un pryd, rhedwch ychydig ar ôl y locomotif, oherwydd yn ddiweddar mae popeth wedi'i ddiweddaru'n eithaf cŵl. Ac mae creiddiau newydd yn dod allan, ac mae ymarferoldeb newydd yn ymddangos, mae perfformiad yn gwella, ac ati.

Pam ydyn ni'n siarad am Linux? Ddim o gwbl oherwydd ein bod ni yng nghynhadledd Linux Peter, ond oherwydd mewn amodau modern un o'r systemau gweithredu mwyaf cyfiawn ar gyfer gweithredu gyda chronfeydd data yn gyffredinol a gyda PostgreSQL yn arbennig yw Linux. Oherwydd mae FreeBSD, yn anffodus, yn datblygu mewn rhyw gyfeiriad rhyfedd iawn. A bydd problemau gyda pherfformiad a llawer o bethau eraill. Yn gyffredinol, mae perfformiad PostgreSQL ar Windows yn bwnc llym ar wahân, yn dibynnu ar y ffaith nad oes gan Windows gof a rennir o'r fath ag UNIX, ac mae PostgreSQL yn ymwneud â'r busnes hwn i gyd, oherwydd ei fod yn system aml-broses.

Ac mae pethau egsotig fel Solaris, dwi'n meddwl, o lai o ddiddordeb i bawb, felly gadewch i ni fynd.

Mae gan ddosbarthiad Linux modern dros 1 o opsiynau syctl, yn dibynnu ar sut mae'r cnewyllyn yn cael ei adeiladu. Ar yr un pryd, os edrychwn ar wahanol gnau, yna gall fod llawer o ffyrdd o addasu rhywbeth o hyd. Mae yna opsiynau system ffeiliau ar sut i osod. Os oes gennych gwestiynau am sut i ddechrau: beth i'w alluogi yn y BIOS, sut i ffurfweddu'r caledwedd, ac ati.

Mae hon yn gyfrol fawr iawn, y gellir siarad amdani am sawl diwrnod, ac nid mewn un adroddiad byr, ond byddaf yn awr yn canolbwyntio ar bethau pwysig, sut i osgoi'r cribiniau hynny na fyddant yn caniatáu ichi weithredu cronfa ddata ar Linux yn dda os nad ydych yn eu trwsio. . Ac ar yr un pryd, pwynt pwysig yw nad yw llawer o baramedrau rhagosodedig wedi'u cynnwys yn y gosodiadau sy'n gywir ar gyfer y gronfa ddata. Hynny yw, yn ddiofyn bydd yn gweithio'n wael neu ni fydd yn gweithio o gwbl.

Beth yw'r targedau tiwnio traddodiadol ar Linux? Gan eich bod i gyd yn delio â gweinyddu Linux, credaf nad oes angen egluro beth yw targedau.

Gallwch diwnio:

• CPUs.
• Cof.
• Storio.
• arall. Byddwn yn siarad am hyn ar y diwedd am fyrbryd. Hyd yn oed, er enghraifft, gall gosodiadau fel polisi arbed pŵer effeithio ar berfformiad mewn ffordd anrhagweladwy iawn ac nid yw'n ddymunol iawn.

Beth yw manylion PostgreSQL a'r gronfa ddata yn gyffredinol? Y broblem yw na allwch chi newid rhywfaint o gneuen benodol a gweld bod ein perfformiad wedi gwella'n fawr.

Oes, mae yna declynnau o'r fath, ond mae'r gronfa ddata yn beth cymhleth. Mae hi'n rhyngweithio â'r holl adnoddau sydd gan y gweinydd ac mae'n well ganddi ryngweithio'n llawn. Os edrychwch ar ganllawiau cyfredol Oracle ar sut i ddefnyddio OS gwesteiwr, mae fel jôc gofodwr Mongolia - bwydo'r ci a pheidiwch â chyffwrdd ag unrhyw beth. Gadewch i ni roi'r holl adnoddau i'r gronfa ddata, bydd y gronfa ddata ei hun yn dinistrio popeth.

Mewn egwyddor, i ryw raddau, mae'r sefyllfa yn union yr un fath â PostgreSQL. Mae'r gwahaniaeth yn gorwedd yn y ffaith nad yw'r sylfaen hefyd yn gallu cymryd yr holl adnoddau drosto'i hun, hynny yw, rhywle ar lefel Linux mae angen i chi ddatrys y cyfan ar eich pen eich hun.

Y prif syniad yw peidio â dewis un targed a dechrau ei diwnio, er enghraifft, cof, CPU neu rywbeth felly, ond i ddadansoddi'r llwyth gwaith a cheisio gwella'r mewnbwn cymaint â phosibl fel bod y llwyth y mae rhaglenwyr da wedi'i greu ar ei gyfer. ni, gan gynnwys ein defnyddwyr.

Dyma lun i egluro beth ydyw. Mae byffer Linux OS ac mae cof a rennir ac mae byfferau a rennir PostgreSQL. Mae PostgreSQL, yn wahanol i Oracle, yn gweithio'n uniongyrchol yn unig trwy'r byffer cnewyllyn, hynny yw, er mwyn i dudalen o ddisg fynd i mewn i'w gof a rennir, rhaid iddo fynd trwy'r byffer cnewyllyn ac yn ôl yn union yr un sefyllfa.

Mae disgiau'n byw o dan y system hon. Tynnais ef fel disgiau. Mewn gwirionedd, efallai y bydd rheolydd RAID, ac ati.

Ac mae'r mewnbwn-allbwn hwn un ffordd neu'r llall yn digwydd trwy'r achos hwn.

Mae PostgreSQL yn gronfa ddata glasurol. Mae y tu mewn i'r dudalen. Ac mae'r holl fewnbwn-allbwn yn digwydd gyda chymorth tudalennau. Rydym yn codi blociau yn y cof wrth dudalennau. Ac os na ddigwyddodd unrhyw beth, rydyn ni'n eu darllen, yna'n raddol maen nhw'n suddo o'r storfa hon, o glustogau a rennir ac yn mynd yn ôl i'r ddisg.

Os ydym wedi disodli rhywbeth yn rhywle, yna mae ein tudalen gyfan wedi'i nodi'n fudr. Fe wnes i eu marcio mewn glas yma. Ac mae hyn yn golygu bod yn rhaid i'r dudalen hon gael ei chydamseru â storfa bloc. Hynny yw, pan wnaethom ni'n fudr, gwnaethon ni gofnod yn WAL. Ac ar ryw adeg iawn, daeth ffenomen o'r enw checkpoint. Ac mae'r log hwn yn cofnodi gwybodaeth y daeth. Ac mae hyn yn golygu bod yr holl dudalennau budr a oedd yma ar y foment honno yn y byfferau a rennir hyn wedi'u cydamseru â'r ddisg storio gan ddefnyddio fsync trwy'r byffer cnewyllyn.

Beth yw ei ddiben? Pe baem yn colli foltedd, yna ni chawsom y sefyllfa bod yr holl ddata wedi'i golli. Mae cof parhaus, y dywedodd pawb wrthym amdano, hyd yn hyn mewn theori cronfa ddata - mae hwn yn ddyfodol disglair, yr ydym, wrth gwrs, yn ymdrechu amdano ac rydym yn ei hoffi, ond hyd yn hyn maent yn dal i fyw mewn minws 20 mlynedd. Ac, wrth gwrs, mae angen monitro hyn i gyd.

A'r dasg o wneud y mwyaf o fewnbwn yw tiwnio ar yr holl gamau hyn fel ei fod yn mynd yn ôl ac ymlaen yn gyflym. Yn y bôn, storfa tudalen yw cof a rennir. Yn PostgreSQL, anfonwyd cais dewis rhywbeth yno, cafodd y data hwn o'r ddisg. Fe wnaethon nhw fynd i mewn i glustogau a rennir. Yn unol â hynny, er mwyn i hyn weithio'n well, rhaid bod llawer o gof.

Er mwyn i hyn i gyd weithio'n dda ac yn gyflym, mae angen i chi ffurfweddu'r system weithredu yn gywir ar bob cam. A dewiswch haearn cytbwys, oherwydd os oes gennych anghydbwysedd mewn rhyw le, yna gallwch chi wneud llawer o gof, ond bydd yn cael ei weini ar gyflymder annigonol.

Gadewch i ni fynd trwy bob un o'r pwyntiau hyn.

Er mwyn i'r tudalennau hyn deithio'n ôl ac ymlaen yn gyflymach, mae angen i chi gyflawni'r canlynol:

• Yn gyntaf, mae angen i chi weithio'n fwy effeithlon gyda'r cof.
• Yn ail, dylai'r trawsnewid hwn fod yn fwy effeithlon pan fydd tudalennau o'r cof yn mynd i ddisg.
• Ac, yn drydydd, rhaid cael disgiau da.

Os oes gennych 512 GB o RAM yn y gweinydd a bod hyn i gyd yn dod i ben ar yriant caled SATA heb unrhyw storfa, yna mae gweinydd y gronfa ddata gyfan yn troi nid yn unig yn bwmpen, ond yn bwmpen gyda rhyngwyneb SATA. Byddwch yn rhedeg i mewn iddo yn uniongyrchol. Ac ni fydd dim yn eich arbed.

O ran y pwynt cyntaf gyda'r cof, mae tri pheth a all wneud bywyd yn anodd iawn.

Yr un cyntaf yw NUMA. Mae NUMA yn beth sy'n cael ei wneud i wella perfformiad. Yn dibynnu ar y llwyth gwaith, gallwch chi wneud y gorau o wahanol bethau. Ac yn ei ffurf gyfredol newydd, nid yw'n dda iawn ar gyfer ceisiadau fel cronfa ddata sy'n defnyddio byfferau a rennir cache tudalen yn ddwys.

Yn gryno. Sut i ddeall bod rhywbeth o'i le ar NUMA? Mae gennych ryw fath o gnoc annymunol, yn sydyn mae rhywfaint o CPU yn cael ei orlwytho. Ar yr un pryd, rydych chi'n dadansoddi ymholiadau yn PostgreSQL ac yn gweld nad oes dim byd tebyg yno. Ni ddylai'r ceisiadau hyn fod mor ddwys o ran CPU. Gallwch chi ei ddal am amser hir. Mae'n haws defnyddio'r cyngor cywir o'r dechrau ar sut i sefydlu NUMA ar gyfer PostgreSQL.

Beth sy'n digwydd mewn gwirionedd? Ystyr NUMA yw Mynediad Cof Di-Unffurf. Beth yw'r pwynt? Mae gennych CPU, wrth ei ymyl mae ei gof lleol. A gall y cof hwn yn cydgysylltu dynnu cof o CPUs eraill.

Os ydych yn rhedeg numactl --hardware, yna byddwch yn cael taflen mor fawr. Ymhlith pethau eraill, bydd maes pellter. Bydd niferoedd - 10-20, rhywbeth felly. Nid yw'r niferoedd hyn yn ddim byd ond nifer y hopys i godi'r cof anghysbell hwn a'i ddefnyddio'n lleol. Syniad da yn y bôn. Mae hyn yn gwella perfformiad yn dda mewn nifer o lwythi gwaith.

Nawr dychmygwch fod gennych un CPU yn gyntaf yn ceisio defnyddio ei gof lleol, yna ceisio tynnu cof arall trwy rhyng-gysylltiad ar gyfer rhywbeth. Ac mae eich storfa dudalen PostgreSQL gyfan yn cyrraedd y CPU hwn - dyna ni, faint o gigabeit sydd yno. Rydych chi bob amser yn cael yr achos gwaethaf oherwydd fel arfer ychydig iawn o gof sydd ar y CPU yn uniongyrchol yn y modiwl hwnnw. Ac mae'r holl gof a weinir yn mynd trwy'r rhyng-gysylltiadau hyn. Mae'n troi allan yn araf ac yn drist. Ac mae gennych brosesydd sy'n gwasanaethu nod hwn yn cael ei orlwytho'n gyson. Ac mae amser mynediad y cof hwn yn ddrwg, yn araf. Dyma'r math o sefyllfa nad ydych chi ei heisiau os ydych chi'n defnyddio'r achos hwn ar gyfer cronfa ddata.

Felly, opsiwn mwy cywir ar gyfer y gronfa ddata yw nad yw system weithredu Linux yn gwybod o gwbl beth sy'n digwydd yno. Fel ei bod yn mynd i'r afael â'r cof wrth iddi annerch.

Pam hynny? Mae'n ymddangos y dylai fod y ffordd arall. Mae hyn yn digwydd am un rheswm syml, sef bod angen llawer o gof ar gyfer cache tudalen - degau, cannoedd o gigabeit.

Ac os byddwn yn dyrannu hyn i gyd ac yn storio ein data yno, yna bydd y budd o ddefnyddio'r storfa yn sylweddol fwy na'r enillion o fynediad cof mor gyfrwys. Ac yn y modd hwn byddwn yn ennill yn anghymharol o'i gymharu â'r ffaith y byddwn yn cyrchu cof yn fwy effeithlon gan ddefnyddio NUMA.

Felly, mae dau ddull ar hyn o bryd, nes bod dyfodol disglair wedi dod, ac ni all y gronfa ddata ei hun ddarganfod pa CPUs y mae'n gweithio arnynt ac o ble mae angen iddo dynnu rhywbeth.

Felly, y dull cywir yw analluogi NUMA yn gyfan gwble.e. wrth ailgychwyn. Yn y rhan fwyaf o achosion, mae'r enillion yn y fath drefn fel nad oes unrhyw gwestiwn o gwbl, pa un sy'n well.

Mae opsiwn arall. Rydyn ni'n ei ddefnyddio'n amlach na'r un cyntaf, oherwydd pan fydd cleient yn dod atom ni am gefnogaeth, yna mae iddo ailgychwyn y gweinydd yn beth cyfan. Mae ganddo fusnes yno. Ac maen nhw'n cael problemau oherwydd NUMA. Felly, rydym yn ceisio ei analluogi mewn ffyrdd llai ymledol nag ailgychwyn, ond yma byddwch yn ofalus i wirio ei fod yn anabl. Oherwydd, fel y dengys profiad, ein bod yn analluogi NUMA ar broses rhiant PostgreSQL, mae hyn yn dda, ond nid yw'n angenrheidiol o gwbl y bydd hyn yn gweithio. Mae angen i ni wirio a gweld ei bod hi wir wedi diffodd.

Mae post da gan Robert Haas. Dyma un o ymroddwyr PostgreSQL. Un o ddatblygwyr allweddol pob giblets lefel isel. Ac os dilynwch y dolenni o'r post hwn, mae'n disgrifio sawl stori liwgar am sut y gwnaeth NUMA fywyd yn anodd i bobl. Edrychwch, astudiwch restr wirio gweinyddwr y system o'r hyn sydd angen ei ffurfweddu ar y gweinydd er mwyn i'n cronfa ddata weithio'n dda. Mae angen cofnodi a gwirio'r gosodiadau hyn, oherwydd fel arall ni fydd yn dda iawn.

Tynnaf eich sylw at y ffaith bod hyn yn berthnasol i’r holl leoliadau y byddaf yn siarad amdanynt. Ond fel arfer cronfeydd data yn cael eu cydosod yn y modd meistr-gaethwas ar gyfer goddef diffygion. Peidiwch ag anghofio gwneud y gosodiadau hyn ar y caethwas, oherwydd un diwrnod byddwch yn cael damwain a byddwch yn newid i'r caethwas a bydd yn dod yn feistr.

Mewn argyfwng, pan fydd popeth yn ddrwg iawn, mae'ch ffôn yn canu'n gyson a'ch bos yn rhedeg gyda ffon fawr, ni fydd gennych amser i feddwl am wirio. A gall y canlyniadau fod yn drychinebus iawn.

Mae'r eiliad nesaf yn dudalennau enfawr. Mae tudalennau enfawr yn anodd eu profi ar wahân, ac nid oes unrhyw bwynt i hyn, er bod meincnodau a all wneud hyn. Maent yn hawdd eu googled.

Beth yw'r pwynt? Mae gennych weinydd nad yw'n ddrud iawn sydd â llawer o RAM, er enghraifft, mwy na 30 GB. Nid ydych yn defnyddio tudalennau enfawr. Mae hyn yn golygu eich bod yn bendant yn cael gorbenion ar ddefnyddio cof. Ac y mae y gorphwysiad hwn ymhell o fod y mwyaf dymunol.

Pam hynny? A beth sy'n mynd ymlaen? Mae'r system weithredu yn dyrannu cof mewn talpiau bach. Mor gyfleus, mor hanesyddol. Ac os ewch chi i fanylion, yna mae'n rhaid i'r OS drosi cyfeiriadau rhithwir yn rhai corfforol. Ac nid y broses hon yw'r hawsaf, felly mae'r OS yn storio canlyniad y llawdriniaeth hon yn y Cyfieithu Lookaside Buffer (TLB).

A chan fod y TLB yn storfa, yna yn y sefyllfa hon mae'r holl broblemau sy'n gynhenid ​​​​yn y storfa yn codi. Yn gyntaf, os oes gennych lawer o RAM a bod y cyfan yn cael ei ddyrannu mewn talpiau bach, yna mae'r byffer hwn yn dod yn fawr iawn. Ac os yw'r storfa'n fawr, yna mae'n arafach i chwilio amdano. Mae gorbenion yn iach ac yn cymryd lle ar ei ben ei hun, h.y. mae rhywbeth o'i le yn defnyddio RAM. Y tro hwn.

Dau - po fwyaf y bydd y storfa'n tyfu mewn sefyllfa o'r fath, y mwyaf tebygol yw hi y bydd gennych fethiannau cache. Ac mae effeithlonrwydd y storfa hon yn gostwng yn gyflym wrth i'w faint dyfu. Felly lluniodd systemau gweithredu ymagwedd syml. Mae Linux wedi bod yn ei ddefnyddio ers amser maith. Ymddangosodd yn FreeBSD ddim mor bell yn ôl. Ond rydyn ni'n siarad am Linux. Mae'r rhain yn dudalennau enfawr.

Ac yma dylid nodi bod tudalennau enfawr, fel syniad, wedi’u gwthio drwodd i ddechrau gan gymunedau a oedd yn cynnwys Oracle ac IBM, h.y. roedd gwneuthurwyr cronfeydd data yn meddwl yn galed am y ffaith y byddai hyn yn ddefnyddiol, gan gynnwys ar gyfer cronfeydd data.

A sut i wneud ffrindiau gyda PostgreSQL? Yn gyntaf, rhaid galluogi tudalennau enfawr yn y cnewyllyn Linux.

Yn ail, rhaid iddynt gael eu nodi'n benodol gan y paramedr sysctl - faint sydd. Mae'r niferoedd yma o rai hen weinydd. Gallwch gyfrifo tua faint o glustogau a rennir sydd gennych fel bod tudalennau enfawr yn ffitio yno.

Ac os oes gennych chi'r gweinydd cyfan yn ymroddedig i PostgreSQL, yna man cychwyn da yw naill ai rhoi 25% o RAM ar gyfer byfferau a rennir, neu 75% os ydych chi'n siŵr y bydd eich cronfa ddata yn bendant yn ffitio yn y 75% hyn. Man cychwyn yn gyntaf. Ac ystyriwch, os oes gennych 256 GB o RAM, yna, yn unol â hynny, bydd gennych 64 GB o glustogau shed. Cyfrifwch yn fras gyda rhywfaint o ymyl - i beth y dylech osod y ffigur hwn.

Cyn fersiwn 9.2 (os nad wyf yn camgymryd, ers fersiwn 8.2) roedd yn bosibl gwneud ffrindiau gyda thudalennau enfawr PostgreSQL gan ddefnyddio llyfrgell trydydd parti. A dylid gwneud hyn bob amser. Yn gyntaf, mae angen y cnewyllyn arnoch i allu dyrannu tudalennau enfawr yn gywir. Ac, yn ail, fel y gall y cymhwysiad sy'n gweithio gyda nhw eu defnyddio. Ni fydd yn cael ei ddefnyddio felly. Gan fod PostgreSQL wedi dyrannu cof mewn arddull system 5, gellid gwneud hyn gan ddefnyddio libhugetlbfs - dyma enw llawn y llyfrgell.

9.3 gwell perfformiad cof PostgreSQL a chael gwared ar y dull dyrannu cof system 5. Roedd pawb yn hapus iawn, oherwydd fel arall rydych chi'n ceisio rhedeg dau achos PostgreSQL ar yr un peiriant, ac mae'n dweud nad oes gen i ddigon o gof a rennir. Ac mae'n dweud bod angen i chi drwsio sysctl. Ac mae sysctl o'r fath y mae angen i chi ei ailgychwyn o hyd, ac ati Yn gyffredinol, roedd pawb wrth eu bodd. Ond torrodd dyraniad cof mmap gan ddefnyddio tudalennau enfawr. Mae'r rhan fwyaf o'n cleientiaid yn defnyddio byfferau mawr a rennir. Ac fe wnaethom argymell yn gryf i beidio â newid i 9.3, oherwydd dechreuwyd cyfrifo gorbenion mewn canrannau da.

Ond ar y llaw arall, tynnodd y gymuned sylw at y broblem hon ac yn 9.4 fe wnaethant ail-weithio'r digwyddiad hwn yn dda iawn. Ac yn 9.4, ymddangosodd paramedr yn postgresql.conf, lle gallwch chi droi ymlaen ceisiwch, ymlaen neu i ffwrdd.

Ceisiwch yw'r opsiwn mwyaf diogel. Pan fydd PostgreSQL yn cychwyn, pan fydd yn dyrannu cof a rennir, mae'n ceisio cydio yn y cof hwn o dudalennau enfawr. Ac os nad yw'n gweithio, yna mae'n mynd yn ôl i'r dewis arferol. Ac os oes gennych chi FreeBSD neu Solaris, yna gallwch chi roi cynnig arni, mae bob amser yn ddiogel.

Os ymlaen, yna nid yw'n dechrau os na allai ddewis o dudalennau enfawr. Yma eisoes - i bwy a beth sy'n fwy ciwt. Ond os oes gennych chi gynnig arni, gwiriwch fod gennych chi'r hyn sydd ei angen arnoch chi mewn gwirionedd, oherwydd mae yna lawer o leoedd ar gyfer gwall. Ar hyn o bryd, dim ond ar Linux y mae'r swyddogaeth hon yn gweithio.

Un nodyn bach arall cyn i ni symud ymlaen. Nid yw tudalennau enfawr tryloyw yn ymwneud â PostgreSQL eto. Ni all eu defnyddio fel arfer. A chyda thudalennau enfawr Tryloyw ar gyfer llwyth gwaith o'r fath, pan fydd angen darn mawr o gof a rennir arnoch, dim ond gyda chyfeintiau mawr iawn y daw'r manteision. Os oes gennych terabytes o gof, yna gall hyn chwarae rôl. Os ydym yn sôn am fwy o gymwysiadau bob dydd, pan fydd gennych 32, 64, 128, 256 GB o gof ar y peiriant, yna mae'r tudalennau enfawr arferol yn iawn, ac rydym yn diffodd Tryloywder.

Ac nid yw'r peth olaf am y cof yn uniongyrchol gysylltiedig â ffrwyth, gall ddifetha bywyd yn fawr iawn. Bydd yr holl trwygyrch yn cael ei effeithio'n fawr gan y ffaith bod y gweinydd yn cyfnewid yn gyson.

A bydd yn annymunol iawn ar rai adegau. A'r prif drafferth yw bod yr ymddygiad mewn cnewyllyn modern ychydig yn wahanol i gnewyllyn Linux hŷn. Ac mae'r peth hwn, sydd braidd yn annymunol i gamu ymlaen, oherwydd pan fyddwn yn siarad am rywfaint o waith gyda chyfnewid, mae'n gorffen gyda dyfodiad annhymig y llofrudd OOM. Ac mae'r llofrudd OOM, na ddaeth mewn amser a thaflu PostgreSQL i ffwrdd, yn annymunol. Bydd pawb yn gwybod amdano, hynny yw, tan y defnyddiwr olaf.

Beth sy'n Digwydd? Mae gennych chi lawer iawn o RAM yno, mae popeth yn gweithio'n dda. Ond am ryw reswm mae'r gweinydd yn hongian mewn cyfnewid ac yn arafu oherwydd hyn. Mae'n ymddangos bod yna lawer o gof, ond mae'n digwydd.

Yn flaenorol, fe wnaethom gynghori y dylid gosod vm.swappiness i sero, h.y. analluogi cyfnewid. Yn flaenorol, roedd yn ymddangos bod 32 GB o RAM a byfferau a rennir cyfatebol yn swm enfawr. Prif bwrpas y cyfnewid yw cael lle i daflu cramen os byddwn yn cwympo i ffwrdd. Ac nid yw wedi cael ei wneud yn dda iawn. Ac yna beth fyddwch chi'n ei wneud â'r gramen hon? Mae hon eisoes yn gymaint o dasg pan nad yw'n glir iawn pam fod angen cyfnewid, yn enwedig o'r fath faint.

Ond mewn mwy modern, h.y., yn nhrydydd fersiwn y cnewyllyn, mae'r ymddygiad wedi newid. Ac os byddwch chi'n gosod cyfnewid i sero, h.y. ei ddiffodd, yna yn hwyr neu'n hwyrach, hyd yn oed gyda rhywfaint o RAM ar ôl, bydd lladdwr OOM yn dod atoch chi i ladd y defnyddwyr mwyaf dwys. Oherwydd bydd yn ystyried gyda llwyth gwaith o'r fath fod gennym ychydig ar ôl o hyd a byddwn yn neidio allan, hynny yw, nid lladd proses y system, ond lladd rhywbeth llai pwysig. Hyn yn llai pwysig fydd y defnyddiwr trwm o gof a rennir, sef y postfeistr. Ac ar ôl hynny bydd yn dda os nad oes angen adfer y sylfaen.

Felly, yn awr y rhagosodiad, hyd y cofiaf, mae'r rhan fwyaf o ddosbarthiadau rhywle o gwmpas 6, h.y. ar ba bwynt i ddechrau defnyddio cyfnewid, yn dibynnu ar faint o gof sydd ar ôl. Cynghorwn yn awr osod vm.swappiness = 1, oherwydd ei fod yn ymarferol yn ei ddiffodd, ond nid yw'n rhoi effeithiau o'r fath fel gyda llofrudd OOM annisgwyl a ddaeth ac a laddodd yr holl beth.

Beth sydd nesaf? Pan fyddwn yn siarad am berfformiad cronfeydd data ac yn raddol, yn raddol, rydym fel disgiau, mae pawb yn dechrau cydio yn eu pennau. Oherwydd bod y gwir bod y ddisg yn araf a'r cof yn gyflym wedi bod yn gyfarwydd i bawb ers plentyndod. Ac mae pawb yn gwybod y bydd materion perfformiad disg yn y gronfa ddata.

Nid yw prif broblem perfformiad PostgreSQL gyda phigau pwyntiau gwirio oherwydd bod y ddisg yn araf. Mae hyn yn fwy tebygol oherwydd y ffaith nad yw lled band y cof a disg yn gytbwys. Fodd bynnag, efallai na fyddant yn gytbwys mewn gwahanol leoedd. Nid yw PostgreSQL wedi'i ffurfweddu, nid yw OS wedi'i ffurfweddu, nid yw caledwedd wedi'i ffurfweddu ac mae caledwedd yn anghywir. Ac nid yw'r broblem hon yn digwydd dim ond os aiff popeth fel y dylai, h.y. naill ai nad oes llwyth, neu mae'r gosodiadau a'r caledwedd wedi'u dewis yn dda.

Beth ydyw a sut olwg sydd arno? Fel arfer, mae pobl sy'n gweithio gyda PostgreSQL wedi ymuno â'r busnes hwn fwy nag unwaith. Byddaf yn esbonio. Fel y dywedais, mae PostgreSQL o bryd i'w gilydd yn gwneud pwyntiau gwirio i ollwng tudalennau budr mewn cof a rennir i ddisg. Os oes gennym lawer iawn o gof a rennir, yna mae checkpoint yn dechrau effeithio'n ddwys ar y ddisg, oherwydd mae fsync yn gollwng y tudalennau hyn. Mae'n cyrraedd y byffer cnewyllyn ac yn cael ei ysgrifennu i ddisg gan ddefnyddio fsync. Ac os yw cyfaint yr achos hwn yn fawr, yna gallwn weld effaith annymunol, sef, defnydd mawr iawn o ddisgiau.

Dyma ddau lun gyda fi. Egluraf yn awr beth ydyw. Mae'r rhain yn ddau graff sy'n cyfateb i amser. Y graff cyntaf yw defnydd disg. Yma mae'n cyrraedd bron i 90% ar hyn o bryd. Os oes gennych chi gwymp cronfa ddata gyda disgiau corfforol, gyda rheolydd RAID o dan 90% o ddefnydd, yna mae hyn yn newyddion drwg. Mae hyn yn golygu y bydd ychydig yn fwy a 100 yn dod a bydd y mewnbwn / allbwn yn dod i ben.

Os oes gennych arae ddisg, yna mae stori ychydig yn wahanol. Yno mae'n dibynnu ar sut mae wedi'i ffurfweddu, pa fath o amrywiaeth, ac ati.

Ac ar y cyd, mae graff wedi'i ffurfweddu yma o'r golwg postgres mewnol, sy'n dweud sut mae'r pwynt gwirio yn digwydd. Ac mae'r lliw gwyrdd yma yn dangos faint o glustogau o'r tudalennau budr hyn ar yr adeg honno a gyrhaeddodd y pwynt gwirio hwn ar gyfer cydamseru. A dyma'r prif beth i'w wybod yma. Rydym yn gweld bod gennym lawer o dudalennau yma ac ar ryw adeg rydym yn rhedeg i mewn i ffi, hynny yw, rydym yn ysgrifennu ac yn ysgrifennu, yma mae'r system ddisg yn amlwg yn brysur iawn. Ac mae ein pwynt gwirio yn cael effaith gref iawn ar y ddisg. Yn ddelfrydol, dylai’r sefyllfa edrych yn debycach i hyn, h.y. roedd gennym lai o record yma. A gallwn ei drwsio gyda gosodiadau fel ei fod yn parhau fel hyn. Hynny yw, mae'r ailgylchu yn fach, ond yn rhywle rydyn ni'n ysgrifennu rhywbeth yma.

Beth sydd angen ei wneud i oresgyn y broblem hon? Os ydych chi wedi rhoi'r gorau i IO o dan y gronfa ddata, yna mae hyn yn golygu y bydd yr holl ddefnyddwyr a ddaeth i weithredu eu ceisiadau yn aros.

Os edrychwch o safbwynt Linux, pe baech chi'n cymryd caledwedd da, wedi'i ffurfweddu'n gywir, wedi ffurfweddu PostgreSQL fel arfer fel y byddai'n gwneud y pwyntiau gwirio hyn yn llai aml, yn eu lledaenu mewn amser rhwng ei gilydd, yna rydych chi'n camu i'r paramedrau Debian rhagosodedig . Ar gyfer y rhan fwyaf o ddosbarthiadau Linux, dyma'r llun: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Beth mae'n ei olygu? Ers cnewyllyn 2.6, mae un fflysio cythraul wedi ymddangos. Pdglush, yn dibynnu ar bwy sy'n defnyddio beth, sy'n ymwneud â'r cefndir taflu tudalennau budr oddi ar y byffer cnewyllyn a thaflu oddi ar dudalennau budr pan fo angen, ni waeth beth, pan nad yw taflu backgrouind yn helpu.

Pryd daw cefndir? Pan fydd 10% o gyfanswm yr RAM sydd ar y gweinydd yn cael ei feddiannu gan dudalennau budr yn y byffer cnewyllyn, yna gelwir swyddogaeth twyllo arbennig yn y cefndir. Pam mae hi'n gefndir? Mae'n cymryd fel paramedr faint o dudalennau i'w dileu. Ac, gadewch i ni ddweud, yn dileu N tudalennau. Ac am ychydig, mae'r peth hwn yn cwympo i gysgu. Ac yna mae hi'n dod yn ôl ac yn ysgrifennu oddi ar rai tudalennau eraill.

Mae hon yn stori hynod o syml. Yma mae'r dasg yn debyg gyda phwll, pan fydd yn arllwys i un bibell, yn arllwys i mewn i un arall. Daeth ein pwynt gwirio ac os anfonodd ychydig o dudalennau budr i'w taflu, yna'n raddol o'r pgflush byffer cnewyllyn bydd yr holl beth hwn yn datrys yn daclus.

Os yw'r tudalennau budr hyn yn parhau i gronni, maent yn cronni hyd at 20%, ar ôl hynny blaenoriaeth yr AO yw dileu'r holl beth i ddisg, oherwydd bydd y pŵer yn hedfan allan, a bydd popeth yn ddrwg i ni. Byddwn yn colli'r data hwn, er enghraifft.

Beth yw'r tric? Y tric yw bod y paramedrau hyn yn y byd modern o 20 a 10% o'r holl RAM sydd ar y peiriant, yn gwbl gwrthun o ran trwygyrch unrhyw system ddisg sydd gennych.

Dychmygwch fod gennych 128 GB o RAM. Daw 12,8 GB i'ch system ddisg. Ac ni waeth pa storfa sydd gennych yno, ni waeth pa amrywiaeth sydd gennych yno, ni fyddant yn gwrthsefyll cymaint.

Felly, rydym yn argymell bod y niferoedd hyn yn cael eu haddasu ar unwaith yn dibynnu ar alluoedd eich rheolydd RAID. Rhoddais argymhelliad yma ar unwaith ar gyfer rheolydd sydd â 512 MB o storfa.

Ystyrir bod popeth yn syml iawn. Gallwch chi roi vm.dirty_background mewn beit. Ac mae'r gosodiadau hyn yn diystyru'r ddau flaenorol. Naill ai mae'r gymhareb yn ddiofyn, neu mae'r rhai â beit yn cael eu gweithredu, yna bydd y rhai â beit yn gweithio. Ond gan fy mod yn ymgynghorydd DBA ac yn gweithio gyda chleientiaid gwahanol, rwy'n ceisio gosod gwellt ac felly, os mewn beit, yna mewn beit. Ni roddodd unrhyw un unrhyw sicrwydd na fyddai gweinyddwr da yn ychwanegu cof at y gweinydd, na fyddai'n ei ailgychwyn, a byddai'r ffigur yn aros yr un fath. Cyfrifwch y niferoedd hyn fel bod popeth yn cyd-fynd â gwarant.

Beth sy'n digwydd os nad ydych chi'n ffitio i mewn? Rwyf wedi ysgrifennu sydd i bob pwrpas yn atal unrhyw fflysio, ond mewn gwirionedd mae'n ffigur lleferydd. Mae gan y system weithredu broblem fawr - mae ganddi lawer o dudalennau budr, felly mae'r IO y mae eich cleientiaid yn ei gynhyrchu yn dod i ben yn effeithiol, h.y. mae'r cais wedi dod i anfon ymholiad sql i'r gronfa ddata, mae'n aros. Mae unrhyw I/O iddo yn y flaenoriaeth isaf, oherwydd bod y pwynt gwirio yn defnyddio'r sylfaen. A phan fydd hi'n gorffen mae'n gwbl annealladwy. A phan fyddwch wedi cyrraedd fflysio di-gefndir, di-gefndir, mae'n golygu bod eich holl IO yn cael ei feddiannu ganddo. A hyd nes iddo ddod i ben, ni fyddwch yn gwneud unrhyw beth.

Mae dau bwynt pwysig arall sydd y tu hwnt i gwmpas yr adroddiad hwn. Dylai'r gosodiadau hyn gyd-fynd â'r gosodiadau yn postgresql.conf, h.y. y gosodiadau pwyntiau gwirio. Ac mae'n rhaid i'ch system ddisg gael ei ffurfweddu'n ddigonol. Os oes gennych storfa ar y RAID, yna mae'n rhaid iddo gael batri. Mae pobl yn prynu RAID gyda storfa dda heb batri. Os oes gennych SSD yn RAID, yna mae'n rhaid iddynt fod yn rhai gweinydd, rhaid bod cynwysorau. Dyma'r rhestr wirio estynedig. Yn y ddolen hon mae fy adroddiad ar sut i sefydlu perfformiad disg yn PostgreSQL. Mae'r rhestrau gwirio hynny i gyd yno.

Beth arall all wneud bywyd yn anodd iawn? Dyma ddau opsiwn. Maent yn gymharol newydd. Yn ddiofyn, gellir eu cynnwys mewn gwahanol gymwysiadau. A gallant gymhlethu bywyd lawn cymaint os cânt eu troi ymlaen yn anghywir.

Mae dau ddarn cymharol newydd. Maent eisoes wedi ymddangos yn y trydydd creiddiau. Mae'r rhain yn sched_migration_cost mewn nanoseconds a sched_autogroup_enabled sef un yn ddiofyn.

A sut maen nhw'n difetha bywyd? Beth yw sched_migration_cost? Gall yr amserlennydd Linux symud proses o un CPU i'r llall. Ac ar gyfer PostgreSQL, sy'n gweithredu ymholiadau, mae mudo i CPU arall yn gwbl annealladwy pam. O safbwynt system weithredu, pan fyddwch yn newid ffenestri rhwng openoffice a therfynell, gall hyn fod yn iawn, ond ar gyfer y gronfa ddata - mae'n ddrwg iawn. Felly, polisi rhesymol yw gosod cost mudo i ryw werth mawr, o leiaf ychydig filoedd o nanoseconds.

Beth fydd hyn yn ei olygu i'r trefnydd? Tybir bod y broses hon yn dal yn boeth yn ystod yr amser hwn. Hynny yw, os oes gennych chi ryw fath o drafodiad hir yn gwneud rhywbeth am amser hir, bydd y trefnydd yn deall hyn. Bydd yn cymryd yn ganiataol, nes bod y terfyn amser hwn wedi dod i ben, na fydd angen symud y broses hon i unrhyw le. Os bydd y broses yn gwneud rhywbeth ar yr un pryd, yna ni fydd yn cael ei symud i unrhyw le, bydd yn gorffen yn dawel ar y CPU a ddyrannwyd iddo. Ac mae'r canlyniad yn rhagorol.

Yr ail bwynt yw autogroup. Mae yna syniad da ar gyfer llwythi gwaith penodol nad ydynt yn gysylltiedig â chronfeydd data modern - mae hyn ar gyfer grwpio prosesau yn ôl y derfynell rithwir y cânt eu lansio ohoni. Mae'n gyfleus ar gyfer rhai tasgau. Yn ymarferol, mae PostgreSQL yn system aml-broses prefork sy'n rhedeg o derfynell sengl. Mae gennych ysgrifennwr clo, pwynt gwirio, ac mae eich holl geisiadau cleient wedi'u grwpio i un amserlennydd, fesul CPU. A byddant yn aros gyda'i gilydd yno pan fydd yn rhydd, er mwyn ymyrryd â'i gilydd a'i gadw'n brysur yn hirach. Dyma stori sy’n gwbl ddiangen yn achos y fath lwyth ac felly dylid ei diffodd.

Gwnaeth fy nghydweithiwr Alexey Lesovsky brofion gyda meinciau tud syml, lle cynyddodd mudo_cost yn ôl trefn maint a diffoddodd autogroup. Trodd y gwahaniaeth ar ddarn drwg o haearn allan i fod bron i 10%. Mae yna drafodaeth ar restr bostio postgres lle mae pobl yn adrodd am ganlyniadau fel newidiadau tebyg i gyflymder ymholiad dylanwadu 50%. Mae yna dipyn o straeon o'r fath.

Ac yn olaf, am y polisi arbed ynni. Mae'n dda bod Linux bellach yn gallu cael ei ddefnyddio ar liniadur. Ac mae'n debyg y bydd yn defnyddio'r batri yn dda. Ond yn sydyn mae'n troi allan y gall hyn ddigwydd ar y gweinydd hefyd.

Ar ben hynny, os ydych chi'n rhentu gweinyddwyr gan westeiwr, yna nid yw gwesteiwyr “da” yn poeni bod gennych chi berfformiad gwell. Eu tasg yw sicrhau bod eu haearn yn cael ei ddefnyddio mor effeithlon â phosibl. Felly, yn ddiofyn, gallant droi'r modd arbed pŵer gliniadur ymlaen ar y system weithredu.

Os ydych chi'n defnyddio hwn ar weinydd cronfa ddata sydd wedi'i lwytho'n drwm, yna eich dewis yw acpi_cpufreq + permormance. Hyd yn oed gydag ondemand, bydd problemau eisoes.

Mae Intel_pstate yn yrrwr ychydig yn wahanol. Ac yn awr rhoddir ffafriaeth i'r un hwn, yn hytrach nag un diweddarach sy'n gweithio'n well.

Ac, yn unol â hynny, dim ond perfformiad yw'r llywodraethwr. Ondemand, powersave a'r gweddill i gyd - nid yw hyn yn ymwneud â chi.

Gall canlyniadau dadansoddi Egluro PostgreSQL amrywio yn ôl nifer o orchmynion maint os byddwch chi'n troi pwerau arbed ymlaen, oherwydd yn ymarferol bydd gennych CPU yn cael ei daflu o dan y gronfa ddata mewn ffordd gwbl anrhagweladwy.

Gellir galluogi'r pethau hyn yn ddiofyn. Edrychwch yn ofalus i weld a ydynt wedi'u galluogi yn ddiofyn. Gall hyn fod yn broblem fawr iawn.

Ac yn y diwedd, roeddwn i eisiau dweud diolch i'r bechgyn o'n tîm DBA PosgreSQL-Consulting, sef Max Boguk ac Alexey Lesovsky, sydd bob dydd yn llenwi'r busnes hwn. Ac ar gyfer ein cleientiaid, rydym yn ceisio gwneud y gorau, fel bod y cyfan yn gweithio iddynt. Mae'n debyg gyda chyfarwyddiadau diogelwch hedfan. Mae popeth yma wedi'i ysgrifennu mewn gwaed. Mae pob un o'r cnau hyn yn cael ei ddarganfod yn y broses o ryw fath o broblem. Rwy'n hapus i'w rhannu gyda chi.

Cwestiynau:

Diolch! Er enghraifft, os yw cwmni eisiau arbed arian a chynnal y gronfa ddata a rhesymeg y cais ar yr un gweinydd, neu os yw'r cwmni'n dilyn y duedd ffasiwn o bensaernïaeth microwasanaeth y mae PostgreSQL yn rhedeg mewn cynhwysydd ynddo. Beth yw'r pwynt? Mae Sysctl yn effeithio ar y cnewyllyn cyfan yn fyd-eang. Nid wyf wedi clywed bod sysctl yn cael ei rhithwiroli rywsut fel eu bod yn gweithio ar wahân ar y cynhwysydd. Dim ond cgroup sydd a dim ond rhan ohono sydd â rheolaeth. Sut gallwch chi fyw gyda hyn? Neu os ydych chi eisiau perfformiad, yna rhedeg PostgreSQL ar weinydd haearn ar wahân a'i diwnio?

Rydym wedi ateb eich cwestiwn mewn tua thair ffordd. Os nad ydym yn sôn am weinydd haearn y gellir ei diwnio, ac ati, yna ymlacio, bydd popeth yn gweithio'n iawn heb y gosodiadau hyn. Os oes gennych chi gymaint o lwyth fel bod angen i chi wneud y gosodiadau hyn, yna fe ddowch at y gweinydd haearn yn gynharach na'r gosodiadau hyn.

Beth yw'r broblem? Os yw hwn yn beiriant rhithwir, yna mae'n fwyaf tebygol y bydd gennych lawer o broblemau, er enghraifft, gyda'r ffaith bod gan y mwyafrif o beiriannau rhithwir hwyrni disg braidd yn anghyson. Hyd yn oed os yw trwybwn disg yn dda, yna un trafodiad I/O a fethodd nad yw'n effeithio'n fawr ar y trwybwn cyfartalog a ddigwyddodd ar adeg y pwynt gwirio neu ar adeg ysgrifennu at WAL, yna bydd y gronfa ddata yn dioddef yn fawr o hyn. A byddwch yn sylwi ar hyn cyn i chi ddod ar draws y problemau hyn.

Os oes gennych NGINX ar yr un gweinydd, bydd gennych yr un broblem hefyd. Bydd yn ymladd dros gof a rennir. Ac ni fyddwch yn cyrraedd y problemau a ddisgrifir yma.

Ond ar y llaw arall, bydd rhai o'r paramedrau hyn yn dal i fod yn berthnasol i chi. Er enghraifft, gyda sysctl, gosod dirty_ratio fel nad yw mor wallgof - beth bynnag, bydd hyn yn helpu. Un ffordd neu'r llall, byddwch yn rhyngweithio â'r ddisg. A bydd yn anghywir. Yn gyffredinol, dyma ragosodiad y paramedrau a ddangosais. Ac mewn unrhyw achos, mae'n well eu newid.

A chyda NUMA gall fod problemau. Mae VmWare, er enghraifft, yn gweithio'n dda gyda NUMA gyda'r gosodiadau gyferbyn yn union. Ac yma mae'n rhaid i chi ddewis - gweinydd haearn neu un nad yw'n haearn.

Mae gen i gwestiwn yn ymwneud ag Amazon AWS. Mae ganddyn nhw ddelweddau wedi'u ffurfweddu ymlaen llaw. Gelwir un ohonynt yn Amazon RDS. A oes unrhyw osodiadau personol ar gyfer eu system weithredu?

Mae yna leoliadau, ond maen nhw'n leoliadau gwahanol. Yma rydym yn ffurfweddu'r system weithredu o ran sut y bydd y gronfa ddata yn defnyddio'r busnes hwn. Ac mae paramedrau sy'n pennu ble y dylem fynd yn awr, siapio o'r fath. Hynny yw, mae angen cymaint o adnoddau arnom, byddwn yn eu bwyta i fyny nawr. Ar ôl hynny, mae Amazon RDS yn cau'r adnoddau hyn, ac mae perfformiad yn gostwng yno. Mae yna straeon ar wahân am sut mae pobl yn dechrau cemeg gyda'r mater hwn. Weithiau hyd yn oed yn eithaf llwyddiannus. Ond nid oes ganddo ddim i'w wneud â gosodiadau OS. Mae fel hacio cwmwl. Mae'n stori wahanol.

Pam nad yw tudalennau enfawr Tryloyw yn cael unrhyw effaith o gymharu â TLB enfawr?

Peidiwch â rhoi. Gellir esbonio hyn mewn sawl ffordd. Ond mewn gwirionedd nid ydynt yn ei roi. Beth yw hanes PostgreSQL? Wrth gychwyn, mae'n dyrannu talp mawr o gof a rennir. Yn dryloyw eu bod ar yr un pryd neu ddim yn dryloyw - nid oes ots o gwbl. Mae'r ffaith eu bod yn sefyll allan ar y dechrau yn esbonio popeth. Ac os oes llawer o gof a bod angen i chi ailadeiladu'r segment shared_memory, yna bydd tudalennau enfawr Tryloyw yn berthnasol. Yn PostgreSQL, mae'n syml yn cael ei amlygu ar y dechrau gyda darn enfawr a dyna ni, ac yna does dim byd arbennig yn digwydd yno. Gallwch, wrth gwrs, ei ddefnyddio, ond mae siawns i gael curruption shared_memory pan fydd yn ail-ddyrannu rhywbeth. Nid yw PostgreSQL yn gwybod am hyn.

Ffynhonnell: hab.com