Pag-tune sa Linux aron mapaayo ang pasundayag sa PostgreSQL. Ilya Kosmodemyansky

Transcript sa 2015 nga report ni Ilya Kosmodemyansky "Linux tuning to improve PostgreSQL performance"

Disclaimer: Namatikdan nako nga kini nga taho gipetsahan Nobyembre 2015 - kapin sa 4 ka tuig ang milabay ug daghang oras ang milabay. Ang bersyon 9.4 nga gihisgutan sa report wala na gisuportahan. Sa miaging 4 ka tuig, 5 ka bag-ong pagpagawas sa PostgreSQL ang gipagawas, ug 15 ka bersyon sa Linux kernel ang gipagawas. Kung imong isulat pag-usab kini nga mga tudling, moabut ka sa usa ka lahi nga taho. Apan dinhi atong gikonsiderar ang sukaranan nga Linux tuning alang sa PostgreSQL, nga may kalabutan gihapon karon.

Ang akong ngalan mao si Ilya Kosmodemyansky. Nagtrabaho ko sa PostgreSQL-Consulting. Ug karon maghisgot ako gamay bahin sa kung unsa ang buhaton sa Linux kalabot sa mga database sa kinatibuk-an ug labi na ang PostgreSQL, tungod kay parehas ang mga prinsipyo.

Unsa may atong hisgotan? Kung nakigkomunikar ka sa PostgreSQL, nan sa pila ka sukod kinahanglan nimo nga usa ka admin sa UNIX. Unsay buot ipasabot niini? Kung atong itandi ang Oracle ug PostgreSQL, nan sa Oracle kinahanglan nimo nga 80% DBA database admin ug 20% ​​Linux admin.

Uban sa PostgreSQL kini usa ka gamay nga mas komplikado. Uban sa PostgreSQL kinahanglan nimo nga adunay mas maayo nga pagsabut kung giunsa ang paglihok sa Linux. Ug sa parehas nga oras, pagdagan gamay pagkahuman sa tren, tungod kay karong bag-o ang tanan na-update nga maayo. Ug ang bag-ong mga kernel gibuhian, ug ang bag-ong pagpaandar nagpakita, ang pasundayag mouswag, ug uban pa.

Ngano nga naghisgot kami bahin sa Linux? Dili tungod kay naa kita sa komperensya sa Linux nga si Peter, apan tungod kay sa modernong mga kondisyon usa sa labing makatarunganon nga mga operating system alang sa paggamit sa mga database sa kinatibuk-an ug ang PostgreSQL sa partikular mao ang Linux. Tungod kay ang FreeBSD, sa walay palad, nag-uswag sa usa ka talagsaon nga direksyon. Ug adunay mga problema sa pasundayag ug sa daghang uban pang mga butang. Ang pasundayag sa PostgreSQL sa Windows sa kasagaran usa ka bulag nga seryoso nga isyu, base sa kamatuoran nga ang Windows walay parehas nga gipaambit nga memorya sama sa UNIX, samtang ang PostgreSQL tanan nahigot niini, tungod kay kini usa ka multi-process nga sistema.

Ug sa akong hunahuna ang tanan dili kaayo interesado sa mga exotics sama sa Solaris, busa lakaw.

Ang modernong pag-apod-apod sa Linux adunay sobra sa 1 ka mga opsyon sa syctl, depende kung giunsa nimo paghimo ang kernel. Sa samang higayon, kon kita motan-aw sa lain-laing mga nuts, kita maka-adjust sa usa ka butang sa daghang mga paagi. Adunay mga parameter sa file system kung giunsa kini pag-mount. Kung adunay ka mga pangutana kung giunsa kini pagsugod: kung unsa ang mahimo sa BIOS, kung giunsa ang pag-configure sa hardware, ug uban pa.

Kini usa ka dako kaayo nga gidaghanon nga mahimong hisgutan sulod sa pipila ka mga adlaw, ug dili sa usa ka mubo nga report, apan karon ako mag-focus sa importante nga mga butang, unsaon paglikay sa mga rake nga gigarantiyahan nga makapugong kanimo sa paggamit sa imong database sa Linux kung ikaw ayaw sila tarong . Ug sa samang higayon, usa ka importante nga punto mao nga daghang mga default nga mga parameter ang wala gilakip sa mga setting nga husto alang sa database. Kana mao, pinaagi sa default kini molihok nga dili maayo o dili gyud.

Unsang tradisyonal nga mga target sa pag-tune ang naa sa Linux? Sa akong hunahuna nga tungod kay kamong tanan nakiglabot sa pagdumala sa Linux, wala’y partikular nga panginahanglan nga ipasabut kung unsa ang mga target.

Mahimo nimong tune:

• Mga CPU.
• Panumduman.
• Pagtipig.
• Ang uban. Atong hisgutan kini sa katapusan alang sa usa ka snack. Bisan pa, pananglitan, ang mga parameter sama sa palisiya sa pagtipig sa enerhiya mahimong makaapekto sa pasundayag sa usa ka dili matag-an ug dili ang labing makapalipay nga paagi.

Unsa ang mga detalye sa PostgreSQL ug ang database sa kinatibuk-an? Ang problema mao nga dili nimo ma-tweak ang bisan unsang indibidwal nga nut ug makita nga ang among pasundayag miuswag pag-ayo.

Oo, adunay ingon nga mga gadyet, apan ang database usa ka komplikado nga butang. Nakig-interact kini sa tanan nga mga kahinguhaan nga naa sa server ug mas gusto nga makig-uban sa hingpit. Kung imong tan-awon ang karon nga mga rekomendasyon sa Oracle kung giunsa ang paggamit sa usa ka host OS, mahisama kini sa joke bahin sa Mongolian cosmonaut - pakan-a ang iro ug ayaw paghikap bisan unsa. Atong ihatag sa database ang tanan nga mga kahinguhaan, ang database mismo ang maghan-ay sa tanan.

Sa prinsipyo, sa usa ka sukod ang sitwasyon parehas ra sa PostgreSQL. Ang kalainan mao nga ang database dili pa makahimo sa pagkuha sa tanan nga mga kapanguhaan alang sa iyang kaugalingon, i.e. sa usa ka lugar sa lebel sa Linux kinahanglan nimo nga ihan-ay ang tanan sa imong kaugalingon.

Ang nag-unang ideya dili ang pagpili sa usa ka target ug pagsugod sa pag-tune niini, pananglitan, memorya, CPU o usa ka butang nga ingon niana, apan pag-analisar sa workload ug pagsulay sa pagpauswag sa throughput kutob sa mahimo aron ang load nga gibuhat sa maayo nga mga programmer. alang kanamo, lakip ang among mga tiggamit.

Ania ang usa ka litrato aron ipasabut kung unsa kini. Adunay usa ka Linux OS buffer ug adunay gipaambit nga memorya ug adunay PostgreSQL nga gipaambit nga buffer. Ang PostgreSQL, dili sama sa Oracle, direkta nga nagtrabaho lamang pinaagi sa kernel buffer, i.e., aron ang usa ka panid gikan sa disk makasulod sa gipaambit nga panumduman niini, kini kinahanglan nga moagi sa kernel buffer ug balik, sa eksaktong parehas nga sitwasyon.

Ang mga disk nagpuyo ubos niini nga sistema. Gidrowing nako kini isip mga disk. Sa tinuud, mahimo nga adunay usa ka RAID controller, ug uban pa.

Ug kini nga input-output sa usa ka paagi o lain mahitabo pinaagi niini nga butang.

Ang PostgreSQL usa ka klasiko nga database. Naay page sa sulod. Ug ang tanan nga input ug output mahitabo gamit ang mga panid. Gipataas namon ang mga bloke sa memorya sa mga panid. Ug kung wala’y nahitabo, gibasa ra namon kini, dayon anam-anam nga mawala kini nga cache, gikan sa gipaambit nga mga buffer ug mabalik sa disk.

Kung gipulihan namon ang usa ka butang sa usa ka lugar, nan ang tibuuk nga panid gimarkahan nga hugaw. Gimarkahan nako sila dinhi sa asul. Ug kini nagpasabot nga kini nga panid kinahanglan nga i-synchronize sa block storage. Mao to, pag hugaw namo, nag entry mi sa WAL. Ug sa usa ka talagsaong higayon sa panahon, usa ka panghitabo nga gitawag og checkpoint miabut. Ug natala ang impormasyon niini nga troso nga siya naabot. Ug kini nagpasabut nga ang tanan nga hugaw nga mga panid nga ania dinhi nianang higayuna niining gipaambit nga mga buffer gi-synchronize sa storage disk gamit ang fsync pinaagi sa kernel buffer.

Nganong gihimo man kini? Kung nawala ang boltahe, wala namon makuha ang kahimtang nga nawala ang tanan nga datos. Ang makanunayon nga panumduman, nga gisulti kanamo sa tanan, layo kaayo sa teorya sa database - kini usa ka hayag nga kaugmaon, nga, siyempre, gipaningkamutan namon ug gusto namon kini, apan sa pagkakaron sila nagpuyo sa minus nga 20 ka tuig. Ug, siyempre, kining tanan kinahanglan nga bantayan.

Ug ang tahas sa pag-maximize sa throughput mao ang pag-ayo sa tanan nga kini nga mga yugto aron kini tanan molihok dayon. Ang gipaambit nga panumduman usa ka cache sa panid. Sa PostgreSQL nagpadala kami usa ka pinili nga pangutana o usa ka butang, nakuha kini nga datos gikan sa disk. Natapos sila sa gipaambit nga mga buffer. Tungod niini, aron kini molihok nga mas maayo, kinahanglan adunay daghang panumduman.

Aron kining tanan molihok nga maayo ug dali, kinahanglan nimo nga husto nga i-configure ang operating system sa tanan nga mga yugto. Ug pilia ang balanse nga hardware, tungod kay kung adunay ka dili balanse sa usa ka lugar, mahimo ka makahimo daghang memorya, apan dili kini maserbisyohan sa igo nga tulin.

Ug atong susihon ang matag usa niini nga mga punto.

Aron mas paspas kining mga panid sa pagbiyahe, kinahanglan nimong makab-ot ang mosunod:

• Una, kinahanglan nimo nga magtrabaho nga mas episyente sa memorya.
• Ikaduha, kini nga transisyon kung ang mga panid gikan sa memorya moadto sa disk kinahanglan nga labi ka episyente.
• Ug ikatulo, kinahanglan adunay maayong mga disk.

Kung ikaw adunay 512 GB nga RAM sa server ug ang tanan niini natapos sa usa ka SATA hard drive nga wala’y bisan unsang cache, nan ang tibuuk nga database server nahimo nga dili lamang usa ka kalabasa, apan usa ka kalabasa nga adunay interface sa SATA. Direkta ka nga modagan niini. Ug walay makaluwas kanimo.

Mahitungod sa unang punto nga may memorya, adunay tulo ka butang nga makapalisod pag-ayo sa kinabuhi.

Ang una kanila mao ang NUMA. Ang NUMA usa ka butang nga gihimo aron mapauswag ang pasundayag. Depende sa workload, lain-laing mga butang mahimong optimized. Ug sa bag-o nga porma niini, dili kaayo maayo alang sa mga aplikasyon sama sa mga database nga kusog nga naggamit sa cache sa panid nga gipaambit nga mga buffer.

Sa laktod nga pagkasulti. Giunsa nimo mahibal-an kung adunay sayup sa NUMA? Ikaw adunay usa ka matang sa dili maayo nga pagtuktok, sa kalit ang pipila ka CPU na-overload. Sa samang higayon, imong analisahon ang mga pangutana sa PostgreSQL ug tan-awa nga walay susama didto. Kini nga mga pangutana kinahanglan dili kaayo CPU intensive. Makuha nimo kini sa dugay nga panahon. Mas sayon ​​ang paggamit sa hustong rekomendasyon gikan sa sinugdanan kon unsaon pag-configure ang NUMA para sa PostgreSQL.

Unsa man gyud ang nahitabo? Ang NUMA mao ang Non-Uniform Memory Access. Unsay punto? Adunay ka usa ka CPU, sunod niini adunay lokal nga memorya. Ug kini nga memory interconnects mahimong makuha ang memorya gikan sa ubang mga CPU.

Kung modagan ka numactl --hardware, unya makakuha ka usa ka dako nga sheet. Lakip sa ubang mga butang, adunay usa ka natad sa distansya. Adunay mga numero - 10-20, ingon niana. Kini nga mga numero wala'y labaw pa sa gidaghanon sa mga hops aron makuha kining hilit nga memorya ug gamiton kini sa lokal. Sa prinsipyo, usa ka maayong ideya. Gipadali niini pag-ayo ang pasundayag sa ilawom sa lainlaing mga buluhaton sa trabaho.

Karon hunahunaa nga adunay usa ka CPU nga una nga nagsulay sa paggamit sa lokal nga panumduman, unya pagsulay sa pagbitad sa laing memorya pinaagi sa interconnect alang sa usa ka butang. Ug kini nga CPU nakakuha sa imong tibuuk nga cache sa panid sa PostgreSQL - kana ra, pipila ka gigabytes. Kanunay nimong makuha ang pinakagrabe nga kaso, tungod kay sa CPU adunay kasagaran nga gamay nga memorya sa mismong module. Ug ang tanan nga panumduman nga giserbisyuhan moagi sa kini nga mga koneksyon. Kini nahimo nga hinay ug masulub-on. Ug ang imong processor nga nagserbisyo niini nga node kanunay nga overloaded. Ug ang oras sa pag-access niini nga panumduman dili maayo, hinay. Kini ang sitwasyon nga dili nimo gusto kung gigamit nimo kini alang sa usa ka database.

Busa, ang usa ka mas husto nga kapilian alang sa database alang sa Linux operating system nga dili mahibal-an kung unsa ang nahitabo didto. Aron kini maka-access sa memorya sama sa gibuhat niini.

Ngano man? Morag balikbalik kini. Kini mahitabo sa usa ka yano nga rason: kita nagkinahanglan og daghang panumduman alang sa panid cache - napulo, gatusan ka gigabytes.

Ug kung gigahin namon kining tanan ug gi-cache ang among datos didto, nan ang ganansya gikan sa paggamit sa cache labi ka labi ka dako kaysa sa ganansya gikan sa ingon usa ka malisud nga pag-access sa memorya. Ug sa ingon kita makabenepisyo nga dili matupngan kon itandi sa kamatuoran nga kita maka-access sa memorya nga mas episyente gamit ang NUMA.

Busa, adunay duha ka mga pamaagi dinhi sa pagkakaron, hangtud nga ang masanag nga kaugmaon moabut, ug ang database mismo dili makahibalo kung asa nga mga CPU kini nagdagan ug diin kini kinahanglan nga magkuha sa usa ka butang.

Busa, ang husto nga pamaagi mao ang pag-disable sa NUMA sa hingpit, pananglitan, kung mag-reboot. Sa kadaghanan nga mga kaso, ang mga kadaugan sa ingon nga mga han-ay sa kadako nga ang pangutana kung diin ang mas maayo wala gyud motumaw.

Adunay laing kapilian. Gigamit namon kini nga mas kanunay kaysa sa una, tungod kay kung ang usa ka kliyente moabut kanamo alang sa suporta, ang pag-reboot sa server usa ka dako nga butang alang kaniya. Naa siyay negosyo didto. Ug makasinati silag mga problema tungod sa NUMA. Busa, gisulayan namon nga i-disable kini sa dili kaayo invasive nga mga paagi kaysa sa pag-reboot, apan pag-amping nga susihon nga kini gibalda. Tungod kay, sama sa gipakita sa kasinatian, maayo nga atong i-disable ang NUMA sa proseso sa ginikanan nga PostgreSQL, apan dili gyud kinahanglan nga kini molihok. Kinahanglan natong susihon ug tan-awon nga napatay na gyud siya.

Adunay usa ka maayo nga post ni Robert Haas. Kini usa sa mga PostgreSQL committers. Usa sa mga nag-unang developer sa tanan nga ubos nga lebel nga giblets. Ug kung gisundan nimo ang mga link gikan sa kini nga post, gihubit nila ang daghang mga mabulukon nga istorya kung giunsa ang NUMA nagpalisud sa kinabuhi sa mga tawo. Tan-awa, tun-i ang checklist sa tagdumala sa sistema kung unsa ang kinahanglan nga i-configure sa server aron maayo ang among database. Kini nga mga setting kinahanglan nga isulat ug susihon, tungod kay kung dili kini dili kaayo maayo.

Palihug timan-i nga kini magamit sa tanan nga mga setting nga akong hisgutan. Apan kasagaran ang mga database gikolekta sa master-slave mode para sa fault tolerance. Ayaw kalimti ang paghimo niini nga mga setting sa ulipon kay usa ka adlaw maaksidente ka ug mobalhin ka sa ulipon ug kini ang mahimong agalon.

Sa usa ka emerhensya nga sitwasyon, kung ang tanan daotan kaayo, ang imong telepono kanunay nga nag-ring ug ang imong boss nagdagan nga adunay usa ka dako nga sungkod, wala ka’y oras sa paghunahuna bahin sa pagsusi. Ug ang mga resulta mahimong makadaot kaayo.

Ang sunod nga punto mao ang dagkong mga panid. Ang dagkong mga panid lisud nga sulayan nga gilain, ug wala’y kapuslanan sa pagbuhat niini, bisan kung adunay mga sukaranan nga makahimo niini. Sayon sila sa Google.

Unsay punto? Ikaw adunay dili kaayo mahal nga server nga adunay daghang RAM, pananglitan, labaw pa sa 30 GB. Dili ka mogamit ug dagkong mga panid. Kini nagpasabot nga ikaw siguradong adunay overhead sa termino sa paggamit sa memorya. Ug kini nga overhead layo sa labing makapahimuot.

Ngano man? Busa unsa ang nahitabo? Ang operating system naggahin sa memorya sa gagmay nga mga piraso. Kini sayon ​​​​kaayo, kini kung giunsa kini nahitabo sa kasaysayan. Ug kung kita moadto sa detalye, ang OS kinahanglan nga maghubad sa mga virtual nga adres sa mga pisikal. Ug kini nga proseso dili ang pinakasimple, mao nga ang OS nagtago sa resulta niini nga operasyon sa Translation Lookaside Buffer (TLB).

Ug tungod kay ang TLB usa ka cache, ang tanan nga mga problema nga naa sa usa ka cache mitungha sa kini nga kahimtang. Una, kung ikaw adunay daghang RAM ug kini tanan gigahin sa gagmay nga mga tipik, nan kini nga buffer mahimong dako kaayo. Ug kung ang cache dako, nan ang pagpangita pinaagi niini mas hinay. Ang overhead himsog ug kini mismo nagkinahanglag wanang, i.e. ang RAM gigamit sa usa ka butang nga dili husto. Niining higayona.

Duha - labi nga ang cache motubo sa ingon nga sitwasyon, mas lagmit nga ikaw adunay mga cache misses. Ug ang kaepektibo niini nga cache paspas nga mokunhod samtang ang gidak-on niini modako. Busa, ang mga operating system adunay usa ka yano nga pamaagi. Kini gigamit sa Linux sa dugay nga panahon. Kini nagpakita sa FreeBSD dili pa lang dugay. Apan naghisgot kami bahin sa Linux. Dagko kini nga mga panid.

Ug dinhi kinahanglan nga matikdan nga ang dagkong mga panid, isip usa ka ideya, sa sinugdan giduso sa mga komunidad nga naglakip sa Oracle ug IBM, i.e. ang mga tiggama sa database kusganong naghunahuna nga kini mapuslanon usab alang sa mga database.

Ug giunsa kini mahimo nga higala sa PostgreSQL? Una, ang dagkong mga panid kinahanglang ma-enable sa Linux kernel.

Ikaduha, sila kinahanglan nga tin-aw nga gipiho sa sysctl parameter - kung pila ang naa. Ang mga numero dinhi gikan sa pipila ka daan nga server. Mahimo nimong kuwentahon kung pila ang imong gipaambit nga buffer aron ang dagkong mga panid mahimong mohaum didto.

Ug kung ang imong tibuuk nga server gipahinungod sa PostgreSQL, nan ang usa ka maayo nga punto sa pagsugod mao ang paggahin sa 25% sa RAM sa gipaambit nga mga buffer, o 75% kung sigurado ka nga ang imong database siguradong mohaum sa kini nga 75%. Unang punto. Ug hunahunaa, kung ikaw adunay 256 GB nga RAM, nan, sumala niana, ikaw adunay 64 GB nga dagkong mga buffer. Kalkulahin ang gibana-bana nga adunay pipila ka margin - kung unsa kini nga numero kinahanglan nga itakda.

Sa wala pa ang bersyon 9.2 (kung wala ako masayop, sukad sa bersyon 8.2), posible nga makonektar ang PostgreSQL sa daghang mga panid gamit ang usa ka librarya sa ikatulo nga partido. Ug kini kinahanglan nga buhaton kanunay. Una, kinahanglan nimo ang kernel aron makagahin og daghang mga panid sa husto. Ug, ikaduha, aron ang aplikasyon nga nagtrabaho kauban nila magamit kini. Dili lang kana gamiton. Tungod kay ang PostgreSQL naggahin ug memorya sa sistema 5 nga estilo, mahimo kini gamit ang libhugetlbfs - kini ang tibuok nga ngalan sa librarya.

Sa 9.3, ang pasundayag sa PostgreSQL gipauswag kung nagtrabaho uban ang panumduman ug ang sistema 5 nga pamaagi sa alokasyon sa memorya gibiyaan. Nalipay kaayo ang tanan, tungod kay kung dili, gisulayan nimo ang pagpadagan sa duha nga mga higayon sa PostgreSQL sa usa ka makina, ug giingon niya nga wala ako igo nga gipaambit nga panumduman. Ug siya nag-ingon nga ang sysctl kinahanglan nga matul-id. Ug adunay ingon nga usa ka sysctl nga kinahanglan nimo nga i-reboot, ug uban pa. Sa kinatibuk-an, ang tanan malipayon. Apan ang alokasyon sa memorya sa mmap nakaguba sa paggamit sa dagkong mga panid. Kadaghanan sa among mga kliyente naggamit ug dagkong gipaambit nga mga buffer. Ug kusganon namon nga girekomenda nga dili mobalhin sa 9.3, tungod kay ang overhead didto nagsugod sa pagkalkulo sa maayong mga porsyento.

Apan ang komunidad naghatag ug pagtagad niini nga problema ug sa 9.4 ilang gitrabaho pag-usab kini nga panghitabo pag-ayo. Ug sa 9.4 usa ka parametro ang nagpakita sa postgresql.conf diin mahimo nimong palihokon ang pagsulay, pag-on o pag-off.

Ang pagsulay mao ang labing luwas nga kapilian. Kung nagsugod ang PostgreSQL, kung gigahin niini ang gipaambit nga memorya, gisulayan niini nga makuha kini nga panumduman gikan sa daghang mga panid. Ug kung dili kini molihok, nan kini mobalik sa normal nga pagpili. Ug kung ikaw adunay FreeBSD o Solaris, mahimo nimong sulayan, kini kanunay nga luwas.

Kung on, nan dili kini magsugod kung dili kini makapili gikan sa dagkong mga panid. Dinhi na mahitungod kung kinsa ug unsa ang mas nindot. Apan kung nasulayan na nimo, nan susiha nga naa gyud nimo kung unsa ang kinahanglan nimo nga gipasiugda, tungod kay adunay daghang lugar alang sa sayup. Sa pagkakaron kini nga gamit naglihok lamang sa Linux.

Usa pa ka gamay nga nota sa dili pa kita mopadayon. Ang mga transparent nga dagkong panid dili pa bahin sa PostgreSQL. Dili niya kini magamit nga normal. Ug uban sa Transparent nga dagkong mga panid alang sa ingon nga usa ka workload, kung gikinahanglan ang usa ka dako nga piraso sa gipaambit nga panumduman, ang mga benepisyo moabut ra nga adunay daghang mga volume. Kung ikaw adunay mga terabytes nga panumduman nan mahimo kini nga dulaon. Kung naghisgot kami bahin sa daghang adlaw-adlaw nga aplikasyon, kung adunay ka 32, 64, 128, 256 GB nga panumduman sa imong makina, nan ang kasagaran nga dagkong mga panid mao ang Ok, ug gi-disable lang namon ang Transparent.

Ug ang katapusan nga butang bahin sa panumduman dili direkta nga may kalabutan sa fruitut, kini makadaot sa imong kinabuhi. Ang tanan nga throughput maapektuhan pag-ayo sa kamatuoran nga ang server kanunay nga nag-swap.

Ug kini mahimong dili maayo sa daghang mga paagi. Ug ang nag-unang problema mao nga ang modernong mga kernels naggawi gamay nga lahi gikan sa mas daan nga Linux kernels. Ug kini nga butang dili maayo nga tun-an, tungod kay kung maghisgot kita bahin sa usa ka matang sa trabaho nga adunay swap, natapos kini sa wala’y oras nga pag-abot sa OOM-killer. Ug ang OOM-killer, nga wala moabut sa tukma nga panahon ug naghulog sa PostgreSQL, dili maayo. Ang tanan mahibal-an bahin niini, kana, hangtod sa katapusan nga tiggamit.

Unsay nahitabo? Adunay ka daghang RAM didto, maayo ang tanan. Apan sa pipila ka rason ang server nagbitay sa swap ug naghinayhinay tungod niini. Morag adunay daghang memorya, apan kini mahitabo.

Kaniadto, among gitambagan ang pagbutang sa vm.swappiness sa zero, i.e. pag-disable sa swap. Kaniadto, ingon og ang 32 GB sa RAM ug ang katugbang nga gipaambit nga mga buffer usa ka dako nga kantidad. Ang nag-unang katuyoan sa swap mao ang adunay usa ka lugar nga ilabay ang crust kung kita mahulog. Ug wala na kini ilabinang natuman. Ug unya unsa ang imong buhaton niini nga crust? Kini usa ka tahas diin dili kaayo klaro kung ngano nga kinahanglan ang swap, labi na sa ingon nga gidak-on.

Apan sa mas moderno, i.e., ikatulo nga bersyon sa kernel, ang pamatasan nausab. Ug kung imong gibutang ang swap sa zero, i.e. i-off kini, unya sa madugay o sa madali, bisan kung adunay nahabilin nga RAM, usa ka OOM killer ang moabut kanimo aron patyon ang labing kusog nga mga konsumedor. Tungod kay iyang ikonsiderar nga sa ingon nga usa ka trabaho nga gibug-aton aduna pa kitay gamay nga nahabilin ug kita molukso, sa ato pa, dili sa paglansang sa proseso sa sistema, apan sa paglansang sa usa ka butang nga dili kaayo importante. Kining dili kaayo importante mao ang intensive consumer sa shared memory, nga mao ang postmaster. Ug pagkahuman kini maayo kung ang base dili kinahanglan nga ibalik.

Busa, karon ang default, kutob sa akong nahinumduman, kadaghanan sa mga pag-apod-apod anaa sa usa ka dapit sa palibot sa 6, i.e. sa unsa nga punto kinahanglan nga magsugod ka sa paggamit sa swap depende sa gidaghanon sa memorya nga nahabilin. Among girekomendar karon ang pagbutang sa vm.swappiness = 1, tungod kay kini halos nagpalong niini, apan wala maghatag sa samang epekto sama sa usa ka OOM-killer nga wala damha nga miabot ug mipatay sa tibuok butang.

Unsay sunod? Kung maghisgot kami bahin sa paghimo sa mga database ug anam-anam nga molihok padulong sa mga disk, ang tanan nagsugod sa pag-ilog sa ilang mga ulo. Tungod kay ang kamatuoran nga ang disk hinay ug ang panumduman paspas pamilyar sa tanan gikan sa pagkabata. Ug nahibal-an sa tanan nga ang database adunay mga problema sa pasundayag sa disk.

Ang nag-unang problema sa pasundayag sa PostgreSQL nga may kalabutan sa mga checkpoints spike dili mahitabo tungod kay ang disk hinay. Kini lagmit tungod sa kamatuoran nga ang memorya ug ang bandwidth sa disk dili balanse. Bisan pa, dili sila mahimong balanse sa lainlaing mga lugar. Ang PostgreSQL wala ma-configure, ang OS wala ma-configure, ang hardware wala ma-configure ug ang hardware dili husto. Ug kini nga problema dili mahitabo lamang kung ang tanan mahitabo ingon nga kini kinahanglan, i.e. bisan wala’y pagkarga, o ang mga setting ug hardware maayo nga gipili.

Unsa kini ug unsa ang hitsura niini? Kasagaran ang mga tawo nga nagtrabaho kauban ang PostgreSQL nakasulod sa kini nga butang labaw sa kausa. Akong ipasabot. Sama sa akong giingon, ang PostgreSQL matag karon ug unya naghimo og mga checkpoint aron ihulog ang mga hugaw nga panid sa gipaambit nga memorya sa disk. Kung kita adunay usa ka dako nga kantidad sa gipaambit nga panumduman, unya ang checkpoint magsugod nga adunay usa ka intensive nga epekto sa disk, tungod kay kini naglabay niini nga mga panid sa fsync. Kini moabut sa kernel buffer ug gisulat sa mga disk gamit ang fsync. Ug kung ang gidaghanon sa kini nga negosyo dako, nan atong makita ang usa ka dili maayo nga epekto, nga mao ang usa ka dako kaayo nga paggamit sa mga disk.

Ania ako adunay duha ka mga litrato. Ako karon ipasabut kung unsa kini. Kini mao ang duha ka time-correlated nga mga graph. Ang una nga graph mao ang paggamit sa disk. Dinhi moabot kini sa halos 90% niining puntoha sa panahon. Kung ikaw adunay kapakyasan sa database sa mga pisikal nga disk, nga adunay paggamit sa RAID controller sa 90%, nan kini dili maayo nga balita. Kini nagpasabot nga gamay pa ug kini moabot sa 100 ug ang I/O mohunong.

Kung ikaw adunay usa ka disk array, nan kini usa ka gamay nga lahi nga istorya. Nagdepende kini kung giunsa kini gi-configure, unsang klase nga array kini, ug uban pa.

Ug parehas, ang usa ka graph gikan sa internal nga postgres nga pagtan-aw gi-configure dinhi, nga nagsulti kung giunsa ang checkpoint nahitabo. Ug ang berde nga kolor dinhi nagpakita kung pila ang mga buffer, kini nga hugaw nga mga panid, nianang higayona miabot sa kini nga checkpoint alang sa pag-synchronize. Ug kini ang panguna nga butang nga kinahanglan nimong mahibal-an dinhi. Nakita namon nga kami adunay daghang mga panid dinhi ug sa usa ka punto kami naigo sa pisara, nga mao, kami nagsulat ug nagsulat, dinhi ang sistema sa disk klaro kaayo nga busy. Ug ang among checkpoint adunay kusog kaayo nga epekto sa disk. Sa tinuud, ang kahimtang kinahanglan tan-awon nga ingon niini, i.e. kami adunay gamay nga pagrekord dinhi. Ug mahimo naton kini nga ayohon sa mga setting aron kini magpadayon nga ingon niini. Sa ato pa, ang pag-recycle gamay ra, apan sa usa ka lugar kami adunay gisulat dinhi.

Unsa ang kinahanglan buhaton aron mabuntog kini nga problema? Kung gihunong nimo ang IO sa ilawom sa database, kini nagpasabut nga ang tanan nga mga tiggamit nga mianhi aron matuman ang ilang mga hangyo maghulat.

Kung imong tan-awon gikan sa punto sa panglantaw sa Linux, kung imong gikuha ang maayo nga hardware, gi-configure kini sa husto, gi-configure ang PostgreSQL nga normal aron kini nga mga checkpoints dili kaayo kanunay, ipakaylap kini sa paglabay sa panahon tali sa usag usa, unya mosulod ka sa default nga mga parameter sa Debian. Alang sa kadaghanan sa mga distribusyon sa Linux, kini ang hulagway: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Unsay buot ipasabot niini? Usa ka nag-flushing nga demonyo nagpakita gikan sa kernel 2.6. Ang Pdglush, depende kung kinsa ang naggamit nga, nga naglihok sa background nga paglabay sa hugaw nga mga panid gikan sa buffer sa kernel ug paglabay kung gikinahanglan nga isalikway ang hugaw nga mga panid bisan unsa pa, kung ang paglabay sa backgrouind dili makatabang.

Kanus-a moabot ang background? Kung ang 10% sa kinatibuk-ang RAM nga magamit sa server giokupahan sa hugaw nga mga panid sa buffer sa kernel, usa ka espesyal nga function sa write-off ang gitawag sa background. Nganong background man? Isip parameter, gikonsiderar kung pila ka panid ang isulat. Ug, ingnon ta, gisulat niya ang N nga panid. Ug sa makadiyot kining butanga nahikatulog. Ug unya mianhi siya pag-usab ug mikopya og uban pang mga pahina.

Kini usa ka hilabihan ka yano nga istorya. Ang problema dinhi sama sa usa ka swimming pool, kung kini ibubo sa usa ka tubo, kini modagayday sa lain. Niabot ang among checkpoint ug kung nagpadala kini og pipila ka hugaw nga mga pahina para sa paglabay, unya sa hinay-hinay ang tibuok butang hapsay nga masulbad gikan sa kernel buffer pgflush.

Kung kini nga mga hugaw nga mga panid nagpadayon sa pagtipon, sila natipon hangtod sa 20%, pagkahuman ang prayoridad sa OS mao ang pagsulat sa tibuuk nga butang sa disk, tungod kay ang gahum mapakyas ug ang tanan mahimong dili maayo alang kanamo. Mawad-an kami niini nga datos, pananglitan.

Unsa ang limbong? Ang lansis mao nga kini nga mga parameter sa modernong kalibutan mao ang 20 ug 10% sa kinatibuk-ang RAM nga naa sa makina, sila hingpit nga makalilisang sa mga termino sa throughput sa bisan unsang disk system nga naa kanimo.

Hunahunaa nga ikaw adunay 128 GB nga RAM. 12,8 GB moabot sa imong disk system. Ug bisan unsa nga cache ang naa nimo didto, bisan unsa pa ang imong array, dili kini molungtad og dugay.

Busa, among girekomendar nga imong i-adjust dayon kini nga mga numero base sa mga kapabilidad sa imong RAID controller. Naghimo dayon ako usa ka rekomendasyon dinhi alang sa usa ka controller nga adunay 512 MB nga cache.

Ang tanan giisip nga yano kaayo. Mahimo nimong ibutang ang vm.dirty_background sa mga byte. Ug kini nga mga setting nagkansela sa miaging duha. Ang bisan unsang ratio kay sa default, o kadtong adunay mga byte gi-activate, unya kadtong adunay mga byte magtrabaho. Apan tungod kay ako usa ka consultant sa DBA ug nagtrabaho kauban ang lainlaing mga kliyente, gisulayan nako ang pagdrowing og mga straw ug busa, kung sa mga byte, unya sa mga byte. Walay usa nga naghatag og bisan unsa nga garantiya nga ang usa ka maayo nga admin dili makadugang sa memorya sa server, i-reboot kini, ug ang numero magpabilin nga pareho. Kalkulahin lang kini nga mga numero aron ang tanan mohaum didto nga adunay garantiya.

Unsa ang mahitabo kung dili ka angay? Gisulat ko nga ang bisan unsang pag-flush epektibo nga gipahunong, apan sa tinuud kini usa ka dagway sa pagsulti. Ang operating system adunay usa ka dako nga problema - kini adunay daghang mga hugaw nga mga panid, mao nga ang IO nga gimugna sa imong mga kliyente epektibo nga nahunong, i.e. ang aplikasyon miabot aron magpadala usa ka sql nga pangutana sa database, kini naghulat. Ang bisan unsang input/output niini mao ang pinakaubos nga prayoridad, tungod kay ang database giokupahan sa usa ka checkpoint. Ug kung kanus-a niya mahuman kini dili klaro. Ug kung nakab-ot nimo ang dili background nga pag-flush, nagpasabut nga ang tanan nimo nga IO giokupahan niini. Ug hangtod nga matapos kini, wala ka'y ​​mahimo.

Adunay duha pa ka hinungdanon nga mga punto dinhi nga wala sa sulud sa kini nga taho. Kini nga mga setting kinahanglan nga mohaum sa mga setting sa postgresql.conf, ie mga checkpoint setting. Ug ang imong disk system kinahanglan nga igo nga ma-configure. Kung ikaw adunay cache sa usa ka RAID, nan kini kinahanglan nga adunay baterya. Gipalit sa mga tawo ang RAID nga adunay maayo nga cache nga wala’y baterya. Kung naa ka mga SSD sa RAID, nan kinahanglan sila nga mga server, kinahanglan adunay mga capacitor didto. Ania ang usa ka detalyado nga checklist. Kini nga link naglangkob sa akong report kung unsaon pag-configure ang usa ka performance disk sa PostgreSQL. Anaa kining tanan nga mga checklist didto.

Unsa pa ang makapalisud sa kinabuhi? Kini mao ang duha ka mga parameter. Bag-o pa sila. Sa kasagaran, mahimo silang ilakip sa lainlaing mga aplikasyon. Ug mahimo nila nga himuon nga lisud ang kinabuhi kung dili husto ang pag-on niini.

Adunay duha ka bag-ong butang. Nagpakita na sila sa ikatulo nga mga cores. Kini mao ang sched_migration_cost sa nanoseconds ug sched_autogroup_enabled, nga usa sa default.

Ug giunsa nila pagguba ang imong kinabuhi? Unsa ang sched_migration_cost? Sa Linux, ang scheduler mahimong mobalhin sa usa ka proseso gikan sa usa ka CPU ngadto sa lain. Ug alang sa PostgreSQL, nga nagpatuman sa mga pangutana, ang pagbalhin sa lain nga CPU dili klaro. Gikan sa punto sa panglantaw sa operating system, kung imong ibalhin ang mga bintana tali sa openoffice ug terminal, mahimo kini nga maayo, apan alang sa usa ka database kini daotan kaayo. Busa, ang usa ka makatarunganon nga palisiya mao ang pagtakda sa migration_cost sa pipila ka dako nga kantidad, labing menos pipila ka libo ka nanoseconds.

Unsa ang ipasabut niini alang sa scheduler? Maisip nga niining panahona init pa ang proseso. Sa ato pa, kung naa kay transaksyon nga dugay nang nabuhat nga dugay na, masabtan kini sa scheduler. Maghunahuna siya nga hangtod sa paglabay sa oras, dili kinahanglan nga ibalhin kini nga proseso bisan diin. Kung sa samang higayon ang proseso adunay usa ka butang, nan dili kini ibalhin bisan asa, kini hilom nga magtrabaho sa CPU nga gigahin niini. Ug ang resulta maayo kaayo.

Ang ikaduha nga punto mao ang autogroup. Adunay usa ka maayo nga ideya alang sa piho nga mga karga sa trabaho nga wala’y kalabutan sa modernong mga database - kini mao ang paggrupo sa mga proseso pinaagi sa virtual nga terminal diin kini gilusad. Kombenyente kini alang sa pipila ka buluhaton. Sa praktis, ang PostgreSQL usa ka multi-process system nga adunay prefork nga nagdagan gikan sa usa ka terminal. Naa kay lock writer, checkpoint, ug ang tanan nimong hangyo sa kliyente igrupo sa usa ka scheduler, kada CPU. Ug magdungan sila nga maghulat didto aron siya mahimong gawasnon, aron manghilabot sa usag usa ug magpabilin siya nga okupado ug dugay. Kini usa ka istorya nga hingpit nga wala kinahanglana sa kaso sa ingon nga pagkarga ug busa kini kinahanglan nga i-off.

Ang akong kauban nga si Alexey Lesovsky naghimo og mga pagsulay gamit ang usa ka yano nga pgbench, diin iyang gipadako ang migration_cost sa usa ka han-ay sa magnitude ug gipalong ang autogroup. Ang kalainan sa dili maayo nga hardware hapit 10%. Adunay usa ka diskusyon sa postgres mailing list diin ang mga tawo naghatag mga resulta sa parehas nga mga pagbag-o sa katulin sa pagpangutana naimpluwensyahan sa 50%. Adunay daghan kaayo nga mga istorya.

Ug sa katapusan, bahin sa palisiya sa pagdaginot sa kuryente. Ang maayo nga butang mao nga ang Linux magamit na karon sa usa ka laptop. Ug mahurot kuno og maayo ang baterya. Apan sa kalit kini nahimo nga kini mahimo usab nga mahitabo sa server.

Dugang pa, kung nag-abang ka sa mga server gikan sa pipila nga nag-host, nan ang "maayo" nga mga host wala magtagad nga adunay ka labi ka maayo nga pasundayag. Ang ilang tahas mao ang pagsiguro nga ang ilang puthaw magamit nga epektibo kutob sa mahimo. Busa, pinaagi sa default sila makahimo sa laptop power saving mode sa operating system.

Kung gigamit nimo kini nga mga butang sa usa ka server nga adunay usa ka database sa ilawom sa bug-at nga karga, nan ang imong gipili mao ang acpi_cpufreq + permormance. Bisan sa ondemand adunay mga problema.

Ang Intel_pstate usa ka gamay nga lahi nga drayber. Ug karon gipalabi ang gihatag niini nga usa, tungod kay kini sa ulahi ug mas maayo.

Ug, sumala niana, ang gobernador kay performance lamang. Ang ondemand, powersave ug uban pa dili bahin kanimo.

Ang mga resulta sa pagpatin-aw sa pag-analisar sa PostgreSQL mahimong magkalainlain sa daghang mga order sa kadako kung mahimo nimo ang powersave, tungod kay halos ang CPU sa ilawom sa imong database modagan sa usa ka hingpit nga dili matag-an nga paagi.

Kini nga mga butang mahimong iapil pinaagi sa default. Tan-awa pag-ayo aron makita kung gi-on ba nila kini pinaagi sa default. Kini mahimo nga usa ka dako nga problema.

Ug sa katapusan, gusto kong magpasalamat sa mga lalaki gikan sa among PosgreSQL-Consulting DBA team, nga sila si Max Boguk ug Alexey Lesovsky, nga nag-uswag sa kini nga butang matag adlaw. Ug naningkamot kami sa pagbuhat sa labing maayo nga among mahimo alang sa among mga kliyente aron kini tanan molihok alang kanila. Sama kini sa mga panudlo sa kaluwasan sa aviation. Ang tanan dinhi nahisulat sa dugo. Ang matag usa niini nga mga nuts makita sa proseso sa usa ka matang sa problema. Nalipay ko nga ipaambit kini kanimo.

Mga Pangutana:

Salamat! Kung, pananglitan, gusto sa usa ka kompanya nga makatipig salapi ug ibutang ang database ug lohika sa aplikasyon sa usa ka server, o kung ang kompanya nagsunod sa us aka uso sa mga arkitektura sa microservice, diin ang PostgreSQL nagdagan sa usa ka sudlanan. Unsa ang limbong? Ang Sysctl makaapekto sa tibuok kernel sa tibuok kalibutan. Wala ako makadungog sa mga sysctls nga sa usa ka paagi virtualized aron sila magtrabaho nga gilain sa usa ka sudlanan. Naa ra cgroup ug naay part sa control didto. Unsaon nimo pagkinabuhi niini? O kung gusto nimo ang pasundayag, dayon pagdagan ang PostgreSQL sa usa ka bulag nga server sa hardware ug i-tune kini?

Gitubag namo ang imong pangutana sa mga tulo ka paagi. Kung wala kami maghisgot bahin sa usa ka server sa hardware nga mahimong ma-tune, ug uban pa, unya relaks, ang tanan molihok nga maayo kung wala kini nga mga setting. Kung ikaw adunay ingon nga karga nga kinahanglan nimo nga buhaton kini nga mga setting, nan moabut ka sa puthaw nga server sa sayo pa kaysa sa kini nga mga setting.

Unsay problema? Kung kini usa ka virtual nga makina, nan lagmit adunay daghang mga problema, pananglitan, sa kamatuoran nga sa kadaghanan sa mga virtual nga makina ang latency sa disk medyo dili managsama. Bisan kung maayo ang disk throughput, unya usa ka napakyas nga transaksyon sa I/O nga dili kaayo makaapekto sa kasagaran nga throughput nga nahitabo sa panahon sa checkpoint o sa pagsulat sa WAL, nan ang database mag-antos pag-ayo niini. Ug mamatikdan nimo kini sa dili pa nimo masinati kini nga mga problema.

Kung ikaw adunay NGINX sa parehas nga server, parehas ka usab nga problema. Makig-away siya alang sa gipaambit nga panumduman. Ug dili nimo makuha ang mga problema nga gihulagway dinhi.

Apan sa laing bahin, ang pipila niini nga mga parametro may kalabotan gihapon kanimo. Pananglitan, ibutang ang dirty_ratio sa sysctl aron dili kini buang - sa bisan unsang kaso, kini makatabang. Sa usa ka paagi o sa lain, ikaw adunay interaksyon sa disk. Ug kini mahimong sumala sa sayop nga sumbanan. Kasagaran kini usa ka default alang sa mga parameter nga akong gipakita. Ug sa bisan unsa nga kaso mas maayo nga usbon kini.

Apan mahimong adunay mga problema sa NUMA. Ang VmWare, pananglitan, nagtrabaho nga maayo sa NUMA nga adunay eksakto nga kaatbang nga mga setting. Ug dinhi kinahanglan ka nga mopili - usa ka puthaw nga server o usa ka dili puthaw.

Naa koy pangutana nga may kalabotan sa Amazon AWS. Sila adunay mga hulagway nga pre-configured. Ang usa niini gitawag nga Amazon RDS. Aduna bay bisan unsang naandan nga mga setting alang sa ilang operating system?

Adunay mga setting didto, apan kini lahi nga mga setting. Dinhi among gi-configure ang operating system kung giunsa paggamit sa database kini nga butang. Ug adunay mga parameter nga nagtino kung asa kita moadto karon, sama sa pagporma. Sa ato pa, nagkinahanglan ta og daghang resources, ato na silang kan-on. Pagkahuman niini, gihigpitan sa Amazon RDS kini nga mga kapanguhaan, ug ang pasundayag nahulog didto. Adunay mga indibidwal nga mga istorya kung giunsa ang mga tawo nagsugod sa pagkagubot sa kini nga butang. Usahay bisan medyo malampuson. Apan kini walay kalabotan sa mga setting sa OS. Kini sama sa pag-hack sa panganod. Kana usa ka lahi nga istorya.

Ngano nga ang Transparent nga dagkong mga panid walay epekto kon itandi sa Dakong TLB?

Ayaw paghatag. Mapaathag ini sa madamo nga paagi. Apan sa pagkatinuod wala lang nila kini ihatag. Unsa ang kasaysayan sa PostgreSQL? Sa pagsugod, naggahin kini usa ka dako nga piraso sa gipaambit nga memorya. Kung sila transparent o dili hingpit nga wala’y kalabotan. Ang kamatuoran nga sila nagbarug sa sinugdanan nagpatin-aw sa tanan. Ug kung adunay daghang panumduman ug kinahanglan nimo nga tukuron pag-usab ang bahin sa shared_memory, nan ang Transparent nga dagkong mga panid adunay kalabotan. Sa PostgreSQL, kini yano nga gigahin sa usa ka dako nga tipik sa pagsugod ug mao kana, ug unya walay espesyal nga mahitabo didto. Mahimo nimo, siyempre, gamiton kini, apan adunay higayon nga makakuha usa ka korapsyon sa shared_memory kung kini gigahin pag-usab ang usa ka butang. PostgreSQL wala mahibalo bahin niini.

Source: www.habr.com