serveril<\/a> ja k\u00f5ik see j\u00f5uab l\u00f5puks SATA k\u00f5vakettale ilma igasuguse vahem\u00e4luta, siis muutub kogu andmebaasiserver mitte ainult k\u00f5rvitsaks, vaid k\u00f5rvitsaks SATA liidesega. Te peate sellega otse kokku puutuma. Ja miski ei p\u00e4\u00e4sta teid sellest.<\/p>\n<\/p>\n
<\/p>\n
Esimese punkti osas m\u00e4lust on kolm asja, mis v\u00f5ivad elu oluliselt raskendada. <\/p>\n
<\/p>\n
Esimene neist on NUMA. NUMA on s\u00fcsteem, mis on loodud tulemuslikkuse parandamiseks. s\u00f5ltuvalt t\u00f6\u00f6koormusest saab erinevaid asju optimeerida. Ja oma praeguses vormis ei ole see andmebaasi rakenduste jaoks, mis kasutavad intensiivselt lehek\u00fclje vahem\u00e4lu ja jagatud puhvreid, just eriti kasulik. <\/p>\n
<\/p>\n
<\/p>\n
Kahe s\u00f5naga. Kuidas m\u00f5ista, et NUMA-ga on midagi valesti? Teil on ebamugav m\u00fcra, \u00e4kki avastate, et m\u00f5ni CPU on \u00fclekoormatud. Samas anal\u00fc\u00fcsite PostgreSQL-i p\u00e4ringuid ja n\u00e4ete, et seal pole midagi sellist. Need p\u00e4ringud ei tohiks CPU-d nii intensiivselt koormata. Sellist olukorda on kaua raske tabada. Lihtsam on algusest peale kasutada \u00f5iget soovitust NUMA seadistamiseks PostgreSQL jaoks.<\/p>\n
<\/p>\n
<\/p>\n
Mis tegelikult toimub? NUMA on Non-Uniform Memory Access. Mis on selle m\u00f5te? Teil on CPU, mille l\u00e4heduses on tema kohaliku m\u00e4lu. Ja see m\u00e4lu interconnects v\u00f5ib tuua m\u00e4lu teistelt CPU-delt.<\/p>\n
<\/p>\n
Kui k\u00e4ivitate numactl --hardware<\/code>, siis n\u00e4ete suurt v\u00e4ljatr\u00fckki. Muuhulgas on seal ka kauguste v\u00e4li. Seal on numbrid - 10-20, midagi sellist. Need numbrid on \u00fcksnes h\u00fcpetega, et seda kauget m\u00e4lu \u00fchenduda ja kohalikult kasutada. \u00dcldiselt on see hea idee. See kiirendab t\u00f5husust teatud koormuste puhul.<\/p>\n<\/p>\n
Kujutage n\u00fc\u00fcd ette, et teil on \u00fcks CPU, mis esmalt proovib kasutada oma lokaalset m\u00e4lu ja seej\u00e4rel p\u00fc\u00fcab interconnect'i kaudu t\u00f5mmata teist m\u00e4lu millegi jaoks. Ja k\u00f5ik teie PostgreSQL page cache'i mahud j\u00f5uavad selle CPU-ni \u2013 paar gigabaiti. Te saate alati halva tulemuse, sest selle m\u00e4lu mooduli kohta on CPU-s tavaliselt v\u00e4he m\u00e4lurubit. Ja kogu m\u00e4lu, mida teenindatakse, liigub l\u00e4bi nende interconnect'ide. Tulemuseks on aeglane ja kurb olukord. Teie protsessor, mis teenindab seda s\u00f5lme, on pidevalt \u00fcle koormatud. Ja selle m\u00e4lu ligip\u00e4\u00e4su aeg \u2013 halb ja aeglane. See on olukord, mida te ei soovi, kui kasutate seda andmebaasi jaoks. <\/p>\n
<\/p>\n
Seet\u00f5ttu on andmebaasi jaoks \u00f5igem lahendus, et Linuxi operatsioonis\u00fcsteem ei teaks \u00fcldse, mis toimub. Et ta k\u00e4sitleks m\u00e4lu sama moodi nagu tavaliselt. <\/p>\n
<\/p>\n
Miks on nii? Tundub, et peaks olema vastupidi. See juhtub \u00fchel lihtsal p\u00f5hjusel \u2013 me vajame page cache'i jaoks palju m\u00e4lu \u2013 k\u00fcmneid, sadu gigabaiti. <\/p>\n
<\/p>\n
Ja kui me oleme k\u00f5ik need andmed v\u00e4lja t\u00f5stnud ja vahem\u00e4cacheerinud, siis kasu vahem\u00e4cacheerimise kasutamisest on m\u00e4rkimisv\u00e4\u00e4rselt suurem kui sellisest nutikast m\u00e4luhaldusest saadud kasu. Nii saavutame me v\u00f5idu, mis ei ole v\u00f5rreldav selle uue m\u00e4luhaldurimeetodi t\u00f5husama rakendamisega NUMA abil.<\/p>\n
<\/p>\n
Teisest k\u00fcljest on sel hetkel kaks l\u00e4henemist, kuni helge tulevik saabub ja andmebaas oskab ise aru saada, millistel CPU-del ta t\u00f6\u00f6tab ja kust tal midagi t\u00f5mmata on vaja. <\/p>\n
<\/p>\n
<\/p>\n
Seega on \u00f5ige l\u00e4henemine NUMA t\u00e4ielik v\u00e4ljal\u00fclitamine.<\/strong>, n\u00e4iteks taask\u00e4ivitamisel. Enamasti on kasu nii suur, et pole \u00fcldse k\u00fcsimust, kuidas paremini toimida. <\/p>\n<\/p>\n
On olemas teine variant. Me kasutame seda tihedamini kui esimest, kuna kui klient meie tugiteenusele tuleb, on serveri taask\u00e4ivitamine tema jaoks suur probleem. Tal on seal \u00e4ri k\u00e4imas. Ja NUMA probleemide t\u00f5ttu nad kannatavad. Seet\u00f5ttu p\u00fc\u00fcame v\u00e4hem invasiivsete meetoditega v\u00e4lja l\u00fclitada, kui taask\u00e4ivitamine, kuid siin tuleb ettevaatlikult kontrollida, et see t\u00f5esti v\u00e4lja l\u00fclitus. Kuna kogemus n\u00e4itab, et kui me v\u00e4lja l\u00fclitame vanema PostgreSQL NUMA protsessi, siis see on hea, kuid pole sugugi kindel, et see t\u00f6\u00f6tab. Tuleb kontrollida ja vaadata, et see t\u00f5epoolest v\u00e4lja l\u00fclitus. <\/p>\n
<\/p>\n
On olemas hea postitus Robert Haasilt. Ta on \u00fcks PostgreSQL-i arendajatest. \u00dcks v\u00f5tme arendaja k\u00f5igist madalate tasemete t\u00f6\u00f6riistadest. Ja kui selle postituse linkide kaudu edasi liikuda, siis seal on mitmeid v\u00e4rvikaid lugusid selle kohta, kuidas NUMA inimese elu keerulisemaks tegi. Vaadake, uurige s\u00fcsteemiadministraatorite kontrollnimekirja, mida serveris seadistada, et meie andmebaas h\u00e4sti t\u00f6\u00f6taks. Need seadistused tuleb \u00fcles kirjutada ja kontrollida, sest muidu ei ole asjad head. <\/p>\n
<\/p>\n
M\u00e4rgin \u00e4ra, et see kehtib k\u00f5ikide seadistuste kohta, millest ma r\u00e4\u00e4gin. Kuid tavaliselt kogutakse andmebaase master-slave re\u017eiimis, et tagada t\u00f5rketaluvus. \u00c4rge unustage neid seadistusi slave'ile teha, sest \u00fchel hetkel v\u00f5ib teil juhtuda \u00f5nnetus, te l\u00fclitate \u00fcle slave'ile ja see saab masteriks. <\/p>\n
<\/p>\n
Kriitilises olukorras, kui k\u00f5ik on v\u00e4ga halvasti, heliseb teie telefon pidevalt ja \u00fclemus jookseb kohale suures k\u00e4es, teil pole aega m\u00f5elda, et kontrollida. Ja tulemused v\u00f5ivad olla v\u00e4ga kahetsusv\u00e4\u00e4rsed.<\/p>\n
<\/p>\n
<\/p>\n
J \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0438\u0439 \u043c\u043e\u043c\u0435\u043d\u0442 \u2013 \u044d\u0442\u043e huge pages. Huge pages on keeruline eraldi testida, ega sellel pole m\u00f5tet, kuigi on b\u00e4nkm\u00e4rgid, mis oskavad seda teha. Need on kergesti \u00fclesleitavad. <\/p>\n
<\/p>\n
Mis m\u00f5te on? Teil on mitte v\u00e4ga kallis server, millel on palju RAMi, n\u00e4iteks rohkem kui 30 GB. Te ei kasuta huge pages. See t\u00e4hendab, et teil on kindlasti m\u00e4lukasutuse \u00fclekatte. Ja see \u00fclekaal ei ole sugugi meeldiv. <\/p>\n
<\/p>\n
<\/p>\n
Miks nii on? Mis toimub? Operatsioonis\u00fcsteem eraldab m\u00e4lu v\u00e4ikeste t\u00fckkidena. See on mugav ja nii on ajalooliselt kujunenud. Kui vaadata s\u00fcgavamale, peab OS t\u00f5lkima virtuaalsed aadressid f\u00fc\u00fcsilisteks. See ei ole k\u00f5ige lihtsam protsess, mist\u00f5ttu OS talletab selle operatsiooni tulemuse Translation Lookaside Buffer (TLB) m\u00e4llu.<\/p>\n
<\/p>\n
Kuna TLB on vahem\u00e4lu, siis sellises olukorras tekivad k\u00f5ik vahem\u00e4lu probleemid. Esiteks, kui teil on v\u00e4ga palju raamatu m\u00e4lu ja see on k\u00f5ik jaotatud v\u00e4ikesteks t\u00fckkideks, siis muutub see vahem\u00e4lu v\u00e4ga suureks. Ja kui vahem\u00e4lu on suur, siis on selle otsimine aeglasem. \u00dcksus on suur ja see ise tarvitab ruumi, st. midagi vale kasutab operatiivm\u00e4lu. See on esimene asi. <\/p>\n
<\/p>\n
Teiseks, mida suuremaks kasvab vahem\u00e4lu, seda t\u00f5en\u00e4olisem on, et teil tekivad vahem\u00e4lu tabamised (cache misses). Ja selle vahem\u00e4lu efektiivsus langeb kiiresti koos selle suuruse kasvuga. Seet\u00f5ttu on operatsioonis\u00fcsteemides v\u00e4lja t\u00f6\u00f6tatud lihtne l\u00e4henemine. Linuxis on see juba ammu kasutusel. FreeBSD-s ilmus see mitte nii kaua aega tagasi. Kuid me r\u00e4\u00e4gime samuti Linuxist. See on huge pages.<\/p>\n
<\/p>\n
Siin tuleb m\u00e4rkida, et huge pages, kui idee, sai algselt propageeritud kogukondade poolt, kuhu kuulusid Oracle ja IBM, st andmebaasi tootjad m\u00f5tlesid t\u00f5siselt, et see tuleb kasuks, sealhulgas andmebaasidele. <\/p>\n
<\/p>\n
<\/p>\n
Kuidas neid PostgreSQL'iga koosk\u00f5lastada? Esiteks peavad Linuxi tuumas olema sisse l\u00fclitatud huge pages.<\/p>\n
<\/p>\n
Teiseks peavad need olema selgelt m\u00e4\u00e4ratletud sysctl parameetriga \u2013 kui palju neid on. Numbrid on siin m\u00f5nelt vanalt serverilt. Saate arvutada, kui palju teie shared buffers ligikaudu on, et huge pages sinna sisse mahuks. <\/p>\n
<\/p>\n
Ja kui kogu server on p\u00fchendatud PostgreSQL'ile, siis hea l\u00e4htepunkt on kas 25% RAM-ist jagada shared buffersi jaoks v\u00f5i 75%, kui olete kindel, et teie andmebaas mahtus kindlasti sellesse 75%. See on esimene l\u00e4htepunkt. Ja arvutage, kui teil on 256 GB RAM-i, siis vastavalt on 64 GB teie shared bufferseid. Arvutage see m\u00f5ningase varuga \u2013 mis numbriks peaks see olema seatud.<\/p>\n
<\/p>\n
Versioonis 9.2 (kui ma ei eksi, alates versioonist 8.2) oli v\u00f5imalik PostgreSQL \u00fchendada huge pages'i abil kolmanda osapoole teegi kaudu. Seda on alati vajalik teha. Esiteks peab tuuma suudma \u00f5igesti jaotada huge pages'e. Teiseks peab rakendus, mis nendega t\u00f6\u00f6tab, olema suuteline neid kasutama. Muul juhul nad ei t\u00f6\u00f6ta. Kuna PostgreSQL jagas m\u00e4lu system 5 stiilis, oli selleks v\u00f5imalik kasutada libhugetlbfs'i \u2014 see on teegi t\u00e4isnimi.<\/p>\n
<\/p>\n
Versioonis 9.3 parandati PostgreSQL-i j\u00f5udlust m\u00e4lu haldamisel ja loobuti system 5 m\u00e4lu jaotamise meetodist. K\u00f5ik olid v\u00e4ga \u00f5nnelikud, sest muidu proovid k\u00e4ivitada kahte PostgreSQL'i eksemplari \u00fchel masinal, ja ta \u00fctleb, et mul pole jagatud m\u00e4lu piisavalt. Ja \u00fctleb, et sysctl'i tuleb parandada. Seal on selline sysctl, et tuleb veel taask\u00e4ivitada jms. \u00dches\u00f5naga, k\u00f5ik r\u00f5\u00f5mustasid. Kuid m\u00e4luhalduse mmap rikkus huge pages'i kasutamise. Enamik meie kliente kasutab suuremaid jagatud puufe. Ja me soovisime tungivalt, et nad ei \u00fcleminekuks versioonile 9.3, sest seal algas overhead m\u00e4rkimisv\u00e4\u00e4rselt kasvama.<\/p>\n
<\/p>\n
Kuid siiski p\u00f6\u00f6rdus community selle probleemi poole ja 9.4 versioonis tehti sellele \u00fcritusele v\u00e4ga head muudatused. Samuti ilmus 9.4-s postgresql.conf failis parameeter, millega saab aktiveerida try, on v\u00f5i off.<\/p>\n
<\/p>\n
Try on k\u00f5ige ohutum parameeter. PostgreSQL-i k\u00e4ivitamisel, kui see eraldab jagatud m\u00e4lu, \u00fcritab ta saada m\u00e4lumahtu huge pages\u2019ist. Ja kui see ei \u00f5nnestu, siis kukub tagasi tavalisse eraldamisse. Ja kui teil on FreeBSD v\u00f5i Solaris, siis v\u00f5ite kasutada try-d, see on alati ohutu. <\/p>\n
<\/p>\n
Kui on, siis see lihtsalt ei k\u00e4ivitu, kui ei suuda huge pages\u2019ist eraldada. Siin on juba see, mis kellelegi sobib. Kuid kui teil on try, siis kontrollige, et teil on t\u00f5eliselt vajalik m\u00e4lu eraldatud, sest seal on palju vigu. Praegu t\u00f6\u00f6tab see funktsionaalsus ainult Linuxis.<\/p>\n
<\/p>\n
Veel \u00fcks v\u00e4ike m\u00e4rkus, enne kui edasi liigume. Transparent huge pages ei kehti PostgreSQL jaoks praegu. Ta ei saa neid normaalselt kasutada. Ja Transparent huge pages puhul sellise t\u00f6\u00f6koormuse korral, kus vajatakse suurt osa jagatud m\u00e4lu, toovad kasu ainult v\u00e4ga suurte mahtude korral. Kui teil on terabaite m\u00e4lu, siis v\u00f5ib see m\u00e4ngida rolli. Kui r\u00e4\u00e4gime tavalisematest rakendustest, kus teil on masinas 32, 64, 128, 256 GB m\u00e4lu, on tavalised huge pages t\u00e4iesti piisavad, ning Transparent lihtsalt keelame. <\/p>\n
<\/p>\n
<\/p>\n
Ja viimane asi, mis on seotud m\u00e4luga, ei ole otseselt seotud l\u00e4bilaskev\u00f5imega, kuid v\u00f5ib elu v\u00e4ga keeruliseks teha. Kogu l\u00e4bilaskev\u00f5ime kannatab t\u00f5siselt, kui server pidevalt vahetab. <\/p>\n
<\/p>\n
Ja ja see toob kaasa mitmeid ebamugavusi. Peamine probleem seisneb selles, et t\u00e4nap\u00e4evaste kernide k\u00e4itumine erineb natuke vanematest Linuxi kernidest. See on asi, millele astuda on \u00fcsna ebameeldiv, sest kui me r\u00e4\u00e4gime swap'iga t\u00f6\u00f6tamisest, l\u00f5ppeb see mitte \u00f5igeaegse OOM-killer'i saabumisega. Ja OOM-killer, kes ei saabu \u00f5igel ajal ja kutsub PostgreSQL-i kokku kukkuma, on ebameeldiv. Sellest saavad teada k\u00f5ik, st viimase kasutajani. <\/p>\n
<\/p>\n
<\/p>\n
Mis toimub? Teie serveris on suur hulk RAMi ja k\u00f5ik t\u00f6\u00f6tab h\u00e4sti. Kuid mingil p\u00f5hjusel seisab server swap'is ja aeglustub seet\u00f5ttu. Tundub, et m\u00e4lu on palju, aga see juhtub siiski. <\/p>\n
<\/p>\n
<\/p>\n
Varem soovitasime vm.swappiness seada nulli, st swap v\u00e4lja l\u00fclitada. Varem tundus, et 32 GB RAM ja vastavad jagatud pu Buffers on tohutu hulk. Swap'i peamine eesm\u00e4rk on lihtsalt saata kernel kuhugi, kui meil on probleem. Ja see polnud enam eriti vajalik. Ja siis, mida sa selle keregiga teed? See on juba selline \u00fclesanne, kus pole eriti selge, miks swap sellise suurusega vajalik on. <\/p>\n
<\/p>\n
Kuid kaasaegsetes, st kolmandates tuumaversioonides on k\u00e4itumine muutunud. Ja kui seadistada swap nulliks, st v\u00e4lja l\u00fclitada, siis varem v\u00f5i hiljem hakkab isegi v\u00e4ikese m\u00e4lusisalduse juures OOM-killer teie juurde tulema, et k\u00f5rvaldada k\u00f5ige intensiivsemad m\u00e4lukasutajad. Ta arvab, et sellise koormuse korral on meil veel v\u00e4he ja me l\u00e4heme \u00fcle, st mitte s\u00fcsteemi protsessi tappa, vaid tappa midagi v\u00e4hem t\u00e4htsat. Selleks v\u00e4hem oluliseks osutub intensiivne jagatud m\u00e4lu kasutaja, nimelt postmaster. Ja peale seda on hea, kui andmebaasi ei pea taastama. <\/p>\n
<\/p>\n
Seet\u00f5ttu on n\u00fc\u00fcd vaikes\u00e4tteid, kui ma \u00f5igesti m\u00e4letan, enamus distributsioonides umbes 6, st millal hakata swap-i kasutama s\u00f5ltuvalt sellest, kui palju m\u00e4lu on j\u00e4\u00e4nud. K\u00e4esoleval hetkel soovitame seadistada vm.swappiness = 1, sest see praktiliselt l\u00fclitab selle v\u00e4lja, kuid ei p\u00f5hjusta selliseid efekte, nagu ootamatult saabunud OOM-killer, kes k\u00f5ik need asjad k\u00f5rvaldada.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Mis edasi? Kui r\u00e4\u00e4gime andmebaaside j\u00f5udlusest ja j\u00e4rk-j\u00e4rgult liigume ketaste poole, hakkavad k\u00f5ik pead kinni haarama. Sest t\u00f5de, et ketas on aeglane ja m\u00e4lu kiire, on k\u00f5igile lapsest peale tuttav. Ja k\u00f5ik teavad, et andmebaasis on ketta j\u00f5udluse probleemid.<\/p>\n
<\/p>\n
Peamine PostgreSQL-i j\u00f5udluse probleem, mis on seotud checkpoints'i t\u00f5usudega, ei tulene sellest, et ketas on aeglane. Pigem on see tingitud sellest, et m\u00e4lu ja ketta l\u00e4bilaskev\u00f5ime ei ole tasakaalus. Samuti v\u00f5ivad need olla tasakaalus eri kohtades. PostgreSQL ei ole seadistatud, operatsioonis\u00fcsteem ei ole seadistatud, riistvara ei ole seadistatud ja riistvara on vale. Seda probleemi ei tekki ainult siis, kui k\u00f5ik toimub nii nagu peab, st kas koormust ei ole v\u00f5i seadistused ja riistvara on h\u00e4sti valitud. <\/p>\n
<\/p>\n
<\/p>\n
Mis see on ja kuidas see v\u00e4lja n\u00e4eb? Tavaline on, et inimesed, kes t\u00f6\u00f6tavad PostgreSQL-iga, on sellesse protsessi korduvalt astunud. Selgitaksin. Nagu ma \u00fctlesin, teeb PostgreSQL perioodiliselt checkpoint'e, et m\u00e4\u00e4rdunud lehed jagatud m\u00e4lust kettale salvestada. Kui meil on suur jagatud m\u00e4lu maht, hakkab checkpoint intensiivselt kettale m\u00f5juma, sest see salvestab need lehed fsync'i kaudu. Need j\u00f5uavad kernel'i puutasse ja kirjutatakse kettale fsync'i abil. Ja kui selle protsessi maht on suur, v\u00f5ime t\u00e4heldada ebameeldivat efekti, nimelt v\u00e4ga suurt kettakasutust.<\/p>\n
<\/p>\n
Siin on mul kaks pilti. Selgitan n\u00fc\u00fcd, mis need on. Need on kaks ajaliselt korreleeritud graafikut. Esimene graafik \u2013 see on kettakasutus. Siin ulatub see peaaegu 90%-ni antud hetkel. Kui teie andmebaasil on f\u00fc\u00fcsilised kettad ja RAID-kontrolleri kettakasutus on 90% ulatuses, siis on see halvad uudised. See t\u00e4hendab, et veel natuke ja j\u00f5uame 100% ja sisendi-v\u00e4ljundi protsess peatus. <\/p>\n
<\/p>\n
Kui teil on kettamassiiv, siis seal on lugu natuke erinev. Seal s\u00f5ltub see sellest, kuidas see on seadistatud, milline massiiv see on jne. <\/p>\n
<\/p>\n
Siin on samal ajal konfigureeritud graafik sisemisest postgres'i vaatepunktist, mis n\u00e4itab, kuidas kontrollpunkt toimub. Roheline v\u00e4rv n\u00e4itab, kui palju puhverdusi, neid m\u00e4\u00e4rdunud lehti, on sellel hetkel kontrollpunktis s\u00fcnkroniseerimiseks saabunud. See on peamine, mida siin on vaja teada. N\u00e4eme, et meil on siin palju lehti saabunud ja mingil hetkel t\u00f5ukame piiri, st kirjutame-kirjutanud, siin on selgelt kett s\u00fcsteem v\u00e4ga h\u00f5ivatud. Kontrollpunkt m\u00f5jutab diskimist tugevalt. Ideaalis peaks olukord v\u00e4lja n\u00e4gema pigem nii, et meil oleks siin v\u00e4hem kirjutamist. Saame seadistustega seda parandada, et tulevikus nii oleks. St madal kasutamine, kuid midagi me siin kirjutame. <\/p>\n
<\/p>\n
Mida teha, et selle probleemi v\u00f5ita? Kui teie andmebaasi all IO peatub, t\u00e4hendab see, et k\u00f5ik kasutajad, kes tulid oma p\u00e4ringute t\u00e4itmiseks, peavad ootama. <\/p>\n
<\/p>\n
<\/p>\n
Kui vaadata Linuxi perspektiivist, siis kui oled v\u00f5tnud hea riistvara, seadisti selle \u00f5igesti ning seadisti PostgreSQL nii, et ta teeks checkpoint'e harvemini, lahutades need ajas \u00fcksteisest, siis satud debiani vaikes\u00e4tetele. Enamikus Linuxi distributsioonides on selline pilt: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
Mida see t\u00e4hendab? Alates tuumast 2.6 ilmus \u00fcks daemon andmete eemaldamiseks. Pdglush s\u00f5ltuvalt sellest, kes mida kasutab, tegeleb ta t\u00f6\u00f6keskkonnas mustade lehtede eemaldamisega kernel-buffersist ja eemaldamisega, kui tuleb igal juhul mustade lehtede eemaldamine, kui juba taustal toimub eemaldamine ei aita. <\/p>\n
<\/p>\n
Millal toimub taustaline tegevus? Kui 10% kogu serveri RAM-st on h\u00f5ivatud mustade lehtedega kernel-bufferis, siis kutsutakse esile eriline funktsioon taustal eemaldamiseks. Miks see on taustaline? Ta v\u00f5tab parameetrina, kui palju lehti eemaldada. Ja \u00fctleme, et eemaldab N lehte. Ja m\u00f5neks ajaks see asi uinub. Siis tuleb see j\u00e4lle tagasi ja eemaldab veel mingi arvu lehti. <\/p>\n
<\/p>\n
See on \u00fclimalt lihtne lugu. Siin on \u00fclesanne nagu basseiniga, kus \u00fchte toru valatakse, \u00fchest torust voolab v\u00e4lja. Meil on checkpoint ja kui ta on saatnud liiga v\u00e4he m\u00e4\u00e4rdunud lehti \u00e4raviskamiseks, siis need hakkavad j\u00e4rk-j\u00e4rgult kernel bufferist pgflush'ist kenasti laiali minema. <\/p>\n
<\/p>\n
Kui need m\u00e4\u00e4rdunud lehed j\u00e4tkavad kogunemist, kogunevad nad 20%-ni, siis on operatsioonis\u00fcsteemil prioriteet need kirjutada kettale, sest toide v\u00f5ib katkeda ja siis on meil k\u00f5ik halvasti. Kaotame need andmed, n\u00e4iteks. <\/p>\n
<\/p>\n
Mis on trikk? Trikk seisneb selles, et need parameetrid, 20% ja 10% kogu masina operatiivm\u00e4lu kohta, on t\u00e4iesti uskumatu diskis\u00fcsteemi l\u00e4bilaskev\u00f5ime seisukohast.<\/strong> <\/p>\n<\/p>\n
Kujutage ette, et teil on 128 GB operatiivm\u00e4lu. 12,8 GB j\u00f5uab teie kettas\u00fcsteemi. Ja s\u00f5ltumata sellest, milline vahem\u00e4lu teil seal on, ei talu nad nii palju. <\/p>\n
<\/p>\n
<\/p>\n
Seet\u00f5ttu soovitame need numbrid seadistada kohe vastavalt teie RAID-kontrolleri v\u00f5imalustele.<\/strong> Mul on siin kohe soovitus kontrolleriga, millel on 512 MB vahem\u00e4lu. <\/p>\n<\/p>\n
K\u00f5ik on v\u00e4ga lihtne. Saate vm.dirty_background m\u00e4\u00e4rata baitides. Need seaded t\u00fchistavad kaks eelnevat. Kas vaikimisi ratio v\u00f5i kui aktiveeritud on need, mis on baitides, siis on need, mis on baitides, j\u00f5us. Kuna olen DBA-n\u00f5ustaja ja t\u00f6\u00f6tan erinevate klientidega, p\u00fc\u00fcan ma ettevaatlik olla, seega, kui baitides, siis baitides. Keegi ei andnud mingit garantiid, et hea administraator ei lisa serverile m\u00e4lu, ei taask\u00e4ivita seda ja number j\u00e4\u00e4b samaks. Lihtsalt arvutage need numbrid nii, et k\u00f5ik mahuks kindlasti sisse. <\/p>\n
<\/p>\n
Mida juhtub, kui te ei pressi? Olen kuulnud, et iga flushimine peatutakse t\u00f5husalt, kuid tegelikult on see k\u00f5igest kujundlik v\u00e4ljend. Ops\u00fcsteem on suure probleemi keskel \u2013 tal on liiga palju m\u00e4\u00e4rdunud lehti, seega t\u00f5husalt peatatakse IO, mis on teie klientide p\u00e4ringutest tulenev, st kui rakendus saatis SQL-p\u00e4ringu andmebaasile, ootab see. K\u00f5ik sisend-v\u00e4ljund, mis sinna j\u00f5uab, on madalaima prioriteediga, kuna andmebaas on kinni checkpoin'is. Ja kui see valmis saab, on t\u00e4iesti arusaamatu. Ja kui olete j\u00f5udnud mitte-taustal, mitte-bakgrep flushimiseni, t\u00e4hendab see, et k\u00f5ik teie IO on sellega h\u00f5ivatud. Ja kuni see pole l\u00f5petatud, ei saa te midagi teha. <\/p>\n
<\/p>\n
Siin on veel kaks olulist punkti, mis j\u00e4\u00e4vad sellest aruandest v\u00e4ljapoole. Need seaded peavad vastama postgresql.conf seadetele, st checkpoint seaded. Ja teie kettas\u00fcsteem peab olema n\u00f5uetekohaselt konfigureeritud. Kui teil on RAID-i peal vahem\u00e4lu, peab sellel olema patarei.<\/strong> Inimesed ostavad RAID-i hea vahem\u00e4luga ilma patareita. Kui teil on RAID-is SSD-d, peavad need olema serveri SSD-d, seal peavad olema kondensaatorid.<\/strong> Siin on p\u00f5hjalik kontrollnimekiri. Selle lingi kaudu leiate minu ettekande kohtlemise seadistamisest PostgreSQL-is. Seal on k\u00f5ik need kontrollnimekirjad. <\/p>\n<\/p>\n
<\/p>\n
Mis veel v\u00e4ga palju elu keeruliseks v\u00f5ib teha? Need on kaks parameetrit. Need on suhteliselt uued. Need v\u00f5ivad vaikimisi olla sisse l\u00fclitatud erinevates rakendustes. Ja need v\u00f5ivad elu keeruliseks teha sama palju, kui need on valesti sisse l\u00fclitatud. <\/p>\n
<\/p>\n
<\/p>\n
On kaks suhteliselt uut asja. Need ilmuvad juba kolmandates tuumades. Need on sched_migration_cost nanosekundites ja sched_autogroup_enabled, mis vaikimisi on \u00fcks. <\/p>\n
<\/p>\n
Ja kuidas need elu rikuvad? Mis on sched_migration_cost? Linuxi ajakava v\u00f5ib migratsiooniprotsessi \u00fchest CPU-st teise. Ja PostgreSQL-i jaoks, mis t\u00e4idab p\u00e4ringuid, ei ole migreerimine teise CPU-le t\u00e4iesti selge, miks seda teha. Operatiivsystemi vaatenurgast, kui vahetate aknaid OpenOffice'i ja terminali vahel, v\u00f5ib see olla hea, kuid andmebaasi jaoks \u2013 see on v\u00e4ga halb.<\/strong> Seet\u00f5ttu on m\u00f5istlik poliitika seadistada migration_cost m\u00f5neks suureks v\u00e4\u00e4rtuseks, v\u00e4hemalt paar tuhat nanosekundit.<\/strong> <\/p>\n<\/p>\n
Mida see scheduler'ile t\u00e4hendab? See arvab, et selle aja jooksul on see protsess endiselt aktiivne. St kui teil on mingi pikk tehing, mis v\u00f5tab aega, siis scheduler saab sellest aru. Ta arvab, et seni, kuni see aegumisaeg pole m\u00f6\u00f6dunud, ei ole vaja seda protsessi kuhugi migreerida. Kui protsess sel ajal midagi teeb, siis ei toimu migratsiooni, vaid see l\u00f5petab t\u00f6\u00f6 sellel CPU-l, mis on talle m\u00e4\u00e4ratud. Ja tulemus on suurep\u00e4rane. <\/p>\n
<\/p>\n
Teine asi on autogroup. On hea idee spetsiifiliste t\u00f6\u00f6koormuste jaoks, mis ei ole seotud kaasaegsete andmebaasidega \u2013 gruppida protsessid vastavalt sellele virtuaalsele terminalile, millelt need k\u00e4ivitati. See on mugav m\u00f5nede \u00fclesannete jaoks. Praktikas on PostgreSQL mitme protsessi s\u00fcsteem prefork'iga, mis k\u00e4ivitatakse \u00fchest terminalist. Teil on lukustaja, kontrollpunkt ja k\u00f5ik teie kliendi p\u00e4ringud r\u00fchmitatakse \u00fchele scheduler'ile, \u00fchele CPU-le. Ja nad ootavad seal s\u00f5bralikult, kuni see vabaneb, et mitte teineteist segada ja kasutada seda kauem. See on lugu, mis ei ole sellise koormuse korral sugugi vajalik, seega tuleks see v\u00e4lja l\u00fclitada.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Minu kolleeg Aleksei Lesovski tegi katseid lihtsa pgbench'iga, kus ta suurendas migration_cost'i j\u00e4rsult ja v\u00e4ljas kirjutas autogroup'i. Halva riistvara puhul tuli vahe peaaegu 10%.<\/strong>. Postgres'i meililistil on arutelu, kus inimesed toovad v\u00e4lja tulemusi, kuidas sellised muudatused m\u00f5jutasid p\u00e4ringu kiirus. m\u00f5jutasid 50%.<\/strong>. Selliseid lugusid on \u00fcsna palju.<\/p>\n<\/p>\n
<\/p>\n
Ja l\u00f5petuseks energia salvestamise poliitika. H\u00e4sti, et n\u00fc\u00fcd saab Linuxit kasutada s\u00fclearvutis. Ja see peaks t\u00f5eliselt h\u00e4sti akku kasutama. Kuid \u00fcllatuslikult selgub, et serverites v\u00f5ib sama olla. <\/p>\n
<\/p>\n
Veelgi enam, kui rendite servereid m\u00f5nelt hostimisettev\u00f5ttelt, siis 'head' hostinguteenuse pakkujad<\/a> ei hooli sellest, et teil oleks parem j\u00f5udlus. Nende \u00fclesanne on tagada, et nende riistvara t\u00f6\u00f6taks maksimaalselt t\u00f5husalt. Seet\u00f5ttu v\u00f5ivad nad vaikimisi operatsioonis\u00fcsteemi abil sisse l\u00fclitada s\u00fclearvutire\u017eiimi, mis s\u00e4\u00e4stab energiat.<\/p>\n<\/p>\n
Kui kasutate intensiivse koormuse aluseks oleva andmebaasi serveris seda head, siis teie valik on acpi_cpufreq + performance. Isegi ondemand'iga v\u00f5ivad juba olla probleemid.<\/strong> <\/p>\n<\/p>\n
Intel_pstate on n\u00fc\u00fcd veidi erinev draiver. Praegu eelistatakse just seda, kuna see on uuenduslikum ja paremini t\u00f6\u00f6tav.<\/p>\n
<\/p>\n
Seega on governor ainult performance. Ondemand, powersave ja k\u00f5ik muu \u2013 need ei puuduta teid. <\/p>\n
<\/p>\n
Explain analyze PostgreSQL tulemused v\u00f5ivad erineda mitu korda, kui aktiveerite powersave, sest teie aluses kapoti all ajakava CPU-d t\u00e4iesti ettearvamatul viisil.<\/p>\n
<\/p>\n
Need asjad v\u00f5ivad olla vaikes\u00e4tetena sisse l\u00fclitatud. Vaadake hoolikalt \u2013 ei ole nad vaikimisi sisse l\u00fclitatud? See v\u00f5ib olla t\u00f5eliselt suur probleem. <\/p>\n
<\/p>\n
<\/p>\n
Ja l\u00f5puks tahaksin t\u00e4nada meie DBA meeskonda PostgreSQL-Consulting, nimelt Maks Boguuit ja Aleksei Lesovskit, kes iga p\u00e4ev sellel alal oma vigadest \u00f5pivad. P\u00fc\u00fcame meie klientidele maksimaalselt head teenust pakkuda, et nende s\u00fcsteemid t\u00f6\u00f6taksid. See on nagu lennunduse ohutusjuhendite puhul. K\u00f5ik on siin verega kirjutatud. Iga nende mutri avastamine toimus mingi probleemi k\u00e4igus. Jagame neid r\u00f5\u00f5muga teiega.<\/p>\n
<\/p>\n
K\u00fcsimused:<\/p>\n
<\/p>\n
Ait\u00e4h! Kui n\u00e4iteks ettev\u00f5te soovib s\u00e4\u00e4sta ja k\u00e4itada \u00fchel serveril andmebaasi ja rakenduse loogikat v\u00f5i kui ettev\u00f5te j\u00e4rgib trendi mikroteenuste arhitektuuris, kus PostgreSQL t\u00f6\u00f6tab konteineris. Mis on nipiks? Sysctl m\u00f5jutab globaalset kogu s\u00fcdamikku. Ma ei ole kuulnud, et sysctl kuidagi virtualiseeritaks, et need t\u00f6\u00f6taksid konteineris eraldi. On ainult cgroup ja seal on ainult osaline kontroll. Kuidas sellega elada? V\u00f5i kui soovite j\u00f5udlust, siis k\u00e4itage PostgreSQL eraldi raua serveris ja optimeerige seda?<\/em><\/p>\n<\/p>\n
Oleme teie k\u00fcsimusele vastanud umbkaudu kolme erineva viisiga. Kui jutt ei ole rauaserverist, mida saab optimeerida jne, siis rahunege, k\u00f5ik t\u00f6\u00f6tab h\u00e4sti ka nende seadistusteta. Kui teil tekib koormus, mis n\u00f5uab nende seadistuste tegemist, siis j\u00f5uate rauaserverile varem kui nende seadistusteni.<\/p>\n
<\/p>\n
Mis probleem selles on? Kui see on virtuaalmasin, siis on t\u00f5en\u00e4oliselt mitmeid probleeme, n\u00e4iteks sellele, et enamikul virtuaalmasinatest on ketta latentsus ebaj\u00e4rjekindel. Isegi kui kettamaht on hea, siis \u00fcks eba\u00f5nnestunud sisendi-v\u00e4ljastusoperatsiooni tehing, mis ei m\u00f5juta oluliselt keskmist l\u00e4bilaskev\u00f5imet, v\u00f5ib m\u00e4rkimisv\u00e4\u00e4rselt m\u00f5jutada andmebaasi, kui see toimub checkpoint'i v\u00f5i WAL-i kirjutamise ajal, ja te m\u00e4rkate seda kiiremini, kui v\u00f5iks arvata. <\/p>\n
<\/p>\n
Kui teil on NGINX samal serveril, on probleem sama. See v\u00f5itleb jagatud m\u00e4luruumi p\u00e4rast. Ja te ei j\u00f5ua siinkohal kirjeldatud probleemideni.<\/p>\n
<\/p>\n
Teiselt poolt teatud parameetrid on siiski teie jaoks olulised. N\u00e4iteks, seadistage sysctl dirty_ratio, et see ei oleks nii \u00e4\u00e4rmuslik \u2013 igal juhul see aitab. Teie ketta kasutamine toimub mingil viisil. Ja see ei toimi \u00f5igesti. Need on \u00fcldiselt vaikimisi seadistused, mida ma n\u00e4itasin. Ja igal juhul on parem neid muuta. <\/p>\n
<\/p>\n
NUMA v\u00f5ib tekitada probleeme. N\u00e4iteks t\u00f6\u00f6tab VmWare NUMA-ga h\u00e4sti, kui seaded on t\u00e4pselt vastupidised. Siin tuleb teha valik \u2013 kas raudserver v\u00f5i mitte. <\/p>\n
<\/p>\n
Mul on k\u00fcsimus, mis on seotud Amazon AWS-iga. Neil on eelkonfigureeritud image. \u00dcks neist on nimetatud Amazon RDS-iks. Kas seal on mingid kohandatud seaded nende operatsioonis\u00fcsteemi jaoks?<\/em><\/p>\n<\/p>\n
Seal on seaded, kuid need on teistsugused. Siin seadistame operatsioonis\u00fcsteemi selle perspektiivist, kuidas andmebaas seda kasutab. Ja seal on parameetrid, mis m\u00e4\u00e4ravad, kuhu me praegu suundume, nii-\u00f6elda shaping. See t\u00e4hendab, et me vajame nii palju ressursse, ja me hakkame neid kohe kasutama. P\u00e4rast seda \u00fchendab Amazon RDS need ressursid ja seal esineb j\u00f5udluse langus. On eraldi juhtumeid, kus inimesed hakkavad sellega eksperimenteerima. M\u00f5nikord isegi \u00fcsna edukalt. Kuid see ei ole seotud operatsioonis\u00fcsteemi seadistustega. See on nagu pilve h\u00e4kkimine. See on hoopis teine lugu.<\/p>\n
<\/p>\n
Miks Transparent huge pages ei anna efekti v\u00f5rreldes Huge TLB-ga?<\/em><\/p>\n<\/p>\n
Nad ei anna. Seda saab selgitada mitmeti, kuid tegelikult nad lihtsalt ei anna seda. Milline on PostgreSQL ajalugu? Ta jagab k\u00e4ivitamisel suure osa jagatud m\u00e4lust. Kas nad on l\u00e4bipaistvad v\u00f5i mitte \u2013 pole absoluutselt oluline. Fakt, et nad jaotatakse k\u00e4ivitamisel, seletab k\u00f5ik. Ja kui m\u00e4lu on v\u00e4ga palju ja tuleb \u00fcmber jaotada jagatud m\u00e4lu segment, siis l\u00e4bipaistvad suured lehed (Transparent huge pages) saavad asjakohaseks. PostgreSQL jaotab lihtsalt k\u00e4ivitamisel tohutu t\u00fcki ja k\u00f5ik, ja edasi seal midagi erilist ei toimu. Loomulikult on v\u00f5imalik kasutada, kuid on oht saada jagatud m\u00e4lu rikutud, kui see peab midagi uuesti jaotama. PostgreSQL ei tea sellest.<\/p>\n
Allikas: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 2015 \u0433\u043e\u0434\u0430 \u0418\u043b\u044c\u0438 \u041a\u043e\u0441\u043c\u043e\u0434\u0435\u043c\u044c\u044f\u043d\u0441\u043a\u043e\u0433\u043e "Linux tuning to improve PostgreSQL performance" Disclaimer: \u0417\u0430\u043c\u0435\u0447\u0443 \u0447\u0442\u043e \u0434\u043e\u043a\u043b\u0430\u0434 \u044d\u0442\u043e\u0442 \u0434\u0430\u0442\u0438\u0440\u043e\u0432\u0430\u043d \u043d\u043e\u044f\u0431\u0440\u0435\u043c 2015 \u0433\u043e\u0434\u0430 \u2014 \u043f\u0440\u043e\u0448\u043b\u043e \u0431\u043e\u043b\u044c\u0448\u0435 4 \u043b\u0435\u0442 \u0438 \u043f\u0440\u043e\u0448\u043b\u043e \u043c\u043d\u043e\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438. \u0420\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u043c\u0430\u044f \u0432 \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0432\u0435\u0440\u0441\u0438\u044f 9.4 \u0443\u0436\u0435 \u043d\u0435 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442\u0441\u044f. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 4 \u0433\u043e\u0434\u0430 \u0432\u044b\u0448\u043b\u043e 5 \u043d\u043e\u0432\u044b\u0445 \u0440\u0435\u043b\u0438\u0437\u043e\u0432 PostgreSQL \u0432\u044b\u0448\u043b\u043e \u0438 15 \u0432\u0435\u0440\u0441\u0438\u0439 \u044f\u0434\u0440\u0430 Linux. \u0415\u0441\u043b\u0438 \u043f\u0435\u0440\u0435\u043f\u0438\u0441\u044b\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84083,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84082","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"PostgreSQL](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n