De SQL Server Page Life Expectancy (PLE)-statistiek wordt al lang beschouwd als een belangrijke prestatie-indicator voor DBA's die kijken naar de algehele gezondheid van hun database-instanties. PLE laat zien of het systeem onder interne geheugendruk staat met behulp van tellers die door het Buffer Manager-object worden geleverd.
Een nadere blik op de levensverwachting van de pagina
PLE is een maat voor de tijdsduur (in seconden) dat een gegevensbestandspagina naar verwachting in de bufferpool van SQL Server blijft. Deze statistiek is geen aggregatie of accumulatie, maar gewoon een point-in-time waarde die DBA's uit de Buffer Manager zullen opvragen.
SQL Server leest alleen gegevenspagina's uit de bufferpool (d.w.z. logisch gelezen), dus als de pagina zich niet in de bufferpool bevindt, vindt het deze op de schijf (d.w.z. fysiek gelezen) en verplaatst de pagina naar de bufferpool zodat het kan een logische lezing doen. Dit is een tijdrovend proces en kan de prestaties negatief beïnvloeden.
Wat is een "goede" PLE-waarde?
Een hoge PLE-waarde betekent dat een pagina langer in de bufferpool blijft, zodat SQL Server minder snel naar de schijf hoeft te gaan op zoek naar de gegevenspagina, waardoor het systeem sneller werkt.
Historisch gezien beschouwden DBA's 300 seconden (vijf minuten) als de PLE-sweet spot. Dat aantal is echter vrij willekeurig. Microsoft raadde 300 aan als de PLE-standaard in de jaren 2000, toen het geheugen beperkt was.
Tegenwoordig richten DBA's zich niet op een "juist" aantal, omdat op de meeste systemen standaard geheugenbakken zijn. Het is niet ongebruikelijk dat SQL Server draait op een systeem dat TB's RAM tot zijn beschikking heeft, dus DBA's hebben een formule-aanpak aangenomen om een "goede" PLE-waarde te identificeren:
Levensverwachting van pagina =300 seconden voor elke 4 GB RAM op uw server
Het is echter aantoonbaar belangrijker om PLE-waarden continu te controleren op wijzigingen in consistentie, zodat u geheugenproblemen kunt identificeren en deze snel kunt oplossen.
Als u met een grote hoeveelheid gegevens werkt, is het belangrijk op te merken dat grotere servers vaak meerdere PLE's hebben. Elk niet-uniform geheugentoegangsknooppunt (NUMA) krijgt zijn eigen PLE-waarde en vervolgens worden die getallen berekend om de PLE-waarde van de server te krijgen. Neem bijvoorbeeld de PLE-waarde van het knooppunt x 1.000 (doe dit voor alle NUMA-knooppunten). Voeg de waarden van alle knooppunten toe, deel vervolgens door het totale aantal NUMA-knooppunten en deel vervolgens opnieuw door 1.000. Dit geeft je de server PLE.
Bepalen of er een probleem is met de levensverwachting van de pagina
Fluctuaties in PLE zijn normaal omdat het gebaseerd is op werkdruk. Door hoge, gemiddelde en lage trends te volgen, kunt u zien of bepaalde processen, zoals tabelscans of het leegmaken van de buffercache, moeten worden afgestemd om PLE te verbeteren.
Een goede manier om te bepalen of er een probleem is, is als het normale PLE-waardebereik daalt en laag blijft. Dit geeft aan dat er waarschijnlijk een verhoogde vraag en druk op de bufferpool is.
Betekent dit dat je wat meer geheugen op het probleem moet gooien? Kan zijn. Misschien niet.
Problemen oplossen met een lage levensduur van SQL Server-pagina's
Er zijn verschillende redenen waarom PLE-waarden laag kunnen zijn. Het is belangrijk om het probleem op te lossen, omdat de oplossing niet voor elke hoofdoorzaak hetzelfde is. Hier zijn drie van de boosdoeners die uw PLE waarschijnlijk vertragen:
Onvoldoende geheugen
Als de werkdruk gestaag toeneemt en PLE afneemt, heeft u waarschijnlijk te weinig geheugen. Het toevoegen van geheugen kan helpen om de PLE te verhogen, maar het zal er niet voor zorgen dat zoekopdrachten efficiënter worden uitgevoerd.
Dure operaties
Als de werklast niet is veranderd, maar er wel meer vraag is naar de bufferpool, kan het zijn dat uitschieters meer geheugen gebruiken. Controleer of er onderhoudstaken worden uitgevoerd of indexreconstructies worden uitgevoerd.
Verouderde statistieken
Verouderde statistieken kunnen wijzigingen in het queryplan veroorzaken. Dit verhoogt de vraag naar de bufferpool doordat dure bewerkingen worden uitgevoerd omdat ze niet worden gesynchroniseerd met nieuwe statistieken.
Hoe een lage levensduur van pagina's oplossen door zoekopdrachten te optimaliseren
De beste manier om lage PLE-waarden op te lossen, is door naar de bron te gaan en uw SQL Server-query's te optimaliseren. Dit komt met een extra bonus omdat het optimaliseren van zoekopdrachten tegelijkertijd de algehele prestaties van uw systeem zal verbeteren.
Er zijn verschillende dingen die u wilt doen die u zullen helpen bij het optimaliseren van zoekopdrachten voor maximale verbetering van PLE:
- Laat ongebruikte indexen vallen
- Dubbele indexen samenvoegen
- Zoek naar grote zoekopdrachten
- Weet wat er in de bufferpool zit
- Indexen defragmenteren
- Statistieken bijwerken
- Gegevens wissen
De levensverwachting van de volgpagina in de loop van de tijd
Hoewel PLE een tijdmeting is, is het bekijken van PLE in de loop van de tijd een belangrijke manier om problemen vroegtijdig te identificeren en snel op te lossen voordat de prestaties aanzienlijk worden beïnvloed.
Er zijn veel manieren om de PLE-statistiek in de loop van de tijd te controleren en de query's te identificeren waarvan de transacties een groot aantal leesbewerkingen veroorzaken. DMV's en uitgebreide gebeurtenissen in SQL Server zijn de beproefde methoden en hebben een belangrijke rol gespeeld bij dit proces van gegevensverzameling. Maar ze zijn ook handmatig en tijdrovend, en ze bieden beperkte voordelen als het gaat om het verkrijgen van een historisch perspectief op metrische prestaties in de loop van de tijd.
Een commerciële oplossing zoals Spotlight Cloud biedt DBA's niet alleen de mogelijkheid om PLE in de loop van de tijd direct uit de doos te volgen, maar analyseert ook de werklast om te identificeren welke query's en uitschieters de bufferpool onder druk zetten, zodat u de probleem en optimaliseer uw SQL Server-prestaties.
Oorspronkelijk gepubliceerd in april 2019 en bijgewerkt in september 2020.