serveri<\/a> un viss beig\u0101s non\u0101k SATA cietaj\u0101 disk\u0101 bez jebk\u0101da ke\u0161a, tad viss datu b\u0101zes serveris p\u0101rv\u0113r\u0161as ne vienk\u0101r\u0161i par \u0137irbi, bet par \u0137irbi ar SATA interfeisu. J\u016bs tie\u0161i ar to saskarsieties. Un nekas jums nepal\u012bdz\u0113s.<\/p>\n<\/p>\n
<\/p>\n
Run\u0101jot par pirmo punktu par atmi\u0146u, ir tr\u012bs lietas, kas var stipri apgr\u016btin\u0101t dz\u012bvi. <\/p>\n
<\/p>\n
Pirm\u0101 no t\u0101m ir NUMA. NUMA ir lieta, kas izveidota, lai uzlabotu veiktsp\u0113ju. Atkar\u012bb\u0101 no darba slodzes var optimiz\u0113t da\u017e\u0101das lietas. Un t\u0101s jaunaj\u0101 izskat\u0101 t\u0101d\u0101m aplik\u0101cij\u0101m k\u0101 datu b\u0101ze, kas intens\u012bvi izmanto page cache, nav \u013coti laba. <\/p>\n
<\/p>\n
<\/p>\n
Divos v\u0101rdos. K\u0101 saprast, ka ar NUMA kaut kas nav k\u0101rt\u012bb\u0101? Jums ir k\u0101ds nepat\u012bkams troksnis, p\u0113k\u0161\u0146i k\u0101ds CPU izr\u0101d\u0101s noslogots. Taj\u0101 pa\u0161\u0101 laik\u0101 j\u016bs analiz\u0113jat vaic\u0101jumus PostgreSQL un redzat, ka tur nekas l\u012bdz\u012bgs nav. \u0160iem vaic\u0101jumiem nevajadz\u0113tu tik intens\u012bvi pat\u0113r\u0113t CPU. To var ilgi med\u012bt. Vienk\u0101r\u0161\u0101k ir s\u0101kum\u0101 izmantot pareiz\u0101s rekomend\u0101cijas, k\u0101 iestat\u012bt NUMA PostgreSQL.<\/p>\n
<\/p>\n
<\/p>\n
Kas paties\u012bb\u0101 notiek? NUMA ir Non-Uniform Memory Access. K\u0101ds ir j\u0113ga? Jums ir CPU, un blakus ir t\u0101 lok\u0101l\u0101 atmi\u0146a. Un \u0161\u012b atmi\u0146a interconnects var piek\u013c\u016bt atmi\u0146ai no citiem CPU.<\/p>\n
<\/p>\n
Ja j\u016bs izpild\u012bsiet numactl --hardware<\/code>, tad jums par\u0101d\u012bsies liela lapa. Starp citu tur b\u016bs lauks distances. B\u016bs cipari \u2013 10-20, kaut kas \u0161\u0101d\u0101 gar\u0101. \u0160ie cipari nav nekas cits k\u0101 hopu skaits, lai piek\u013c\u016btu \u0161ai att\u0101lajai atmi\u0146ai un izmantotu to lok\u0101li. Princip\u0101 t\u0101 ir laba ideja. Tas labi pa\u0101trina veiktsp\u0113ju noteiktu slod\u017eu gad\u012bjum\u0101.<\/p>\n<\/p>\n
Tagad iedom\u0101jieties, ka jums ir viens CPU, kas vispirms m\u0113\u0123ina izmantot savu lok\u0101lo atmi\u0146u, tad m\u0113\u0123ina piesaist\u012bt citas atmi\u0146as caur interconnect priek\u0161 k\u0101da. Un \u0161is CPU sa\u0146em visu j\u016bsu PostgreSQL page cache \u2013 visas, cik nu tur gigabaitu. J\u016bs vienm\u0113r sa\u0146emat slikt\u0101ko gad\u012bjumu, jo CPU tie\u0161i \u0161aj\u0101 atmi\u0146as modul\u012b parasti ir maz. Un visa apkalpot\u0101 atmi\u0146a tiek apstr\u0101d\u0101ta caur \u0161iem interconnects. Rezult\u0101ts ir l\u0113ns un skumj\u0161. Un jums ir procesors, kas apkalpo \u0161o mezglu, past\u0101v\u012bgi noslogots. Un \u0161\u012bs atmi\u0146as piek\u013cuves laiks ir slikts, l\u0113ns. T\u0101 ir situ\u0101cija, kuru j\u016bs nev\u0113laties, ja izmantojat to datu b\u0101zei. <\/p>\n
<\/p>\n
T\u0101p\u0113c pareiz\u0101ks variants datu b\u0101zei ir t\u0101ds, lai oper\u0113t\u0101jsist\u0113ma Linux visp\u0101r nezin\u0101tu, kas tur notiek. Lai t\u0101 piek\u013c\u016btu atmi\u0146ai t\u0101, k\u0101 tam vajag. <\/p>\n
<\/p>\n
K\u0101p\u0113c t\u0101? Izskat\u0101s, ka tam vajadz\u0113tu b\u016bt pret\u0113ji. Tas notiek vienas vienk\u0101r\u0161as iemesla d\u0113\u013c: mums page cache ir nepiecie\u0161ama liela atmi\u0146a \u2013 desmitiem, simtiem gigabaitu. <\/p>\n
<\/p>\n
Un, ja m\u0113s to visu esam pie\u0161\u0137\u012bru\u0161i un apstr\u0101d\u0101ju\u0161i m\u016bsu datus tur, ieguvums no ke\u0161a izmanto\u0161anas b\u016bs iev\u0113rojami liel\u0101ks nek\u0101 ieguvums no t\u0101da izsmalcin\u0101ta piek\u013cuves veida atmi\u0146ai. Un \u0161\u0101d\u0101 veid\u0101 mums b\u016bs nep\u0101rsp\u0113jams ieguvums, sal\u012bdzinot to, ka m\u0113s efekt\u012bv\u0101k piek\u013c\u016bsim atmi\u0146ai, izmantojot NUMA.<\/p>\n
<\/p>\n
T\u0101p\u0113c \u0161obr\u012bd ir divi pieejamie pieg\u0101jieni, kam\u0113r gai\u0161\u0101 n\u0101kotne nav pien\u0101kusi, un datu b\u0101ze nem\u0101c\u0101s pati saprast, uz k\u0101diem CPU t\u0101 str\u0101d\u0101 un no kurienes tai kaut kas j\u0101ieg\u016bst. <\/p>\n
<\/p>\n
<\/p>\n
T\u0101p\u0113c pareizais pieg\u0101jiens ir visp\u0101r atsl\u0113gt NUMA<\/strong>, piem\u0113ram, pie restart\u0113\u0161anas. Liel\u0101kaj\u0101 da\u013c\u0101 gad\u012bjumu ieguvumi ir tik lieli, ka jaut\u0101jums, k\u0101 lab\u0101k, visp\u0101r nerodas. <\/p>\n<\/p>\n
Ir v\u0113l viena iesp\u0113ja. M\u0113s to bie\u017e\u0101k izmantojam nek\u0101 pirmo, jo, kad uz m\u016bsu atbalstu v\u0113r\u0161as klients, servera restart\u0113\u0161ana vi\u0146am ir liels darbs. Vi\u0146am tur uz\u0146\u0113mums str\u0101d\u0101. Un vi\u0146i piedz\u012bvo probl\u0113mas ar NUMA. T\u0101p\u0113c m\u0113s cen\u0161amies atsl\u0113gt maz\u0101k invaz\u012bv\u0101 veid\u0101, nek\u0101 restart\u0113jot, bet \u0161eit uzman\u012bgi j\u0101p\u0101rbauda, vai tas ir atsl\u0113gts. Jo, k\u0101 pier\u0101da pieredze, atsl\u0113g\u0161ana uz PostgreSQL m\u0101tes procesu NUMA ir laba, tom\u0113r nav visp\u0101r garant\u0113ts, ka tas darbosies. J\u0101skat\u0101s un j\u0101p\u0101rbauda, vai tas tie\u0161\u0101m ir atsl\u0113gts. <\/p>\n
<\/p>\n
Ir ir labs ieraksts no Robert Haas. Vi\u0146\u0161 ir viens no PostgreSQL komitejas locek\u013ciem. Viens no galvenajiem izstr\u0101d\u0101t\u0101jiem visiem zem\u0101ko sl\u0101\u0146u tehniskajiem aspektiem. Un, ja izp\u0113t\u012bsit saites no \u0161\u012b ieraksta, tur ir aprakst\u012btas vair\u0101kas kr\u0101\u0161\u0146as st\u0101stu par to, k\u0101 NUMA apgr\u016btin\u0101ja cilv\u0113ku dz\u012bvi. Apskatiet, izp\u0113tiet sist\u0113admina kontrolsarakstu par to, ko nepiecie\u0161ams iestat\u012bt server\u012b, lai m\u016bsu datub\u0101ze darbotu labi. \u0160os iestat\u012bjumus ir j\u0101pieraksta un j\u0101p\u0101rbauda, jo cit\u0101di viss var\u0113tu neb\u016bt tik labi. <\/p>\n
<\/p>\n
V\u0113r\u0161u uzman\u012bbu, ka tas attiecas uz visiem iestat\u012bjumiem, par kuriem es run\u0101\u0161u. Bet parasti datub\u0101zes tiek veidotas master-slave re\u017e\u012bm\u0101, lai nodro\u0161in\u0101tu notur\u012bbu pret k\u013c\u016bd\u0101m. Neaizmirstiet veikt \u0161os iestat\u012bjumus uz slave, jo k\u0101d\u0101 br\u012bd\u012b jums var notikt av\u0101rija, un jums b\u016bs j\u0101p\u0101rsl\u0113dzas uz slave, kur\u0161 k\u013c\u016bs par Master. <\/p>\n
<\/p>\n
Av\u0101rijas situ\u0101cij\u0101, kad viss ir \u013coti slikti, j\u016bsu telefons past\u0101v\u012bgi zvan\u012bs, un vad\u012bt\u0101js ierad\u012bsies ar lielu n\u016bju, jums neb\u016bs laika dom\u0101t par to, lai p\u0101rbaud\u012btu. Un rezult\u0101ti var b\u016bt \u0101rk\u0101rt\u012bgi b\u0113d\u012bgi.<\/p>\n
<\/p>\n
<\/p>\n
N\u0101kam\u0101 lieta \u2013 tas ir huge pages. Huge pages ir gr\u016bti p\u0101rbaud\u012bt atsevi\u0161\u0137i, un tam nav \u012bsti j\u0113gas, kaut ar\u012b ir veiktsp\u0113jas testi, kas to prot dar\u012bt. Tie viegli atrodami internet\u0101. <\/p>\n
<\/p>\n
K\u0101ds ir j\u0113ga? Jums ir ne p\u0101r\u0101k d\u0101rgs serveris, kur\u0101 ir daudz operat\u012bv\u0101s atmi\u0146as, piem\u0113ram, vair\u0101k par 30 GB. Jums netiek izmantoti huge pages. Tas noz\u012bm\u0113, ka jums nep\u0101rprotami ir atmi\u0146as overhead, un \u0161is overhead ir t\u0101lu nepat\u012bkams. <\/p>\n
<\/p>\n
<\/p>\n
K\u0101p\u0113c t\u0101? Un kas notiek? Oper\u0113t\u0101jsist\u0113ma sadala atmi\u0146u mazos gabali\u0146os. Tas ir \u0113rti, t\u0101 ir v\u0113sturiski izveidota k\u0101rt\u012bba. Un, ja iedzi\u013cin\u0101mies deta\u013c\u0101s, tad oper\u0113t\u0101jsist\u0113mai ir j\u0101p\u0101rveido virtu\u0101l\u0101s adreses fiziskaj\u0101s. Un \u0161is ir diezgan sare\u017e\u0123\u012bts process, t\u0101p\u0113c oper\u0113t\u0101jsist\u0113ma \u0161\u012bs oper\u0101cijas rezult\u0101tu ke\u0161\u0113 tuv\u0101kaj\u0101 Translation Lookaside Buffer (TLB).<\/p>\n
<\/p>\n
Un, t\u0101 k\u0101 TLB ir ke\u0161atmi\u0146a, tad \u0161\u0101d\u0101 situ\u0101cij\u0101 rodas visas rakstur\u012bg\u0101s ke\u0161atmi\u0146as probl\u0113mas. Pirmk\u0101rt, ja jums ir \u013coti daudz operat\u012bv\u0101s atmi\u0146as, un t\u0101 visa ir sadal\u012bta mazos gabali\u0146os, tad \u0161is buferis k\u013c\u016bst \u013coti liels. Un, ja ke\u0161a buferis ir liels, tad mekl\u0113\u0161ana taj\u0101 notiek l\u0113n\u0101k. Overhead ir liels, un tas pats aiz\u0146em vietu, t.i., operat\u012bvo atmi\u0146u pat\u0113r\u0113 kaut kas nepareizs. Tas ir viens. <\/p>\n
<\/p>\n
Divi \u2013 jo liel\u0101ks ke\u0161atmi\u0146as apm\u0113rs \u0161\u0101d\u0101 situ\u0101cij\u0101, jo liel\u0101ka ir iesp\u0113ja, ka b\u016bs ke\u0161atmi\u0146as tr\u016bkumi. Un \u0161\u012bs ke\u0161atmi\u0146as efektivit\u0101te strauji samazin\u0101s ar t\u0101s lieluma pieaugumu. T\u0101p\u0113c oper\u0113t\u0101jsist\u0113m\u0101s tika izstr\u0101d\u0101ta vienk\u0101r\u0161a pieeja. Linux to jau ilgu laiku izmanto. FreeBSD to nesen ieviesa. Tom\u0113r m\u0113s run\u0101jam par Linux. Tas ir huge pages.<\/p>\n
<\/p>\n
Un \u0161eit j\u0101atz\u012bm\u0113, ka huge pages, k\u0101 ideja, s\u0101kotn\u0113ji tika virz\u012bta kopienu, tostarp Oracle un IBM, v\u0101rd\u0101, t.i., datu b\u0101zu ra\u017eot\u0101ji nopietni dom\u0101ja, ka tas b\u016bs noder\u012bgi, ar\u012b datu b\u0101z\u0113m. <\/p>\n
<\/p>\n
<\/p>\n
Un k\u0101 to savienot ar PostgreSQL? Pirmk\u0101rt, Linux kodol\u0101 ir j\u0101b\u016bt iesl\u0113gtiem huge pages.<\/p>\n
<\/p>\n
Otrk\u0101rt, tie skaidri j\u0101nor\u0101da ar sysctl parametru \u2013 cik daudz to ir. Skait\u013ci \u0161eit ir no k\u0101da vec\u0101 servera. J\u016bs varat apr\u0113\u0137in\u0101t, cik aptuveni jums ir shared buffers, lai huge pages tajos ietilptu. <\/p>\n
<\/p>\n
Un, ja j\u016bs visu serveri esat atdevu\u0161i PostgreSQL, tad laba s\u0101kumpunkts ir vai nu 25 % no operat\u012bv\u0101s atmi\u0146as atv\u0113l\u0113t shared buffers, vai 75 %, ja esat p\u0101rliecin\u0101ti, ka j\u016bsu datu b\u0101ze 75 % noteikti ietilps. Pirmais s\u0101kumpunkts. Un apr\u0113\u0137iniet, ja jums ir 256 GB operat\u012bv\u0101s atmi\u0146as, tad attiec\u012bgi 64 GB jums b\u016bs shared buffers. Aptuveni apr\u0113\u0137iniet ar nelielu rezervi \u2013 k\u0101dai j\u0101b\u016bt \u0161ai v\u0113rt\u012bbai.<\/p>\n
<\/p>\n
L\u012bdz versijai 9.2 (ja nemaldos, s\u0101kot no versijas 8.2) var\u0113ja ar tre\u0161o pu\u0161u bibliot\u0113ku savienot PostgreSQL ar huge pages. Un to vienm\u0113r vajag dar\u012bt. Pirmk\u0101rt, jums ir j\u0101p\u0101rliecin\u0101s, ka kodols prot pareizi pie\u0161\u0137irt huge pages. Un, otrk\u0101rt, lai lietojumprogramma, kas ar t\u0101m str\u0101d\u0101, var\u0113tu t\u0101m piek\u013c\u016bt. Vienk\u0101r\u0161i t\u0101 tas nedarbosies. T\u0101 k\u0101 PostgreSQL pie\u0161\u0137\u012bra atmi\u0146u System V stil\u0101, to var\u0113ja izdar\u012bt, izmantojot libhugetlbfs \u2014 tas ir pilnais bibliot\u0113kas nosaukums.<\/p>\n
<\/p>\n
Versij\u0101 9.3 tika uzlabota PostgreSQL veiktsp\u0113ja, str\u0101d\u0101jot ar atmi\u0146u, un tika atteikts izmantot 5. sist\u0113mas metodi atmi\u0146as pie\u0161\u0137ir\u0161anai. Visi bija \u013coti priec\u012bgi, jo pret\u0113j\u0101 gad\u012bjum\u0101, m\u0113\u0123inot palaist divus PostgreSQL instancus uz viena datora, t\u0101 saka, ka man tr\u016bkst kop\u0113j\u0101s atmi\u0146as. Un saka, ka j\u0101labo sysctl. Tur ir t\u0101ds sysctl, ka j\u0101reboot\u0113 un t\u0101 t\u0101l\u0101k. Kopum\u0101, visi bija priec\u012bgi. Bet mmap atmi\u0146as pie\u0161\u0137ir\u0161ana p\u0101rtrauca huge pages izmanto\u0161anu. Mums liel\u0101k\u0101 da\u013ca klientu izmanto lielus kop\u0113jos buferus. Un m\u0113s uzst\u0101j\u0101m, ka nevajadz\u0113tu p\u0101riet uz 9.3, jo tur p\u0101rslodze s\u0101k\u0101s skait\u0101mos procentos.<\/p>\n
<\/p>\n
Bet \u0161aj\u0101 laik\u0101 kopiena piev\u0113rsa uzman\u012bbu \u0161ai probl\u0113mai, un versij\u0101 9.4 tika \u013coti labi p\u0101rstr\u0101d\u0101ta \u0161\u012b funkcija. Un 9.4 par\u0101d\u012bj\u0101s parametrs postgresql.conf, kur\u0101 var iesl\u0113gt try, on vai off.<\/p>\n
<\/p>\n
Try \u2013 tas ir visdro\u0161\u0101kais parametrs. Palaidot PostgreSQL, kad tas pie\u0161\u0137ir kop\u0113jo atmi\u0146u, tas m\u0113\u0123ina ieg\u016bt \u0161o atmi\u0146u no huge pages. Un, ja tas neizdodas, tas atgrie\u017eas uz parasto pie\u0161\u0137ir\u0161anu. Un, ja jums ir FreeBSD vai Solaris, tad j\u016bs varat iestat\u012bt try, tas vienm\u0113r ir dro\u0161i. <\/p>\n
<\/p>\n
Ja ir on, tad tas vienk\u0101r\u0161i nes\u0101ksies, ja nevar\u0113s pie\u0161\u0137irt no huge pages. \u0160eit jau \u2013 k\u0101dam tas ir lab\u0101k. Bet, ja jums ir try, tad p\u0101rbaudiet, vai jums tie\u0161\u0101m ir pie\u0161\u0137irta vajadz\u012bg\u0101 atmi\u0146a, jo tur ir daudz k\u013c\u016bdu iesp\u0113ju. \u0160obr\u012bd \u0161\u012b funkcionalit\u0101te darbojas tikai Linux.<\/p>\n
<\/p>\n
V\u0113l viens neliels nov\u0113rojums, pirms ejam t\u0101l\u0101k. Transparent huge pages \u2013 tas v\u0113l nav par PostgreSQL. To norm\u0101li izmantot tas nevar. Un ar Transparent huge pages \u0161\u0101da darba slodzes gad\u012bjum\u0101, kad nepiecie\u0161ama liela da\u013ca kop\u0113j\u0101s atmi\u0146as, priek\u0161roc\u012bbas par\u0101d\u0101s tikai pie \u013coti lieliem apjomiem. Ja jums ir terabaiti atmi\u0146as, tad tas var sp\u0113l\u0113t lomu. Ja run\u0101jam par ikdieni\u0161\u0137\u0101m lietojumprogramm\u0101m, kad jums ir 32, 64, 128, 256 GB atmi\u0146as uz ma\u0161\u012bnas, tad parastie huge pages ir labi, bet Transparent vienk\u0101r\u0161i izsl\u0113dzam. <\/p>\n
<\/p>\n
<\/p>\n
Un p\u0113d\u0113j\u0101 lieta, kas saist\u012bta ar atmi\u0146u, tie\u0161i nav saist\u012bta ar caurlaidsp\u0113ju, t\u0101 var \u013coti trauc\u0113t dz\u012bvi. Visa caurlaidsp\u0113ja iev\u0113rojami cie\u0161 no t\u0101, ka serveris past\u0101v\u012bgi swap'ojas. <\/p>\n
<\/p>\n
Un tas b\u016bs \u013coti nepat\u012bkami vair\u0101k\u0101s situ\u0101cij\u0101s. Galven\u0101 nepatik\u0161ana ir t\u0101, ka m\u016bsdienu kodoli nedaudz at\u0161\u0137iras no vec\u0101kiem Linux kodoliem. Tas ir jaut\u0101jums, uz kura nepat\u012bkami uzk\u0101pt, jo, kad m\u0113s run\u0101jam par darbu ar swap, tas beidzas ar OOM-killer ne savlaic\u012bgu iejauk\u0161anos. Un OOM-killer, kur\u0161 neierad\u0101s savlaic\u012bgi un no\u0146\u0113ma PostgreSQL, ir nepat\u012bkami. Par to uzzin\u0101s visi, t.i., l\u012bdz p\u0113d\u0113jam lietot\u0101jam. <\/p>\n
<\/p>\n
<\/p>\n
Kas notiek? Jums tur ir liels operat\u012bv\u0101s atmi\u0146as apjoms, viss labi str\u0101d\u0101. Bet kaut k\u0101d\u0101 veid\u0101 serveris iestr\u0113gst swap un pal\u0113nin\u0101s d\u0113\u013c t\u0101. Izskat\u0101s, ka atmi\u0146as ir daudz, bet t\u0101 tom\u0113r notiek. <\/p>\n
<\/p>\n
<\/p>\n
Agr\u0101k m\u0113s ieteic\u0101m iestat\u012bt vm.swappiness uz nulli, t.i., atsl\u0113gt swap. Agr\u0101k lik\u0101s, ka 32 GB operat\u012bv\u0101s atmi\u0146as un attiec\u012bgi dal\u012btie buferi ir milz\u012bgs apjoms. Galvenais swap uzdevums ir, lai b\u016btu vieta, kur iemest kodolu, ja m\u0113s avar\u0113jam. Un tas vairs \u012bsti netika paveikts. Un ko tad dar\u012bs ar \u0161o kodolu? T\u0101 jau ir probl\u0113ma, kad neskaidri saprot, k\u0101p\u0113c swap ir nepiecie\u0161ams, \u012bpa\u0161i t\u0101d\u0101 apjom\u0101. <\/p>\n
<\/p>\n
Tom\u0113r m\u016bsdien\u012bg\u0101kos, t.i., tre\u0161\u0101s versijas kodolos uzved\u012bba ir main\u012bjusies. Un, ja iestat\u012bsiet swap uz nulli, t.i., izsl\u0113gsiet to, dr\u012bz vai v\u0113l\u0101k, pat ja atlicis k\u0101ds operat\u012bv\u0101s atmi\u0146as apjoms, pie jums ierad\u012bsies OOM-killer, lai nogalin\u0101tu visintens\u012bv\u0101kos pat\u0113r\u0113t\u0101jus. Jo tas uzskat\u012bs, ka pie t\u0101da darba slodzes mums v\u0113l ir mazliet un m\u0113s izbeigsimies, t.i., nevis nogalin\u0101t sist\u0113mas procesu, bet nogalin\u0101t ko maz\u0101k svar\u012bgu. Tas maz\u0101k svar\u012bgais izr\u0101d\u012bsies intens\u012bvais dal\u012bt\u0101s atmi\u0146as pat\u0113r\u0113t\u0101js, proti, postmaster. Un p\u0113c tam b\u016bs labi, ja datub\u0101zi neb\u016bs j\u0101p\u0101rstruktur\u0113. <\/p>\n
<\/p>\n
T\u0101d\u0113\u013c pa\u0161laik p\u0113c man\u0101m atmi\u0146\u0101m liel\u0101k\u0101 da\u013ca distrib\u016bciju \u2013 tas ir kaut kur 6, t.i., kad s\u0101kt izmantot swap atkar\u012bb\u0101 no t\u0101, cik daudz atmi\u0146as palicis. M\u0113s pa\u0161laik iesak\u0101m iestat\u012bt vm.swappiness = 1, jo tas praktiski to izsl\u0113dz, bet nenoved pie t\u0101diem efektiem k\u0101 ar negaid\u012bti ierad\u012bsies OOM-killer un visu \u0161o lietu nogalin\u0101s.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Kas t\u0101l\u0101k? Kad run\u0101jam par datu b\u0101zu veiktsp\u0113ju un pak\u0101peniski p\u0101rn\u0101kam uz diskiem, visi s\u0101k satraukti satvert galvas. Jo paties\u012bba, ka disks ir l\u0113ns un atmi\u0146a \u0101tra, visiem no b\u0113rn\u012bbas ir paz\u012bstama. Un visi zina, ka datu b\u0101z\u0113m b\u016bs probl\u0113mas ar diska veiktsp\u0113ju.<\/p>\n
<\/p>\n
Pamatprobl\u0113ma ar PostgreSQL veiktsp\u0113ju, kas saist\u012bta ar checkpoints spikes, rodas nevis t\u0101p\u0113c, ka disks ir l\u0113ns. Tas dr\u012bz\u0101k ir saist\u012bts ar to, ka atmi\u0146as un diska caurlaidsp\u0113ja nav l\u012bdzsvarota. Turkl\u0101t t\u0101s var b\u016bt nel\u012bdzsvarotas da\u017e\u0101dos viet\u0101s. PostgreSQL nav pareizi konfigur\u0113ts, oper\u0113t\u0101jsist\u0113ma nav konfigur\u0113ta, aparat\u016bra nav konfigur\u0113ta un aparat\u016bra ir nepareiza. \u0160\u012b probl\u0113ma nenotiek tikai tad, ja viss notiek k\u0101 vajag, t.i., ja vai nu slodzes nav, vai nu iestat\u012bjumi un aparat\u016bra ir labi izv\u0113l\u0113ti. <\/p>\n
<\/p>\n
<\/p>\n
Kas tas ir un k\u0101 tas izskat\u0101s? Parasti cilv\u0113ki, kuri str\u0101d\u0101 ar PostgreSQL, ir \u0161aj\u0101 proces\u0101 piedal\u012bju\u0161ies ne reizi vien. Es paskaidro\u0161u. K\u0101 jau teicu, PostgreSQL periodiski veic checkpoints, lai net\u012br\u0101s lapas kop\u0113j\u0101 atmi\u0146\u0101 p\u0101rvietotu uz disku. Ja mums ir liels kop\u0113j\u0101s atmi\u0146as apjoms, tad checkpoints s\u0101k intens\u012bvi ietekm\u0113t disku, jo p\u0101rvieto \u0161\u012bs lapas uz fsync. Tas non\u0101k kodola bufer\u012b un tiek ierakst\u012bts diskos, izmantojot fsync. Un, ja \u0161\u012b apjoma ir liels, m\u0113s varam nov\u0113rot nepat\u012bkamu efektu, proti, \u013coti lielu disku noslodzi.<\/p>\n
<\/p>\n
\u0160eit man ir divas bildes. Es tagad paskaidro\u0161u, kas tas ir. Tas ir divi ar laiku kori\u0123\u0113ti grafiki. Pirmais grafiks \u2013 tas ir diska noslodze. \u0160eit tas sasniedz gandr\u012bz 90% \u0161aj\u0101 laika br\u012bd\u012b. Ja jums ir datu b\u0101ze ar fiziskiem diskiem un RAID kontrolieri, kura noslodze tuvojas 90%, tad tas ir slikti jaunumi. Tas noz\u012bm\u0113, ka v\u0113l nedaudz un tas sasniegs 100 un ievades-ievades tiks apst\u0101din\u0101ta. <\/p>\n
<\/p>\n
Ja jums ir diska mas\u012bvs, tad tur ir nedaudz cita st\u0101sta. Tas atkar\u012bgs no t\u0101, k\u0101 tas ir konfigur\u0113ts, k\u0101ds ir mas\u012bvs utt. <\/p>\n
<\/p>\n
Vienlaikus \u0161eit ir konfigur\u0113ts grafiks no iek\u0161\u0113j\u0101s PostgreSQL skata, kas nor\u0101da, k\u0101 notiek checkpoint. Za\u013caj\u0101 kr\u0101s\u0101 ir par\u0101d\u012bts buferu skaits, t. i., cik daudz net\u012bro lapu \u0161aj\u0101 br\u012bd\u012b tika p\u0101rs\u016bt\u012bts \u0161im checkpoint, lai sinhroniz\u0113tos. Un tas ir galvenais, kas \u0161eit ir j\u0101zina. M\u0113s redzam, ka mums ir daudz lapu, un k\u0101d\u0101 br\u012bd\u012b m\u0113s non\u0101kam pie ierobe\u017eojuma, t. i., rakst\u012bj\u0101m rakst\u012bj\u0101m, \u0161eit ac\u012bmredzot disk sist\u0113ma ir \u013coti aiz\u0146emta. Un m\u016bsu checkpoint \u013coti sp\u0113c\u012bgi ietekm\u0113 disku. Ide\u0101l\u0101 situ\u0101cija izskat\u012btos dr\u012bz\u0101k \u0161\u0101di, t. i., mums \u0161eit b\u016btu maz\u0101k ierakstu. Un ar iestat\u012bjumiem m\u0113s varam to salabot, lai tas turpin\u0101tos. T. i., noslodze ir neliela, bet kaut kur m\u0113s \u0161eit rakst\u0101m. <\/p>\n
<\/p>\n
Ko dar\u012bt, lai uzvar\u0113tu \u0161o probl\u0113mu? Ja jums ir apst\u0101jies I\/O datu b\u0101z\u0113, tas noz\u012bm\u0113, ka visi lietot\u0101ji, kuri ir piekritu\u0161i izpild\u012bt savus piepras\u012bjumus, gaid\u012bs. <\/p>\n
<\/p>\n
<\/p>\n
Ja skat\u0101s no Linux skatpunkta, ja esat pa\u0146\u0113mis labu aparat\u016bru, pareizi to iestat\u012bjis, norm\u0101li konfigur\u0113jis PostgreSQL, lai tas reti veiktu \u0161os checkpointus, izstiepjot tos laika gait\u0101, tad j\u016bs non\u0101kat pie Debian noklus\u0113juma parametriem. Liel\u0101kajai da\u013cai Linux distrib\u016bciju \u0161\u0101da aina: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
Ko tas noz\u012bm\u0113? Ar kodu 2.6 par\u0101d\u012bj\u0101s viens fons, kas veic flushing. Pgflush, atkar\u012bb\u0101 no t\u0101, ko k\u0101ds izmanto, kas nodarbojas ar net\u012bro lapu izsnieg\u0161anu no kodola bufera un izsnieg\u0161anu, kad ir nepiecie\u0161ams nekav\u0113joties izsniegt net\u012bras lapas, kad fona izsnieg\u0161ana vairs nepal\u012bdz. <\/p>\n
<\/p>\n
Kad s\u0101kas fons? Kad 10 % no visas operat\u012bv\u0101s atmi\u0146as, kas ir server\u012b, ir aiz\u0146emti ar net\u012br\u0101m lap\u0101m kodola bufer\u012b, tiek izsaukta \u012bpa\u0161a funkcija fona izsnieg\u0161anai. K\u0101p\u0113c t\u0101 ir fona? T\u0101 k\u0101 parametru t\u0101 pie\u0146em, cik lapas izsniegt. Un, pie\u0146emsim, izsniedz N lapas. Un uz k\u0101du laiku \u0161\u012b funkcija aizmieg. Un tad t\u0101 atkal n\u0101k un izsniedz v\u0113l k\u0101du lapu skaitu. <\/p>\n
<\/p>\n
Tas ir \u013coti vienk\u0101r\u0161s st\u0101sts. \u0160eit uzdevums ir k\u0101 ar baseinu, kad vien\u0101 caurul\u0113 iepl\u016bst, otr\u0101 izpl\u016bst. Mums ir ieraksts un, ja tas nos\u016bt\u012bjis maz net\u012bro lapu uz izsnieg\u0161anu, tad pak\u0101peniski no kodola bufera pgflush viss tiks uzman\u012bgi izklied\u0113ts. <\/p>\n
<\/p>\n
Ja, ja turpina uzkr\u0101ties \u0161\u012bm net\u012braj\u0101m lap\u0101m, t\u0101s uzkr\u0101jas l\u012bdz 20 %. P\u0113c tam oper\u0113t\u0101jsist\u0113mai ir priorit\u0101te visu \u0161o uzrakst\u012bt disk\u0101, jo var izsl\u0113gties str\u0101va, un mums viss b\u016bs slikti. M\u0113s zaud\u0113sim \u0161os datus, piem\u0113ram. <\/p>\n
<\/p>\n
Kas ir triks? Triks ir taj\u0101, ka \u0161ie parametri m\u016bsdienu pasaul\u0113, 20 un 10 % no visas operat\u012bv\u0101s atmi\u0146as, kas ir uz ma\u0161\u012bnas, ir \u0101rk\u0101rt\u012bgi augsts slogs jebkurai diskosist\u0113mai, kas jums ir.<\/strong> <\/p>\n<\/p>\n
Iedom\u0101jieties, ka jums ir 128 GB operat\u012bv\u0101s atmi\u0146as. 12,8 GB non\u0101k j\u016bsu diskosist\u0113m\u0101. Un, k\u0101ds b\u016btu j\u016bsu ke\u0161atmi\u0146as tips vai mas\u012bvs, tas nevar\u0113s iztur\u0113t tik daudz. <\/p>\n
<\/p>\n
<\/p>\n
T\u0101d\u0113\u013c m\u0113s iesak\u0101m \u0161os skait\u013cus uzreiz noregul\u0113t, \u0146emot v\u0113r\u0101 j\u016bsu RAID kontroliera iesp\u0113jas.<\/strong> Man \u0161eit ir sniegta ieteikums kontrolierim ar 512 MB ke\u0161atmi\u0146u. <\/p>\n<\/p>\n
Visu uzskait\u012bt ir \u013coti vienk\u0101r\u0161i. Varat iestat\u012bt vm.dirty_background byte form\u0101t\u0101. Un \u0161ie iestat\u012bjumi atce\u013c iepriek\u0161\u0113jos divus. Vai nu noklus\u0113juma proporcija, vai aktiviz\u0113 t\u0101s, kas ir byte form\u0101t\u0101, un str\u0101d\u0101s t\u0101s, kas ir byte form\u0101t\u0101. Bet, t\u0101 k\u0101 es esmu DBA konsultants un str\u0101d\u0101ju ar da\u017e\u0101diem klientiem, es cen\u0161os b\u016bt piesardz\u012bgs un t\u0101d\u0113\u013c, ja byte, tad byte. Neviens nav devis nek\u0101das garantijas, ka labs administrators nepapildin\u0101s serverim atmi\u0146u, un restart\u0113s to, bet skaitlis paliks t\u0101ds pats. Vienk\u0101r\u0161i apr\u0113\u0137iniet \u0161os skait\u013cus, lai j\u016bs var\u0113tu b\u016bt dro\u0161i, ka viss iek\u013causies. <\/p>\n
<\/p>\n
Kas notiks, ja neiek\u013causieties? Man ir nor\u0101d\u012bts, ka efekt\u012bvi tiek aptur\u0113ta jebkura flushing, bet paties\u012bb\u0101 t\u0101 ir izteiksmes forma. Oper\u0113t\u0101jsist\u0113mai ir liela probl\u0113ma - tai ir daudz net\u012bro lapu, t\u0101p\u0113c efekt\u012bvi tiek aptur\u0113ta jebkura IO, ko rada j\u016bsu klienti, tas ir, ja k\u0101ds SQL piepras\u012bjums tiek nos\u016bt\u012bts uz datu b\u0101zi, tas gaida. Jebkura ievade-izvade tiek veikta zem\u0101k\u0101 priorit\u0101t\u0113, jo datu b\u0101ze ir aiz\u0146emta ar checkpoint. Un kad t\u0101 beigsies, nav skaidrs. Un, ja esat sasniedzis ne fona, ne aizmugures flushing, tas noz\u012bm\u0113, ka viss j\u016bsu IO ir aiz\u0146emts ar to. Un l\u012bdz tam tas netiks izdar\u012bts. <\/p>\n
<\/p>\n
\u0160eit ir v\u0113l divi svar\u012bgi aspekti, kas izn\u0101k \u0101rpus \u0161\u012b zi\u0146ojuma. \u0160iem iestat\u012bjumiem vajadz\u0113tu saskan\u0113t ar iestat\u012bjumiem postgresql.conf, t.i., checkpoint iestat\u012bjumiem. Un j\u016bsu diskosist\u0113mai j\u0101b\u016bt pien\u0101c\u012bgi konfigur\u0113tai. Ja jums ir RAID ke\u0161atmi\u0146a, taj\u0101 j\u0101b\u016bt baterijai.<\/strong> Cilv\u0113ki p\u0113rk RAID ar labu ke\u0161atmi\u0146u bez baterijas. Ja jums ir SSD RAID, tad tiem j\u0101b\u016bt servera versijai, un tajos j\u0101b\u016bt kondensatoriem.<\/strong> \u0160eit ir detaliz\u0113ta p\u0101rbaudes saraksts. \u0160aj\u0101 saist\u0113 ir mans refer\u0101ts par to, k\u0101 konfigur\u0113t diska veiktsp\u0113ju PostgreSQL. Tur ir visi \u0161ie p\u0101rbaudes saraksti. <\/p>\n<\/p>\n
<\/p>\n
Kas v\u0113l var \u013coti sare\u017e\u0123\u012bt dz\u012bvi? Tie ir divi parametri. Tie ir sal\u012bdzino\u0161i jauni. Tie p\u0113c noklus\u0113juma var b\u016bt iesl\u0113gti da\u017e\u0101d\u0101s lietotn\u0113s. Un tie var sare\u017e\u0123\u012bt dz\u012bvi ne maz\u0101k, ja tie tiek nepareizi iesl\u0113gti. <\/p>\n
<\/p>\n
<\/p>\n
Ir divas relat\u012bvi jaunas lietas. T\u0101s jau par\u0101d\u012bj\u0101s tre\u0161aj\u0101s kodol\u0101s. Tas ir sched_migration_cost nanosekund\u0113s un sched_autogroup_enabled, kur\u0161 p\u0113c noklus\u0113juma ir viens. <\/p>\n
<\/p>\n
Un k\u0101 t\u0101s boj\u0101 dz\u012bvi? Kas ir sched_migration_cost? Linux pl\u0101not\u0101js var migr\u0113t procesu no viena CPU uz citu. Un PostgreSQL, kas izpilda vaic\u0101jumus, migr\u0101cija uz citu CPU ir piln\u012bgi neskaidra. No oper\u0113t\u0101jsist\u0113mas viedok\u013ca, kad j\u016bs p\u0101rsl\u0113dzat logus starp OpenOffice un termin\u0101li, tas var b\u016bt labi, bet datub\u0101z\u0113m \u2013 tas ir \u013coti slikti.<\/strong> T\u0101p\u0113c sapr\u0101t\u012bga politika ir iestat\u012bt migration_cost uz k\u0101du lielu v\u0113rt\u012bbu, vismaz da\u017eus t\u016bksto\u0161us nanosekun\u017eu.<\/strong> <\/p>\n<\/p>\n
Ko tas noz\u012bm\u0113s pl\u0101not\u0101jam? Tas tiks uzskat\u012bts, ka \u0161aj\u0101 laik\u0101 process joproj\u0101m ir karsts. T.i., ja jums ir kaut k\u0101da ilga transakcija, kas kaut ko ilgsto\u0161i veic, tad pl\u0101not\u0101js to saprat\u012bs. Vi\u0146\u0161 uzskat\u012bs, ka, kam\u0113r \u0161is laiks nav pag\u0101jis, migr\u0113t \u0161o procesu nav nepiecie\u0161ams. Ja \u0161aj\u0101 laik\u0101 process kaut ko dara, tad tas netiks migr\u0113ts nekur, un tas mier\u012bgi pabeigs darbu taj\u0101 CPU, kuru vi\u0146am ir pie\u0161\u0137\u012bris. Un rezult\u0101ts ir lielisks. <\/p>\n
<\/p>\n
Otrais moments \u2013 tas ir autogroup. Ir laba ideja specifisk\u0101m darba slodz\u0113m, kas nav saist\u012btas ar m\u016bsdienu datub\u0101z\u0113m \u2013 grup\u0113t procesus p\u0113c t\u0101 virtu\u0101l\u0101 termin\u0101la, no kura tie ir palaisti. Tas ir \u0113rti noteikt\u0101m uzdevumu grup\u0101m. Praks\u0113 PostgreSQL ir multiplatformu sist\u0113ma ar prefork, kas tiek palaista no viena termin\u0101\u013ca. Jums ir rakst\u012b\u0161anas blo\u0137\u0113\u0161ana, paz\u012bmes un visi j\u016bsu klienta piepras\u012bjumi tiek grup\u0113ti vien\u0101 pl\u0101not\u0101j\u0101, vien\u0101 CPU. Un tie visi laipni gaid\u012bs, kad tas atbr\u012bvosies, lai nevienam netrauc\u0113tu un izmantotu to ilg\u0101k. \u0160\u012b ir situ\u0101cija, kas ir piln\u012bgi nevajadz\u012bga, ja slodze ir liela, t\u0101d\u0113\u013c to ir j\u0101izsl\u0113dz.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Mans kol\u0113\u0123is Aleksejs Lesovskis veica testus ar vienk\u0101r\u0161o pgbench, kur palielin\u0101ja migr\u0101cijas izmaksas par k\u0101rtu un izsl\u0113dza autogroup. At\u0161\u0137ir\u012bba slikt\u0101 aparat\u016br\u0101 izr\u0101d\u012bj\u0101s gandr\u012bz 10 %<\/strong>. Ir diskusijas PostgreSQL e-pasta sarakst\u0101, kur cilv\u0113ki dal\u0101s ar rezult\u0101tiem, k\u0101 l\u012bdz\u012bgas izmai\u0146as ietekm\u0113ja piepras\u012bjumu \u0101trumu par 50 %<\/strong>. \u0160\u0101du st\u0101stu ir diezgan daudz.<\/p>\n<\/p>\n
<\/p>\n
Un visbeidzot par ener\u0123ijas taup\u012b\u0161anas politiku. Ir labi, ka tagad Linux var izmantot kl\u0113pjdator\u0101. Un tam it k\u0101 j\u0101pat\u0113r\u0113 labi akumulatora resurss. Bet p\u0113k\u0161\u0146i izr\u0101d\u0101s, ka server\u012b tas var gad\u012bties ar\u012b. <\/p>\n
<\/p>\n
Turkl\u0101t, ja j\u016bs no k\u0101da hostinga nom\u0101jat serverus, tad \"laipnie\" hostinga<\/a> neuztraucas par to, lai jums b\u016btu lab\u0101ka veiktsp\u0113ja. Vi\u0146u uzdevums ir nodro\u0161in\u0101t, lai vi\u0146u aparat\u016bra tiktu izmantota maksim\u0101li efekt\u012bvi. T\u0101d\u0113\u013c vi\u0146i noklus\u0113juma iestat\u012bjumos var iesl\u0113gt kl\u0113pjdatoru ener\u0123ijas taup\u012b\u0161anas re\u017e\u012bmu oper\u0113t\u0101jsist\u0113m\u0101.<\/p>\n<\/p>\n
Ja j\u016bs server\u012b ar datub\u0101zi intens\u012bv\u0101 slodze izmantojat \u0161os labumus, tad j\u016bsu izv\u0113le ir acpi_cpufreq + performance. Pat ar ondemand jau b\u016bs probl\u0113mas.<\/strong> <\/p>\n<\/p>\n
Intel_pstate ir nedaudz cit\u0101ds draiveris. Un tagad priek\u0161roka tiek dota \u0161im, jo tas ir jaun\u0101ks un lab\u0101k darbojas.<\/p>\n
<\/p>\n
Un attiec\u012bgi governors tikai performance. Ondemand, powersave un viss p\u0101r\u0113jais \u2013 tas nav par jums. <\/p>\n
<\/p>\n
Rezult\u0101ti p\u0113c explain analyze PostgreSQL var at\u0161\u0137irties par vair\u0101kiem pas\u016bt\u012bjumiem, ja j\u016bs iesl\u0113dzat powersave, jo praktiski jums zem datub\u0101zes CPU tiks pl\u0101notas nep\u0101rskat\u0101m\u0101 veid\u0101.<\/p>\n
<\/p>\n
\u0160\u012bs lietas var b\u016bt iesl\u0113gtas noklus\u0113jum\u0101. R\u016bp\u012bgi paskatieties \u2013 vai vi\u0146i nav iesl\u0113gu\u0161i to noklus\u0113jum\u0101. Tas var b\u016bt patie\u0161\u0101m liela probl\u0113ma. <\/p>\n
<\/p>\n
<\/p>\n
Un beig\u0101s es v\u0113l\u0113tos pateikt paldies m\u016bsu DBA komandas PosgreSQL-Consulting pui\u0161iem, proti, Maksam Bogukam un Aleksejam Lesovskim, kuri katru dienu iegulda cen\u0161oties \u0161o darbu padar\u012bt lab\u0101ku. M\u0113s cen\u0161amies dar\u012bt visu iesp\u0113jamo, lai m\u016bsu klientiem viss darbotos. Te ir k\u0101 ar avi\u0101cijas dro\u0161\u012bbas instrukcij\u0101m. Viss ir rakst\u012bts asin\u012bm. Katrs no \u0161iem skr\u016bv\u0113m ir atrasts k\u0101das probl\u0113mas proces\u0101. Es labpr\u0101t dalos ar jums \u0161ajos ieskatos.<\/p>\n
<\/p>\n
Jaut\u0101jumi:<\/p>\n
<\/p>\n
Paldies! Ja, piem\u0113ram, uz\u0146\u0113mums v\u0113las ietaup\u012bt un novietot uz viena servera datu b\u0101zi un aplik\u0101cijas lo\u0123iku, vai ja uz\u0146\u0113mums seko modernai mikroservisu arhitekt\u016brai, kur\u0101 PostgreSQL darbojas konteiner\u0101. K\u0101da ir specifika? Sysctl glob\u0101li ietekm\u0113 visus kodolus. Es neesmu dzird\u0113jis, ka sysctl kaut k\u0101d\u0101 veid\u0101 tiek virtualiz\u0113ts, lai tie str\u0101d\u0101tu atsevi\u0161\u0137i konteiner\u0101. Ir tikai cgroup, un tur ir tikai da\u013c\u0113js kontrole. K\u0101 tas b\u016btu iesp\u0113jams? Vai, ja v\u0113laties veikt optimiz\u0101ciju, palaidiet PostgreSQL uz atsevi\u0161\u0137a fizisk\u0101 servera un optimiz\u0113jiet to?<\/em><\/p>\n<\/p>\n
M\u0113s esam atbild\u0113ju\u0161i uz j\u016bsu jaut\u0101jumu aptuveni trijos veidos. Ja runa ir par fizisko serveri, kuru var optimiz\u0113t utt., tad atsl\u0101binieties, viss darbosies labi bez \u0161\u012bm konfigur\u0101cij\u0101m. Ja jums rodas slodze, kas prasa \u0161\u012bs konfigur\u0101cijas, tad j\u016bs agr\u0101k non\u0101ksiet pie fizisk\u0101 servera nek\u0101 pie \u0161\u012bm konfigur\u0101cij\u0101m.<\/p>\n
<\/p>\n
K\u0101da ir probl\u0113ma? Ja t\u0101 ir virtu\u0101l\u0101 ma\u0161\u012bna, tad, visticam\u0101k, jums b\u016bs daudz probl\u0113mu, piem\u0113ram, ar to, ka liel\u0101k\u0101 da\u013c\u0101 virtu\u0101lo ma\u0161\u012bnu diskam ir diezgan nekonsekventa latentit\u0101te. Pat ja disku caurlaid\u012bba ir laba, viena nepareiza transakcija ievades-izejas oper\u0101cij\u0101, kas b\u016btiski neietekm\u0113 vid\u0113jo caurlaid\u012bbu, kas notika checkpoint vai WAL ierakst\u012b\u0161anas br\u012bd\u012b, padar\u012bs datu b\u0101zi \u013coti cie\u0161amu. Un j\u016bs to paman\u012bsit \u0101tr\u0101k, nek\u0101 tiksiet pie \u0161\u012bm probl\u0113m\u0101m. <\/p>\n
<\/p>\n
Ja jums uz t\u0101 pa\u0161a servera b\u016bs NGINX, tad b\u016bs ar\u012b t\u0101 pati probl\u0113ma. Tas sacent\u012bsies par kop\u0113jo atmi\u0146u. Un l\u012bdz iestr\u0113gumiem, kas te aprakst\u012bti, j\u016bs nenon\u0101ksiet.<\/p>\n
<\/p>\n
Tom\u0113r no otras puses, da\u017ei no \u0161iem parametriem jums tom\u0113r b\u016bs aktu\u0101li. Piem\u0113ram, izmantojot sysctl, j\u0101uzst\u0101da dirty_ratio, lai tas neb\u016btu tik nepr\u0101t\u012bgs \u2013 tas jebkur\u0101 gad\u012bjum\u0101 pal\u012bdz\u0113s. T\u0101 vai cit\u0101di, j\u016bs mijiedarbosities ar disku. Un tas notiks p\u0113c nepareizas sh\u0113mas. Tie ir noklus\u0113juma parametri, kurus es r\u0101d\u012bju. Un jebkur\u0101 gad\u012bjum\u0101 tos lab\u0101k main\u012bt. <\/p>\n
<\/p>\n
Bet ar NUMA var b\u016bt probl\u0113mas. VmWare, piem\u0113ram, labi str\u0101d\u0101 ar NUMA ar tie\u0161i pret\u0113j\u0101m iestat\u012bjumiem. Un \u0161eit ir j\u0101izv\u0113las \u2013 dzelzs serveris vai ne dzelzs. <\/p>\n
<\/p>\n
Man ir jaut\u0101jums, kas saist\u012bts ar Amazon AWS. Vi\u0146iem ir iepriek\u0161 konfigur\u0113ti att\u0113li. Viens no tiem saucas Amazon RDS. Vai tur ir k\u0101di piel\u0101goti iestat\u012bjumi vi\u0146u oper\u0113t\u0101jsist\u0113mai?<\/em><\/p>\n<\/p>\n
Tur ir iestat\u012bjumi, bet tie ir citi iestat\u012bjumi. \u0160eit m\u0113s konfigur\u0113jam oper\u0113t\u0101jsist\u0113mu no aspekta, k\u0101 datu b\u0101ze to izmantos. Un tur ir parametri, kas nosaka, kur mums tagad j\u0101iet, t\u0101ds shapings. Proti, mums ir nepiecie\u0161ams tik daudz resursu, un m\u0113s tos tagad izmantosim. P\u0113c tam Amazon RDS \u0161os resursus pievieno, un tur veiktsp\u0113ja kr\u012btas. Ir atsevi\u0161\u0137as lietas, k\u0101 cilv\u0113ki s\u0101k \u0161aj\u0101 sakar\u0101 eksperiment\u0113t. Da\u017ereiz pat diezgan veiksm\u012bgi. Bet tas nav saist\u012bts ar OS iestat\u012bjumiem. Tas ir k\u0101 m\u0101ko\u0146a hakings. T\u0101 ir cita st\u0101sts.<\/p>\n
<\/p>\n
K\u0101p\u0113c Transparent huge pages nedod efektu sal\u012bdzin\u0101jum\u0101 ar Huge TLB?<\/em><\/p>\n<\/p>\n
Nedod. To var izskaidrot daudzos veidos. Bet paties\u012bb\u0101 vi\u0146i vienk\u0101r\u0161i to nedod. K\u0101da ir PostgreSQL st\u0101sts? Vi\u0146\u0161 start\u0101 pie\u0161\u0137ir lielu da\u013cu kop\u0113j\u0101s atmi\u0146as. Transparent vai netransparent tas ir piln\u012bgi bez noz\u012bmes. Fakts, ka vi\u0146i tiek pie\u0161\u0137irti start\u0101, viss skaidro. Un, ja atmi\u0146as ir \u013coti daudz un ir j\u0101p\u0101rstruktur\u0113 shared_memory segments, tad Transparent huge pages b\u016bs aktu\u0101li. PostgreSQL tas ir vienk\u0101r\u0161i start\u0101 pie\u0161\u0137irts milz\u012bgs gabals un viss, un t\u0101l\u0101k tur nekas \u012bpa\u0161s nenotiek. Protams, var izmantot, bet past\u0101v risks ieg\u016bt curruption shared_memory, kad tas atk\u0101rtoti atv\u0113l\u0113s kaut ko. PostgreSQL par to pat nezina.<\/p>\n
Avots: 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
![\"Linux](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n