Linux tuning to improve PostgreSQL performance. Илья Космодемьянский

Расшифровка доклада 2015 года Ильи Космодемьянского "Linux tuning to improve PostgreSQL performance"

Disclaimer: Замечу что доклад этот датирован ноябрем 2015 года — прошло больше 4 лет и прошло много времени. Рассматриваемая в докладе версия 9.4 уже не поддерживается. За прошедшие 4 года вышло 5 новых релизов PostgreSQL вышло и 15 версий ядра Linux. Если переписывать эти места, то получится в итоге другой доклад. Но здесь рассмотрен фундаментальный тюнинг Linux для PostgreSQL, который актуален и сейчас.

Меня зовут Илья Космодемьянский. Я работаю в компании PostgreSQL-Consulting. И сейчас буду рассказывать немножко про то, что делать с Linux применительно к базам данных вообще и к PostgreSQL в частности, потому что принципы довольно схожие.

О чем пойдет речь? Если вы общаетесь с PostgreSQL, то до какой-то степени нужно быть UNIX’овым админом. Что это значит? Если мы сравним Oracle и PostgreSQL, то в Oracle надо быть на 80 % DBA админом базы данных и на 20 % админом Linux.

С PostgreSQL немножко посложнее. С PostgreSQL надо сильно лучше представлять себе, как работает Linux. И при этом немножко бежать вслед за паровозом, потому что в последнее время довольно здорово все апдейтится. И новые ядра выходят, и новый функционал появляется, перфоманс улучшается и т. д.

Почему мы говорим про Linux? Совсем не по тому, что мы на конференции Linux Питер, а потому что в современных условиях одна из самых оправданных ОС для эксплуатации с базами данных вообще и с PostgreSQL в частности – это Linux. Потому что FreeBSD, к сожалению, развивается в каком-то очень странном направлении. И будут проблемы как с производительностью, так и с многими другими вещами. Производительность PostgreSQL на Windows – это вообще отдельная суровая тема, упирающая в то, что у Windows нет такой шаредной памяти как у UNIX, а у PostgreSQL все на это дело завязано, потому что многопроцессная система.

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

У современного дистрибутива Linux более 1 000 параметров syctl, в зависимости от того, как собрать ядро. При этом, если мы посмотрим еще на разные гайки, то там можно еще многими способами что-нибудь поднастраивать. Есть параметры файловых систем, как монтировать. Если вопросы, как запустить: что в BIOS включить, как железки настроить и т. д.

Это очень большой объем, о котором можно рассказывать несколько дней, а не за один короткий доклад, но я сейчас остановлюсь на важных вещах, как избежать тех граблей, которые с гарантией не дадут вам хорошо эксплуатировать базу данных на Linux, если вы их не поправите. И при этом важный такой момент, что многие параметры по дефолту включены не в такие настройки, которые правильны для базы данных. Т. е. по умолчанию работать будет плохо или работать не будет вообще.

Какие традиционные tuning targets есть в Linux? Я думаю, что поскольку вы все имеете дело с администрированием Linux, то что такое targets объяснять особо не надо.

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.

В принципе, до некоторой степени с PostgreSQL точно такая же ситуация. Разница заключается в том, что база еще и не все ресурсы сама умеет себе забирать, т. е. где-то нужно на уровне Linux это все разруливать самостоятельно.

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.

Вот такая картинка для пояснения того, что это такое. Есть буфер ОС Linux и есть шаредная память и есть шаредные буфера PostgreSQL. PostgreSQL в отличие от Oracle работает непосредственно только через буфер ядра, т. е. чтобы страничка с диска попала в его шаредную память, она должна пройти через kernel buffer и обратно точно такая же ситуация.

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.

Kon ikaw adunay 512 GB nga RAM sa server Ug kon kining tanan matapos sa usa ka SATA hard drive nga walay bisan unsang cache, ang tibuok database server dili lang mahimong usa ka kalabasa, kondili usa ka kalabasa nga adunay SATA interface. Ma-stuck ka diha. 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.

Поэтому более правильный вариант для базы данных, чтобы операционная система Linux вообще не знала, что там происходит. Чтобы она обращалась к памяти как обращается.

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.

Два – чем больше разрастается кэш в такой ситуации, тем больше вероятность того, что у вас будет cache misses. И эффективность этого кэша стремительно падает с ростом его размера. Поэтому в операционных системах придумали простой подход. В Linux он давно уже используется. В FreeBSD не так давно появился. Но мы говорим о Linux. Это huge pages.

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.

Если on, то он просто не стартует, если не смог выделить из huge pages. Тут уже – кому и что более мило. Но если у вас стоит try, то проверяйте, что у вас действительно то, что нужно выделилось, потому что пространств для ошибки там много. Сейчас этот функционал работает только на 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.

И это будет очень неприятно в ряде моментов. И основная неприятность заключается в том, что в современных ядрах немножко разнится поведение с более старыми ядрами Linux. И эта вещь, на которую наступать довольно неприятно, потому что, когда мы говорим о какой-то работе с swap’ом, заканчивается это не своевременным приходом OOM-killer. И OOM-killer, который не своевременно пришел и скинул PostgreSQL, это неприятно. Об этом узнают все, т. е. до последнего пользователя.

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.

Если посмотреть с точки зрения Linux, если вы взяли хороший hardware, правильно его настроили, нормально настроили PostgreSQL, чтобы он пореже делал эти checkpoints, размазывал их по времени друг между другом, то вы наступаете в дефолтные параметры Debian. Для большинства дистрибутивов Linux вот такая картина: 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.

И как они портят жизнь? Что такое sched_migration_cost? У Linux scheduler может смигрировать процесс с одного CPU на другой. И для PostgreSQL, который выполняет запросы, миграция на другой CPU совершенно не понятна зачем. С точки зрения операционной системы, когда вы переключаете окна между openoffice и терминалом, то это, может быть, хорошо, но 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.

И напоследок про power saving policy. Хорошо, что теперь Linux можно использовать на ноутбуке. И он будет якобы хорошо расходовать батарейку. Но внезапно оказывается, что на сервере такое тоже может быть.

Dugang pa, kon mag-abang ka og mga server gikan sa bisan unsang hosting provider, nan "maayo" hostery Wala silay pakialam sa imong performance. Ang ilang trabaho mao ang pagsiguro nga ang ilang hardware magamit sa labing episyente nga paagi. Mao nang mahimo nilang i-enable ang laptop-like power-saving mode sa operating system isip default.

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