Grunderna i PostgreSQL-övervakning. Alexey Lesovsky

Jag föreslår att du läser utskriften av rapporten av Alexey Lesovsky från Data Egret "Fundamentals of PostgreSQL monitoring"

I den här rapporten kommer Alexey Lesovsky att prata om nyckelpunkterna i statistik efter konferens, vad de betyder och varför de bör vara närvarande i övervakningen; om vilka grafer som ska finnas i övervakningen, hur man lägger till dem och hur man tolkar dem. Rapporten kommer att vara användbar för databasadministratörer, systemadministratörer och utvecklare som är intresserade av Postgres felsökning.

Jag heter Alexey Lesovsky, jag representerar företaget Data Egret.

Några ord om mig själv. Jag började för länge sedan som systemadministratör.

Jag administrerade alla möjliga olika Linuxsystem, jobbade med olika saker relaterat till Linux, d.v.s virtualisering, övervakning, jobbade med proxyer etc. Men någon gång började jag jobba mer med databaser, PostgreSQL. Jag gillade honom verkligen. Och någon gång började jag jobba på PostgreSQL större delen av min arbetstid. Och så gradvis blev jag en PostgreSQL DBA.

Och under hela min karriär har jag alltid varit intresserad av ämnena statistik, övervakning och telemetri. Och när jag var systemadministratör arbetade jag väldigt nära Zabbix. Och jag skrev en liten uppsättning manus som zabbix-förlängningar. Han var ganska populär på sin tid. Och där var det möjligt att övervaka väldigt olika viktiga saker, inte bara Linux, utan även olika komponenter.

Nu jobbar jag på PostgreSQL. Jag skriver redan en annan sak som gör att du kan arbeta med PostgreSQL-statistik. Det kallas pgCenter (artikel om Habré - Post-gress statistik utan nerver och spänningar).

En liten introduktion. Vilka situationer har våra kunder, våra kunder? Det är någon sorts olycka relaterad till databasen. Och när databasen redan har återställts kommer avdelningschefen eller utvecklingschefen och säger: "Vänner, vi måste övervaka databasen, för något dåligt har hänt och vi måste förhindra att detta händer i framtiden." Och här börjar den intressanta processen med att välja ett övervakningssystem eller anpassa ett befintligt övervakningssystem så att du kan övervaka din databas - PostgreSQL, MySQL eller några andra. Och kollegor börjar föreslå: ”Jag hörde att det finns en sådan och en databas. Låt oss använda det." Kollegor börjar bråka med varandra. Och till slut visar det sig att vi väljer någon form av databas, men PostgreSQL-övervakning presenteras i den ganska dåligt och vi måste alltid lägga till något. Ta några arkiv från GitHub, klona dem, anpassa skript och anpassa dem på något sätt. Och i slutändan blir det något slags manuellt arbete.

Därför ska jag i det här föredraget försöka ge dig lite kunskap om hur du väljer övervakning inte bara för PostgreSQL, utan även för databasen. Och ge dig kunskapen som gör att du kan slutföra din övervakning för att få lite nytta av den, så att du kan övervaka din databas med fördel, för att snabbt förhindra kommande nödsituationer som kan uppstå.

Och idéerna som kommer att finnas i denna rapport kan direkt anpassas till vilken databas som helst, oavsett om det är en DBMS eller noSQL. Därför finns det inte bara PostgreSQL, utan det kommer att finnas många recept på hur man gör detta i PostgreSQL. Det kommer att finnas exempel på frågor, exempel på enheter som PostgreSQL har för övervakning. Och om ditt DBMS har samma saker som gör att du kan lägga dem i övervakning kan du även anpassa dem, lägga till dem så blir det bra.

Jag kommer inte att vara med i rapporten
prata om hur man levererar och lagrar mätvärden. Jag kommer inte att säga något om att efterbehandla uppgifterna och presentera dem för användaren. Och jag kommer inte att säga något om att varna.
Men allt eftersom historien fortskrider kommer jag att visa olika skärmdumpar av befintlig övervakning och på något sätt kritisera dem. Men ändå kommer jag att försöka att inte namnge varumärken för att inte skapa reklam eller antireklam för dessa produkter. Därför är alla tillfälligheter slumpmässiga och lämnas till din fantasi.

Låt oss först ta reda på vad övervakning är. Övervakning är en mycket viktig sak att ha. Alla förstår detta. Men samtidigt hänför sig övervakningen inte till en affärsprodukt och påverkar inte direkt företagets vinst, så det avsätts alltid tid till övervakning på restbasis. Om vi ​​har tid, så gör vi övervakning; om vi inte har tid, då OK, vi lägger det i eftersläpningen och en dag kommer vi att återgå till dessa uppgifter.

Därför, från vår praxis, när vi kommer till kunder, är övervakningen ofta ofullständig och har inga intressanta saker som skulle hjälpa oss att göra ett bättre jobb med databasen. Och därför måste övervakningen alltid slutföras.

Databaser är så komplexa saker som också måste övervakas, eftersom databaser är ett arkiv med information. Och information är väldigt viktig för företaget, den kan inte gå förlorad på något sätt. Men samtidigt är databaser mycket komplexa programvaror. De består av ett stort antal komponenter. Och många av dessa komponenter måste övervakas.

Om vi ​​pratar specifikt om PostgreSQL, så kan det representeras i form av ett schema som består av ett stort antal komponenter. Dessa komponenter interagerar med varandra. Och samtidigt har PostgreSQL det så kallade Stats Collector-undersystemet, vilket gör att du kan samla in statistik om driften av dessa undersystem och tillhandahålla någon form av gränssnitt till administratören eller användaren så att denne kan se denna statistik.

Denna statistik presenteras i form av en viss uppsättning funktioner och vyer. De kan också kallas tabeller. Det vill säga, med en vanlig psql-klient kan du ansluta till databasen, göra ett urval av dessa funktioner och vyer och få några specifika siffror om hur PostgreSQL-delsystemen fungerar.

Du kan lägga till dessa siffror i ditt favoritövervakningssystem, rita grafer, lägga till funktioner och få analyser på lång sikt.

Men i denna rapport kommer jag inte att täcka alla dessa funktioner helt, eftersom det kan ta hela dagen. Jag kommer bokstavligen att ta upp två, tre eller fyra saker och berätta hur de hjälper till att göra övervakningen bättre.

Och om vi pratar om databasövervakning, vad behöver då övervakas? Först och främst måste vi övervaka tillgängligheten, eftersom databasen är en tjänst som ger tillgång till data till kunder och vi måste övervaka tillgängligheten, och även tillhandahålla några av dess kvalitativa och kvantitativa egenskaper.

Vi behöver också övervaka klienter som ansluter till vår databas, eftersom de kan vara både normala klienter och skadliga klienter som kan skada databasen. De måste också övervakas och deras aktiviteter spåras.

När klienter ansluter till databasen är det uppenbart att de börjar arbeta med vår data, så vi måste övervaka hur klienter arbetar med datan: med vilka tabeller, och i mindre utsträckning, med vilka index. Det vill säga att vi behöver utvärdera den arbetsbelastning som skapas av våra kunder.

Men arbetsbelastningen består naturligtvis också av förfrågningar. Applikationer ansluter till databasen, får tillgång till data med hjälp av frågor, så det är viktigt att utvärdera vilka frågor vi har i databasen, övervaka deras adekvans, att de inte är snett skrivna, att vissa alternativ behöver skrivas om och göras så att de fungerar snabbare och med bättre prestanda.

Och eftersom vi pratar om en databas är databasen alltid bakgrundsprocesser. Bakgrundsprocesser hjälper till att hålla databasens prestanda på en bra nivå, så de kräver en viss mängd resurser för att de ska kunna fungera. Och samtidigt kan de överlappa med resurser för klientförfrågningar, så giriga bakgrundsprocesser kan direkt påverka prestanda för klientförfrågningar. Därför behöver de också övervakas och spåras så att det inte finns några snedvridningar vad gäller bakgrundsprocesser.

Och allt detta när det gäller databasövervakning finns kvar i systemmåttet. Men med tanke på att det mesta av vår infrastruktur flyttas till molnen, tonas alltid systemmåtten för en enskild värd in i bakgrunden. Men i databaser är de fortfarande relevanta och det är naturligtvis också nödvändigt att övervaka systemmått.

Allt är mer eller mindre bra med systemmått, alla moderna övervakningssystem stödjer redan dessa mätvärden, men generellt sett räcker det fortfarande inte till med vissa komponenter och vissa saker måste läggas till. Jag kommer också att beröra dem, det kommer att finnas flera bilder om dem.

Planens första punkt är tillgänglighet. Vad är tillgänglighet? Tillgänglighet enligt min uppfattning är basens förmåga att betjäna anslutningar, dvs basen höjs, den, som en tjänst, accepterar anslutningar från klienter. Och denna tillgänglighet kan bedömas av vissa egenskaper. Det är mycket bekvämt att visa dessa egenskaper på instrumentpaneler.

Alla vet vad instrumentpaneler är. Det var då du tog en titt på skärmen där den nödvändiga informationen sammanfattas. Och du kan omedelbart avgöra om det finns ett problem i databasen eller inte.
Tillgängligheten av databasen och andra nyckelegenskaper bör därför alltid visas på instrumentpaneler så att denna information finns till hands och alltid tillgänglig för dig. Några ytterligare detaljer som redan hjälper till vid undersökningen av incidenter, när man undersöker vissa nödsituationer, de måste redan placeras på sekundära instrumentpaneler, eller gömmas i drilldown-länkar som leder till tredje parts övervakningssystem.

Ett exempel på ett välkänt övervakningssystem. Detta är ett väldigt coolt övervakningssystem. Hon samlar in mycket data, men ur min synvinkel har hon ett konstigt koncept med instrumentpaneler. Det finns en länk för att "skapa en instrumentpanel". Men när du skapar en instrumentpanel skapar du en lista med två kolumner, en lista med grafer. Och när du behöver titta på något börjar du klicka med musen, rulla, leta efter önskat diagram. Och detta tar tid, det vill säga det finns inga instrumentpaneler som sådana. Det finns bara listor med diagram.

Vad ska du lägga till i dessa instrumentpaneler? Du kan börja med en sådan egenskap som svarstid. PostgreSQL har vyn pg_stat_statements. Det är inaktiverat som standard, men det är en av de viktiga systemvyerna som alltid bör aktiveras och användas. Den lagrar information om alla pågående frågor som har körts i databasen.

Följaktligen kan vi utgå från det faktum att vi kan ta den totala exekveringstiden för alla förfrågningar och dividera den med antalet förfrågningar med hjälp av ovanstående fält. Men det här är medeltemperaturen på sjukhuset. Vi kan utgå från andra fält - minsta frågekörningstid, maximum och median. Och vi kan till och med bygga percentiler, PostgreSQL har motsvarande funktioner för detta. Och vi kan få några siffror som kännetecknar svarstiden för vår databas för redan genomförda förfrågningar, d.v.s. vi kör inte den falska förfrågan 'välj 1' och tittar på svarstiden, utan vi analyserar svarstiden för redan genomförda förfrågningar och drar. antingen en separat figur, eller så bygger vi en graf utifrån den.

Det är också viktigt att övervaka antalet fel som för närvarande genereras av systemet. Och för detta kan du använda vyn pg_stat_database. Vi fokuserar på fältet xact_rollback. Det här fältet visar inte bara antalet återställningar som sker i databasen, utan tar även hänsyn till antalet fel. Relativt sett kan vi visa den här siffran i vår instrumentpanel och se hur många fel vi har för närvarande. Om det är många fel så är detta en bra anledning att titta i loggarna och se vad det är för fel och varför de uppstår, och sedan investera och lösa dem.

Du kan lägga till en sådan sak som en varvräknare. Dessa är antalet transaktioner per sekund och antalet förfrågningar per sekund. Relativt sett kan du använda dessa siffror som den aktuella prestandan för din databas och observera om det finns toppar i förfrågningar, toppar i transaktioner, eller omvänt, om databasen är underbelastad på grund av att någon backend har misslyckats. Det är viktigt att alltid titta på den här siffran och komma ihåg att för vårt projekt är den här typen av prestanda normal, men värdena ovan och nedan är redan något slags problematisk och obegriplig, vilket innebär att vi måste titta på varför dessa siffror är så hög.

För att uppskatta antalet transaktioner kan vi återigen hänvisa till vyn pg_stat_database. Vi kan lägga till antalet commits och antalet rollbacks och få antalet transaktioner per sekund.

Förstår alla att flera förfrågningar kan passa in i en transaktion? Därför är TPS och QPS något olika.

Antalet förfrågningar per sekund kan erhållas från pg_stat_statements och beräkna helt enkelt summan av alla avslutade förfrågningar. Det är tydligt att vi jämför det aktuella värdet med det föregående, subtraherar det, får deltat och får kvantiteten.

Du kan lägga till ytterligare mätvärden om så önskas, som också hjälper till att utvärdera tillgängligheten för vår databas och övervaka om det har förekommit några driftstopp.

En av dessa mätvärden är drifttid. Men upptid i PostgreSQL är lite knepigt. Jag ska berätta varför. När PostgreSQL har startat börjar drifttiden rapporteras. Men om någon gång, till exempel, någon uppgift pågick på natten, en OOM-mördare kom och tvångsavbröt PostgreSQL-underprocessen, så avslutar PostgreSQL i det här fallet anslutningen för alla klienter, återställer det sönderdelade minnesområdet och börjar återhämta sig från den sista checkpointen. Och medan denna återhämtning från kontrollpunkten varar, accepterar databasen inte anslutningar, det vill säga denna situation kan bedömas som driftstopp. Men upptidsräknaren kommer inte att återställas, eftersom den tar hänsyn till postmasterns starttid från första stund. Därför kan sådana situationer hoppas över.

Du bör också övervaka antalet vakuumarbetare. Vet alla vad autovacuum är i PostgreSQL? Detta är ett intressant delsystem i PostgreSQL. Det har skrivits många artiklar om henne, många rapporter har gjorts. Det diskuteras mycket om vakuum och hur det ska fungera. Många anser att det är ett nödvändigt ont. Men det är så det är. Detta är en sorts analog till en sophämtare som rensar föråldrade versioner av rader som inte behövs för någon transaktion och frigör utrymme i tabeller och index för nya rader.

Varför behöver du övervaka det? Eftersom vakuumet ibland gör väldigt ont. Det förbrukar en stor mängd resurser och kundförfrågningar börjar bli lidande som ett resultat.

Och det bör övervakas genom vyn pg_stat_activity, som jag kommer att prata om i nästa avsnitt. Denna vy visar den aktuella aktiviteten i databasen. Och genom denna aktivitet kan vi spåra antalet dammsugare som fungerar just nu. Vi kan spåra vakuum och se att om vi har överskridit gränsen så är detta en anledning att titta på PostgreSQL-inställningarna och på något sätt optimera driften av vakuumet.

En annan sak med PostgreSQL är att PostgreSQL är väldigt trött på långa transaktioner. Särskilt från transaktioner som hänger kvar länge och inte gör någonting. Detta är den så kallade stat idle-in-transaction. En sådan transaktion håller lås och hindrar vakuumet från att fungera. Och som ett resultat sväller borden och ökar i storlek. Och frågor som fungerar med dessa tabeller börjar arbeta långsammare, eftersom du måste skyffla alla gamla versioner av rader från minne till disk och tillbaka. Därför måste tiden, varaktigheten för de längsta transaktionerna, de längsta vakuumförfrågningarna också övervakas. Och om vi ser några processer som har körts under mycket lång tid, redan mer än 10-20-30 minuter för en OLTP-belastning, måste vi vara uppmärksamma på dem och kraftfullt avsluta dem, eller optimera applikationen så att de kallas inte och hänger inte så länge. För en analytisk arbetsbelastning är 10-20-30 minuter normalt, det finns också längre.

Därefter har vi alternativet med anslutna klienter. När vi redan har skapat en instrumentpanel och lagt upp viktiga tillgänglighetsstatistik på den, kan vi även lägga till ytterligare information om anslutna klienter där.

Information om anslutna klienter är viktig eftersom klienter är olika ur ett PostgreSQL-perspektiv. Det finns bra kunder och det finns dåliga kunder.

Ett enkelt exempel. Av klient förstår jag applikationen. Applikationen har anslutit till databasen och börjar omedelbart skicka sina förfrågningar dit, databasen bearbetar och exekverar dem och returnerar resultaten till klienten. Det är bra och korrekta kunder.

Det finns situationer när klienten har anslutit, den håller i anslutningen, men gör ingenting. Den är i viloläge.

Men det finns dåliga kunder. Till exempel kopplade samma klient upp, öppnade en transaktion, gjorde något i databasen och gick sedan in i koden, till exempel för att komma åt en extern källa eller för att bearbeta mottagna data där. Men han avslutade inte transaktionen. Och transaktionen hänger i databasen och hålls i ett lås på linjen. Detta är ett dåligt tillstånd. Och om plötsligt en ansökan någonstans inom sig misslyckas med ett undantag, kan transaktionen förbli öppen under mycket lång tid. Och detta påverkar direkt PostgreSQL-prestanda. PostgreSQL kommer att vara långsammare. Därför är det viktigt att spåra sådana kunder i tid och med kraft avsluta deras arbete. Och du måste optimera din applikation så att sådana situationer inte uppstår.

Andra dåliga kunder är väntande kunder. Men de blir dåliga på grund av omständigheterna. Till exempel, en enkel inaktiv transaktion: den kan öppna en transaktion, ta lås på vissa rader, sedan någonstans i koden kommer den att misslyckas, vilket lämnar en hängande transaktion. En annan klient kommer och begär samma data, men han kommer att stöta på ett lås, eftersom den hängande transaktionen redan har lås på vissa obligatoriska rader. Och den andra transaktionen kommer att hänga kvar och vänta på att den första transaktionen ska slutföras eller tvångsstänga den av administratören. Därför kan väntande transaktioner ackumuleras och fylla databasanslutningsgränsen. Och när gränsen är full kan applikationen inte längre fungera med databasen. Detta är redan en nödsituation för projektet. Därför måste dåliga kunder spåras och bemötas i tid.

Ytterligare ett exempel på övervakning. Och det finns redan en anständig instrumentpanel här. Det finns information om anslutningar ovan. DB-anslutning – 8 st. Och det är allt. Vi har ingen information om vilka klienter som är aktiva, vilka klienter som bara är lediga och inte gör någonting. Det finns ingen information om pågående transaktioner och pågående anslutningar, det vill säga det här är en siffra som visar antalet anslutningar och det är allt. Och sedan gissa själv.

För att lägga till denna information till övervakning måste du följaktligen komma åt systemvyn pg_stat_activity. Om du spenderar mycket tid i PostgreSQL, så är detta en mycket bra vy som borde bli din vän, eftersom den visar den aktuella aktiviteten i PostgreSQL, dvs vad som händer i den. För varje process finns det en separat rad som visar information om denna process: från vilken värd anslutningen gjordes, under vilken användare, under vilket namn, när transaktionen startades, vilken begäran som körs för närvarande, vilken begäran som senast utfördes. Och följaktligen kan vi utvärdera klientens tillstånd med hjälp av statfältet. Relativt sett kan vi gruppera efter detta fält och få den statistik som för närvarande finns i databasen och antalet anslutningar som har denna statistik i databasen. Och vi kan skicka de redan mottagna siffrorna till vår övervakning och rita grafer utifrån dem.
Det är också viktigt att utvärdera transaktionens varaktighet. Jag har redan sagt att det är viktigt att utvärdera varaktigheten av vakuum, men transaktioner utvärderas på samma sätt. Det finns fälten xact_start och query_start. De, relativt sett, visar starttiden för transaktionen och starttiden för begäran. Vi tar funktionen now(), som visar den aktuella tidsstämpeln, och subtraherar transaktionen och begär tidsstämpel. Och vi får transaktionens varaktighet, varaktigheten för begäran.

Om vi ​​ser långa transaktioner bör vi slutföra dem redan. För en OLTP-laddning är långa transaktioner redan mer än 1-2-3 minuter. För en OLAP-arbetsbelastning är långa transaktioner normalt, men om de tar mer än två timmar att slutföra är detta också ett tecken på att vi har en skevhet någonstans.

När kunderna har anslutit sig till databasen börjar de arbeta med vår data. De kommer åt tabeller, de kommer åt index för att få data från tabellen. Och det är viktigt att utvärdera hur kunder interagerar med denna data.

Detta är nödvändigt för att kunna utvärdera vår arbetsbelastning och ungefär förstå vilka tabeller som är de "hetaste" för oss. Detta behövs till exempel i situationer där vi vill placera "heta" bord på någon form av snabb SSD-lagring. Exempelvis kan vissa arkivtabeller som vi inte har använt på länge flyttas till något slags "kallt" arkiv, till SATA-enheter och låta dem bo där, de kommer att nås efter behov.

Detta är också användbart för att upptäcka avvikelser efter eventuella utgåvor och distributioner. Låt oss säga att projektet har släppt någon ny funktion. Till exempel har vi lagt till ny funktionalitet för att arbeta med databasen. Och om vi plottar tabellanvändningsgrafer kan vi enkelt upptäcka dessa anomalier på dessa grafer. Till exempel uppdatera skurar eller ta bort skurar. Det kommer att synas mycket.

Du kan också upptäcka anomalier i "flytande" statistik. Vad betyder det? PostgreSQL har en mycket stark och mycket bra frågeschemaläggare. Och utvecklarna ägnar mycket tid åt dess utveckling. Hur fungerar han? För att göra bra planer samlar PostgreSQL in statistik över distributionen av data i tabeller vid ett visst tidsintervall och med en viss frekvens. Dessa är de vanligaste värdena: antalet unika värden, information om NULL i tabellen, mycket information.

Baserat på denna statistik konstruerar planeraren flera frågor, väljer den mest optimala och använder denna frågeplan för att köra själva frågan och returnera data.

Och det händer att statistiken "flyter". Kvalitets- och kvantitetsdata ändrades på något sätt i tabellen, men statistiken samlades inte in. Och planerna som bildas kanske inte är optimala. Och om våra planer visar sig vara suboptimala baserat på den insamlade övervakningen, baserat på tabellerna, kommer vi att kunna se dessa anomalier. Till exempel någonstans ändrades data kvalitativt och istället för indexet började en sekventiell passage genom tabellen användas, d.v.s. om en fråga endast behöver returnera 100 rader (det finns en gräns på 100), kommer en fullständig sökning att utföras för denna fråga. Och detta har alltid en mycket dålig effekt på prestandan.

Och det kan vi se i övervakningen. Och titta redan på den här frågan, kör en förklara för den, samla in statistik, bygg ett nytt ytterligare index. Och redan svara på detta problem. Det är därför det är viktigt.

Ytterligare ett exempel på övervakning. Jag tror att många kände igen honom för att han är väldigt populär. Som använder det i sina projekt Prometheus? Vem använder denna produkt tillsammans med Prometheus? Faktum är att i standardförrådet för denna övervakning finns en instrumentpanel för att arbeta med PostgreSQL - postgres_exporter Prometheus. Men det finns en dålig detalj.

Det finns flera grafer. Och bytes anges som enhet, det vill säga det finns 5 grafer. Dessa är Infoga data, Uppdatera data, Ta bort data, Hämta data och Returnera data. Enhetsmåttet är byte. Men grejen är att statistik i PostgreSQL returnerar data i tupel (rader). Och följaktligen är dessa grafer ett mycket bra sätt att underskatta din arbetsbelastning flera gånger, tiotals gånger, eftersom en tuppel inte är en byte, en tupel är en sträng, den är många byte och den är alltid av variabel längd. Det vill säga att beräkna arbetsbelastning i byte med hjälp av tupler är en orealistisk uppgift eller mycket svår. Därför, när du använder en instrumentpanel eller inbyggd övervakning, är det alltid viktigt att förstå att det fungerar korrekt och returnerar korrekt bedömd data.

Hur får man statistik på dessa tabeller? För detta ändamål har PostgreSQL en viss familj av åsikter. Och huvudvyn är pg_stat_user_tables. User_tables - detta betyder tabeller skapade på uppdrag av användaren. Däremot finns det systemvyer som används av PostgreSQL själv. Och det finns en sammanfattningstabell Alltables, som inkluderar både system- och användare. Du kan utgå från någon av dem som du gillar bäst.

Med hjälp av ovanstående fält kan du uppskatta antalet infogningar, uppdateringar och borttagningar. Exemplet på en instrumentpanel som jag använde använder dessa fält för att utvärdera egenskaperna hos en arbetsbelastning. Därför kan vi också bygga vidare på dem. Men det är värt att komma ihåg att dessa är tupler, inte byte, så vi kan inte bara göra det i byte.

Baserat på dessa data kan vi bygga så kallade TopN-tabeller. Till exempel Top-5, Top-10. Och du kan spåra de varma borden som återvinns mer än andra. Till exempel 5 "heta" tabeller för insättning. Och med hjälp av dessa TopN-tabeller utvärderar vi vår arbetsbelastning och kan utvärdera skurar av arbetsbelastning efter eventuella releaser, uppdateringar och distributioner.

Det är också viktigt att utvärdera tabellens storlek, eftersom ibland utvecklare rullar ut en ny funktion, och våra tabeller börjar svälla i sina stora storlekar, eftersom de bestämde sig för att lägga till en extra mängd data, men förutspådde inte hur detta skulle påverka storleken på databasen. Sådana fall kommer också som överraskningar för oss.

Och nu en liten fråga till dig. Vilken fråga uppstår när du märker belastningen på din databasserver? Vad är nästa fråga du har?

Men i själva verket uppstår frågan enligt följande. Vilka förfrågningar orsakar belastningen? Det vill säga att det inte är intressant att titta på de processer som orsakas av belastningen. Det är klart att om värden har en databas så kör databasen där och det är klart att endast databaserna kommer att kasseras där. Om vi ​​öppnar Top kommer vi att se en lista över processer i PostgreSQL som gör något. Det kommer inte att framgå av Top vad de gör.

Följaktligen måste du hitta de frågor som orsakar den högsta belastningen, eftersom justering av frågor, som regel, ger mer vinst än att ställa in PostgreSQL- eller operativsystemkonfigurationen, eller till och med ställa in hårdvaran. Enligt min uppskattning är detta cirka 80-85-90%. Och detta görs mycket snabbare. Det är snabbare att korrigera en begäran än att korrigera konfigurationen, schemalägga en omstart, särskilt om databasen inte kan startas om, eller lägga till hårdvara. Det är lättare att skriva om frågan någonstans eller lägga till ett index för att få ett bättre resultat av den här frågan.

Följaktligen är det nödvändigt att övervaka förfrågningar och deras tillräcklighet. Låt oss ta ett annat exempel på övervakning. Och även här verkar det vara utmärkt bevakning. Det finns information om replikering, det finns information om genomströmning, blockering, resursutnyttjande. Allt är bra, men det finns ingen information om förfrågningar. Det är inte klart vilka frågor som körs i vår databas, hur länge de körs, hur många av dessa frågor är. Vi behöver alltid ha denna information i vår övervakning.

Och för att få denna information kan vi använda modulen pg_stat_statements. Baserat på det kan du bygga en mängd olika grafer. Du kan till exempel få information om de vanligaste frågorna, det vill säga om de frågor som körs oftast. Ja, efter implementeringar är det också mycket användbart att titta på det och förstå om det finns någon ökning av förfrågningar.

Du kan övervaka de längsta frågorna, det vill säga de frågor som tar längst tid att slutföra. De körs på processorn, de förbrukar I/O. Vi kan också utvärdera detta med fälten total_time, mean_time, blk_write_time och blk_read_time.

Vi kan utvärdera och övervaka de tyngsta förfrågningarna när det gäller resursanvändning, de som läser från disk, som arbetar med minne, eller, omvänt, skapar någon form av skrivbelastning.

Vi kan utvärdera de mest generösa förfrågningarna. Det här är frågorna som returnerar ett stort antal rader. Det kan till exempel vara någon begäran där de glömt att sätta en gräns. Och det returnerar helt enkelt hela innehållet i tabellen eller frågan över de efterfrågade tabellerna.

Och du kan också övervaka frågor som använder temporära filer eller temporära tabeller.

Och vi har fortfarande bakgrundsprocesser. Bakgrundsprocesser är i första hand checkpoints eller så kallas de också checkpoints, dessa är autovakuum och replikering.

Ytterligare ett exempel på övervakning. Det finns en Underhållsflik till vänster, gå till den och hoppas på något användbart. Men här är bara tiden för vakuumdrift och statistikinsamling, inget mer. Detta är väldigt dålig information, så vi behöver alltid ha information om hur bakgrundsprocesser fungerar i vår databas och om det finns några problem från deras arbete.

När vi tittar på checkpoints bör vi komma ihåg att checkpoints spolar smutsiga sidor från det sönderdelade minnesområdet till disken och sedan skapar en checkpoint. Och denna kontrollpunkt kan sedan användas som en plats för återhämtning om PostgreSQL plötsligt avslutades i en nödsituation.

Följaktligen, för att spola alla "smutsiga" sidor till disken, måste du skriva en viss mängd. Och, som regel, på system med stora mängder minne är detta mycket. Och om vi gör checkpoints väldigt ofta med korta intervaller kommer diskens prestanda att sjunka mycket avsevärt. Och kundförfrågningar kommer att lida av brist på resurser. De kommer att konkurrera om resurser och sakna produktivitet.

Följaktligen kan vi genom pg_stat_bgwriter använda de angivna fälten övervaka antalet kontrollpunkter som uppstår. Och om vi har många kontrollpunkter under en viss tid (på 10-15-20 minuter, på en halvtimme), till exempel 3-4-5, så kan detta redan vara ett problem. Och du behöver redan titta i databasen, titta i konfigurationen, vad som orsakar ett sådant överflöd av kontrollpunkter. Kanske är det någon slags stor inspelning på gång. Vi kan redan utvärdera arbetsbelastningen, eftersom vi redan har lagt till arbetsbelastningsdiagram. Vi kan redan justera kontrollpunktsparametrarna och se till att de inte i stor utsträckning påverkar frågeprestanda.

Jag kommer tillbaka till autovacuum igen eftersom det är en sådan sak, som sagt, som enkelt kan lägga till både disk- och frågeprestanda, så det är alltid viktigt att uppskatta mängden autovacuum.

Antalet autovakuumarbetare i databasen är begränsat. Som standard finns det tre av dem, så om vi alltid har tre arbetare som arbetar i databasen betyder det att vårt autovakuum inte är konfigurerat, vi måste höja gränserna, revidera autovakuuminställningarna och komma in i konfigurationen.
Det är viktigt att utvärdera vilka vakuumarbetare vi har. Antingen lanserades det från användaren, DBA:n kom och startade manuellt någon form av vakuum, och detta skapade en belastning. Vi har något slags problem. Eller så är detta antalet dammsugare som skruvar loss transaktionsräknaren. För vissa versioner av PostgreSQL är dessa mycket tunga dammsugare. Och de kan enkelt lägga ihop prestanda eftersom de läser hela tabellen, skannar alla block i den tabellen.

Och, naturligtvis, varaktigheten av vakuum. Om vi ​​har långvariga dammsugare som går under mycket lång tid, betyder det att vi återigen måste vara uppmärksamma på vakuumkonfigurationen och kanske ompröva dess inställningar. Eftersom en situation kan uppstå när vakuumet arbetar på bordet under en längre tid (3-4 timmar), men under tiden som vakuumet fungerade, lyckades en stor mängd döda rader samlas i bordet igen. Och så fort vakuumet är klart måste han dammsuga det här bordet igen. Och vi kommer till en situation - ett oändligt vakuum. Och i det här fallet klarar inte vakuumet sitt arbete, och tabellerna börjar gradvis svälla i storlek, även om volymen av användbar data i den förblir densamma. Under långa vakuum tittar vi därför alltid på konfigurationen och försöker optimera den, men samtidigt så att prestanda för klientförfrågningar inte blir lidande.

Nuförtiden finns det praktiskt taget ingen PostgreSQL-installation som inte har strömmande replikering. Replikering är processen att flytta data från en master till en replik.

Replikering i PostgreSQL görs genom en transaktionslogg. Guiden genererar en transaktionslogg. Transaktionsloggen går över nätverksanslutningen till repliken och sedan reproduceras den på repliken. Det är enkelt.

Följaktligen används pg_stat_replikeringsvyn för att övervaka replikeringsfördröjningen. Men allt är inte enkelt med henne. I version 10 har vyn genomgått flera förändringar. För det första har vissa fält bytt namn. Och några fält har lagts till. I version 10 dök fält upp som låter dig uppskatta replikeringsfördröjningen i sekunder. Det är väldigt bekvämt. Före version 10 var det möjligt att uppskatta replikeringsfördröjningen i byte. Det här alternativet finns kvar i version 10, det vill säga du kan välja vad som är bekvämare för dig - uppskatta eftersläpningen i byte eller uppskatta fördröjningen i sekunder. Många människor gör båda.

Men ändå, för att utvärdera replikeringsfördröjningen, måste du känna till loggens position i transaktionen. Och dessa transaktionsloggpositioner är exakt i pg_stat_replikeringsvyn. Relativt sett kan vi ta två punkter i transaktionsloggen med funktionen pg_xlog_location_diff() . Beräkna deltat mellan dem och få replikeringsfördröjningen i byte. Det är väldigt bekvämt och enkelt.

I version 10 döptes denna funktion om till pg_wal_lsn_diff(). I allmänhet, i alla funktioner, vyer och verktyg där ordet "xlog" förekom, ersattes det med värdet "wal". Det gäller både vyer och funktioner. Det här är en sådan innovation.

Plus, i version 10 lades linjer till som specifikt visar eftersläpningen. Dessa är skrivlag, flushlag, replay lag. Det vill säga att det är viktigt att övervaka dessa saker. Om vi ​​ser att vi har en replikeringsfördröjning måste vi undersöka varför den dök upp, var den kom ifrån och åtgärda problemet.

Nästan allt är i sin ordning med systemmått. När någon övervakning börjar, börjar den med systemmått. Detta är förfogande av processorer, minne, swap, nätverk och disk. Många parametrar finns dock inte där som standard.

Om allt är i sin ordning med återvinningsprocessen, så finns det problem med diskåtervinning. Som regel lägger övervakningsutvecklare till information om genomströmning. Det kan vara i iops eller byte. Men de glömmer latens och användning av diskenheter. Dessa är viktigare parametrar som gör att vi kan utvärdera hur laddade våra diskar är och hur långsamma de är. Om vi ​​har hög latens betyder det att det finns några problem med diskarna. Om vi ​​har högt utnyttjande betyder det att diskarna inte orkar. Dessa är bättre egenskaper än genomströmning.

Dessutom kan denna statistik också erhållas från filsystemet /proc, vilket görs för återvinningsprocessorer. Jag vet inte varför denna information inte läggs till i övervakningen. Men ändå är det viktigt att ha detta i din övervakning.

Detsamma gäller för nätverksgränssnitt. Det finns information om nätverksgenomströmning i paket, i byte, men ändå finns det ingen information om latens och ingen information om utnyttjande, även om detta också är användbar information.

All övervakning har nackdelar. Och oavsett vilken typ av övervakning du tar kommer den alltid inte att uppfylla vissa kriterier. Men ändå utvecklas de, nya funktioner och nya saker läggs till, så välj något och avsluta det.

Och för att avsluta måste du alltid ha en uppfattning om vad statistiken som tillhandahålls betyder och hur du kan använda den för att lösa problem.

Och några viktiga punkter:

• Du bör alltid övervaka tillgängligheten och ha instrumentpaneler så att du snabbt kan bedöma att allt är i sin ordning med databasen.
• Du måste alltid ha en uppfattning om vilka kunder som arbetar med din databas för att sålla bort dåliga kunder och skjuta ner dem.
• Det är viktigt att utvärdera hur dessa klienter arbetar med data. Du måste ha en uppfattning om din arbetsbelastning.
• Det är viktigt att utvärdera hur denna arbetsbelastning bildas, med hjälp av vilka frågor. Du kan utvärdera frågor, du kan optimera dem, refaktorisera dem, bygga index för dem. Det är väldigt viktigt.
• Bakgrundsprocesser kan påverka klientförfrågningar negativt, så det är viktigt att övervaka att de inte använder för många resurser.
• Systemstatistik låter dig göra planer för skalning och ökning av kapaciteten på dina servrar, så det är viktigt att spåra och utvärdera dem också.

Om du är intresserad av detta ämne kan du följa dessa länkar.
http://bit.do/stats_collector - detta är officiell dokumentation från statistikinsamlaren. Det finns en beskrivning av alla statistiska vyer och en beskrivning av alla fält. Du kan läsa, förstå och analysera dem. Och baserat på dem, bygg dina grafer och lägg till dem i din övervakning.

Exempelförfrågningar:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Det här är vårt företagsförråd och mitt eget. De innehåller exempelfrågor. Det finns inga frågor från serien välj* från där. Det finns redan färdiga frågor med joins, med intressanta funktioner som låter dig omvandla råa tal till läsbara, bekväma värden, det vill säga dessa är bytes, tid. Du kan plocka upp dem, titta på dem, analysera dem, lägga till dem i din övervakning, bygga din övervakning utifrån dem.

frågor

Fråga: Du sa att du inte kommer att marknadsföra varumärken, men jag är fortfarande nyfiken - vilken typ av instrumentpaneler använder du i dina projekt?
Svar: Det varierar. Det händer att vi kommer till en kund och denne har redan en egen bevakning. Och vi ger kunden råd om vad som behöver läggas till i deras övervakning. Den värsta situationen är med Zabbix. Eftersom den inte har möjlighet att bygga TopN-grafer. Vi använder själva Okmeter, eftersom vi samrådde med dessa killar om övervakning. De övervakade PostgreSQL baserat på våra tekniska specifikationer. Jag skriver mitt eget husdjursprojekt, som samlar in data via Prometheus och återger det grafana. Min uppgift är att skapa en egen exportör i Prometheus och sedan rendera allt i Grafana.

Fråga: Finns det några analoger till AWR-rapporter eller... aggregering? Känner du till något sånt här?
Svar: Ja, jag vet vad AWR är, det är en cool grej. För närvarande finns det en mängd olika cyklar som implementerar ungefär följande modell. Vid ett visst tidsintervall skrivs vissa baslinjer till samma PostgreSQL eller till en separat lagring. Du kan googla dem på Internet, de finns där. En av utvecklarna av en sådan sak sitter på sql.ru-forumet i PostgreSQL-tråden. Du kan fånga honom där. Ja, det finns sådana saker, de kan användas. Plus i sin pgCenter Jag skriver också en sak som låter dig göra samma sak.

PS1 Om du använder postgres_exporter, vilken instrumentpanel använder du? Det finns flera av dem. De är redan föråldrade. Kanske kommer communityn att skapa en uppdaterad mall?

PS2 togs bort pganalyze eftersom det är ett proprietärt SaaS-erbjudande som fokuserar på prestandaövervakning och automatiserade justeringar.

Endast registrerade användare kan delta i undersökningen. Logga in, Snälla du.

Vilken självvärd postgresql-övervakning (med instrumentpanel) anser du vara bäst?

• 30,0%Zabbix + tillägg från Alexey Lesovsky eller zabbix 4.4 eller libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze är en proprietär SaaS - jag kan inte ta bort den1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

10 användare röstade. 26 användare avstod från att rösta.

Källa: will.com