serveris<\/a> ja see k\u00f5ik suundub l\u00f5puks SATA k\u00f5vakettale ilma igasuguse vahem\u00e4lu, siis muutub kogu andmebaasiserver mitte lihtsalt k\u00f5rvitsaks, vaid k\u00f5rvitsaks SATA liidesega. Te seisate selle ees otseselt. Ja miski ei p\u00e4\u00e4sta teid.<\/p>\n<\/p>\n
<\/p>\n
Mida puudutab esimest punkti m\u00e4lu osas, siis on kolm asja, mis v\u00f5ivad elu oluliselt keerulisemaks muuta. <\/p>\n
<\/p>\n
Esimene neist on NUMA. NUMA on asi, mis on loodud j\u00f5udluse parandamiseks. Olenevalt t\u00f6\u00f6koormusest v\u00f5ib erinevaid asju optimeerida. Ja oma t\u00e4nases kujus ei ole see selliste rakenduste, nagu andmebaas, mis intensiivselt kasutavad lehek\u00fclje vahem\u00e4lu jagatud puhverdes, v\u00e4ga hea. <\/p>\n
<\/p>\n
<\/p>\n
L\u00fchidalt. Kuidas m\u00f5ista, et NUMA-ga on midagi valesti? Teil on mingi ebameeldiv m\u00fcrin, \u00fcht\u00e4kki on m\u00f5ni CPU \u00fclekoormatud. Samal ajal anal\u00fc\u00fcsite PostgreSQL-is p\u00e4ringuid ja n\u00e4ete, et seal pole midagi sellist. Need p\u00e4ringud ei tohiks olla nii intensiivsed CPU kasutamise osas. Seda saab kaua j\u00e4lgida. Lihtsam on alates algusest kasutada \u00f5iget soovitust, kuidas NUMA PostgreSQL-i seadistada.<\/p>\n
<\/p>\n
<\/p>\n
Mis tegelikult juhtub? NUMA - see on Mittet\u00e4iuslik M\u00e4luelektroonika. Miks see on? Teil on CPU, mille k\u00f5rval 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 saate sellise suure lehe. Muuhulgas on seal valdkond distances. Seal on numbrid \u2013 10-20, midagi sellist. Need numbrid ei ole midagi muud kui h\u00fcpikute arv, et see eemal asuv m\u00e4lu \u00fchendada ja kohapeal kasutada. \u00dcldiselt on see hea m\u00f5te. See kiirendab j\u00f5udlust teatud koormuste puhul.<\/p>\n<\/p>\n
Kujutage n\u00fc\u00fcd ette, et teie \u00fcks CPU \u00fcritab esmalt kasutada oma kohalikku m\u00e4lu, seej\u00e4rel proovib ta interconnecti kaudu tuua endale muud m\u00e4lu millegi tarbeks. Ja sellele CPU-le j\u00f5uab kogu teie PostgreSQL page cache \u2013 k\u00f5ik need paar gigabaiti. Te alati saate halvimat juhtumit, sest CPU-l on tavaliselt otseselt selles m\u00e4lumoodulis v\u00e4he m\u00e4lu. Ja kogu m\u00e4lu, mis teenindatakse, liigub l\u00e4bi nende interconnectide. See on aeglane ja kurb. Ja teil on protsessor, mis teenindab seda s\u00f5lme, pidevalt \u00fcle koormatud. Ja selle m\u00e4lu juurdep\u00e4\u00e4su aeg on halb, aeglane. See on see olukord, mida te ei soovi, kui kasutate seda andmebaasi tarbeks. <\/p>\n
<\/p>\n
Seet\u00f5ttu on \u00f5igem variant andmebaasiks, et Linuxi operatsioonis\u00fcsteem ei teadliks sellest, mis seal toimub. Et ta p\u00f6\u00f6rdub m\u00e4lu poole nii, nagu ta tavaliselt p\u00f6\u00f6rdub. <\/p>\n
<\/p>\n
Miks nii? Tundub, et peaks olema vastupidi. See juhtub \u00fchel lihtsal p\u00f5hjusel, et m\u00e4lu on meil page cache jaoks palju vaja \u2013 k\u00fcmneid, sadu gigabaiate. <\/p>\n
<\/p>\n
Ja kui me oleme k\u00f5ik selle eraldanud ja oma andmed seal vahem\u00e4lusse salvestanud, siis on kasu vahem\u00e4lu kasutamisest oluliselt suurem kui see kasu, mis tuleneb sellisest nutikast m\u00e4lu k\u00e4sitsemisest. Ja me v\u00f5idame seel\u00e4bi v\u00f5rreldamatult rohkem, v\u00f5rreldes sellega, et oleksime efektiivsemad m\u00e4lu k\u00e4sitsemisel NUMA abil.<\/p>\n
<\/p>\n
Niisiis, hetkel on siin kaks l\u00e4henemist, kuni valgus tulevikus ei saabu ja andmebaas ei oska ise aru saada, millistel CPU-del ta t\u00f6\u00f6tab ja kust tuleb midagi laadida. <\/p>\n
<\/p>\n
<\/p>\n
Seet\u00f5ttu on \u00f5ige l\u00e4henemine \u2013 \u00fcldse NUMA v\u00e4lja l\u00fclitada<\/strong>, n\u00e4iteks taask\u00e4ivitamisel. Enamiku juhtumite puhul on kasum nii suur, et k\u00fcsimus, kuidas paremini, ei teki \u00fcldse. <\/p>\n<\/p>\n
On teine v\u00f5imalus. Me kasutame seda sagedamini kui esimest, sest kui klient tuleb meie tehnilisse tugi, siis on serveri taask\u00e4ivitamine tema jaoks suur asi. Tema seal ju \u00e4ri k\u00e4ib. Probleemid NUMA t\u00f5ttu on nad kogenud. Seet\u00f5ttu p\u00fc\u00fcame neid v\u00e4lja l\u00fclitada v\u00e4hem invasiivsete meetoditega kui taask\u00e4ivitamine, kuid siin tuleb ettevaatlikult kontrollida, et see t\u00f5esti v\u00e4lja l\u00fclitatud oleks. Sest, nagu kogemus n\u00e4itab, kui me vanemalt PostgreSQL NUMA protsessilt v\u00e4lja l\u00fclitame, on see hea, kuid kindlasti pole see vajalik, et see t\u00f6\u00f6le hakkaks. Tuleb kontrollida ja vaadata, et see t\u00f5eliselt v\u00e4lja l\u00fclitatakse. <\/p>\n
<\/p>\n
On olemas hea postitus Robert Haasilt. Ta on \u00fcks PostgreSQL'i pannijaid. \u00dcks v\u00f5tme arendajatest k\u00f5ikide madala taseme komponente. Ja kui sellele postitusele viidatud linkidele minna, siis seal on mitmeid v\u00e4rvikate lugusid sellest, kuidas NUMA elusid keeruliseks tegi. Vaadake, uurige s\u00fcsteemiadministraatori kontrollnimekirja, mida serveris seadistada, et meie andmebaas t\u00f6\u00f6taks h\u00e4sti. Need seaded tuleb kirja panna ja kontrollida, sest vastasel juhul ei l\u00e4he h\u00e4sti. <\/p>\n
<\/p>\n
T\u00f5mban t\u00e4helepanu sellele, et see puudutab k\u00f5iki seadeid, millest ma r\u00e4\u00e4gin. Kuid tavaliselt kogutakse andmebaasid master-slave re\u017eiimis t\u00f5rgeteta t\u00f6\u00f6kindluse jaoks. \u00c4rge unustage need seaded slave'i sisse viia, sest \u00fchel kaunil hetkel juhtub teil katastroof ja te l\u00fclitate \u00fcle slave'ile, kes saab masteriks. <\/p>\n
<\/p>\n
H\u00e4daolukorras, kui k\u00f5ik on v\u00e4ga halb, heliseb teie telefon pidevalt ja juhataja jookseb suure kepiga, siis pole teil aega m\u00f5elda, et kontrollida. Ja tulemused v\u00f5ivad olla v\u00e4ga kurvad.<\/p>\n
<\/p>\n
<\/p>\n
J\u00e4rgmine punkt on huge pages. Huge pages'i on keeruline eraldi testida, ja selles pole ka m\u00f5tet, kuigi on olemas benhmarke, mis oskavad seda teha. Need leiavad kergesti Google'is. <\/p>\n
<\/p>\n
Mis on m\u00f5te? Teil on mitte eriti kallis server, milles on palju RAM-i, n\u00e4iteks \u00fcle 30 GB. Te ei kasuta huge pages'i. See t\u00e4hendab, et teil on kindlasti \u00f5ige \u00fcleliigne m\u00e4lu kasutamine. Ja see \u00fcleliigne on kaugeltki mitte mugav. <\/p>\n
<\/p>\n
<\/p>\n
Miks see nii on? Mis toimub? Operatsioonis\u00fcsteem jaotab m\u00e4lu v\u00e4ikesteks t\u00fckkideks. See on mugav ja ajalooliselt v\u00e4lja kujunenud. Ja kui detaljidesse laskuda, peab operatsioonis\u00fcsteem edastama virtuaalsed aadressid f\u00fc\u00fcsilistesse aadressitesse. See protsess ei ole k\u00f5ige lihtsam, seega talletab operatsioonis\u00fcsteem selle operatsiooni tulemuse Translation Lookaside Bufferis (TLB).<\/p>\n
<\/p>\n
Ja kuna TLB on vahem\u00e4lu, siis sellistes olukordades tekivad k\u00f5ik sellele omased probleemid. Esiteks, kui teil on v\u00e4ga palju j\u00f5udlusse 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, on selle t\u00f5ttu otsimine aeglasem. \u00dcleminek on suur ja see ise v\u00f5tab ruumi, st, et operatiivm\u00e4lu tarbib midagi ebavajalikku. See on esimene punkt. <\/p>\n
<\/p>\n
Teiseks \u2013 mida suurem muutub vahem\u00e4lu sellises olukorras, seda suurem on t\u00f5en\u00e4osus, et teil tekib cache misses. Ja selle vahem\u00e4lu efektiivsus langeb kiiresti koos selle suuruse suurenemisega. Seet\u00f5ttu on operatsioonis\u00fcsteemides v\u00e4lja m\u00f5eldud lihtne l\u00e4henemine. Linuxis on see juba ammu kasutusel. FreeBSD-s on see mitte nii kaua tagasi ilmunud. Kuid me r\u00e4\u00e4gime Linuxist. See on huge pages.<\/p>\n
<\/p>\n
Siinkohal tuleb m\u00e4rkida, et huge pages m\u00f5tteviit oli algselt edendatud kogukondade poolt, kuhu kuulusid Oracle ja IBM, st andmebaasi tootjad m\u00f5tlesid t\u00f5siselt, et see v\u00f5iks olla kasulik, sealhulgas andmebaaside jaoks. <\/p>\n
<\/p>\n
<\/p>\n
Kuidas seda PostgreSQL-iga siduda? Esiteks peavad Linuxi ydas olema lubatud huge pages.<\/p>\n
<\/p>\n
Teiseks, need peavad olema selgelt m\u00e4\u00e4ratud sysctl parameetriga \u2013 kui palju neid on. Numbrid siinkohal p\u00e4rinevad m\u00f5nelt vanalt serverilt. Saate arvutada, kui palju teile ligikaudu shared buffers on, et huge pages sinna mahuksid. <\/p>\n
<\/p>\n
Ja kui kogu server on p\u00fchendatud PostgreSQL-ile, siis hea l\u00e4htepunkt on kas anda 25% operatiivm\u00e4last jagatud pufferitele v\u00f5i 75%, kui olete kindel, et teie andmebaas mahub kindlasti sellesse 75% suurusesse. Esimene l\u00e4htepunkt. Ja arvutage, kui teil on 256 GB operatiivm\u00e4lu, siis vastavalt on 64 GB jagatud pufferite jaoks. Arvutage veidi marginaaliga \u2013 milline peaks see arv olema.<\/p>\n
<\/p>\n
Enne versiooni 9.2 (kui ma ei eksi, alates versioonist 8.2) oli v\u00f5imalik kolmanda osapoole raamatukogu abil PostgreSQL \u00fchendada huge pages'iga. Ja seda tuleb alati teha. Esiteks, teil on vajalik, et kernel oskaks huge pages'i \u00f5igesti jagada. Teiseks, rakendusel, mis nendega t\u00f6\u00f6tab, peab olema v\u00f5imalus neid kasutada. Ilma selle v\u00f5imaluseta ei saa see nendest kasu. Kuna PostgreSQL jagas m\u00e4lu system 5 stiilis, sai seda teha libhugetlbfs abil \u2014 see on selle raamatukogu t\u00e4isnimi.<\/p>\n
<\/p>\n
Versioonis 9.3 paranes PostgreSQL-i j\u00f5udlus m\u00e4lu haldamisel ja loobuti system 5 m\u00e4lu jagamise meetodist. K\u00f5ik olid v\u00e4ga r\u00f5\u00f5msad, sest muidu proovisid sa k\u00e4ivitada kahte PostgreSQL-i instantsi samal masinal ja \u00fctles, et mul on jagatud m\u00e4lu v\u00e4he. Ja selgus, et sysctl tuleb muuta. Ja seal on selline sysctl, et peab veel taask\u00e4ivitama jne. \u00dches\u00f5naga, k\u00f5ik olid r\u00f5\u00f5msad. Kuid mmap-i m\u00e4lu jagamine rikkus huge pages'i kasutamist. Enamik meie kliente kasutab suuri jagatud puhvreid. Ja me soovisime tungivalt mitte minna versioonile 9.3, kuna seal tekkis \u00fclekattega probleemide hulk.<\/p>\n
<\/p>\n
Aga siiski t\u00e4helepanu sellele probleemile p\u00f6\u00f6ras community ja versioonis 9.4 t\u00f6\u00f6tati seda v\u00e4ga h\u00e4sti \u00fcmber. Ja versioonis 9.4 ilmus parameeter postgresql.conf-is, kus saab lubada try, on v\u00f5i off.<\/p>\n
<\/p>\n
Try on k\u00f5ige ohutum parameeter. PostgreSQL-i k\u00e4ivitamisel, kui see jagab jagatud m\u00e4lu, p\u00fc\u00fcab ta endale vastava m\u00e4lu saada huge pages-ist. Ja kui see ei \u00f5nnestu, siis tagasi tavalisel jagamisel. Kui teie s\u00fcsteem on FreeBSD v\u00f5i Solaris, siis saate panna try, see on alati ohutu. <\/p>\n
<\/p>\n
Kui on on, siis see lihtsalt ei k\u00e4ivitu, kui ei suutnud huge pages'ist jagada. Siin s\u00f5ltub k\u00f5ik teie eelistustest. Kuid kui teil on seadistatud try, siis kontrollige, et teil on t\u00f5epoolest see, mis peab olema eraldatud, sest seal on palju viga tegemise ruumi. Praegu t\u00f6\u00f6tab see funktsioon ainult Linuxis.<\/p>\n
<\/p>\n
Veel t\u00e4helepanuts, enne kui l\u00e4heme edasi. Transparent huge pages ei kehti hetkel PostgreSQL jaoks. Ta ei saa neid normaalselt kasutada. Ja transparent huge pages puhul, kui on vajalik suur osa jagatud m\u00e4lu, tulevad eelised esile ainult v\u00e4ga suurte mahtude korral. Kui teil on terabaiti m\u00e4lu, siis see v\u00f5ib m\u00e4ngida rolli. Aga kui r\u00e4\u00e4gime tavap\u00e4rastest rakendustest, kus teie masinas on 32, 64, 128, 256 GB m\u00e4lu, siis tavalised huge pages on ok ja transparent tuleb lihtsalt v\u00e4lja l\u00fclitada. <\/p>\n
<\/p>\n
<\/p>\n
Ja viimane asi, mis on m\u00e4luga seotud, ei ole otseselt seotud l\u00e4bilaskev\u00f5imega, vaid v\u00f5ib elu oluliselt halvendada. Kogu l\u00e4bilaskvus kannatab selle all, et server vahetab pidevalt. <\/p>\n
<\/p>\n
Ja see on mitmel hetkel v\u00e4ga ebameeldiv. Peamine ebameeldivus tuleneb sellest, et kaasaegsete kernide k\u00e4itumine erineb veidi vanematest Linuxi kernidest. Ja see on asi, mille peale astuda on \u00fcsna ebameeldiv, kuna kui r\u00e4\u00e4gime swap'iga t\u00f6\u00f6tamisest, l\u00f5ppeb see OOM-killeri ebamugava sissetuleku t\u00f5ttu. Ja OOM-killer, mis ei tule \u00f5igeaegselt ja l\u00f5petab PostgreSQL-i, on ebameeldiv. Sellest saavad teada k\u00f5ik, st viimane kasutaja. <\/p>\n
<\/p>\n
<\/p>\n
Mis toimub? Sul on seal suur hulk operatiivm\u00e4lu, k\u00f5ik t\u00f6\u00f6tab h\u00e4sti. Kuid mingil p\u00f5hjusel server hangub swap'is ja see p\u00f5hjustab viivitusi. Tundub, et m\u00e4lu on piisavalt, aga see juhtub ikkagi. <\/p>\n
<\/p>\n
<\/p>\n
Varem soovitasime vm.swappiness nulli seadistada, st swap v\u00e4lja l\u00fclitada. Varem tundus, et 32 GB operatiivm\u00e4lu ja vastavad jagatud buferid on tohutu hulk. Swap'i peamine eesm\u00e4rk on anda ruumi, kuhu visata tuum, kui oleme kukkunud. Ja see ei t\u00e4itnud enam oma eesm\u00e4rki. Ja mida sa selle tuumaga p\u00e4rast teed? See on juba selline \u00fclesanne, kus ei ole eriti selge, miks swap'i sellises suuruses \u00fcldse vaja on. <\/p>\n
<\/p>\n
Kuid kaasaegsemates, st kolmandates versioonides on k\u00e4itumine muutunud. Ja kui seadistada swap nulli, st v\u00e4lja l\u00fclitada, siis varem v\u00f5i hiljem, isegi kui m\u00f5ned m\u00e4luressursid on alles, tuleb OOM-killer teie juurde, et tappa k\u00f5ige intensiivsemad ressursikasutajad. Sest ta arvab, et sellise t\u00f6\u00f6koormuse korral on meil j\u00e4\u00e4nud veel v\u00e4he m\u00e4lu ja me l\u00e4heme \u00fcle piiri, st mitte s\u00fcsteemset protsessi tapma, vaid midagi v\u00e4hem olulist. Selleks v\u00e4hem oluliseks osutub intensiivne jagatud m\u00e4lu tarbija, nimelt postmaster. Ja p\u00e4rast seda on hea, kui andmebaasi ei pea taastama. <\/p>\n
<\/p>\n
Seet\u00f5ttu on n\u00fc\u00fcd vaikimisi, kui ma \u00f5igesti m\u00e4letan, enamikus jaotustes umbes 6, st millal hakata kasutama swap'i s\u00f5ltuvalt sellest, kui palju m\u00e4lu on j\u00e4\u00e4nud. Me soovitame praegu seadistada vm.swappiness = 1, sest see praktiliselt l\u00fclitab selle v\u00e4lja, kuid ei too kaasa selliseid efekte, nagu ootamatult saabunud OOM-killer ja k\u00f5ik see, mis on igasuguste probleemide p\u00f5hjus.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Mis edasi? Kui r\u00e4\u00e4gime andmebaaside j\u00f5udlusest ja j\u00e4rk-j\u00e4rgult j\u00f5uame ketaste juurde, haaravad k\u00f5ik oma pead. Sest t\u00f5de, et ketas on aeglane ja m\u00e4lu kiire, on k\u00f5igile lapsep\u00f5lvest tuttav. Ja k\u00f5ik teavad, et andmebaasis tekivad probleemid ketta j\u00f5udlusega.<\/p>\n
<\/p>\n
Peamine probleem PostgreSQL-i j\u00f5udlusega, mis on seotud checkpoints spikes'idega, ei tulene mitte sellest, et ketas on aeglane. See tuleneb pigem sellest, et m\u00e4lu ja ketta l\u00e4bilaskev\u00f5ime ei ole tasakaalus. Samas v\u00f5ivad nad olla tasakaalustamata erinevates kohtades. PostgreSQL ei ole seadistatud, operatsioonis\u00fcsteem ei ole seadistatud, riistvara ei ole seadistatud ja riistvara ei ole \u00f5ige. Ja seda probleem ei esine 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? Tavaliselt astuvad inimesed, kes t\u00f6\u00f6tavad PostgreSQL-iga, sellesse valdkonda korduvalt. Selgitan. Nagu ma \u00fctlesin, teeb PostgreSQL perioodiliselt kontrollpunkte, et m\u00e4\u00e4rdunud lehed jagatud m\u00e4lust kettale salvestada. Kui meil on suur jagatud m\u00e4lu maht, siis hakkab kontrollpunkt intensiivselt kettale m\u00f5ju avaldama, kuna see salvestab need lehed fsync'iga. Need j\u00f5uavad kernel-buffrisse ja kirjutatakse ketastele fsync'i abil. Ja kui selle mahud on suured, siis v\u00f5ime j\u00e4lgida ebameeldivat efekti, nimelt v\u00e4ga k\u00f5rget ketaste kasutust.<\/p>\n
<\/p>\n
Siin on mul kaks pilti. Selgitan, mis need on. Need on kaks ajaliselt korreleeritud graafikut. Esimene graafik \u2013 see on ketta kasutus. Siin ulatub see antud hetkel peaaegu 90%-ni. Kui teie andmebaas ja f\u00fc\u00fcsilised kettad koos RAID-kontrolleriga saavutavad 90% kasutust, siis on see halvad uudised. See t\u00e4hendab, et veel natuke ja j\u00f5uame 100%-ni ning sisend-v\u00e4ljund peatub. <\/p>\n
<\/p>\n
Kui teil on kettas\u00fcsteem, siis on seal veidi teine lugu. See s\u00f5ltub sellest, kuidas see on konfigureeritud, milline s\u00fcsteem see on jne. <\/p>\n
<\/p>\n
Samas on siin konfigureeritud graafik PostgreSQL-i sisemise vaate p\u00f5hjal, mis n\u00e4itab, kuidas kontrollpunkt toimub. Roheline v\u00e4rv n\u00e4itab, kui palju bufreid, neid m\u00e4\u00e4rdunud lehti, on sel hetkel selle kontrollpunkti jaoks s\u00fcnkroniseerimiseks saabunud. Ja see on peamine, mida siin teadma peame. N\u00e4eme, et meil on siin palju lehti saabunud ja mingil hetkel saime 'plaati' otsa, st kirjutasime-kirjutasime, siin on ilmselgelt kettas\u00fcsteem v\u00e4ga h\u00f5ivatud. Ja meie kontrollpunkt avaldab kettale suurt m\u00f5ju. Ideaalis peaks olukord v\u00e4lja n\u00e4gema pigem nii, et meil oleks siin v\u00e4hem kirjutatud. Ja saame seadistustega selle parandada, et tulevikus niimoodi ei juhtuks. St kasutus on v\u00e4ike, kuid midagi me siin kirjutame. <\/p>\n
<\/p>\n
Mida tuleb teha, et see probleem \u00fcletada? Kui teie andmebaasi IO on peatunud, 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 olete valinud hea riistvara, seadistanud selle \u00f5igesti ja konfigureerinud PostgreSQL, et see teeks need checkpoints harvem, ja hajutaks need ajaliselt, siis j\u00e4\u00e4te Debian'i vaikeseadistuste juurde. Enamiku Linuxi distributsioonide puhul on pilt j\u00e4rgmine: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
Mida see t\u00e4hendab? Tuumast 2.6 alates ilmus \u00fcks demon, mis tegeleb andmete t\u00fchjendamisega. Pdglush s\u00f5ltuvalt sellest, kes mida kasutab, tegeleb taustal m\u00e4\u00e4rdunud lehtede eemaldamisega kernel buffer'ist ja eemaldab need, kui on h\u00e4davajalik t\u00fchjendada m\u00e4\u00e4rdunud lehti, kui taustal t\u00fchjendamine enam ei aita. <\/p>\n
<\/p>\n
Millal algab taust? Kui 10% kogu serveri RAM-ist on m\u00e4\u00e4rdunud lehtedega kernel buffer'is, siis kutsutakse spetsiaalne funktsioon t\u00fchjendamiseks taustal. Miks see on taustal? See v\u00f5tab parameterina, kui palju lehti t\u00fchjendada. N\u00e4iteks t\u00fchjendab N lehte. Ja m\u00f5neks ajaks see asi magab. Siis tuleb see j\u00e4lle ja t\u00fchjendab veel mingi arvu lehti. <\/p>\n
<\/p>\n
See on \u00e4\u00e4rmiselt lihtne lugu. Siin on \u00fclesanne nagu basseinis, kus \u00fchte torusse voolab vett ja teisest voolab v\u00e4lja. Meil on checkpoint ja kui ta on saatnud v\u00e4he m\u00e4\u00e4rdunud lehti eemaldamiseks, siis imenduvad need j\u00e4rk-j\u00e4rgult kernel buffer'i pgflush'i kaudu. <\/p>\n
<\/p>\n
Kui need m\u00e4\u00e4rdunud lehed j\u00e4tkuvalt kuhjuvad, kuhjuvad nad kuni 20%, p\u00e4rast seda on OS prioriteet need \u00e4ra t\u00fchjendada, sest v\u00f5ite kaotada toite ja meil l\u00e4heb k\u00f5ik halvasti. N\u00e4iteks v\u00f5ime kaotada need andmed. <\/p>\n
<\/p>\n
Mis on trikk? Trikk seisneb selles, et need parameetrid, 20 ja 10% kogu masina RAM-ist, on t\u00e4iesti kohutavad diskis\u00fcsteemi l\u00e4bilaskvuse seisukohalt, mis teil on.<\/strong> <\/p>\n<\/p>\n
Kujutage ette, et teil on 128 GB RAM. 12,8 GB j\u00f5uab teie diskis\u00fcsteemi. Ja milline iganes vahem\u00e4lu v\u00f5i maatriks teil seal on, ei suuda nad seda taluda. <\/p>\n
<\/p>\n
<\/p>\n
Seet\u00f5ttu soovitame need numbrid kohe seadistada vastavalt teie RAID-kontrolleri v\u00f5imalustele.<\/strong> Mul on siin kohe soovitus kontrolleri jaoks, millel on 512 MB vahem\u00e4lu. <\/p>\n<\/p>\n
Arvatakse, et k\u00f5ik on v\u00e4ga lihtne. V\u00f5ite vm.dirty_background seadistada baitides. Need seaded t\u00fchistavad kaks eelnevat. Kas defaukti j\u00e4rgi, v\u00f5i aktiveeritakse need, mis on baitides, ja siis t\u00f6\u00f6tavad need, mis on baitides. Aga kuna ma olen DBA-konsultant ja t\u00f6\u00f6tan erinevate klientidega, siis p\u00fc\u00fcan ma tagada, et k\u00f5ik oleks stabiilne, seega, kui baitides, siis baitides. Keegi ei ole andnud mingisugust garantiid, et hea admin ei lisa serverisse m\u00e4lu, ei taask\u00e4ivita teda, ja numbrid j\u00e4\u00e4vad samaks. Lihtsalt arvutage need numbrid, et garanteerida, et k\u00f5ik mahub sinna sisse. <\/p>\n
<\/p>\n
Mis juhtub, kui te ei mahu sisse? Mul on kirjas, et igasugune flushing peatub efektiivselt, aga tegelikult on see metafoor. Operatsioonis\u00fcsteemil on t\u00f5sine probleem \u2013 tal on palju r\u00e4pane lehti, seega peatub efektiivselt see IO, mis teie klientide poolt genereeritud, st. kui rakendus saadab SQL-p\u00e4ringu andmebaasi, ootab see. Iga IO sinna \u2013 on madalaimal prioriteedil, sest andmebaas on kinni checkpointis. Ja millal ta selle l\u00f5petab, pole selge. Ja kui olete j\u00f5udnud mitte-taustalisse flushing'usse, siis see t\u00e4hendab, et kogu teie IO on selle t\u00f6\u00f6ga h\u00f5ivatud. Ja seni, kuni see ei l\u00f5peta, ei tee te midagi. <\/p>\n
<\/p>\n
Siin on veel kaks olulist punkti, mis \u00fcletavad selle ettekande piire. Need seaded peavad vastama postgresql.conf seadetega, st. checkpointide seadistustega. Ja teie diskis\u00fcsteem peab olema \u00f5igesti seadistatud. Kui teil on RAID-kate, siis sellel peaks olema aku.<\/strong> Inimesed ostavad RAIDi hea k\u00e4tiga ilma akuta. Kui teil on SSD RAIDis, siis need peaks olema serveri t\u00fc\u00fcpi, seal peaks olema kondensaatorid.<\/strong> Siin on p\u00f5hjalik kontrollnimekiri. Selle lingi kaudu on mu ettekannet, kuidas konfigureerida disk perfomance'i PostgreSQL-is. Seal on k\u00f5ik need kontrolle. <\/p>\n<\/p>\n
<\/p>\n
Mis veel v\u00f5ib elu keeruliseks muuta? Need on kaks parameetrit. Need on suhteliselt uued. Need v\u00f5ivad erinevates rakendustes olla vaikimisi sissel\u00fclitatud. Ja need v\u00f5ivad keeruliseks muuta elu mitte v\u00e4hem, kui nad on valesti sisse l\u00fclitatud. <\/p>\n
<\/p>\n
<\/p>\n
On kaks suhteliselt uut funktsiooni. Need on juba ilmunud kolmandates kernites. Need on sched_migration_cost nanosekundites ja sched_autogroup_enabled, mis vaikimisi on \u00fcks. <\/p>\n
<\/p>\n
Ja kuidas nad elu rikuvad? Mis on sched_migration_cost? Linuxi ajakava v\u00f5ib protsessi migreerida \u00fchest CPU-st teise. Ja PostgreSQL jaoks, mis t\u00e4idab p\u00e4ringuid, on migreerimise p\u00f5hjustamine teisele CPU-le t\u00e4iesti arusaamatu. Operatsioonis\u00fcsteemi seisukohalt, kui vahetate aknaid OpenOffice'i ja terminali vahel, siis see v\u00f5ib-olla on hea, kuid andmebaasi jaoks \u2013 see on v\u00e4ga halb.<\/strong> Seet\u00f5ttu on m\u00f5istlik poliitika seada migration_cost m\u00f5neks suureks v\u00e4\u00e4rtuseks, v\u00e4hemalt paar tuhat nanosekundit.<\/strong> <\/p>\n<\/p>\n
Mida see scheduler\u2019i jaoks t\u00e4hendab? Ta peab arvestama, et selle aja jooksul on see protsess endiselt kuum. T. e. kui teil on m\u00f5ni pikk tehing, mis millegagi kaua tegeleb, siis scheduler saab sellest aru. Ta arvab, et seni, kuni see ajavahemik ei ole m\u00f6\u00f6das, ei ole m\u00f5tet seda protsessi mitte kuhugi migreerida. Kui protsess sel ajal midagi teeb, siis ei migreerita seda kuhugi, vaid ta l\u00f5petab rahulikult selle CPU-l, mis talle m\u00e4\u00e4ratud. Ja tulemus on suurep\u00e4rane. <\/p>\n
<\/p>\n
Teine aspekt on autogroup. Oleks hea idee spetsiifiliste t\u00f6\u00f6koormuste jaoks, mis ei ole seotud kaasaegsete andmebaasidega \u2013 r\u00fchmitada protsessid vastavalt sellele virtuaalsele terminalile, mille alt nad on k\u00e4ivitatud. See on mugav m\u00f5ningate \u00fclesannete jaoks. Praktikas on PostgreSQL mitme protsessiga s\u00fcsteem prefork\u2019iga, mis k\u00e4ivitatakse \u00fchest terminalist. Teil on lock writer, checkpoint ja k\u00f5ik teie kliendip\u00e4ringud r\u00fchmitatakse \u00fche ajakava alla, \u00fche CPU alla. Ja nad ootavad seal rahulikult, kuni see vabastatakse, et \u00fcksteisele segada ja kauem oma ressursse kasutada. See on lugu, mis on sellise koormuse korral t\u00e4iesti ebavajalik ja seet\u00f5ttu tuleb see v\u00e4lja l\u00fclitada.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Minu kolleeg Alexey Lesovski tegi teste lihtsa pgbench'iga, kus ta suurendas migration_cost v\u00e4\u00e4rtust ja l\u00fclitas autogroup v\u00e4lja. Halva riistvara korral oli erinevus peaaegu 10%<\/strong>. Postgresi postituslistis toimub arutelu, kus inimesed toovad tulemusi selle kohta, kuidas sarnased muutused p\u00e4ringu kiirus m\u00f5jutasid 50%<\/strong>. Selliseid lugusid on p\u00e4ris palju.<\/p>\n<\/p>\n
<\/p>\n
Ja l\u00f5petuseks vooluharjumuste poliitika. H\u00e4sti, et n\u00fc\u00fcd saab Linuxit kasutada s\u00fclearvutis. Ja see eeldab, et see s\u00e4\u00e4stab aku energiat. Kuid ootamatult selgub, et serveris v\u00f5ib see samuti juhtuda. <\/p>\n
<\/p>\n
Veelgi enam, kui rentite servereid m\u00f5nelt hostitajalt, siis on \"head\" hostitajad<\/a> ei hoolitse selle eest, et teie j\u00f5udlus oleks parem. Nende \u00fclesanne on tagada, et nende riistvara oleks maksimaalselt efektiivne. Seet\u00f5ttu v\u00f5ivad nad vaikimisi oma operatsioonis\u00fcsteemis lubada s\u00fclearvuti energias\u00e4\u00e4sture\u017eiimi.<\/p>\n<\/p>\n
Kui kasutate andmebaasi serveris, mille koormus on k\u00f5rge, siis teie valikuks on acpi_cpufreq + performance. Isegi ondemandiga hakkavad juba probleemid tekkima.<\/strong> <\/p>\n<\/p>\n
Intel_pstate on juba veidi teine draiver. Praegu eelistatakse seda, kuna see on uuem ja t\u00f6\u00f6tab paremini.<\/p>\n
<\/p>\n
Ja seega governor ainult performance. Ondemand, powersave ja k\u00f5ik muu \u2013 see ei ole teie jaoks. <\/p>\n
<\/p>\n
PostgreSQL explain analyze tulemused v\u00f5ivad erineda mitme j\u00e4rgu v\u00f5rra, kui lubate powersave, kuna teie all oleva andmebaasi CPU ajakava on t\u00e4iesti ettearvamatu.<\/p>\n
<\/p>\n
Need asjad v\u00f5ivad olla vaikimisi sisse l\u00fclitatud. Vaadake hoolikalt \u2013 kas need on 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 meeskonna PosgreSQL-Consulting, eriti Maks Bogu ja Aleksei Lesovsky, kes iga p\u00e4ev sellel alal vaeva n\u00e4evad. Me p\u00fc\u00fcame meie klientide jaoks teha k\u00f5ik v\u00f5imaliku, et see toimiks h\u00e4sti. Siin on see nagu lennuohutuse juhistes. K\u00f5ik on kirjutatud verega. Iga mutter avastatakse mingi probleemi k\u00e4igus. Jagame r\u00f5\u00f5muga koos teiega.<\/p>\n
<\/p>\n
K\u00fcsimused:<\/p>\n
<\/p>\n
Ait\u00e4h! Kui n\u00e4iteks ettev\u00f5te soovib kokku hoida ja paigutada andmebaasi ning rakenduse loogika samale serverile v\u00f5i kui ettev\u00f5te j\u00e4rgib moes suundi mikroteenuste arhitektuuris, kus PostgreSQL t\u00f6\u00f6tab konteineris. Mis on trikk? Sysctl m\u00f5jutavad globaalselt kogu tuuma. Ma ei ole kuulnud, et sysctl kuidagi virtualiseeritaks, et need toimiksid konteineris eraldi. Ainult cgroup ja seal on kontroll ainult osa kohta. Kuidas sellega elada? V\u00f5i kui soovite j\u00f5udlust, siis k\u00e4ivitage PostgreSQL eraldi f\u00fc\u00fcsilisel serveril ja optimeerige seda?<\/em><\/p>\n<\/p>\n
Me vastasime teie k\u00fcsimusele umbes kolme erineva viisi kaudu. Kui jutt ei ole raua serverist, mida saab seadistada jne, siis v\u00f5tke rahulikult, k\u00f5ik t\u00f6\u00f6tab h\u00e4sti ilma nende seadistusteta. Kui teil tekib koormus, mis n\u00f5uab neid seadistusi, siis j\u00f5uate raua serverini varem, kui nende seadistusteni.<\/p>\n
<\/p>\n
Mis on probleem? Kui see on virtuaalmasin, siis on t\u00f5en\u00e4oliselt palju probleeme, n\u00e4iteks see, et paljuski virtuaalmasinate kettas on ebaj\u00e4rjekindel latentsus. Isegi kui ketaste ribalaius on hea, siis \u00fcks eba\u00f5nnestunud sisend-v\u00e4ljundoperatsiooni tehing, mis ei m\u00f5juta keskmist ribalaiust, mis juhtus hetkel checkpoin'is v\u00f5i WAL'i kirjutamisel, p\u00f5hjustab andmebaasile t\u00f5siseid probleeme. Ja te m\u00e4rkate seda varem, kui te nendesse probleemidesse takerduda. <\/p>\n
<\/p>\n
Kui teil on NGINX samal serveril, siis on ka sama probleem. Ta v\u00f5itleb jagatud m\u00e4luga. Ja te ei j\u00f5ua kunagi siinkohal kirjeldatud probleemideni.<\/p>\n
<\/p>\n
Aga teisest k\u00fcljest, m\u00f5ned neist parameetritest on teile ikkagi olulised. N\u00e4iteks, seadistage sysctl'is dirty_ratio, et see ei oleks nii hull \u2013 see aitab sellegipoolest. Igal juhul on teil suhe kettaga. Ja see toimub vale mustri j\u00e4rgi. Need on vaikimisi parameetrid, mida ma n\u00e4itasin. Ja igal juhul on parem need muuta. <\/p>\n
<\/p>\n
NUMA-ga v\u00f5ivad olla probleemid. VmWare t\u00f6\u00f6tab n\u00e4iteks NUMA-ga h\u00e4sti t\u00e4pselt vastupidiste seadistustega. Siin tuleb valida \u2013 raua server v\u00f5i mitte raua. <\/p>\n
<\/p>\n
Mul on k\u00fcsimus, mis on seotud Amazon AWS-iga. Neil on eelkonfigureeritud pildid. \u00dcks neist nimetatakse Amazon RDS-iks. Kas seal on mingeid kohandatud seadistusi nende operatsioonis\u00fcsteemi jaoks?<\/em><\/p>\n<\/p>\n
Seal on seadistused, kuid need on teistsugused seadistused. Siin seadistame operatsioonis\u00fcsteemi vaatenurgast, kuidas andmebaas seda kasutab. Ja seal on parameetrid, mis m\u00e4\u00e4ravad, kuhu me praegu minema peame, selline shaping. Ehk me vajame nii palju ressursse, me hakkame neid n\u00fc\u00fcd kulutama. P\u00e4rast seda kinnitab Amazon RDS need ressursid, ja sealne j\u00f5udlus kannatab. On eraldi lugusid, kuidas 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 teine lugu.<\/p>\n
<\/p>\n
Miks Transparent huge pages ei toimi v\u00f5rreldes Huge TLB-ga?<\/em><\/p>\n<\/p>\n
Ei toimi. Seda saab selgitada mitmeti. Kuid tegelikult nad lihtsalt ei anna efekti. Mis lugu on PostgreSQLiga? Ta eraldab k\u00e4ivitamisel suure t\u00fcki jagatud m\u00e4lust. Kas nad on transparent v\u00f5i mitte \u2013 see pole absoluutselt oluline. Fakt, et nad eraldatakse k\u00e4ivitamisel, selgitab k\u00f5ike. Ja kui m\u00e4lu on v\u00e4ga palju ja jagatud m\u00e4lu segmenti tuleb \u00fcmber ehitada, siis on Transparent huge pages asjakohased. PostgreSQL eraldab selle lihtsalt k\u00e4ivitamisel tohutu t\u00fcki ja k\u00f5ik, edasi seal midagi erilist ei toimu. Loomulikult v\u00f5ib seda kasutada, kuid on oht saada jagatud m\u00e4lu kahjustusi, kui see p\u00fc\u00fcab midagi uuesti eraldada. 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
![\"Linuxi](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n