En industriell metod för att trimma PostgreSQL: experiment med databaser." Nikolay Samokhvalov

Jag föreslår att du läser utskriften av Nikolai Samokhvalovs rapport "Industriell metod för att trimma PostgreSQL: experiment på databaser"

Shared_buffers = 25% – är det mycket eller lite? Eller helt rätt? Hur vet du om denna – ganska förlegade – rekommendation är lämplig i just ditt fall?

Det är dags att närma sig frågan om att välja postgresql.conf-parametrar "som en vuxen". Inte med hjälp av blinda "autotuners" eller föråldrade råd från artiklar och bloggar, utan baserat på:

1. strikt verifierade experiment på databaser, utförda automatiskt, i stora mängder och under förhållanden så nära "bekämpande" som möjligt,
2. djup förståelse för funktionerna i DBMS och OS.

Använder Nancy CLI (https://gitlab.com/postgres.ai/nancy), kommer vi att titta på ett specifikt exempel - de ökända shared_buffers - i olika situationer, i olika projekt och försöka ta reda på hur man väljer den optimala inställningen för vår infrastruktur, databas och belastning.

Vi kommer att prata om experiment med databaser. Det här är en historia som varar i drygt ett halvår.

Lite om mig själv. Erfarenhet av Postgres i mer än 14 år. Ett antal sociala nätverksföretag har grundat. Postgres var och används överallt.

Även RuPostgres-gruppen på Meetup, 2:a plats i världen. Vi närmar oss sakta 2 000 personer. RuPostgres.org.

Och på PC:er på olika konferenser, inklusive Highload, är jag ansvarig för databaser, i synnerhet Postgres från första början.

Och under de senaste åren har jag startat om min Postgres konsultverksamhet 11 tidszoner härifrån.

Och när jag gjorde det här för några år sedan hade jag ett uppehåll i det aktiva manuella arbetet med Postgres, förmodligen sedan 2010. Jag blev förvånad över hur lite arbetsrutinen för en DBA har förändrats, hur mycket manuellt arbete som fortfarande behöver användas. Och jag tänkte direkt att något var fel här, jag måste automatisera mer av allt.

Och eftersom allt var avlägset befann sig de flesta klienterna i molnen. Och mycket har redan automatiserats, uppenbarligen. Mer om detta senare. Det vill säga, allt detta resulterade i idén att det borde finnas ett antal verktyg, det vill säga någon form av plattform som kommer att automatisera nästan alla DBA-åtgärder så att ett stort antal databaser kan hanteras.

Denna rapport kommer inte att innehålla:

• "Silverkulor" och uttalanden som - ställ in 8 GB eller 25% shared_buffers och du kommer att bli bra. Det kommer inte att finnas mycket om shared_buffers.
• Hardcore "inälvor".

Och vad kommer att hända?

• Det kommer att finnas optimeringsprinciper som vi tillämpar och utvecklar. Det kommer att dyka upp alla möjliga idéer på vägen och olika verktyg som vi skapar till största delen i Open Source, det vill säga vi gör grunden i Open Source. Dessutom har vi biljetter, all kommunikation är praktiskt taget öppen källkod. Du kan se vad vi gör nu, vad som kommer att finnas i nästa release osv.
• Det kommer också att finnas en del erfarenhet av att använda dessa principer, dessa verktyg i ett antal företag: från små startups till stora företag.

Hur utvecklas allt detta?

För det första är huvuduppgiften för en DBA, förutom att säkerställa skapandet av instanser, distribution av säkerhetskopior etc., att hitta flaskhalsar och optimera prestanda.

Nu är det uppställt så här. Vi tittar på övervakningen, vi ser något, men vi saknar några detaljer. Vi börjar gräva mer noggrant, vanligtvis med händerna, och förstår vad vi ska göra med det på ett eller annat sätt.

Och det finns två tillvägagångssätt. Pg_stat_statements är standardlösningen för att identifiera långsamma frågor. Och analys av Postgres-loggar med pgBadger.

Varje tillvägagångssätt har allvarliga nackdelar. I det första tillvägagångssättet har vi kastat ut alla parametrar. Och om vi ser grupperna SELECT * FROM där kolumnen är lika med "?" eller "$" sedan Postgres 10. Vi vet inte om detta är en indexskanning eller en seq-skanning. Det beror väldigt mycket på parametern. Om du ersätter ett sällan påträffat värde där blir det en indexskanning. Om du ersätter ett värde som upptar 90% av tabellen där, kommer seq-skanningen att vara uppenbar, eftersom Postgres kan statistiken. Och detta är en stor nackdel med pg_stat_statements, även om en del arbete pågår.

Den största nackdelen med logganalys är att du som regel inte har råd med "log_min_duration_statement = 0". Och vi ska prata om detta också. Följaktligen ser du inte hela bilden. Och vissa frågor, som är mycket snabba, kan förbruka en enorm mängd resurser, men du kommer inte att se den eftersom den ligger under din tröskel.

Hur löser DBA:er de problem de hittar?

Vi hittade till exempel något problem. Vad brukar man göra? Om du är en utvecklare kommer du att göra något på någon instans som inte är av samma storlek. Om du är en DBA, då har du iscensättning. Och det kan bara finnas en. Och han var sex månader efter. Och du tror att du kommer att gå till produktion. Och även erfarna DBA:er checkar sedan in produktionen, på en replik. Och det händer att de skapar ett tillfälligt index, ser till att det hjälper, släpper det och ger det till utvecklarna så att de kan lägga det i migreringsfilerna. Det är den typen av nonsens som händer nu. Och detta är ett problem.

• Justera konfigurationer.
• Optimera uppsättningen av index.
• Ändra själva SQL-frågan (detta är det svåraste sättet).
• Lägg till kapacitet (det enklaste sättet i de flesta fall).

Det händer mycket med dessa saker. Det finns många handtag i Postgres. Det finns mycket att veta. Det finns många index i Postgres, tack också till arrangörerna av denna konferens. Och allt detta måste vara känt, och det är detta som får icke-DBA:er att känna att DBA:er utövar svart magi. Det vill säga, du behöver studera i 10 år för att börja förstå allt detta normalt.

Och jag är en kämpe mot denna svarta magi. Jag vill göra allt så att det finns teknik, och det finns ingen intuition i allt detta.

Verkliga exempel

Jag observerade detta i minst två projekt, inklusive mitt eget. Ett annat blogginlägg berättar att ett värde på 1 000 för default_statistict_target är bra. Okej, låt oss prova det i produktionen.

Och här är vi, med hjälp av vårt verktyg två år senare, med hjälp av experiment på de databaser som vi pratar om idag, kan vi jämföra vad som var och vad som har blivit.

Och för detta måste vi skapa ett experiment. Den består av fyra delar.

• Den första är miljön. Vi behöver en hårdvara. Och när jag kommer till något företag och skriver på ett kontrakt säger jag åt dem att ge mig samma hårdvara som i produktionen. För var och en av dina mästare behöver jag minst en sådan hårdvara. Antingen är detta en virtuell maskin i Amazon eller Google, eller så behöver jag exakt samma maskinvara. Det vill säga jag vill återskapa miljön. Och i miljökonceptet inkluderar vi huvudversionen av Postgres.
• Den andra delen är föremål för vår forskning. Detta är en databas. Det kan skapas på flera sätt. Jag ska visa dig hur.
• Den tredje delen är belastningen. Detta är det svåraste ögonblicket.
• Och den fjärde delen är vad vi kontrollerar, det vill säga vad vi kommer att jämföra med vad. Låt oss säga att vi kan ändra en eller flera parametrar i konfigurationen, eller så kan vi skapa ett index osv.

Vi lanserar ett experiment. Här är pg_stat_statements. Till vänster är vad som hände. Till höger - vad hände.

Till vänster default_statistics_target = 100, till höger = 1 000. Vi ser att detta hjälpte oss. Sammantaget blev allt bättre med 8%.

Men om vi scrollar ner kommer det att finnas grupper av förfrågningar från pgBadger eller från pg_stat_statements. Det finns två alternativ. Vi kommer att se att en del begäran har minskat med 88 %. Och här kommer det tekniska tillvägagångssättet. Vi kan gräva längre inuti eftersom vi undrar varför den sjönk. Du måste förstå vad som hände med statistiken. Varför fler hinkar i statistik leder till sämre resultat.

Eller så kan vi inte gräva, utan gör "ÄNDRA TABELL ... ÄNDRA KOLUMN" och returnera 100 hinkar till statistiken i denna kolumn. Och sedan med ett annat experiment kan vi se till att det här plåstret hjälpte. Allt. Det här är en ingenjörsmetod som hjälper oss att se helheten och fatta beslut baserat på data snarare än på intuition.

Ett par exempel från andra områden. Det har funnits CI-tester i testning i många år. Och inget projekt med sitt fulla sinne skulle leva utan automatiserade tester.

I andra branscher: inom flyget, inom fordonsindustrin, när vi testar aerodynamik har vi också möjlighet att göra experiment. Vi kommer inte att skjuta upp något från en ritning direkt ut i rymden, eller så tar vi inte omedelbart någon bil ut på banan. Det finns till exempel en vindtunnel.

Vi kan dra slutsatser från observationer av andra branscher.

För det första har vi en speciell miljö. Det är nära produktion, men inte nära. Dess huvudsakliga funktion är att den ska vara billig, repeterbar och så automatiserad som möjligt. Och det måste också finnas speciella verktyg för att genomföra detaljerad analys.

Med största sannolikhet när vi sjösätter ett plan och flyger har vi mindre möjlighet att studera varje millimeter av vingytan än vad vi har i en vindtunnel. Vi har fler diagnostiska verktyg. Vi har råd att bära mer tunga saker som vi inte har råd att sätta på ett flygplan i luften. Samma sak med Postgres. Vi kan i vissa fall aktivera fullständig frågeloggning under experiment. Och vi vill inte göra detta i produktionen. Vi kanske till och med planerar att aktivera detta med auto_explain.

Och som sagt, en hög automatisering innebär att vi trycker på knappen och upprepar. Så här ska det vara, så att det blir mycket experimenterande, så att det är igång.

Nancy CLI - grunden för "databaslaboratoriet"

Och så gjorde vi det här. Det vill säga, jag pratade om dessa idéer i juni, för nästan ett år sedan. Och vi har redan den så kallade Nancy CLI i öppen källkod. Detta är grunden för att bygga ett databaslaboratorium.

Nancy – Det är i öppen källkod, på Gitlab. Du kan säga det, du kan prova. Jag gav en länk i bilderna. Du kan klicka på den så kommer den att finnas där hjälpa i alla avseenden.

Naturligtvis är det mycket som fortfarande är under utveckling. Det finns många idéer där. Men det här är något vi använder nästan varje dag. Och när vi har en idé - varför kommer det sig att när vi raderar 40 000 000 rader så kommer allt till IO, då kan vi genomföra ett experiment och titta mer i detalj för att förstå vad som händer och sedan försöka fixa det i farten. Det vill säga, vi gör ett experiment. Vi justerar till exempel något och ser vad som händer i slutändan. Och det gör vi inte i produktionen. Detta är kärnan i idén.

Var kan detta fungera? Detta kan fungera lokalt, det vill säga du kan göra det var som helst, du kan till och med köra det på en MacBook. Vi behöver en hamnarbetare, låt oss gå. Det är allt. Du kan köra det i vissa fall på en hårdvara, eller i en virtuell maskin, var som helst.

Och det finns också möjlighet att köra på distans i Amazon i EC2 Instance, på fläckar. Och det här är en väldigt cool möjlighet. Igår genomförde vi till exempel mer än 500 experiment på i3-instanser, som började med den yngsta och slutade med i3-16-xlarge. Och 500 experiment kostade oss $64. Var och en varade i 15 minuter. Det vill säga, på grund av att spots används där är det väldigt billigt – 70% rabatt, Amazons per sekund fakturering. Du kan göra mycket. Du kan göra riktig forskning.

Och tre huvudversioner av Postgres stöds. Det är inte så svårt att avsluta några gamla och den nya 12:e versionen också.

Vi kan definiera ett objekt på tre sätt. Detta:

• Dump/sql-fil.
• Det huvudsakliga sättet är att klona PGDATA-katalogen. Som regel tas den från backupservern. Om du har normala binära säkerhetskopior kan du göra kloner därifrån. Om du har moln, kommer ett molnkontor som Amazon och Google att göra detta åt dig. Detta är det viktigaste sättet att klona verklig produktion. Så här utvecklar vi oss.
• Och den sista metoden passar för forskning när man vill förstå hur något fungerar i Postgres. Det här är pgbench. Du kan generera med pgbench. Det är bara ett "db-pgbench"-alternativ. Du berättar för honom vilken skala. Och allt kommer att genereras i molnet, som sagt.

Och ladda:

• Vi kan utföra belastningen i en SQL-tråd. Detta är det mest primitiva sättet.
• Och vi kan efterlikna belastningen. Och vi kan först och främst efterlikna det på följande sätt. Vi måste samla alla stockar. Och det är smärtsamt. Jag ska visa dig varför. Och med pgreplay spelar vi, som är inbyggt i Nancy.
• Eller ett annat alternativ. Den så kallade hantverksbelastningen, som vi gör med en viss ansträngning. Genom att analysera vår nuvarande belastning på stridssystemet drar vi ut de översta grupperna av förfrågningar. Och med hjälp av pgbench kan vi emulera denna belastning i laboratoriet.

• Antingen måste vi utföra någon form av SQL, dvs vi kontrollerar någon form av migrering, skapar ett index där, kör ANALAZE där. Och vi tittar på vad som hände före vakuumet och efter vakuumet. I allmänhet, vilken SQL som helst.
• Antingen ändrar vi en eller flera parametrar i konfigurationen. Vi kan berätta för oss att kontrollera till exempel 100 värden i Amazon för vår terabytedatabas. Och om några timmar har du resultatet. Som regel kommer det att ta dig flera timmar att distribuera en terabyte-databas. Men det finns en patch under utveckling, vi har en serie möjlig, dvs du kan konsekvent använda samma pgdata på samma server och kontrollera. Postgres kommer att starta om och cacheminne kommer att återställas. Och du kan köra lasten.

• En katalog kommer med ett gäng olika filer, med början från pg ögonblicksbilderstat***. Och det mest intressanta där är pg_stat_statements, pg_stat_kcacke. Det här är två tillägg som analyserar förfrågningar. Och pg_stat_bgwriter innehåller inte bara pgwriter-statistik, utan också om checkpoint och hur backends själva förskjuter smutsiga buffertar. Och allt är intressant att se. Till exempel, när vi ställer in shared_buffers är det väldigt intressant att se hur mycket alla ersatte.
• Postgres loggar kommer också. Två loggar – en förberedelselogg och en laddningslogg.
• En relativt ny funktion är FlameGraphs.
• Dessutom, om du använde pgreplay eller pgbench alternativ för att spela belastningen, kommer deras utdata att vara inbyggt. Och du kommer att se latens och TPS. Det kommer att gå att förstå hur de såg det.
• Systeminformation.
• Grundläggande CPU- och IO-kontroller. Detta är mer för EC2-instanser i Amazon, när du vill starta 100 identiska instanser i en tråd och köra 100 olika körningar där, då har du 10 000 experiment. Och du måste se till att du inte stöter på en felaktig instans som redan förtrycks av någon. Andra är aktiva på den här hårdvaran och du har lite resurser kvar. Det är bättre att kassera sådana resultat. Och med hjälp av sysbench från Alexey Kopytov gör vi flera korta kontroller som kommer och kan jämföras med andra, det vill säga du kommer att förstå hur CPU:n beter sig och hur IO:n beter sig.

Vilka är de tekniska svårigheterna utifrån exemplet från olika företag?

Låt oss säga att vi vill upprepa den verkliga belastningen med loggar. Det är en bra idé om det är skrivet på Open Source pgreplay. Vi använder det. Men för att det ska fungera bra måste du aktivera fullständig frågeloggning med parametrar och timing.

Det finns vissa komplikationer med varaktighet och tidsstämpel. Vi tömmer hela köket. Huvudfrågan är om du har råd eller inte?

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

Problemet är att det kanske inte är tillgängligt. Först och främst måste du förstå vilken ström som kommer att skrivas till loggen. Om du har pg_stat_statements kan du använda den här frågan (länken kommer att finnas i bilderna) för att förstå ungefär hur många byte som kommer att skrivas per sekund.

Vi tittar på längden på förfrågan. Vi försummar det faktum att det inte finns några parametrar, men vi vet längden på begäran och vi vet hur många gånger per sekund den kördes. På så sätt kan vi uppskatta ungefär hur många byte per sekund. Vi kan göra fel dubbelt så mycket, men vi kommer definitivt att förstå ordningen på detta sätt.

Vi kan se att denna begäran exekveras 802 gånger per sekund. Och vi ser att bytes_per sek – 300 kB/s kommer att skrivas plus eller minus. Och som regel har vi råd med ett sådant flöde.

Men! Faktum är att det finns olika loggningssystem. Och folks standard är vanligtvis "syslog".

Och om du har syslog kan du ha en sådan här bild. Vi tar pgbench, aktiverar frågeloggning och ser vad som händer.

Utan loggning - det här är kolumnen till vänster. Vi fick 161 000 TPS. Med syslog - detta är i Ubuntu 16.04 på Amazon får vi 37 000 TPS. Och om vi byter till två andra loggningsmetoder så är situationen mycket bättre. Det vill säga vi förväntade oss att det skulle sjunka, men inte i samma utsträckning.

Och på CentOS 7, där journald också deltar, förvandlar loggar till ett binärt format för enkel sökning etc., då är det en mardröm där, vi tappar 44 gånger i TPS.

Och det här är vad folk lever med. Och ofta i företag, särskilt stora, är detta väldigt svårt att ändra på. Om du kan komma bort från syslog, snälla kom bort från den.

• Utvärdera IOPS och skrivflöde.
• Kontrollera ditt loggningssystem.
• Om den beräknade belastningen är för stor, överväg provtagning.

Vi har pg_stat_statements. Den måste som sagt finnas där. Och vi kan ta och beskriva varje grupp av förfrågningar på ett speciellt sätt i en fil. Och sedan kan vi använda en mycket bekväm funktion i pgbench - det här är möjligheten att infoga flera filer med alternativet "-f".

Den förstår mycket "-f". Och du kan berätta med hjälp av "@" i slutet vilken andel varje fil ska ha. Det vill säga, vi kan säga att gör detta i 10% av fallen, och detta i 20%. Och detta kommer att föra oss närmare det vi ser i produktionen.

Hur ska vi förstå vad vi har i produktionen? Vilken andel och hur? Det här är lite åt sidan. Vi har en produkt till postgres-checkup. Även en bas i öppen källkod. Och vi utvecklar det nu aktivt.

Han föddes av lite olika anledningar. Av skäl att övervakning inte räcker. Det vill säga, man kommer, tittar på basen, tittar på problemen som finns. Och som regel gör du en hälsokontroll. Om du är en erfaren DBA, då gör du health_check. Vi tittade på användningen av index, etc. Om du har OKmeter, så bra. Det här är cool övervakning för Postgres. OKmeter.io – snälla installera det, allt är gjort väldigt bra där. Det är betalt.

Om du inte har en så har du oftast inte så mycket. Vid övervakning finns det vanligtvis CPU, IO och sedan med reservationer, och det är allt. Och vi behöver mer. Vi måste se hur autovakuum fungerar, hur checkpoint fungerar, i io måste vi separera checkpoint från bgwriter och från backends, etc.

Problemet är att när man hjälper ett stort företag kan de inte implementera något snabbt. De kan inte snabbt köpa OKmeter. De kanske köper den om ett halvår. Vissa paket kan de inte snabbt leverera.

Och vi kom på idén att vi behöver ett specialverktyg som inte kräver att något installeras, det vill säga du behöver inte installera något alls i produktionen. Installera den på din bärbara dator eller på en observationsserver där du kommer att köra den. Och det kommer att analysera många saker: operativsystemet, filsystemet och Postgres själv, vilket gör några lätta frågor som kan köras direkt till produktionen och ingenting kommer att misslyckas.

Vi kallade det Postgres-checkup. I medicinska termer är detta en vanlig hälsokontroll. Om det är biltema är det som underhåll. Du gör underhåll på din bil var sjätte månad eller ett år, beroende på märke. Gör du underhåll för din bas? Det vill säga, gör du djupgående research regelbundet? Det måste göras. Om du gör säkerhetskopior, gör sedan en kontroll, detta är inte mindre viktigt.

Och vi har ett sådant verktyg. Det började aktivt dyka upp för bara cirka tre månader sedan. Han är fortfarande ung, men det finns mycket där.

Samla de mest "inflytelserika" grupperna av frågor - rapportera K003 i Postgres-checkup

Och det finns en grupp rapporter K. Tre rapporter hittills. Och det finns en sådan rapport K003. Det finns toppen från pg_stat_statements, sorterad efter total_time.

När vi sorterar förfrågningsgrupper efter total_time ser vi högst upp den grupp som laddar vårt system mest, det vill säga förbrukar mer resurser. Varför namnger jag frågegrupper? För vi kastade ut parametrarna. Dessa är inte längre förfrågningar, utan grupper av förfrågningar, det vill säga de är abstraherade.

Och om vi optimerar från topp till botten kommer vi att lätta på våra resurser och försena det ögonblick då vi behöver uppgradera. Detta är ett mycket bra sätt att spara pengar.

Kanske är detta inte ett särskilt bra sätt att ta hand om användare, eftersom vi kanske inte ser sällsynta, men väldigt irriterande fall där en person väntat i 15 sekunder. Totalt sett är de så sällsynta att vi inte ser dem, men vi har att göra med resurser.

Vad hände i den här tabellen? Vi tog två ögonblicksbilder. Postgres_checkup ger dig ett delta för varje mätvärde: total tid, samtal, rader, shared_blks_read, etc. Det är allt, delta har beräknats. Det stora problemet med pg_stat_statements är att den inte kommer ihåg när den återställdes. Om pg_stat_database kommer ihåg, så kommer inte pg_stat_statements ihåg. Du ser att det finns ett antal på 1 000 000, men vi vet inte var vi räknade ifrån.

Och här vet vi, här har vi två ögonblicksbilder. Vi vet att deltat i det här fallet var 56 sekunder. Ett mycket kort mellanrum. Sorterat efter total_time. Och sedan kan vi differentiera, det vill säga vi delar upp alla mätvärden efter varaktighet. Om vi ​​delar varje mätvärde efter varaktighet får vi antalet samtal per sekund.

Därefter är total_time per second mitt favoritmått. Det mäts i sekunder, per sekund, det vill säga hur många sekunder det tog vårt system att utföra denna grupp av förfrågningar per sekund. Om du ser mer än en sekund per sekund där betyder det att du var tvungen att ge mer än en kärna. Detta är ett mycket bra mått. Du kan förstå att den här vännen till exempel behöver minst tre kärnor.

Det här är vårt kunnande, jag har aldrig sett något liknande någonstans. Observera - detta är en mycket enkel sak - sekund per sekund. Ibland, när din CPU är 100%, sedan en halvtimme per sekund, det vill säga, du spenderade en halvtimme på att göra just denna begäran.

Därefter ser vi rader per sekund. Vi vet hur många rader per sekund den returnerade.

Och så finns det också en intressant sak. Hur många shared_buffers vi läser per sekund från själva shared_buffers. Träffarna fanns redan där, och vi tog raderna från operativsystemets cache eller från disken. Det första alternativet är snabbt, och det andra kan eller kanske inte är snabbt, beroende på situationen.

Och det andra sättet att differentiera är att dela upp antalet förfrågningar i denna grupp. I den andra kolumnen kommer du alltid att ha en fråga uppdelad per fråga. Och då är det intressant - hur många millisekunder var det i denna begäran. Vi vet hur den här frågan beter sig i genomsnitt. 101 millisekunder krävdes för varje begäran. Detta är den traditionella måtten vi behöver förstå.

Hur många rader returnerade varje fråga i genomsnitt? Vi ser 8 denna grupp återvänder. I genomsnitt hur mycket som togs från cachen och lästes. Vi ser att allt är cachat fint. Solida träffar för den första gruppen.

Och den fjärde delsträngen i varje rad är hur stor procentandel av totalen. Vi har samtal. Låt oss säga 1 000 000. Och vi kan förstå vilket bidrag den här gruppen ger. Vi ser att i detta fall bidrar den första gruppen med mindre än 0,01 %. Det vill säga att det går så långsamt att vi inte ser det i helhetsbilden. Och den andra gruppen har 5 % på samtal. Det vill säga 5 % av alla samtal är den andra gruppen.

Total_time är också intressant. Vi spenderade 14 % av vår totala arbetstid på den första gruppen av förfrågningar. Och för den andra - 11%, etc.

Jag går inte in på detaljer, men det finns finesser där. Vi visar ett fel högst upp, för när vi jämför kan ögonblicksbilder flyta, det vill säga vissa förfrågningar kan falla ut och kan inte längre finnas i den andra, medan några nya kan dyka upp. Och där räknar vi felet. Om du ser 0 så är det bra. Det finns inga fel. Om felfrekvensen är upp till 20 % är det OK.

Sedan återgår vi till vårt ämne. Vi måste skapa arbetsbördan. Vi tar det från topp till botten och går tills vi når 80% eller 90%. Vanligtvis är detta 10-20 grupper. Och vi gör filer för pgbench. Vi använder random där. Ibland går detta tyvärr inte. Och i Postgres 12 kommer det att finnas fler möjligheter att använda detta tillvägagångssätt.

Och då vinner vi 80-90% i total_time på detta sätt. Vad ska jag sätta efter "@"? Vi tittar på samtalen, tittar på hur stort intresse det är och förstår att vi är skyldiga så mycket intresse här. Från dessa procentsatser kan vi förstå hur man balanserar var och en av filerna. Efter det använder vi pgbench och går till jobbet.

Vi har även K001 och K002.

K001 är en stor sträng med fyra delsträngar. Detta är ett kännetecken för hela vår last. Se andra kolumnen och andra underraden. Vi ser att ungefär en och en halv sekund per sekund, d.v.s. om det finns två kärnor, så blir det bra. Det kommer att finnas cirka 75 % kapacitet. Och det kommer att fungera så här. Om vi ​​har 10 kärnor, kommer vi generellt att vara lugna. På så sätt kan vi utvärdera resurser.

K002 är vad jag kallar frågeklasser, dvs SELECT, INSERT, UPDATE, DELETE. Och separat VÄLJ FÖR UPPDATERING, eftersom det är ett lås.

Och här kan vi dra slutsatsen att SELECT är vanliga läsare - 82% av alla samtal, men samtidigt - 74% i total_time. Det vill säga, de kallas mycket, men förbrukar mindre resurser.

Och vi återgår till frågan: "Hur kan vi välja rätt shared_buffers?" Jag observerar att de flesta riktmärken är baserade på idén - låt oss se vad genomströmningen blir, d.v.s. vad genomströmningen blir. Det mäts vanligtvis i TPS eller QPS.

Och vi försöker pressa ut så många transaktioner per sekund som möjligt från bilen med hjälp av inställningsparametrar. Här är exakt 311 per sekund för att välja.

Men ingen kör i full fart till jobbet och hem igen. Detta är dumt. Samma sak med databaser. Vi behöver inte köra i full fart, och det gör ingen. Ingen bor i produktionen, som har 100% CPU. Fast kanske någon lever, men det här är inte bra.

Tanken är att vi brukar köra på 20 procent av kapaciteten, helst inte mer än 50 procent. Och vi försöker optimera svarstiden för våra användare framför allt. Det vill säga, vi måste vrida våra rattar så att det finns en minsta latens vid 20 % hastighet, villkorligt. Detta är en idé som vi också försöker använda i våra experiment.

Och slutligen, rekommendationer:

• Var noga med att göra Databas Lab.
• Om möjligt, gör det på begäran så att det vecklas ut ett tag – lek och släng det. Om du har moln, då är detta självklart, d.v.s. har mycket stående.
• Var nyfiken. Och om något är fel, kolla sedan med experiment hur det beter sig. Nancy kan användas för att träna dig själv för att kontrollera hur basen fungerar.
• Och sträva efter minsta svarstid.
• Och var inte rädd för Postgres källor. När du arbetar med källor måste du kunna engelska. Det är många kommentarer där, allt förklaras där.
• Och kontrollera databasens hälsa regelbundet, minst en gång var tredje månad, manuellt eller Postgres-checkup.

frågor

Tack så mycket! En mycket intressant sak.

Två bitar.

Ja, två stycken. Bara jag förstod inte riktigt. När Nancy och jag jobbar, kan vi justera bara en parameter eller en hel grupp?

Vi har en deltakonfigurationsparameter. Du kan vända dit hur mycket du vill på en gång. Men du måste förstå att när du ändrar många saker kan du dra fel slutsatser.

Ja. Varför frågade jag? För det är svårt att genomföra experiment när man bara har en parameter. Du drar åt det, se hur det fungerar. Jag satte ut honom. Sedan börjar du nästa.

Man kan dra åt samtidigt, men det beror på situationen såklart. Men det är bättre att testa en idé. Vi fick en idé igår. Vi hade en väldigt nära situation. Det fanns två konfigurationer. Och vi kunde inte förstå varför det var stor skillnad. Och idén uppstod att man måste använda dikotomi för att konsekvent förstå och hitta vad skillnaden är. Du kan omedelbart göra hälften av parametrarna lika, sedan en fjärdedel, etc. Allt är flexibelt.

Och det finns en fråga till. Projektet är ungt och utvecklande. Dokumentationen är redan klar, finns det en detaljerad beskrivning?

Jag gjorde specifikt en länk där till beskrivningen av parametrarna. Är det där. Men mycket är inte där än. Jag letar efter likasinnade. Och jag hittar dem när jag uppträder. Det här är väldigt coolt. Någon jobbar redan med mig, någon hjälpte till och gjorde något där. Och om du är intresserad av detta ämne, ge feedback om vad som saknas.

När vi väl bygger laboratoriet kanske det kommer återkoppling. Låt oss se. Tack!

Hallå! Tack för rapporten! Jag såg att det finns stöd för Amazon. Finns det några planer på att stödja GSP?

Bra fråga. Vi började göra det. Och vi frös det för nu eftersom vi vill spara pengar. Det vill säga att det finns stöd för att köra på localhost. Du kan skapa en instans själv och arbeta lokalt. Det är förresten vad vi gör. Jag gör det här på Getlab, där på GSP. Men vi ser inte poängen med att göra just en sådan orkestrering ännu, eftersom Google inte har billiga platser. Det finns ??? fall, men de har begränsningar. För det första har de alltid bara 70 % rabatt och du kan inte spela med priset där. På spots höjer vi priset med 5-10% för att minska sannolikheten att du blir sparkad. Det vill säga du sparar fläckar, men de kan tas ifrån dig när som helst. Om du bjuder lite högre än vad andra gör, kommer du att dödas senare. Google har helt andra detaljer. Och det finns en annan mycket dålig begränsning - de lever bara i 24 timmar. Och ibland vill vi köra ett experiment i 5 dagar. Men du kan göra detta på fläckar, fläckar varar ibland i månader.

Hallå! Tack för rapporten! Du nämnde kontroll. Hur beräknar man stat_statements-fel?

Mycket bra fråga. Jag kan visa och berätta i detalj. Kortfattat tittar vi på hur uppsättningen av förfrågningsgrupper har flutit: hur många har fallit av och hur många nya som har dykt upp. Och sedan tittar vi på två mätvärden: total_time och calls, så det finns två fel. Och vi tittar på de flytande gruppernas bidrag. Det finns två undergrupper: de som lämnade och de som kom. Låt oss se vad deras bidrag är till helhetsbilden.

Är du inte rädd att den ska vända dit två eller tre gånger under tiden mellan ögonblicksbilderna?

Dvs registrerade de sig igen eller vad?

Till exempel har denna begäran redan förhandsregistrerats en gång, sedan kom den och förköptes igen, sedan kom den igen och förköptes igen. Och du räknade ut något här, och var är allt?

Bra fråga, vi får titta.

Jag gjorde en liknande sak. Det var enklare såklart, jag gjorde det ensam. Men jag var tvungen att återställa, återställa stat_statements och ta reda på vid tidpunkten för ögonblicksbilden att det fanns mindre än en viss bråkdel, som fortfarande inte nådde taket för hur mycket stat_statements kunde ackumuleras där. Och min uppfattning är att, med största sannolikhet, ingenting fördrevs.

Jaja.

Men jag förstår inte hur man annars ska göra det på ett tillförlitligt sätt.

Tyvärr kommer jag inte ihåg exakt om vi använder frågetexten där eller queryid med pg_stat_statements och fokuserar på det. Om vi ​​fokuserar på queryid, så jämför vi i teorin jämförbara saker.

Nej, han kan tvingas ut flera gånger mellan ögonblicksbilderna och komma igen.

Med samma id?

Ja.

Vi ska studera detta. Bra fråga. Vi måste studera det. Men för tillfället skrivs det vi ser antingen 0...

Detta är naturligtvis ett sällsynt fall, men jag blev chockad när jag fick reda på att stat_statemetns kan förskjuta dit.

Det kan finnas många saker i Pg_stat_statements. Vi stötte på det faktum att om du har track_utility = på så spåras även dina set.

Ja visst.

Och om du har java hibernate, vilket är slumpmässigt, så börjar hashtabellen finnas där. Och så fort du stänger av en väldigt laddad applikation hamnar du på 50-100 grupper. Och allt är mer eller mindre stabilt där. Ett sätt att bekämpa detta är att öka pg_stat_statements.max.

Ja, men du måste veta hur mycket. Och på något sätt måste vi hålla ett öga på honom. Det är vad jag gör. Det vill säga jag har pg_stat_statements.max. Och jag ser att jag vid ögonblicksbilden inte hade nått 70%. Okej, så vi har inte förlorat något. Låt oss återställa. Och vi sparar igen. Om nästa ögonblicksbild är mindre än 70, har du troligen inte förlorat något igen.

Ja. Standardinställningen är nu 5 000. Och detta räcker för många.

Vanligtvis ja.

videor:

PS För min egen räkning vill jag tillägga att om Postgres innehåller konfidentiell data och den inte kan inkluderas i testmiljön, så kan du använda PostgreSQL Anonymizer. Schemat är ungefär som följer:

Källa: will.com