sql >> Databasteknik >  >> RDS >> Sqlserver

Övervaka sidans förväntade livslängd i SQL Server

SQL Server Page Life Expectancy (PLE)-måttet har länge ansetts vara en nyckelprestandaindikator för DBA:er som tittar på den övergripande hälsan hos sina databasinstanser. PLE visar om systemet är under internt minnestryck med hjälp av räknare som tillhandahålls av Buffer Manager-objektet.

En närmare titt på sidans förväntade livslängd

PLE är ett mått på hur lång tid (i sekunder) en datafilsida förväntas stanna i SQL Servers buffertpool. Detta mått är inte ett aggregat eller ackumulering, utan bara ett tidpunktsvärde som DBA:er kommer att fråga ut från Buffer Manager.

SQL Server läser bara datasidor från buffertpoolen (dvs logisk läsning), så om sidan inte finns i buffertpoolen hittar den den på disken (dvs fysisk läsning) och flyttar sidan till buffertpoolen så den kan göra en logisk läsning. Detta är en tidskrävande process och kan påverka prestandan negativt.

Vad är ett "bra" PLE-värde?

Ett högt PLE-värde betyder att en sida stannar i buffertpoolen längre, så det är mindre troligt att SQL Server behöver gå till disken och leta efter datasidan, vilket gör att systemet körs snabbare.

Historiskt sett ansåg DBA:er 300 sekunder (fem minuter) som PLE sweet spot. Den siffran är dock ganska godtycklig. Microsoft rekommenderade 300 som PLE-standard redan på 2000-talet när minnet var begränsat.

Idag fokuserar DBA inte på ett "rätt" nummer eftersom hinkar med minne är standard på de flesta system. Det är inte ovanligt att SQL Server körs på ett system som har TB RAM till sitt förfogande, så DBA:er har antagit ett formellt tillvägagångssätt för att identifiera ett "bra" PLE-värde:

Sidans förväntade livslängd =300 sekunder för varje 4 GB RAM-minne på din server

Men det är utan tvekan viktigare att kontinuerligt övervaka PLE-värden för förändringar i konsistens så att du kan identifiera minnesproblem och lösa dem snabbt.

Om du arbetar med en stor mängd data är det viktigt att notera att större servrar ofta har flera PLE:er. Varje nod för icke-uniform minnesåtkomst (NUMA) får sitt eget PLE-värde, och sedan beräknas dessa siffror för att få serverns PLE-värde. Ta till exempel PLE-värdet för noden x 1 000 (gör detta för alla NUMA-noder). Lägg till värdena för alla noder, dividera sedan med det totala antalet NUMA-noder och dividera sedan igen med 1 000. Detta kommer att ge dig servern PLE.

Hur man avgör om det finns ett problem med sidans förväntade livslängd

Fluktuationer i PLE är normala eftersom det är baserat på arbetsbelastning. Att spåra höga, genomsnittliga och låga trender kan visa dig om vissa processer, som tabellgenomsökningar eller tömning av buffertcachen, behöver ställas in för att förbättra PLE.

Ett bra sätt att avgöra om det finns ett problem är om det normala PLE-värdeintervallet sjunker och förblir lågt. Detta indikerar att det sannolikt finns en ökad efterfrågan och tryck på buffertpoolen.

Betyder detta att du behöver lägga lite mer minne på problemet? Kanske. Kanske inte.

Felsökning av låg förväntad livslängd för SQL Server-sidor

Det finns flera anledningar till att PLE-värden kan vara låga. Det är viktigt att felsöka problemet eftersom lösningen inte är densamma för alla grundorsaker. Här är tre av de skyldiga som mest sannolikt saktar ner din PLE:

Otillräckligt minne

Om arbetsbelastningen stadigt ökar och PLE minskar, har du sannolikt ont om minne. Att lägga till minne kan hjälpa till att öka PLE, men det kommer inte att göra att frågor körs mer effektivt.

Dyra operationer

Om arbetsbelastningen inte har förändrats, men det finns en ökad efterfrågan på buffertpoolen, kan det vara så att extremvärden använder mer minne. Kontrollera om det pågår underhållsjobb eller ombyggnader av index pågår.

Inaktuell statistik

Inaktuell statistik kan orsaka ändringar i frågeplanen. Detta ökar efterfrågan på buffertpoolen genom att få dyra operationer att köras eftersom de inte synkroniseras med ny statistik.

Hur man åtgärdar låg förväntad livslängd på sidan genom att optimera sökfrågor

Det bästa sättet att fixa låga PLE-värden är genom att gå till källan och optimera dina SQL Server-frågor. Detta kommer med en extra bonus eftersom optimering av frågor kommer att förbättra den övergripande prestandan för ditt system samtidigt.

Det finns flera saker du vill göra som hjälper dig att optimera frågor för maximal förbättring av PLE:

  • Släpp oanvända index
  • Slå samman dubbletter av index
  • Leta efter stora frågor
  • Vet vad som finns i buffertpoolen
  • Defragmentera index
  • Uppdatera statistik
  • Rensa data

Spåra sidans förväntade livslängd över tid

Även om PLE är ett mått i tid, är det att titta på PLE över tid ett viktigt sätt att identifiera problem tidigt och åtgärda dem snabbt innan prestandan påverkas avsevärt.

Det finns många sätt att övervaka PLE-måttet över tid och identifiera de frågor vars transaktioner orsakar en stor mängd läsningar. DMV:er och utökade händelser i SQL Server är de beprövade metoderna och har varit avgörande i denna process att samla in data. Men de är också manuella och tidskrävande, och de erbjuder begränsade fördelar när det gäller att få ett historiskt perspektiv på metrisk prestanda över tid.

En kommersiell lösning som Spotlight Cloud ger inte bara DBA:er möjlighet att spåra PLE över tid direkt ur lådan, utan den analyserar också arbetsbelastningen för att identifiera vilka frågor och outlieraktiviteter som orsakar press på buffertpoolen så att du kan isolera och åtgärda problem och optimera din SQL Server-prestanda.

Ursprungligen publicerad april 2019 och uppdaterad september 2020.


  1. Kolv efter exempel – Konfigurera Postgres, SQLAlchemy och Alembic

  2. Skapa och ta bort en PostgreSQL-databas på Ubuntu 16.04

  3. Hur MINUTE() fungerar i MariaDB

  4. Begränsande returnerad post från SQL-fråga i Oracle