Massoptimering av PostgreSQL-frågor. Kirill Borovikov (Tensor)

Rapporten presenterar några tillvägagångssätt som tillåter övervaka prestanda för SQL-frågor när det finns miljontals av dem per dag, och det finns hundratals övervakade PostgreSQL-servrar.

Vilka tekniska lösningar gör att vi effektivt kan bearbeta en sådan mängd information, och hur underlättar detta livet för en vanlig utvecklare?

Vem är intresserad? analys av specifika problem och olika optimeringstekniker SQL-frågor och lösa typiska DBA-problem i PostgreSQL - du kan också läsa en serie artiklar om detta ämne.


Jag heter Kirill Borovikov, jag representerar Tensorföretag. Specifikt är jag specialiserad på att arbeta med databaser i vårt företag.

Idag kommer jag att berätta hur vi optimerar frågor, när du inte behöver "plocka isär" prestandan för en enda fråga, utan lösa problemet en masse. När det finns miljontals förfrågningar och du behöver hitta några tillvägagångssätt till lösning detta stora problem.

I allmänhet är Tensor för en miljon av våra kunder VLSI är vår applikation: företags sociala nätverk, lösningar för videokommunikation, för internt och externt dokumentflöde, redovisningssystem för redovisning och lager,... Det vill säga en sådan "megakombination" för integrerad företagsledning, där det finns mer än 100 olika interna projekt.

För att säkerställa att de alla fungerar och utvecklas normalt har vi 10 utvecklingscentra över hela landet, med fler i dem 1000 utvecklare.

Vi har arbetat med PostgreSQL sedan 2008 och har samlat på oss en stor mängd av det vi bearbetar - kunddata, statistisk, analytisk, data från externa informationssystem - mer än 400TB. Det finns cirka 250 servrar enbart i produktion och totalt är det cirka 1000 databasservrar som vi övervakar.

SQL är ett deklarativt språk. Du beskriver inte "hur" något ska fungera, utan "vad" du vill uppnå. DBMS vet bättre hur man gör en JOIN - hur man kopplar ihop dina tabeller, vilka villkor som ska införas, vad kommer att gå igenom indexet, vad kommer inte ...

Vissa DBMS:er accepterar tips: "Nej, anslut dessa två tabeller i en sådan och en sådan kö", men PostgreSQL kan inte göra detta. Detta är ledande utvecklares medvetna position: "Vi skulle hellre avsluta frågeoptimeraren än att låta utvecklare använda någon form av tips."

Men trots att PostgreSQL inte tillåter "utsidan" att kontrollera sig själv, tillåter det perfekt se vad som händer inom honomnär du kör din fråga och där den har problem.

I allmänhet, vilka klassiska problem brukar en utvecklare [till en DBA] komma med? ”Här uppfyllde vi begäran, och allt går långsamt med oss, allt hänger, något händer... Något slags problem!”

Anledningarna är nästan alltid desamma:

• ineffektiv frågealgoritm
  Utvecklare: "Nu ger jag honom 10 tabeller i SQL via JOIN..." - och förväntar sig att hans villkor mirakulöst kommer att vara effektivt "obundna" och att han kommer att få allt snabbt. Men mirakel sker inte, och alla system med sådan variation (10 tabeller i en FROM) ger alltid något slags fel. [artikel]
• föråldrad statistik
  Denna punkt är mycket relevant specifikt för PostgreSQL, när du "hällde" en stor datauppsättning på servern, gör en förfrågan och den "sexcaniterar" din surfplatta. För igår fanns det 10 poster i den, och idag finns det 10 miljoner, men PostgreSQL är ännu inte medveten om detta, och vi måste berätta om det. [artikel]
• "plugga" på resurser
  Du har installerat en stor och hårt belastad databas på en svag server som inte har tillräckligt med disk-, minnes- eller processorprestanda. Och det är allt... Någonstans finns det ett prestationstak över vilket du inte längre kan hoppa.
• blockering
  Detta är en svår punkt, men de är mest relevanta för olika modifieringsfrågor (INSERT, UPDATE, DELETE) - detta är ett separat stort ämne.

Får en plan

...Och för allt annat vi behöver en plan! Vi måste se vad som händer inuti servern.

En frågeexekveringsplan för PostgreSQL är ett träd för frågeexekveringsalgoritmen i textrepresentation. Det är just algoritmen som, som ett resultat av analys av planeraren, visade sig vara den mest effektiva.

Varje trädnod är en operation: hämta data från en tabell eller index, bygga en bitmapp, sammanfoga två tabeller, sammanfoga, skära eller utesluta urval. Att köra en fråga innebär att gå igenom noderna i detta träd.

För att få frågeplanen är det enklaste sättet att köra uttalandet EXPLAIN. För att få med alla verkliga attribut, det vill säga att faktiskt köra en fråga på basen - EXPLAIN (ANALYZE, BUFFERS) SELECT ....

Den dåliga delen: när du kör det händer det "här och nu", så det är bara lämpligt för lokal felsökning. Om du tar en högt laddad server som är under ett starkt flöde av dataförändringar, och du ser: "Åh! Här har vi ett långsamt utförandeXia begäran." För en halvtimme, en timme sedan - medan du körde och hämtade denna begäran från loggarna, förde den tillbaka till servern, ändrades hela din datauppsättning och statistik. Du kör det för att felsöka - och det går snabbt! Och du kan inte förstå varför, varför было långsamt.

För att förstå vad som hände exakt i det ögonblick då begäran kördes på servern, skrev smarta personer auto_explain-modul. Det finns i nästan alla de vanligaste PostgreSQL-distributionerna och kan enkelt aktiveras i konfigurationsfilen.

Om den inser att en begäran löper längre än gränsen du sa till den, gör den det "ögonblicksbild" av planen för denna begäran och skriver dem tillsammans i loggen.

Allt verkar vara bra nu, vi går till stocken och ser där... [text fotduk]. Men vi kan inte säga något om det, annat än att det är en utmärkt plan eftersom det tog 11 ms att genomföra.

Allt verkar vara bra - men ingenting är klart vad som faktiskt hände. Förutom den allmänna tiden ser vi egentligen ingenting. För att titta på ett sådant "lamm" av vanlig text är i allmänhet inte visuellt.

Men även om det inte är uppenbart, även om det är obekvämt, finns det mer grundläggande problem:

• Noden indikerar summan av resurser för hela underträdet under honom. Det vill säga, du kan inte bara ta reda på hur mycket tid som spenderades på just denna Index Scan om det finns något kapslat tillstånd under den. Vi måste dynamiskt titta för att se om det finns "barn" och villkorsvariabler, CTEs inuti - och subtrahera allt detta "i våra sinnen".
• Andra punkten: tiden som anges på noden är exekveringstid för en enda nod. Om denna nod exekveras som ett resultat av, till exempel, en loop genom tabellposter flera gånger, så ökar antalet loopar – cykler för denna nod – i planen. Men själva atomavrättningstiden förblir densamma när det gäller planen. Det vill säga, för att förstå hur länge denna nod utfördes totalt, måste du multiplicera en sak med en annan - igen, "i ditt huvud."

I sådana situationer, förstå "Vem är den svagaste länken?" nästan omöjligt. Därför skriver även utvecklarna själva i "manualen" att "Att förstå en plan är en konst som måste läras, uppleva...".

Men vi har 1000 utvecklare, och du kan inte förmedla den här upplevelsen till var och en av dem. Jag, du, han vet, men någon där borta vet inte längre. Kanske kommer han att lära sig, eller kanske inte, men han behöver jobba nu – och var skulle han få den här erfarenheten?

Planera visualisering

Därför insåg vi att för att kunna hantera dessa problem behöver vi bra visualisering av planen. [artikel]

Vi gick först "genom marknaden" - låt oss titta på Internet för att se vad som ens existerar.

Men det visade sig att det finns väldigt få relativt "live" lösningar som är mer eller mindre under utveckling - bokstavligen bara en: explain.depesz.com av Hubert Lubaczewski. När du anger "flöde"-fältet en textrepresentation av planen, visar den dig en tabell med analyserad data:

• nodens egen handläggningstid
• total tid för hela underträdet
• antal poster som hämtats som var statistiskt förväntade
• själva nodkroppen

Den här tjänsten har också möjlighet att dela ett arkiv med länkar. Du slängde in din plan och sa: "Hej, Vasya, här är en länk, det är något fel där."

Men det finns också små problem.

För det första en enorm mängd "copy-paste". Du tar en bit av stocken, sticker in den där, och igen, och igen.

Andra, ingen analys av mängden avläst data — samma buffertar som matas ut EXPLAIN (ANALYZE, BUFFERS), vi ser det inte här. Han vet helt enkelt inte hur man tar isär dem, förstår dem och arbetar med dem. När du läser mycket data och inser att du kan ha felallokerat disken och minnescachen, är denna information mycket viktig.

Den tredje negativa punkten är den mycket svaga utvecklingen av detta projekt. Åtagandena är mycket små, det är bra om det är en gång var sjätte månad, och koden finns i Perl.

Men det här är alla "texter", vi skulle på något sätt kunna leva med detta, men det finns en sak som kraftigt avvisade oss från den här tjänsten. Dessa är fel i analysen av Common Table Expression (CTE) och olika dynamiska noder som InitPlan/SubPlan.

Om du tror på den här bilden är den totala exekveringstiden för varje enskild nod större än den totala exekveringstiden för hela begäran. Det är enkelt - genereringstiden för denna CTE subtraherades inte från CTE Scan-noden. Därför vet vi inte längre det korrekta svaret på hur lång tid själva CTE-skanningen tog.

Då insåg vi att det var dags att skriva eget – hurra! Varje utvecklare säger: "Nu ska vi skriva vårt eget, det blir superenkelt!"

Vi tog en stack typisk för webbtjänster: en kärna baserad på Node.js + Express, använde Bootstrap och D3.js för vackra diagram. Och våra förväntningar var helt berättigade - vi fick den första prototypen på 2 veckor:

• anpassad planparser
  Det vill säga, nu kan vi analysera vilken plan som helst från de som genereras av PostgreSQL.
• korrekt analys av dynamiska noder - CTE Scan, InitPlan, SubPlan
• analys av buffertfördelning - var datasidor läses från minnet, var från den lokala cachen, var från disken
• fick klarhet
  För att inte "gräva" allt detta i loggen, utan för att se den "svagaste länken" direkt i bilden.

Vi fick något sånt här, med syntaxmarkering inkluderad. Men vanligtvis arbetar våra utvecklare inte längre med en fullständig representation av planen, utan med en kortare. Vi har trots allt redan analyserat alla siffror och kastat dem åt vänster och höger, och i mitten lämnade vi bara den första raden, vilken typ av nod det är: CTE Scan, CTE generation eller Seq Scan enligt något tecken.

Detta är den förkortade representationen vi kallar plan mall.

Vad mer skulle vara bekvämt? Det skulle vara bekvämt att se vilken del av vår totala tid som allokeras till vilken nod - och bara "hålla den" åt sidan tårtdiagram.

Vi pekar på noden och ser - det visar sig att Seq Scan tog mindre än en fjärdedel av den totala tiden, och de återstående 3/4 togs av CTE Scan. Skräck! Detta är en liten anteckning om "brandhastigheten" för CTE Scan om du aktivt använder dem i dina frågor. De är inte särskilt snabba - de är sämre även för vanlig bordsskanning. [artikel] [artikel]

Men vanligtvis är sådana diagram mer intressanta, mer komplexa, när vi omedelbart pekar på ett segment och till exempel ser att mer än hälften av tiden någon Seq Scan "ätit". Dessutom fanns det något slags filter inuti, många poster slängdes enligt det... Du kan direkt kasta den här bilden till utvecklaren och säga: "Vasya, allt är dåligt här för dig! Ta reda på det, titta - något är fel!"

Naturligtvis var det några "rakes" inblandade.

Det första vi stötte på var avrundningsproblemet. Tiden för varje enskild nod i planen anges med en noggrannhet på 1 μs. Och när antalet nodcykler överstiger till exempel 1000 - efter exekvering av PostgreSQL delat "inom noggrannhet", då får vi vid tillbakaräkning den totala tiden "någonstans mellan 0.95 ms och 1.05 ms". När räkningen går till mikrosekunder är det okej, men när det redan är [milli]sekunder, måste du ta hänsyn till denna information när du "löser" resurser till noderna i planen "vem konsumerade hur mycket".

Den andra punkten, mer komplex, är fördelningen av resurser (dessa buffertar) mellan dynamiska noder. Detta kostade oss de första 2 veckorna av prototypen plus ytterligare 4 veckor.

Det är ganska lätt att få den här typen av problem - vi gör en CTE och lär läsa något i den. Faktum är att PostgreSQL är "smart" och kommer inte att läsa något direkt där. Sedan tar vi den första skivan från den, och till den den hundraförsta från samma CTE.

Vi tittar på planen och förstår - det är konstigt, vi har 3 buffertar (datasidor) "konsumerade" i Seq Scan, 1 till i CTE Scan och 2 till i den andra CTE Scan. Det vill säga om vi helt enkelt summerar allt så får vi 6, men från surfplattan läser vi bara 3! CTE Scan läser ingenting från någonstans, utan arbetar direkt med processminnet. Det vill säga något är helt klart fel här!

Det visar sig faktiskt att här är alla de där 3 sidorna med data som begärdes från Seq Scan, först 1 bad om den 1:a CTE Scan, och sedan den 2:a, och 2 till lästes för honom. 3 sidor lästes data, inte 6.

Och den här bilden ledde oss till förståelsen att genomförandet av en plan inte längre är ett träd, utan bara någon form av acyklisk graf. Och vi fick ett diagram som detta, så att vi förstår "vad som kom ifrån var från början." Det vill säga, här skapade vi en CTE från pg_class, och bad om den två gånger, och nästan all vår tid spenderades på grenen när vi bad om den andra gången. Det är klart att det är mycket dyrare att läsa den 2:a posten än att bara läsa den 101:a posten från surfplattan.

Vi andades ut en stund. De sa: "Nu, Neo, du vet kung fu! Nu är vår upplevelse direkt på din skärm. Nu kan du använda den." [artikel]

Loggkonsolidering

Våra 1000 utvecklare andades en lättnadens suck. Men vi förstod att vi bara har hundratals "combat"-servrar, och allt detta "copy-paste" från utvecklarnas sida är inte alls bekvämt. Vi insåg att vi var tvungna att hämta den själva.

Generellt finns det en standardmodul som kan samla in statistik, men den måste också aktiveras i konfigurationen - detta modul pg_stat_statements. Men han passade inte oss.

För det första tilldelar den samma frågor med olika scheman inom samma databas olika QueryIds. Det vill säga om du först gör det SET search_path = '01'; SELECT * FROM user LIMIT 1;och sedan SET search_path = '02'; och samma förfrågan, då kommer statistiken för denna modul att ha olika poster, och jag kommer inte att kunna samla in allmän statistik specifikt i samband med denna förfrågningsprofil, utan att ta hänsyn till scheman.

Den andra punkten som hindrade oss från att använda den är brist på planer. Det vill säga det finns ingen plan, det finns bara själva förfrågan. Vi ser vad som saktade ner, men vi förstår inte varför. Och här återvänder vi till problemet med ett snabbt föränderligt dataset.

Och sista stunden - brist på "fakta". Det vill säga, du kan inte ta itu med en specifik instans av sökexekvering - det finns ingen, det finns bara aggregerad statistik. Även om det går att jobba med detta är det bara väldigt svårt.

Därför bestämde vi oss för att bekämpa copy-paste och började skriva kollektor.

Samlaren ansluter via SSH, upprättar en säker anslutning till servern med databasen med hjälp av ett certifikat, och tail -F "klamrar sig fast" vid den i loggfilen. Så i denna session vi får en komplett "spegel" av hela loggfilen, som servern genererar. Belastningen på själva servern är minimal, eftersom vi inte analyserar någonting där, vi speglar bara trafiken.

Eftersom vi redan hade börjat skriva gränssnittet i Node.js fortsatte vi att skriva samlaren i det. Och den här tekniken har motiverat sig, eftersom det är väldigt bekvämt att använda JavaScript för att arbeta med svagt formaterad textdata, som är loggen. Och själva Node.js-infrastrukturen som en backend-plattform låter dig enkelt och bekvämt arbeta med nätverksanslutningar, och faktiskt med alla dataströmmar.

Följaktligen "sträcker" vi två anslutningar: den första för att "lyssna" på själva loggen och ta den till oss själva, och den andra för att regelbundet fråga basen. "Men loggen visar att skylten med oid 123 är blockerad," men detta betyder ingenting för utvecklaren, och det skulle vara trevligt att fråga databasen, "Vad är OID = 123 ändå?" Och så frågar vi regelbundet basen vad vi ännu inte vet om oss själva.

"Det finns bara en sak du inte tog hänsyn till, det finns en art av elefantliknande bin!..." Vi började utveckla det här systemet när vi ville övervaka 10 servrar. Det mest kritiska i vår förståelse, där det uppstod några problem som var svåra att hantera. Men under det första kvartalet fick vi hundra för övervakning – eftersom systemet fungerade, alla ville ha det, alla var bekväma.

Allt detta måste läggas ihop, dataflödet är stort och aktivt. Faktum är att det vi övervakar, vad vi kan hantera, är vad vi använder. Vi använder även PostgreSQL som datalagring. Och ingenting är snabbare att "hälla" data i den än operatören COPY Inte än.

Men att helt enkelt "hälla" data är inte riktigt vår teknik. För om du har ungefär 50 100 förfrågningar per sekund på hundra servrar, kommer detta att generera 150-XNUMX GB loggar per dag. Därför var vi tvungna att försiktigt "klippa" basen.

För det första gjorde vi det uppdelning per dag, eftersom ingen i stort sett är intresserad av sambandet mellan dagar. Vilken skillnad gör det vad du hade igår, om du ikväll rullade ut en ny version av applikationen - och redan lite ny statistik.

För det andra lärde vi oss (var tvingade) väldigt, väldigt snabbt att skriva med hjälp av COPY. Det vill säga inte bara COPYeftersom han är snabbare än INSERT, och ännu snabbare.

Den tredje punkten - jag var tvungen överge utlösare respektive främmande nycklar. Det vill säga att vi inte har någon referensintegritet alls. För om du har en tabell som har ett par FK:er, och du säger i databasstrukturen att "här är en loggpost som t.ex. refereras av FK till en grupp av poster", så när du infogar den, PostgreSQL har inget kvar än hur man tar det och gör det ärligt SELECT 1 FROM master_fk1_table WHERE ... med identifieraren som du försöker infoga - bara för att kontrollera att denna post finns där, att du inte "bryter av" denna främmande nyckel med din insättning.

Istället för en post till måltabellen och dess index får vi den extra fördelen av att läsa från alla tabeller den refererar till. Men vi behöver inte det här alls - vår uppgift är att spela in så mycket som möjligt och så snabbt som möjligt med minsta möjliga belastning. Så FK - ner!

Nästa punkt är aggregering och hash. Till en början implementerade vi dem i databasen - trots allt är det bekvämt att omedelbart, när en post kommer, göra det i någon form av surfplatta "plus ett" direkt i avtryckaren. Tja, det är bekvämt, men samma dåliga sak - du infogar en post, men tvingas läsa och skriva något annat från en annan tabell. Dessutom läser och skriver du inte bara, du gör det också varje gång.

Föreställ dig nu att du har en tabell där du helt enkelt räknar antalet förfrågningar som har passerat en specifik värd: +1, +1, +1, ..., +1. Och du behöver i princip inte detta - det är allt möjligt summa i minnet på samlaren och skicka till databasen på en gång +10.

Ja, vid vissa problem kan din logiska integritet "falla isär", men detta är ett nästan orealistiskt fall - eftersom du har en normal server, den har ett batteri i styrenheten, du har en transaktionslogg, en logg på filsystem... I allmänhet är det inte värt det. Förlusten av produktivitet du får av att köra triggers/FK är inte värt kostnaden du ådrar dig.

Det är samma sak med hashing. En viss förfrågan flyger till dig, du beräknar en viss identifierare från den i databasen, skriver den till databasen och berättar sedan för alla. Allt är bra tills, vid inspelningstillfället, en andra person kommer till dig som vill spela in samma sak - och du blir blockerad, och det här är redan dåligt. Därför, om du kan överföra genereringen av vissa ID:n till klienten (i förhållande till databasen), är det bättre att göra detta.

Det var bara perfekt för oss att använda MD5 från texten - begäran, plan, mall,... Vi beräknar det på samlarsidan och "häller" det färdiga ID:t i databasen. Längden på MD5 och daglig partitionering gör att vi inte kan oroa oss för eventuella kollisioner.

Men för att kunna spela in allt detta snabbt behövde vi modifiera själva inspelningsproceduren.

Hur brukar du skriva data? Vi har någon slags datauppsättning, vi delar upp den i flera tabeller och sedan KOPIERA den - först till den första, sedan till den andra, till den tredje... Det är obekvämt, eftersom vi verkar skriva en dataström i tre steg sekventiellt. Obehaglig. Kan det göras snabbare? Burk!

För att göra detta räcker det bara att bryta ner dessa flöden parallellt med varandra. Det visar sig att vi har fel, förfrågningar, mallar, blockeringar, ... som flyger i separata trådar - och vi skriver det hela parallellt. Tillräckligt för detta håll en COPY-kanal ständigt öppen för varje enskild måltabell.

Det vill säga hos samlaren det finns alltid en ström, där jag kan skriva de data jag behöver. Men så att databasen ser dessa data, och någon inte fastnar i väntan på att denna data ska skrivas, COPY måste avbrytas med vissa intervall. För oss var den mest effektiva perioden cirka 100 ms - vi stänger den och öppnar den omedelbart igen till samma bord. Och om vi inte har tillräckligt med ett flöde under vissa toppar, gör vi poolning upp till en viss gräns.

Dessutom fick vi reda på att för en sådan belastningsprofil är all aggregering, när poster samlas in i omgångar, dålig. Klassisk ondska är INSERT ... VALUES och ytterligare 1000 poster. För vid den tidpunkten har du en skrivtopp på media, och alla andra som försöker skriva något till disken kommer att vänta.

För att bli av med sådana anomalier, samla helt enkelt ingenting, buffra inte alls. Och om buffring till disk inträffar (lyckligtvis tillåter Stream API i Node.js dig att ta reda på det) – skjut upp denna anslutning. När du får en händelse att den är gratis igen, skriv till den från den ackumulerade kön. Och medan det är upptaget, ta nästa lediga från poolen och skriv till den.

Innan vi introducerade detta tillvägagångssätt för datainspelning hade vi ungefär 4K skrivoperationer, och på så sätt minskade vi belastningen med 4 gånger. Nu har de vuxit ytterligare 6 gånger på grund av nya övervakade databaser - upp till 100MB/s. Och nu lagrar vi loggar för de senaste 3 månaderna i en volym på cirka 10-15TB, i hopp om att alla utvecklare på bara tre månader ska kunna lösa alla problem.

Vi förstår problemen

Men att helt enkelt samla in all denna data är bra, användbart, relevant, men inte tillräckligt - det måste förstås. För det här är miljontals olika planer per dag.

Men miljoner är ohanterliga, vi måste först göra "mindre". Och först och främst måste du bestämma hur du ska organisera denna "mindre" sak.

Vi har identifierat tre nyckelpunkter:

• som skickade denna begäran
  Det vill säga från vilken applikation "kom" den: webbgränssnitt, backend, betalningssystem eller något annat.
• där det hände
  På vilken specifik server? För om du har flera servrar under en applikation, och plötsligt en "blir dum" (eftersom "disken är ruttet", "minnet läckt", något annat problem), måste du specifikt adressera servern.
• как problemet yttrade sig på ett eller annat sätt

För att förstå "vem" som skickade en förfrågan till oss använder vi ett standardverktyg - ställer in en sessionsvariabel: SET application_name = '{bl-host}:{bl-method}'; — vi skickar namnet på den affärslogikvärd som förfrågan kommer från och namnet på metoden eller applikationen som initierade den.

Efter att vi har passerat "ägaren" av begäran måste den matas ut till loggen - för detta konfigurerar vi variabeln log_line_prefix = ' %m [%p:%v] [%d] %r %a'. För den intresserade kanske titta i manualenvad betyder allt. Det visar sig att vi ser i loggen:

• tid
• process- och transaktionsidentifierare
• Databas namn
• IP för personen som skickade denna begäran
• och metodnamn

Sedan insåg vi att det inte är särskilt intressant att titta på korrelationen för en begäran mellan olika servrar. Det är inte ofta som du har en situation där en applikation skruvas upp lika här och där. Men även om det är samma, titta på någon av dessa servrar.

Så här är snittet "en server - en dag" det visade sig vara tillräckligt för oss för alla analyser.

Det första analytiska avsnittet är detsamma "prov" - en förkortad form av presentation av planen, rensad från alla numeriska indikatorer. Det andra snittet är applikationen eller metoden, och det tredje snittet är den specifika plannoden som orsakade oss problem.

När vi gick från specifika instanser till mallar fick vi två fördelar samtidigt:

• multipel minskning av antalet objekt för analys
  Vi måste analysera problemet inte längre genom tusentals frågor eller planer, utan genom dussintals mallar.
• tidslinjen
  Det vill säga, genom att sammanfatta "fakta" inom ett visst avsnitt kan du visa deras utseende under dagen. Och här kan du förstå att om du har något slags mönster som händer, till exempel en gång i timmen, men det ska ske en gång om dagen, så ska du tänka på vad som gick fel - vem som orsakade det och varför, det kanske borde vara här borde inte. Detta är en annan icke-numerisk, rent visuell, analysmetod.

De återstående metoderna är baserade på de indikatorer som vi extraherar från planen: hur många gånger ett sådant mönster inträffade, den totala och genomsnittliga tiden, hur mycket data som lästes från disken och hur mycket från minnet ...

För att du till exempel kommer till analyssidan för värden, titta - något börjar läsa för mycket på disken. Disken på servern klarar inte av det – vem läser från den?

Och du kan sortera efter vilken kolumn som helst och bestämma vad du ska ta itu med just nu - belastningen på processorn eller disken, eller det totala antalet förfrågningar... Vi sorterade det, tittade på de "översta", fixade det och rullade ut en ny version av applikationen.
[videoföreläsning]

Och direkt kan du se olika applikationer som kommer med samma mall från en förfrågan som SELECT * FROM users WHERE login = 'Vasya'. Frontend, backend, bearbetning... Och du undrar varför bearbetning skulle läsa användaren om han inte interagerar med honom.

Det motsatta sättet är att omedelbart se från applikationen vad den gör. Till exempel är gränssnittet det här, det här, det här och det här en gång i timmen (tidslinjen hjälper). Och frågan uppstår omedelbart: det verkar som att det inte är frontends uppgift att göra något en gång i timmen...

Efter en tid insåg vi att vi saknade aggregerade statistik efter plannoder. Vi isolerade från planerna endast de noder som gör något med själva tabellernas data (läs/skriv dem efter index eller inte). Faktum är att bara en aspekt läggs till i förhållande till föregående bild - hur många poster gav den här noden oss?, och hur många som kasserades (rader togs bort med filter).

Du har inte ett lämpligt index på plattan, du gör en förfrågan till det, det flyger förbi indexet, hamnar i Seq Scan... du har filtrerat bort alla poster utom en. Varför behöver du 100 miljoner filtrerade poster per dag? Är det inte bättre att rulla upp indexet?

Efter att ha analyserat alla planerna nod för nod insåg vi att det finns några typiska strukturer i planerna som med stor sannolikhet kommer att se misstänkta ut. Och det skulle vara trevligt att berätta för utvecklaren: "Vän, här läser du först efter index, sorterar sedan och klipper sedan av" - som regel finns det en post.

Alla som skrev frågor har förmodligen stött på det här mönstret: "Ge mig den sista beställningen för Vasya, dess datum." Och om du inte har ett index efter datum, eller om det inte finns något datum i indexet du använde, kommer du att trampa på exakt samma "rake" .

Men vi vet att detta är en "rake" - så varför inte omedelbart berätta för utvecklaren vad han ska göra. Följaktligen, när vi öppnar en plan nu, ser vår utvecklare omedelbart en vacker bild med tips, där de omedelbart säger till honom: "Du har problem här och där, men de är lösta på det här sättet och det sättet."

Som ett resultat har mängden erfarenhet som behövdes för att lösa problem i början och nu minskat avsevärt. Det är den här typen av verktyg vi har.

Källa: will.com