Linux-instelling om PostgreSQL-werkverrigting te verbeter. Ilya Kosmodemyansky

Transkripsie van die 2015-verslag deur Ilya Kosmodemyansky "Linux-instelling om PostgreSQL-prestasie te verbeter"

Vrywaring: Ek neem kennis dat hierdie verslag gedateer is November 2015 - meer as 4 jaar het verloop en baie tyd het verloop. Weergawe 9.4 wat in die verslag bespreek word, word nie meer ondersteun nie. Oor die afgelope 4 jaar was daar 5 nuwe vrystellings van PostgreSQL en 15 weergawes van die Linux-kern. As jy hierdie plekke herskryf, sal jy met 'n ander verslag eindig. Maar hier is 'n fundamentele Linux-instelling vir PostgreSQL, wat vandag nog relevant is.

My naam is Ilya Kosmodemyansky. Ek werk vir PostgreSQL-konsultasiemaatskappy. En nou sal ek 'n bietjie praat oor wat om te doen met Linux met betrekking tot databasisse in die algemeen en PostgreSQL in die besonder, want die beginsels is baie soortgelyk.

Wat sal bespreek word? As jy met PostgreSQL te doen het, moet jy tot 'n mate 'n UNIX-administrateur wees. Wat beteken dit? As ons Oracle en PostgreSQL vergelyk, dan moet u in Oracle 80% DBA-databasisadministrateur en 20% Linux-admin wees.

PostgreSQL is 'n bietjie moeiliker. Met PostgreSQL moet u 'n baie beter idee hê van hoe Linux werk. En hardloop terselfdertyd bietjie agter die lokomotief aan, want die afgelope tyd is alles nogal cool opgedateer. En nuwe kerne kom uit, en nuwe funksionaliteit verskyn, werkverrigting verbeter, ens.

Hoekom praat ons van Linux? Glad nie omdat ons by die Linux-konferensie Peter is nie, maar omdat in moderne toestande Linux een van die mees geregverdigde bedryfstelsels is om met databasisse in die algemeen en met PostgreSQL in die besonder te werk. Omdat FreeBSD, ongelukkig, in een of ander baie vreemde rigting ontwikkel. En daar sal probleme wees met beide prestasie en baie ander dinge. Die werkverrigting van PostgreSQL op Windows is oor die algemeen 'n aparte harde onderwerp, wat berus op die feit dat Windows nie so 'n gedeelde geheue soos UNIX het nie, en PostgreSQL gaan alles oor hierdie besigheid, want dit is 'n multi-proses stelsel.

En eksotiese produkte soos Solaris, dink ek, is van minder belang vir almal, so kom ons gaan.

'n Moderne Linux-verspreiding het meer as 1 000 syctl-opsies, afhangend van hoe die kern gebou is. Terselfdertyd, as ons na verskillende neute kyk, dan kan daar nog baie maniere wees om iets aan te pas. Daar is lêerstelselopsies oor hoe om te monteer. As jy vrae het oor hoe om te begin: wat om in die BIOS te aktiveer, hoe om die hardeware op te stel, ens.

Dit is 'n baie groot volume, waaroor vir 'n paar dae gepraat kan word, en nie in een kort verslag nie, maar ek sal nou fokus op belangrike dinge, hoe om daardie harke te vermy wat jou nie sal toelaat om 'n databasis op Linux goed te bedryf as jy maak hulle nie reg nie.. En terselfdertyd is 'n belangrike punt dat baie verstekparameters nie ingesluit is in die instellings wat korrek is vir die databasis nie. Dit wil sê, dit sal by verstek sleg werk of glad nie werk nie.

Wat is die tradisionele instelteikens op Linux? Ek dink dat aangesien julle almal met Linux-administrasie te doen het, dit nie nodig is om te verduidelik wat teikens is nie.

Jy kan instel:

• SVE.
• Geheue.
• Stoor.
• ander. Ons sal aan die einde hieroor praat vir 'n versnapering. Selfs byvoorbeeld instellings soos kragbesparingsbeleid kan prestasie op 'n baie onvoorspelbare en nie baie aangename manier beïnvloed nie.

Wat is die besonderhede van PostgreSQL en die databasis in die algemeen? Die probleem is dat jy nie een of ander spesifieke neut kan aanpas en sien dat ons prestasie baie verbeter het nie.

Ja, daar is sulke gadgets, maar die databasis is 'n ingewikkelde ding. Sy het interaksie met al die hulpbronne wat die bediener het en verkies om ten volle te kommunikeer. As jy na Oracle se huidige riglyne kyk oor hoe om 'n gasheer-bedryfstelsel te gebruik, is dit soos daardie Mongoolse ruimtevaarder se grap - voer die hond en moenie aan iets raak nie. Kom ons gee die databasis al die hulpbronne, die databasis self sal alles vernietig.

In beginsel, tot 'n mate, is die situasie presies dieselfde met PostgreSQL. Die verskil lê in die feit dat die basis ook nie in staat is om al die hulpbronne vir homself te neem nie, dit wil sê, iewers op die Linux-vlak moet jy dit alles op jou eie uitsorteer.

Die hoofgedagte is nie om 'n enkele teiken te kies en dit te begin instel nie, byvoorbeeld geheue, SVE of iets dergeliks, maar om die werklading te ontleed en die deurset soveel as moontlik te probeer verbeter sodat die las wat goeie programmeerders geskep het vir ons, insluitend ons gebruikers.

Hier is 'n prentjie om te verduidelik wat dit is. Daar is 'n Linux OS-buffer en daar is gedeelde geheue en daar is PostgreSQL-gedeelde buffers. PostgreSQL, anders as Oracle, werk direk net deur die kernbuffer, dit wil sê, om 'n bladsy vanaf skyf in sy gedeelde geheue te kry, moet dit deur die kernbuffer gaan en presies dieselfde situasie terug.

Skywe leef onder hierdie stelsel. Ek het dit as skywe geteken. Trouens, daar kan 'n RAID-beheerder wees, ens.

En hierdie inset-uitset gebeur op een of ander manier deur hierdie besigheid.

PostgreSQL is 'n klassieke databasis. Dit is binne die bladsy. En alle invoer-uitvoer vind plaas met behulp van bladsye. Ons verhoog blokkies in geheue deur bladsye. En as niks gebeur het nie, lees ons dit net, dan sink hulle geleidelik uit hierdie kas, uit gedeelde buffers en kom terug na die skyf.

As ons iets iewers vervang het, dan word ons hele bladsy as vuil gemerk. Ek het hulle hier in blou gemerk. En dit beteken dat hierdie bladsy met blokberging gesinchroniseer moet word. Dit wil sê, toe ons dit vuil gemaak het, het ons 'n inskrywing in WAL gemaak. En op 'n goeie tydstip het 'n verskynsel genaamd kontrolepunt gekom. En hierdie log het inligting aangeteken dat hy gekom het. En dit beteken dat al die vuil bladsye wat op daardie oomblik hier in hierdie gedeelde buffers was, gesinchroniseer is met die stoorskyf met behulp van fsync deur die kernbuffer.

Waarvoor is dit? As ons spanning verloor het, dan het ons nie die situasie gekry dat alle data verlore was nie. Aanhoudende geheue, waarvan almal ons vertel het, is sover in die databasisteorie - dit is 'n blink toekoms waarna ons natuurlik streef en ons hou daarvan, maar tot dusver leef hulle nog in minus 20 jaar. En dit alles moet natuurlik gemonitor word.

En die taak om deurset te maksimeer, is om op al hierdie stadiums in te stem sodat dit alles vinnig heen en weer gaan. Gedeelde geheue is basies 'n bladsykas. In PostgreSQL het ons 'n uitgesoekte iets daar versoek gestuur, dit het hierdie data van die skyf gekry. Hulle het in gedeelde buffers beland. Gevolglik, vir dit om beter te werk, moet daar baie geheue wees.

Om dit alles goed en vinnig te laat werk, moet u die bedryfstelsel in alle stadiums korrek opstel. En kies gebalanseerde yster, want as jy op 'n plek 'n wanbalans het, dan kan jy baie geheue maak, maar dit sal teen onvoldoende spoed bedien word.

Kom ons gaan deur elkeen van hierdie punte.

Om hierdie bladsye vinniger heen en weer te laat reis, moet jy die volgende bereik:

• Eerstens moet jy meer doeltreffend met geheue werk.
• Tweedens behoort hierdie oorgang meer doeltreffend te wees wanneer bladsye uit die geheue na skyf toe gaan.
• En, derdens, moet daar goeie skywe wees.

As jy 512 GB RAM in die bediener het en dit alles beland op 'n SATA-hardeskyf sonder enige kas, dan verander die hele databasisbediener nie net in 'n pampoen nie, maar in 'n pampoen met 'n SATA-koppelvlak. Jy sal dit direk raakloop. En niks sal jou red nie.

Wat die eerste punt met geheue betref, is daar drie dinge wat die lewe baie moeilik kan maak.

Die eerste een is NUMA. NUMA is 'n ding wat gemaak is om prestasie te verbeter. Afhangende van die werklading, kan jy verskillende dinge optimaliseer. En in sy nuwe huidige vorm is dit nie baie goed vir toepassings soos 'n databasis wat intensief gedeelde buffers vir bladsykas gebruik nie.

In 'n neutedop. Hoe om te verstaan ​​dat iets fout is met NUMA? Jy het een of ander onaangename klop, skielik is een of ander SVE oorlaai. Terselfdertyd ontleed jy navrae in PostgreSQL en sien dat daar niks soortgelyks daar is nie. Hierdie versoeke behoort nie so SVE-intensief te wees nie. Jy kan dit vir 'n lang tyd vang. Dit is makliker om van die begin af die regte raad te gebruik oor hoe om NUMA vir PostgreSQL op te stel.

Wat is regtig aan die gang? NUMA staan ​​vir Non-Uniform Memory Access. Wat is die punt? Jy het 'n SVE, langsaan is daar sy plaaslike geheue. En hierdie geheueverbindings kan geheue van ander SVE's trek.

As jy hardloop numactl --hardware, dan kry jy so 'n groot laken. Daar sal onder meer 'n afstandsveld wees. Daar sal nommers wees - 10-20, so iets. Hierdie getalle is niks anders as die aantal hops om hierdie afgeleë geheue op te tel en dit plaaslik te gebruik nie. Basies 'n goeie idee. Dit verbeter prestasie goed in 'n aantal werkladings.

Stel jou nou voor dat jy een SVE het wat eers probeer om sy plaaslike geheue te gebruik, en dan probeer om 'n ander geheue op te haal via interkonneksie vir iets. En jou hele PostgreSQL-bladsykas kom na hierdie SVE - dis dit, hoeveel gigagrepe is daar. Jy kry altyd die ergste geval, want daar is gewoonlik min geheue op die SVE direk in daardie module. En al die geheue wat bedien word, gaan deur hierdie verbindings. Dit blyk stadig en hartseer. En jy het 'n verwerker wat hierdie nodus bedien, is voortdurend oorlaai. En die toegangstyd van hierdie geheue is sleg, stadig. Dit is die soort situasie wat jy nie wil hê as jy hierdie saak vir 'n databasis gebruik nie.

Daarom is 'n meer korrekte opsie vir die databasis dat die Linux-bedryfstelsel glad nie weet wat daar gebeur nie. Sodat sy die herinnering aanspreek soos sy aanspreek.

Hoekom is dit? Dit wil voorkom asof dit andersom moet wees. Dit gebeur om een ​​eenvoudige rede, dat ons baie geheue nodig het vir bladsykas - tiene, honderde gigagrepe.

En as ons dit alles toeken en ons data daar gekas het, dan sal die wins uit die gebruik van die kas aansienlik groter wees as die wins van so 'n slinkse geheuetoegang. En op hierdie manier sal ons onvergelykbaar wen in vergelyking met die feit dat ons meer doeltreffend toegang tot geheue sal verkry deur NUMA te gebruik.

Daarom is daar op die oomblik twee benaderings, totdat 'n blink toekoms aangebreek het, en die databasis self kan nie uitvind op watter SVE's dit werk en waar dit iets vandaan moet trek nie.

Daarom is die korrekte benadering om NUMA heeltemal uit te skakelbv by herlaai. In die meeste gevalle is die winste in sulke volgordes dat daar glad nie sprake is nie, wat beter is.

Daar is 'n ander opsie. Ons gebruik dit meer gereeld as die eerste een, want wanneer 'n kliënt na ons toe kom vir ondersteuning, is dit 'n hele ding vir hom om die bediener te herbegin. Hy het 'n besigheid daar. En hulle ervaar probleme as gevolg van NUMA. Daarom probeer ons dit op minder indringende maniere deaktiveer as om te herlaai, maar wees versigtig om seker te maak dat dit gedeaktiveer is. Omdat, soos ervaring toon, dat ons NUMA op die ouerproses van PostgreSQL deaktiveer, is dit goed, maar dit is glad nie nodig dat dit sal werk nie. Ons moet kyk of sy regtig afgeskakel het.

Daar is 'n goeie plasing deur Robert Haas. Dit is een van die PostgreSQL-committers. Een van die belangrikste ontwikkelaars van alle lae-vlak ingewande. En as jy die skakels van hierdie pos volg, beskryf dit verskeie kleurvolle stories oor hoe NUMA die lewe vir mense moeilik gemaak het. Kyk, bestudeer die stelseladministrateur se kontrolelys van wat op die bediener gekonfigureer moet word sodat ons databasis goed kan werk. Hierdie instellings moet aangeteken en nagegaan word, want anders sal dit nie baie goed wees nie.

Ek vestig u aandag daarop dat dit van toepassing is op al die instellings waaroor ek sal praat. Maar gewoonlik word databasisse in meester-slaaf-modus saamgestel vir fouttoleransie. Moenie vergeet om hierdie instellings op die slaaf te maak nie, want eendag sal jy 'n ongeluk hê en jy sal na die slaaf oorskakel en dit sal die meester word.

In 'n noodgeval, wanneer alles baie sleg is, jou foon gedurig lui en jou baas kom aangehardloop met 'n groot stok, sal jy nie tyd hê om daaraan te dink nie. En die resultate kan baie rampspoedig wees.

Die volgende oomblik is groot bladsye. Groot bladsye is moeilik om afsonderlik te toets, en daar is geen sin hierin nie, hoewel daar maatstawwe is wat dit kan doen. Hulle word maklik gegoogle.

Wat is die punt? Jy het 'n nie baie duur bediener wat baie RAM het, byvoorbeeld meer as 30 GB. Jy gebruik nie groot bladsye nie. Dit beteken dat u beslis 'n oorhoofse koste het op geheuegebruik. En hierdie oorhoofse koste is ver van die aangenaamste.

Hoekom is dit? En wat gaan aan? Die bedryfstelsel ken geheue in klein stukke toe. So gerieflik, so histories. En as jy in besonderhede ingaan, moet die bedryfstelsel virtuele adresse in fisiese adresse vertaal. En hierdie proses is nie die maklikste nie, so die bedryfstelsel kas die resultaat van hierdie bewerking in die Vertaling Lookaside Buffer (TLB).

En aangesien die TLB 'n kas is, ontstaan ​​in hierdie situasie al die probleme wat inherent is aan die kas. Eerstens, as jy baie RAM het en dit word alles in klein stukke toegewys, dan word hierdie buffer baie groot. En as die kas groot is, is dit stadiger om daarna te soek. Oorhoofse koste is gesond en neem spasie op sy eie op, d.w.s. iets verkeerd verbruik RAM. Hierdie keer.

Twee - hoe meer die kas groei in so 'n situasie, hoe meer waarskynlik is dit dat jy kas mis. En die doeltreffendheid van hierdie kas neem vinnig af namate die grootte daarvan groei. Bedryfstelsels het dus met 'n eenvoudige benadering vorendag gekom. Linux gebruik dit al lank. Dit het nie so lank gelede in FreeBSD verskyn nie. Maar ons praat oor Linux. Dit is groot bladsye.

En hier moet daarop gelet word dat groot bladsye, as 'n idee, aanvanklik deur gemeenskappe gedruk is wat Oracle en IBM ingesluit het, dit wil sê databasisvervaardigers het hard gedink oor die feit dat dit nuttig sou wees, insluitend vir databasisse.

En hoe om vriende te maak met PostgreSQL? Eerstens moet groot bladsye in die Linux-kern geaktiveer word.

Tweedens moet hulle uitdruklik gespesifiseer word deur die sysctl-parameter - hoeveel daar is. Die nommers hier is van 'n ou bediener. Jy kan ongeveer bereken hoeveel gedeelde buffers jy het sodat groot bladsye daar pas.

En as jy die hele bediener het wat aan PostgreSQL toegewy is, dan is 'n goeie beginpunt om óf 25% RAM vir gedeelde buffers te gee, óf 75% as jy seker is dat jou databasis beslis in hierdie 75% sal pas. Beginpunt eerste. En dink aan, as jy 256 GB RAM het, sal jy dienooreenkomstig 64 GB skuurbuffers hê. Bereken ongeveer met 'n mate van marge - waarop jy hierdie syfer moet stel.

Voor weergawe 9.2 (as ek my nie misgis nie, sedert weergawe 8.2) was dit moontlik om vriende te maak met groot bladsye PostgreSQL deur 'n derdeparty-biblioteek te gebruik. En dit moet altyd gedoen word. Eerstens het jy die kern nodig om groot bladsye korrek te kan toewys. En, tweedens, sodat die toepassing wat met hulle werk, hulle kan gebruik. Dit sal net nie so gebruik word nie. Aangesien PostgreSQL geheue in 'n stelsel 5-styl toegewys het, kan dit gedoen word met libhugetlbfs - dit is die volle naam van die biblioteek.

9.3 het PostgreSQL-geheuewerkverrigting verbeter en die stelsel 5-geheuetoewysingsmetode laat vaar. Almal was baie gelukkig, want anders probeer jy twee PostgreSQL-instansies op dieselfde masjien laat loop, en hy sê dat ek nie genoeg gedeelde geheue het nie. En hy sê dat jy sysctl moet regmaak. En daar is so 'n sysctl dat jy nog moet herlaai, ens. Oor die algemeen was almal verheug. Maar mmap geheue toewysing het gebreek met behulp van groot bladsye. Die meeste van ons kliënte gebruik groot gedeelde buffers. En ons het sterk aanbeveel om nie na 9.3 oor te skakel nie, want daar het bokoste in goeie persentasies begin bereken.

Maar aan die ander kant het die gemeenskap die aandag op hierdie probleem gevestig en in 9.4 het hulle hierdie geleentheid baie goed herwerk. En in 9.4 het 'n parameter verskyn in postgresql.conf, waarin jy probeer kan aanskakel, aan of af.

Probeer is die veiligste opsie. Wanneer PostgreSQL begin, wanneer dit gedeelde geheue toeken, probeer dit om hierdie geheue van groot bladsye af te gryp. En as dit nie werk nie, dan rol dit terug na die gewone keuse. En as jy FreeBSD of Solaris het, kan jy probeer, dit is altyd veilig.

As dit aan is, begin dit eenvoudig nie as dit nie uit groot bladsye kon kies nie. Hier reeds - vir wie en wat is ouliker. Maar as jy probeer, maak seker dat jy regtig uitgelig het wat jy nodig het, want daar is baie spasies vir 'n fout. Tans werk hierdie funksionaliteit net op Linux.

Nog 'n klein nota voor ons aanbeweeg. Deursigtige groot bladsye gaan nog nie oor PostgreSQL nie. Hy kan hulle nie normaal gebruik nie. En met Deursigtige groot bladsye vir so 'n werklading, wanneer jy 'n groot stuk gedeelde geheue nodig het, kom die voordele net met baie groot volumes. As jy teragrepe geheue het, kan dit 'n rol speel. As ons praat oor meer alledaagse toepassings, wanneer jy 32, 64, 128, 256 GB geheue op die masjien het, dan is die gewone groot bladsye OK, en ons skakel net deursigtig af.

En die laaste ding van geheue hou nie direk verband met fruput nie, dit kan die lewe baie verwoes. Alle deurset sal grootliks beïnvloed word deur die feit dat die bediener voortdurend omruil.

En dit sal op sommige punte baie onaangenaam wees. En die grootste probleem is dat in moderne pitte die gedrag effens verskil van ouer Linux-pitte. En hierdie ding, wat nogal onaangenaam is om op te trap, want as ons praat oor 'n bietjie werk met ruil, eindig dit met die ontydige koms van die OOM-moordenaar. En die OOM-moordenaar, wat nie betyds gekom het nie en PostgreSQL afgegooi het, is onaangenaam. Almal sal daarvan weet, dit wil sê tot die laaste gebruiker.

Wat is besig om te gebeur? Jy het 'n groot hoeveelheid RAM daar, alles werk goed. Maar om een ​​of ander rede hang die bediener in ruil en vertraag dit as gevolg hiervan. Dit wil voorkom asof daar baie geheue is, maar dit gebeur.

Voorheen het ons aangeraai om vm.swappiness op nul gestel te word, dit wil sê deaktiveer ruil. Voorheen het dit gelyk of 32 GB RAM en ooreenstemmende gedeelde buffers 'n groot hoeveelheid was. Die hoofdoel van die ruil is om 'n plek te hê om 'n kors te gooi as ons afval. En dit is nie baie goed gedoen nie. En wat sal jy dan met hierdie kors doen? Dit is reeds so 'n taak wanneer dit nie baie duidelik is hoekom ruil nodig is nie, veral van so 'n grootte.

Maar in meer moderne, dit wil sê in die derde weergawes van die kern, het die gedrag verander. En as jy ruil op nul stel, dit wil sê skakel dit af, dan sal vroeër of later, selfs met 'n bietjie RAM oor, 'n OOM-moordenaar na jou toe kom om die mees intensiewe verbruikers dood te maak. Want hy sal in ag neem dat ons met so 'n werklading nog 'n bietjie oor het en ons sal uitspring, dit wil sê, nie die stelselproses doodmaak nie, maar iets minder belangrik doodmaak. Hierdie minder belangrik sal die swaar verbruiker van gedeelde geheue wees, naamlik die posmeester. En daarna sal dit goed wees as die basis nie herstel hoef te word nie.

Daarom is nou die verstek, sover ek onthou, is die meeste verspreidings iewers rondom 6, dit wil sê op watter punt om ruil te begin gebruik, afhangende van hoeveel geheue oor is. Ons beveel nou aan om vm.swappiness = 1 te stel, want dit skakel dit feitlik af, maar gee nie sulke effekte soos met 'n onverwagte OOM-moordenaar wat die hele ding kom doodmaak het nie.

Wat is volgende? As ons praat oor die werkverrigting van databasisse en geleidelik, geleidelik, is ons soos skywe, begin almal na hul koppe gryp. Want die waarheid dat die skyf stadig is en geheue vinnig is, is al van kleins af aan almal bekend. En almal weet dat daar probleme met skyfwerkverrigting in die databasis sal wees.

Die belangrikste PostgreSQL-werkverrigtingprobleem met kontrolepunte is nie omdat die skyf stadig is nie. Dit is meer waarskynlik as gevolg van die feit dat die geheue en skyfbandwydte nie gebalanseer is nie. Hulle mag egter nie op verskillende plekke gebalanseer word nie. PostgreSQL is nie opgestel nie, bedryfstelsel is nie opgestel nie, hardeware is nie opgestel nie en hardeware is verkeerd. En hierdie probleem gebeur nie net as alles verloop soos dit moet nie, dit wil sê óf daar is geen las nie, óf die instellings en hardeware is goed gekies.

Wat is dit en hoe lyk dit? Gewoonlik het mense wat met PostgreSQL werk meer as een keer by hierdie besigheid aangegaan. Ek sal verduidelik. Soos ek gesê het, PostgreSQL maak periodiek kontrolepunte om vuil bladsye in gedeelde geheue na skyf te stort. As ons 'n groot hoeveelheid gedeelde geheue het, begin kontrolepunt die skyf intensief beïnvloed, want fsync stort hierdie bladsye. Dit kom in die kernbuffer aan en word met fsync na skyf geskryf. En as die volume van hierdie saak groot is, kan ons 'n onaangename effek waarneem, naamlik 'n baie groot gebruik van skywe.

Hier het ek twee foto's. Ek sal nou verduidelik wat dit is. Dit is twee tyd-gekorreleerde grafieke. Die eerste grafiek is skyfbenutting. Hier bereik dit byna 90% op hierdie tydstip. As jy 'n databasisval met fisiese skywe het, met 'n RAID-beheerder onder 90% benutting, dan is dit slegte nuus. Dit beteken dat 'n bietjie meer en 100 sal kom en die invoer / uitvoer sal stop.

As jy 'n skyfskikking het, is daar 'n effens ander storie. Daar hang dit af van hoe dit opgestel is, watter soort skikking, ens.

En in parallel word 'n grafiek hier gekonfigureer vanuit die interne postgres-aansig, wat vertel hoe die kontrolepunt gebeur. En die groen kleur hier wys hoeveel buffers van hierdie vuil bladsye op daardie oomblik by hierdie kontrolepunt aangekom het vir sinchronisasie. En dit is die belangrikste ding om hier te weet. Ons sien dat ons baie bladsye hier het en op 'n stadium het ons 'n fooi raakgeloop, dit wil sê ons het geskryf en geskryf, hier is die skyfstelsel duidelik baie besig. En ons kontrolepunt het 'n baie sterk effek op die skyf. Ideaal gesproke moet die situasie meer so lyk, dit wil sê ons het minder rekord hier gehad. En ons kan dit regmaak met instellings sodat dit so voortgaan. Dit wil sê die herwinning is min, maar iewers skryf ons iets hier.

Wat moet gedoen word om hierdie probleem te oorkom? As jy IO onder die databasis gestop het, beteken dit dat alle gebruikers wat gekom het om hul versoeke uit te voer, sal wag.

As jy uit die oogpunt van Linux kyk, as jy goeie hardeware geneem het, dit korrek gekonfigureer het, PostgreSQL normaalweg gekonfigureer het sodat dit hierdie kontrolepunte minder gereeld sou maak, dit betyds tussen mekaar versprei, dan stap jy in die verstek Debian-parameters . Vir die meeste Linux-verspreidings is dit die prentjie: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Wat beteken dit? Sedert kern 2.6 het een demoonspoeling verskyn. Pdglush, afhangende van wie wat gebruik, wat handel oor die agtergrond wat vuil bladsye van die kernbuffer afgooi en vuil bladsye afgooi wanneer dit nodig is, maak nie saak wat nie, wanneer die agtergrondgooi nie help nie.

Wanneer kom agtergrond? Wanneer 10% van die totale RAM wat op die bediener is beset word deur vuil bladsye in die kernbuffer, dan word 'n spesiale cheat-funksie in die agtergrond genoem. Hoekom is sy agtergrond? Dit neem as 'n parameter hoeveel bladsye om af te skryf. En, kom ons sê, skryf N bladsye af. En vir 'n rukkie raak hierdie ding aan die slaap. En dan kom sy terug en skryf nog 'n paar bladsye af.

Dit is 'n uiters eenvoudige storie. Hier is die taak soos met 'n swembad, wanneer dit in een pyp stort, in 'n ander. Ons kontrolepunt het gekom en as dit 'n paar vuil bladsye gestuur het om weg te gooi, dan sal hierdie hele ding geleidelik vanaf die kernbuffer pgflush netjies oplos.

As hierdie vuil bladsye aanhou akkumuleer, versamel hulle tot 20%, daarna is die OS-prioriteit om die hele ding op skyf af te skryf, want die krag sal uitvlieg, en alles sal sleg wees vir ons. Ons sal byvoorbeeld hierdie data verloor.

Wat is die truuk? Die truuk is dat hierdie parameters in die moderne wêreld van 20 en 10% van al die RAM wat op die masjien is, absoluut monsteragtig is in terme van die deurset van enige skyfstelsel wat jy het.

Stel jou voor dat jy 128 GB RAM het. 12,8 GB kom na jou skyfstelsel. En maak nie saak watter kas jy daar het nie, maak nie saak watter skikking jy daar het nie, hulle sal nie soveel weerstaan ​​nie.

Daarom beveel ons aan dat hierdie nommers onmiddellik aangepas word na gelang van die vermoëns van jou RAID-beheerder. Ek het dadelik 'n aanbeveling hier gegee vir 'n kontroleerder wat 512 MB kas het.

Alles word as baie eenvoudig beskou. Jy kan vm.dirty_background in grepe plaas. En hierdie instellings ignoreer die vorige twee. Of die verhouding is by verstek, of dié met grepe is geaktiveer, dan sal dié met grepe werk. Maar aangesien ek 'n DBA-konsultant is en ek met verskillende kliënte werk, probeer ek strooitjies lê en dus, as in grepe, dan in grepe. Niemand het enige waarborg gegee dat 'n goeie administrateur nie geheue by die bediener sal voeg nie, dit nie sal herlaai nie, en die syfer sal dieselfde bly. Bereken net hierdie getalle sodat alles daar pas met 'n waarborg.

Wat gebeur as jy nie inpas nie? Ek het geskryf dat dit effektief enige spoeling stop, maar in werklikheid is dit 'n figuur van spraak. Die bedryfstelsel het 'n groot probleem - dit het baie vuil bladsye, so die IO wat jou kliënte genereer stop effektief, dit wil sê die toepassing het 'n sql-navraag na die databasis gestuur, dit wag. Enige I/O daarvoor het die laagste prioriteit, want die basis word deur die kontrolepunt beset. En as sy klaar is is dit heeltemal onverstaanbaar. En wanneer jy nie-agtergrond-, nie-agtergrondspoeling bereik het, beteken dit dat al jou IO daardeur beset word. En totdat dit eindig, sal jy niks doen nie.

Daar is nog twee belangrike punte wat buite die bestek van hierdie verslag val. Hierdie instellings moet ooreenstem met die instellings in postgresql.conf, dit wil sê die kontrolepunte instellings. En jou skyfstelsel moet voldoende gekonfigureer wees. As jy 'n kas op die RAID het, moet dit 'n battery hê. Mense koop RAID met goeie kas sonder battery. As jy 'n SSD in RAID het, dan moet hulle bedieners wees, daar moet kapasitors wees. Hier is die uitgebreide kontrolelys. By hierdie skakel is daar my verslag oor hoe om skyfwerkverrigting in PostgreSQL op te stel. Al daardie kontrolelyste is daar.

Wat anders kan die lewe baie moeilik maak? Dit is twee opsies. Hulle is relatief nuut. By verstek kan hulle by verskillende toepassings ingesluit word. En hulle kan die lewe net soveel kompliseer as hulle verkeerd aangeskakel word.

Daar is twee relatief nuwe stukke. Hulle het reeds in die derde kerne verskyn. Dit is sched_migration_cost in nanoseconds en sched_autogroup_enabled wat by verstek een is.

En hoe bederf hulle die lewe? Wat is sched_migrasie_koste? Die Linux-skeduleerder kan 'n proses van een SVE na 'n ander migreer. En vir PostgreSQL, wat navrae uitvoer, is dit heeltemal onverstaanbaar om na 'n ander SVE te migreer. Vanuit 'n bedryfstelsel oogpunt, wanneer jy vensters wissel tussen oopkantoor en terminale, kan dit goed wees, maar vir die databasis - dit is baie sleg. Daarom is 'n redelike beleid om migration_cost op 'n groot waarde te stel, ten minste 'n paar duisend nanosekondes.

Wat sal dit vir die skeduleerder beteken? Daar sal aanvaar word dat hierdie proses gedurende hierdie tyd nog warm is. Dit wil sê, as jy 'n soort lang transaksie het wat vir 'n lang tyd iets doen, sal die skeduleerder dit verstaan. Hy sal aanvaar dat totdat hierdie tydsverloop verby is, hierdie proses nêrens heen gemigreer hoef te word nie. As die proses terselfdertyd iets doen, sal dit nêrens heen gemigreer word nie, dit sal rustig eindig op die SVE wat daaraan toegewys is. En die resultaat is uitstekend.

Die tweede punt is outogroep. Daar is 'n goeie idee vir spesifieke werkladings wat nie met moderne databasisse verband hou nie - dit is om prosesse te groepeer volgens die virtuele terminaal waarvandaan dit van stapel gestuur word. Dit is gerieflik vir sommige take. In die praktyk is PostgreSQL 'n voorvurk-multiprosesstelsel wat vanaf 'n enkele terminale loop. Jy het 'n slotskrywer, 'n kontrolepunt, en al jou kliëntversoeke word in een skeduleerder per SVE gegroepeer. En hulle sal saam daar wag as hy vry is, om met mekaar in te meng en hom langer besig te hou. Dit is 'n storie wat heeltemal onnodig is in die geval van so 'n vrag en daarom moet dit afgeskakel word.

My kollega Alexey Lesovsky het toetse met 'n eenvoudige pgbench gedoen, waar hy migration_cost met 'n orde van grootte verhoog het en outogroep afgeskakel het. Die verskil op 'n slegte stuk yster blyk amper 10% te wees. Daar is 'n bespreking op die postgres-poslys waar mense resultate rapporteer soos soortgelyke veranderinge aan navraagspoed 50% beïnvloed. Daar is heelwat sulke stories.

En laastens, oor die kragbesparingsbeleid. Dit is goed dat Linux nou op 'n skootrekenaar gebruik kan word. En dit sal kwansuis die battery goed verteer. Maar skielik blyk dit dat dit ook op die bediener kan gebeur.

Boonop, as u bedieners van een of ander gasheer huur, gee “goeie” gasheer nie om dat u beter werkverrigting het nie. Hulle taak is om seker te maak dat hul yster so doeltreffend moontlik benut word. Daarom kan hulle by verstek die skootrekenaar-kragbesparingsmodus op die bedryfstelsel aanskakel.

As jy dit op 'n swaar gelaaide databasisbediener gebruik, dan is jou keuse acpi_cpufreq + permormance. Selfs met on-demand sal daar reeds probleme wees.

Intel_pstate is 'n effens ander bestuurder. En nou word voorkeur gegee aan hierdie een, as aan 'n later en beter werkende een.

En dienooreenkomstig is die goewerneur slegs prestasie. Op aanvraag, kragbesparing en al die res - dit gaan nie oor jou nie.

Die resultate van verduidelik ontleed PostgreSQL kan met verskeie ordes van grootte verskil as jy kragbesparing aanskakel, want in die praktyk sal jy SVE-storting onder die databasis op 'n heeltemal onvoorspelbare manier hê.

Hierdie dinge kan by verstek geaktiveer word. Kyk mooi om te sien of hulle by verstek geaktiveer is. Dit kan 'n baie groot probleem wees.

En op die ou end wou ek dankie sê aan die ouens van ons PosgreSQL-Consulting DBA-span, naamlik Max Boguk en Alexey Lesovsky, wat elke dag bulte in hierdie besigheid vul. En vir ons kliënte probeer ons om die beste te doen, sodat dit alles vir hulle werk. Dit is soos met lugvaartsekuriteitsinstruksies. Alles hier is in bloed geskryf. Elkeen van hierdie neute word ontdek in die proses van 'n soort probleem. Ek deel dit graag met jou.

Vrae:

Dankie! As 'n maatskappy byvoorbeeld geld wil spaar en die databasis en toepassingslogika op dieselfde bediener wil huisves, of as die maatskappy die modetendens volg van mikrodiensargitekture waarin PostgreSQL in 'n houer loop. Wat is die punt? Sysctl raak wêreldwyd die hele kern. Ek het nie gehoor dat sysctls op een of ander manier gevirtualiseer word sodat hulle afsonderlik op die houer werk nie. Daar is net cgroup en net 'n deel daarvan het beheer. Hoe kan jy daarmee saamleef? Of as jy prestasie wil hê, hardloop dan PostgreSQL op 'n aparte ysterbediener en stel dit in?

Ons het jou vraag op ongeveer drie maniere beantwoord. As ons nie praat van 'n ysterbediener wat ingestel kan word, ens. nie, ontspan dan, alles sal goed werk sonder hierdie instellings. As jy so 'n las het dat jy hierdie instellings moet doen, sal jy vroeër as hierdie instellings by die ysterbediener kom.

Wat is die probleem? As dit 'n virtuele masjien is, sal jy heel waarskynlik baie probleme hê, byvoorbeeld met die feit dat die meeste virtuele masjiene taamlik inkonsekwente skyfvertraging het. Selfs al is skyfdeurset goed, 'n enkele mislukte I/O-transaksie wat nie die gemiddelde deurset wat plaasgevind het ten tyde van die kontrolepunt of ten tyde van die skryf aan WAL grootliks beïnvloed nie, dan sal die databasis baie hierdeur ly. En jy sal dit agterkom voordat jy hierdie probleme ondervind.

As jy NGINX op dieselfde bediener het, sal jy ook dieselfde probleem hê. Hy sal veg vir gedeelde geheue. En jy sal nie die probleme bereik wat hier beskryf word nie.

Maar aan die ander kant sal sommige van hierdie parameters steeds vir jou relevant wees. Byvoorbeeld, met sysctl, stel dirty_ratio sodat dit nie so mal is nie - dit sal in elk geval help. Op een of ander manier sal jy interaksie met die skyf hê. En dit sal verkeerd wees. Dit is oor die algemeen die verstek van die parameters wat ek gewys het. En in elk geval is dit beter om hulle te verander.

En met NUMA kan daar probleme wees. VmWare, byvoorbeeld, werk goed met NUMA met presies die teenoorgestelde instellings. En hier moet jy kies - 'n ysterbediener of 'n nie-yster een.

Ek het 'n vraag wat verband hou met Amazon AWS. Hulle het beelde wat vooraf gekonfigureer is. Een van hulle word Amazon RDS genoem. Is daar enige persoonlike instellings vir hul bedryfstelsel?

Daar is instellings, maar dit is verskillende instellings. Hier konfigureer ons die bedryfstelsel in terme van hoe die databasis hierdie besigheid sal gebruik. En daar is parameters wat bepaal waarheen ons nou moet gaan, so 'n vorming. Dit wil sê, ons het soveel hulpbronne nodig, ons sal dit nou opvreet. Daarna maak Amazon RDS hierdie hulpbronne vas, en werkverrigting daal daar. Daar is afsonderlike stories van hoe mense begin chemie met hierdie saak. Soms selfs redelik suksesvol. Maar dit het niks met OS-instellings te doen nie. Dit is soos wolkkrakery. Dis 'n ander storie.

Waarom het deursigtige groot bladsye geen effek in vergelyking met Groot TLB nie?

Moenie gee nie. Dit kan op baie maniere verduidelik word. Maar in werklikheid gee hulle dit net nie. Wat is die geskiedenis van PostgreSQL? By die opstart ken dit 'n groot deel gedeelde geheue toe. Deursigtig is hulle terselfdertyd of nie deursigtig nie - dit maak glad nie saak nie. Die feit dat hulle aan die begin uitstaan, verklaar alles. En as daar baie geheue is en jy moet die shared_memory-segment herbou, dan sal deursigtige groot bladsye relevant wees. In PostgreSQL word dit eenvoudig aan die begin uitgelig met 'n groot stuk en dit is dit, en dan gebeur niks spesiaals daar nie. Jy kan dit natuurlik gebruik, maar daar is 'n kans om tekortkoming shared_memory te kry wanneer dit iets hertoeken. PostgreSQL weet nie hiervan nie.

Bron: will.com