Linuxi häälestamine PostgreSQLi jõudluse parandamiseks. Ilya Kosmodemyanskiy

2015. aasta ettekande "Linuxi häälestamine PostgreSQLi jõudluse parandamiseks" tõlgendus Ilya Kosmodemyanskiy poolt

Käesolev väljavõte: Tahan märkida, et see ettekande kuupäev on novembrist 2015 — on möödunud rohkem kui 4 aastat ja palju on muutunud. Ettekandes käsitletav versioon 9.4 ei ole enam toetatud. Viimase 4 aasta jooksul on ilmunud 5 uut PostgreSQL versiooni ja 15 Linuxi kerneli versiooni. Kui siin kohtasid ümber kirjutada, saaks lõppkokkuvõttes hoopis teine ettekande. Kuid siinkohal on käsitletud põhi häälestust Linuxi jaoks PostgreSQL’i jaoks, mis on endiselt aktuaalne.

Minu nimi on Ilya Kosmodemyanskiy. Töödan ettevõttes PostgreSQL-Consulting. Ja nüüd hakkan rääkima natuke sellest, mida teha Linuxiga, seoses andmebaasidega üldiselt ja PostgreSQL’iga konkreetselt, sest põhimõtted on üsna sarnased.

Millest me räägime? Kui suhtlete PostgreSQL’iga, peate mingil määral olema UNIXi administraator. Mida see tähendab? Kui võrrelda Oracle’it ja PostgreSQL’i, siis Oracle’iga peab olema 80% DBA andmebaasi administraator ja 20% Linuxi administraator.

PostgreSQL’iga on natuke keerulisem. PostgreSQL’i puhul tuleb oluliselt paremini mõista, kuidas Linux töötab. Ja samal ajal tuleb vahel kiiremini joosta, sest viimasel ajal on kõik üsna aktiivselt uuendatud. Uusi kernelit on välja antud ning uut funktsionaalsust on ilmunud, jõudlus paraneb jne.

Miks me räägime Linuxist? Mitte sellepärast, et oleme Linuxi konverentsil Peterburis, vaid seetõttu, et tänapäeval on üks kõige põhjendatum operatsioonisüsteem andmebaaside käitamiseks üldiselt ja PostgreSQL’iga konkreetselt — see on Linux. Kuna FreeBSD, kahjuks, areneb mingis väga kummalises suunas. Ja tekivad probleemid nii jõudluse kui ka paljude muude aspektidega. PostgreSQL jõudlus Windowsis — see on täiesti eraldi karm teema, kuna Windowsil ei ole sellist jagatud mälu nagu UNIXil, ja PostgreSQL sõltub sellest, sest see on mitme protsessi süsteem.

Ja eksootika nagu Solaris, arvan, huvitab vähem inimesi, seega liikume edasi.

Kaasaegse Linuxi distributsiooni puhul on üle 1 000 syctl parameetri, sõltuvalt sellest, kuidas tuum koguda. Kui vaatame veel erinevaid mutreid, siis on veel palju viise, kuidas midagi kohandada. On failisüsteemi parameetreid, kuidas mountida. Kui küsimusi, kuidas käivitada: mida BIOSis sisse lülitada, kuidas riistvara seadistada jne.

See on väga mahukas teema, millest võiks rääkida mitu päeva, mitte ühe lühikese ettekande jooksul, kuid ma keskendun nüüd olulistele asjadele, kuidas vältida neid lõkse, mis kindlasti ei võimalda teil hästi hallata andmebaasi Linuxis, kui te neid ei paranda. Oluline on märkida, et paljud parameetrid on vaikimisi seades, mis ei ole andmebaasi jaoks õiged. Ehkki vaikimisi töötamine võib olla halb või mitte töötada üldse.

Millised on traditsioonilised tuning targets Linuxis? Ma arvan, et kuna te kõik tegeleme Linuxi haldamisega, siis ei ole targets'i seletamine eriti vajalik.

Võimalik on häälestada:

• CPU.
• Mälu.
• Salvestus.
• Muud. Sellest räägime lõpus. Isegi näiteks sellised parameetrid nagu energiasäästupoliitika võivad ettearvamatu ja mitte kõige meeldivama mõjuga olla jõudlusele.

Milline on PostgreSQL spetsiifika ja andmebaaside üldiselt? Probleem on selles, et ei saa häälestada mõnda eraldi mutrit ja vaadata, et jõudlus on oluliselt paranenud.

Jah, selliseid mutreid on, kuid andmebaas on keeruline asi. See suhtleb kõigi serveri ressurssidega ja eelistab nendega täielikult suhelda. Kui vaatate Oracle'i kaasaegseid soovitusi selle kohta, kuidas kasutada hostimisoperatsioonisüsteemi, on see nagu anekdoot Mongoli kosmonautidest – toida koera ja ära puuduta midagi. Andke andmebaasile kõik ressursid, andmebaas lahendab kõik ise.

Üldiselt on PostgreSQL puhul sama olukord. Erinevus seisneb selles, et andmebaas ei oska kõiki ressursse ise haarata, seega tuleb Linuxi tasemel mõned asjad ise korraldada.

Peamine idee ei ole valida ühte sihtkohta ja alustada selle tuunimist, näiteks mälu, CPU või midagi sarnast, vaid analüüsida töökoormust ja püüda maksimaalselt parandada läbilaskevõimet, et meie andmebaas saaks tõhusalt läbi viia laengu, mille head programmeerijad meile kokku on pannud, sealhulgas ka meie kasutajad.

Siin on pilt, et selgitada, mis see on. On Linuxi operatsioonisüsteemi puhversälu, jagatud mälu ja PostgreSQL jagatud puhversälu. PostgreSQL töötab erinevalt Oracle'ist otse ainult tuuma puhversäluga, st et leht peab läbima tuumapuhversälu, et jõuda tema jagatud mälu, ja sama olukord kehtib ka tagasi.

Selle süsteemi all asuvad kettad. Ma joonistasin need ketasteks. Tegelikult võib seal olla RAID-kontroller jne.

Ja see sisse- ja väljund, mingil moel, toimub läbi selle asja.

PostgreSQL on klassikaline andmebaas. Seal on lehed sees. Ja kogu sisse- ja väljund toimub lehtede abil. Me toome lehed mällu. Ja kui midagi ei juhtunud, lihtsalt lugesime neid, siis järk-järgult need kaduvad sellest puhversälust, jagatud puhversälist ja jõuavad tagasi kettale.

Kui me kuskil midagi asendasime, siis märgistatakse kogu leht kui määrdunud. Ma olen need sinise värviga esile tõstnud. See tähendab, et see leht peab olema sünkroniseeritud plokkidehoidjaga. St kui me tegime selle määrdunuks, siis tegime kirje WAL-is. Ja mingil kaunil hetkel saabus nähtus nimega kontrollpunkt. Ja sellesse logisse salvestati teave selle kohta, et see on saabunud. See tähendab, et kõik määrdunud lehed, mis seal sel hetkel jagatud puhversälist olid, sünkroniseeriti kettal hoidmisega fsync kaudu tuumapuhversälu abil.

Miks see tehakse? Kui meil kaob toide, siis me ei saa olukorda, kus kõik andmed on kadunud. Püsiv mälu, millest me kõik oleme kuulnud, on seni andmebaaside teoorias – see on helge tulevik, mille poole me loomulikult pürgime ja see meeldib meile, kuid praegu elavad nad endiselt 20 aastat minevikus. Ja loomulikult peab selle üle jälgima.

Ja ülesanne maksimeerida läbilaskvust on häälestada kõigis neis etappides, et kõik see liiguks kiiresti edasi-tagasi. Jagatud mälu on peamiselt leheküljekassa. PostgreSQL-is sõidame päringu select midagi seal, see tõi need andmed kettalt välja. Need jõudsid jagatud puhverdesse. Seega, et see töötaks paremini, peab olema palju mälu.

Selleks, et see kõik toimiks hästi ja kiiresti, peate kõigis etappides operatsioonisüsteemi õigesti seadistama. Ja valima tasakaalustatud riistvara, sest kui teil on mõnes kohas tasakaaluhäire, siis võite teha väga palju mälu, kuid see teenindatakse ebapiisava kiiruseni.

Ja vaatame igaüht neist punktidest.

Kuna neid lehekülgi tuleb kiiremini edasi-tagasi liigutada, tuleb saavutada järgnev:

• Esiteks, tuleb tõhusamalt mälu kasutada.
• Teiseks, see üleminek, kui leheküljed mälust kettale jõuavad, peab olema tõhusam.
• Ja kolmandaks, peab olema head kettad.

Kui teil on 512 GB RAM-i serveris ja see kõik suundub lõpuks SATA kõvakettale ilma igasuguse vahemälu, siis muutub kogu andmebaasiserver mitte lihtsalt kõrvitsaks, vaid kõrvitsaks SATA liidesega. Te seisate selle ees otseselt. Ja miski ei päästa teid.

Mida puudutab esimest punkti mälu osas, siis on kolm asja, mis võivad elu oluliselt keerulisemaks muuta.

Esimene neist on NUMA. NUMA on asi, mis on loodud jõudluse parandamiseks. Olenevalt töökoormusest võib erinevaid asju optimeerida. Ja oma tänases kujus ei ole see selliste rakenduste, nagu andmebaas, mis intensiivselt kasutavad lehekülje vahemälu jagatud puhverdes, väga hea.

Lühidalt. Kuidas mõista, et NUMA-ga on midagi valesti? Teil on mingi ebameeldiv mürin, ühtäkki on mõni CPU ülekoormatud. Samal ajal analüüsite PostgreSQL-is päringuid ja näete, et seal pole midagi sellist. Need päringud ei tohiks olla nii intensiivsed CPU kasutamise osas. Seda saab kaua jälgida. Lihtsam on alates algusest kasutada õiget soovitust, kuidas NUMA PostgreSQL-i seadistada.

Mis tegelikult juhtub? NUMA - see on Mittetäiuslik Mäluelektroonika. Miks see on? Teil on CPU, mille kõrval on tema kohaliku mälu. Ja see mälu interconnects võib tuua mälu teistelt CPU-delt.

Kui käivitate numactl --hardware, siis saate sellise suure lehe. Muuhulgas on seal valdkond distances. Seal on numbrid – 10-20, midagi sellist. Need numbrid ei ole midagi muud kui hüpikute arv, et see eemal asuv mälu ühendada ja kohapeal kasutada. Üldiselt on see hea mõte. See kiirendab jõudlust teatud koormuste puhul.

Kujutage nüüd ette, et teie üks CPU üritab esmalt kasutada oma kohalikku mälu, seejärel proovib ta interconnecti kaudu tuua endale muud mälu millegi tarbeks. Ja sellele CPU-le jõuab kogu teie PostgreSQL page cache – kõik need paar gigabaiti. Te alati saate halvimat juhtumit, sest CPU-l on tavaliselt otseselt selles mälumoodulis vähe mälu. Ja kogu mälu, mis teenindatakse, liigub läbi nende interconnectide. See on aeglane ja kurb. Ja teil on protsessor, mis teenindab seda sõlme, pidevalt üle koormatud. Ja selle mälu juurdepääsu aeg on halb, aeglane. See on see olukord, mida te ei soovi, kui kasutate seda andmebaasi tarbeks.

Seetõttu on õigem variant andmebaasiks, et Linuxi operatsioonisüsteem ei teadliks sellest, mis seal toimub. Et ta pöördub mälu poole nii, nagu ta tavaliselt pöördub.

Miks nii? Tundub, et peaks olema vastupidi. See juhtub ühel lihtsal põhjusel, et mälu on meil page cache jaoks palju vaja – kümneid, sadu gigabaiate.

Ja kui me oleme kõik selle eraldanud ja oma andmed seal vahemälusse salvestanud, siis on kasu vahemälu kasutamisest oluliselt suurem kui see kasu, mis tuleneb sellisest nutikast mälu käsitsemisest. Ja me võidame seeläbi võrreldamatult rohkem, võrreldes sellega, et oleksime efektiivsemad mälu käsitsemisel NUMA abil.

Niisiis, hetkel on siin kaks lähenemist, kuni valgus tulevikus ei saabu ja andmebaas ei oska ise aru saada, millistel CPU-del ta töötab ja kust tuleb midagi laadida.

Seetõttu on õige lähenemine – üldse NUMA välja lülitada, näiteks taaskäivitamisel. Enamiku juhtumite puhul on kasum nii suur, et küsimus, kuidas paremini, ei teki üldse.

On teine võimalus. Me kasutame seda sagedamini kui esimest, sest kui klient tuleb meie tehnilisse tugi, siis on serveri taaskäivitamine tema jaoks suur asi. Tema seal ju äri käib. Probleemid NUMA tõttu on nad kogenud. Seetõttu püüame neid välja lülitada vähem invasiivsete meetoditega kui taaskäivitamine, kuid siin tuleb ettevaatlikult kontrollida, et see tõesti välja lülitatud oleks. Sest, nagu kogemus näitab, kui me vanemalt PostgreSQL NUMA protsessilt välja lülitame, on see hea, kuid kindlasti pole see vajalik, et see tööle hakkaks. Tuleb kontrollida ja vaadata, et see tõeliselt välja lülitatakse.

On olemas hea postitus Robert Haasilt. Ta on üks PostgreSQL'i pannijaid. Üks võtme arendajatest kõikide madala taseme komponente. Ja kui sellele postitusele viidatud linkidele minna, siis seal on mitmeid värvikate lugusid sellest, kuidas NUMA elusid keeruliseks tegi. Vaadake, uurige süsteemiadministraatori kontrollnimekirja, mida serveris seadistada, et meie andmebaas töötaks hästi. Need seaded tuleb kirja panna ja kontrollida, sest vastasel juhul ei lähe hästi.

Tõmban tähelepanu sellele, et see puudutab kõiki seadeid, millest ma räägin. Kuid tavaliselt kogutakse andmebaasid master-slave režiimis tõrgeteta töökindluse jaoks. Ärge unustage need seaded slave'i sisse viia, sest ühel kaunil hetkel juhtub teil katastroof ja te lülitate üle slave'ile, kes saab masteriks.

Hädaolukorras, kui kõik on väga halb, heliseb teie telefon pidevalt ja juhataja jookseb suure kepiga, siis pole teil aega mõelda, et kontrollida. Ja tulemused võivad olla väga kurvad.

Järgmine punkt on huge pages. Huge pages'i on keeruline eraldi testida, ja selles pole ka mõtet, kuigi on olemas benhmarke, mis oskavad seda teha. Need leiavad kergesti Google'is.

Mis on mõte? Teil on mitte eriti kallis server, milles on palju RAM-i, näiteks üle 30 GB. Te ei kasuta huge pages'i. See tähendab, et teil on kindlasti õige üleliigne mälu kasutamine. Ja see üleliigne on kaugeltki mitte mugav.

Miks see nii on? Mis toimub? Operatsioonisüsteem jaotab mälu väikesteks tükkideks. See on mugav ja ajalooliselt välja kujunenud. Ja kui detaljidesse laskuda, peab operatsioonisüsteem edastama virtuaalsed aadressid füüsilistesse aadressitesse. See protsess ei ole kõige lihtsam, seega talletab operatsioonisüsteem selle operatsiooni tulemuse Translation Lookaside Bufferis (TLB).

Ja kuna TLB on vahemälu, siis sellistes olukordades tekivad kõik sellele omased probleemid. Esiteks, kui teil on väga palju jõudlusse mälu ja see on kõik jaotatud väikesteks tükkideks, siis muutub see vahemälu väga suureks. Ja kui vahemälu on suur, on selle tõttu otsimine aeglasem. Üleminek on suur ja see ise võtab ruumi, st, et operatiivmälu tarbib midagi ebavajalikku. See on esimene punkt.

Teiseks – mida suurem muutub vahemälu sellises olukorras, seda suurem on tõenäosus, et teil tekib cache misses. Ja selle vahemälu efektiivsus langeb kiiresti koos selle suuruse suurenemisega. Seetõttu on operatsioonisüsteemides välja mõeldud lihtne lähenemine. Linuxis on see juba ammu kasutusel. FreeBSD-s on see mitte nii kaua tagasi ilmunud. Kuid me räägime Linuxist. See on huge pages.

Siinkohal tuleb märkida, et huge pages mõtteviit oli algselt edendatud kogukondade poolt, kuhu kuulusid Oracle ja IBM, st andmebaasi tootjad mõtlesid tõsiselt, et see võiks olla kasulik, sealhulgas andmebaaside jaoks.

Kuidas seda PostgreSQL-iga siduda? Esiteks peavad Linuxi ydas olema lubatud huge pages.

Teiseks, need peavad olema selgelt määratud sysctl parameetriga – kui palju neid on. Numbrid siinkohal pärinevad mõnelt vanalt serverilt. Saate arvutada, kui palju teile ligikaudu shared buffers on, et huge pages sinna mahuksid.

Ja kui kogu server on pühendatud PostgreSQL-ile, siis hea lähtepunkt on kas anda 25% operatiivmälast jagatud pufferitele või 75%, kui olete kindel, et teie andmebaas mahub kindlasti sellesse 75% suurusesse. Esimene lähtepunkt. Ja arvutage, kui teil on 256 GB operatiivmälu, siis vastavalt on 64 GB jagatud pufferite jaoks. Arvutage veidi marginaaliga – milline peaks see arv olema.

Enne versiooni 9.2 (kui ma ei eksi, alates versioonist 8.2) oli võimalik kolmanda osapoole raamatukogu abil PostgreSQL ühendada huge pages'iga. Ja seda tuleb alati teha. Esiteks, teil on vajalik, et kernel oskaks huge pages'i õigesti jagada. Teiseks, rakendusel, mis nendega töötab, peab olema võimalus neid kasutada. Ilma selle võimaluseta ei saa see nendest kasu. Kuna PostgreSQL jagas mälu system 5 stiilis, sai seda teha libhugetlbfs abil — see on selle raamatukogu täisnimi.

Versioonis 9.3 paranes PostgreSQL-i jõudlus mälu haldamisel ja loobuti system 5 mälu jagamise meetodist. Kõik olid väga rõõmsad, sest muidu proovisid sa käivitada kahte PostgreSQL-i instantsi samal masinal ja ütles, et mul on jagatud mälu vähe. Ja selgus, et sysctl tuleb muuta. Ja seal on selline sysctl, et peab veel taaskäivitama jne. Ühesõnaga, kõik olid rõõmsad. Kuid mmap-i mälu jagamine rikkus huge pages'i kasutamist. Enamik meie kliente kasutab suuri jagatud puhvreid. Ja me soovisime tungivalt mitte minna versioonile 9.3, kuna seal tekkis ülekattega probleemide hulk.

Aga siiski tähelepanu sellele probleemile pööras community ja versioonis 9.4 töötati seda väga hästi ümber. Ja versioonis 9.4 ilmus parameeter postgresql.conf-is, kus saab lubada try, on või off.

Try on kõige ohutum parameeter. PostgreSQL-i käivitamisel, kui see jagab jagatud mälu, püüab ta endale vastava mälu saada huge pages-ist. Ja kui see ei õnnestu, siis tagasi tavalisel jagamisel. Kui teie süsteem on FreeBSD või Solaris, siis saate panna try, see on alati ohutu.

Kui on on, siis see lihtsalt ei käivitu, kui ei suutnud huge pages'ist jagada. Siin sõltub kõik teie eelistustest. Kuid kui teil on seadistatud try, siis kontrollige, et teil on tõepoolest see, mis peab olema eraldatud, sest seal on palju viga tegemise ruumi. Praegu töötab see funktsioon ainult Linuxis.

Veel tähelepanuts, enne kui läheme edasi. Transparent huge pages ei kehti hetkel PostgreSQL jaoks. Ta ei saa neid normaalselt kasutada. Ja transparent huge pages puhul, kui on vajalik suur osa jagatud mälu, tulevad eelised esile ainult väga suurte mahtude korral. Kui teil on terabaiti mälu, siis see võib mängida rolli. Aga kui räägime tavapärastest rakendustest, kus teie masinas on 32, 64, 128, 256 GB mälu, siis tavalised huge pages on ok ja transparent tuleb lihtsalt välja lülitada.

Ja viimane asi, mis on mäluga seotud, ei ole otseselt seotud läbilaskevõimega, vaid võib elu oluliselt halvendada. Kogu läbilaskvus kannatab selle all, et server vahetab pidevalt.

Ja see on mitmel hetkel väga ebameeldiv. Peamine ebameeldivus tuleneb sellest, et kaasaegsete kernide käitumine erineb veidi vanematest Linuxi kernidest. Ja see on asi, mille peale astuda on üsna ebameeldiv, kuna kui räägime swap'iga töötamisest, lõppeb see OOM-killeri ebamugava sissetuleku tõttu. Ja OOM-killer, mis ei tule õigeaegselt ja lõpetab PostgreSQL-i, on ebameeldiv. Sellest saavad teada kõik, st viimane kasutaja.

Mis toimub? Sul on seal suur hulk operatiivmälu, kõik töötab hästi. Kuid mingil põhjusel server hangub swap'is ja see põhjustab viivitusi. Tundub, et mälu on piisavalt, aga see juhtub ikkagi.

Varem soovitasime vm.swappiness nulli seadistada, st swap välja lülitada. Varem tundus, et 32 GB operatiivmälu ja vastavad jagatud buferid on tohutu hulk. Swap'i peamine eesmärk on anda ruumi, kuhu visata tuum, kui oleme kukkunud. Ja see ei täitnud enam oma eesmärki. Ja mida sa selle tuumaga pärast teed? See on juba selline ülesanne, kus ei ole eriti selge, miks swap'i sellises suuruses üldse vaja on.

Kuid kaasaegsemates, st kolmandates versioonides on käitumine muutunud. Ja kui seadistada swap nulli, st välja lülitada, siis varem või hiljem, isegi kui mõned mäluressursid on alles, tuleb OOM-killer teie juurde, et tappa kõige intensiivsemad ressursikasutajad. Sest ta arvab, et sellise töökoormuse korral on meil jäänud veel vähe mälu ja me läheme üle piiri, st mitte süsteemset protsessi tapma, vaid midagi vähem olulist. Selleks vähem oluliseks osutub intensiivne jagatud mälu tarbija, nimelt postmaster. Ja pärast seda on hea, kui andmebaasi ei pea taastama.

Seetõttu on nüüd vaikimisi, kui ma õigesti mäletan, enamikus jaotustes umbes 6, st millal hakata kasutama swap'i sõltuvalt sellest, kui palju mälu on jäänud. Me soovitame praegu seadistada vm.swappiness = 1, sest see praktiliselt lülitab selle välja, kuid ei too kaasa selliseid efekte, nagu ootamatult saabunud OOM-killer ja kõik see, mis on igasuguste probleemide põhjus.

Mis edasi? Kui räägime andmebaaside jõudlusest ja järk-järgult jõuame ketaste juurde, haaravad kõik oma pead. Sest tõde, et ketas on aeglane ja mälu kiire, on kõigile lapsepõlvest tuttav. Ja kõik teavad, et andmebaasis tekivad probleemid ketta jõudlusega.

Peamine probleem PostgreSQL-i jõudlusega, mis on seotud checkpoints spikes'idega, ei tulene mitte sellest, et ketas on aeglane. See tuleneb pigem sellest, et mälu ja ketta läbilaskevõime ei ole tasakaalus. Samas võivad nad olla tasakaalustamata erinevates kohtades. PostgreSQL ei ole seadistatud, operatsioonisüsteem ei ole seadistatud, riistvara ei ole seadistatud ja riistvara ei ole õige. Ja seda probleem ei esine ainult siis, kui kõik toimub nii nagu peab, st kas koormust ei ole või seadistused ja riistvara on hästi valitud.

Mis see on ja kuidas see välja näeb? Tavaliselt astuvad inimesed, kes töötavad PostgreSQL-iga, sellesse valdkonda korduvalt. Selgitan. Nagu ma ütlesin, teeb PostgreSQL perioodiliselt kontrollpunkte, et määrdunud lehed jagatud mälust kettale salvestada. Kui meil on suur jagatud mälu maht, siis hakkab kontrollpunkt intensiivselt kettale mõju avaldama, kuna see salvestab need lehed fsync'iga. Need jõuavad kernel-buffrisse ja kirjutatakse ketastele fsync'i abil. Ja kui selle mahud on suured, siis võime jälgida ebameeldivat efekti, nimelt väga kõrget ketaste kasutust.

Siin on mul kaks pilti. Selgitan, mis need on. Need on kaks ajaliselt korreleeritud graafikut. Esimene graafik – see on ketta kasutus. Siin ulatub see antud hetkel peaaegu 90%-ni. Kui teie andmebaas ja füüsilised kettad koos RAID-kontrolleriga saavutavad 90% kasutust, siis on see halvad uudised. See tähendab, et veel natuke ja jõuame 100%-ni ning sisend-väljund peatub.

Kui teil on kettasüsteem, siis on seal veidi teine lugu. See sõltub sellest, kuidas see on konfigureeritud, milline süsteem see on jne.

Samas on siin konfigureeritud graafik PostgreSQL-i sisemise vaate põhjal, mis näitab, kuidas kontrollpunkt toimub. Roheline värv näitab, kui palju bufreid, neid määrdunud lehti, on sel hetkel selle kontrollpunkti jaoks sünkroniseerimiseks saabunud. Ja see on peamine, mida siin teadma peame. Näeme, et meil on siin palju lehti saabunud ja mingil hetkel saime 'plaati' otsa, st kirjutasime-kirjutasime, siin on ilmselgelt kettasüsteem väga hõivatud. Ja meie kontrollpunkt avaldab kettale suurt mõju. Ideaalis peaks olukord välja nägema pigem nii, et meil oleks siin vähem kirjutatud. Ja saame seadistustega selle parandada, et tulevikus niimoodi ei juhtuks. St kasutus on väike, kuid midagi me siin kirjutame.

Mida tuleb teha, et see probleem ületada? Kui teie andmebaasi IO on peatunud, tähendab see, et kõik kasutajad, kes tulid oma päringute täitmiseks, peavad ootama.

Kui vaadata Linuxi perspektiivist, siis kui olete valinud hea riistvara, seadistanud selle õigesti ja konfigureerinud PostgreSQL, et see teeks need checkpoints harvem, ja hajutaks need ajaliselt, siis jääte Debian'i vaikeseadistuste juurde. Enamiku Linuxi distributsioonide puhul on pilt järgmine: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Mida see tähendab? Tuumast 2.6 alates ilmus üks demon, mis tegeleb andmete tühjendamisega. Pdglush sõltuvalt sellest, kes mida kasutab, tegeleb taustal määrdunud lehtede eemaldamisega kernel buffer'ist ja eemaldab need, kui on hädavajalik tühjendada määrdunud lehti, kui taustal tühjendamine enam ei aita.

Millal algab taust? Kui 10% kogu serveri RAM-ist on määrdunud lehtedega kernel buffer'is, siis kutsutakse spetsiaalne funktsioon tühjendamiseks taustal. Miks see on taustal? See võtab parameterina, kui palju lehti tühjendada. Näiteks tühjendab N lehte. Ja mõneks ajaks see asi magab. Siis tuleb see jälle ja tühjendab veel mingi arvu lehti.

See on äärmiselt lihtne lugu. Siin on ülesanne nagu basseinis, kus ühte torusse voolab vett ja teisest voolab välja. Meil on checkpoint ja kui ta on saatnud vähe määrdunud lehti eemaldamiseks, siis imenduvad need järk-järgult kernel buffer'i pgflush'i kaudu.

Kui need määrdunud lehed jätkuvalt kuhjuvad, kuhjuvad nad kuni 20%, pärast seda on OS prioriteet need ära tühjendada, sest võite kaotada toite ja meil läheb kõik halvasti. Näiteks võime kaotada need andmed.

Mis on trikk? Trikk seisneb selles, et need parameetrid, 20 ja 10% kogu masina RAM-ist, on täiesti kohutavad diskisüsteemi läbilaskvuse seisukohalt, mis teil on.

Kujutage ette, et teil on 128 GB RAM. 12,8 GB jõuab teie diskisüsteemi. Ja milline iganes vahemälu või maatriks teil seal on, ei suuda nad seda taluda.

Seetõttu soovitame need numbrid kohe seadistada vastavalt teie RAID-kontrolleri võimalustele. Mul on siin kohe soovitus kontrolleri jaoks, millel on 512 MB vahemälu.

Arvatakse, et kõik on väga lihtne. Võite vm.dirty_background seadistada baitides. Need seaded tühistavad kaks eelnevat. Kas defaukti järgi, või aktiveeritakse need, mis on baitides, ja siis töötavad need, mis on baitides. Aga kuna ma olen DBA-konsultant ja töötan erinevate klientidega, siis püüan ma tagada, et kõik oleks stabiilne, seega, kui baitides, siis baitides. Keegi ei ole andnud mingisugust garantiid, et hea admin ei lisa serverisse mälu, ei taaskäivita teda, ja numbrid jäävad samaks. Lihtsalt arvutage need numbrid, et garanteerida, et kõik mahub sinna sisse.

Mis juhtub, kui te ei mahu sisse? Mul on kirjas, et igasugune flushing peatub efektiivselt, aga tegelikult on see metafoor. Operatsioonisüsteemil on tõsine probleem – tal on palju räpane lehti, seega peatub efektiivselt see IO, mis teie klientide poolt genereeritud, st. kui rakendus saadab SQL-päringu andmebaasi, ootab see. Iga IO sinna – on madalaimal prioriteedil, sest andmebaas on kinni checkpointis. Ja millal ta selle lõpetab, pole selge. Ja kui olete jõudnud mitte-taustalisse flushing'usse, siis see tähendab, et kogu teie IO on selle tööga hõivatud. Ja seni, kuni see ei lõpeta, ei tee te midagi.

Siin on veel kaks olulist punkti, mis ületavad selle ettekande piire. Need seaded peavad vastama postgresql.conf seadetega, st. checkpointide seadistustega. Ja teie diskisüsteem peab olema õigesti seadistatud. Kui teil on RAID-kate, siis sellel peaks olema aku. Inimesed ostavad RAIDi hea kätiga ilma akuta. Kui teil on SSD RAIDis, siis need peaks olema serveri tüüpi, seal peaks olema kondensaatorid. Siin on põhjalik kontrollnimekiri. Selle lingi kaudu on mu ettekannet, kuidas konfigureerida disk perfomance'i PostgreSQL-is. Seal on kõik need kontrolle.

Mis veel võib elu keeruliseks muuta? Need on kaks parameetrit. Need on suhteliselt uued. Need võivad erinevates rakendustes olla vaikimisi sisselülitatud. Ja need võivad keeruliseks muuta elu mitte vähem, kui nad on valesti sisse lülitatud.

On kaks suhteliselt uut funktsiooni. Need on juba ilmunud kolmandates kernites. Need on sched_migration_cost nanosekundites ja sched_autogroup_enabled, mis vaikimisi on üks.

Ja kuidas nad elu rikuvad? Mis on sched_migration_cost? Linuxi ajakava võib protsessi migreerida ühest CPU-st teise. Ja PostgreSQL jaoks, mis täidab päringuid, on migreerimise põhjustamine teisele CPU-le täiesti arusaamatu. Operatsioonisüsteemi seisukohalt, kui vahetate aknaid OpenOffice'i ja terminali vahel, siis see võib-olla on hea, kuid andmebaasi jaoks – see on väga halb. Seetõttu on mõistlik poliitika seada migration_cost mõneks suureks väärtuseks, vähemalt paar tuhat nanosekundit.

Mida see scheduler’i jaoks tähendab? Ta peab arvestama, et selle aja jooksul on see protsess endiselt kuum. T. e. kui teil on mõni pikk tehing, mis millegagi kaua tegeleb, siis scheduler saab sellest aru. Ta arvab, et seni, kuni see ajavahemik ei ole möödas, ei ole mõtet seda protsessi mitte kuhugi migreerida. Kui protsess sel ajal midagi teeb, siis ei migreerita seda kuhugi, vaid ta lõpetab rahulikult selle CPU-l, mis talle määratud. Ja tulemus on suurepärane.

Teine aspekt on autogroup. Oleks hea idee spetsiifiliste töökoormuste jaoks, mis ei ole seotud kaasaegsete andmebaasidega – rühmitada protsessid vastavalt sellele virtuaalsele terminalile, mille alt nad on käivitatud. See on mugav mõningate ülesannete jaoks. Praktikas on PostgreSQL mitme protsessiga süsteem prefork’iga, mis käivitatakse ühest terminalist. Teil on lock writer, checkpoint ja kõik teie kliendipäringud rühmitatakse ühe ajakava alla, ühe CPU alla. Ja nad ootavad seal rahulikult, kuni see vabastatakse, et üksteisele segada ja kauem oma ressursse kasutada. See on lugu, mis on sellise koormuse korral täiesti ebavajalik ja seetõttu tuleb see välja lülitada.

Minu kolleeg Alexey Lesovski tegi teste lihtsa pgbench'iga, kus ta suurendas migration_cost väärtust ja lülitas autogroup välja. Halva riistvara korral oli erinevus peaaegu 10%. Postgresi postituslistis toimub arutelu, kus inimesed toovad tulemusi selle kohta, kuidas sarnased muutused päringu kiirus mõjutasid 50%. Selliseid lugusid on päris palju.

Ja lõpetuseks vooluharjumuste poliitika. Hästi, et nüüd saab Linuxit kasutada sülearvutis. Ja see eeldab, et see säästab aku energiat. Kuid ootamatult selgub, et serveris võib see samuti juhtuda.

Veelgi enam, kui rentite servereid mõnelt hostitajalt, siis on "head" hostitajad ei hoolitse selle eest, et teie jõudlus oleks parem. Nende ülesanne on tagada, et nende riistvara oleks maksimaalselt efektiivne. Seetõttu võivad nad vaikimisi oma operatsioonisüsteemis lubada sülearvuti energiasäästurežiimi.

Kui kasutate andmebaasi serveris, mille koormus on kõrge, siis teie valikuks on acpi_cpufreq + performance. Isegi ondemandiga hakkavad juba probleemid tekkima.

Intel_pstate on juba veidi teine draiver. Praegu eelistatakse seda, kuna see on uuem ja töötab paremini.

Ja seega governor ainult performance. Ondemand, powersave ja kõik muu – see ei ole teie jaoks.

PostgreSQL explain analyze tulemused võivad erineda mitme järgu võrra, kui lubate powersave, kuna teie all oleva andmebaasi CPU ajakava on täiesti ettearvamatu.

Need asjad võivad olla vaikimisi sisse lülitatud. Vaadake hoolikalt – kas need on vaikimisi sisse lülitatud. See võib olla tõeliselt suur probleem.

Ja lõpuks tahaksin tänada meie DBA meeskonna PosgreSQL-Consulting, eriti Maks Bogu ja Aleksei Lesovsky, kes iga päev sellel alal vaeva näevad. Me püüame meie klientide jaoks teha kõik võimaliku, et see toimiks hästi. Siin on see nagu lennuohutuse juhistes. Kõik on kirjutatud verega. Iga mutter avastatakse mingi probleemi käigus. Jagame rõõmuga koos teiega.

Küsimused:

Aitäh! Kui näiteks ettevõte soovib kokku hoida ja paigutada andmebaasi ning rakenduse loogika samale serverile või kui ettevõte järgib moes suundi mikroteenuste arhitektuuris, kus PostgreSQL töötab konteineris. Mis on trikk? Sysctl mõjutavad globaalselt kogu tuuma. Ma ei ole kuulnud, et sysctl kuidagi virtualiseeritaks, et need toimiksid konteineris eraldi. Ainult cgroup ja seal on kontroll ainult osa kohta. Kuidas sellega elada? Või kui soovite jõudlust, siis käivitage PostgreSQL eraldi füüsilisel serveril ja optimeerige seda?

Me vastasime teie küsimusele umbes kolme erineva viisi kaudu. Kui jutt ei ole raua serverist, mida saab seadistada jne, siis võtke rahulikult, kõik töötab hästi ilma nende seadistusteta. Kui teil tekib koormus, mis nõuab neid seadistusi, siis jõuate raua serverini varem, kui nende seadistusteni.

Mis on probleem? Kui see on virtuaalmasin, siis on tõenäoliselt palju probleeme, näiteks see, et paljuski virtuaalmasinate kettas on ebajärjekindel latentsus. Isegi kui ketaste ribalaius on hea, siis üks ebaõnnestunud sisend-väljundoperatsiooni tehing, mis ei mõjuta keskmist ribalaiust, mis juhtus hetkel checkpoin'is või WAL'i kirjutamisel, põhjustab andmebaasile tõsiseid probleeme. Ja te märkate seda varem, kui te nendesse probleemidesse takerduda.

Kui teil on NGINX samal serveril, siis on ka sama probleem. Ta võitleb jagatud mäluga. Ja te ei jõua kunagi siinkohal kirjeldatud probleemideni.

Aga teisest küljest, mõned neist parameetritest on teile ikkagi olulised. Näiteks, seadistage sysctl'is dirty_ratio, et see ei oleks nii hull – see aitab sellegipoolest. Igal juhul on teil suhe kettaga. Ja see toimub vale mustri järgi. Need on vaikimisi parameetrid, mida ma näitasin. Ja igal juhul on parem need muuta.

NUMA-ga võivad olla probleemid. VmWare töötab näiteks NUMA-ga hästi täpselt vastupidiste seadistustega. Siin tuleb valida – raua server või mitte raua.

Mul on küsimus, mis on seotud Amazon AWS-iga. Neil on eelkonfigureeritud pildid. Üks neist nimetatakse Amazon RDS-iks. Kas seal on mingeid kohandatud seadistusi nende operatsioonisüsteemi jaoks?

Seal on seadistused, kuid need on teistsugused seadistused. Siin seadistame operatsioonisüsteemi vaatenurgast, kuidas andmebaas seda kasutab. Ja seal on parameetrid, mis määravad, kuhu me praegu minema peame, selline shaping. Ehk me vajame nii palju ressursse, me hakkame neid nüüd kulutama. Pärast seda kinnitab Amazon RDS need ressursid, ja sealne jõudlus kannatab. On eraldi lugusid, kuidas inimesed hakkavad sellega eksperimenteerima. Mõnikord isegi üsna edukalt. Kuid see ei ole seotud operatsioonisüsteemi seadistustega. See on nagu pilve häkkimine. See on teine lugu.

Miks Transparent huge pages ei toimi võrreldes Huge TLB-ga?

Ei toimi. Seda saab selgitada mitmeti. Kuid tegelikult nad lihtsalt ei anna efekti. Mis lugu on PostgreSQLiga? Ta eraldab käivitamisel suure tüki jagatud mälust. Kas nad on transparent või mitte – see pole absoluutselt oluline. Fakt, et nad eraldatakse käivitamisel, selgitab kõike. Ja kui mälu on väga palju ja jagatud mälu segmenti tuleb ümber ehitada, siis on Transparent huge pages asjakohased. PostgreSQL eraldab selle lihtsalt käivitamisel tohutu tüki ja kõik, edasi seal midagi erilist ei toimu. Loomulikult võib seda kasutada, kuid on oht saada jagatud mälu kahjustusi, kui see püüab midagi uuesti eraldada. PostgreSQL ei tea sellest.

Allikas: habr.com