Linux stillingar til að bæta PostgreSQL árangur. Ilya Kosmodemyansky

Afrit af 2015 skýrslu Ilya Kosmodemyansky "Linux stillingar til að bæta PostgreSQL árangur"

Fyrirvari: Ég tek fram að þessi skýrsla er dagsett í nóvember 2015 - meira en 4 ár eru liðin og langur tími liðinn. Útgáfa 9.4 sem fjallað er um í skýrslunni er ekki lengur studd. Undanfarin 4 ár hafa 5 nýjar útgáfur af PostgreSQL verið gefnar út og 15 útgáfur af Linux kjarnanum hafa verið gefnar út. Ef þú endurskrifar þessar kaflar, muntu fá aðra skýrslu. En hér skoðum við grundvallar Linux stillingar fyrir PostgreSQL, sem á enn við í dag.

Ég heiti Ilya Kosmodemyansky. Ég vinn hjá PostgreSQL-Consulting. Og nú mun ég tala aðeins um hvað á að gera við Linux í tengslum við gagnagrunna almennt og PostgreSQL sérstaklega, því meginreglurnar eru nokkuð svipaðar.

Hvað munum við tala um? Ef þú átt samskipti við PostgreSQL, þá þarftu að einhverju leyti að vera UNIX stjórnandi. Hvað þýðir það? Ef við berum saman Oracle og PostgreSQL, þá í Oracle þarftu að vera 80% DBA gagnagrunnsstjóri og 20% ​​Linux admin.

Með PostgreSQL er það aðeins flóknara. Með PostgreSQL þarftu að hafa miklu betri skilning á því hvernig Linux virkar. Og á sama tíma, hlaupið aðeins á eftir eimreiðinni, því undanfarið hefur allt verið uppfært nokkuð vel. Og nýir kjarnar eru gefnir út og ný virkni birtist, frammistaða batnar o.s.frv.

Af hverju erum við að tala um Linux? Alls ekki vegna þess að við erum á Linux ráðstefnunni Peter, heldur vegna þess að við nútíma aðstæður er Linux eitt réttlætanlegasta stýrikerfið til að nota gagnagrunna almennt og PostgreSQL sérstaklega. Vegna þess að FreeBSD, því miður, er að þróast í einhverja mjög undarlega átt. Og það verða vandamál bæði með frammistöðu og margt annað. Frammistaða PostgreSQL á Windows er almennt sérstakt alvarlegt mál, byggt á því að Windows er ekki með sama sameiginlega minni og UNIX, á meðan PostgreSQL er allt bundið við þetta, vegna þess að þetta er fjölvinnslukerfi.

Og ég held að allir hafi minni áhuga á framandi hlutum eins og Solaris, svo við skulum fara.

Nútíma Linux dreifing hefur yfir 1 syctl valkosti, allt eftir því hvernig þú byggir upp kjarnann. Á sama tíma, ef við skoðum mismunandi hnetur, getum við stillt eitthvað á margan hátt. Það eru skráarkerfisfæribreytur um hvernig á að tengja þær. Ef þú hefur spurningar um hvernig á að ræsa það: hvað á að virkja í BIOS, hvernig á að stilla vélbúnaðinn osfrv.

Þetta er mjög mikið magn sem hægt er að ræða á nokkrum dögum, og ekki í einni stuttri skýrslu, en nú mun ég einbeita mér að mikilvægum hlutum, hvernig á að forðast þessar hrífur sem eru tryggðar til að koma í veg fyrir að þú notir gagnagrunninn þinn vel á Linux ef þú ekki leiðrétta þær. Og á sama tíma er mikilvægt atriði að margar sjálfgefnar breytur eru ekki innifaldar í stillingunum sem eru réttar fyrir gagnagrunninn. Það er, sjálfgefið mun það virka illa eða alls ekki.

Hvaða hefðbundnu stillimarkmið eru til í Linux? Ég held að þar sem þið eruð öll að fást við Linux stjórnun, þá er engin sérstök þörf á að útskýra hvað markmið eru.

Þú getur stillt:

• ÖRGJÖRVI.
• Minni.
• Geymsla.
• Annað. Við tölum um þetta í lokin fyrir snarl. Jafnvel, til dæmis, breytur eins og orkusparnaðarstefna geta haft áhrif á frammistöðu á mjög ófyrirsjáanlegan og ekki skemmtilegasta hátt.

Hver eru sérstöðu PostgreSQL og gagnagrunnsins almennt? Vandamálið er að þú getur ekki lagað neina einstaka hnetu og séð að árangur okkar hefur batnað verulega.

Já, það eru til slíkar græjur, en gagnagrunnur er flókinn hlutur. Það hefur samskipti við öll þau úrræði sem þjónninn hefur og kýs að hafa samskipti til hins ýtrasta. Ef þú skoðar núverandi ráðleggingar Oracle um hvernig eigi að nota hýsingarstýrikerfi, þá verður það eins og brandarinn um þann mongólska geimfara - fæða hundinn og ekki snerta neitt. Gefum gagnagrunninum öll tilföng, gagnagrunnurinn sjálfur mun redda öllu.

Í grundvallaratriðum er staðan að einhverju leyti nákvæmlega sú sama með PostgreSQL. Munurinn er sá að gagnagrunnurinn er ekki enn fær um að taka öll tilföng fyrir sig, þ.e. einhvers staðar á Linux stigi þarftu að redda þessu öllu sjálfur.

Meginhugmyndin er ekki að velja eitt mark og byrja að stilla það, til dæmis minni, örgjörva eða eitthvað slíkt, heldur að greina vinnuálagið og reyna að bæta afköst eins og hægt er þannig að álagið sem góðir forritarar bjuggu til. fyrir okkur, þar á meðal notendur okkar.

Hér er mynd til að útskýra hvað það er. Það er Linux OS biðminni og það er sameiginlegt minni og það eru PostgreSQL sameiginlegir biðminni. PostgreSQL, ólíkt Oracle, virkar aðeins beint í gegnum kjarnabuffið, þ.e.a.s. til þess að síða af disknum komist inn í samnýtt minni hans verður hún að fara í gegnum kjarnabuðminn og til baka, nákvæmlega sömu aðstæður.

Diskar lifa undir þessu kerfi. Ég teiknaði þetta sem diska. Reyndar gæti verið RAID stjórnandi osfrv.

Og þetta input-output gerist á einn eða annan hátt í gegnum þetta mál.

PostgreSQL er klassískur gagnagrunnur. Það er síða inni. Og allt inntak og úttak á sér stað með því að nota síður. Við erum að hækka kubba í minnið með síðum. Og ef ekkert gerðist, lesum við þær bara, svo hverfa þær smám saman úr þessu skyndiminni, úr sameiginlegu biðmunum og lenda aftur á disknum.

Ef við skiptum um eitthvað einhvers staðar, þá er öll síðan merkt sem óhrein. Ég merkti þær hér með bláum lit. Og þetta þýðir að þessi síða verður að vera samstillt við blokkargeymslu. Það er að segja, þegar við gerðum það óhreint, þá færðum við inn færslu í WAL. Og á yndislegu augnabliki kom upp fyrirbæri sem kallast eftirlitsstöð. Og upplýsingar voru skráðar í þennan log um að hann væri kominn. Og þetta þýðir að allar óhreinu síðurnar sem voru hér á því augnabliki í þessum sameiginlegu biðmunum voru samstilltar við geymsludiskinn með því að nota fsync í gegnum kjarnabuffinn.

Hvers vegna er þetta gert? Ef við misstum spennu, þá fengum við ekki þá stöðu að öll gögn týndust. Viðvarandi minni, sem allir sögðu okkur frá, er enn sem komið er í gagnagrunnsfræði - þetta er björt framtíð, sem við að sjálfsögðu keppum að og líkar vel við, en í bili lifa þau eftir mínus 20 ár. Og auðvitað þarf að fylgjast með þessu öllu.

Og verkefnið við að hámarka afköst er að fínstilla á öllum þessum stigum þannig að allt hreyfist hratt fram og til baka. Sameiginlegt minni er í grundvallaratriðum skyndiminni síðu. Í PostgreSQL sendum við valda fyrirspurn eða eitthvað, það sótti þessi gögn af disknum. Þeir enduðu í sameiginlegum biðmunum. Samkvæmt því, til að þetta virki betur, verður að vera mikið minni.

Til þess að allt þetta virki vel og hratt þarftu að stilla stýrikerfið rétt á öllum stigum. Og veldu jafnvægi vélbúnaðar, því ef þú ert með ójafnvægi á einhverjum stað, þá geturðu búið til mikið minni, en það verður ekki þjónustað á nægum hraða.

Og við skulum fara í gegnum hvern þessara punkta.

Til að láta þessar síður ferðast hraðar fram og til baka þarftu að ná eftirfarandi:

• Í fyrsta lagi þarftu að vinna á skilvirkari hátt með minni.
• Í öðru lagi ætti þessi umskipti þegar síður úr minni fara á diskur að vera skilvirkari.
• Og í þriðja lagi verða að vera til góðir diskar.

Ef þú ert með 512 GB af vinnsluminni á þjóninum og allt endar á SATA harða disknum án skyndiminni, þá breytist allur gagnagrunnsþjónninn í ekki bara grasker heldur grasker með SATA viðmóti. Þú lendir beint í því. Og ekkert mun bjarga þér.

Varðandi fyrsta atriðið með minni, þá er þrennt sem getur gert lífið mjög erfitt.

Fyrsta þeirra er NUMA. NUMA er hlutur sem er gerður til að bæta árangur. Það fer eftir vinnuálagi, mismunandi hluti er hægt að hagræða. Og í nýju núverandi formi er það ekki mjög gott fyrir forrit eins og gagnagrunna sem nota ákaft sameiginlega biðminni síðu skyndiminni.

Í hnotskurn. Hvernig geturðu sagt hvort eitthvað sé að NUMA? Þú ert með einhvers konar óþægilegt bank, allt í einu er einhver CPU ofhlaðinn. Á sama tíma greinir þú fyrirspurnir í PostgreSQL og sérð að það er ekkert svipað þar. Þessar fyrirspurnir ættu ekki að vera svo örgjörvafrekar. Þú getur lent í þessu í langan tíma. Það er auðveldara að nota réttar ráðleggingar frá upphafi um hvernig á að stilla NUMA fyrir PostgreSQL.

Hvað er eiginlega í gangi? NUMA stendur fyrir Non-Uniform Memory Access. Hver er tilgangurinn? Þú ert með CPU, við hliðina á honum er staðbundið minni hans. Og þessar samtengingar minni geta dregið upp minni frá öðrum örgjörvum.

Ef þú hleypur numactl --hardware, þá færðu svo stórt blað. Þar verður meðal annars fjarlægðarvöllur. Það verða tölur - 10-20, eitthvað svoleiðis. Þessar tölur eru ekkert annað en fjöldi hoppa til að taka upp þetta fjarminni og nota það á staðnum. Í grundvallaratriðum, góð hugmynd. Þetta flýtir fyrir frammistöðu vel undir margvíslegu vinnuálagi.

Ímyndaðu þér nú að þú sért með einn örgjörva sem reynir fyrst að nota staðbundið minni og reynir síðan að draga upp annað minni með samtengingu fyrir eitthvað. Og þessi örgjörvi fær allt PostgreSQL síðu skyndiminni - það er það, nokkur gígabæt. Þú færð alltaf versta tilfellið, því á örgjörvanum er yfirleitt lítið minni í þeirri einingu sjálfri. Og allt minnið sem er þjónustað fer í gegnum þessar samtengingar. Það reynist hægt og sorglegt. Og örgjörvinn þinn sem þjónustar þennan hnút er stöðugt ofhlaðinn. Og aðgangstími þessa minnis er slæmur, hægur. Þetta er ástandið sem þú vilt ekki ef þú ert að nota þetta fyrir gagnagrunn.

Því er réttari valkostur fyrir gagnagrunninn að Linux stýrikerfið viti alls ekki hvað er að gerast þar. Svo að það fái aðgang að minni eins og það gerir.

Afhverju er það? Það virðist sem það ætti að vera á hinn veginn. Þetta gerist af einni einfaldri ástæðu: við þurfum mikið minni fyrir skyndiminni síðunnar - tugir, hundruð gígabæta.

Og ef við úthlutuðum þessu öllu og settum gögnin okkar í skyndiminni þar, þá verður ávinningurinn af því að nota skyndiminni verulega meiri en ávinningurinn af svo erfiðum aðgangi að minni. Og við munum þannig hagnast óviðjafnanlega miðað við þá staðreynd að við munum fá aðgang að minni á skilvirkari hátt með því að nota NUMA.

Þess vegna eru tvær nálganir hér í augnablikinu, þar til björt framtíð er komin, og gagnagrunnurinn sjálfur er ekki fær um að átta sig á hvaða örgjörva hann er að keyra á og hvaðan hann þarf að draga eitthvað frá.

Þess vegna er rétta aðferðin að slökkva á NUMA að öllu leyti, til dæmis við endurræsingu. Í flestum tilfellum eru vinningarnir af þeirri stærðargráðu að spurningin um hvor sé betri kemur alls ekki upp.

Það er annar valkostur. Við notum hann oftar en sá fyrsti, því þegar viðskiptavinur kemur til okkar til að fá stuðning er það mikið mál fyrir hann að endurræsa þjóninn. Hann er með viðskipti þar. Og þeir upplifa vandamál vegna NUMA. Þess vegna reynum við að slökkva á því á minna ífarandi hátt en að endurræsa, en gæta þess að athuga hvort það sé óvirkt. Vegna þess að eins og reynslan sýnir er gott að við slökkva á NUMA á PostgreSQL móðurferlinu, en það er alls ekki nauðsynlegt að það virki. Við þurfum að athuga hvort hún hafi virkilega slökkt.

Það er góð færsla eftir Robert Haas. Þetta er einn af PostgreSQL skuldbindingum. Einn af lykilhönnuðum allra lágstigs innmata. Og ef þú fylgir krækjunum úr þessari færslu lýsa þeir nokkrum litríkum sögum um hvernig NUMA gerði fólki lífið erfitt. Sko, skoðaðu gátlistann kerfisstjóra yfir það sem þarf að stilla á þjóninum til að gagnagrunnurinn okkar virki vel. Þessar stillingar þarf að skrifa niður og athuga, því annars verður það ekki mjög gott.

Vinsamlegast athugaðu að þetta á við um allar stillingar sem ég mun tala um. En venjulega er gagnagrunnum safnað í master-slave ham fyrir bilanaþol. Ekki gleyma að gera þessar stillingar á þrælnum því einn daginn verður þú fyrir slysi og þú munt skipta yfir í þrælinn og hann verður meistarinn.

Í neyðartilvikum, þegar allt er mjög slæmt, síminn þinn hringir stöðugt og yfirmaðurinn þinn kemur hlaupandi með stóran spýtu, þú munt ekki hafa tíma til að hugsa um að athuga. Og niðurstöðurnar geta verið mjög hörmulegar.

Næsti punktur er risastórar síður. Risastórar síður er erfitt að prófa sérstaklega, og það þýðir ekkert að gera það, þó að það séu viðmið sem geta gert þetta. Það er auðvelt að Google.

Hver er tilgangurinn? Þú ert með ekki mjög dýran netþjón með miklu vinnsluminni, til dæmis meira en 30 GB. Þú notar ekki risastórar síður. Þetta þýðir að þú hefur örugglega kostnaður hvað varðar minnisnotkun. Og þessi kostnaður er langt frá því að vera skemmtilegastur.

Afhverju er það? Svo hvað er í gangi? Stýrikerfið úthlutar minni í litlum bitum. Það er svo þægilegt, það er hvernig það gerðist sögulega. Og ef við förum í smáatriði, verður stýrikerfið að þýða sýndarvistföng yfir í líkamleg. Og þetta ferli er ekki það einfaldasta, þannig að stýrikerfið vistar niðurstöðu þessarar aðgerðar í þýðingarútlitsbuffernum (TLB).

Og þar sem TLB er skyndiminni, koma öll vandamál sem felast í skyndiminni upp í þessum aðstæðum. Í fyrsta lagi, ef þú ert með mikið af vinnsluminni og því er öllu úthlutað í litlum klumpur, þá verður þessi biðminni mjög stór. Og ef skyndiminni er stór, þá er leit í gegnum það hægari. Overhead er heilbrigt og það tekur sjálft pláss, þ.e. vinnsluminni er neytt af einhverju sem er rangt. Þetta skipti.

Tvö - því meira sem skyndiminni stækkar við slíkar aðstæður, því meiri líkur eru á að þú missir af skyndiminni. Og skilvirkni þessa skyndiminnis minnkar hratt eftir því sem stærð þess eykst. Þess vegna komu stýrikerfin með einfalda nálgun. Það hefur verið notað í Linux í langan tíma. Það birtist í FreeBSD fyrir ekki svo löngu síðan. En við erum að tala um Linux. Þetta eru risastórar síður.

Og hér skal tekið fram að risastórar síður, sem hugmynd, voru upphaflega ýtt af samfélögum sem innihéldu Oracle og IBM, þ.e.a.s. gagnagrunnsframleiðendur töldu eindregið að þetta væri gagnlegt fyrir gagnagrunna líka.

Og hvernig er hægt að eignast þetta vini með PostgreSQL? Í fyrsta lagi verður að virkja risastórar síður í Linux kjarnanum.

Í öðru lagi verða þau að vera sérstaklega tilgreind með sysctl færibreytunni - hversu margir þeir eru. Tölurnar hér eru frá einhverjum gömlum netþjóni. Þú getur reiknað út hversu marga sameiginlega biðminni þú ert með svo að risastórar síður rúmist þar.

Og ef allur þjónninn þinn er tileinkaður PostgreSQL, þá er góður upphafspunktur að úthluta annað hvort 25% af vinnsluminni til sameiginlegra biðminni, eða 75% ef þú ert viss um að gagnagrunnurinn þinn passi örugglega í þessum 75%. Upphafspunktur eitt. Og íhugaðu, ef þú ert með 256 GB af vinnsluminni, þá muntu í samræmi við það hafa 64 GB af stórum biðminni. Reiknaðu um það bil með nokkurri spássíu - hvað ætti að stilla þessi tala á.

Fyrir útgáfu 9.2 (ef mér skjátlast ekki, síðan útgáfa 8.2), var hægt að tengja PostgreSQL við risastórar síður með því að nota þriðja aðila bókasafn. Og þetta á alltaf að gera. Í fyrsta lagi þarftu kjarnann til að geta úthlutað risastórum síðum rétt. Og í öðru lagi svo að forritið sem vinnur með þeim geti notað þau. Það verður ekki bara notað þannig. Þar sem PostgreSQL úthlutaði minni í kerfi 5 stíl, gæti þetta verið gert með libhugetlbfs - þetta er fullt nafn bókasafnsins.

Í 9.3 var PostgreSQL árangur bætt þegar unnið var með minni og kerfi 5 minnisúthlutunaraðferðin var hætt. Allir voru mjög ánægðir, því annars reynirðu að keyra tvö PostgreSQL tilvik á einni vél og hann segir að ég hafi ekki nóg sameiginlegt minni. Og hann segir að sysctl þurfi að leiðrétta. Og það er svo sysctl að þú þarft enn að endurræsa osfrv. Almennt séð voru allir ánægðir. En mmap minnisúthlutun braut notkun risastórra síðna. Flestir viðskiptavinir okkar nota stóra sameiginlega biðminni. Og við mældum eindregið með því að skipta ekki yfir í 9.3, því yfirkostnaður þar fór að vera reiknaður í góðum prósentum.

En samfélagið veitti þessu vandamáli athygli og í 9.4 endurgerðu þeir þennan atburð mjög vel. Og í 9.4 birtist færibreyta í postgresql.conf þar sem þú getur virkjað tilraun, kveikt eða slökkt.

Reyna er öruggasti kosturinn. Þegar PostgreSQL byrjar, þegar það úthlutar sameiginlegu minni, reynir það að grípa þetta minni af risastóru síðunum. Og ef það virkar ekki, þá fer það aftur í venjulega valið. Og ef þú ert með FreeBSD eða Solaris, þá geturðu prófað, það er alltaf öruggt.

Ef kveikt er á, þá byrjar það einfaldlega ekki ef það gæti ekki valið af risastóru síðunum. Hér snýst það nú þegar um hver og hvað er flottara. En ef þú hefur reynt skaltu athuga hvort þú hafir raunverulega það sem þú þarft undirstrikað, því það er mikið pláss fyrir mistök. Eins og er virkar þessi virkni aðeins á Linux.

Enn ein lítil athugasemd áður en lengra er haldið. Gagnsæar risastórar síður eru ekki enn um PostgreSQL. Hann getur ekki notað þau venjulega. Og með gagnsæjum risastórum síðum fyrir slíkt vinnuálag, þegar þörf er á stóru stykki af sameiginlegu minni, kemur ávinningurinn aðeins með mjög miklu magni. Ef þú ert með terabæta af minni þá gæti þetta komið við sögu. Ef við erum að tala um fleiri hversdagsleg forrit, þegar þú ert með 32, 64, 128, 256 GB af minni á vélinni þinni, þá eru venjulega risastóru síðurnar í lagi og við slökkva einfaldlega á Transparent.

Og það síðasta um minnið er ekki beint tengt ávöxtum, það getur raunverulega eyðilagt líf þitt. Öll afköst verða fyrir miklum áhrifum af því að þjónninn er stöðugt að skipta.

Og þetta verður mjög óþægilegt á ýmsan hátt. Og aðalvandamálið er að nútímakjarnar hegða sér aðeins öðruvísi en eldri Linux kjarna. Og þetta er frekar óþægilegt að stíga á, því þegar við tölum um einhvers konar vinnu með skiptum, þá endar það með ótímabærri komu OOM-morðingja. Og OOM-dráparinn, sem kom ekki á réttum tíma og sleppti PostgreSQL, er óþægilegur. Allir munu vita af þessu, það er, þar til síðasti notandi.

Hvað er að gerast? Þú ert með mikið vinnsluminni þarna, allt virkar vel. En af einhverjum ástæðum hangir þjónninn í swap og hægir á sér útaf þessu. Það virðist sem það sé mikið minni, en þetta gerist.

Áður ráðlögðum við að stilla vm.swappiness á núll, þ.e. slökkva á skiptum. Áður virtist sem 32 GB af vinnsluminni og samsvarandi sameiginlegum biðminni væri mikið magn. Megintilgangur skiptanna er að hafa stað til að kasta skorpunni ef við dettum af. Og það var ekki lengur sérstaklega uppfyllt. Og hvað ætlarðu þá að gera við þessa skorpu? Þetta er verkefni þar sem ekki er mjög ljóst hvers vegna skipta þarf, sérstaklega af slíkri stærð.

En í nútímalegri, þ.e. þriðju útgáfum af kjarnanum, hefur hegðunin breyst. Og ef þú stillir swap á núll, þ.e. slökkva á því, þá mun fyrr eða síðar, jafnvel þó að eitthvað vinnsluminni sé eftir, koma OOM-drápari til þín til að drepa ákaflegasta neytendurna. Vegna þess að hann mun líta svo á að með svona vinnuálagi eigum við enn svolítið eftir og við munum hoppa út, þ.e.a.s. ekki til að negla niður kerfisferlið, heldur til að negla niður eitthvað sem er minna mikilvægt. Þessi minna mikilvægi mun vera hinn ákafi neytandi sameiginlegs minnis, nefnilega póstmeistarinn. Og eftir það verður gott ef ekki þarf að endurheimta grunninn.

Þess vegna er nú sjálfgefið, eftir því sem ég man eftir, eru flestar dreifingar einhvers staðar í kringum 6, þ.e.a.s. á hvaða tímapunkti ættir þú að byrja að nota swap eftir því hversu mikið minni er eftir. Við mælum nú með að stilla vm.swappiness = 1, því þetta slekkur nánast á því, en gefur ekki sömu áhrif og með OOM-drápari sem kom óvænt og drap allt.

Hvað er næst? Þegar við tölum um frammistöðu gagnagrunna og færumst smám saman í átt að diskum, byrja allir að grípa í hausinn á sér. Vegna þess að sannleikurinn um að diskurinn sé hægur og minnið hratt þekkja allir frá barnæsku. Og allir vita að gagnagrunnurinn mun eiga í vandræðum með frammistöðu diska.

Helsta PostgreSQL frammistöðuvandamálið sem tengist eftirlitsstöðvum kemur ekki fram vegna þess að diskurinn er hægur. Þetta er líklegast vegna þess að minni og bandbreidd disks eru ekki í jafnvægi. Hins vegar er ekki víst að þau séu í jafnvægi á mismunandi stöðum. PostgreSQL er ekki stillt, stýrikerfið er ekki stillt, vélbúnaðurinn er ekki stilltur og vélbúnaðurinn er rangur. Og þetta vandamál gerist ekki aðeins ef allt gerist eins og það á að gera, þ.e. annað hvort er ekkert álag eða stillingar og vélbúnaður er vel valinn.

Hvað er það og hvernig lítur það út? Venjulega hefur fólk sem vinnur með PostgreSQL komið inn í þetta mál oftar en einu sinni. Ég skal útskýra. Eins og ég sagði, PostgreSQL gerir reglulega eftirlitsstöðvar til að henda óhreinum síðum í samnýtt minni á diskinn. Ef við erum með mikið magn af sameiginlegu minni, þá byrjar eftirlitspunktur að hafa mikil áhrif á diskinn, vegna þess að það varpar þessum síðum með fsync. Það kemur í kjarnabuffið og er skrifað á diska með fsync. Og ef umfang þessa viðskipta er mikið, þá getum við fylgst með óþægilegum áhrifum, nefnilega mjög mikilli nýtingu á diskum.

Hérna er ég með tvær myndir. Ég mun nú útskýra hvað það er. Þetta eru tvö tímatengd línurit. Fyrsta grafið er nýting diska. Hér nær það næstum 90% á þessum tímapunkti. Ef þú ert með bilun í gagnagrunni með líkamlegum diskum, með RAID stjórnandi nýtingu á 90%, þá eru þetta slæmar fréttir. Þetta þýðir að aðeins meira og það mun ná 100 og I/O mun hætta.

Ef þú ert með diskafylki, þá er það aðeins önnur saga. Það fer eftir því hvernig það er stillt, hvers konar fylki það er o.s.frv.

Og samhliða er graf frá innri postgres sýn stillt hér, sem segir til um hvernig eftirlitspunkturinn á sér stað. Og græni liturinn hér sýnir hversu margir biðminni, þessar óhreinu síður, komu á þessu augnabliki til samstillingar. Og þetta er það helsta sem þú þarft að vita hér. Við sjáum að við erum með fullt af síðum hérna og á einhverjum tímapunkti skelltum við okkur á töfluna, það er að segja við skrifuðum og skrifuðum, hér er diskakerfið greinilega mjög upptekið. Og eftirlitsstöðin okkar hefur mjög sterk áhrif á diskinn. Helst ætti staðan að líta meira svona út, þ.e.a.s. við vorum með minni upptökur hér. Og við getum lagað það með stillingunum þannig að þetta haldi áfram að vera svona. Það er að segja að endurvinnslan er lítil en einhvers staðar erum við að skrifa eitthvað hér.

Hvað þarf að gera til að vinna bug á þessu vandamáli? Ef þú hefur stöðvað IO undir gagnagrunninum þýðir það að allir notendur sem komu til að uppfylla beiðnir þeirra munu bíða.

Ef þú lítur frá sjónarhóli Linux, ef þú tókst góðan vélbúnað, stillir hann rétt, stillir PostgreSQL venjulega þannig að það gerir þessar eftirlitsstöðvar sjaldnar, dreifir þeim með tímanum á milli sín, þá stígur þú inn í sjálfgefna Debian breytur. Fyrir flestar Linux dreifingar er þetta myndin: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Hvað þýðir það? Einn skolpúki birtist úr kjarna 2.6. Pdglush, eftir því hver er að nota hvaða, sem tekur þátt í að fleygja óhreinum síðum í bakgrunni úr kjarna biðminni og fleygja þegar nauðsynlegt er að henda óhreinum síðum, sama hvað, þegar það hjálpar ekki.

Hvenær kemur bakgrunnur? Þegar 10% af heildarvinnsluminni sem er tiltækt á þjóninum er upptekið af óhreinum síðum í kjarnabuffi, er sérstök afskriftaraðgerð kallað í bakgrunni. Af hverju er það bakgrunnur? Sem breytu tekur það tillit til þess hversu margar síður á að afskrifa. Og við skulum segja að hann afskrifi N síður. Og um stund sofnar þessi hlutur. Og svo kemur hún aftur og afritar nokkrar síður í viðbót.

Þetta er ákaflega einföld saga. Vandamálið hér er eins og með sundlaug, þegar hún hellist í eina pípu, rennur hún í aðra. Eftirlitsstöðin okkar kom og ef hann sendi nokkrar óhreinar síður til að farga, þá mun allt málið smám saman leysast snyrtilega úr kjarnabuffi pgflush.

Ef þessar óhreinu síður halda áfram að safnast upp safnast þær allt að 20%, eftir það er forgangsverkefni stýrikerfisins að afskrifa allt á diskinn, því rafmagnið mun bresta og allt fer illa með okkur. Við munum til dæmis missa þessi gögn.

Hvað er bragðið? The bragð er að þessar breytur í nútíma heimi eru 20 og 10% af heildar vinnsluminni sem er á vélinni, þær eru alveg svakalegar hvað varðar afköst hvers diskakerfis sem þú ert með.

Ímyndaðu þér að þú sért með 128 GB af vinnsluminni. 12,8 GB berast í diskakerfið þitt. Og sama hvaða skyndiminni þú ert með þar, sama hvaða fylki þú ert með þar, þau endast ekki svo lengi.

Þess vegna mælum við með því að þú stillir þessar tölur strax út frá getu RAID-stýringarinnar. Ég gerði strax meðmæli hér um stjórnandi sem hefur 512 MB skyndiminni.

Allt er talið mjög einfalt. Þú getur sett vm.dirty_background í bæti. Og þessar stillingar hætta við fyrri tvær. Annað hvort hlutfall er sjálfgefið, eða þeir sem eru með bæti eru virkjaðir, þá virka þeir sem eru með bæti. En þar sem ég er DBA ráðgjafi og vinn með mismunandi viðskiptavinum reyni ég að draga strá og þess vegna, ef í bætum, þá í bætum. Enginn gaf neina tryggingu fyrir því að góður stjórnandi myndi ekki bæta meira minni við þjóninn, endurræsa hann og myndin yrði sú sama. Reiknaðu bara þessar tölur þannig að allt passi þarna inn með tryggingu.

Hvað gerist ef þú passar ekki inn? Ég hef skrifað að hvers kyns roði sé í raun stöðvaður, en í raun er þetta orðbragð. Stýrikerfið á við stórt vandamál að etja - það hefur mikið af óhreinum síðum, þannig að IO sem viðskiptavinir þínir búa til er í raun stöðvuð, þ.e.a.s. forritið er komið til að senda sql fyrirspurn í gagnagrunninn, það bíður. Sérhver inntak/útgangur á það er með lægsta forgang, vegna þess að gagnagrunnurinn er upptekinn af eftirlitsstöð. Og hvenær hún klárar það er algjörlega óljóst. Og þegar þú hefur náð roði án bakgrunns þýðir það að allt IO þitt er upptekið af því. Og þangað til því lýkur muntu ekki gera neitt.

Hér eru tvö mikilvæg atriði í viðbót sem falla utan gildissviðs þessarar skýrslu. Þessar stillingar ættu að passa við stillingarnar í postgresql.conf, þ.e. stillingar eftirlitsstaða. Og diskakerfið þitt verður að vera fullnægjandi stillt. Ef þú ert með skyndiminni á RAID, þá verður það að vera með rafhlöðu. Fólk kaupir RAID með góðu skyndiminni án rafhlöðu. Ef þú ert með SSD diska í RAID, þá verða þeir að vera server, það verða að vera þéttar þar. Hér er ítarlegur gátlisti. Þessi hlekkur inniheldur skýrslu mína um hvernig á að stilla árangursdisk í PostgreSQL. Það eru allir þessir gátlistar þarna.

Hvað annað getur gert lífið mjög erfitt? Þetta eru tvær breytur. Þeir eru tiltölulega nýir. Sjálfgefið er að þau geta verið með í mismunandi forritum. Og þeir geta gert lífið jafn erfitt ef þeir eru rangt kveiktir.

Það eru tveir tiltölulega nýir hlutir. Þeir hafa þegar birst í þriðja kjarna. Þetta er sched_migration_cost í nanoseconds og sched_autogroup_enabled, sem er sjálfgefið einn.

Og hvernig eyðileggja þeir líf þitt? Hvað er sched_migration_cost? Á Linux getur tímaáætlunarmaðurinn flutt ferli frá einum örgjörva til annars. Og fyrir PostgreSQL, sem keyrir fyrirspurnir, er flutningur yfir í annan örgjörva algjörlega óljós. Frá stýrikerfissjónarmiði, þegar þú skiptir um glugga á milli openoffice og terminal, getur þetta verið gott, en fyrir gagnagrunn er þetta mjög slæmt. Þess vegna er sanngjörn stefna að stilla migration_cost á eitthvað mikið gildi, að minnsta kosti nokkur þúsund nanósekúndur.

Hvað mun þetta þýða fyrir tímaáætlun? Það verður talið að á þessum tíma sé ferlið enn heitt. Það er, ef þú ert með langvarandi viðskipti sem hefur verið að gera eitthvað í langan tíma, mun tímaáætlunarmaðurinn skilja þetta. Hann mun gera ráð fyrir að þar til þessi frestur er liðinn, sé engin þörf á að flytja þetta ferli neitt. Ef ferlið gerir eitthvað á sama tíma, þá verður það ekki flutt neitt, það mun hljóðlega vinna á örgjörvanum sem var úthlutað til þess. Og útkoman er frábær.

Annað atriðið er sjálfshópur. Það er góð hugmynd fyrir tiltekið vinnuálag sem er ekki tengt nútíma gagnagrunnum - þetta er að flokka ferla eftir sýndarstöðinni sem þeir eru ræstir úr. Þetta er þægilegt fyrir sum verkefni. Í reynd er PostgreSQL fjölvinnslukerfi með forgaffli sem keyrir frá einni flugstöð. Þú ert með læsingarritara, eftirlitsstöð og allar beiðnir viðskiptavina verða flokkaðar í einn tímaáætlun, á hvern örgjörva. Og þeir munu bíða þar í sameiningu eftir því að hann verði frjáls, til þess að trufla hver annan og halda honum uppteknum lengur. Þetta er saga sem er algjörlega óþörf þegar um slíkt álag er að ræða og því þarf að slökkva á henni.

Samstarfsmaður minn Alexey Lesovsky gerði próf með einföldum pgbench, þar sem hann jók migration_cost um stærðargráðu og slökkti á sjálfvirkum hópi. Munurinn á slæmum vélbúnaði var næstum 10%. Það er umræða á postgres póstlistanum þar sem fólk gefur niðurstöður af svipuðum breytingum á fyrirspurnarhraða hafði 50% áhrif. Það eru til talsvert margar slíkar sögur.

Og að lokum um orkusparnaðarstefnu. Það góða er að nú er hægt að nota Linux á fartölvu. Og það mun að sögn nota upp rafhlöðuna vel. En allt í einu kemur í ljós að þetta getur líka gerst á servernum.

Þar að auki, ef þú leigir netþjóna frá einhverjum hýsingaraðila, þá er „góðu“ hýsingaraðilum ekki sama um að þú hafir betri afköst. Verkefni þeirra er að tryggja að járn þeirra nýtist eins vel og hægt er. Þess vegna geta þeir sjálfgefið virkjað orkusparnaðarham fartölvu á stýrikerfinu.

Ef þú notar þetta efni á netþjóni með gagnagrunn undir miklu álagi, þá er val þitt acpi_cpufreq + permormance. Jafnvel með eftirspurn verða vandamál.

Intel_pstate er aðeins annar bílstjóri. Og nú er valinn þessi, eins og hann er síðar og virkar betur.

Og í samræmi við það, seðlabankastjóri er aðeins frammistaða. Eftirspurn, orkusparnaður og allt annað snýst ekki um þig.

Niðurstöður skýringargreiningar PostgreSQL geta verið mismunandi ef þú virkjar orkusparnað, vegna þess að örgjörvinn undir gagnagrunninum þínum mun keyra á algjörlega ófyrirsjáanlegan hátt.

Þessir hlutir gætu verið innifalin sjálfgefið. Horfðu vandlega til að sjá hvort þeir kveiktu á því sjálfgefið. Þetta getur verið mjög mikið vandamál.

Og í lokin vildi ég þakka strákunum frá PosgreSQL-ráðgjöf DBA teyminu okkar, nefnilega Max Boguk og Alexey Lesovsky, sem eru að ná árangri í þessu máli á hverjum degi. Og við reynum að gera það besta sem við getum fyrir viðskiptavini okkar þannig að allt gangi upp fyrir þá. Þetta er eins og með flugöryggisleiðbeiningar. Hér er allt skrifað í blóði. Hver af þessum hnetum er að finna í ferli einhvers konar vandamála. Ég er ánægður með að deila þeim með þér.

Spurningar:

Þakka þér fyrir! Ef til dæmis fyrirtæki vill spara peninga og setja gagnagrunninn og forritsrökfræðina á einn netþjón, eða ef fyrirtækið fylgir tískuþróun örþjónustuarkitektúra, þar sem PostgreSQL keyrir í gámi. Hvað er bragðið? Sysctl mun hafa áhrif á allan kjarnann á heimsvísu. Ég hef ekki heyrt um að sysctls séu einhvern veginn sýndargerðar þannig að þeir virki sérstaklega á íláti. Það er aðeins cgroup og það er aðeins hluti af eftirlitinu þar. Hvernig geturðu lifað með þessu? Eða ef þú vilt afköst, keyrðu þá PostgreSQL á sérstökum vélbúnaðarþjóni og stilltu hann?

Við svöruðum spurningu þinni á um það bil þrjá vegu. Ef við erum ekki að tala um vélbúnaðarþjón sem hægt er að stilla o.s.frv., slakaðu á, allt mun virka vel án þessara stillinga. Ef þú ert með svo mikið álag að þú þarft að gera þessar stillingar, þá kemurðu fyrr á járnþjóninn en í þessar stillingar.

Hvað er vandamálið? Ef þetta er sýndarvél, þá er líklegt að þú eigir við mörg vandamál að stríða, til dæmis vegna þess að á flestum sýndarvélum er leynd disksins frekar ósamræmi. Jafnvel þó að afköst disksins séu góð, þá er ein misheppnuð I/O færsla sem hefur ekki mikil áhrif á meðalafköst sem átti sér stað við eftirlitsstöðina eða þegar skrifað var til WAL, þá mun gagnagrunnurinn líða mjög fyrir þetta. Og þú munt taka eftir þessu áður en þú lendir í þessum vandamálum.

Ef þú ert með NGINX á sama netþjóni muntu líka eiga við sama vandamál að stríða. Hann mun berjast fyrir sameiginlegri minningu. Og þú munt ekki komast að vandamálunum sem lýst er hér.

En á hinn bóginn munu sumar af þessum breytum enn eiga við þig. Til dæmis, stilltu dirty_ratio með sysctl þannig að það sé ekki svo klikkað - í öllum tilvikum mun þetta hjálpa. Með einum eða öðrum hætti muntu hafa samskipti við diskinn. Og það mun vera samkvæmt röngu mynstri. Þetta er almennt sjálfgefið fyrir færibreyturnar sem ég sýndi. Og í öllum tilvikum er betra að breyta þeim.

En það gætu verið vandamál með NUMA. VmWare, til dæmis, virkar vel með NUMA með nákvæmlega öfugum stillingum. Og hér verður þú að velja - járnþjónn eða járnlausan.

Ég er með spurningu sem tengist Amazon AWS. Þeir hafa myndir fyrirfram stilltar. Einn þeirra heitir Amazon RDS. Eru einhverjar sérsniðnar stillingar fyrir stýrikerfið þeirra?

Það eru stillingar þarna, en það eru mismunandi stillingar. Hér stillum við stýrikerfið með tilliti til þess hvernig gagnagrunnurinn mun nota þetta. Og það eru breytur sem ákvarða hvert við ættum að fara núna, svo sem mótun. Það er, við þurfum svo mikið af auðlindum, við munum nú éta þær upp. Eftir þetta herðir Amazon RDS þessar auðlindir og árangur lækkar þar. Það eru einstakar sögur af því hvernig fólk er farið að skipta sér af þessu máli. Stundum jafnvel með góðum árangri. En þetta hefur ekkert með OS stillingar að gera. Það er eins og að hakka skýið. Það er önnur saga.

Af hverju hafa gagnsæjar risastórar síður engin áhrif miðað við Risastóra TLB?

Ekki gefa. Þetta má útskýra á margan hátt. En í raun gefa þeir það einfaldlega ekki. Hver er saga PostgreSQL? Við ræsingu úthlutar það stóru stykki af sameiginlegu minni. Hvort þær eru gagnsæjar eða ekki skiptir algjörlega engu máli. Sú staðreynd að þeir skera sig úr í byrjun skýrir allt. Og ef það er mikið af minni og þú þarft að endurbyggja shared_memory hlutann, þá munu gagnsæjar risastórar síður skipta máli. Í PostgreSQL er því einfaldlega úthlutað í stórum klumpur í byrjun og það er allt og svo gerist ekkert sérstakt þar. Þú getur auðvitað notað það, en það er möguleiki á að skemma shared_memory þegar það endurúthlutar einhverju. PostgreSQL veit ekki um þetta.

Heimild: www.habr.com