Linuxin viritys PostgreSQL:n suorituskyvyn parantamiseksi. Ilja Kosmodemyansky

Transkriptio Ilja Kosmodemyanskyn vuoden 2015 raportista "Linuxin viritys PostgreSQL-suorituskyvyn parantamiseksi"

Vastuuvapauslauseke: Huomaan, että tämä raportti on päivätty marraskuussa 2015 - yli 4 vuotta on kulunut ja paljon aikaa on kulunut. Raportissa käsiteltyä versiota 9.4 ei enää tueta. Viimeisten 4 vuoden aikana on julkaistu 5 uutta PostgreSQL-julkaisua ja 15 versiota Linux-ytimestä. Jos kirjoitat nämä kohdat uudelleen, saat toisenlaisen raportin. Mutta tässä tarkastelemme perustavaa Linux-viritystä PostgreSQL:lle, joka on edelleen ajankohtainen.

Nimeni on Ilja Kosmodemyansky. Työskentelen PostgreSQL-Consultingissa. Ja nyt puhun hieman siitä, mitä tehdä Linuxin kanssa suhteessa tietokantoihin yleensä ja erityisesti PostgreSQL: hen, koska periaatteet ovat melko samanlaiset.

Mistä puhumme? Jos kommunikoit PostgreSQL:n kanssa, sinun on jossain määrin oltava UNIX-järjestelmänvalvoja. Mitä se tarkoittaa? Jos vertaamme Oraclea ja PostgreSQL:ää, niin Oraclessa sinun on oltava 80% DBA-tietokannan ylläpitäjä ja 20% Linux-järjestelmänvalvoja.

PostgreSQL:llä se on hieman monimutkaisempaa. PostgreSQL:n avulla sinulla on oltava paljon parempi käsitys Linuxin toiminnasta. Ja samalla vähän juosta veturin perässä, sillä viime aikoina kaikki on päivitetty aika mukavasti. Ja uusia ytimiä julkaistaan, uusia toimintoja ilmestyy, suorituskyky paranee jne.

Miksi puhumme Linuxista? Ei ollenkaan siksi, että olemme Linux-konferenssissa Peter, vaan koska nykyaikaisissa olosuhteissa yksi oikeutetuimmista käyttöjärjestelmistä tietokantojen ja erityisesti PostgreSQL:n käyttöön on Linux. Koska FreeBSD, valitettavasti, kehittyy johonkin hyvin outoon suuntaan. Ja ongelmia tulee sekä suorituskyvyn että monien muiden asioiden kanssa. PostgreSQL:n suorituskyky Windowsissa on yleensä erillinen vakava ongelma, joka perustuu siihen, että Windowsilla ei ole samaa jaettua muistia kuin UNIXissa, kun taas PostgreSQL on kaikki sidottu tähän, koska se on moniprosessijärjestelmä.

Ja uskon, että kaikki ovat vähemmän kiinnostuneita Solariksen kaltaisista eksoottisista kohteista, joten mennään.

Nykyaikaisessa Linux-jakelussa on yli 1 syctl-vaihtoehtoa riippuen siitä, kuinka rakennat ytimen. Samaan aikaan, jos tarkastelemme erilaisia ​​pähkinöitä, voimme säätää jotain monin tavoin. Niiden liittämiseen on tiedostojärjestelmäparametreja. Jos sinulla on kysyttävää sen käynnistämisestä: mitä otetaan käyttöön BIOSissa, kuinka laitteisto määritetään jne.

Tämä on erittäin suuri volyymi, josta voidaan keskustella useiden päivien ajan, eikä yhdessä lyhyessä raportissa, mutta nyt keskityn tärkeisiin asioihin, kuinka välttää niitä rakeita, jotka taatusti estävät sinua käyttämästä tietokantaa hyvin Linuxissa, jos älä korjaa niitä. Ja samalla tärkeä seikka on, että monet oletusparametrit eivät sisälly tietokannan oikeisiin asetuksiin. Eli oletusarvoisesti se toimii huonosti tai ei ollenkaan.

Mitä perinteisiä virityskohteita Linuxissa on? Uskon, että koska olette kaikki tekemisissä Linuxin hallinnan kanssa, ei ole erityistä tarvetta selittää, mitkä ovat tavoitteet.

Voit virittää:

• CPU.
• Muisti.
• Varastointi.
• muu. Puhumme tästä lopuksi välipalaksi. Jopa esimerkiksi parametrit, kuten energiansäästöpolitiikka, voivat vaikuttaa suorituskykyyn hyvin arvaamattomalla ja ei kaikkein miellyttävimmällä tavalla.

Mitkä ovat PostgreSQL:n ja tietokannan erityispiirteet yleensä? Ongelmana on, että et voi säätää yksittäistä mutteria ja nähdä, että suorituskykymme on parantunut merkittävästi.

Kyllä, tällaisia ​​vempaimia on, mutta tietokanta on monimutkainen asia. Se on vuorovaikutuksessa kaikkien palvelimella olevien resurssien kanssa ja haluaa olla vuorovaikutuksessa täysillä. Jos katsot Oraclen nykyisiä suosituksia isäntäkäyttöjärjestelmän käytöstä, se on kuin vitsi tuosta mongolialaisesta kosmonautista - ruoki koiraa äläkä koske mihinkään. Annetaan tietokannalle kaikki resurssit, tietokanta itse selvittää kaiken.

Periaatteessa tilanne on jossain määrin täsmälleen sama PostgreSQL:n kanssa. Erona on, että tietokanta ei vielä pysty ottamaan kaikkia resursseja itselleen, eli jossain Linux-tasolla sinun täytyy selvittää kaikki itse.

Pääajatuksena ei ole valita yhtä kohdetta ja alkaa virittää sitä, esimerkiksi muistia, prosessoria tai jotain vastaavaa, vaan analysoida työkuormaa ja yrittää parantaa suorituskykyä niin paljon kuin mahdollista niin, että kuormitus, jonka hyvät ohjelmoijat loivat sen. meille, myös käyttäjillemme.

Tässä on kuva, joka selittää, mikä se on. On Linux-käyttöjärjestelmäpuskuri, jaettu muisti ja PostgreSQL-puskurit. PostgreSQL, toisin kuin Oracle, toimii suoraan vain ytimen puskurin kautta, eli jotta sivu levyltä pääsisi sen jaettuun muistiin, sen on mentävä ytimen puskurin läpi ja takaisin, täsmälleen sama tilanne.

Levyt elävät tämän järjestelmän alla. Piirsin tämän levyiksi. Itse asiassa siellä voi olla RAID-ohjain jne.

Ja tämä panos-tulostus tapahtuu tavalla tai toisella tämän asian kautta.

PostgreSQL on klassinen tietokanta. Sisällä on sivu. Ja kaikki syöttö ja tulostus tapahtuu sivujen avulla. Nostamme lohkoja muistiin sivuilla. Ja jos mitään ei tapahtunut, luimme ne vain, sitten ne vähitellen katoavat tästä välimuistista, jaetuista puskureista ja päätyvät takaisin levylle.

Jos vaihdamme jotain jossain, koko sivu merkitään likaiseksi. Merkitsin ne tänne sinisellä. Ja tämä tarkoittaa, että tämä sivu on synkronoitava lohkotallennustilan kanssa. Eli kun teimme sen likaiseksi, teimme merkinnän WAL:iin. Ja eräänä ihmeellisenä hetkenä tuli ilmiö nimeltä checkpoint. Ja tähän lokiin kirjattiin tieto, että hän oli saapunut. Ja tämä tarkoittaa, että kaikki likaiset sivut, jotka olivat tällä hetkellä tässä jaetuissa puskureissa, synkronoitiin tallennuslevyn kanssa fsyncin avulla ytimen puskurin kautta.

Miksi näin tehdään? Jos menetimme jännitteen, emme saaneet tilannetta, jossa kaikki tiedot katosivat. Pysyvä muisti, josta kaikki kertoivat meille, on toistaiseksi tietokantoteoriassa - tämä on valoisa tulevaisuus, johon me tietysti pyrimme ja pidämme siitä, mutta toistaiseksi he elävät miinus 20 vuodessa. Ja tietysti tätä kaikkea pitää seurata.

Ja suorituskyvyn maksimoimisen tehtävänä on hienosäätää kaikkia näitä vaiheita niin, että kaikki liikkuu nopeasti edestakaisin. Jaettu muisti on pohjimmiltaan sivuvälimuisti. PostgreSQL:ssä lähetimme valintakyselyn tai jotain, se haki nämä tiedot levyltä. He päätyivät yhteisiin puskureihin. Näin ollen, jotta tämä toimisi paremmin, muistia on oltava paljon.

Jotta kaikki tämä toimisi hyvin ja nopeasti, sinun on määritettävä käyttöjärjestelmä oikein kaikissa vaiheissa. Ja valitse tasapainotettu laitteisto, koska jos sinulla on jossain paikassa epätasapaino, voit tehdä paljon muistia, mutta sitä ei huolleta riittävällä nopeudella.

Ja käydään läpi jokainen näistä kohdista.

Jotta nämä sivut liikkuvat edestakaisin nopeammin, sinun on saavutettava seuraavat:

• Ensinnäkin sinun on työskenneltävä tehokkaammin muistin kanssa.
• Toiseksi tämän siirtymän, kun sivut siirtyvät muistista levylle, pitäisi olla tehokkaampi.
• Ja kolmanneksi, täytyy olla hyviä levyjä.

Jos palvelimessa on 512 Gt RAM-muistia ja se kaikki päätyy SATA-kiintolevylle ilman välimuistia, koko tietokantapalvelin ei muutu pelkäksi kurpitsaksi, vaan kurpitsaksi, jossa on SATA-liitäntä. Törmäät siihen suoraan. Ja mikään ei pelasta sinua.

Mitä tulee ensimmäiseen muistiin, on kolme asiaa, jotka voivat tehdä elämästä erittäin vaikeaa.

Ensimmäinen niistä on NUMA. NUMA on asia, joka on tehty parantamaan suorituskykyä. Työmäärästä riippuen erilaisia ​​asioita voidaan optimoida. Ja uudessa nykyisessä muodossaan se ei ole kovin hyvä sovelluksille, kuten tietokantoille, jotka käyttävät intensiivisesti sivuvälimuistin jaettuja puskureita.

Pähkinänkuoressa. Mistä tiedät, onko NUMA:ssa jotain vialla? Sinulla on jonkinlainen epämiellyttävä koputus, yhtäkkiä jokin prosessori on ylikuormitettu. Samalla analysoit kyselyitä PostgreSQL:ssä ja huomaat, ettei siellä ole mitään vastaavaa. Nämä kyselyt eivät saa olla niin prosessoriintensiivisiä. Voit saada tämän kiinni pitkään. On helpompi käyttää alusta alkaen oikeaa suositusta NUMA:n määrittämiseen PostgreSQL:lle.

Mitä todella tapahtuu? NUMA on lyhenne sanoista Non-Uniform Memory Access. Mitä järkeä? Sinulla on CPU, sen vieressä on sen paikallinen muisti. Ja nämä muistiliitännät voivat vetää muistia muista suorittimista.

Jos juokset numactl --hardware, niin saat niin suuren arkin. Mukana on muun muassa etäisyyskenttä. Siellä on numeroita - 10-20, jotain sellaista. Nämä luvut eivät ole mitään muuta kuin hyppyjen lukumäärä tämän etämuistin poimimiseen ja sen paikalliseen käyttöön. Periaatteessa hyvä idea. Tämä nopeuttaa suorituskykyä hyvin erilaisissa työkuormissa.

Kuvittele nyt, että sinulla on yksi prosessori, joka yrittää ensin käyttää paikallista muistiaan ja sitten yrittää vetää ylös toisen muistin yhteenliittämisen kautta jotain varten. Ja tämä prosessori saa koko PostgreSQL-sivusi välimuistin - siinä kaikki, joitain gigatavuja. Saat aina pahimman tapauksen, koska CPU:ssa on yleensä vähän muistia itse moduulissa. Ja kaikki huollettava muisti kulkee näiden liitäntöjen kautta. Siitä tulee hidas ja surullinen. Ja tätä solmua palveleva prosessori on jatkuvasti ylikuormitettu. Ja tämän muistin käyttöaika on huono, hidas. Tämä on tilanne, jota et halua, jos käytät tätä tietokannassa.

Siksi tietokannan oikeampi vaihtoehto on, että Linux-käyttöjärjestelmä ei tiedä ollenkaan, mitä siellä tapahtuu. Joten se käyttää muistia sellaisenaan.

Miksi niin? Näyttäisi siltä, ​​että asian pitäisi olla toisinpäin. Tämä tapahtuu yhdestä yksinkertaisesta syystä: tarvitsemme paljon muistia sivun välimuistille - kymmeniä, satoja gigatavuja.

Ja jos allokoimme kaiken tämän ja tallensimme tietomme sinne, välimuistin käytöstä saatava hyöty on huomattavasti suurempi kuin hyöty näin hankalasta muistin käytöstä. Ja hyödymme siten verrattomasti verrattuna siihen, että käytämme muistia tehokkaammin NUMA:n avulla.

Siksi tässä on tällä hetkellä kaksi lähestymistapaa, kunnes valoisa tulevaisuus on saapunut, eikä tietokanta itse pysty selvittämään, millä prosessoreilla se toimii ja mistä sen pitää vetää jotain.

Siksi oikea lähestymistapa on poistaa NUMA kokonaan käytöstäesimerkiksi uudelleenkäynnistyksen yhteydessä. Useimmissa tapauksissa voitot ovat sen suuruusluokkaa, että kysymystä kumpi on parempi ei esiinny ollenkaan.

On toinenkin vaihtoehto. Käytämme sitä useammin kuin ensimmäistä, koska kun asiakas tulee meille tukea, palvelimen uudelleenkäynnistys on hänelle iso juttu. Hänellä on siellä yritys. Ja heillä on ongelmia NUMA:n takia. Siksi yritämme poistaa sen käytöstä vähemmän invasiivisilla tavoilla kuin käynnistämällä uudelleen, mutta varmista, että se on poistettu käytöstä. Koska, kuten kokemus osoittaa, on hyvä, että poistamme NUMA:n käytöstä PostgreSQL-emoprosessissa, mutta se ei ole ollenkaan välttämätöntä, että se toimii. Meidän täytyy tarkistaa ja nähdä, että hän todella sammui.

Robert Haasilta on hyvä postaus. Tämä on yksi PostgreSQL-sitoutujista. Yksi kaikkien matalan tason sisälmysten tärkeimmistä kehittäjistä. Ja jos seuraat tämän postauksen linkkejä, ne kuvaavat useita värikkäitä tarinoita siitä, kuinka NUMA teki ihmisten elämän vaikeaksi. Katso, tutki järjestelmänvalvojan tarkistuslistaa siitä, mitä palvelimella on määritettävä, jotta tietokanta toimisi hyvin. Nämä asetukset pitää kirjoittaa ylös ja tarkistaa, koska muuten ne eivät ole kovin hyviä.

Huomaa, että tämä koskee kaikkia asetuksia, joista puhun. Mutta yleensä tietokannat kerätään master-slave-tilassa vikasietoisuutta varten. Älä unohda tehdä näitä asetuksia orjalle, koska jonain päivänä joudut onnettomuuteen ja vaihdat orjaan ja siitä tulee isäntä.

Hätätilanteessa, kun kaikki on erittäin huonosti, puhelin soi jatkuvasti ja pomosi juoksee isolla kepillä, sinulla ei ole aikaa miettiä tarkistamista. Ja tulokset voivat olla varsin tuhoisia.

Seuraava kohta ovat suuret sivut. Valtavia sivuja on vaikea testata erikseen, eikä siinä ole mitään järkeä, vaikka on olemassa vertailuarvoja, jotka voivat tehdä tämän. Niitä on helppo googlettaa.

Mitä järkeä? Sinulla on ei kovin kallis palvelin, jossa on paljon RAM-muistia, esimerkiksi yli 30 Gt. Et käytä suuria sivuja. Tämä tarkoittaa, että sinulla on ehdottomasti ylimääräisiä kustannuksia muistinkäytön suhteen. Ja tämä yleiskustannukset eivät ole kaikkea muuta kuin miellyttävimmät.

Miksi niin? Joten mitä tapahtuu? Käyttöjärjestelmä varaa muistin pieniksi paloiksi. Se on niin kätevää, niin se tapahtui historiallisesti. Ja jos mennään yksityiskohtiin, käyttöjärjestelmän on muutettava virtuaaliset osoitteet fyysisiksi. Ja tämä prosessi ei ole yksinkertaisin, joten käyttöjärjestelmä tallentaa tämän toiminnon tuloksen välimuistiin Translation Lookaside Buffer (TLB).

Ja koska TLB on välimuisti, kaikki välimuistiin liittyvät ongelmat syntyvät tässä tilanteessa. Ensinnäkin, jos sinulla on paljon RAM-muistia ja se on allokoitu pienissä paloissa, tästä puskurista tulee erittäin suuri. Ja jos välimuisti on suuri, sen läpi etsiminen on hitaampaa. Overhead on terveellistä ja se vie itse tilaa, eli RAM-muistia kuluttaa jokin väärin. Tällä kertaa.

Kaksi - mitä enemmän välimuisti kasvaa tällaisessa tilanteessa, sitä todennäköisemmin välimuistissa on menetyksiä. Ja tämän välimuistin tehokkuus laskee nopeasti sen koon kasvaessa. Siksi käyttöjärjestelmät keksivät yksinkertaisen lähestymistavan. Sitä on käytetty Linuxissa pitkään. Se ilmestyi FreeBSD: ssä ei niin kauan sitten. Mutta puhumme Linuxista. Nämä ovat suuria sivuja.

Ja tässä on huomioitava, että valtavat sivut ajatuksena olivat alunperin Oracle- ja IBM-yhteisöt, eli tietokantavalmistajat ajattelivat vahvasti, että tästä olisi hyötyä myös tietokantoille.

Ja miten tämä voi ystävystyä PostgreSQL:n kanssa? Ensinnäkin suuret sivut on otettava käyttöön Linux-ytimessä.

Toiseksi ne on määriteltävä erikseen sysctl-parametrilla - kuinka monta niitä on. Tässä olevat numerot ovat joltain vanhalta palvelimelta. Voit laskea, kuinka monta jaettua puskuria sinulla on, jotta suuret sivut mahtuvat sinne.

Ja jos koko palvelimesi on omistettu PostgreSQL:lle, hyvä lähtökohta on varata joko 25 % RAM-muistista jaetuille puskureille tai 75 %, jos olet varma, että tietokantasi mahtuu varmasti tähän 75 %:iin. Lähtökohta yksi. Ja harkitse, jos sinulla on 256 Gt RAM-muistia, sinulla on vastaavasti 64 Gt suuria puskureita. Laske suunnilleen marginaalilla - mihin tämä luku tulisi asettaa.

Ennen versiota 9.2 (jos en erehdy, versiosta 8.2 lähtien) PostgreSQL oli mahdollista yhdistää valtaviin sivuihin kolmannen osapuolen kirjaston avulla. Ja näin pitää aina tehdä. Ensinnäkin tarvitset ytimen, jotta voit jakaa suuret sivut oikein. Ja toiseksi, jotta heidän kanssaan toimiva sovellus voi käyttää niitä. Sitä ei käytetä vain sillä tavalla. Koska PostgreSQL allokoi muistia system 5 -tyyliin, tämä voidaan tehdä käyttämällä libhugetlbfs -ohjelmaa - tämä on kirjaston koko nimi.

9.3:ssa PostgreSQL:n suorituskykyä parannettiin käytettäessä muistia ja järjestelmän 5 muistinvarausmenetelmästä luovuttiin. Kaikki olivat erittäin tyytyväisiä, koska muuten yrität ajaa kahta PostgreSQL-instanssia yhdellä koneella, ja hän sanoo, että minulla ei ole tarpeeksi jaettua muistia. Ja hän sanoo, että sysctl on korjattava. Ja siellä on sellainen sysctl, että sinun on vielä käynnistettävä uudelleen jne. Yleensä kaikki olivat tyytyväisiä. Mutta mmap-muistin varaus katkaisi valtavien sivujen käytön. Suurin osa asiakkaistamme käyttää suuria yhteisiä puskureita. Ja suosittelimme vahvasti, että 9.3:een ei vaihdeta, koska siellä alettiin laskea yleiskustannuksia hyvissä prosenteissa.

Mutta yhteisö kiinnitti huomiota tähän ongelmaan ja 9.4:ssä he muokkasivat tämän tapahtuman erittäin hyvin. Ja 9.4:ssä postgresql.conf-tiedostoon ilmestyi parametri, jossa voit ottaa try, päälle tai pois päältä.

Kokeile on turvallisin vaihtoehto. Kun PostgreSQL käynnistyy ja varaa jaettua muistia, se yrittää napata tämän muistin suurilta sivuilta. Ja jos se ei toimi, se palaa normaaliin valintaan. Ja jos sinulla on FreeBSD tai Solaris, voit kokeilla, se on aina turvallista.

Jos käytössä, se ei yksinkertaisesti käynnisty, jos se ei voinut valita valtavista sivuista. Täällä puhutaan jo siitä, kuka ja mikä on mukavampaa. Mutta jos olet yrittänyt, tarkista, että olet todella korostanut tarvitsemaasi, koska siinä on paljon tilaa virheille. Tällä hetkellä tämä toiminto toimii vain Linuxissa.

Vielä yksi pieni huomautus ennen kuin mennään pidemmälle. Läpinäkyvät valtavat sivut eivät vielä kerro PostgreSQL:stä. Hän ei voi käyttää niitä normaalisti. Ja Transparentin valtavat sivut sellaiseen työmäärään, kun tarvitaan paljon jaettua muistia, hyödyt tulevat vain erittäin suurista määristä. Jos sinulla on teratavua muistia, tämä voi tulla kysymykseen. Jos puhumme jokapäiväisemmistä sovelluksista, kun koneessasi on 32, 64, 128, 256 Gt muistia, niin tavalliset valtavat sivut ovat ok, ja poistamme vain Transparentin käytöstä.

Ja viimeinen asia muistissa ei liity suoraan fruitutiin, se voi todella pilata elämäsi. Palvelimen jatkuva vaihtaminen vaikuttaa suuresti kaikkeen suoritustehoon.

Ja tämä tulee olemaan erittäin epämiellyttävää monella tapaa. Ja suurin ongelma on, että nykyaikaiset ytimet käyttäytyvät hieman eri tavalla kuin vanhemmat Linux-ytimet. Ja tähän asiaan on aika epämiellyttävä astua, koska kun puhutaan jonkinlaisesta työstä swapin kanssa, se päättyy OOM-tappajan ennenaikaiseen saapumiseen. Ja OOM-tappaja, joka ei saapunut ajoissa ja pudotti PostgreSQL:n, on epämiellyttävä. Kaikki tietävät tästä, eli viimeiseen käyttäjään asti.

Mitä tapahtuu? Sinulla on paljon RAM-muistia siellä, kaikki toimii hyvin. Mutta jostain syystä palvelin roikkuu swapissa ja hidastuu tämän vuoksi. Näyttää siltä, ​​​​että muistia on paljon, mutta näin tapahtuu.

Aiemmin suosittelimme asettamaan vm.swappiness nollaan, eli poistamaan swapin käytöstä. Aikaisemmin näytti siltä, ​​että 32 Gt RAM-muistia ja vastaavat jaetut puskurit olivat valtava määrä. Vaihdon päätarkoitus on, että meillä on paikka heittää kuori, jos putoamme. Eikä se enää erityisen täyttynyt. Ja mitä sitten aiot tehdä tälle kuorelle? Tämä on tehtävä, jossa ei ole kovin selvää, miksi vaihtoa tarvitaan, varsinkin tällaisen kokoisena.

Mutta nykyaikaisemmissa, eli ytimen kolmannessa versiossa, käyttäytyminen on muuttunut. Ja jos asetat swapin nollaan, eli sammutat sen, niin ennemmin tai myöhemmin, vaikka RAM-muistia olisikin jäljellä, OOM-tappaja tulee luoksesi tappamaan intensiivisimmät kuluttajat. Koska hän ajattelee, että tuollaisella työmäärällä meillä on vielä vähän jäljellä ja hyppäämme ulos, eli emme naulaa järjestelmän prosessia, vaan naulaamme jotain vähemmän tärkeää. Tämä vähemmän tärkeä tulee olemaan jaetun muistin intensiivinen kuluttaja, nimittäin postimestari. Ja sen jälkeen on hyvä, jos alustaa ei tarvitse palauttaa.

Siksi nyt oletuksena, muistaakseni suurin osa jakeluista on jossain 6:n tienoilla, eli missä vaiheessa kannattaa aloittaa swapin käyttö sen mukaan, kuinka paljon muistia on jäljellä. Suosittelemme nyt asettamaan vm.swappiness = 1, koska tämä käytännössä sammuttaa sen, mutta ei anna samoja vaikutuksia kuin odottamatta saapuneella OOM-killerillä, joka tappoi koko jutun.

Mitä seuraavaksi? Kun puhumme tietokantojen suorituskyvystä ja siirrymme vähitellen kohti levyjä, kaikki alkavat tarttua päihinsä. Koska totuus, että levy on hidas ja muisti nopea, on tuttu kaikille lapsuudesta lähtien. Ja kaikki tietävät, että tietokannassa on levyn suorituskykyongelmia.

Pääasiallinen PostgreSQL-suorituskykyongelma, joka liittyy tarkistuspisteiden piikkeihin, ei esiinny, koska levy on hidas. Tämä johtuu todennäköisesti siitä, että muisti ja levyn kaistanleveys eivät ole tasapainossa. Ne eivät kuitenkaan välttämättä ole tasapainossa eri paikoissa. PostgreSQL:ää ei ole määritetty, käyttöjärjestelmää ei ole määritetty, laitteistoa ei ole määritetty ja laitteisto on virheellinen. Ja tätä ongelmaa ei tapahdu vain, jos kaikki tapahtuu niin kuin pitää, eli joko ei ole kuormaa tai asetukset ja laitteisto on valittu hyvin.

Mikä se on ja miltä se näyttää? Yleensä PostgreSQL:n kanssa työskentelevät ihmiset ovat tulleet tähän asiaan useammin kuin kerran. Minä selitän. Kuten sanoin, PostgreSQL tekee ajoittain tarkistuspisteitä tyhjentääkseen jaetussa muistissa olevat likaiset sivut levylle. Jos meillä on paljon jaettua muistia, tarkistuspisteellä alkaa olla voimakas vaikutus levyyn, koska se tyhjentää nämä sivut fsyncillä. Se saapuu ytimen puskuriin ja kirjoitetaan levyille fsyncin avulla. Ja jos tämän liiketoiminnan volyymi on suuri, voimme havaita epämiellyttävän vaikutuksen, nimittäin erittäin suuren levyjen käytön.

Tässä minulla on kaksi kuvaa. Selitän nyt mikä se on. Nämä ovat kaksi aikakorreloitua kuvaajaa. Ensimmäinen kaavio on levyn käyttö. Tässä se saavuttaa lähes 90 % tässä vaiheessa. Jos sinulla on tietokantavirhe fyysisten levyjen kanssa, kun RAID-ohjaimen käyttöaste on 90%, tämä on huono uutinen. Tämä tarkoittaa, että hieman enemmän ja se saavuttaa 100 ja I/O pysähtyy.

Jos sinulla on levyryhmä, se on hieman erilainen tarina. Se riippuu siitä, miten se on konfiguroitu, millainen matriisi se on jne.

Ja rinnakkain tässä konfiguroidaan sisäisestä postgres-näkymästä kuvaaja, joka kertoo kuinka tarkistuspiste tapahtuu. Ja vihreä väri tässä näyttää kuinka monta puskuria, näitä likaisia ​​sivuja, saapui sillä hetkellä tähän synkronoinnin tarkistuspisteeseen. Ja tämä on tärkein asia, joka sinun on tiedettävä täällä. Näemme, että meillä on täällä paljon sivuja ja jossain vaiheessa osuimme tauluun, eli kirjoitimme ja kirjoitimme, täällä levyjärjestelmä on selvästi erittäin kiireinen. Ja tarkistuspisteellämme on erittäin vahva vaikutus levyyn. Ihannetapauksessa tilanteen pitäisi näyttää enemmän tältä, eli meillä oli vähemmän äänitystä täällä. Ja voimme korjata sen asetuksilla niin, että se jatkuu samanlaisena. Eli kierrätys on pientä, mutta jossain täällä kirjoitetaan jotain.

Mitä on tehtävä tämän ongelman ratkaisemiseksi? Jos olet pysäyttänyt IO:n tietokannan alla, tämä tarkoittaa, että kaikki käyttäjät, jotka tulivat täyttämään pyyntönsä, odottavat.

Jos katsot Linuxin näkökulmasta, jos valitsit hyvän laitteiston, määritit sen oikein, konfiguroit PostgreSQL:n normaalisti niin, että se tekee näitä tarkistuspisteitä harvemmin, levittää ne ajan mittaan keskenään, niin astut oletusarvoisiin Debian-parametreihin. Useimmissa Linux-jakeluissa tämä on kuva: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Mitä se tarkoittaa? Yksi huuhteleva demoni ilmestyi ytimestä 2.6. Pdglush, riippuen siitä, kuka käyttää kumpaakin, joka poistaa taustalla likaiset sivut ytimen puskurista ja hylkää, kun on tarpeen hylätä likaiset sivut mitä tahansa, kun taustan hylkääminen ei auta.

Milloin tausta tulee? Kun 10 % palvelimella käytettävissä olevasta RAM-muistista on likaisten sivujen varassa ytimen puskurissa, taustalla kutsutaan erityinen poistotoiminto. Miksi se on tausta? Parametrina se ottaa huomioon, kuinka monta sivua poistetaan. Ja sanotaan, että hän kirjoittaa N sivua. Ja hetkeksi tämä asia nukahtaa. Ja sitten hän tulee taas ja kopioi lisää sivuja.

Tämä on erittäin yksinkertainen tarina. Ongelma tässä on kuin uima-altaassa, kun se kaatuu yhteen putkeen, se virtaa toiseen. Tarkistuspisteemme saapui ja jos se lähetti muutaman likaisen sivun hylättäväksi, niin vähitellen koko asia ratkeaa siististi ytimen puskurista pgflush.

Jos näitä likaisia ​​sivuja kertyy edelleen, niitä kertyy jopa 20%, minkä jälkeen käyttöjärjestelmän prioriteetti on kirjoittaa koko juttu levylle, koska virta katkeaa ja kaikki on huonosti meille. Menetämme esimerkiksi nämä tiedot.

Mikä on temppu? Temppu on, että nämä parametrit nykymaailmassa ovat 20 ja 10% koneen kokonaisRAM-muistista, ne ovat aivan hirveitä minkä tahansa levyjärjestelmän suorituskyvyn kannalta.

Kuvittele, että sinulla on 128 Gt RAM-muistia. 12,8 Gt saapuu levyjärjestelmääsi. Ja riippumatta siitä, mikä välimuisti sinulla on siellä, riippumatta siitä, mikä joukko sinulla on siellä, ne eivät kestä niin kauan.

Siksi suosittelemme, että säädät nämä numerot välittömästi RAID-ohjaimesi ominaisuuksien perusteella. Tein heti suosituksen täällä ohjaimesta, jossa on 512 Mt välimuistia.

Kaikkea pidetään hyvin yksinkertaisena. Voit laittaa vm.dirty_background tavuiksi. Ja nämä asetukset kumoavat kaksi edellistä. Joko suhde on oletuksena tai ne, joissa on tavuja, on aktivoitu, silloin tavuiset toimivat. Mutta koska olen DBA-konsultti ja työskentelen eri asiakkaiden kanssa, yritän piirtää pillejä ja siksi, jos tavuina, niin tavuina. Kukaan ei antanut takuuta siitä, että hyvä järjestelmänvalvoja ei lisää muistia palvelimeen, käynnistäisi sitä uudelleen ja luku pysyisi samana. Laske vain nämä luvut niin, että kaikki mahtuu sinne takuun kanssa.

Mitä tapahtuu, jos et sovi? Olen kirjoittanut, että kaikki huuhtelu pysäytetään tehokkaasti, mutta itse asiassa tämä on puhetta. Käyttöjärjestelmässä on iso ongelma - siinä on paljon likaisia ​​sivuja, joten asiakkaasi luoma IO on käytännössä pysäytetty, eli sovellus on tullut lähettämään sql-kyselyn tietokantaan, se odottaa. Kaikki siihen syötetyt/tulosteet ovat alhaisimman prioriteetin, koska tietokanta on tarkastuspisteen varaama. Ja milloin hän lopettaa, on täysin epäselvää. Ja kun olet saavuttanut ei-taustahuuhtelun, se tarkoittaa, että kaikki IO on sen varaama. Ja ennen kuin se loppuu, et tee mitään.

Tässä on kaksi muuta tärkeää seikkaa, jotka eivät kuulu tämän mietinnön soveltamisalaan. Näiden asetusten tulee vastata postgresql.conf-tiedoston asetuksia, eli tarkistuspisteiden asetuksia. Ja levyjärjestelmäsi on oltava asianmukaisesti määritetty. Jos RAIDissa on välimuisti, siinä on oltava akku. Ihmiset ostavat RAIDia hyvällä välimuistilla ilman akkua. Jos sinulla on SSD-levyjä RAIDissa, niiden on oltava palvelinlevyjä, siellä on oltava kondensaattoreita. Tässä on yksityiskohtainen tarkistuslista. Tämä linkki sisältää raportin suorituskyvyn levyn määrittämisestä PostgreSQL:ssä. Siellä on kaikki nämä tarkistuslistat.

Mikä muu voi tehdä elämästä kovin vaikeaa? Nämä ovat kaksi parametria. Ne ovat suhteellisen uusia. Oletuksena ne voidaan sisällyttää eri sovelluksiin. Ja ne voivat tehdä elämästä yhtä vaikeaa, jos ne laitetaan päälle väärin.

On kaksi suhteellisen uutta asiaa. Ne ovat jo ilmestyneet kolmannessa ytimessä. Tämä on sched_migration_cost nanosekunteina ja sched_autogroup_enabled, joka on oletuksena yksi.

Ja kuinka ne pilaavat elämäsi? Mikä on sched_migration_cost? Linuxissa ajoitusohjelma voi siirtää prosessin suorittimesta toiseen. Ja PostgreSQL:lle, joka suorittaa kyselyitä, siirtyminen toiseen suorittimeen on täysin epäselvää. Käyttöjärjestelmän näkökulmasta tämä voi olla hyvä asia, kun vaihdat ikkunoita openofficen ja terminaalin välillä, mutta tietokannan kannalta tämä on erittäin huono asia. Siksi järkevä käytäntö on asettaa migration_cost -arvo johonkin suureen arvoon, vähintään useisiin tuhansiin nanosekunteihin.

Mitä tämä tarkoittaa aikatauluttajalle? Tänä aikana prosessin katsotaan olevan vielä kuuma. Eli jos sinulla on pitkäaikainen tapahtuma, joka on tehnyt jotain pitkään, ajoittaja ymmärtää tämän. Hän olettaa, että ennen kuin tämä aikakatkaisu on kulunut, tätä prosessia ei tarvitse siirtää minnekään. Jos prosessi tekee samalla jotain, niin sitä ei siirretä minnekään, se toimii hiljaa sille varatulla suorittimella. Ja tulos on erinomainen.

Toinen kohta on autogroup. Tietyille työkuormille, jotka eivät liity nykyaikaisiin tietokantoihin, on hyvä idea - tämä on prosessien ryhmittely virtuaalisen päätteen mukaan, josta ne käynnistetään. Tämä on kätevä joihinkin tehtäviin. Käytännössä PostgreSQL on moniprosessijärjestelmä, jossa on esihaarukka, joka toimii yhdestä päätteestä. Sinulla on lukituskirjoitin, tarkistuspiste, ja kaikki asiakaspyyntösi ryhmitellään yhteen ajastimeen prosessoria kohden. Ja he odottavat siellä yhdessä hänen vapautumistaan ​​häiritäkseen toisiaan ja pitääkseen hänet miehitettynä pidempään. Tämä on tarina, joka on täysin tarpeeton tällaisen kuorman tapauksessa ja siksi se on kytkettävä pois päältä.

Kollegani Aleksei Lesovsky teki testejä yksinkertaisella pgbenchillä, jossa hän lisäsi migration_cost'ia suuruusluokkaa ja sammutti autogroupin. Ero huonossa laitteistossa oli lähes 10 %. Postgres-postituslistalla käydään keskustelua, jossa ihmiset antavat tuloksia vastaavista muutoksista kyselyn nopeuteen vaikutti 50 %. Tällaisia ​​tarinoita on aika paljon.

Ja lopuksi virransäästöpolitiikasta. Hyvä asia on, että Linuxia voidaan nyt käyttää kannettavassa tietokoneessa. Ja se varmaan kuluttaa akkua hyvin. Mutta yhtäkkiä käy ilmi, että tämä voi tapahtua myös palvelimella.

Lisäksi, jos vuokraat palvelimia joltakin isännöitsijältä, "hyvät" isännöitsijät eivät välitä siitä, että sinulla on parempi suorituskyky. Heidän tehtävänsä on varmistaa, että heidän raudansa hyödynnetään mahdollisimman tehokkaasti. Siksi ne voivat oletusarvoisesti ottaa käyttöön kannettavan tietokoneen virransäästötilan käyttöjärjestelmässä.

Jos käytät tätä tavaraa palvelimella, jonka tietokanta on raskaan kuormituksen alaisena, valintasi on acpi_cpufreq + permormance. Jopa tilauksesta tulee ongelmia.

Intel_pstate on hieman erilainen ohjain. Ja nyt etusija annetaan tälle, koska se on myöhemmin ja toimii paremmin.

Ja vastaavasti kuvernööri on vain suorituskykyä. Ondemand, powersave ja kaikki muu eivät koske sinua.

PostgreSQL:n selitysanalyysin tulokset voivat poiketa useita suuruusluokkia, jos otat virransäästön käyttöön, koska käytännössä tietokannan alla oleva CPU toimii täysin arvaamattomalla tavalla.

Nämä kohteet voivat olla mukana oletusarvoisesti. Tarkista huolellisesti, ovatko he ottaneet sen käyttöön oletusarvoisesti. Tämä voi olla todella suuri ongelma.

Ja lopuksi halusin kiittää PosgreSQL-Consulting DBA -tiimimme tyyppejä, nimittäin Max Boguk ja Alexey Lesovsky, jotka edistyvät tässä asiassa joka päivä. Ja yritämme tehdä parhaamme asiakkaidemme hyväksi, jotta kaikki toimisi heille. Se on kuin lentoturvallisuusohjeissa. Kaikki täällä on verellä kirjoitettu. Jokainen näistä pähkinöistä löytyy jonkinlaisen ongelman prosessista. Olen iloinen voidessani jakaa ne kanssasi.

Kysymykset:

Kiitos! Jos esimerkiksi yritys haluaa säästää rahaa ja sijoittaa tietokanta- ja sovelluslogiikka yhdelle palvelimelle tai jos yritys seuraa muodikasta mikropalveluarkkitehtuurien trendiä, jossa PostgreSQL toimii säiliössä. Mikä on temppu? Sysctl vaikuttaa koko ytimeen maailmanlaajuisesti. En ole kuullut, että sysctls olisi jotenkin virtualisoitu niin, että ne toimivat erikseen säiliössä. On vain c-ryhmä ja siellä on vain osa ohjauksesta. Kuinka voit elää tämän kanssa? Tai jos haluat suorituskykyä, suorita PostgreSQL erillisellä laitteistopalvelimella ja säädä se?

Vastasimme kysymykseesi noin kolmella tavalla. Jos emme puhu viritettävästä laitteistopalvelimesta jne., rentoudu, kaikki toimii hyvin ilman näitä asetuksia. Jos sinulla on sellainen kuorma, että sinun on tehtävä nämä asetukset, tulet rautapalvelimelle aikaisemmin kuin näihin asetuksiin.

Mikä on ongelma? Jos tämä on virtuaalikone, sinulla on todennäköisesti monia ongelmia, esimerkiksi se, että useimmissa virtuaalikoneissa levyn latenssi on melko epäjohdonmukainen. Vaikka levyn suorituskyky on hyvä, yksi epäonnistunut I/O-tapahtuma, joka ei vaikuta suuresti keskimääräiseen suoritustehoon, joka tapahtui tarkistuspisteen tai WAL-kirjoituksen aikana, tietokanta kärsii tästä suuresti. Ja huomaat tämän ennen kuin törmäät näihin ongelmiin.

Jos sinulla on NGINX samalla palvelimella, sinulla on myös sama ongelma. Hän taistelee yhteisen muistin puolesta. Etkä pääse käsiksi tässä kuvattuihin ongelmiin.

Mutta toisaalta, jotkin näistä parametreista ovat edelleen tärkeitä sinulle. Aseta esimerkiksi dirty_ratio sysctl:llä, jotta se ei ole niin hullua - joka tapauksessa tämä auttaa. Tavalla tai toisella sinulla on vuorovaikutusta levyn kanssa. Ja se tulee olemaan väärän kaavan mukaan. Tämä on yleensä oletusarvo näyttämilleni parametreille. Ja joka tapauksessa on parempi vaihtaa ne.

Mutta NUMA:ssa voi olla ongelmia. Esimerkiksi VmWare toimii hyvin NUMA:n kanssa täsmälleen päinvastaisilla asetuksilla. Ja tässä sinun on valittava - rautainen palvelin tai ei-rauta.

Minulla on Amazon AWS:ään liittyvä kysymys. Niissä on valmiiksi määritettyjä kuvia. Yksi niistä on nimeltään Amazon RDS. Onko heidän käyttöjärjestelmälleen mukautettuja asetuksia?

Siellä on asetuksia, mutta ne ovat erilaisia. Tässä määritämme käyttöjärjestelmän sen mukaan, kuinka tietokanta käyttää tätä asiaa. Ja on olemassa parametreja, jotka määräävät, mihin meidän pitäisi nyt mennä, kuten muotoilu. Eli tarvitsemme niin paljon resursseja, että syömme ne nyt. Tämän jälkeen Amazon RDS kiristää näitä resursseja ja suorituskyky laskee siellä. On olemassa yksittäisiä tarinoita siitä, kuinka ihmiset alkavat sotkea tätä asiaa. Joskus jopa varsin onnistuneesti. Mutta tällä ei ole mitään tekemistä käyttöjärjestelmän asetusten kanssa. Se on kuin pilven hakkerointia. Se on eri tarina.

Miksi läpinäkyvillä suurilla sivuilla ei ole vaikutusta Huge TLB:hen verrattuna?

Älä anna. Tämä voidaan selittää monella tapaa. Mutta itse asiassa he eivät yksinkertaisesti anna sitä. Mikä on PostgreSQL:n historia? Käynnistettäessä se varaa suuren osan jaettua muistia. Se, ovatko ne läpinäkyviä vai eivät, on täysin yhdentekevää. Se, että ne erottuvat heti alussa, selittää kaiken. Ja jos muistia on paljon ja sinun on rakennettava share_memory-segmentti uudelleen, läpinäkyvät valtavat sivut ovat merkityksellisiä. PostgreSQL:ssä se yksinkertaisesti allokoidaan valtavassa osassa alussa ja siinä kaikki, ja sitten siellä ei tapahdu mitään erikoista. Voit tietysti käyttää sitä, mutta on olemassa mahdollisuus, että share_memory vaurioituu, kun se varaa jotain uudelleen. PostgreSQL ei tiedä tästä.

Lähde: will.com