Transkript fan it 2015-rapport fan Ilya Kosmodemyansky "Linux-tuning om PostgreSQL-prestaasjes te ferbetterjen"
Disclaimer: Ik merk op dat dit rapport is datearre novimber 2015 - mear as 4 jier binne ferrûn en in protte tiid is ferrûn. De ferzje 9.4 besprutsen yn it rapport wurdt net langer stipe. Yn 'e ôfrûne 4 jier binne 5 nije releases fan PostgreSQL frijlitten, en 15 ferzjes fan' e Linux kernel binne frijlitten. As jo dizze passaazjes oerskriuwe, sille jo einigje mei in oar rapport. Mar hjir beskôgje wy fûnemintele Linux-tuning foar PostgreSQL, dy't hjoed noch relevant is.
Myn namme is Ilya Kosmodemyansky. Ik wurkje by PostgreSQL-Consulting. En no sil ik in bytsje prate oer wat te dwaan mei Linux yn relaasje ta databases yn 't algemien en PostgreSQL yn' t bysûnder, om't de prinsipes frijwat ferlykber binne.
Wêr sille wy oer prate? As jo kommunisearje mei PostgreSQL, dan moatte jo yn guon mjitte in UNIX-admin wêze. Wat betsjut dat? As wy Oracle en PostgreSQL fergelykje, dan moatte jo yn Oracle 80% DBA-database-admin en 20% Linux-admin wêze.
Mei PostgreSQL is it in bytsje komplisearre. Mei PostgreSQL moatte jo in folle better begryp hawwe fan hoe't Linux wurket. En tagelyk in bytsje efter de lokomotyf rinne, want de lêste tiid is alles aardich bywurke. En nije kernels wurde frijlitten, en nije funksjonaliteit ferskynt, prestaasjes ferbetterje, ensfh.
Wêrom hawwe wy it oer Linux? Net om't wy op 'e Linux-konferinsje Peter binne, mar om't yn moderne omstannichheden ien fan' e meast rjochtfeardige bestjoeringssystemen foar it brûken fan databases yn 't algemien en PostgreSQL yn' t bysûnder Linux is. Om't FreeBSD, spitigernôch, ûntwikkelet yn wat heul frjemde rjochting. En d'r sille problemen wêze sawol mei prestaasjes as mei in protte oare dingen. De prestaasjes fan PostgreSQL op Windows is oer it generaal in apart serieus probleem, basearre op it feit dat Windows net itselde dielde ûnthâld hat as UNIX, wylst PostgreSQL hjir allegear bûn is, om't it in multyprosessysteem is.
En ik tink dat elkenien minder ynteressearre is yn eksoaten lykas Solaris, dus litte wy gean.
In moderne Linux-distribúsje hat mear as 1 syctl-opsjes, ôfhinklik fan hoe't jo de kernel bouwe. Tagelyk, as wy nei de ferskillende nuten sjogge, kinne wy op in protte manieren wat oanpasse. D'r binne triemsysteemparameters oer hoe't jo se kinne montearje. As jo fragen hawwe oer hoe't jo it begjinne: wat te aktivearjen yn 'e BIOS, hoe't jo de hardware konfigurearje, ensfh.
Dit is in heul grut folume dat kin wurde besprutsen oer ferskate dagen, en net yn ien koart rapport, mar no sil ik rjochtsje op wichtige dingen, hoe't jo dy rakes kinne foarkomme dy't garandearre binne om te foarkommen dat jo jo database goed brûke op Linux as jo korrigearje se net. En tagelyk is in wichtich punt dat in protte standertparameters net opnommen binne yn 'e ynstellingen dy't korrekt binne foar de databank. Dat is, standert sil it min of hielendal net wurkje.
Hokker tradisjonele tuningdoelen binne d'r yn Linux? Ik tink dat, om't jo allegear mei Linux-administraasje te meitsjen hawwe, d'r gjin spesjale need is om út te lizzen wat doelen binne.
Jo kinne ôfstimme:
- CPUs.
- Oantinken.
- Opslach.
- Oar. Wy prate oer dit oan 'e ein foar in hapke. Sels bygelyks parameters lykas enerzjybesparringsbelied kinne op in tige ûnfoarspelbere en net de noflikste manier de prestaasjes beynfloedzje.
Wat binne de spesifiken fan PostgreSQL en de databank yn it algemien? It probleem is dat jo gjin yndividuele nut kinne oanpasse en sjen dat ús prestaasjes signifikant ferbettere binne.
Ja, d'r binne sokke gadgets, mar in databank is in kompleks ding. It ynteraksje mei alle boarnen dy't de tsjinner hat en it leafst ynteraksje mei de meast folsleine. As jo nei de hjoeddeistige oanbefellings fan Oracle sjogge oer hoe't jo in host-OS brûke, sil it wêze as de grap oer dy Mongoalske kosmonaut - fiede de hûn en net oanreitsje. Litte wy de databank alle boarnen jaan, de databank sels sil alles sortearje.
Yn prinsipe is de situaasje yn guon mjitte krekt itselde mei PostgreSQL. It ferskil is dat de databank noch net alle boarnen foar himsels kin nimme, dus earne op it Linux-nivo moatte jo it allegear sels sortearje.
It haadgedachte is net om ien doel te selektearjen en it te begjinnen mei it ôfstimmen, bygelyks ûnthâld, CPU of sa, mar om de wurkdruk te analysearjen en de trochslach safolle mooglik te ferbetterjen sadat de lading dy't goede programmeurs it makke hawwe foar ús, ynklusyf ús brûkers.
Hjir is in foto om út te lizzen wat it is. D'r is in Linux OS-buffer en d'r is dield ûnthâld en d'r binne PostgreSQL dielde buffers. PostgreSQL, yn tsjinstelling ta Oracle, wurket direkt allinich fia de kernelbuffer, dat wol sizze, om in side fan 'e skiif yn syn dielde ûnthâld te krijen, moat it troch de kernelbuffer gean en werom, krekt deselde situaasje.
Disks libje ûnder dit systeem. Ik tekene dit as skiven. Yn feite kin d'r in RAID-controller wêze, ensfh.
En dizze input-output bart op ien of oare manier troch dizze saak.
PostgreSQL is in klassike databank. Der is in side yn. En alle ynfier en útfier komt foar mei help fan siden. Wy ferheegje blokken yn it ûnthâld mei siden. En as der neat barde, lêze wy se gewoan, dan ferdwine se stadichoan út dizze cache, út 'e dielde buffers en komme werom op' e skiif.
As wy earne wat ferfange, dan wurdt de hiele side markearre as smoarch. Ik markearre se hjir yn blau. En dit betsjut dat dizze side moat wurde syngronisearre mei blok opslach. Dat is, doe't wy it smoarch makken, makken wy in yngong yn WAL. En op in prachtich momint yn 'e tiid kaam in fenomeen neamd checkpoint. En ynformaasje waard opnommen yn dit log dat hy oankommen wie. En dit betsjut dat alle smoarge siden dy't hjir op dat stuit yn dizze dielde buffers wiene syngronisearre mei de opslachskiif mei fsync troch de kernelbuffer.
Wêrom wurdt dit dien? As wy ferlearen spanning, dan wy net krije de situaasje dat alle gegevens wiene ferlern. Persistent ûnthâld, dêr't elkenien ús oer fertelde, is oant no ta yn 'e databankteory - dit is in ljochte takomst, dêr't wy, fansels, nei stribje en wy fine it, mar foar no libje se yn min 20 jier. En dit alles moat fansels kontrolearre wurde.
En de taak om de trochstream te maksimalisearjen is om op al dizze stadia te fine-tunen, sadat it allegear fluch hinne en wer beweecht. Dielde ûnthâld is yn prinsipe in side-cache. Yn PostgreSQL stjoerde wy in selekteare fraach of sa, it helle dizze gegevens fan skiif. Se bedarre yn dielde buffers. Om dit better te wurkjen moat der dus in soad ûnthâld wêze.
Om dit alles goed en fluch te wurkjen, moatte jo it bestjoeringssysteem yn alle stadia goed konfigurearje. En kies lykwichtige hardware, want as jo op ien of oare plak in ûnbalâns hawwe, dan kinne jo in protte ûnthâld meitsje, mar it sil net mei genôch snelheid betsjinne wurde.
En lit ús gean troch elk fan dizze punten.
Om dizze siden rapper hinne en wer te reizgjen, moatte jo it folgjende berikke:
- As earste moatte jo effisjinter wurkje mei ûnthâld.
- Twad, dizze oergong as siden fan it ûnthâld nei skiif geane soe effisjinter wêze moatte.
- En as tredde moatte d'r goede skiven wêze.
As jo 512 GB RAM yn 'e tsjinner hawwe en alles einiget op in SATA hurde skiif sûnder cache, dan feroaret de folsleine databanktsjinner net allinich in pompoen, mar in pompoen mei in SATA-ynterface. Jo sille der direkt yn rinne. En neat sil jo rêde.
Oangeande it earste punt mei ûnthâld binne d'r trije dingen dy't it libben heul lestich meitsje kinne.
De earste fan harren is NUMA. NUMA is in ding dat is makke om prestaasjes te ferbetterjen. Ofhinklik fan 'e wurkdruk kinne ferskate dingen optimalisearre wurde. En yn syn nije hjoeddeistige foarm is it net heul goed foar applikaasjes lykas databases dy't yntinsyf gebrûk meitsje fan dielde buffers fan side-cache.
Yn in nutedop. Hoe kinne jo fertelle as der wat mis is mei NUMA? Jo hawwe in soarte fan onaangename knock, ynienen wat CPU wurdt oerladen. Tagelyk analysearje jo fragen yn PostgreSQL en sjogge dat d'r neat ferlykber is. Dizze fragen moatte net sa CPU-yntinsyf wêze. Jo kinne dit foar in lange tiid fange. It is makliker om de juste oanbefelling fan it begjin ôf te brûken oer hoe't jo NUMA foar PostgreSQL konfigurearje.
Wat bart der echt? NUMA stiet foar Non-Uniform Memory Access. Wat is it punt? Jo hawwe in CPU, neist it is it lokale ûnthâld. En dit ûnthâld interconnects kinne lûke ûnthâld fan oare CPUs.
As jo rinne numactl --hardware, dan krijst sa'n grut blêd. Der komt ûnder oare in ôfstannenfjild. D'r sille nûmers wêze - 10-20, soksawat. Dizze nûmers binne neat mear as it oantal hops om dit ûnthâld op ôfstân op te heljen en lokaal te brûken. Yn prinsipe in goed idee. Dit fersnelt de prestaasjes goed ûnder in ferskaat oan workloads.
Stel jo no foar dat jo ien CPU hawwe dy't earst besykje syn lokale ûnthâld te brûken, en dan besykje in oar ûnthâld op te heljen fia interconnect foar iets. En dizze CPU krijt jo heule PostgreSQL-pagina-cache - dat is it, wat gigabytes. Jo krije altyd it slimste gefal, om't op 'e CPU meastentiids in bytsje ûnthâld is yn dy module sels. En al it ûnthâld dat wurdt betsjinne giet troch dizze interconnects. It komt stadich en tryst út. En jo prosessor dy't dit knooppunt betsjinnet wurdt konstant oerladen. En de tagong tiid fan dit ûnthâld is min, stadich. Dit is de situaasje dy't jo net wolle as jo dit brûke foar in databank.
Dêrom is in mear korrekte opsje foar de databank foar it Linux-bestjoeringssysteem om hielendal net te witten wat der bart. Sadat it tagong ta ûnthâld as it docht.
Wêrom is dat? It soe lykje dat it oarsom moat. Dit bart foar ien ienfâldige reden: wy hawwe in soad ûnthâld nedich foar de side-cache - tsientallen, hûnderten gigabytes.
En as wy dit alles alloceare en ús gegevens dêr yn 'e cache hawwe, dan sil de winst fan it brûken fan' e cache signifikant grutter wêze as de winst fan sa'n lestige tagong ta ûnthâld. En wy sille dus ûnfergelykber profitearje yn ferliking mei it feit dat wy effisjinter tagong krije ta ûnthâld mei NUMA.
Dêrom binne d'r hjir op it stuit twa oanpakken, oant de ljochte takomst is oankaam, en de databank sels is net by steat om út te finen hokker CPU's it rint en wêr't it wat moat lûke.
Dêrom is de juste oanpak om NUMA hielendal út te skeakeljen, bygelyks by it opnij opstarten. Yn 'e measte gefallen binne de winsten fan sa'n folchoarder dat de fraach wat better is, hielendal net opkomt.
Der is in oare opsje. Wy brûke it faker as de earste, want as in klant by ús komt foar stipe, is it opnij opstarten fan de tsjinner in grut probleem foar him. Hy hat dêr in bedriuw. En se ûnderfine problemen fanwegen NUMA. Dêrom besykje wy it op minder invasive manieren út te skeakeljen dan opnij te starten, mar wês foarsichtich om te kontrolearjen dat it is útskeakele. Om't, lykas ûnderfining docht bliken, is it goed dat wy NUMA útskeakelje op it âlder PostgreSQL-proses, mar it is hielendal net nedich dat it sil wurkje. Wy moatte kontrolearje en sjen dat se echt útskeakele is.
Der is in goede post fan Robert Haas. Dit is ien fan 'e PostgreSQL-committers. Ien fan 'e wichtichste ûntwikkelders fan alle lege-nivo giblets. En as jo de keppelings fan dizze post folgje, beskriuwe se ferskate kleurige ferhalen oer hoe't NUMA it libben lestich makke foar minsken. Sjoch, studearje de checklist fan systeembehearder fan wat op 'e server moat wurde konfigureare om ús database goed te wurkjen. Dizze ynstellingen moatte opskreaun en kontrolearre wurde, want oars sil it net sa goed wêze.
Tink derom dat dit jildt foar alle ynstellingen wêr't ik oer sil prate. Mar meastal databases wurde sammele yn master-slave modus foar skuld tolerânsje. Ferjit net om dizze ynstellingen op 'e slaaf te meitsjen, om't jo ien dei in ûngelok sille hawwe en jo sille oerskeakelje nei de slaaf en it sil de master wurde.
Yn in needsituaasje, as alles heul min is, jo tillefoan konstant rinkelt en jo baas komt mei in grutte stok rinnen, sille jo gjin tiid hawwe om nei te tinken oer kontrolearjen. En de resultaten kinne hiel desastreus wêze.
It folgjende punt is enoarme siden. Enorme siden binne lestich om apart te testen, en d'r hat gjin punt om dit te dwaan, hoewol d'r benchmarks binne dy't dit kinne dwaan. Se binne maklik te Google.
Wat is it punt? Jo hawwe in net hiel djoer tsjinner mei in soad RAM, Bygelyks, mear as 30 GB. Jo brûke gjin grutte siden. Dit betsjut dat jo perfoarst overhead hawwe yn termen fan ûnthâldgebrûk. En dizze overhead is fier fan de meast noflike.
Wêrom is dat? Wat is der geande? It bestjoeringssysteem allocates ûnthâld yn lytse stikken. It is sa handich, it is hoe't it histoarysk barde. En as wy yn detail gean, moat it OS firtuele adressen oersette yn fysike. En dit proses is net it ienfâldichste, dus it OS cache it resultaat fan dizze operaasje yn 'e Translation Lookaside Buffer (TLB).
En om't de TLB in cache is, ûntsteane alle problemen dy't yn in cache binne yn dizze situaasje. As earste, as jo in protte RAM hawwe en it is allegear yn lytse brokken tawiisd, dan wurdt dizze buffer heul grut. En as de cache grut is, dan is it sykjen troch it stadiger. Overhead is sûn en it sels nimt romte yn, d.w.s. RAM wurdt konsumearre troch wat ferkeards. Dizze kear.
Twa - hoe mear de cache groeit yn sa'n situaasje, hoe wierskynliker it is dat jo cache mist hawwe. En de effisjinsje fan dizze cache nimt rap ôf as syn grutte nimt ta. Dêrom, bestjoeringssystemen kamen mei in ienfâldige oanpak. It is in lange tiid brûkt yn Linux. It ferskynde yn FreeBSD net sa lang lyn. Mar wy prate oer Linux. Dit binne grutte siden.
En hjir moat opmurken wurde dat enoarme siden, as idee, yn earste ynstânsje waarden opstutsen troch mienskippen dy't Oracle en IBM omfette, dat wol sizze dat databankfabrikanten sterk tochten dat dit ek nuttich wêze soe foar databases.
En hoe kin dit befreone wurde mei PostgreSQL? As earste moatte enoarme siden ynskeakele wurde yn 'e Linux-kernel.
Twadder moatte se eksplisyt wurde oantsjutte troch de sysctl-parameter - hoefolle d'r binne. De nûmers hjir binne fan guon âlde tsjinner. Jo kinne berekkenje hoefolle dielde buffers jo hawwe, sadat enoarme siden dêr kinne passe.
En as jo hiele tsjinner is wijd oan PostgreSQL, dan is in goed begjinpunt om of 25% fan 'e RAM te allocearjen oan dielde buffers, of 75% as jo der wis fan binne dat jo databank perfoarst yn dizze 75% past. Begjinpunt ien. En beskôgje, as jo 256 GB RAM hawwe, dan sille jo dus 64 GB grutte buffers hawwe. Berekkenje sawat mei wat marzje - wêrop dit figuer moat wurde ynsteld.
Foar ferzje 9.2 (as ik my net fersin, sûnt ferzje 8.2), wie it mooglik om PostgreSQL te ferbinen mei enoarme siden mei in bibleteek fan tredden. En dit moat altyd dien wurde. Earst hawwe jo de kernel nedich om enoarme siden korrekt te allocearjen. En, twadde, sadat de applikaasje dy't mei har wurket, se kinne brûke. It sil net allinich sa brûkt wurde. Sûnt PostgreSQL ûnthâld tawiisd yn 'e styl fan systeem 5, koe dit dien wurde mei libhugetlbfs - dit is de folsleine namme fan' e bibleteek.
Yn 9.3 waarden PostgreSQL-prestaasjes ferbettere by it wurkjen mei ûnthâld en de systeem 5 ûnthâld tawizing metoade waard ferlitten. Elkenien wie tige bliid, want oars besykje jo twa PostgreSQL-eksimplaren op ien masine út te fieren, en hy seit dat ik net genôch dield ûnthâld haw. En hy seit dat sysctl korrizjearre wurde moat. En d'r is sa'n sysctl dat jo noch moatte opnij starte, ensfh Yn 't algemien wie elkenien bliid. Mar tawizing fan mmap-ûnthâld bruts it gebrûk fan enoarme siden. De measte fan ús kliïnten brûke grutte dielde buffers. En wy riede sterk oan om net oer te skeakeljen nei 9.3, om't de overhead begon te berekkenjen yn goede persintaazjes.
Mar de mienskip joech omtinken oan dit probleem en yn 9.4 hawwe se dit barren tige goed bewurke. En yn 9.4 ferskynde in parameter yn postgresql.conf wêryn jo besykje kinne ynskeakelje, oan of út.
Besykje is de feilichste opsje. As PostgreSQL begjint, as it dielde ûnthâld allocearret, besiket it dit ûnthâld fan 'e enoarme siden te pakken. En as it net wurket, dan rôlet it werom nei de normale seleksje. En as jo FreeBSD of Solaris hawwe, dan kinne jo besykje, it is altyd feilich.
As oan, dan begjint it gewoan net as it net koe selektearje út 'e enoarme siden. Hjir giet it al oer wa en wat moaier is. Mar as jo besykje, kontrolearje dan dat jo echt hawwe wat jo nedich hawwe markearre, om't d'r in protte romte is foar flaters. Op it stuit wurket dizze funksjonaliteit allinich op Linux.
Noch ien lytse notysje foardat wy fierder gean. Transparante enoarme siden binne noch net oer PostgreSQL. Hy kin se net normaal brûke. En mei Transparante enoarme siden foar sa'n wurkdruk, as in grut stik dielde ûnthâld nedich is, komme de foardielen allinich mei heul grutte folumes. As jo terabytes oan ûnthâld hawwe dan kin dit yn spiel komme. As wy it hawwe oer mear deistige applikaasjes, as jo 32, 64, 128, 256 GB ûnthâld op jo masine hawwe, dan binne de gewoane enoarme siden Ok, en wy skeakelje gewoan Transparent út.
En it lêste ding oer ûnthâld is net direkt relatearre oan fruitut, it kin jo libben echt ferneatigje. Alle trochstreaming sil sterk beynfloede wurde troch it feit dat de tsjinner konstant wikselet.
En dit sil op in oantal manieren heul onaangenaam wêze. En it wichtichste probleem is dat moderne kernels wat oars gedrage as âldere Linux kernels. En dit ding is nochal onaangenaam om op te stappen, want as wy it hawwe oer in soarte fan wurk mei ruil, dan einiget it mei de ûntiidske komst fan de OOM-moardner. En de OOM-killer, dy't net op 'e tiid kaam en PostgreSQL liet falle, is onaangenaam. Eltsenien sil witte oer dit, dat is, oant de lêste brûker.
Wat bart der? Jo hawwe in grutte hoemannichte RAM dêr, alles wurket goed. Mar om ien of oare reden hinget de tsjinner yn swap en fertraget hjirtroch. It soe lykje dat der in soad ûnthâld, mar dit bart.
Earder advisearre wy vm.swappiness op nul te setten, dus ruilje útskeakelje. Earder like it dat 32 GB RAM en oerienkommende dielde buffers in enoarm bedrach wie. It haaddoel fan 'e ruil is om in plak te hawwen om de krust te smiten as wy falle. En it wie net mear spesjaal foldien. En wat sille jo dan mei dizze koarst dwaan? Dit is in taak dêr't it is net hiel dúdlik wêrom swap is nedich, benammen fan sa'n grutte.
Mar yn modernere, dus tredde ferzjes fan 'e kearn, is it gedrach feroare. En as jo swap op nul sette, d.w.s. it útsette, dan sil ier of letter, sels as der wat RAM oer is, in OOM-killer nei jo komme om de meast yntinsive konsuminten te deadzjen. Want hy sil beskôgje dat wy mei sa'n wurkdruk noch in bytsje oer hawwe en wy springe út, dus net om it systeemproses te spikerjen, mar om wat minder wichtichs te spikerjen. Dizze minder wichtige sil de yntinsive konsumint fan dielde ûnthâld wêze, nammentlik de postmaster. En dêrnei sil it goed wêze as de basis net restaurearre wurde moat.
Dêrom, no de standert, sa fier as ik tink, de measte distribúsjes binne earne om 6, i.e. op hokker punt moatte jo begjinne te brûken swap ôfhinklik fan hoefolle ûnthâld is oerbleaun. Wy riede no oan om vm.swappiness = 1 yn te stellen, om't dit praktysk útskeakelt, mar net deselde effekten jout as mei in OOM-killer dy't ûnferwachts oankaam en it hiele ding fermoarde.
Wat komt hjirnei? As wy prate oer de prestaasjes fan databases en stadichoan ferhúzje nei skiven, begjint elkenien har holle te pakken. Om't de wierheid dat de skiif stadich is en it ûnthâld fluch is, is elkenien fan 'e jeugd bekend. En elkenien wit dat de databank problemen mei skiifprestaasjes sil hawwe.
It wichtichste PostgreSQL-prestaasjeprobleem ferbûn mei kontrôlepunten spikes komt net foar om't de skiif stadich is. Dit komt nei alle gedachten troch it feit dat ûnthâld en skiif bânbreedte binne net balansearre. Se kinne lykwols net op ferskate plakken lykwichtich wêze. PostgreSQL is net konfigureare, it OS is net konfigureare, de hardware is net konfigureare en de hardware is ferkeard. En dit probleem bart net allinich as alles bart lykas it moat, d.w.s. d'r is gjin lading, of de ynstellingen en hardware binne goed selektearre.
Wat is it en hoe sjocht it der út? Normaal binne minsken dy't wurkje mei PostgreSQL dizze saak mear as ien kear oangien. Ik sil it útlizze. Lykas ik sei, makket PostgreSQL periodyk kontrôlepunten om smoarge siden yn dielde ûnthâld op skiif te dumpen. As wy hawwe in grut bedrach fan dielde ûnthâld, dan checkpoint begjint te hawwen in yntinsive ynfloed op de skiif, omdat it dumpt dizze siden mei fsync. It komt yn 'e kernelbuffer en wurdt skreaun nei skiven mei fsync. En as it folume fan dit bedriuw grut is, dan kinne wy in onaangename effekt observearje, nammentlik in heul grut gebrûk fan skiven.
Hjir haw ik twa foto's. Ik sil no útlizze wat it is. Dit binne twa tiid-korrelearre grafiken. De earste grafyk is skiif gebrûk. Hjir berikt it hast 90% op dit stuit yn 'e tiid. As jo in databankfout hawwe mei fysike skiven, mei in RAID-controller gebrûk op 90%, dan is dit min nijs. Dit betsjut dat in bytsje mear en it sil berikke 100 en de I / O sil stopje.
As jo in skiif array hawwe, dan is it in wat oars ferhaal. It hinget ôf fan hoe't it is konfigurearre, hokker soarte fan array it is, ensfh.
En parallel is hjir in grafyk fan 'e ynterne postgres-werjefte konfigureare, dy't fertelt hoe't it kontrôlepunt bart. En de griene kleur hjir lit sjen hoefolle buffers, dizze smoarge siden, op dat stuit by dit kontrôlepunt kamen foar syngronisaasje. En dit is it wichtichste ding dat jo hjir moatte witte. Wy sjogge dat wy hjir in protte siden hawwe en op in stuit reitsje wy op it boerd, dat is, wy hawwe skreaun en skreaun, hjir is it skiifsysteem dúdlik drok. En ús kontrôle hat in heul sterke ynfloed op 'e skiif. Idealiter soe de situaasje der mear sa útsjen moatte, d.w.s. wy hiene hjir minder opnames. En wy kinne it reparearje mei de ynstellingen sadat it sa bliuwt. Dat wol, de recycling is lyts, mar earne skriuwe wy hjir wat.
Wat moat dien wurde om dit probleem te oerwinnen? As jo hawwe stoppe IO ûnder de databank, dit betsjut dat alle brûkers dy't kamen te ferfoljen harren oanfragen sille wachtsje.
As jo sjogge út it eachpunt fan Linux, as jo namen goede hardware, konfigurearre it korrekt, konfigurearre PostgreSQL normaal sadat it makket dizze checkpoints minder faak, ferspriedt se oer de tiid tusken inoar, dan stappe jo yn 'e standert Debian parameters. Foar de measte Linux-distribúsjes is dit de ôfbylding: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
Wat betsjut dat? Ien flushing demon ferskynde út kernel 2.6. Pdglush, ôfhinklik fan wa't brûkt hokker, dy't dwaande is mei eftergrûn ferwiderjen fan smoarge siden út 'e kearnbuffer en ôfsjitte as it nedich is om smoarge siden te ferwiderjen, wat dan ek, as it fuortheljen fan backgrouind net helpt.
Wannear komt eftergrûn? As 10% fan 'e totale RAM beskikber op' e tsjinner wurdt beset troch smoarge siden yn 'e kearnbuffer, wurdt in spesjale ôfskriuwfunksje op' e eftergrûn neamd. Wêrom is it eftergrûn? As parameter hâldt it rekken mei hoefolle siden ôfskriuwe moatte. En, lit ús sizze, hy skriuwt N siden ôf. En in skoft falt dit ding yn 'e sliep. En dan komt se wer en kopiearret noch wat siden.
Dit is in ekstreem ienfâldich ferhaal. It probleem hjir is as mei in swimbad, as it yn ien piip streamt, streamt it yn in oare. Us kontrôlepunt kaam oan en as it in pear smoarge siden stjoerde om te ferwiderjen, dan sil it heule ding stadichoan kreas oplost wurde fan 'e kernelbuffer pgflush.
As dizze smoarge siden trochgean te sammeljen, sammelje se oant 20%, wêrnei't de OS-prioriteit is om it hiele ding op 'e skiif ôf te skriuwen, om't de macht sil falle en alles sil min wêze foar ús. Wy sille bygelyks dizze gegevens ferlieze.
Wat is de trúk? De trúk is dat dizze parameters yn 'e moderne wrâld binne 20 en 10% fan de totale RAM dat is op' e masine, se binne absolút meunsterlike yn termen fan de trochstreaming fan alle skiif systeem dat jo hawwe.
Stel jo foar dat jo 128 GB RAM hawwe. 12,8 GB komt yn jo skiif systeem. En hokker cache jo dêr ek hawwe, hokker array jo dêr ek hawwe, se sille net sa lang duorje.
Dêrom riede wy oan dat jo dizze nûmers fuortendaliks oanpasse op basis fan 'e mooglikheden fan jo RAID-controller. Ik makke hjir fuortendaliks in oanbefelling foar in kontrôler dy't 512 MB fan cache hat.
Alles wurdt beskôge as hiel ienfâldich. Jo kinne sette vm.dirty_background yn bytes. En dizze ynstellingen annulearje de foarige twa. Of ferhâlding is standert, of dy mei bytes binne aktivearre, dan sille dy mei bytes wurkje. Mar om't ik in DBA-adviseur bin en mei ferskate kliïnten wurkje, besykje ik strie te tekenjen en dêrom, as yn bytes, dan yn bytes. Gjinien joech gjin garânsje dat in goede admin soe net tafoegje mear ûnthâld oan de tsjinner, opnij starte, en it figuer soe bliuwe itselde. Berekkenje dizze sifers gewoan sadat alles der mei garânsje yn past.
Wat bart der as jo net passe? Ik haw skreaun dat elke flushing effektyf stoppe wurdt, mar yn feite is dit in figuer fan spraak. It bestjoeringssysteem hat in grut probleem - it hat in protte smoarge siden, dus de IO dy't jo kliïnten generearje wurdt effektyf stoppe, d.w.s. de applikaasje is kommen om in sql-fraach nei de databank te stjoeren, it wachtet. Elke ynfier/útfier dêrta hat de leechste prioriteit, om't de databank beset wurdt troch in kontrôlepunt. En wannear't se klear is is it folslein ûndúdlik. En as jo net-eftergrûnspoeling hawwe berikt, betsjut dit dat al jo IO der troch is beset. En oant it einiget, sille jo neat dwaan.
D'r binne hjir noch twa wichtige punten dy't bûten it ramt fan dit rapport lizze. Dizze ynstellings moatte oerienkomme mei de ynstellings yn postgresql.conf, d.w.s. checkpoints ynstellings. En jo skiifsysteem moat adekwaat konfigureare wurde. As jo in cache hawwe op in RAID, dan moat it in batterij hawwe. Minsken keapje RAID mei goede cache sûnder batterij. As jo SSD's hawwe yn RAID, dan moatte se tsjinner wêze, d'r moatte kondensatoren wêze. Hjir is in detaillearre checklist. Dizze keppeling befettet myn rapport oer hoe't jo in prestaasjeskiif yn PostgreSQL konfigurearje. Der binne al dizze checklists dêr.
Wat oars kin meitsje it libben hiel dreech? Dit binne twa parameters. Se binne relatyf nij. Standert kinne se opnommen wurde yn ferskate applikaasjes. En se kinne it libben like dreech meitsje as se ferkeard ynskeakele wurde.
Der binne twa relatyf nije dingen. Se hawwe al ferskynd yn de tredde kearnen. Dit is sched_migration_cost yn nanosekonden en sched_autogroup_enabled, dat is ien standert.
En hoe ferneatigje se jo libben? Wat is sched_migration_cost? Op Linux kin de planner in proses fan de iene CPU nei de oare migrearje. En foar PostgreSQL, dy't queries útfiert, is it migrearjen nei in oare CPU folslein ûndúdlik. Ut in bestjoeringssysteem eachpunt, as jo wikselje finsters tusken openoffice en terminal, dit kin wêze goed, mar foar in databank dit is hiel min. Dêrom is in ridlik belied om migration_cost te setten op wat grutte wearde, op syn minst ferskate tûzen nanosekonden.
Wat sil dit betsjutte foar planner? It sil beskôge wurde dat yn dizze tiid it proses noch heul is. Dat is, as jo in langrinnende transaksje hawwe dy't in lange tiid wat dien hat, sil de planner dit begripe. Hy sil oannimme dat oant dizze time-out foarby is, d'r gjin need is om dit proses oeral te migrearjen. As it proses tagelyk wat docht, dan sil it net oeral wurde migrearre, it sil rêstich wurkje op 'e CPU dy't deroan is tawiisd. En it resultaat is poerbêst.
It twadde punt is autogroup. D'r is in goed idee foar spesifike workloads dy't net relatearre binne oan moderne databases - dit is om prosessen te groepearjen troch de firtuele terminal wêrfan se wurde lansearre. Dit is handich foar guon taken. Yn 'e praktyk is PostgreSQL in multi-proses systeem mei in prefork dy't rint fan ien terminal. Jo hawwe in slot skriuwer, checkpoint, en al jo klant fersiken sille wurde groepearre yn ien planner, per CPU. En se sille dêr ienriedich wachtsje oant er frij is, om inoar te bemuoien en him langer dwaande te hâlden. Dit is in ferhaal dat by sa'n lading hielendal net nedich is en dêrom útskeakele wurde moat.
Myn kollega Alexey Lesovsky die tests mei in ienfâldige pgbench, dêr't hy fergrutte migration_cost mei in folchoarder fan grutte en útskeakele autogroup. It ferskil op minne hardware wie hast 10%. D'r is in diskusje oer de postgres-mailinglist wêr't minsken resultaten jouwe fan ferlykbere feroarings oan query-snelheid beynfloede 50%. Der binne nochal in soad fan sokke ferhalen.
En as lêste, oer enerzjybesparringsbelied. It goede ding is dat Linux no kin wurde brûkt op in laptop. En it sil nei alle gedachten de batterij goed brûke. Mar ynienen docht bliken dat dit ek op de server kin.
Boppedat, as jo tsjinners hiere fan guon hoster, dan kinne de "goede" hosters net skele dat jo bettere prestaasjes hawwe. Harren taak is om te soargjen dat har izer sa effisjint mooglik brûkt wurdt. Dêrom kinne se standert laptop enerzjybesparjende modus ynskeakelje op it bestjoeringssysteem.
As jo dit guod brûke op in tsjinner mei in databank ûnder swiere lading, dan is jo kar acpi_cpufreq + permormance. Sels mei ondemand sille d'r problemen wêze.
Intel_pstate is in wat oare bestjoerder. En no wurdt dizze foarkar jûn, sa't it letter is en better wurket.
En, dêrom, gûverneur is allinnich prestaasje. Ondemand, powersave en al it oare giet net oer jo.
De resultaten fan ferklearje analysearje PostgreSQL kinne ferskille mei ferskate oarders fan grutte as jo enerzjybesparring ynskeakelje, om't praktysk de CPU ûnder jo databank op in folslein ûnfoarspelbere manier sil rinne.
Dizze items kinne standert wurde opnommen. Sjoch foarsichtich om te sjen oft se it standert ynskeakele hawwe. Dit kin in echt grut probleem wêze.
En op it lêst woe ik tank sizze oan 'e jonges fan ús PosgreSQL-Consulting DBA-team, nammentlik Max Boguk en Alexey Lesovsky, dy't elke dei foarút meitsje yn dizze saak. En wy besykje it bêste te dwaan foar ús kliïnten, sadat it allegear foar har wurket. It is lykas mei ynstruksjes foar loftfeartfeiligens. Alles is hjir yn bloed skreaun. Elk fan dizze nuten wurdt fûn yn it proses fan in soarte fan probleem. Ik bin bliid om se mei jo te dielen.
Fragen:
Dankewol! As bygelyks in bedriuw jild besparje wol en de database en applikaasjelogika op ien server pleatse, of as it bedriuw de modieuze trend fan mikroservicearsjitektueren folget, wêryn PostgreSQL yn in kontener rint. Wat is de trúk? Sysctl sil de hiele kernel wrâldwiid beynfloedzje. Ik haw net heard fan sysctls dy't op ien of oare manier virtualisearre binne, sadat se apart wurkje op in kontener. D'r is mar in cgroup en d'r is mar in diel fan 'e kontrôle dêr. Hoe kinne jo libje mei dit? Of as jo prestaasjes wolle, rinne dan PostgreSQL op in aparte hardware-tsjinner en ôfstimme it?
Wy hawwe jo fraach op sawat trije manieren beäntwurde. As wy it net hawwe oer in hardware-tsjinner dy't kin wurde ôfstimd, ensfh., ûntspanne dan, alles sil goed wurkje sûnder dizze ynstellingen. As jo sa'n lading hawwe dat jo dizze ynstellings moatte meitsje, dan komme jo earder nei de izeren tsjinner dan nei dizze ynstellingen.
Wat is it probleem? As dit in firtuele masine is, dan sille jo wierskynlik in protte problemen hawwe, bygelyks mei it feit dat op 'e measte firtuele masines de latency fan' e skiif frijwat inkonsistint is. Sels as de skiif trochfier is goed, dan ien mislearre I / O transaksje dy't gjin grutte ynfloed op de trochsneed trochslach dy't barde op it momint fan checkpoint of op it momint fan skriuwen nei WAL, dan sil de databank gâns lêst fan dit. En jo sille dit fernimme foardat jo dizze problemen tsjinkomme.
As jo NGINX op deselde tsjinner hawwe, sille jo ek itselde probleem hawwe. Hy sil fjochtsje foar dielde ûnthâld. En jo sille net komme ta de problemen beskreaun hjir.
Mar oan 'e oare kant sille guon fan dizze parameters noch altyd relevant wêze foar jo. Stel bygelyks dirty_ratio yn mei sysctl sadat it net sa gek is - yn alle gefallen sil dit helpe. Op ien of oare manier sille jo ynteraksje hawwe mei de skiif. En it sil wêze neffens it ferkearde patroan. Dit is oer it algemien in standert foar de parameters dy't ik sjen litten. En yn alle gefallen is it better om se te feroarjen.
Mar d'r kinne problemen wêze mei NUMA. VmWare, bygelyks, wurket goed mei NUMA mei krekt de tsjinoerstelde ynstellings. En hjir moatte jo kieze - in izeren server as in net-izeren.
Ik haw in fraach yn ferbân mei Amazon AWS. Se hawwe ôfbyldings foarôf ynsteld. Ien fan harren hjit Amazon RDS. Binne d'r oanpaste ynstellings foar har bestjoeringssysteem?
Der binne ynstellings dêr, mar se binne ferskillende ynstellings. Hjir konfigurearje wy it bestjoeringssysteem yn termen fan hoe't de databank dit ding sil brûke. En d'r binne parameters dy't bepale wêr't wy no hinne moatte, lykas foarmjouwing. Dat is, wy hawwe safolle middels nedich, wy sille se no opfrette. Hjirnei fersterket Amazon RDS dizze boarnen, en de prestaasjes sakje dêr. D'r binne yndividuele ferhalen oer hoe't minsken mei dizze saak begjinne te rommeljen. Soms sels frij suksesfol. Mar dit hat neat te krijen mei OS-ynstellingen. It is as it hacken fan 'e wolk. Dat is in oar ferhaal.
Wêrom hat Transparante enoarme siden gjin effekt yn ferliking mei Huge TLB?
Net jaan. Dit kin op in protte manieren ferklearre wurde. Mar feitlik jouwe se it gewoan net. Wat is de skiednis fan PostgreSQL? By it opstarten jout it in grut stik dielde ûnthâld ta. Oft se transparant binne of net is folslein irrelevant. Dat se oan it begjin opfalle, ferklearret alles. En as d'r in protte ûnthâld is en jo it shared_memory-segment opnij moatte opbouwe, dan sille Transparante enoarme siden relevant wêze. Yn PostgreSQL wurdt it gewoan oan it begjin yn in enoarme brok tawiisd en dat is it, en dan bart der neat spesjaal. Jo kinne it fansels brûke, mar d'r is in kâns om in korrupsje fan shared_memory te krijen as it wat opnij allocearret. PostgreSQL wit dit net.
Boarne: www.habr.com