Linux tuning para mapahusay ang pagganap ng PostgreSQL. Ilya Kosmodemyansky

Transcript ng 2015 na ulat ni Ilya Kosmodemyansky "Linux tuning to improve PostgreSQL performance"

Disclaimer: Tandaan ko na ang ulat na ito ay may petsang Nobyembre 2015 - mahigit 4 na taon na ang lumipas at maraming oras na ang lumipas. Ang bersyon 9.4 na tinalakay sa ulat ay hindi na sinusuportahan. Sa nakalipas na 4 na taon, 5 bagong release ng PostgreSQL ang inilabas, at 15 na bersyon ng Linux kernel ang inilabas. Kung muling isusulat mo ang mga sipi na ito, magkakaroon ka ng ibang ulat. Ngunit dito isinasaalang-alang namin ang pangunahing Linux tuning para sa PostgreSQL, na may kaugnayan pa rin ngayon.

Ang pangalan ko ay Ilya Kosmodemyansky. Nagtatrabaho ako sa PostgreSQL-Consulting. At ngayon ay magsasalita ako ng kaunti tungkol sa kung ano ang gagawin sa Linux na may kaugnayan sa mga database sa pangkalahatan at sa PostgreSQL sa partikular, dahil ang mga prinsipyo ay medyo magkatulad.

Ano ang pag-uusapan natin? Kung nakikipag-usap ka sa PostgreSQL, sa ilang lawak kailangan mong maging isang UNIX admin. Ano ang ibig sabihin nito? Kung ihahambing namin ang Oracle at PostgreSQL, sa Oracle kailangan mong maging 80% DBA database admin at 20% Linux admin.

Sa PostgreSQL ito ay medyo mas kumplikado. Sa PostgreSQL kailangan mong magkaroon ng mas mahusay na pag-unawa sa kung paano gumagana ang Linux. At sa parehong oras, tumakbo ng kaunti pagkatapos ng lokomotibo, dahil kamakailan lamang ang lahat ay na-update nang maayos. At ang mga bagong kernel ay inilabas, at ang bagong pag-andar ay lilitaw, ang pagganap ay nagpapabuti, atbp.

Bakit Linux ang pinag-uusapan natin? Hindi sa lahat dahil tayo ay nasa Linux conference Peter, ngunit dahil sa modernong mga kondisyon isa sa mga pinaka-makatwirang operating system para sa paggamit ng mga database sa pangkalahatan at PostgreSQL sa partikular ay ang Linux. Dahil ang FreeBSD, sa kasamaang-palad, ay umuunlad sa ilang kakaibang direksyon. At magkakaroon ng mga problema sa pagganap at sa maraming iba pang mga bagay. Ang pagganap ng PostgreSQL sa Windows sa pangkalahatan ay isang hiwalay na seryosong isyu, batay sa katotohanan na ang Windows ay walang parehong nakabahaging memorya gaya ng UNIX, habang ang PostgreSQL ay lahat ay nakatali dito, dahil ito ay isang multi-process na sistema.

At sa tingin ko lahat ay hindi gaanong interesado sa mga exotics tulad ng Solaris, kaya't pumunta tayo.

Ang isang modernong pamamahagi ng Linux ay may higit sa 1 syctl na mga opsyon, depende sa kung paano mo binuo ang kernel. Kasabay nito, kung titingnan natin ang iba't ibang mga mani, maaari nating ayusin ang isang bagay sa maraming paraan. Mayroong mga parameter ng file system kung paano i-mount ang mga ito. Kung mayroon kang mga katanungan tungkol sa kung paano simulan ito: kung ano ang paganahin sa BIOS, kung paano i-configure ang hardware, atbp.

Ito ay isang napakalaking volume na maaaring talakayin sa loob ng ilang araw, at hindi sa isang maikling ulat, ngunit ngayon ay magtutuon ako ng pansin sa mga mahahalagang bagay, kung paano maiiwasan ang mga rake na garantisadong pipigil sa iyo na gamitin nang maayos ang iyong database sa Linux kung ikaw ay huwag mo silang itama. At sa parehong oras, ang isang mahalagang punto ay ang maraming mga default na parameter ay hindi kasama sa mga setting na tama para sa database. Iyon ay, sa pamamagitan ng default ito ay gagana nang hindi maganda o hindi sa lahat.

Anong mga tradisyunal na target sa pag-tune ang mayroon sa Linux? Sa tingin ko, dahil lahat kayo ay nakikitungo sa pangangasiwa ng Linux, walang partikular na pangangailangang ipaliwanag kung ano ang mga target.

Maaari mong ibagay:

• CPU.
• Memorya.
• Imbakan.
• Iba pa. Pag-uusapan natin ito sa dulo para sa meryenda. Kahit na, halimbawa, ang mga parameter tulad ng patakaran sa pagtitipid ng enerhiya ay maaaring makaapekto sa pagganap sa isang napaka-unpredictable at hindi ang pinaka-kaaya-ayang paraan.

Ano ang mga detalye ng PostgreSQL at ang database sa pangkalahatan? Ang problema ay hindi ka maaaring mag-tweak ng anumang indibidwal na nut at makita na ang aming pagganap ay bumuti nang malaki.

Oo, may mga ganoong gadget, ngunit ang isang database ay isang kumplikadong bagay. Nakikipag-ugnayan ito sa lahat ng mga mapagkukunan na mayroon ang server at mas gustong makipag-ugnayan nang lubos. Kung titingnan mo ang kasalukuyang mga rekomendasyon ng Oracle sa kung paano gumamit ng host OS, ito ay magiging katulad ng biro tungkol sa Mongolian cosmonaut na iyon - pakainin ang aso at huwag hawakan ang anumang bagay. Bigyan natin ang database ng lahat ng mga mapagkukunan, ang database mismo ay ayusin ang lahat.

Sa prinsipyo, sa ilang lawak ang sitwasyon ay eksaktong pareho sa PostgreSQL. Ang pagkakaiba ay hindi pa nakukuha ng database ang lahat ng mga mapagkukunan para sa sarili nito, ibig sabihin, sa isang lugar sa antas ng Linux kailangan mong ayusin ang lahat ng ito sa iyong sarili.

Ang pangunahing ideya ay hindi upang pumili ng isang solong target at simulan ang pag-tune nito, halimbawa, memorya, CPU o isang bagay na katulad nito, ngunit upang pag-aralan ang workload at subukang pagbutihin ang throughput hangga't maaari upang ang load na nilikha ng mahusay na mga programmer. para sa amin, kasama ang aming mga gumagamit.

Narito ang isang larawan upang ipaliwanag kung ano ito. Mayroong Linux OS buffer at mayroong shared memory at mayroong PostgreSQL shared buffers. Ang PostgreSQL, hindi tulad ng Oracle, ay direktang gumagana lamang sa pamamagitan ng kernel buffer, ibig sabihin, upang ang isang pahina mula sa disk ay makapasok sa nakabahaging memorya nito, dapat itong dumaan sa kernel buffer at pabalik, sa eksaktong parehong sitwasyon.

Nabubuhay ang mga disk sa ilalim ng sistemang ito. Iginuhit ko ito bilang mga disk. Sa katunayan, maaaring mayroong RAID controller, atbp.

At ang input-output na ito sa isang paraan o iba ay nangyayari sa pamamagitan ng bagay na ito.

Ang PostgreSQL ay isang klasikong database. May page sa loob. At lahat ng input at output ay nangyayari gamit ang mga pahina. Kami ay nagtataas ng mga bloke sa memorya ng mga pahina. At kung walang nangyari, binabasa lang namin ang mga ito, pagkatapos ay unti-unting nawawala ang mga ito mula sa cache na ito, mula sa mga nakabahaging buffer at napupunta pabalik sa disk.

Kung papalitan namin ang isang bagay sa isang lugar, ang buong pahina ay mamarkahan bilang marumi. Minarkahan ko sila dito ng asul. At nangangahulugan ito na ang page na ito ay dapat na naka-synchronize sa block storage. Ibig sabihin, kapag ginawa naming madumi, gumawa kami ng entry sa WAL. At sa ilang kahanga-hangang sandali ay dumating ang isang phenomenon na tinatawag na checkpoint. At ang impormasyon ay naitala sa log na ito na siya ay dumating. At nangangahulugan ito na ang lahat ng maruruming pahina na narito sa sandaling iyon sa mga nakabahaging buffer na ito ay na-synchronize sa storage disk gamit ang fsync sa pamamagitan ng kernel buffer.

Bakit ito ginagawa? Kung nawalan kami ng boltahe, hindi namin nakuha ang sitwasyon na nawala ang lahat ng data. Ang patuloy na memorya, na sinabi sa amin ng lahat, ay napakalayo sa teorya ng database - ito ay isang maliwanag na hinaharap, na, siyempre, nagsusumikap at gusto namin ito, ngunit sa ngayon ay nabubuhay sila sa minus 20 taon. At, siyempre, ang lahat ng ito ay kailangang subaybayan.

At ang gawain ng pag-maximize ng throughput ay ang pag-fine-tune sa lahat ng mga yugtong ito upang ang lahat ay gumagalaw nang mabilis pabalik-balik. Ang nakabahaging memorya ay karaniwang isang cache ng pahina. Sa PostgreSQL nagpadala kami ng isang piling query o isang bagay, nakuha nito ang data na ito mula sa disk. Napunta sila sa mga nakabahaging buffer. Alinsunod dito, para ito ay gumana nang mas mahusay, dapat mayroong maraming memorya.

Upang ang lahat ng ito ay gumana nang maayos at mabilis, kailangan mong i-configure nang tama ang operating system sa lahat ng mga yugto. At pumili ng balanseng hardware, dahil kung mayroon kang kawalan ng timbang sa ilang lugar, maaari kang gumawa ng maraming memorya, ngunit hindi ito maseserbisyuhan sa sapat na bilis.

At talakayin natin ang bawat isa sa mga puntong ito.

Upang mapabilis ang paglalakbay ng mga page na ito, kailangan mong makamit ang sumusunod:

• Una, kailangan mong magtrabaho nang mas mahusay sa memorya.
• Pangalawa, ang paglipat na ito kapag ang mga pahina mula sa memorya ay pumunta sa disk ay dapat na mas mahusay.
• At pangatlo, dapat mayroong magagandang disk.

Kung mayroon kang 512 GB ng RAM sa server at lahat ng ito ay napupunta sa isang SATA hard drive nang walang anumang cache, ang buong database server ay nagiging hindi lamang isang kalabasa, ngunit isang kalabasa na may interface ng SATA. Direkta kang tatakbo dito. At walang magliligtas sa iyo.

Tungkol sa unang punto na may memorya, may tatlong bagay na maaaring magpahirap sa buhay.

Ang una sa kanila ay NUMA. Ang NUMA ay isang bagay na ginawa upang mapabuti ang pagganap. Depende sa workload, maaaring ma-optimize ang iba't ibang bagay. At sa bagong kasalukuyang anyo nito, hindi ito napakahusay para sa mga application tulad ng mga database na masinsinang gumagamit ng mga nakabahaging buffer ng cache ng pahina.

Sa maikling sabi. Paano mo malalaman kung may mali sa NUMA? Mayroon kang isang uri ng hindi kasiya-siyang katok, biglang na-overload ang ilang CPU. Kasabay nito, sinusuri mo ang mga query sa PostgreSQL at makita na walang katulad doon. Ang mga query na ito ay hindi dapat masyadong masinsinang CPU. Maaari mong mahuli ito sa mahabang panahon. Mas madaling gamitin ang tamang rekomendasyon mula sa simula kung paano i-configure ang NUMA para sa PostgreSQL.

Ano ba talaga ang nangyayari? Ang NUMA ay kumakatawan sa Non-Uniform Memory Access. Ano ang punto? Mayroon kang isang CPU, sa tabi nito ay mayroong lokal na memorya. At ang memory interconnects na ito ay maaaring kumuha ng memorya mula sa iba pang mga CPU.

Kung tatakbo ka numactl --hardware, pagkatapos ay makakakuha ka ng napakalaking sheet. Sa iba pang mga bagay, magkakaroon ng field ng mga distansya. Magkakaroon ng mga numero - 10-20, isang bagay na ganoon. Ang mga numerong ito ay hindi hihigit sa bilang ng mga hop upang kunin ang malayuang memorya na ito at gamitin ito nang lokal. Sa prinsipyo, isang magandang ideya. Pinapabilis nito ang pagganap sa ilalim ng hanay ng mga workload.

Ngayon isipin na mayroon kang isang CPU na unang sinusubukang gamitin ang lokal na memorya nito, pagkatapos ay sinusubukang i-pull up ang isa pang memorya sa pamamagitan ng interconnect para sa isang bagay. At nakukuha ng CPU na ito ang iyong buong PostgreSQL page cache - iyon lang, ilang gigabytes. Palagi kang nakakakuha ng pinakamasamang kaso, dahil sa CPU ay karaniwang may maliit na memorya sa mismong module na iyon. At lahat ng memorya na naseserbisyuhan ay dumadaan sa mga interconnect na ito. Ito ay lumiliko na mabagal at malungkot. At ang iyong processor na nagseserbisyo sa node na ito ay patuloy na na-overload. At ang oras ng pag-access ng memorya na ito ay masama, mabagal. Ito ang sitwasyong hindi mo gusto kung ginagamit mo ito para sa isang database.

Samakatuwid, ang isang mas tamang opsyon para sa database ay para sa Linux operating system na hindi malaman kung ano ang nangyayari doon. Upang ma-access nito ang memorya tulad ng ginagawa nito.

Bakit ganon? Tila ito ay dapat na maging kabaligtaran. Nangyayari ito sa isang simpleng dahilan: kailangan namin ng maraming memorya para sa cache ng pahina - sampu, daan-daang gigabytes.

At kung ilalaan namin ang lahat ng ito at i-cache ang aming data doon, kung gayon ang pakinabang mula sa paggamit ng cache ay magiging mas malaki kaysa sa pakinabang mula sa gayong nakakalito na pag-access sa memorya. At sa gayon ay makikinabang tayo nang walang kapantay kumpara sa katotohanang maa-access natin ang memorya nang mas mahusay gamit ang NUMA.

Samakatuwid, mayroong dalawang diskarte dito sa sandaling ito, hanggang sa dumating ang maliwanag na hinaharap, at ang database mismo ay hindi matukoy kung aling mga CPU ito ay tumatakbo at kung saan kailangan itong kumuha ng isang bagay.

Samakatuwid, ang tamang diskarte ay ang ganap na huwag paganahin ang NUMA, halimbawa, kapag nagre-reboot. Sa karamihan ng mga kaso, ang mga panalo ay may mga order ng magnitude na ang tanong kung alin ang mas mahusay ay hindi lumabas sa lahat.

May isa pang pagpipilian. Ginagamit namin ito nang mas madalas kaysa sa una, dahil kapag ang isang kliyente ay dumating sa amin para sa suporta, ang pag-reboot ng server ay isang malaking bagay para sa kanya. May negosyo siya doon. At nakakaranas sila ng mga problema dahil sa NUMA. Samakatuwid, sinusubukan naming i-disable ito sa hindi gaanong invasive na paraan kaysa sa pag-reboot, ngunit mag-ingat na suriin kung hindi ito pinagana. Dahil, tulad ng ipinapakita ng karanasan, magandang i-disable natin ang NUMA sa parent na proseso ng PostgreSQL, ngunit hindi naman talaga kailangan na gagana ito. Kailangan nating suriin at makita na siya ay talagang naka-off.

May magandang post si Robert Haas. Ito ay isa sa mga PostgreSQL committers. Isa sa mga pangunahing developer ng lahat ng mababang antas ng giblet. At kung susundin mo ang mga link mula sa post na ito, inilalarawan nila ang ilang makulay na kwento tungkol sa kung paano pinahirapan ng NUMA ang buhay ng mga tao. Tingnan, pag-aralan ang checklist ng administrator ng system kung ano ang kailangang i-configure sa server upang gumana nang maayos ang aming database. Ang mga setting na ito ay kailangang isulat at suriin, dahil kung hindi, hindi ito magiging napakahusay.

Pakitandaan na nalalapat ito sa lahat ng setting na pag-uusapan ko. Ngunit kadalasan ang mga database ay kinokolekta sa master-slave mode para sa fault tolerance. Huwag kalimutang gawin ang mga setting na ito sa alipin dahil isang araw ay maaksidente ka at lilipat ka sa alipin at ito ang magiging master.

Sa isang emergency na sitwasyon, kapag ang lahat ay napakasama, ang iyong telepono ay patuloy na nagri-ring at ang iyong boss ay tumatakbo na may dalang malaking stick, wala kang oras upang mag-isip tungkol sa pagsuri. At ang mga resulta ay maaaring maging lubos na nakapipinsala.

Ang susunod na punto ay malalaking pahina. Ang malalaking pahina ay mahirap subukan nang hiwalay, at walang saysay na gawin ito, bagama't may mga benchmark na makakagawa nito. Madali silang i-Google.

Ano ang punto? Mayroon kang hindi masyadong mahal na server na may maraming RAM, halimbawa, higit sa 30 GB. Hindi ka gumagamit ng malalaking pahina. Nangangahulugan ito na tiyak na mayroon kang overhead sa mga tuntunin ng paggamit ng memorya. At ang overhead na ito ay malayo sa pinakakaaya-aya.

Bakit ganon? Kaya ano ang nangyayari? Ang operating system ay naglalaan ng memorya sa maliliit na piraso. Napaka-convenient, ganito ang nangyari sa kasaysayan. At kung tutukuyin natin ang detalye, dapat isalin ng OS ang mga virtual na address sa mga pisikal. At ang prosesong ito ay hindi ang pinakasimpleng, kaya ini-cache ng OS ang resulta ng operasyong ito sa Translation Lookaside Buffer (TLB).

At dahil ang TLB ay isang cache, ang lahat ng mga problema na likas sa isang cache ay lumitaw sa sitwasyong ito. Una, kung marami kang RAM at lahat ito ay inilalaan sa maliliit na tipak, ang buffer na ito ay nagiging napakalaki. At kung malaki ang cache, mas mabagal ang paghahanap dito. Ang overhead ay malusog at ito mismo ay tumatagal ng espasyo, ibig sabihin, ang RAM ay kinakain ng isang bagay na hindi tama. Sa pagkakataong ito.

Dalawa - mas lumalaki ang cache sa ganoong sitwasyon, mas malamang na magkakaroon ka ng mga miss sa cache. At ang kahusayan ng cache na ito ay mabilis na bumababa habang lumalaki ang laki nito. Samakatuwid, ang mga operating system ay dumating sa isang simpleng diskarte. Matagal na itong ginagamit sa Linux. Lumitaw ito sa FreeBSD hindi pa katagal. Ngunit pinag-uusapan natin ang tungkol sa Linux. Ang mga ito ay malalaking pahina.

At dito dapat tandaan na ang malalaking pahina, bilang isang ideya, ay una nang itinulak ng mga komunidad na kinabibilangan ng Oracle at IBM, ibig sabihin, ang mga tagagawa ng database ay lubos na naisip na ito ay magiging kapaki-pakinabang din para sa mga database.

At paano ito magiging kaibigan sa PostgreSQL? Una, ang malalaking pahina ay dapat paganahin sa Linux kernel.

Pangalawa, dapat silang tahasang tinukoy ng sysctl parameter - kung ilan ang mayroon. Ang mga numero dito ay mula sa ilang lumang server. Maaari mong kalkulahin kung gaano karaming mga nakabahaging buffer ang mayroon ka para magkasya doon ang malalaking page.

At kung ang iyong buong server ay nakatuon sa PostgreSQL, kung gayon ang isang magandang panimulang punto ay ang paglalaan ng alinman sa 25% ng RAM sa mga nakabahaging buffer, o 75% kung sigurado ka na ang iyong database ay talagang magkasya sa 75%. Panimulang punto uno. At isaalang-alang, kung mayroon kang 256 GB ng RAM, kung gayon, nang naaayon, magkakaroon ka ng 64 GB ng malalaking buffer. Kalkulahin ang humigit-kumulang na may ilang margin - kung saan dapat itakda ang figure na ito.

Bago ang bersyon 9.2 (kung hindi ako nagkakamali, mula noong bersyon 8.2), posible na ikonekta ang PostgreSQL sa malalaking pahina gamit ang isang third-party na library. At ito ay dapat palaging gawin. Una, kailangan mo ang kernel upang makapaglaan ng malalaking pahina nang tama. At, pangalawa, para magamit sila ng application na gumagana sa kanila. Hindi lang yan gagamitin. Dahil ang PostgreSQL ay naglaan ng memorya sa system 5 style, ito ay maaaring gawin gamit ang libhugetlbfs - ito ang buong pangalan ng library.

Sa 9.3, ang pagganap ng PostgreSQL ay napabuti kapag nagtatrabaho sa memorya at ang paraan ng paglalaan ng memorya ng system 5 ay inabandona. Masayang-masaya ang lahat, dahil kung hindi ay susubukan mong magpatakbo ng dalawang PostgreSQL instance sa isang makina, at sinabi niya na wala akong sapat na shared memory. At sinabi niya na ang sysctl ay kailangang itama. At mayroong tulad ng isang sysctl na kailangan mo pa ring i-reboot, atbp. Sa pangkalahatan, lahat ay masaya. Ngunit sinira ng paglalaan ng memorya ng mmap ang paggamit ng malalaking pahina. Karamihan sa aming mga kliyente ay gumagamit ng malalaking shared buffer. At mahigpit naming inirerekomenda na huwag lumipat sa 9.3, dahil doon nagsimulang kalkulahin ang overhead sa magagandang porsyento.

Ngunit binigyang-pansin ng komunidad ang problemang ito at sa 9.4 ay muling ginawa nila ang kaganapang ito nang napakahusay. At sa 9.4 isang parameter ang lumitaw sa postgresql.conf kung saan maaari mong paganahin ang try, on o off.

Subukan ang pinakaligtas na opsyon. Kapag nagsimula ang PostgreSQL, kapag naglaan ito ng nakabahaging memorya, sinusubukan nitong kunin ang memorya na ito mula sa malalaking pahina. At kung hindi ito gumana, pagkatapos ay babalik ito sa normal na pagpili. At kung mayroon kang FreeBSD o Solaris, maaari mong subukan, ito ay palaging ligtas.

Kung naka-on, hindi ito magsisimula kung hindi ito makakapili mula sa malalaking pahina. Narito na ang tungkol sa kung sino at ano ang mas maganda. Ngunit kung nasubukan mo na, pagkatapos ay suriin kung talagang mayroon kang kung ano ang kailangan mong i-highlight, dahil mayroong maraming puwang para sa pagkakamali. Sa kasalukuyan, gumagana lang ang functionality na ito sa Linux.

Isang maliit na note pa bago tayo tumuloy. Ang mga transparent na malalaking pahina ay hindi pa tungkol sa PostgreSQL. Hindi niya magagamit ang mga ito nang normal. At sa mga Transparent na malalaking page para sa ganoong workload, kapag kailangan ang isang malaking piraso ng shared memory, ang mga benepisyo ay dumarating lamang sa napakalaking volume. Kung mayroon kang mga terabytes ng memorya, maaari itong maglaro. Kung pinag-uusapan natin ang higit pang pang-araw-araw na mga application, kapag mayroon kang 32, 64, 128, 256 GB ng memorya sa iyong makina, kung gayon ang karaniwang malalaking pahina ay Ok, at hindi namin pinapagana ang Transparent.

At ang huling bagay tungkol sa memorya ay hindi direktang nauugnay sa fruitut, maaari itong masira ang iyong buhay. Ang lahat ng throughput ay lubos na maaapektuhan ng katotohanan na ang server ay patuloy na nagpapalit.

At ito ay magiging lubhang hindi kasiya-siya sa maraming paraan. At ang pangunahing problema ay ang mga modernong kernel ay kumikilos nang bahagyang naiiba sa mas lumang mga kernel ng Linux. At ang bagay na ito ay medyo hindi kanais-nais na hakbang, dahil kapag pinag-uusapan natin ang tungkol sa ilang uri ng trabaho na may swap, nagtatapos ito sa hindi napapanahong pagdating ng OOM-killer. At ang OOM-killer, na hindi dumating sa isang napapanahong paraan at bumaba sa PostgreSQL, ay hindi kanais-nais. Malalaman ng lahat ang tungkol dito, iyon ay, hanggang sa huling gumagamit.

Anong nangyayari? Mayroon kang malaking halaga ng RAM doon, lahat ay gumagana nang maayos. Ngunit sa ilang kadahilanan ang server ay nag-hang sa swap at bumagal dahil dito. Mukhang maraming memorya, ngunit nangyayari ito.

Dati, pinayuhan namin na itakda ang vm.swappiness sa zero, ibig sabihin, i-disable ang swap. Dati, tila napakalaking halaga ang 32 GB ng RAM at mga katumbas na shared buffer. Ang pangunahing layunin ng swap ay upang magkaroon ng isang lugar upang itapon ang crust kung mahulog tayo. At hindi na ito partikular na natupad. At saka ano ang gagawin mo sa crust na ito? Ito ay isang gawain kung saan hindi masyadong malinaw kung bakit kailangan ang swap, lalo na sa ganoong laki.

Ngunit sa mas modernong, ibig sabihin, mga ikatlong bersyon ng kernel, ang pag-uugali ay nagbago. At kung itinakda mo ang swap sa zero, ibig sabihin, i-off ito, sa lalong madaling panahon, kahit na may ilang RAM na natitira, isang OOM killer ang darating sa iyo upang patayin ang mga pinakamatinding consumer. Dahil isasaalang-alang niya na sa ganoong workload ay mayroon pa tayong kaunting natitira at lalabas tayo, i.e., hindi para ipako ang proseso ng system, ngunit para ipako ang isang bagay na hindi gaanong mahalaga. Ang hindi gaanong mahalaga ay ang masinsinang mamimili ng nakabahaging memorya, lalo na ang postmaster. At pagkatapos nito ay magiging mabuti kung ang base ay hindi kailangang ibalik.

Samakatuwid, ngayon ang default, sa pagkakatanda ko, karamihan sa mga distribusyon ay nasa paligid ng 6, ibig sabihin, sa anong punto ka dapat magsimulang gumamit ng swap depende sa kung gaano karaming memorya ang natitira. Inirerekomenda namin ngayon ang pagtatakda ng vm.swappiness = 1, dahil ito ay halos naka-off ito, ngunit hindi nagbibigay ng parehong mga epekto tulad ng sa isang OOM-killer na hindi inaasahang dumating at pinatay ang buong bagay.

Anong susunod? Kapag pinag-uusapan natin ang pagganap ng mga database at unti-unting lumipat patungo sa mga disk, ang lahat ay nagsisimulang agawin ang kanilang mga ulo. Dahil ang katotohanan na ang disk ay mabagal at ang memorya ay mabilis ay pamilyar sa lahat mula pagkabata. At alam ng lahat na ang database ay magkakaroon ng mga problema sa pagganap ng disk.

Ang pangunahing problema sa pagganap ng PostgreSQL na nauugnay sa mga checkpoint na spike ay hindi nangyayari dahil ang disk ay mabagal. Ito ay malamang dahil sa ang katunayan na ang memorya at disk bandwidth ay hindi balanse. Gayunpaman, maaaring hindi sila balanse sa iba't ibang lugar. Hindi naka-configure ang PostgreSQL, hindi naka-configure ang OS, hindi naka-configure ang hardware at mali ang hardware. At ang problemang ito ay hindi mangyayari lamang kung ang lahat ay mangyayari ayon sa nararapat, ibig sabihin, alinman sa walang pag-load, o ang mga setting at hardware ay mahusay na napili.

Ano ito at ano ang hitsura nito? Kadalasan ang mga taong nagtatrabaho sa PostgreSQL ay pumasok sa bagay na ito nang higit sa isang beses. Ipapaliwanag ko. Tulad ng sinabi ko, ang PostgreSQL ay pana-panahong gumagawa ng mga checkpoint upang itapon ang mga maruruming pahina sa shared memory sa disk. Kung mayroon tayong malaking halaga ng nakabahaging memorya, ang checkpoint ay magsisimulang magkaroon ng matinding epekto sa disk, dahil itinatapon nito ang mga pahinang ito gamit ang fsync. Dumating ito sa kernel buffer at isinulat sa mga disk gamit ang fsync. At kung ang dami ng negosyong ito ay malaki, maaari nating obserbahan ang isang hindi kasiya-siyang epekto, lalo na ang isang napakalaking paggamit ng mga disk.

Narito mayroon akong dalawang larawan. Ipapaliwanag ko ngayon kung ano ito. Ito ay dalawang graph na may kaugnayan sa oras. Ang unang graph ay ang paggamit ng disk. Dito umabot ito ng halos 90% sa puntong ito ng oras. Kung mayroon kang pagkabigo sa database sa mga pisikal na disk, na may RAID controller na paggamit sa 90%, kung gayon ito ay masamang balita. Ibig sabihin, kaunti pa at aabot sa 100 at titigil na ang I/O.

Kung mayroon kang isang disk array, kung gayon ito ay isang bahagyang naiibang kuwento. Depende ito sa kung paano ito na-configure, kung anong uri ng array ito, atbp.

At kahanay, ang isang graph mula sa panloob na view ng postgres ay na-configure dito, na nagsasabi kung paano nangyayari ang checkpoint. At ang berdeng kulay dito ay nagpapakita kung gaano karaming mga buffer, ang mga maruruming pahinang ito, sa sandaling iyon ay dumating sa checkpoint na ito para sa pag-synchronize. At ito ang pangunahing bagay na kailangan mong malaman dito. Nakikita namin na mayroon kaming maraming mga pahina dito at sa ilang mga punto ay naabot namin ang board, iyon ay, nagsulat kami at nagsulat, dito ang disk system ay malinaw na abala. At ang aming checkpoint ay may napakalakas na epekto sa disk. Sa isip, ang sitwasyon ay dapat magmukhang mas ganito, ibig sabihin, mas kaunti ang recording namin dito. At maaari naming ayusin ito sa mga setting upang ito ay patuloy na maging ganito. Iyon ay, ang pag-recycle ay maliit, ngunit sa isang lugar kami ay nagsusulat ng isang bagay dito.

Ano ang kailangang gawin upang malampasan ang problemang ito? Kung itinigil mo ang IO sa ilalim ng database, nangangahulugan ito na maghihintay ang lahat ng user na dumating upang tuparin ang kanilang mga kahilingan.

Kung titingnan mo mula sa punto ng view ng Linux, kung kumuha ka ng mahusay na hardware, na-configure ito nang tama, na-configure ang PostgreSQL nang normal upang hindi gaanong madalas ang mga checkpoint na ito, ikakalat ang mga ito sa paglipas ng panahon sa pagitan ng isa't isa, pagkatapos ay pumasok ka sa mga default na parameter ng Debian. Para sa karamihan ng mga pamamahagi ng Linux, ito ang larawan: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Ano ang ibig sabihin nito? Isang namumula na demonyo ang lumitaw mula sa kernel 2.6. Pdglush, depende sa kung sino ang gumagamit ng kung saan, na kung saan ay nakikibahagi sa background discarding ng maruming mga pahina mula sa kernel buffer at discarding kapag ito ay kinakailangan upang itapon ang maruruming mga pahina kahit na ano, kapag backgrouind discarding ay hindi makakatulong.

Kailan darating ang background? Kapag ang 10% ng kabuuang RAM na magagamit sa server ay inookupahan ng mga maruruming pahina sa buffer ng kernel, isang espesyal na function ng write-off ang tinatawag sa background. Bakit background? Bilang isang parameter, isinasaalang-alang kung gaano karaming mga pahina ang isusulat. At, sabihin nating, isinulat niya ang N pages. At ilang sandali ay nakatulog ang bagay na ito. At pagkatapos ay bumalik siya at kumukopya ng ilan pang mga pahina.

Ito ay isang napakasimpleng kwento. Ang problema dito ay parang swimming pool, kapag bumuhos ito sa isang tubo, dumadaloy ito sa isa pa. Dumating ang aming checkpoint at kung nagpadala ito ng ilang maruruming pahina para itapon, pagkatapos ay unti-unting malulutas ang buong bagay mula sa kernel buffer pgflush.

Kung ang mga maruruming pahinang ito ay patuloy na maipon, nag-iipon sila ng hanggang 20%, pagkatapos kung saan ang priyoridad ng OS ay isulat ang buong bagay sa disk, dahil ang kapangyarihan ay mabibigo at ang lahat ay magiging masama para sa atin. Mawawala ang data na ito, halimbawa.

Ano ang pakulo? Ang trick ay ang mga parameter na ito sa modernong mundo ay 20 at 10% ng kabuuang RAM na nasa makina, ang mga ito ay talagang napakapangit sa mga tuntunin ng throughput ng anumang disk system na mayroon ka.

Isipin na mayroon kang 128 GB ng RAM. Dumating ang 12,8 GB sa iyong disk system. At kahit anong cache ang mayroon ka doon, kahit anong array ang mayroon ka doon, hindi ito magtatagal ng ganoon katagal.

Samakatuwid, inirerekomenda namin na agad mong ayusin ang mga numerong ito batay sa mga kakayahan ng iyong RAID controller. Agad akong gumawa ng rekomendasyon dito para sa isang controller na may 512 MB ng cache.

Ang lahat ay itinuturing na napakasimple. Maaari mong ilagay ang vm.dirty_background sa mga byte. At kinansela ng mga setting na ito ang naunang dalawa. Ang alinman sa ratio ay bilang default, o ang mga may mga byte ay na-activate, pagkatapos ay ang mga may mga byte ay gagana. Ngunit dahil ako ay isang consultant ng DBA at nagtatrabaho sa iba't ibang mga kliyente, sinusubukan kong gumuhit ng mga straw at samakatuwid, kung sa mga byte, pagkatapos ay sa mga byte. Walang nagbigay ng anumang garantiya na ang isang mahusay na admin ay hindi magdaragdag ng higit pang memorya sa server, i-reboot ito, at ang figure ay mananatiling pareho. Kalkulahin lamang ang mga numerong ito upang ang lahat ay magkasya doon na may garantiya.

Ano ang mangyayari kung hindi ka nababagay? Isinulat ko na ang anumang pag-flush ay epektibong itinigil, ngunit sa katunayan ito ay isang pigura ng pananalita. Ang operating system ay may malaking problema - marami itong maruruming mga pahina, kaya ang IO na nabuo ng iyong mga kliyente ay epektibong nahinto, ibig sabihin, ang application ay dumating upang magpadala ng isang sql query sa database, ito ay naghihintay. Ang anumang input/output dito ay nasa pinakamababang priyoridad, dahil ang database ay inookupahan ng checkpoint. At kung kailan siya matatapos ito ay ganap na hindi malinaw. At kapag nakamit mo ang non-background flushing, nangangahulugan ito na ang lahat ng iyong IO ay inookupahan nito. At hanggang sa matapos ito, wala kang gagawin.

Mayroong dalawang mas mahalagang punto dito na lampas sa saklaw ng ulat na ito. Ang mga setting na ito ay dapat tumugma sa mga setting sa postgresql.conf, ibig sabihin, mga setting ng mga checkpoint. At ang iyong disk system ay dapat na sapat na na-configure. Kung mayroon kang cache sa isang RAID, dapat ay mayroon itong baterya. Bumibili ang mga tao ng RAID na may magandang cache na walang baterya. Kung mayroon kang mga SSD sa RAID, dapat silang mga server, dapat mayroong mga capacitor doon. Narito ang isang detalyadong checklist. Ang link na ito ay naglalaman ng aking ulat kung paano i-configure ang isang performance disk sa PostgreSQL. Mayroong lahat ng mga checklist na ito doon.

Ano pa ang maaaring magpahirap sa buhay? Ito ay dalawang parameter. Sila ay medyo bago. Bilang default, maaari silang isama sa iba't ibang mga application. At maaari nilang gawing mahirap ang buhay kung sila ay na-on nang hindi tama.

Mayroong dalawang medyo bagong bagay. Lumitaw na sila sa ikatlong core. Ito ay sched_migration_cost sa nanoseconds at sched_autogroup_enabled, na isa bilang default.

At paano nila sinisira ang buhay mo? Ano ang sched_migration_cost? Sa Linux, maaaring ilipat ng scheduler ang isang proseso mula sa isang CPU patungo sa isa pa. At para sa PostgreSQL, na nagpapatupad ng mga query, ang paglipat sa isa pang CPU ay ganap na hindi malinaw. Mula sa punto ng view ng operating system, kapag nagpalipat-lipat ka ng mga bintana sa pagitan ng openoffice at terminal, maaaring ito ay mabuti, ngunit para sa isang database ito ay napakasama. Samakatuwid, ang isang makatwirang patakaran ay ang magtakda ng migration_cost sa ilang malaking halaga, kahit ilang libong nanosecond.

Ano ang ibig sabihin nito para sa scheduler? Isasaalang-alang na sa panahong ito ay mainit pa rin ang proseso. Ibig sabihin, kung mayroon kang matagal nang transaksyon na may ginagawa nang mahabang panahon, mauunawaan ito ng scheduler. Ipapalagay niya na hanggang sa lumipas ang timeout na ito, hindi na kailangang ilipat ang prosesong ito kahit saan. Kung sa parehong oras ang proseso ay gumagawa ng isang bagay, kung gayon hindi ito ililipat kahit saan, tahimik itong gagana sa CPU na inilaan dito. At ang resulta ay napakahusay.

Ang pangalawang punto ay autogroup. May magandang ideya para sa mga partikular na workload na hindi nauugnay sa mga modernong database - ito ay upang pangkatin ang mga proseso ayon sa virtual na terminal kung saan sila inilunsad. Ito ay maginhawa para sa ilang mga gawain. Sa pagsasagawa, ang PostgreSQL ay isang multi-process system na may prefork na tumatakbo mula sa isang terminal. Mayroon kang lock writer, checkpoint, at lahat ng iyong kahilingan ng kliyente ay ipapangkat sa isang scheduler, bawat CPU. At sila ay maghihintay doon nang sabay-sabay para sa kanya upang maging malaya, upang makagambala sa isa't isa at panatilihin siyang abala nang mas matagal. Ito ay isang kuwento na ganap na hindi kailangan sa kaso ng naturang pag-load at samakatuwid kailangan itong i-off.

Ang aking kasamahan na si Alexey Lesovsky ay nagsagawa ng mga pagsubok gamit ang isang simpleng pgbench, kung saan pinataas niya ang migration_cost sa isang order ng magnitude at pinatay ang autogroup. Ang pagkakaiba sa masamang hardware ay halos 10%. Mayroong talakayan sa postgres mailing list kung saan ang mga tao ay nagbibigay ng mga resulta ng mga katulad na pagbabago sa bilis ng query naimpluwensyahan ng 50%. Medyo marami ang mga ganitong kwento.

At panghuli, tungkol sa patakaran sa pagtitipid ng kuryente. Ang maganda ay magagamit na ang Linux sa isang laptop. At uubusin daw ng maayos ang baterya. Ngunit biglang lumalabas na maaari rin itong mangyari sa server.

Bukod dito, kung nagrenta ka ng mga server mula sa ilang hoster, kung gayon ang "mahusay" na mga host ay walang pakialam na mayroon kang mas mahusay na pagganap. Ang kanilang gawain ay upang matiyak na ang kanilang bakal ay ginagamit nang mahusay hangga't maaari. Samakatuwid, bilang default maaari nilang paganahin ang laptop power saving mode sa operating system.

Kung gagamitin mo ang bagay na ito sa isang server na may database sa ilalim ng mabigat na pagkarga, ang iyong pipiliin ay acpi_cpufreq + permormance. Kahit na may ondemand ay magkakaroon ng mga problema.

Ang Intel_pstate ay isang bahagyang naiibang driver. At ngayon ang kagustuhan ay ibinibigay sa isang ito, dahil ito ay mamaya at mas mahusay na gumagana.

At, ayon dito, ang gobernador ay pagganap lamang. Ang ondemand, powersave at lahat ng iba pa ay hindi tungkol sa iyo.

Ang mga resulta ng explain analysis PostgreSQL ay maaaring mag-iba sa ilang mga order ng magnitude kung paganahin mo ang powersave, dahil halos ang CPU sa ilalim ng iyong database ay tatakbo sa isang ganap na hindi mahulaan na paraan.

Maaaring isama ang mga item na ito bilang default. Tingnang mabuti kung na-on nila ito bilang default. Ito ay maaaring maging isang malaking problema.

At sa huli, gusto kong magpasalamat sa mga lalaki mula sa aming PosgreSQL-Consulting DBA team, na sina Max Boguk at Alexey Lesovsky, na umuunlad sa bagay na ito araw-araw. At sinisikap naming gawin ang lahat ng aming makakaya para sa aming mga kliyente nang sa gayon ay gumana ang lahat para sa kanila. Ito ay tulad ng mga tagubilin sa kaligtasan ng aviation. Lahat dito ay nakasulat sa dugo. Ang bawat isa sa mga mani na ito ay matatagpuan sa proseso ng ilang uri ng problema. Ikinagagalak kong ibahagi ang mga ito sa iyo.

Tanong:

Salamat! Kung, halimbawa, ang isang kumpanya ay nais na makatipid ng pera at ilagay ang database at application logic sa isang server, o kung ang kumpanya ay sumusunod sa sunod sa moda ng mga microservice architecture, kung saan ang PostgreSQL ay tumatakbo sa isang lalagyan. Ano ang pakulo? Maaapektuhan ng Sysctl ang buong kernel sa buong mundo. Wala akong narinig na sysctls na kahit papaano ay na-virtualize upang gumana sila nang hiwalay sa isang lalagyan. Mayroon lamang isang cgroup at mayroon lamang bahagi ng kontrol doon. Paano ka mabubuhay dito? O kung gusto mo ng pagganap, pagkatapos ay patakbuhin ang PostgreSQL sa isang hiwalay na server ng hardware at ibagay ito?

Sinagot namin ang iyong tanong sa halos tatlong paraan. Kung hindi namin pinag-uusapan ang tungkol sa isang server ng hardware na maaaring i-tune, atbp., pagkatapos ay mag-relax, lahat ay gagana nang maayos nang wala ang mga setting na ito. Kung mayroon kang ganoong load na kailangan mong gawin ang mga setting na ito, pupunta ka sa iron server nang mas maaga kaysa sa mga setting na ito.

Ano ang problema? Kung ito ay isang virtual machine, malamang na magkakaroon ka ng maraming mga problema, halimbawa, sa katotohanan na sa karamihan ng mga virtual machine ang latency ng disk ay medyo hindi naaayon. Kahit na ang disk throughput ay mabuti, kung gayon ang isang nabigo na transaksyon sa I/O na hindi gaanong nakakaapekto sa average na throughput na nangyari sa oras ng checkpoint o sa oras ng pagsulat sa WAL, kung gayon ang database ay magdurusa nang husto mula dito. At mapapansin mo ito bago ka tumakbo sa mga problemang ito.

Kung mayroon kang NGINX sa parehong server, magkakaroon ka rin ng parehong problema. Ipaglalaban niya ang shared memory. At hindi ka makakarating sa mga problemang inilarawan dito.

Ngunit sa kabilang banda, may kaugnayan pa rin sa iyo ang ilan sa mga parameter na ito. Halimbawa, itakda ang dirty_ratio sa sysctl upang hindi ito mabaliw - sa anumang kaso, makakatulong ito. Sa isang paraan o iba pa, magkakaroon ka ng pakikipag-ugnayan sa disk. At ito ay magiging ayon sa maling pattern. Ito ay karaniwang isang default para sa mga parameter na ipinakita ko. At sa anumang kaso ito ay mas mahusay na baguhin ang mga ito.

Ngunit maaaring may mga problema sa NUMA. Ang VmWare, halimbawa, ay gumagana nang maayos sa NUMA na may eksaktong kabaligtaran na mga setting. At dito kailangan mong pumili - isang bakal na server o isang hindi bakal.

Mayroon akong tanong na nauugnay sa Amazon AWS. Mayroon silang mga larawang na-pre-configure. Ang isa sa kanila ay tinatawag na Amazon RDS. Mayroon bang anumang mga custom na setting para sa kanilang operating system?

May mga setting doon, ngunit iba ang mga setting. Dito namin i-configure ang operating system sa mga tuntunin kung paano gagamitin ng database ang bagay na ito. At may mga parameter na tumutukoy kung saan tayo dapat pumunta ngayon, tulad ng paghubog. Ibig sabihin, kailangan natin ng napakaraming resources, kakainin natin sila ngayon. Pagkatapos nito, hinihigpitan ng Amazon RDS ang mga mapagkukunang ito, at bumaba ang pagganap doon. May mga indibidwal na kwento kung paano nagsisimulang guluhin ang mga tao sa bagay na ito. Minsan kahit medyo matagumpay. Ngunit wala itong kinalaman sa mga setting ng OS. Ito ay tulad ng pag-hack sa ulap. Ibang kwento yan.

Bakit walang epekto ang Transparent na malalaking pahina kumpara sa Huge TLB?

Huwag ibigay. Ito ay maaaring ipaliwanag sa maraming paraan. Ngunit sa katunayan hindi nila ito ibinibigay. Ano ang kasaysayan ng PostgreSQL? Sa pagsisimula, naglalaan ito ng malaking bahagi ng nakabahaging memorya. Kung sila ay transparent o hindi ay ganap na walang kaugnayan. Ang katotohanan na sila ay namumukod-tangi sa simula ay nagpapaliwanag ng lahat. At kung mayroong maraming memorya at kailangan mong muling buuin ang shared_memory segment, kung gayon ang mga Transparent na malalaking pahina ay magiging may kaugnayan. Sa PostgreSQL, ito ay inilalaan lamang sa isang malaking tipak sa simula at iyon na, at pagkatapos ay walang espesyal na mangyayari doon. Maaari mo, siyempre, gamitin ito, ngunit may pagkakataon na magkaroon ng katiwalian ng shared_memory kapag muling naglaan ito ng isang bagay. Hindi alam ng PostgreSQL ang tungkol dito.

Pinagmulan: www.habr.com