Industrijski pristup podešavanju PostgreSQL-a: eksperimenti s bazama podataka.” Nikolaj Samokhvalov

Predlažem da pročitate transkript izvještaja Nikolaja Samokhvalova “Industrijski pristup podešavanju PostgreSQL-a: eksperimenti na bazama podataka”

Shared_buffers = 25% – da li je to puno ili malo? Ili samo kako treba? Kako znate da li je ova - prilično zastarjela - preporuka prikladna u vašem konkretnom slučaju?

Vrijeme je da pristupimo pitanju odabira parametara postgresql.conf "kao odrasla osoba". Ne uz pomoć slijepih "auto tjunera" ili zastarjelih savjeta iz članaka i blogova, već na osnovu:

1. strogo verifikovani eksperimenti na bazama podataka, izvođeni automatski, u velikim količinama i pod uslovima što je moguće bližim „borbenim“,
2. duboko razumijevanje karakteristika DBMS-a i OS-a.

Korištenje Nancy CLI (https://gitlab.com/postgres.ai/nancy), pogledat ćemo konkretan primjer - ozloglašene shared_buffers - u različitim situacijama, u različitim projektima i pokušati shvatiti kako odabrati optimalnu postavku za našu infrastrukturu, bazu podataka i opterećenje.

Govorit ćemo o eksperimentima s bazama podataka. Ovo je priča koja traje nešto više od šest mjeseci.

Malo o meni. Iskustvo sa Postgresom više od 14 godina. Osnovano je nekoliko kompanija za društvene mreže. Postgres je bio i koristi se svuda.

Takođe RuPostgres grupa na Meetup-u, 2. mjesto na svijetu. Polako se približavamo 2 ljudi. RuPostgres.org.

A na računarima raznih konferencija, uključujući Highload, odgovoran sam za baze podataka, posebno za Postgres od samog početka.

I u posljednjih nekoliko godina, ponovo sam započeo svoju postgres konsultantsku praksu 11 vremenskih zona odavde.

A kada sam to uradio pre nekoliko godina, imao sam pauzu u aktivnom ručnom radu sa Postgresom, verovatno od 2010. Iznenadio sam se koliko se malo promijenila radna rutina jednog DBA-a i koliko je još potrebno koristiti fizički rad. I odmah sam pomislio da tu nešto nije u redu, moram sve više automatizovati.

A pošto je sve bilo udaljeno, većina klijenata je bila u oblacima. I mnogo je toga već automatizovano, očigledno. Više o tome kasnije. Odnosno, sve je to rezultiralo idejom da treba postojati niz alata, odnosno neka vrsta platforme koja će automatizirati gotovo sve DBA radnje kako bi se moglo upravljati velikim brojem baza podataka.

Ovaj izvještaj neće uključivati:

• “Silver bullets” i izjave poput - postavite 8 GB ili 25% shared_buffers i bit ćete dobro. Neće biti puno o shared_buffers.
• Hardcore "nutrina".

Šta će se desiti?

• Postojat će principi optimizacije koje primjenjujemo i razvijamo. Na tom putu će se pojaviti svakakve ideje i razni alati koje kreiramo najvećim dijelom u Open Source-u, odnosno pravimo osnovu u Open Source-u. Štaviše, imamo karte, sva komunikacija je praktično otvorenog koda. Možete vidjeti šta radimo sada, šta će biti u sljedećem izdanju itd.
• Biće i određenog iskustva u korišćenju ovih principa, ovih alata u brojnim kompanijama: od malih startupa do velikih kompanija.

Kako se sve ovo razvija?

Prvo, glavni zadatak DBA, pored osiguravanja kreiranja instanci, postavljanja sigurnosnih kopija, itd., je pronaći uska grla i optimizirati performanse.

Sada je ovako postavljeno. Gledamo monitoring, vidimo nešto, ali nam nedostaju neki detalji. Počinjemo pažljivije kopati, obično rukama, i razumijemo šta da radimo s tim na ovaj ili onaj način.

I postoje dva pristupa. Pg_stat_statements je zadano rješenje za identifikaciju sporih upita. I analiza Postgres logova koristeći pgBadger.

Svaki pristup ima ozbiljne nedostatke. U prvom pristupu izbacili smo sve parametre. A ako vidimo grupe SELECT * FROM tablicu u kojoj je stupac jednak "?" ili “$” od Postgresa 10. Ne znamo da li je ovo skeniranje indeksa ili seq skeniranje. Mnogo zavisi od parametra. Ako tu zamijenite vrijednost koja se rijetko sreće, to će biti skeniranje indeksa. Ako tu zamenite vrednost koja zauzima 90% tabele, sekvencijalno skeniranje će biti očigledno, jer Postgres poznaje statistiku. A ovo je veliki nedostatak pg_stat_statements, iako je neki posao u toku.

Najveći nedostatak analize dnevnika je to što si po pravilu ne možete priuštiti "log_min_duration_statement = 0". I o ovome ćemo također razgovarati. Shodno tome, ne vidite cijelu sliku. I neki upit, koji je vrlo brz, može potrošiti ogromnu količinu resursa, ali ga nećete vidjeti jer je ispod vašeg praga.

Kako DBA rješavaju probleme koje pronađu?

Na primjer, pronašli smo neki problem. Šta se obično radi? Ako ste programer, onda ćete raditi nešto na instanci koja nije iste veličine. Ako ste DBA, onda imate inscenaciju. A može postojati samo jedan. I zaostajao je šest mjeseci. I mislite da ćete ići u proizvodnju. Pa čak i iskusni DBA zatim provjeravaju proizvodnju, na replici. I dešava se da kreiraju privremeni indeks, uvere se da pomaže, ispuste ga i daju programerima da ga stave u fajlove za migraciju. To je vrsta gluposti koja se sada dešava. I ovo je problem.

• Podesite konfiguracije.
• Optimizirajte skup indeksa.
• Promijenite sam SQL upit (ovo je najteži način).
• Dodajte kapacitet (najlakši način u većini slučajeva).

Mnogo toga se dešava sa ovim stvarima. U Postgresu ima puno ručica. Ima puno toga da se zna. U Postgresu postoji mnogo indeksa, zahvaljujući i organizatorima ove konferencije. I sve ovo treba da se zna, i to je ono zbog čega se ne-DBA osećaju kao da DBA praktikuju crnu magiju. Odnosno, morate učiti 10 godina da biste sve ovo počeli normalno razumjeti.

I ja sam borac protiv ove crne magije. Želim učiniti sve da postoji tehnologija, a da u svemu tome nema intuicije.

Primjeri iz stvarnog života

To sam primijetio u najmanje dva projekta, uključujući i svoj vlastiti. Još jedan blog post nam govori da je vrijednost od 1 za default_statistict_target dobra. U redu, probajmo u proizvodnji.

I evo nas, koristeći naš alat dvije godine kasnije, uz pomoć eksperimenata na bazama podataka o kojima je danas riječ, možemo uporediti što je bilo i što je postalo.

A za to moramo napraviti eksperiment. Sastoji se od četiri dijela.

• Prvi je životna sredina. Treba nam komad hardvera. I kad dođem u neku firmu i potpišem ugovor, kažem da mi daju isti hardver kao u proizvodnji. Za svakog vašeg majstora treba mi barem jedan ovakav hardver. Ili je ovo instanca virtuelne mašine u Amazonu ili Google-u, ili mi treba potpuno isti komad hardvera. Odnosno, želim da rekreiram okruženje. A u koncept okruženja uključujemo glavnu verziju Postgresa.
• Drugi dio je predmet našeg istraživanja. Ovo je baza podataka. Može se kreirati na nekoliko načina. Pokazaću ti kako.
• Treći dio je opterećenje. Ovo je najteži trenutak.
• A četvrti dio je ono što provjeravamo, odnosno šta ćemo s čim uporediti. Recimo da možemo promijeniti jedan ili više parametara u konfiguraciji, ili možemo kreirati indeks, itd.

Pokrećemo eksperiment. Evo pg_stat_statements. Na lijevoj strani je ono što se dogodilo. Desno - šta se desilo.

Na lijevoj strani default_statistics_target = 100, desno = 1. Vidimo da nam je ovo pomoglo. Sve u svemu, sve je bilo bolje za 000%.

Ali ako skrolujemo prema dolje, biće grupe zahtjeva iz pgBadgera ili iz pg_stat_statements. Postoje dvije opcije. Vidjet ćemo da je neki zahtjev opao za 88%. I tu dolazi inženjerski pristup. Možemo kopati dalje unutra jer se pitamo zašto je potonuo. Morate razumjeti šta se dogodilo sa statistikom. Zašto više kantica u statistici dovodi do lošijih rezultata.

Ili ne možemo da kopamo, već uradimo “ALTER TABLE ... ALTER COLUMN” i vratimo 100 bucketa nazad u statistiku ove kolone. A onda sa još jednim eksperimentom možemo se uvjeriti da je ova zakrpa pomogla. Sve. Ovo je inženjerski pristup koji nam pomaže da vidimo širu sliku i donosimo odluke zasnovane na podacima, a ne na intuiciji.

Par primjera iz drugih oblasti. Postoje CI testovi u testiranju dugi niz godina. I nijedan projekat pri zdravoj pameti ne bi živio bez automatiziranih testova.

U drugim industrijama: u vazduhoplovstvu, u automobilskoj industriji, kada testiramo aerodinamiku, takođe imamo priliku da radimo eksperimente. Nećemo lansirati nešto sa crteža direktno u svemir, ili nećemo odmah neki automobil iznijeti na stazu. Na primjer, postoji aerotunel.

Zaključke možemo izvući iz zapažanja drugih industrija.

Prvo, imamo posebno okruženje. Blizu je proizvodnje, ali nije blizu. Njegova glavna karakteristika je da bi trebao biti jeftin, ponovljiv i što je moguće automatiziraniji. I moraju postojati posebni alati za provođenje detaljne analize.

Najvjerovatnije, kada lansiramo avion i letimo, imamo manje mogućnosti da proučimo svaki milimetar površine krila nego u aerotunelu. Imamo više dijagnostičkih alata. Možemo sebi priuštiti da nosimo više teških stvari koje ne možemo sebi priuštiti da stavimo u avion u zraku. Isto i sa Postgresom. U nekim slučajevima možemo omogućiti potpuno evidentiranje upita tokom eksperimenata. A mi to ne želimo da radimo u proizvodnji. Možda čak planiramo da ovo omogućimo koristeći auto_explain.

I kao što sam rekao, visok nivo automatizacije znači da pritisnemo dugme i ponovimo. Ovako i treba da bude, da bude puno eksperimentisanja, da bude na toku.

Nancy CLI - osnova "laboratorije baze podataka"

I tako smo uradili ovu stvar. Odnosno, pričao sam o ovim idejama u junu, prije skoro godinu dana. I već imamo takozvani Nancy CLI u otvorenom kodu. Ovo je temelj za izgradnju laboratorije baze podataka.

Nancy — Nalazi se u otvorenom kodu, na Gitlabu. Možete to reći, možete pokušati. Dao sam link u slajdovima. Možete kliknuti na njega i bit će tamo pomoći u svakom pogledu.

Naravno, mnogo toga je još u razvoju. Ima tu mnogo ideja. Ali ovo je nešto što koristimo skoro svaki dan. A kada imamo ideju – zašto kada izbrišemo 40 redova, sve se svodi na IO, onda možemo provesti eksperiment i pogledati detaljnije da shvatimo šta se dešava i onda pokušati to popraviti u hodu. Odnosno, mi radimo eksperiment. Na primjer, nešto podesimo i vidimo šta će se na kraju dogoditi. A mi to ne radimo u proizvodnji. Ovo je suština ideje.

Gdje ovo može funkcionirati? Ovo može raditi lokalno, tj. možete to učiniti bilo gdje, čak možete pokrenuti i na MacBook-u. Treba nam docker, idemo. To je sve. Možete ga pokrenuti u nekom slučaju na komadu hardvera ili u virtuelnoj mašini, bilo gde.

Postoji i mogućnost za daljinsko pokretanje u Amazonu u EC2 instanci, na mjestima. I ovo je veoma dobra prilika. Na primjer, jučer smo proveli više od 500 eksperimenata na i3 instanci, počevši od najmlađeg do i3-16-xlarge. A 500 eksperimenata nas košta 64 dolara. Svaki je trajao 15 minuta. Odnosno, zbog činjenice da se tamo koriste spotovi, vrlo je jeftino - 70% popusta, Amazonov obračun po sekundi. Možeš mnogo. Možete napraviti pravo istraživanje.

Podržane su tri glavne verzije Postgresa. Nije tako teško završiti neke stare i novu 12. verziju.

Objekt možemo definirati na tri načina. Ovo:

• Dump/sql fajl.
• Glavni način je kloniranje PGDATA direktorija. U pravilu se preuzima sa backup servera. Ako imate normalne binarne sigurnosne kopije, možete napraviti klonove odatle. Ako imate oblake, onda će kancelarija u oblaku kao što su Amazon i Google to učiniti za vas. Ovo je najvažniji način kloniranja stvarne proizvodnje. Ovako se razvijamo.
• I posljednja metoda je pogodna za istraživanje kada želite razumjeti kako nešto funkcionira u Postgresu. Ovo je pgbench. Možete generirati koristeći pgbench. To je samo jedna opcija "db-pgbench". Reci mu na kojoj skali. I sve će biti generisano u oblaku, kao što je navedeno.

I učitaj:

• Možemo izvršiti učitavanje u jednoj SQL niti. Ovo je najprimitivniji način.
• I možemo oponašati opterećenje. A možemo ga oponašati prije svega na sljedeći način. Moramo prikupiti sve trupce. I to je bolno. Pokazaću ti zašto. I pomoću pgreplaya igramo, koji je ugrađen u Nancy.
• Ili druga opcija. Takozvano zanatsko opterećenje koje radimo uz određeni napor. Analizirajući naše trenutno opterećenje na borbenom sistemu, izdvajamo najveće grupe zahtjeva. A pomoću pgbench-a možemo emulirati ovo opterećenje u laboratoriji.

• Ili moramo izvesti neku vrstu SQL-a, tj. provjeriti neku vrstu migracije, tamo kreirati indeks, tamo izvršiti ANALAZE. I gledamo šta se desilo pre vakuuma i posle vakuuma. Općenito, bilo koji SQL.
• Ili ćemo promijeniti jedan ili više parametara u konfiguraciji. Možemo nam reći da provjerimo, na primjer, 100 vrijednosti ​​​na Amazonu za našu bazu podataka u terabajtu. I za nekoliko sati ćete imati rezultat. Po pravilu će vam trebati nekoliko sati za postavljanje terabajtne baze podataka. Ali postoji zakrpa u razvoju, imamo niz mogućih, tj. možete dosljedno koristiti iste pgdata na istom serveru i provjeriti. Postgres će se ponovo pokrenuti i keš će se resetovati. I možete voziti teret.

• Direktorij stiže s gomilom različitih datoteka, počevši od pg snimakastanje***. A tu je najzanimljivija stvar pg_stat_statements, pg_stat_kcacke. Ovo su dvije ekstenzije koje analiziraju zahtjeve. A pg_stat_bgwriter sadrži ne samo pgwriter statistiku, već i na kontrolnoj tački i kako sami backendovi zamenjuju prljave bafere. I sve je to zanimljivo vidjeti. Na primjer, kada smo postavili shared_buffers, vrlo je zanimljivo vidjeti koliko su svi zamijenjeni.
• Postgres logovi također stižu. Dva dnevnika – dnevnik pripreme i dnevnik reprodukcije učitavanja.
• Relativno nova karakteristika je FlameGraphs.
• Također, ako ste koristili pgreplay ili pgbench opcije za igranje opterećenja, onda će njihov izlaz biti izvorni. I vidjet ćete kašnjenje i TPS. Biće moguće razumeti kako su to videli.
• Informacije o sistemu.
• Osnovne CPU i IO provjere. Ovo je više za EC2 instancu u Amazonu, kada želite pokrenuti 100 identičnih instanci u niti i pokrenuti 100 različitih pokretanja tamo, tada ćete imati 10 eksperimenata. I morate se pobrinuti da ne naiđete na pogrešan primjer koji je već neko ugnjetavan. Drugi su aktivni na ovom komadu hardvera i preostalo vam je malo resursa. Bolje je odbaciti takve rezultate. A uz pomoć sysbench-a od Alexeyja Kopytova, radimo nekoliko kratkih provjera koje će doći i mogu se uporediti s drugima, tj. razumjet ćete kako se CPU ponaša i kako se ponaša IO.

Koje su tehničke poteškoće na primjeru različitih kompanija?

Recimo da želimo ponoviti stvarno opterećenje koristeći dnevnike. Odlična je ideja ako je napisana na Open Source pgreplayu. Koristimo ga. Ali da bi dobro funkcionisao, morate omogućiti potpuno evidentiranje upita s parametrima i vremenom.

Postoje neke komplikacije s trajanjem i vremenskom oznakom. Ispraznićemo celu kuhinju. Glavno pitanje je možete li to priuštiti ili ne?

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

Problem je što možda nije dostupan. Prije svega, morate razumjeti koji će tok biti upisan u dnevnik. Ako imate pg_stat_statements, možete koristiti ovaj upit (veza će biti dostupna na slajdovima) da shvatite koliko će bajtova biti upisano u sekundi.

Gledamo dužinu zahtjeva. Zanemarujemo činjenicu da nema parametara, ali znamo dužinu zahtjeva i znamo koliko je puta u sekundi izvršen. Na ovaj način možemo procijeniti otprilike koliko bajtova u sekundi. Možda ćemo duplo više pogriješiti, ali ćemo svakako na ovaj način razumjeti redoslijed.

Možemo vidjeti da se ovaj zahtjev izvršava 802 puta u sekundi. I vidimo da će bytes_per sec – 300 kB/s biti upisano plus ili minus. I, po pravilu, možemo sebi priuštiti takav tok.

Ali! Činjenica je da postoje različiti sistemi evidentiranja. I zadana vrijednost ljudi je obično "syslog".

A ako imate syslog, onda možda imate ovakvu sliku. Uzet ćemo pgbench, omogućiti evidentiranje upita i vidjeti šta će se dogoditi.

Bez evidentiranja - ovo je kolona s lijeve strane. Imamo 161 TPS. Sa syslogom - ovo je u Ubuntu 000 na Amazonu, dobijamo 16.04 TPS. A ako pređemo na dvije druge metode evidentiranja, onda je situacija mnogo bolja. Odnosno, očekivali smo da će opasti, ali ne u istoj mjeri.

A na CentOS-u 7, u kojem učestvuje i journald, pretvarajući logove u binarni format za jednostavno pretraživanje, itd., onda je tu noćna mora, padamo 44 puta u TPS.

I to je ono sa čime ljudi žive. A često je u kompanijama, posebno velikim, to vrlo teško promijeniti. Ako možete pobjeći od syslog-a, molim vas, maknite se od njega.

• Procijenite IOPS i tok pisanja.
• Provjerite svoj sistem evidentiranja.
• Ako je predviđeno opterećenje pretjerano veliko, razmislite o uzorkovanju.

Imamo pg_stat_statements. Kao što sam rekao, mora biti tamo. A svaku grupu zahtjeva možemo uzeti i opisati na poseban način u fajlu. A onda možemo koristiti vrlo zgodnu funkciju u pgbench-u - ovo je mogućnost umetanja nekoliko datoteka pomoću opcije “-f”.

Razumije puno "-f". Uz pomoć znaka "@" na kraju možete reći koji udio treba da ima svaka datoteka. Odnosno, možemo reći da to radite u 10% slučajeva, a ovo u 20%. I to će nas približiti onome što vidimo u proizvodnji.

Kako ćemo shvatiti šta imamo u proizvodnji? Koji udio i kako? Ovo je malo po strani. Imamo još jedan proizvod postgres-checkup. Takođe baza u otvorenom kodu. I sada ga aktivno razvijamo.

Rođen je iz malo drugačijih razloga. Iz razloga što praćenje nije dovoljno. Odnosno, dođete, pogledajte bazu, pogledajte probleme koji postoje. I, po pravilu, radite zdravstveni pregled. Ako ste iskusni DBA, onda uradite health_check. Pogledali smo upotrebu indeksa itd. Ako imate OKmetar, onda odlično. Ovo je super praćenje za Postgres. OKmeter.io – instalirajte ga, tamo je sve urađeno jako dobro. Plaćeno je.

Ako ga nemate, onda obično nemate mnogo. U monitoringu obično postoji CPU, IO, pa s rezervacijama, i to je sve. I treba nam više. Moramo vidjeti kako autovacuum radi, kako radi checkpoint, u io moramo odvojiti checkpoint od bgwritera i od backenda, itd.

Problem je što kada pomognete velikoj kompaniji, oni ne mogu nešto brzo da implementiraju. Ne mogu brzo kupiti OKmetar. Možda će ga kupiti za šest mjeseci. Ne mogu brzo isporučiti neke pakete.

I došli smo na ideju da nam treba poseban alat koji ne zahtijeva ništa da se instalira, odnosno ne morate ništa instalirati u proizvodnji. Instalirajte ga na svoj laptop ili na server za posmatranje odakle ćete ga pokrenuti. I analizirat će mnogo stvari: operativni sistem, sistem datoteka i sam Postgres, praveći neke lagane upite koji se mogu pokrenuti direktno u produkciju i ništa neće uspjeti.

Nazvali smo to Postgres-provjera. U medicinskom smislu, ovo je redovna zdravstvena kontrola. Ako je na temu automobila, onda je to kao održavanje. Održavanje vašeg automobila obavljate svakih šest mjeseci ili godinu dana, ovisno o marki. Održavate li svoju bazu? Odnosno, da li redovno istražujete? To se mora uraditi. Ako napravite sigurnosne kopije, onda napravite provjeru, ovo nije ništa manje važno.

I mi imamo takav alat. Počeo je da se aktivno pojavljuje prije otprilike tri mjeseca. Još je mlad, ali ima mnogo toga.

Prikupljanje najuticajnijih grupa upita - prijavite K003 u Postgres-checkup-u

I postoji grupa izveštaja K. Tri izveštaja do sada. I postoji takav izveštaj K003. Tu je vrh iz pg_stat_statements, sortiran prema ukupnom_vremenu.

Kada sortiramo grupe zahtjeva prema total_time, na vrhu vidimo grupu koja najviše učitava naš sistem, odnosno troši više resursa. Zašto dajem naziv grupama upita? Zato što smo izbacili parametre. To više nisu zahtjevi, već grupe zahtjeva, odnosno apstrahovani su.

A ako optimiziramo od vrha do dna, olakšat ćemo naše resurse i odgoditi trenutak kada trebamo nadograditi. Ovo je veoma dobar način da uštedite novac.

Možda ovo nije baš dobar način za brigu o korisnicima, jer možda ne vidimo rijetke, ali vrlo dosadne slučajeve da je osoba čekala 15 sekundi. Sve u svemu, toliko su rijetki da ih ne vidimo, ali imamo posla s resursima.

Šta se dogodilo u ovoj tabeli? Napravili smo dva snimka. Postgres_checkup će vam dati deltu za svaku metriku: ukupno vrijeme, pozive, redove, shared_blks_read, itd. To je to, delta je izračunata. Veliki problem sa pg_stat_statements je taj što se ne sjeća kada je resetovan. Ako pg_stat_database pamti, onda se pg_stat_statements ne sjeća. Vidite da postoji broj od 1, ali ne znamo odakle smo brojali.

I ovdje znamo, ovdje imamo dva snimka. Znamo da je delta u ovom slučaju bila 56 sekundi. Veoma kratak razmak. Sortirano po ukupno_vrijeme. I onda možemo razlikovati, tj. podijeliti sve metrike po trajanju. Ako svaku metriku podijelimo po trajanju, imat ćemo broj poziva u sekundi.

Zatim, ukupno_vrijeme u sekundi je moja omiljena metrika. Mjeri se u sekundama, u sekundi, odnosno koliko je sekundi bilo potrebno našem sistemu da izvrši ovu grupu zahtjeva u sekundi. Ako vidite više od sekunde u sekundi, to znači da ste morali dati više od jedne jezgre. Ovo je veoma dobra metrika. Možete razumjeti da su ovom prijatelju, na primjer, potrebna najmanje tri jezgra.

Ovo je naše znanje, nikada nigde nisam video nešto slično. Imajte na umu - ovo je vrlo jednostavna stvar - sekunda u sekundi. Ponekad, kada vam je CPU 100%, onda pola sata u sekundi, odnosno pola sata radite samo ove zahtjeve.

Zatim vidimo redove u sekundi. Znamo koliko je redova u sekundi vratilo.

A tu je i jedna zanimljiva stvar. Koliko shared_buffers čitamo u sekundi iz samog shared_buffera. Pogoci su već bili tu, a mi smo uzeli redove iz keša operativnog sistema ili sa diska. Prva opcija je brza, a druga može ili ne mora biti brza, ovisno o situaciji.

A drugi način razlikovanja je podjela broja zahtjeva u ovoj grupi. U drugoj koloni uvijek ćete imati jedan upit podijeljen po upitu. A onda je zanimljivo - koliko je milisekundi bilo u ovom zahtjevu. Znamo kako se ovaj upit ponaša u prosjeku. Za svaki zahtjev bila je potrebna 101 milisekunda. Ovo je tradicionalna metrika koju moramo razumjeti.

Koliko je redova u prosjeku svaki upit vratio? Vidimo da se ova grupa vraća. U prosjeku, koliko je uzeto iz keša i pročitano. Vidimo da je sve lepo keširano. Solidni hitovi za prvu grupu.

I četvrti podniz u svakom redu je koji procenat od ukupnog broja. Imamo pozive. Recimo 1 000 000. I možemo shvatiti kakav doprinos ova grupa daje. Vidimo da u ovom slučaju prva grupa doprinosi manje od 0,01%. Odnosno, toliko je spor da ga ne vidimo u ukupnoj slici. A druga grupa je 5% na pozive. Odnosno, 5% svih poziva je druga grupa.

Ukupno_vrijeme je također zanimljivo. Na prvu grupu zahtjeva potrošili smo 14% ukupnog radnog vremena. A za drugi - 11% itd.

Neću ulaziti u detalje, ali tu ima suptilnosti. Na vrhu prikazujemo grešku, jer kada upoređujemo, snimci mogu plutati, odnosno neki zahtjevi mogu ispasti i više ne mogu biti prisutni u drugom, dok se neki novi mogu pojaviti. I tu izračunavamo grešku. Ako vidite 0, onda je to dobro. Nema grešaka. Ako je stopa greške do 20%, u redu je.

Zatim se vraćamo na našu temu. Moramo da osmislimo opterećenje. Uzimamo ga od vrha do dna i idemo dok ne dođemo do 80% ili 90%. Obično je to 10-20 grupa. I pravimo fajlove za pgbench. Tamo koristimo random. Ponekad to, nažalost, ne uspije. I u Postgresu 12 će biti više mogućnosti za korištenje ovog pristupa.

I onda na ovaj način dobijamo 80-90% u total_timeu. Šta da stavim sledeće posle „@“? Gledamo pozive, gledamo kolika je zainteresovanost i shvatamo da ovde dugujemo toliki interes. Iz ovih postotaka možemo razumjeti kako izbalansirati svaki od fajlova. Nakon toga koristimo pgbench i idemo na posao.

Imamo i K001 i K002.

K001 je jedan veliki niz sa četiri podniza. To je karakteristika cjelokupnog našeg opterećenja. Vidi drugu kolonu i drugi podred. To vidimo oko jedne i po sekunde u sekundi, odnosno ako postoje dvije jezgre, onda će biti dobro. Kapacitet će biti oko 75%. I funkcionirat će ovako. Ako imamo 10 jezgri, onda ćemo generalno biti mirni. Na ovaj način možemo procijeniti resurse.

K002 je ono što ja nazivam klasama upita, tj. SELECT, INSERT, UPDATE, DELETE. I posebno SELECT FOR UPDATE, jer je to brava.

I ovdje možemo zaključiti da je SELECT obični čitač - 82% svih poziva, ali istovremeno - 74% u total_timeu. Odnosno, zovu se puno, ali troše manje resursa.

I vraćamo se na pitanje: "Kako možemo odabrati prave shared_buffers?" Primećujem da se većina merila zasniva na ideji - da vidimo kolika će biti propusnost, odnosno kolika će biti propusnost. Obično se mjeri u TPS ili QPS.

I mi pokušavamo istisnuti što više transakcija u sekundi iz automobila koristeći parametre podešavanja. Evo tačno 311 u sekundi za odabrane.

Ali niko se na posao i kući ne vozi punom brzinom. Ovo je glupo. Isto je i sa bazama podataka. Ne moramo da vozimo punom brzinom, a niko ne mora. Niko ne živi u proizvodnji, koja ima 100% CPU. Mada, možda neko živi, ​​ali ovo nije dobro.

Ideja je da obično vozimo sa 20 posto kapaciteta, po mogućnosti ne više od 50%. I trudimo se prije svega optimizirati vrijeme odgovora za naše korisnike. Odnosno, moramo okrenuti dugmad tako da postoji minimalna latencija pri 20% brzine, uslovno. To je ideja koju također pokušavamo koristiti u našim eksperimentima.

I na kraju preporuke:

• Obavezno uradite Laboratoriju za baze podataka.
• Ako je moguće, uradite to na zahtjev tako da se neko vrijeme rasklapa - igrajte i bacite. Ako imate oblake, onda se to podrazumijeva, odnosno imate dosta stajanja.
• Budite radoznali. A ako nešto nije u redu, provjerite eksperimentima kako se ponaša. Nancy se može koristiti da se obučite da provjerite kako baza radi.
• I ciljajte na minimalno vrijeme odgovora.
• I ne plašite se Postgres izvora. Kada radite sa izvorima, morate znati engleski. Tamo ima puno komentara, tamo je sve objašnjeno.
• I redovno provjeravajte ispravnost baze podataka, najmanje jednom u tri mjeseca, ručno ili Postgres-provjeru.

Vaša pitanja

Hvala puno! Vrlo zanimljiva stvar.

Dva dijela.

Da, dva komada. Samo nisam baš razumeo. Kada Nancy i ja radimo, možemo li podesiti samo jedan parametar ili cijelu grupu?

Imamo delta konfiguracijski parametar. Možete se okretati tamo koliko god želite odjednom. Ali morate shvatiti da kada promijenite mnogo stvari, možete izvući pogrešne zaključke.

Da. Zašto sam pitao? Zato što je teško izvoditi eksperimente kada imate samo jedan parametar. Zategni ga, vidi kako radi. Ugasio sam ga. Onda počinjete sa sljedećom.

Možete ga zategnuti u isto vrijeme, ali zavisi od situacije, naravno. Ali bolje je isprobati jednu ideju. Juče smo imali ideju. Imali smo vrlo blisku situaciju. Postojale su dvije konfiguracije. I nismo mogli da shvatimo zašto postoji velika razlika. I pojavila se ideja da morate koristiti dihotomiju kako biste dosljedno razumjeli i pronašli u čemu je razlika. Polovinu parametara možete odmah učiniti istim, zatim četvrtinu itd. Sve je fleksibilno.

I postoji još jedno pitanje. Projekat je mlad i razvija se. Dokumentacija je već gotova, postoji li detaljan opis?

Tamo sam posebno napravio link do opisa parametara. To je tamo. Ali mnogo toga još nije tu. Tražim istomišljenike. I nalazim ih kada nastupam. Ovo je super. Neko već radi sa mnom, neko je tu pomogao i uradio nešto. A ako vas zanima ova tema, dajte povratnu informaciju o tome šta nedostaje.

Kada napravimo laboratoriju, možda će biti povratnih informacija. da vidimo. Hvala ti!

Zdravo! Hvala na izvještaju! Vidio sam da postoji Amazon podrška. Postoje li planovi za podršku GSP-u?

Dobro pitanje. Počeli smo to raditi. I zamrznuli smo ga za sada jer želimo uštedjeti novac. To jest, postoji podrška za korištenje run on localhost. Možete sami kreirati instancu i raditi lokalno. Usput, to je ono što mi radimo. Ovo radim u Getlabu, tamo u GSP-u. Ali još uvijek ne vidimo smisao u samo takvoj orkestraciji, jer Google nema jeftina mjesta. Tu je ??? instance, ali imaju ograničenja. Prvo, uvijek imaju samo 70% popusta i tamo se ne možete igrati s cijenom. Na spotovima povećavamo cijenu za 5-10% kako bismo smanjili vjerovatnoću da ćete biti izbačeni. Odnosno, štedite mjesta, ali vam ih mogu oduzeti u svakom trenutku. Ako licitirate malo više od drugih, kasnije ćete biti ubijeni. Google ima potpuno drugačije specifičnosti. Postoji još jedno vrlo loše ograničenje - žive samo 24 sata. A ponekad želimo provesti eksperiment 5 dana. Ali to možete učiniti na mjestima; fleke ponekad traju mjesecima.

Zdravo! Hvala na izvještaju! Spomenuli ste pregled. Kako izračunati greške stat_statements?

Vrlo dobro pitanje. Mogu vam pokazati i ispričati vrlo detaljno. Ukratko, gledamo kako je skup grupa zahtjeva plutao: koliko ih je otpalo, a koliko se novih pojavilo. A onda gledamo dvije metrike: ukupno_vrijeme i pozive, tako da postoje dvije greške. I pogledamo doprinos plutajućih grupa. Postoje dvije podgrupe: oni koji su otišli i oni koji su stigli. Pogledajmo kakav je njihov doprinos ukupnoj slici.

Ne bojite li se da će se okrenuti tamo dva ili tri puta tokom vremena između snimaka?

Odnosno, da li su se ponovo registrovali ili šta?

Na primjer, ovaj zahtjev je već jednom bio preuzet, zatim je došao i ponovo je bio preuzet, pa je ponovo došao i ponovo je bio preuzet. A ti si ovde nešto izračunao, a gde je sve?

Dobro pitanje, moraćemo da pogledamo.

Uradio sam sličnu stvar. Bilo je jednostavnije, naravno, radio sam sam. Ali morao sam da resetujem, resetujem stat_statements i da shvatim u trenutku snimanja da je bilo manje od određenog dela, koji još uvek nije dostigao plafon koliko stat_statements može da se akumulira. Koliko sam shvatio, najvjerovatnije ništa nije pomjereno.

Da da.

Ali ne razumijem kako drugačije to pouzdano učiniti.

Nažalost, ne sjećam se tačno da li koristimo tekst upita ili queryid sa pg_stat_statements i fokusiramo se na njega. Ako se fokusiramo na queryid, onda u teoriji uspoređujemo uporedive stvari.

Ne, može biti prisiljen nekoliko puta između snimaka i doći ponovo.

Sa istim ID-om?

Da.

Proučićemo ovo. Dobro pitanje. Moramo to proučiti. Ali za sada, ono što vidimo je ili napisano 0...

Ovo je, naravno, rijedak slučaj, ali sam bio šokiran kada sam saznao da se stat_statemetns tamo može pomjeriti.

U Pg_stat_statements može biti mnogo stvari. Naišli smo na činjenicu da ako imate track_utility = uključen, onda se i vaši setovi prate.

Da, naravno.

A ako imate hibernaciju java, koja je nasumična, tada se hash tablica počinje tamo nalaziti. I čim isključite veoma opterećenu aplikaciju, na kraju imate 50-100 grupa. I tamo je sve manje-više stabilno. Jedan od načina za borbu protiv ovoga je povećanje pg_stat_statements.max.

Da, ali morate znati koliko. I nekako ga moramo držati na oku. To je ono što ja radim. To jest, imam pg_stat_statements.max. I vidim da u trenutku snimanja nisam dostigao 70%. Dobro, znači nismo ništa izgubili. Hajde da resetujemo. I opet štedimo. Ako je sljedeći snimak manji od 70, onda najvjerovatnije opet ništa niste izgubili.

Da. Zadana vrijednost je sada 5. I ovo je dovoljno za mnoge ljude.

Obično da.

Video:

P.S. U svoje lično ime, dodaću da ako Postgres sadrži povjerljive podatke i ne može biti uključen u testno okruženje, onda možete koristiti PostgreSQL Anonymizer. Shema je otprilike sljedeća:

izvor: www.habr.com