Syntes som en av metoderna för att förbättra prestandan hos PostgreSQL

Filosofisk introduktion

Som bekant finns det endast två metoder för att lösa problem:

1. Analysmetoden eller deduktiv metod, eller från det allmänna till det specifika.
2. Syntesmetoden eller induktiv metod, eller från det speciella till det allmänna.

För att lösa problemet "förbättra databasens prestanda" kan det se ut så här.

Analys — vi analyserar problemet i olika delar och försöker förbättra databasens prestanda som helhet.

I praktiken ser analysen ut ungefär så här:

• Ett problem uppstår (prestandahändelse)
• Vi samlar in statistisk information om databasens status
• Vi letar efter flaskhalsar
• Vi löser problemen med flaskhalsarna

Flaskhalsar i databasen — infrastruktur (CPU, minne, diskar, nätverk, OS), inställningar (postgresql.conf), frågor:

Infrastruktur: möjligheterna till påverkan och förändring för ingenjören är nästan noll.

Databasinställningar: möjligheterna till förändringar är något större än i föregående fall, men som regel fortfarande ganska besvärliga, särskilt i molnet.

Förfrågningar till databasen: den enda möjligheten för manövrerande.

Syntes — vi förbättrar prestandan hos enskilda delar, i förväntan att databasens prestanda som helhet förbättras.

Lyrisk introduktion eller varför allt detta är nödvändigt

Hur processen för att lösa prestandahändelser går till, om databasens prestanda inte övervakas:

Kunden - "vi har det dåligt, långsamt, gör oss bra"
Ingenjören - "vad är dåligt?"
Kunden - "så här är det nu (för en timme sedan, igår, förra gången), långsamt"
Ingenjören - "och när var det bra?"
Kunden - "för en vecka (två veckor) sedan var det inte illa." (Det var tur)
Kunden - "och jag minns inte när det var bra, men nu är det dåligt" (Vanligt svar)

Resultatet blir en klassisk bild:

Vem är skyldig och vad ska göras?

Det är lättast att svara på den första delen av frågan — DBA-ingenjören är alltid skyldig.

Det är inte heller alltför svårt att svara på den andra delen — en övervakningssystem för databasens prestanda måste implementeras.

Det uppstår en första fråga — vad ska övervakas?

Väg 1. Vi ska övervaka ALLT

CPU-belastning, antal diskoperationer (läs/skriv), storleken på det tilldelade minnet, och en mängd olika statistiska mått som vilket mer eller mindre fungerande övervakningssystem kan tillhandahålla.

Resultatet blir en massa grafer, sammanställningar och kontinuerliga notifikationer via e-post, vilket gör att ingenjören alltid är upptagen med att hantera en mängd likadana ärenden, ofta med en standardformulering – "Temporary issue. No action need". Åtminstone är alla upptagna, och det finns alltid något att visa för kunden – arbetet pågår.

Väg 2. Övervaka endast det som är nödvändigt, och det som inte behövs, ska inte övervakas

Det går att övervaka, lite annorlunda — bara enheter och händelser:

• Som ingenjör DBA kan påverka
• För vilka det finns en handlingsplan vid uppkomsten av en händelse eller ändring av en enhet.

Utifrån den här förutsättningen och med tanke på "Filosofisk introduktion" för att undvika regelbundet återkommande "Lyrisk introduktion eller varför allt detta är nödvändigt" kan det vara fördelaktigt att övervaka prestanda för specifika frågor, för att optimera och analysera, vilket i slutändan bör leda till en förbättring av hela databasens prestanda.

Men för att förbättra en tung fråga som påverkar databasens totala prestanda, måste man först hitta den.

Så, två relaterade frågor uppstår:

• vilken fråga betraktas som tung
• hur man söker efter tunga frågor.

Uppenbarligen är en tung fråga en fråga som använder mycket av systemresurserna för att få ett resultat.

Vi går vidare till den andra frågan – hur man söker och sedan övervakar tunga frågor?

Vilka möjligheter för övervakning av frågor finns det i PostgreSQL?

Jämfört med Oracle finns det inte många möjligheter, men det går fortfarande att göra en del.

PG_STAT_STATEMENTS

För att hitta och övervaka tunga frågor i PostgreSQL är det standardutvidgningen pg_stat_statements avsedd.

Efter installationen av utvidgningen, dyker det upp en visning med samma namn i den mål-databasen, som behövs för övervakning.

Målcellerna pg_stat_statements för att bygga ett övervakningssystem:

• queryid Inre hash-kod beräknad utifrån operatorns syntaxträd
• max_time Maximal tid som spenderas på operatorn, i millisekunder

Genom att samla in och använda statistik från dessa två kolumner kan ett övervakningssystem byggas.

Hur pg_stat_statements används för att övervaka PostgreSQL:s prestanda

För att övervaka prestandan av frågor används:
På sidan av måldatabasen – vy pg_stat_statements
Från sidan servern och övervakningsdatabasen – en uppsättning bash-skript och servicetabeller.

Steg 1 — insamling av statistiska data

På övervakningsservern körs regelbundet ett skript via cron som kopierar innehållet i vyerna pg_stat_statements från måldatabasen till tabellen pg_stat_history i övervakningsdatabasen.

På så sätt skapas en historik över utförandet av enskilda frågor, vilken kan användas för att skapa prestandarapporter och justera mätvärden.

Steg 2 — inställning av prestandamätningar

Baserat på de insamlade uppgifterna väljer vi ut de frågor vars utförande är mest kritiska/viktiga för kunden (applikationen). I samförstånd med beställaren fastställer vi värdena för prestandamätningarna med hjälp av fälten queryid och max_time.

Resultatet — start av prestandaövervakning

1. Övervakningsskriptet kontrollerar de konfigurerade prestandamätningarna vid start, genom att jämföra värdet max_time för mätningen med värdet från vyerna pg_stat_statements i måldatabasen.
2. Om värdet i måldatabasen överstiger mätvärdet – genereras en varning (incident i ärendehanteringssystemet)

Ytterligare möjlighet 1

Historik över exekveringsplaner för frågor

För att lösa prestandaincidenter är det mycket användbart att ha en historik över förändringar i exekveringsplanerna för frågor.

För att lagra historiken används en service-tabell log_query. Tabellens fylls vid analysen av den laddade loggfilen från PostgreSQL. Eftersom loggfilen, till skillnad från vyerna pg_stat_statements, innehåller den fullständiga texten med värdena för körningsparametrarna, istället för normaliserad text, finns det möjlighet att registrera inte bara tid och varaktighet för frågor, utan också spara exekveringsplaner vid den aktuella tidpunkten.

Ytterligare möjlighet 2

Kontinuerlig process för prestandaförbättring

Övervakning av enskilda frågor är i allmänhet inte avsedd för att lösa problemet med ständig förbättring av databasens prestanda som helhet, eftersom den kontrollerar och löser prestandaärenden endast för enskilda frågor. Men metoden kan utvidgas och övervakningen kan anpassas för alla databaser.

För detta behöver vi införa ytterligare prestandamätningar:

• Under de senaste dagarna
• För grundperioden

Skriptet väljer frågor från visningen pg_stat_statements i databasen och jämför värdet av max_time med det genomsnittliga värdet av max_time, i det första fallet under de senaste dagarna eller under en vald tidsperiod (baseline), i det andra fallet.

Således kommer en varning automatiskt att genereras vid prestandaförsämring för vilken fråga som helst, utan manuell analys av rapporter.

Vad har syntes med detta att göra?

I den beskrivna metoden, som antas av syntesmetoden - genom att förbättra individuella delar av systemet, förbättrar vi systemet som helhet.

• Frågan som databasen utför - tes
• Den ändrade frågan - antites
• Ändring av systemets tillstånd - syntes

Utveckling av systemet

• Uppbyggnad av insamlad statistik genom att lägga till historik för systemvisningen pg_stat_activity
• Utökning av insamlad statistik genom att lägga till historik för statistiken för specifika tabeller som deltar i frågorna
• Integration med övervakningssystemet i molnet AWS
• Och något mer kan vi komma på...

Källa: habr.com