En industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser." Nikolay Samokhvalov

Jeg foreslår, at du læser udskriften af ​​Nikolai Samokhvalovs rapport "Industriel tilgang til tuning af PostgreSQL: eksperimenter på databaser"

Shared_buffers = 25% – er det meget eller lidt? Eller bare rigtigt? Hvordan ved du, om denne - ret forældede - anbefaling er passende i netop dit tilfælde?

Det er tid til at nærme sig spørgsmålet om at vælge postgresql.conf-parametre "som en voksen." Ikke ved hjælp af blinde "autotunere" eller forældede råd fra artikler og blogs, men baseret på:

1. strengt verificerede eksperimenter på databaser, udført automatisk, i store mængder og under forhold så tæt som muligt på "bekæmpende" dem,
2. dyb forståelse af funktionerne i DBMS og OS.

Bruger Nancy CLI (https://gitlab.com/postgres.ai/nancy), vil vi se på et specifikt eksempel - de notoriske shared_buffers - i forskellige situationer, i forskellige projekter og forsøge at finde ud af, hvordan man vælger den optimale indstilling for vores infrastruktur, database og belastning.

Vi vil tale om eksperimenter med databaser. Dette er en historie, der varer lidt over seks måneder.

Lidt om mig. Erfaring med Postgres i mere end 14 år. En række sociale netværksvirksomheder har grundlagt. Postgres var og bliver brugt overalt.

Også RuPostgres-gruppen på Meetup, 2. pladsen i verden. Vi nærmer os langsomt 2 mennesker. RuPostgres.org.

Og på pc'er på forskellige konferencer, herunder Highload, er jeg ansvarlig for databaser, især Postgres helt fra starten.

Og i de sidste par år har jeg genstartet min Postgres konsulentpraksis 11 tidszoner herfra.

Og da jeg gjorde dette for et par år siden, havde jeg en pause i aktivt manuelt arbejde med Postgres, formentlig siden 2010. Jeg var overrasket over, hvor lidt arbejdsrutinen på en DBA har ændret sig, og hvor meget manuelt arbejde, der stadig skal bruges. Og jeg tænkte med det samme, at der var noget galt her, jeg skal automatisere mere af det hele.

Og da det hele var fjerntliggende, var de fleste af klienterne i skyerne. Og meget er naturligvis allerede blevet automatiseret. Mere om dette senere. Det vil sige, at alt dette resulterede i ideen om, at der skulle være en række værktøjer, det vil sige en form for platform, der vil automatisere næsten alle DBA-handlinger, så et stort antal databaser kan administreres.

Denne rapport vil ikke indeholde:

• "Silver bullets" og udsagn som - sæt 8 GB eller 25% shared_buffers, og du vil være i orden. Der vil ikke være meget om shared_buffers.
• Hardcore "indvolde".

Hvad vil der ske?

• Der vil være optimeringsprincipper, som vi anvender og udvikler. Der vil være alle mulige ideer, der opstår undervejs og forskellige værktøjer, som vi for det meste skaber i Open Source, det vil sige, at vi laver grundlaget i Open Source. Desuden har vi billetter, al kommunikation er praktisk talt Open Source. Du kan se, hvad vi laver nu, hvad der kommer i næste udgivelse osv.
• Der vil også være en del erfaring med at bruge disse principper, disse værktøjer i en række virksomheder: fra små startups til store virksomheder.

Hvordan udvikler det sig alt sammen?

For det første er hovedopgaven for en DBA, udover at sikre oprettelse af instanser, udrulning af backups osv., at finde flaskehalse og optimere ydeevnen.

Nu er det sat op sådan her. Vi ser på overvågningen, vi ser noget, men vi mangler nogle detaljer. Vi begynder at grave mere omhyggeligt, normalt med hænderne, og forstår, hvad vi skal gøre med det på den ene eller anden måde.

Og der er to tilgange. Pg_stat_statements er standardløsningen til at identificere langsomme forespørgsler. Og analyse af Postgres-logfiler ved hjælp af pgBadger.

Hver tilgang har alvorlige ulemper. I den første tilgang har vi smidt alle parametrene ud. Og hvis vi ser grupperne SELECT * FROM, hvor kolonnen er lig med "?" eller "$" siden Postgres 10. Vi ved ikke, om dette er en indeksscanning eller en seq-scanning. Det afhænger meget af parameteren. Hvis du erstatter en sjældent stødt værdi der, vil det være en indeksscanning. Hvis du erstatter en værdi, der fylder 90% af tabellen der, vil seq-scanningen være indlysende, fordi Postgres kender statistikken. Og dette er en stor ulempe ved pg_stat_statements, selvom noget arbejde er i gang.

Den største ulempe ved loganalyse er, at du som regel ikke har råd til "log_min_duration_statement = 0". Og det vil vi også tale om. Derfor ser du ikke hele billedet. Og nogle forespørgsler, som er meget hurtige, kan bruge en enorm mængde ressourcer, men du vil ikke se den, fordi den er under din tærskel.

Hvordan løser DBA'er de problemer, de finder?

For eksempel fandt vi et problem. Hvad gør man normalt? Hvis du er en udvikler, vil du gøre noget på en instans, der ikke er af samme størrelse. Hvis du er DBA, så har du iscenesættelse. Og der kan kun være én. Og han var seks måneder bagud. Og du tror, ​​at du vil gå til produktion. Og selv erfarne DBA'er tjekker så produktionen ind på en replika. Og det sker, at de laver et midlertidigt indeks, sørger for at det hjælper, dropper det og giver det til udviklerne, så de kan lægge det i migreringsfilerne. Det er den slags nonsens, der sker nu. Og dette er et problem.

• Tune konfigurationer.
• Optimer sættet af indekser.
• Skift selve SQL-forespørgslen (dette er den sværeste måde).
• Tilføj kapacitet (den nemmeste måde i de fleste tilfælde).

Der sker meget med disse ting. Der er mange håndtag i Postgres. Der er meget at vide. Der er mange indekser i Postgres, også tak til arrangørerne af denne konference. Og alt dette skal vides, og det er det, der får ikke-DBA'er til at føle, at DBA'er praktiserer sort magi. Det vil sige, at du skal studere i 10 år for at begynde at forstå alt dette normalt.

Og jeg er en kæmper mod denne sorte magi. Jeg vil gøre alt, så der er teknologi, og der er ingen intuition i alt det her.

Livseksempler

Jeg observerede dette i mindst to projekter, inklusive mit eget. Et andet blogindlæg fortæller os, at en værdi på 1 for default_statistict_target er god. Okay, lad os prøve det i produktionen.

Og her er vi, ved at bruge vores værktøj to år senere, og ved hjælp af eksperimenter på de databaser, som vi taler om i dag, kan vi sammenligne, hvad der var og hvad der er blevet til.

Og til dette skal vi lave et eksperiment. Den består af fire dele.

• Den første er miljøet. Vi har brug for et stykke hardware. Og når jeg kommer til et eller andet firma og underskriver en kontrakt, fortæller jeg dem, at de skal give mig det samme hardware som i produktionen. Til hver af dine Masters har jeg brug for mindst ét ​​stykke hardware som dette. Enten er dette en virtuel maskine i Amazon eller Google, eller også har jeg brug for nøjagtig det samme stykke hardware. Det vil sige, at jeg vil genskabe miljøet. Og i miljøkonceptet inkluderer vi hovedversionen af ​​Postgres.
• Den anden del er genstand for vores forskning. Dette er en database. Det kan laves på flere måder. Jeg skal vise dig hvordan.
• Den tredje del er belastningen. Dette er det sværeste øjeblik.
• Og den fjerde del er, hvad vi tjekker, altså hvad vi vil sammenligne med hvad. Lad os sige, at vi kan ændre en eller flere parametre i konfigurationen, eller vi kan oprette et indeks osv.

Vi sætter et eksperiment i gang. Her er pg_stat_statements. Til venstre er hvad der skete. Til højre - hvad skete der.

Til venstre default_statistics_target = 100, til højre = 1. Vi kan se, at dette hjalp os. Alt i alt blev alt bedre med 000 %.

Men hvis vi scroller ned, vil der være grupper af anmodninger fra pgBadger eller fra pg_stat_statements. Der er to muligheder. Vi vil se, at nogle anmodninger er faldet med 88 %. Og her kommer den ingeniørmæssige tilgang. Vi kan grave længere indenfor, fordi vi undrer os over, hvorfor den sank. Du skal forstå, hvad der skete med statistikken. Hvorfor flere buckets i statistik fører til dårligere resultater.

Eller vi kan ikke grave, men gør "ALTER TABLE ... ALTER COLUMN" og returnerer 100 buckets tilbage til statistikken i denne kolonne. Og så med endnu et eksperiment kan vi sikre os, at denne patch hjalp. Alle. Dette er en ingeniørtilgang, der hjælper os med at se det store billede og træffe beslutninger baseret på data snarere end på intuition.

Et par eksempler fra andre områder. Der har været CI-test i test i mange år. Og intet projekt ved sit rette sind ville leve uden automatiserede tests.

I andre brancher: i luftfarten, i bilindustrien, når vi tester aerodynamik, har vi også mulighed for at lave eksperimenter. Vi vil ikke sende noget fra en tegning direkte ud i rummet, eller vi vil ikke med det samme tage en bil ind på banen. For eksempel er der en vindtunnel.

Vi kan drage konklusioner fra observationer fra andre brancher.

For det første har vi et særligt miljø. Det er tæt på produktion, men ikke tæt på. Dens vigtigste funktion er, at den skal være billig, gentagelig og så automatiseret som muligt. Og der skal også være specielle værktøjer til at udføre detaljerede analyser.

Når vi sender et fly op og flyver, har vi højst sandsynligt mindre mulighed for at studere hver millimeter af vingeoverfladen, end vi har i en vindtunnel. Vi har flere diagnostiske værktøjer. Vi har råd til at transportere flere tunge ting, som vi ikke har råd til at sætte på et fly i luften. Det samme med Postgres. Vi kan i nogle tilfælde aktivere fuld forespørgselslogning under eksperimenter. Og vi ønsker ikke at gøre dette i produktionen. Vi planlægger måske endda at aktivere dette ved hjælp af auto_explain.

Og som sagt betyder et højt automatiseringsniveau, at vi trykker på knappen og gentager. Sådan skal det være, så der bliver eksperimenteret meget, så det er i gang.

Nancy CLI - grundlaget for "databaselaboratoriet"

Og så gjorde vi denne ting. Det vil sige, jeg talte om disse ideer i juni for næsten et år siden. Og vi har allerede den såkaldte Nancy CLI i Open Source. Dette er grundlaget for at bygge et databaselaboratorium.

Nancy - Det er i Open Source, på Gitlab. Du kan sige det, du kan prøve det. Jeg har givet et link i slides. Du kan klikke på den, og den vil være der hjælpe i alle henseender.

Der er selvfølgelig stadig meget under udvikling. Der er mange ideer der. Men det er noget, vi bruger næsten hver dag. Og når vi har en idé - hvorfor er det, at når vi sletter 40 linjer, kommer det hele ned på IO, så kan vi udføre et eksperiment og se mere detaljeret for at forstå, hvad der sker, og så forsøge at rette det på farten. Det vil sige, at vi laver et eksperiment. For eksempel justerer vi noget og ser, hvad der sker i sidste ende. Og det gør vi ikke i produktionen. Dette er essensen af ​​ideen.

Hvor kan dette virke? Dette kan fungere lokalt, dvs. du kan gøre det hvor som helst, du kan endda køre det på en MacBook. Vi har brug for en havnearbejder, lad os gå. Det er alt. Du kan køre det i nogle tilfælde på et stykke hardware eller i en virtuel maskine, hvor som helst.

Og der er også mulighed for at køre eksternt i Amazon i EC2 Instance, i spots. Og det er en meget fed mulighed. For eksempel udførte vi i går mere end 500 eksperimenter på i3-forekomster, startende med den yngste og sluttede med i3-16-xlarge. Og 500 eksperimenter kostede os $64. Hver varede 15 minutter. Det vil sige, at på grund af at der bruges spots der, er det meget billigt – 70% rabat, Amazons pr. Du kan gøre meget. Du kan lave rigtig research.

Og tre større versioner af Postgres er understøttet. Det er ikke så svært at afslutte nogle gamle og den nye 12. version også.

Vi kan definere et objekt på tre måder. Det her:

• Dump/sql-fil.
• Den vigtigste måde er at klone PGDATA-biblioteket. Som regel tages det fra backupserveren. Hvis du har normale binære sikkerhedskopier, kan du lave kloner derfra. Hvis du har skyer, så vil et cloud-kontor som Amazon og Google gøre dette for dig. Dette er den vigtigste måde at klone ægte produktion på. Sådan udfolder vi os.
• Og den sidste metode er velegnet til research, når man vil forstå, hvordan noget fungerer i Postgres. Dette er pgbench. Du kan generere ved hjælp af pgbench. Det er kun en "db-pgbench" mulighed. Fortæl ham hvilken skala. Og alt bliver som sagt genereret i skyen.

Og indlæs:

• Vi kan udføre belastningen i én SQL-tråd. Dette er den mest primitive måde.
• Og vi kan efterligne belastningen. Og vi kan efterligne det først og fremmest på følgende måde. Vi skal samle alle logfilerne. Og det er smertefuldt. Jeg skal vise dig hvorfor. Og ved at bruge pgreplay spiller vi, som er indbygget i Nancy.
• Eller en anden mulighed. Den såkaldte håndværksbelastning, som vi laver med en vis indsats. Ved at analysere vores nuværende belastning på kampsystemet trækker vi de øverste grupper af anmodninger ud. Og ved at bruge pgbench kan vi efterligne denne belastning i laboratoriet.

• Enten skal vi udføre en form for SQL, dvs. vi tjekker en form for migrering, opretter et indeks der, udfører ANALAZE der. Og vi ser på, hvad der skete før vakuumet og efter vakuumet. Generelt enhver SQL.
• Enten ændrer vi en eller flere parametre i konfigurationen. Vi kan bede os om at tjekke for eksempel 100 værdier i Amazon for vores terabyte-database. Og om et par timer har du resultatet. Som regel vil det tage dig flere timer at implementere en terabyte-database. Men der er en patch under udvikling, vi har en serie mulig, dvs. du kan konsekvent bruge de samme pgdata på den samme server og tjekke. Postgres genstarter, og cachen nulstilles. Og du kan køre læsset.

• En mappe ankommer med en masse forskellige filer, startende fra pg snapshotsstat***. Og det mest interessante der er pg_stat_statements, pg_stat_kcacke. Dette er to udvidelser, der analyserer anmodninger. Og pg_stat_bgwriter indeholder ikke kun pgwriter-statistikker, men også om checkpoint og hvordan backends selv fortrænger beskidte buffere. Og det hele er interessant at se. For eksempel, når vi opsætter shared_buffers, er det meget interessant at se, hvor meget alle erstattede.
• Postgres logs ankommer også. To logs – en forberedelseslog og en load-afspilningslog.
• En relativt ny funktion er FlameGraphs.
• Også, hvis du brugte pgreplay eller pgbench muligheder til at spille belastningen, så vil deres output være native. Og du vil se latency og TPS. Det vil være muligt at forstå, hvordan de så det.
• Systemoplysninger.
• Grundlæggende CPU- og IO-tjek. Dette er mere for EC2-forekomster i Amazon, når du vil starte 100 identiske forekomster i en tråd og køre 100 forskellige kørsler der, så vil du have 10 eksperimenter. Og du skal sørge for, at du ikke støder på en mangelfuld instans, der allerede er undertrykt af nogen. Andre er aktive på dette stykke hardware, og du har kun få ressourcer tilbage. Det er bedre at kassere sådanne resultater. Og ved hjælp af sysbench fra Alexey Kopytov laver vi flere korte tjek, der kommer og kan sammenlignes med andre, dvs. du vil forstå, hvordan CPU'en opfører sig, og hvordan IO'en opfører sig.

Hvad er de tekniske vanskeligheder baseret på eksemplet fra forskellige virksomheder?

Lad os sige, at vi vil gentage den reelle belastning ved hjælp af logfiler. Det er en god idé, hvis det er skrevet på Open Source pgreplay. Vi bruger det. Men for at det skal fungere godt, skal du aktivere fuld forespørgselslogning med parametre og timing.

Der er nogle komplikationer med varighed og tidsstempling. Vi tømmer hele køkkenet. Hovedspørgsmålet er, om du har råd eller ej?

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

Problemet er, at det muligvis ikke er tilgængeligt. Først og fremmest skal du forstå, hvilken strøm der vil blive skrevet til loggen. Hvis du har pg_stat_statements, kan du bruge denne forespørgsel (linket vil være tilgængeligt i slides) til at forstå cirka hvor mange bytes der bliver skrevet pr. sekund.

Vi ser på længden af ​​anmodningen. Vi ser bort fra det faktum, at der ikke er nogen parametre, men vi kender længden af ​​anmodningen, og vi ved, hvor mange gange i sekundet den blev udført. På denne måde kan vi estimere cirka hvor mange bytes pr. sekund. Vi laver måske dobbelt så meget fejl, men vi vil helt sikkert forstå rækkefølgen på denne måde.

Vi kan se, at denne anmodning udføres 802 gange i sekundet. Og vi ser, at bytes_per sek – 300 kB/s vil blive skrevet plus eller minus. Og som regel har vi råd til et sådant flow.

Men! Faktum er, at der er forskellige logningssystemer. Og folks standard er normalt "syslog".

Og hvis du har syslog, så har du måske et billede som dette. Vi tager pgbench, aktiverer forespørgselslogning og ser, hvad der sker.

Uden logning - dette er kolonnen til venstre. Vi fik 161 TPS. Med syslog - dette er i Ubuntu 000 på Amazon, vi får 16.04 TPS. Og hvis vi skifter til to andre logningsmetoder, så er situationen meget bedre. Det vil sige, vi forventede, at det ville falde, men ikke i samme omfang.

Og på CentOS 7, som journald også deltager i, gør logs til et binært format for nem søgning osv., så er det et mareridt der, vi falder 44 gange i TPS.

Og det er det, folk lever med. Og ofte i virksomheder, især store, er dette meget svært at ændre. Hvis du kan komme væk fra syslog, så kom venligst væk fra det.

• Evaluer IOPS og skrive flow.
• Tjek dit logningssystem.
• Hvis den forventede belastning er for stor, skal du overveje prøveudtagning.

Vi har pg_stat_statements. Den skal som sagt være der. Og vi kan tage og beskrive hver gruppe af anmodninger på en særlig måde i en fil. Og så kan vi bruge en meget praktisk funktion i pgbench - dette er muligheden for at indsætte flere filer ved hjælp af "-f" muligheden.

Den forstår meget "-f". Og du kan fortælle ved hjælp af "@" i slutningen, hvilken share hver fil skal have. Det vil sige, vi kan sige, at gør dette i 10% af tilfældene, og dette i 20%. Og det vil bringe os tættere på det, vi ser i produktionen.

Hvordan vil vi forstå, hvad vi har i produktionen? Hvilken andel og hvordan? Dette er lidt af en sidebemærkning. Vi har et produkt mere postgres-tjek. Også en base i Open Source. Og det udvikler vi nu aktivt.

Han blev født af lidt andre årsager. Af grunde til, at overvågning ikke er nok. Det vil sige, du kommer, ser på basen, ser på de problemer, der findes. Og som regel laver du et sundhedstjek. Hvis du er en erfaren DBA, så laver du sundhedstjek. Vi kiggede på brugen af ​​indekser osv. Hvis du har OKmeter, så er det super. Dette er cool overvågning for Postgres. OKmeter.io – installer det, alt er gjort meget godt der. Det er betalt.

Hvis du ikke har en, så har du normalt ikke meget. I overvågning er der normalt CPU, IO og så med forbehold, og det er alt. Og vi har brug for flere. Vi skal se, hvordan autovakuum fungerer, hvordan checkpoint fungerer, i io skal vi adskille checkpoint fra bgwriter og fra backends osv.

Problemet er, at når man hjælper en stor virksomhed, kan de ikke implementere noget hurtigt. De kan ikke hurtigt købe OKmeter. Måske køber de det om seks måneder. De kan ikke hurtigt levere nogle pakker.

Og vi kom op med den idé, at vi har brug for et specielt værktøj, der ikke kræver noget at blive installeret, dvs. du behøver ikke at installere noget som helst på produktionen. Installer det på din bærbare computer eller på en observerende server, hvorfra du vil køre det. Og det vil analysere en masse ting: styresystemet, filsystemet og Postgres selv, hvilket laver nogle lette forespørgsler, der kan køres direkte til produktion, og intet vil fejle.

Vi kaldte det Postgres-checkup. I medicinske termer er dette et almindeligt helbredstjek. Hvis det er biltema, så er det ligesom vedligeholdelse. Du laver vedligeholdelse på din bil hvert halve år eller hvert år, afhængigt af mærket. Vedligeholder du din base? Det vil sige, laver du dyb research regelmæssigt? Det skal gøres. Hvis du laver sikkerhedskopier, så lav et tjek, dette er ikke mindre vigtigt.

Og sådan et værktøj har vi. Det begyndte aktivt at dukke op for kun cirka tre måneder siden. Han er stadig ung, men der er meget der.

Indsamling af de mest "indflydelsesrige" grupper af forespørgsler - rapport K003 i Postgres-checkup

Og der er en gruppe rapporter K. Tre rapporter indtil videre. Og der er sådan en rapport K003. Der er toppen fra pg_stat_statements, sorteret efter total_time.

Når vi sorterer anmodningsgrupper efter total_time, ser vi øverst den gruppe, der belaster vores system mest, dvs. bruger flere ressourcer. Hvorfor navngiver jeg forespørgselsgrupper? Fordi vi smed parametrene ud. Disse er ikke længere anmodninger, men grupper af anmodninger, dvs. de er abstraheret.

Og hvis vi optimerer fra top til bund, vil vi lette vores ressourcer og forsinke det øjeblik, hvor vi skal opgradere. Dette er en meget god måde at spare penge på.

Måske er dette ikke en særlig god måde at tage sig af brugerne på, fordi vi måske ikke ser sjældne, men meget irriterende tilfælde, hvor en person ventede 15 sekunder. I alt er de så sjældne, at vi ikke ser dem, men vi har med ressourcer at gøre.

Hvad skete der i denne tabel? Vi tog to snapshots. Postgres_checkup vil give dig et delta for hver metrik: total tid, opkald, rækker, shared_blks_read osv. Det er det, deltaet er blevet beregnet. Det store problem med pg_stat_statements er, at den ikke husker, hvornår den blev nulstillet. Hvis pg_stat_database husker, så husker pg_stat_statements det ikke. Du kan se, at der er et antal på 1, men vi ved ikke, hvor vi har talt fra.

Og her ved vi, her har vi to snapshots. Vi ved, at deltaet i dette tilfælde var 56 sekunder. Et meget kort mellemrum. Sorteret efter total_time. Og så kan vi differentiere, det vil sige at vi deler alle målinger efter varighed. Hvis vi deler hver metrik efter varighed, vil vi have antallet af opkald pr. sekund.

Dernæst er total_time per second min yndlingsmetrik. Det måles i sekunder pr. sekund, dvs. hvor mange sekunder det tog vores system at udføre denne gruppe af anmodninger pr. sekund. Hvis du ser mere end et sekund i sekundet der, betyder det, at du skulle give mere end én kerne. Dette er en meget god metrik. Du kan forstå, at denne ven, for eksempel, har brug for mindst tre kerner.

Dette er vores knowhow, jeg har aldrig set noget lignende nogen steder. Bemærk venligst - dette er en meget simpel ting - sekund i sekundet. Nogle gange, når din CPU er 100%, derefter en halv time i sekundet, det vil sige, du brugte en halv time på at gøre netop denne anmodning.

Dernæst ser vi rækker pr. sekund. Vi ved, hvor mange rækker i sekundet den returnerede.

Og så er der også en interessant ting. Hvor mange shared_buffers vi læser pr. sekund fra shared_buffers selv. Hitsene var der allerede, og vi tog rækkerne fra operativsystemets cache eller fra disken. Den første mulighed er hurtig, og den anden kan være hurtig eller ikke, afhængigt af situationen.

Og den anden måde at differentiere på er at opdele antallet af anmodninger i denne gruppe. I den anden kolonne vil du altid have en forespørgsel opdelt pr. forespørgsel. Og så er det interessant - hvor mange millisekunder var der i denne anmodning. Vi ved, hvordan denne forespørgsel opfører sig i gennemsnit. 101 millisekunder var nødvendige for hver anmodning. Dette er den traditionelle metrik, vi skal forstå.

Hvor mange rækker returnerede hver forespørgsel i gennemsnit? Vi ser 8 denne gruppe vender tilbage. I gennemsnit, hvor meget blev taget fra cachen og læst. Vi ser, at alt er cachet pænt. Solide hits til den første gruppe.

Og den fjerde understreng i hver linje er, hvor stor en procentdel af totalen. Vi har opkald. Lad os sige 1. Og vi kan forstå, hvilket bidrag denne gruppe yder. Vi ser, at i dette tilfælde bidrager den første gruppe med mindre end 000 %. Det vil sige, at det går så langsomt, at vi ikke ser det i det samlede billede. Og den anden gruppe er 000% på opkald. Det vil sige, at 0,01 % af alle opkald er den anden gruppe.

Total_time er også interessant. Vi brugte 14 % af vores samlede arbejdstid på den første gruppe af anmodninger. Og for den anden - 11% osv.

Jeg vil ikke gå i detaljer, men der er finesser der. Vi viser en fejl øverst, for når vi sammenligner, kan snapshots flyde, det vil sige, at nogle anmodninger kan falde ud og ikke længere kan være til stede i den anden, mens nogle nye kan dukke op. Og der regner vi fejlen ud. Hvis du ser 0, så er det godt. Der er ingen fejl. Hvis fejlprocenten er op til 20 %, er det OK.

Så vender vi tilbage til vores emne. Vi skal lave arbejdsbyrden. Vi tager det fra top til bund og går, indtil vi når 80% eller 90%. Normalt er dette 10-20 grupper. Og vi laver filer til pgbench. Vi bruger tilfældigt der. Nogle gange lykkes dette desværre ikke. Og i Postgres 12 vil der være flere muligheder for at bruge denne tilgang.

Og så vinder vi 80-90% i total_time på denne måde. Hvad skal jeg sætte efter "@"? Vi ser på opkaldene, ser på hvor stor interesse der er og forstår, at vi skylder så stor interesse her. Ud fra disse procentsatser kan vi forstå, hvordan man balancerer hver af filerne. Derefter bruger vi pgbench og går på arbejde.

Vi har også K001 og K002.

K001 er én stor streng med fire understrenge. Dette er karakteristisk for hele vores last. Se anden kolonne og anden underrække. Vi ser, at omkring halvandet sekund pr. sekund, altså hvis der er to kerner, så vil det være godt. Der vil være cirka 75 % kapacitet. Og det vil fungere sådan her. Hvis vi har 10 kerner, så vil vi generelt være rolige. På denne måde kan vi vurdere ressourcer.

K002 er det, jeg kalder forespørgselsklasser, dvs. SELECT, INSERT, UPDATE, DELETE. Og separat VÆLG FOR OPDATERING, fordi det er en lås.

Og her kan vi konkludere, at SELECT er almindelige læsere - 82% af alle opkald, men på samme tid - 74% i total_time. Det vil sige, at de hedder meget, men bruger færre ressourcer.

Og vi vender tilbage til spørgsmålet: "Hvordan kan vi vælge de rigtige shared_buffers?" Jeg observerer, at de fleste benchmarks er baseret på ideen - lad os se, hvad gennemløbet bliver, dvs. hvad gennemløbet bliver. Det måles normalt i TPS eller QPS.

Og vi forsøger at presse så mange transaktioner ud i sekundet som muligt fra bilen ved hjælp af tuning-parametre. Her er præcis 311 pr. sekund for at vælge.

Men ingen kører med fuld fart på arbejde og hjem igen. Det her er fjollet. Det samme med databaser. Vi skal ikke køre med fuld fart, og det er der ingen, der gør. Ingen bor i produktionen, som har 100% CPU. Selvom der måske er nogen, der lever, men det er ikke godt.

Tanken er, at vi normalt kører med 20 procent af kapaciteten, helst ikke mere end 50 procent. Og vi forsøger frem for alt at optimere responstiden for vores brugere. Det vil sige, at vi skal dreje vores knapper, så der er en minimum latency ved 20% hastighed, betinget. Det er en idé, som vi også forsøger at bruge i vores eksperimenter.

Og endelig anbefalinger:

• Sørg for at lave Database Lab.
• Hvis det er muligt, så gør det på efterspørgsel, så det folder sig ud et stykke tid – leg og smid det væk. Hvis du har skyer, så siger det sig selv, altså har en masse stående.
• Vær nysgerrig. Og hvis noget er galt, så tjek med eksperimenter, hvordan det opfører sig. Nancy kan bruges til at træne dig selv til at tjekke, hvordan basen fungerer.
• Og sigt efter den minimale svartid.
• Og vær ikke bange for Postgres-kilder. Når du arbejder med kilder, skal du kunne engelsk. Der er mange kommentarer der, alt er forklaret der.
• Og kontroller databasens tilstand regelmæssigt, mindst en gang hver tredje måned, manuelt eller Postgres-checkup.

R'RѕRїSЂRѕSЃS <

Mange tak! En meget interessant ting.

To stykker.

Ja, to stk. Bare jeg ikke helt forstod. Når Nancy og jeg arbejder, kan vi så kun justere én parameter eller en hel gruppe?

Vi har en delta config parameter. Du kan vende dertil, så meget du vil på én gang. Men du skal forstå, at når du ændrer mange ting, kan du drage de forkerte konklusioner.

Ja. Hvorfor spurgte jeg? For det er svært at udføre eksperimenter, når man kun har én parameter. Du strammer det op, se hvordan det virker. Jeg satte ham ud. Så starter du den næste.

Du kan stramme den samtidig, men det afhænger selvfølgelig af situationen. Men det er bedre at teste én idé. Vi fik en idé i går. Vi havde en meget tæt situation. Der var to konfigurationer. Og vi kunne ikke forstå, hvorfor der var den store forskel. Og ideen opstod, at man skal bruge dikotomi for konsekvent at forstå og finde ud af, hvad forskellen er. Du kan straks gøre halvdelen af ​​parametrene ens, derefter en fjerdedel osv. Alt er fleksibelt.

Og der er et spørgsmål mere. Projektet er ungt og udviklende. Dokumentationen er allerede klar, er der en detaljeret beskrivelse?

Jeg lavede specifikt et link der til beskrivelsen af ​​parametrene. Er det der. Men mange ting er der ikke endnu. Jeg leder efter ligesindede. Og jeg finder dem, når jeg optræder. Det her er meget fedt. Nogen arbejder allerede med mig, nogen hjalp og gjorde noget der. Og hvis du er interesseret i dette emne, så giv feedback på, hvad der mangler.

Når vi har bygget laboratoriet, vil der måske være feedback. Lad os se. Tak skal du have!

Hej! Tak for rapporten! Jeg så, at der er Amazon-understøttelse. Er der planer om at støtte GSP?

Godt spørgsmål. Vi begyndte at gøre det. Og vi frøs den ind for nu, fordi vi gerne vil spare penge. Det vil sige, at der er support ved at bruge run på localhost. Du kan selv oprette en instans og arbejde lokalt. Det er i øvrigt det, vi gør. Jeg gør det her hos Getlab, der hos GSP. Men vi kan ikke se meningen med at lave netop en sådan orkestrering endnu, for Google har ikke billige pladser. Der er ??? tilfælde, men de har begrænsninger. For det første har de altid kun 70% rabat, og du kan ikke spille med prisen der. På spots hæver vi prisen med 5-10% for at mindske sandsynligheden for, at du bliver sparket. Det vil sige, at du sparer pletter, men de kan til enhver tid tages fra dig. Hvis du byder lidt højere end andre gør, bliver du slået ihjel senere. Google har helt andre specifikationer. Og der er en anden meget dårlig begrænsning - de lever kun i 24 timer. Og nogle gange vil vi køre et eksperiment i 5 dage. Men du kan gøre dette pletter; pletter varer nogle gange i måneder.

Hej! Tak for rapporten! Du nævnte kontrol. Hvordan beregner du stat_statements fejl?

Meget godt spørgsmål. Jeg kan vise og fortælle dig meget detaljeret. Kort fortalt ser vi på, hvordan sættet af forespørgselsgrupper har svævet: hvor mange er faldet fra, og hvor mange nye er dukket op. Og så ser vi på to metrics: total_time og calls, så der er to fejl. Og vi ser på bidraget fra de flydende grupper. Der er to undergrupper: dem, der rejste, og dem, der ankom. Lad os se, hvad deres bidrag er til det samlede billede.

Er du ikke bange for, at den vil vende der to eller tre gange i løbet af tiden mellem snapshots?

Det vil sige, har de registreret sig igen eller hvad?

For eksempel er denne anmodning allerede blevet foregrebet én gang, så kom den og blev foregrebet igen, så kom den igen og blev foregrebet igen. Og du har beregnet noget her, og hvor er det hele?

Godt spørgsmål, vi må se.

Jeg gjorde en lignende ting. Det var selvfølgelig nemmere, jeg gjorde det alene. Men jeg var nødt til at nulstille, nulstille stat_statements og regne ud på tidspunktet for øjebliksbilledet, at der var mindre end en vis brøkdel, som stadig ikke nåede loftet for, hvor meget stat_statements kunne akkumulere der. Og min forståelse er, at der højst sandsynligt intet blev fortrængt.

Ja Ja.

Men jeg forstår ikke, hvordan man ellers kan gøre det pålideligt.

Desværre husker jeg ikke præcist, om vi bruger forespørgselsteksten der eller queryid med pg_stat_statements og fokuserer på det. Hvis vi fokuserer på queryid, så sammenligner vi i teorien sammenlignelige ting.

Nej, han kan blive tvunget ud flere gange mellem snapshots og komme igen.

Med samme id?

Ja.

Vi vil studere dette. Godt spørgsmål. Vi skal studere det. Men for nu er det, vi ser, enten skrevet 0...

Dette er selvfølgelig et sjældent tilfælde, men jeg blev chokeret, da jeg fandt ud af, at stat_statemetns kan fortrænge der.

Der kan være mange ting i Pg_stat_statements. Vi stødte på det faktum, at hvis du har track_utility = slået til, så spores dine sæt også.

Ja sikkert.

Og hvis du har java hibernate, som er tilfældigt, så begynder hash-tabellen at blive placeret der. Og så snart du slukker for en meget indlæst applikation, ender du med 50-100 grupper. Og alt er mere eller mindre stabilt der. En måde at bekæmpe dette på er at øge pg_stat_statements.max.

Ja, men du skal vide hvor meget. Og på en eller anden måde skal vi holde øje med ham. Det er hvad jeg gør. Det vil sige, at jeg har pg_stat_statements.max. Og jeg kan se, at jeg på tidspunktet for øjebliksbilledet ikke havde nået 70%. Okay, så vi har ikke mistet noget. Lad os nulstille. Og vi sparer igen. Hvis det næste øjebliksbillede er mindre end 70, så har du højst sandsynligt ikke mistet noget igen.

Ja. Standarden er nu 5. Og det er nok for mange mennesker.

Normalt ja.

Video:

P.S. På mine egne vegne vil jeg tilføje, at hvis Postgres indeholder fortrolige data, og de ikke kan inkluderes i testmiljøet, så kan du bruge PostgreSQL Anonymizer. Ordningen er omtrent som følger:

Kilde: www.habr.com