SQL Server Page Life Expectancy (PLE)-metrikken har længe været betragtet som en nøglepræstationsindikator for DBA'er, der ser på den overordnede tilstand af deres databaseforekomster. PLE viser, om systemet er under internt hukommelsestryk ved hjælp af tællere leveret af Buffer Manager-objektet.
Et nærmere kig på sidens forventede levetid
PLE er et mål for den tid (i sekunder), en datafilside forventes at forblive i SQL Servers bufferpulje. Denne metrik er ikke en aggregering eller akkumulering, men blot en punkt-i-tidsværdi, som DBA'er vil forespørge ud af Buffer Manager.
SQL Server læser kun datasider fra bufferpuljen (dvs. logisk læsning), så hvis siden ikke er i bufferpuljen, finder den den på disken (dvs. fysisk læsning) og flytter siden til bufferpuljen, så det kan gøre en logisk læsning. Dette er en tidskrævende proces og kan påvirke ydeevnen negativt.
Hvad er en "god" PLE-værdi?
En høj PLE-værdi betyder, at en side bliver længere i bufferpuljen, så SQL Server er mindre tilbøjelig til at skulle gå til disken og lede efter datasiden, hvilket får systemet til at køre hurtigere.
Historisk set betragtede DBA'er 300 sekunder (fem minutter) som PLE-sødepunktet. Det tal er dog ret vilkårligt. Microsoft anbefalede 300 som PLE-standard tilbage i 2000'erne, da hukommelsen var begrænset.
I dag fokuserer DBA'er ikke på et "rigtigt" tal, fordi spande med hukommelse er standard på de fleste systemer. Det er ikke usædvanligt, at SQL Server kører på et system, der har TB'er RAM til sin rådighed, så DBA'er har vedtaget en formel tilgang til at identificere en "god" PLE-værdi:
Sidelevetid =300 sekunder for hver 4 GB RAM på din server
Det er dog uden tvivl vigtigere at løbende overvåge PLE-værdier for ændringer i konsistens, så du kan identificere hukommelsesproblemer og løse dem hurtigt.
Hvis du arbejder med en stor mængde data, er det vigtigt at bemærke, at større servere ofte har flere PLE'er. Hver non-uniform memory access (NUMA) node får sin egen PLE-værdi, og derefter beregnes disse tal for at få serverens PLE-værdi. Tag for eksempel PLE-værdien for noden x 1.000 (gør dette for alle NUMA-knuderne). Tilføj værdierne for alle noder, divider derefter med det samlede antal NUMA noder, og divider derefter igen med 1.000. Dette vil give dig serveren PLE.
Sådan afgør du, om der er et problem med sidelevetiden
Udsving i PLE er normale, fordi det er baseret på arbejdsbelastning. Sporing af høje, gennemsnitlige og lave tendenser kan vise dig, om visse processer, såsom tabelscanninger eller tømning af buffercachen, skal tunes for at forbedre PLE.
En god måde at afgøre, om der er et problem på, er, om det normale PLE-værdiområde falder og forbliver lavt. Dette indikerer, at der sandsynligvis er øget efterspørgsel og pres på bufferpuljen.
Betyder det, at du skal kaste noget mere hukommelse på problemet? Måske. Måske ikke.
Fejlfinding af lav forventet levetid for SQL Server-side
Der er flere grunde til, at PLE-værdier kan være lave. Det er vigtigt at fejlfinde problemet, fordi løsningen ikke er den samme for alle underliggende årsager. Her er tre af de skyldige, der med størst sandsynlighed vil bremse din PLE:
Utilstrækkelig hukommelse
Hvis arbejdsbyrden er støt stigende, og PLE falder, har du sandsynligvis mangel på hukommelse. Tilføjelse af hukommelse kan hjælpe med at øge PLE, men det vil ikke få forespørgsler til at køre mere effektivt.
Dyre operationer
Hvis arbejdsbyrden ikke har ændret sig, men der er øget efterspørgsel på bufferpuljen, kan det være, at outliers bruger mere hukommelse. Tjek for at se, om der kører vedligeholdelsesjob eller indeksgenopbygninger i gang.
Forældet statistik
Forældede statistikker kan forårsage ændringer i forespørgselsplanen. Dette øger efterspørgslen på bufferpuljen ved at få dyre operationer til at køre, fordi de ikke er synkroniseret med ny statistik.
Sådan rettes lav forventet sidelevetid ved at optimere forespørgsler
Den bedste måde at rette lave PLE-værdier på er ved at gå til kilden og optimere dine SQL Server-forespørgsler. Dette kommer med en ekstra bonus, fordi optimering af forespørgsler vil forbedre dit systems overordnede ydeevne på samme tid.
Der er flere ting, du gerne vil gøre, som vil hjælpe dig med at optimere forespørgsler for maksimal forbedring af PLE:
- Slet ubrugte indekser
- Flet dublerede indekser
- Kig efter store forespørgsler
- Vid, hvad der er i bufferpuljen
- Defragmenter indekser
- Opdater statistik
- Slet data
Sporing af sidelevetid over tid
Selvom PLE er en point-in-time-metrik, er det at se på PLE over tid en vigtig måde at identificere problemer på tidligt og hurtigt rette dem, før ydeevnen bliver væsentligt påvirket.
Der er mange måder at overvåge PLE-metrikken over tid og identificere de forespørgsler, hvis transaktioner forårsager en stor mængde læsninger. DMV'er og udvidede hændelser i SQL Server er de gennemprøvede metoder og har været medvirkende til denne proces med at indsamle data. Men de er også manuelle og tidskrævende, og de tilbyder begrænsede fordele, når det kommer til at få et historisk perspektiv på metrisk ydeevne over tid.
En kommerciel løsning som Spotlight Cloud giver ikke kun DBA'er muligheden for at spore PLE over tid lige ud af boksen, men den analyserer også arbejdsbyrden for at identificere, hvilke forespørgsler og outlier-aktiviteter, der forårsager pres på bufferpuljen, så du kan isolere og afhjælpe problem og optimer din SQL Server-ydelse.
Oprindeligt udgivet april 2019 og opdateret september 2020.