Teollinen lähestymistapa PostgreSQL:n virittämiseen: kokeiluja tietokantojen kanssa. Nikolai Samokhvalov

Suosittelen, että luet tekstin Nikolai Samokhvalovin raportista "Teollinen lähestymistapa PostgreSQL:n viritykseen: tietokantoja koskevat kokeilut"

Shared_buffers = 25 % – onko se paljon vai vähän? Vai ihan oikein? Mistä tiedät, onko tämä - melko vanhentunut - suositus sopiva sinun tapauksessasi?

On aika lähestyä postgresql.conf-parametrien valintaa "kuten aikuinen". Ei sokeiden "autovirittimien" tai vanhentuneiden artikkeleiden ja blogien neuvojen avulla, vaan perustuen:

1. tiukasti varmennetut kokeet tietokannoissa, jotka suoritetaan automaattisesti, suurina määrinä ja olosuhteissa, jotka ovat mahdollisimman lähellä "taistelevia" kokeita,
2. syvällinen ymmärrys DBMS:n ja käyttöjärjestelmän ominaisuuksista.

Nancy CLI (https://gitlab.com/postgres.ai/nancy), tarkastelemme konkreettista esimerkkiä - pahamaineisia jaettuja_puskureita - eri tilanteissa, eri projekteissa ja yritämme selvittää, kuinka valita optimaalinen asetus infrastruktuurillemme, tietokannallemme ja kuormituksellemme.

Puhumme tietokantojen kokeista. Tämä on tarina, joka kestää hieman yli kuusi kuukautta.

Hieman minusta. Kokemus Postgresista yli 14 vuoden ajalta. Useita sosiaalisen verkostoitumisen yrityksiä on perustettu. Postgresia käytettiin ja käytetään kaikkialla.

Myös RuPostgres-ryhmä Meetupissa, 2. sija maailmassa. Lähestymme pikkuhiljaa 2 ihmistä. RuPostgres.org.

Ja eri konferenssien tietokoneilla, mukaan lukien Highload, olen vastuussa tietokannoista, erityisesti Postgresista alusta alkaen.

Ja muutaman viime vuoden aikana olen aloittanut uudelleen Postgres-konsultointikäytäntöni 11 aikavyöhykkeellä täältä.

Ja kun tein tämän muutama vuosi sitten, minulla oli pieni tauko aktiivisessa manuaalisessa työssä Postgresin kanssa, luultavasti vuodesta 2010 lähtien. Olin yllättynyt siitä, kuinka vähän DBA:n työrutiini on muuttunut ja kuinka paljon käsityötä on vielä käytettävä. Ja ajattelin heti, että tässä on jotain vialla, minun täytyy automatisoida enemmän kaikkea.

Ja koska kaikki oli kaukana, suurin osa asiakkaista oli pilvissä. Ja paljon on jo tietysti automatisoitu. Tästä lisää myöhemmin. Eli kaikki tämä johti ajatukseen, että pitäisi olla useita työkaluja, eli jonkinlainen alusta, joka automatisoi melkein kaikki DBA-toiminnot, jotta suuri määrä tietokantoja voidaan hallita.

Tämä raportti ei sisällä:

• "Hopeiset luodit" ja lausunnot, kuten - aseta 8 Gt tai 25% share_buffers ja olet kunnossa. Share_buffersista ei kerrota paljon.
• Kovat "sisäosat".

Ja mitä tapahtuu?

• Sovellamme ja kehitämme optimointiperiaatteita. Matkan varrella syntyy kaikenlaisia ​​ideoita ja erilaisia ​​työkaluja, joita luomme suurimmaksi osaksi Open Sourcessa, eli teemme pohjan Open Sourcessa. Lisäksi meillä on lippuja, kaikki viestintä on käytännössä avointa lähdekoodia. Näet mitä teemme nyt, mitä tulee olemaan seuraavassa julkaisussa jne.
• Näiden periaatteiden, työkalujen käytöstä tulee myös jonkin verran kokemusta useissa yrityksissä: pienistä startupeista suuriin yrityksiin.

Miten tämä kaikki kehittyy?

Ensinnäkin DBA:n päätehtävänä, instanssien luomisen, varmuuskopioiden käyttöönoton jne. varmistamisen lisäksi, on löytää pullonkaulat ja optimoida suorituskyky.

Nyt se on asetettu näin. Katsomme seurantaa, näemme jotain, mutta meiltä puuttuu joitain yksityiskohtia. Alamme kaivaa huolellisemmin, yleensä käsillämme, ja ymmärrämme, mitä tehdä sillä tavalla tai toisella.

Ja on olemassa kaksi lähestymistapaa. Pg_stat_statements on oletusratkaisu hitaiden kyselyjen tunnistamiseen. Ja Postgres-lokien analyysi pgBadgerilla.

Jokaisella lähestymistavalla on vakavia haittoja. Ensimmäisessä lähestymistavassa olemme heittäneet pois kaikki parametrit. Ja jos näemme ryhmät SELECT * FROM, jossa sarake on yhtä suuri kuin "?" tai "$" Postgres 10:n jälkeen. Emme tiedä, onko tämä indeksiskannaus vai sekvenssiskannaus. Se riippuu paljon parametrista. Jos korvaat siellä harvoin esiintyvän arvon, kyseessä on indeksiskannaus. Jos korvaat arvon, joka kattaa 90 % taulukosta, seq-skannaus on ilmeinen, koska Postgres tietää tilastot. Ja tämä on pg_stat_statementsin suuri haitta, vaikka työ on kesken.

Lokianalyysin suurin haitta on, että sinulla ei ole yleensä varaa "log_min_duration_statement = 0". Ja puhumme myös tästä. Näin ollen et näe koko kuvaa. Ja jotkut kyselyt, jotka ovat erittäin nopeat, voivat kuluttaa valtavasti resursseja, mutta et näe sitä, koska se on kynnyksesi alapuolella.

Miten DBA:t ratkaisevat löytämänsä ongelmat?

Löysimme esimerkiksi jonkin ongelman. Mitä yleensä tehdään? Jos olet kehittäjä, teet jotain jossain tapauksessa, joka ei ole samankokoinen. Jos olet DBA, sinulla on lavastus. Ja niitä voi olla vain yksi. Ja hän oli kuusi kuukautta jäljessä. Ja luulet siirtyväsi tuotantoon. Ja jopa kokeneet DBA:t kirjautuvat tuotantoon replikalla. Ja tapahtuu, että he luovat väliaikaisen indeksin, varmistavat, että se auttaa, pudottavat sen ja antavat sen kehittäjille, jotta he voivat laittaa sen siirtotiedostoihin. Sellaista hölynpölyä nyt tapahtuu. Ja tämä on ongelma.

• Viritä kokoonpanot.
• Optimoi indeksijoukko.
• Muuta itse SQL-kyselyä (tämä on vaikein tapa).
• Lisää kapasiteettia (helpein tapa useimmissa tapauksissa).

Näiden asioiden kanssa tapahtuu paljon. Postgresissa on paljon kahvoja. Tiedossa on paljon. Postgresissa on monia indeksejä, kiitos myös tämän konferenssin järjestäjille. Ja kaikki tämä on tiedettävä, ja tämä saa ei-DBA:t tuntemaan, että DBA:t harjoittavat mustaa magiaa. Eli sinun täytyy opiskella 10 vuotta, jotta alat ymmärtää kaiken tämän normaalisti.

Ja minä taistelen tätä mustaa magiaa vastaan. Haluan tehdä kaiken niin, että on teknologiaa, eikä tässä kaikessa ole intuitiota.

Esimerkkejä elämästä

Huomasin tämän ainakin kahdessa projektissa, mukaan lukien omassani. Toinen blogikirjoitus kertoo meille, että default_statistict_target-arvon 1 000 on hyvä. Okei, kokeillaan tuota tuotannossa.

Ja tässä olemme, käyttämällä työkaluamme kaksi vuotta myöhemmin, kokeilujen avulla tietokannoista, joista puhumme tänään, voimme verrata mitä oli ja mitä on tullut.

Ja tätä varten meidän on luotava kokeilu. Se koostuu neljästä osasta.

• Ensimmäinen on ympäristö. Tarvitsemme laitteiston. Ja kun tulen johonkin yritykseen ja allekirjoitan sopimuksen, sanon heille, että minulle annetaan samat laitteet kuin tuotannossa. Tarvitsen jokaista mestariasi varten vähintään yhden tällaisen laitteiston. Joko tämä on Amazonin tai Googlen esiintymän virtuaalikone, tai tarvitsen täsmälleen saman laitteiston. Eli haluan luoda ympäristön uudelleen. Ja ympäristön käsitteeseen sisällytämme Postgresin pääversion.
• Toinen osa on tutkimuksemme kohde. Tämä on tietokanta. Se voidaan luoda useilla tavoilla. Näytän sinulle kuinka.
• Kolmas osa on kuorma. Tämä on vaikein hetki.
• Ja neljäs osa on se, mitä tarkistamme, eli mitä verrataan mihin. Oletetaan, että voimme muuttaa yhtä tai useampaa parametria konfiguraatiossa, tai voimme luoda indeksin jne.

Aloitamme kokeilun. Tässä on pg_stat_statements. Vasemmalla on mitä tapahtui. Oikealla - mitä tapahtui.

Vasemmalla default_statistics_target = 100, oikealla = 1 000. Näemme, että tämä auttoi meitä. Kaiken kaikkiaan kaikki parani 8 %.

Mutta jos vieritämme alaspäin, pgBadgerista tai pg_stat_statementsista tulee pyyntöryhmiä. Vaihtoehtoja on kaksi. Näemme, että jotkut pyynnöt ovat pudonneet 88 prosenttia. Ja tässä tulee tekninen lähestymistapa. Voimme kaivaa syvemmälle sisälle, koska ihmettelemme miksi se upposi. Sinun on ymmärrettävä, mitä tilastoille tapahtui. Miksi useammat ämpärit tilastoissa johtavat huonompiin tuloksiin?

Tai emme voi kaivaa, vaan tee "ALTER TABLE ... ALTER COLUMN" ja palauta 100 ämpäriä takaisin tämän sarakkeen tilastoihin. Ja sitten toisella kokeella voimme varmistaa, että tämä korjaustiedosto auttoi. Kaikki. Tämä on tekninen lähestymistapa, joka auttaa meitä näkemään kokonaisuuden ja tekemään päätöksiä datan eikä intuition perusteella.

Pari esimerkkiä muilta alueilta. CI-testejä on testattu useiden vuosien ajan. Eikä yksikään järkevä projekti eläisi ilman automaattisia testejä.

Muilla toimialoilla: ilmailussa, autoteollisuudessa, kun testaamme aerodynamiikkaa, meillä on myös mahdollisuus tehdä kokeita. Emme laukaise mitään piirroksesta suoraan avaruuteen tai emme vie jotain autoa heti radalle. Siellä on esimerkiksi tuulitunneli.

Voimme tehdä johtopäätöksiä muiden toimialojen havainnoista.

Ensinnäkin meillä on erityinen ympäristö. Se on lähellä tuotantoa, mutta ei lähellä. Sen pääominaisuus on, että sen tulee olla halpa, toistettava ja mahdollisimman automatisoitu. Lisäksi on oltava erityisiä työkaluja yksityiskohtaisen analyysin suorittamiseen.

Todennäköisimmin meillä on lentokoneen laukaisussa ja lentäessämme vähemmän mahdollisuuksia tutkia jokaista siiven pinnan millimetriä kuin tuulitunnelissa. Meillä on enemmän diagnostiikkatyökaluja. Meillä on varaa kuljettaa raskaampaa tavaraa, jota meillä ei ole varaa laittaa lentokoneeseen ilmaan. Sama Postgresin kanssa. Saatamme joissakin tapauksissa ottaa käyttöön täyden kyselylokin kokeiden aikana. Emmekä halua tehdä tätä tuotannossa. Saatamme jopa suunnitella ottavamme tämän käyttöön käyttämällä auto_explain-toimintoa.

Ja kuten sanoin, korkea automaatio tarkoittaa, että painamme painiketta ja toistamme. Näin sen pitäisi olla, jotta on paljon kokeilua, jotta se on virrassa.

Nancy CLI - "tietokantalaboratorion" perusta

Ja niin teimme tämän asian. Eli puhuin näistä ideoista kesäkuussa, melkein vuosi sitten. Ja meillä on jo niin kutsuttu Nancy CLI avoimessa lähdekoodissa. Tämä on perusta tietokantalaboratorion rakentamiselle.

Nancy - Se on avoimessa lähdekoodissa, Gitlabissa. Voit sanoa sen, voit kokeilla sitä. Annoin linkin dioihin. Voit klikata sitä ja se on siellä auttaa kaikella kunnioituksella.

Tietysti paljon on vielä kehitteillä. Siellä on paljon ideoita. Mutta tämä on jotain, jota käytämme melkein joka päivä. Ja kun meillä on idea - miksi on niin, että kun poistamme 40 000 000 riviä, kaikki jää IO:ksi, sitten voimme suorittaa kokeen ja tarkastella yksityiskohtaisemmin ymmärtääksemme, mitä tapahtuu, ja sitten yrittää korjata sen lennossa. Eli teemme kokeilun. Esimerkiksi säädämme jotain ja katsomme mitä lopulta tapahtuu. Emmekä tee tätä tuotannossa. Tämä on idean ydin.

Missä tämä voi toimia? Tämä voi toimia paikallisesti, eli voit tehdä sen missä tahansa, voit jopa käyttää sitä MacBookissa. Tarvitsemme telakan, mennään. Siinä kaikki. Voit suorittaa sen jossain tapauksessa laitteistossa tai virtuaalikoneessa missä tahansa.

Ja Amazonissa on myös mahdollisuus ajaa etänä EC2-instanssissa, pisteissä. Ja tämä on erittäin hieno mahdollisuus. Esimerkiksi eilen teimme yli 500 koetta i3-instanssilla, alkaen nuorimmasta ja päättyen i3-16-xlargeen. Ja 500 koetta maksoi meille 64 dollaria. Jokainen kesti 15 minuuttia. Eli koska spotteja käytetään siellä, se on erittäin halpaa - 70% alennus, Amazonin sekuntilaskutus. Voit tehdä paljon. Voit tehdä todellista tutkimusta.

Ja kolmea pääversiota Postgresista tuetaan. Ei ole niin vaikeaa viimeistellä joitain vanhoja ja myös uutta 12. versiota.

Voimme määritellä kohteen kolmella tavalla. Tämä:

• Dump/sql tiedosto.
• Pääasiallinen tapa on kloonata PGDATA-hakemisto. Yleensä se otetaan varmuuskopiopalvelimelta. Jos sinulla on normaalit binäärivarmuuskopiot, voit tehdä klooneja sieltä. Jos sinulla on pilviä, pilvitoimisto, kuten Amazon ja Google, tekevät tämän puolestasi. Tämä on tärkein tapa kloonata todellinen tuotanto. Näin me avaudumme.
• Ja viimeinen menetelmä sopii tutkimukseen, kun haluat ymmärtää, miten jokin toimii Postgresissa. Tämä on pgbench. Voit luoda käyttämällä pgbench. Se on vain yksi "db-pgbench" -vaihtoehto. Kerrot hänelle, mikä mittakaava. Ja kaikki luodaan pilvessä, kuten todettiin.

Ja lataa:

• Voimme suorittaa latauksen yhdessä SQL-säikeessä. Tämä on alkeellisin tapa.
• Ja voimme jäljitellä kuormaa. Ja voimme jäljitellä sitä ensinnäkin seuraavalla tavalla. Meidän on kerättävä kaikki lokit. Ja se on kipeä. Näytän sinulle miksi. Ja käytämme pgreplayä, joka on sisäänrakennettu Nancyyn.
• Tai toinen vaihtoehto. Niin sanottu käsityökuorma, jonka teemme tietyllä vaivalla. Analysoimme nykyistä taistelujärjestelmäämme kohdistuvaa kuormitusta, vedämme esiin tärkeimmät pyyntöryhmät. Ja pgbenchin avulla voimme jäljitellä tätä kuormaa laboratoriossa.

• Joko meidän on suoritettava jonkinlainen SQL, eli tarkistetaan jonkinlainen migraatio, luodaan sinne indeksi, suoritetaan siellä ANALAZE. Ja katsomme mitä tapahtui ennen tyhjiötä ja tyhjiön jälkeen. Yleensä mikä tahansa SQL.
• Joko muutamme yhtä tai useampaa parametria konfiguraatiossa. Voimme pyytää meitä tarkistamaan esimerkiksi 100 arvoa Amazonista teratavutietokantaamme varten. Ja muutaman tunnin kuluttua saat tuloksen. Yleensä teratavuisen tietokannan käyttöönotto kestää useita tunteja. Mutta korjaustiedosto on kehitteillä, meillä on sarja mahdollista, eli voit jatkuvasti käyttää samaa pgdataa samalla palvelimella ja tarkistaa. Postgres käynnistyy uudelleen ja välimuistit nollataan. Ja voit ajaa kuormaa.

• Hakemisto saapuu, jossa on joukko erilaisia ​​tiedostoja, alkaen pg-snapshotistastat***. Ja mielenkiintoisin asia on pg_stat_statements, pg_stat_kcacke. Nämä ovat kaksi laajennusta, jotka analysoivat pyyntöjä. Ja pg_stat_bgwriter ei sisällä vain pgwriter-tilastoja, vaan myös tarkistuspisteitä ja sitä, kuinka taustaohjelmat itse syrjäyttävät likaisia ​​puskureita. Ja kaikki on mielenkiintoista nähdä. Kun esimerkiksi määritämme share_buffers -puskurit, on erittäin mielenkiintoista nähdä, kuinka paljon kaikki korvasivat.
• Myös Postgres-lokit saapuvat. Kaksi lokia – valmisteluloki ja latausloki.
• Suhteellisen uusi ominaisuus on FlameGraphs.
• Lisäksi, jos käytit pgreplay- tai pgbench-asetuksia kuorman toistamiseen, niiden tulos on natiivi. Ja näet latenssin ja TPS:n. On mahdollista ymmärtää, kuinka he näkivät sen.
• Järjestelmätiedot.
• Perussuorittimen ja IO:n tarkistukset. Tämä on enemmän Amazonin EC2-esiintymää varten, kun haluat käynnistää 100 identtistä esiintymää säikeessä ja suorittaa siellä 100 erilaista ajoa, sinulla on 10 000 kokeilua. Ja sinun on varmistettava, että et törmää vialliseen tapaukseen, jota joku jo sortaa. Muut ovat aktiivisia tällä laitteistolla, ja sinulla on vähän resursseja jäljellä. On parempi hylätä tällaiset tulokset. Ja Alexey Kopytovin sysbenchin avulla teemme useita lyhyitä tarkistuksia, jotka tulevat ja joita voidaan verrata muihin, eli ymmärrät kuinka CPU käyttäytyy ja miten IO käyttäytyy.

Mitkä ovat tekniset vaikeudet eri yritysten esimerkin perusteella?

Oletetaan, että haluamme toistaa todellisen kuormituksen lokien avulla. On hieno idea, jos se on kirjoitettu avoimen lähdekoodin pgreplayllä. Käytämme sitä. Mutta jotta se toimisi hyvin, sinun on otettava käyttöön täydellinen kyselyloki parametreilla ja ajoituksella.

Kestoon ja aikaleimaan liittyy joitain ongelmia. Tyhjennämme koko keittiön. Pääkysymys on, onko sinulla siihen varaa vai ei?

https://gist.github.com/NikolayS/08d9b7b4845371d03e195a8d8df43408

Ongelmana on, että se ei ehkä ole saatavilla. Ensinnäkin sinun on ymmärrettävä, mikä virta kirjoitetaan lokiin. Jos sinulla on pg_stat_statements, voit käyttää tätä kyselyä (linkki on saatavilla dioissa) ymmärtääksesi, kuinka monta tavua kirjoitetaan suunnilleen sekunnissa.

Tarkastelemme pyynnön pituutta. Unohdamme sen tosiasian, että parametreja ei ole, mutta tiedämme pyynnön pituuden ja tiedämme kuinka monta kertaa sekunnissa se suoritettiin. Tällä tavalla voimme arvioida suunnilleen kuinka monta tavua sekunnissa. Saatamme tehdä virheen kaksi kertaa niin paljon, mutta ymmärrämme varmasti järjestyksen tällä tavalla.

Voimme nähdä, että tämä pyyntö suoritetaan 802 kertaa sekunnissa. Ja näemme, että bytes_per sec – 300 kB/s kirjoitetaan plus tai miinus. Ja yleensä meillä on varaa sellaiseen virtaukseen.

Mutta! Tosiasia on, että on olemassa erilaisia ​​kirjausjärjestelmiä. Ja ihmisten oletusarvo on yleensä "syslog".

Ja jos sinulla on syslog, sinulla voi olla tällainen kuva. Otetaan pgbench, otetaan kyselyloki käyttöön ja katsotaan mitä tapahtuu.

Ilman kirjaamista - tämä on sarake vasemmalla. Saimme 161 000 TPS. Syslogilla - tämä on Ubuntu 16.04:ssä Amazonissa, saamme 37 000 TPS:ää. Ja jos vaihdamme kahteen muuhun kirjausmenetelmään, tilanne on paljon parempi. Eli odotimme sen laskevan, mutta ei samassa määrin.

Ja CentOS 7:ssä, jossa myös journald osallistuu, muuttaen lokit binäärimuotoon helpottamaan hakua jne., silloin se on painajainen, pudotamme TPS:ssä 44 kertaa.

Ja tämän kanssa ihmiset elävät. Ja usein yrityksissä, varsinkin suurissa, tätä on erittäin vaikea muuttaa. Jos pääset eroon syslogista, ole hyvä ja eroa siitä.

• Arvioi IOPS ja kirjoituskulku.
• Tarkista lokijärjestelmäsi.
• Jos ennakoitu kuorma on liian suuri, harkitse näytteenottoa.

Meillä on pg_stat_statements. Kuten sanoin, sen täytyy olla siellä. Ja voimme ottaa ja kuvata jokaisen pyyntöryhmän erityisellä tavalla tiedostossa. Ja sitten voimme käyttää erittäin kätevää ominaisuutta pgbenchissä - tämä on kyky lisätä useita tiedostoja "-f" -vaihtoehdolla.

Se ymmärtää paljon "-f". Ja voit kertoa lopussa olevan @-merkin avulla, mikä osuus kullakin tiedostolla tulee olla. Eli voimme sanoa, että tee tämä 10 prosentissa tapauksista ja tämä 20 prosentissa tapauksista. Ja tämä tuo meidät lähemmäksi sitä, mitä näemme tuotannossa.

Miten ymmärrämme, mitä meillä on tuotannossa? Mikä osuus ja miten? Tämä on vähän sivuseikka. Meillä on vielä yksi tuote jälkitarkastus. Myös avoimen lähdekoodin tukikohta. Ja kehitämme sitä nyt aktiivisesti.

Hän syntyi hieman eri syistä. Syistä, että valvonta ei riitä. Eli tulet katsomaan tukikohtaa, katsomaan olemassa olevia ongelmia. Ja yleensä teet terveystarkastuksen. Jos olet kokenut DBA, teet health_checkin. Tarkastelimme indeksien käyttöä jne. Jos sinulla on OKmeter, niin hienoa. Tämä on siistiä seurantaa Postgresille. OKmeter.io – asenna se, siellä kaikki on tehty erittäin hyvin. Se on maksettu.

Jos sinulla ei ole sitä, sinulla ei yleensä ole paljon. Valvonnassa on yleensä CPU, IO ja sitten varauksin, ja siinä kaikki. Ja me tarvitsemme lisää. Meidän on nähtävä kuinka autotyhjiö toimii, kuinka tarkistuspiste toimii, io:ssa meidän on erotettava tarkistuspiste bgwriteristä ja taustaohjelmista jne.

Ongelmana on, että kun autat suurta yritystä, se ei pysty toteuttamaan jotain nopeasti. He eivät voi nopeasti ostaa OKmeteriä. Ehkä he ostavat sen kuuden kuukauden kuluttua. He eivät voi toimittaa nopeasti joitakin paketteja.

Ja keksimme, että tarvitsemme erikoistyökalun, joka ei vaadi mitään asentamista, eli tuotantoon ei tarvitse asentaa juuri mitään. Asenna se kannettavaan tietokoneeseen tai havainnointipalvelimeen, josta käytät sitä. Ja se analysoi monia asioita: käyttöjärjestelmän, tiedostojärjestelmän ja itse Postgresin tehden joitain kevyitä kyselyitä, jotka voidaan suorittaa suoraan tuotantoon, eikä mikään epäonnistu.

Kutsuimme sitä Postgres-checkupiksi. Lääketieteellisesti tämä on säännöllinen terveystarkastus. Jos se on autoteemaa, se on kuin huoltoa. Huollat ​​autoasi kuuden kuukauden tai vuoden välein merkistä riippuen. Huollatko tukikohtaasi? Eli teetkö syvällistä tutkimusta säännöllisesti? Se on tehtävä. Jos teet varmuuskopioita, tee sitten tarkistus, tämä ei ole vähemmän tärkeä.

Ja meillä on sellainen työkalu. Se alkoi esiintyä aktiivisesti vasta noin kolme kuukautta sitten. Hän on vielä nuori, mutta siellä on paljon.

"vaikuttavimpien" kyselyryhmien kerääminen - raportti K003 Postgres-checkupissa

Ja siellä on joukko raportteja K. Kolme raporttia tähän mennessä. Ja on sellainen raportti K003. Siellä on alkuun pg_stat_statements, lajiteltuna kokonaisajan mukaan.

Kun lajittelemme pyyntöryhmät total_time-perusteen mukaan, yläreunassa näkyy ryhmä, joka kuormittaa järjestelmäämme eniten, eli kuluttaa enemmän resursseja. Miksi nimeän kyselyryhmiä? Koska jätimme parametrit pois. Nämä eivät ole enää pyyntöjä, vaan pyyntöryhmiä, eli ne ovat abstrakteja.

Ja jos optimoimme ylhäältä alas, kevennämme resurssejamme ja viivästämme hetkeä, jolloin meidän on päivitettävä. Tämä on erittäin hyvä tapa säästää rahaa.

Ehkä tämä ei ole kovin hyvä tapa huolehtia käyttäjistä, koska emme ehkä näe harvinaisia, mutta erittäin ärsyttäviä tapauksia, joissa henkilö odotti 15 sekuntia. Kaiken kaikkiaan ne ovat niin harvinaisia, että emme näe niitä, mutta olemme tekemisissä resurssien kanssa.

Mitä tässä taulukossa tapahtui? Otimme kaksi tilannekuvaa. Postgres_checkup antaa sinulle delta-arvon jokaiselle mittarille: kokonaisaika, puhelut, rivit, share_blks_read jne. Siinä kaikki, delta on laskettu. Suuri ongelma pg_stat_statementsin kanssa on, että se ei muista milloin se nollattiin. Jos pg_stat_database muistaa, pg_stat_statements ei muista. Näet, että lukuja on 1 000 000, mutta emme tiedä, mistä olemme laskeneet.

Ja tässä me tiedämme, tässä meillä on kaksi tilannekuvaa. Tiedämme, että delta tässä tapauksessa oli 56 sekuntia. Hyvin lyhyt väli. Lajiteltu kokonaisajan mukaan. Ja sitten voimme erottaa, eli jaamme kaikki mittarit kestolla. Jos jaamme jokaisen mittarin kestolla, saamme puheluiden määrän sekunnissa.

Seuraavaksi kokonaisaika sekunnissa on suosikkini. Se mitataan sekunneissa, sekunnissa, eli kuinka monta sekuntia järjestelmältämme kului tämän pyyntöryhmän suorittamiseen sekunnissa. Jos näet siellä enemmän kuin sekunnin sekunnissa, se tarkoittaa, että sinun oli annettava enemmän kuin yksi ydin. Tämä on erittäin hyvä mittari. Voit ymmärtää, että esimerkiksi tämä ystävä tarvitsee vähintään kolme ydintä.

Tämä on meidän osaamistamme, en ole koskaan nähnyt vastaavaa missään. Huomaa - tämä on hyvin yksinkertainen asia - sekunti sekunnissa. Joskus, kun suorittimesi on 100%, niin puoli tuntia sekunnissa, eli vietit puoli tuntia juuri näiden pyyntöjen tekemiseen.

Seuraavaksi näemme rivejä sekunnissa. Tiedämme kuinka monta riviä sekunnissa se palasi.

Ja sitten on myös mielenkiintoinen asia. Kuinka monta jaettua_puskuria luemme sekunnissa itse share_buffereista. Osumat olivat jo siellä, ja otimme rivit käyttöjärjestelmän välimuistista tai levyltä. Ensimmäinen vaihtoehto on nopea, ja toinen voi olla nopea tai ei, tilanteesta riippuen.

Ja toinen tapa erottaa toisistaan ​​on jakaa pyyntöjen määrä tässä ryhmässä. Toisessa sarakkeessa on aina yksi kysely jaettuna kyselyä kohti. Ja sitten on mielenkiintoista - kuinka monta millisekuntia tässä pyynnössä oli. Tiedämme, miten tämä kysely toimii keskimäärin. Kuhunkin pyyntöön vaadittiin 101 millisekuntia. Tämä on perinteinen mittari, joka meidän on ymmärrettävä.

Kuinka monta riviä kukin kysely palautti keskimäärin? Näemme 8 tämän ryhmän palaavan. Kuinka paljon keskimäärin otettiin välimuistista ja luettiin. Näemme, että kaikki on välimuistissa hienosti. Vahvat osumat ensimmäiselle ryhmälle.

Ja neljäs osamerkkijono jokaisella rivillä on kuinka monta prosenttia kokonaismäärästä. Meillä on puheluita. Sanotaan 1 000 000. Ja voimme ymmärtää, minkä panoksen tämä ryhmä antaa. Näemme, että tässä tapauksessa ensimmäisen ryhmän osuus on alle 0,01 %. Eli se on niin hidas, että emme näe sitä kokonaiskuvassa. Ja toinen ryhmä on 5% puheluista. Toisin sanoen 5 % kaikista puheluista on toinen ryhmä.

Total_time on myös mielenkiintoinen. Käytimme 14 % kokonaistyöajastamme ensimmäiseen pyyntöryhmään. Ja toiselle - 11% jne.

En mene yksityiskohtiin, mutta siinä on hienouksia. Näytämme virheen yläreunassa, koska vertailussa tilannekuvat voivat kellua, toisin sanoen jotkut pyynnöt voivat pudota pois, eivätkä ne voi enää olla toisessa, kun taas jotkut voivat ilmaantua uusia. Ja siellä lasketaan virhe. Jos näet 0, se on hyvä. Virheitä ei ole. Jos virheprosentti on jopa 20 %, se on OK.

Sitten palataan aiheeseemme. Meidän on määritettävä työmäärä. Otamme sen ylhäältä alas ja menemme, kunnes saavutamme 80% tai 90%. Yleensä tämä on 10-20 ryhmää. Ja teemme tiedostoja pgbenchille. Käytämme siellä satunnaista. Joskus tämä ei valitettavasti onnistu. Ja Postgres 12:ssa on enemmän mahdollisuuksia käyttää tätä lähestymistapaa.

Ja sitten saamme 80-90% kokonaisajasta tällä tavalla. Mitä laitan seuraavaksi @-merkin jälkeen? Katsomme puheluita, näemme, kuinka paljon kiinnostusta on, ja ymmärrämme, että olemme täällä niin paljon koron velkaa. Näistä prosenttiosuuksista voimme ymmärtää, kuinka jokainen tiedosto tasapainotetaan. Sen jälkeen käytämme pgbenchiä ja lähdemme töihin.

Meillä on myös K001 ja K002.

K001 on yksi iso merkkijono, jossa on neljä osamerkkijonoa. Tämä on ominaisuus koko kuormituksellemme. Katso toinen sarake ja toinen alarivi. Näemme, että noin puolitoista sekuntia sekunnissa, eli jos on kaksi ydintä, se on hyvä. Kapasiteettia tulee olemaan noin 75 %. Ja se tulee toimimaan näin. Jos meillä on 10 ydintä, olemme yleensä rauhallisia. Näin voimme arvioida resursseja.

K002 on se, mitä kutsun kyselyluokiksi, eli SELECT, INSERT, UPDATE, DELETE. Ja erikseen SELECT FOR UPDATE, koska se on lukko.

Ja tästä voimme päätellä, että SELECT on tavallisia lukijoita - 82% kaikista puheluista, mutta samalla - 74% kokonaisajasta. Eli niitä kutsutaan paljon, mutta ne kuluttavat vähemmän resursseja.

Ja palaamme kysymykseen: "Kuinka voimme valita oikeat jaetut puskurit?" Huomaan, että useimmat benchmarkit perustuvat ajatukseen - katsotaan mikä on läpimenokyky, eli mikä on läpimenokyky. Se mitataan yleensä TPS:nä tai QPS:nä.

Ja yritämme puristaa autosta mahdollisimman monta tapahtumaa sekunnissa viritysparametreilla. Tässä on tarkalleen 311 sekunnissa valituille.

Mutta kukaan ei aja töihin ja kotiin täydellä vauhdilla. Tämä on typerää. Sama tietokantojen kanssa. Meidän ei tarvitse ajaa täydellä nopeudella, eikä kenenkään tarvitse. Kukaan ei asu tuotannossa, jossa on 100 % CPU. Vaikka ehkä joku elää, mutta tämä ei ole hyvä.

Ajatuksena on, että ajetaan yleensä 20 prosentilla kapasiteetista, mieluiten enintään 50 prosentilla. Ja yritämme ennen kaikkea optimoida käyttäjiemme vasteajan. Toisin sanoen meidän on käännettävä nuppejamme niin, että 20 %:n nopeudella on vähimmäisviive, ehdollisesti. Tämä on idea, jota yritämme myös käyttää kokeiluissamme.

Ja lopuksi suositukset:

• Muista tehdä Database Lab.
• Jos mahdollista, tee se pyynnöstä, jotta se avautuu hetkeksi - pelaa ja heitä se pois. Jos sinulla on pilviä, tämä on sanomattakin selvää, eli sinulla on paljon seisomista.
• Olla utelias. Ja jos jokin on vialla, tarkista kokein, miten se käyttäytyy. Nancyn avulla voit kouluttaa itsesi tarkistamaan, kuinka tukikohta toimii.
• Ja pyri mahdollisimman lyhyeen vasteaikaan.
• Ja älä pelkää Postgres-lähteitä. Kun työskentelet lähteiden kanssa, sinun tulee osata englantia. Siellä on paljon kommentteja, siellä on kaikki selitetty.
• Ja tarkista tietokannan kunto säännöllisesti, vähintään kerran kolmessa kuukaudessa, manuaalisesti tai Postgres-tarkastuksella.

kysymykset

Kiitos paljon! Erittäin mielenkiintoinen asia.

Kaksi palaa.

Kyllä, kaksi kappaletta. En vain ymmärtänyt. Kun Nancy ja minä työskentelemme, voimmeko säätää vain yhtä parametria vai kokonaista ryhmää?

Meillä on delta config -parametri. Voit kääntyä siellä niin paljon kuin haluat kerralla. Mutta sinun on ymmärrettävä, että kun muutat monia asioita, voit tehdä vääriä johtopäätöksiä.

Joo. Miksi kysyin? Koska on vaikea suorittaa kokeita, kun sinulla on vain yksi parametri. Kiristä se, katso kuinka se toimii. Laitoin hänet ulos. Sitten aloitat seuraavan.

Voit kiristää sitä samalla, mutta se riippuu tietysti tilanteesta. Mutta on parempi testata yhtä ideaa. Meillä oli eilen idea. Meillä oli hyvin läheinen tilanne. Konfiguja oli kaksi. Emmekä voineet ymmärtää, miksi ero oli suuri. Ja syntyi ajatus, että sinun on käytettävä dikotomiaa ymmärtääksesi johdonmukaisesti ja löytääksesi eron. Voit tehdä heti puolet parametreista samoina, sitten neljänneksen jne. Kaikki on joustavaa.

Ja on vielä yksi kysymys. Projekti on nuori ja kehittyvä. Dokumentaatio on jo valmis, onko tarkempaa kuvausta?

Laitoin sinne nimenomaan linkin parametrien kuvaukseen. Se on siellä. Mutta monet asiat eivät ole vielä siellä. Etsin samanhenkisiä ihmisiä. Ja löydän ne esiintyessäni. Tämä on erittäin siistiä. Joku työskentelee jo kanssani, joku auttoi ja teki jotain siellä. Ja jos olet kiinnostunut tästä aiheesta, anna palautetta siitä, mitä puuttuu.

Kun rakennamme laboratorion, ehkä palautetta tulee. Katsotaan. Kiitos!

Hei! Kiitos raportista! Huomasin, että siellä on Amazon-tuki. Onko suunnitelmia tukea GSP:tä?

Hyvä kysymys. Aloimme tehdä sitä. Ja jäädytimme sen toistaiseksi, koska haluamme säästää rahaa. Eli run on localhost tukee käyttöä. Voit luoda ilmentymän itse ja työskennellä paikallisesti. Sitä me muuten teemme. Teen tämän Getlabissa, siellä GSP:ssä. Mutta emme näe vielä järkeä tehdä vain tällaista orkestrointia, koska Googlella ei ole halpoja paikkoja. On ??? tapauksia, mutta niillä on rajoituksia. Ensinnäkin heillä on aina vain 70% alennus, etkä voi leikkiä hinnalla siellä. Spoteissa nostamme hintaa 5-10 % vähentääksemme potkimisen todennäköisyyttä. Eli säästät paikkoja, mutta ne voidaan ottaa sinulta pois milloin tahansa. Jos tarjoat hieman korkeamman tarjouksen kuin muut, sinut tapetaan myöhemmin. Googlella on täysin erilaiset tiedot. Ja on toinen erittäin huono rajoitus - he elävät vain 24 tuntia. Ja joskus haluamme suorittaa kokeen 5 päivän ajan. Mutta voit tehdä tämän täplillä; täplät kestävät joskus kuukausia.

Hei! Kiitos raportista! Mainitsit tarkastuksen. Kuinka lasket stat_statements-virheet?

Erittäin hyvä kysymys. Voin näyttää ja kertoa sinulle erittäin yksityiskohtaisesti. Lyhyesti sanottuna tarkastellaan, kuinka pyyntöryhmien joukko on kellunut: kuinka monta on pudonnut ja kuinka monta uutta on ilmaantunut. Ja sitten tarkastelemme kahta mittaria: kokonaisaika ja puhelut, joten virheitä on kaksi. Ja katsomme kelluvien ryhmien panosta. Alaryhmiä on kaksi: lähteneet ja saapuneet. Katsotaanpa, mikä on heidän panoksensa kokonaiskuvaan.

Etkö pelkää, että se kääntyy siellä kaksi tai kolme kertaa tilannekuvien välisenä aikana?

Eli rekisteröityivätkö he uudelleen vai mitä?

Esimerkiksi tämä pyyntö on jo ennakolta ennakolta kerran, sitten se tuli ja ennakoitettiin uudelleen, sitten se tuli uudelleen ja ennakolta taas. Ja lasket tässä jotain, ja missä se kaikki on?

Hyvä kysymys, täytyy katsoa.

Tein samanlaisen asian. Se oli tietysti yksinkertaisempaa, tein sen yksin. Mutta minun täytyi nollata, nollata stat_statements ja selvittää tilannekuvan aikana, että siellä oli vähemmän kuin tietty murto-osa, joka ei silti saavuttanut kattoa, kuinka paljon stat_statements voisi kertyä sinne. Ja ymmärrykseni on, että mitä todennäköisimmin ei ole siirretty.

Kyllä kyllä.

Mutta en ymmärrä miten se muuten tehdään luotettavasti.

Valitettavasti en muista tarkalleen, käytämmekö siellä kyselytekstiä vai queryid:tä pg_stat_statementsin kanssa ja keskitymmekö siihen. Jos keskitymme queryidiin, niin teoriassa vertaamme vertailukelpoisia asioita.

Ei, hänet voidaan pakottaa ulos useita kertoja tilannekuvien välillä ja tulla uudestaan.

Samalla tunnuksella?

Kyllä.

Tutkimme tätä. Hyvä kysymys. Meidän täytyy tutkia sitä. Mutta toistaiseksi se, mitä näemme, on joko kirjoitettu 0...

Tämä on tietysti harvinainen tapaus, mutta olin järkyttynyt, kun huomasin, että stat_statemetns voi siirtyä sinne.

Pg_stat_statementsissa voi olla monia asioita. Huomasimme, että jos sinulla on track_utility = päällä, myös joukkojasi seurataan.

Kyllä tietysti.

Ja jos sinulla on java-hibernate, joka on satunnainen, hash-taulukko alkaa sijaita siellä. Ja heti kun sammutat hyvin ladatun sovelluksen, päädyt 50-100 ryhmään. Ja siellä kaikki on enemmän tai vähemmän vakaata. Yksi tapa torjua tätä on lisätä pg_stat_statements.max.

Kyllä, mutta sinun on tiedettävä kuinka paljon. Ja jotenkin meidän on pidettävä häntä silmällä. Sitä minä teen. Eli minulla on pg_stat_statements.max. Ja näen, että tilannekuvan ottamisen aikaan en ollut saavuttanut 70 prosenttia. Okei, emme ole menettäneet mitään. Nollataan. Ja säästämme taas. Jos seuraava tilannekuva on alle 70, et todennäköisesti ole menettänyt enää mitään.

Joo. Oletusarvo on nyt 5 000. Ja tämä riittää monille ihmisille.

Yleensä kyllä.

Video:

P.S. Lisään omasta puolestani, että jos Postgres sisältää luottamuksellisia tietoja eikä niitä voida sisällyttää testiympäristöön, voit käyttää PostgreSQL Anonymizer. Kaava on suunnilleen seuraava:

Lähde: will.com