Sqlserver
 sql >> Database >  >> RDS >> Sqlserver

Monitoraggio dell'aspettativa di vita della pagina in SQL Server

La metrica PLE (Page Life Expectancy) di SQL Server è stata a lungo considerata un indicatore di prestazioni chiave per i DBA che esaminano lo stato generale delle istanze di database. PLE mostra se il sistema è sotto pressione di memoria interna utilizzando i contatori forniti dall'oggetto Buffer Manager.

Uno sguardo più da vicino all'aspettativa di vita della pagina

PLE è una misura del tempo (in secondi) che una pagina di file di dati dovrebbe rimanere nel pool di buffer di SQL ServerSQL Server. Questa metrica non è un aggregato o un accumulo, ma semplicemente un valore point-in-time che i DBA eseguiranno query da Buffer Manager.

SQL Server legge solo le pagine di dati dal pool di buffer (ovvero, lettura logica), quindi se la pagina non è nel pool di buffer, la trova sul disco (ovvero, lettura fisica) e sposta la pagina nel pool di buffer in modo può fare una lettura logica. Questo è un processo che richiede tempo e può influire negativamente sulle prestazioni.

Che cos'è un valore PLE "buono"?

Un valore PLE elevato significa che una pagina rimane nel pool di buffer più a lungo, quindi è meno probabile che SQL Server debba andare sul disco per cercare la pagina dei dati, il che rende il sistema più veloce.

Storicamente, i DBA consideravano 300 secondi (cinque minuti) il punto debole del PLE. Tuttavia, quel numero è abbastanza arbitrario. Microsoft consigliava 300 come standard PLE negli anni 2000, quando la memoria era limitata.

Oggi, i DBA non si concentrano su un numero "giusto" perché i bucket di memoria sono standard sulla maggior parte dei sistemi. Non è insolito che SQL Server venga eseguito su un sistema che dispone di TB di RAM, quindi i DBA hanno adottato un approccio stereotipato per identificare un valore PLE "buono":

Aspettativa di vita della pagina =300 secondi per ogni 4 GB di RAM sul tuo server

Tuttavia, è probabilmente più importante monitorare continuamente i valori PLE per le modifiche alla coerenza in modo da poter identificare i problemi di memoria e risolverli rapidamente.

Se lavori con un grande volume di dati, è importante notare che i server più grandi hanno spesso più PLE. Ogni nodo di accesso alla memoria non uniforme (NUMA) ottiene il proprio valore PLE, quindi quei numeri vengono calcolati per ottenere il valore PLE del server. Ad esempio, prendi il valore PLE del nodo x 1.000 (fai questo per tutti i nodi NUMA). Aggiungi i valori di tutti i nodi, quindi dividi per il numero totale di nodi NUMA, quindi dividi di nuovo per 1.000. Questo ti darà il server PLE.

Come determinare se c'è un problema con l'aspettativa di vita della pagina

Le fluttuazioni in PLE sono normali perché si basa sul carico di lavoro. Il monitoraggio delle tendenze alte, medie e basse può mostrarti se determinati processi, come le scansioni delle tabelle o lo svuotamento della cache del buffer, devono essere ottimizzati per migliorare PLE.

Un buon modo per determinare se c'è un problema è se il normale intervallo di valori PLE diminuisce e rimane basso. Ciò indica che è probabile che vi sia un aumento della domanda e della pressione sul pool di buffer.

Questo significa che devi dedicare più memoria al problema? Forse. Forse no.

Risoluzione dei problemi della bassa aspettativa di vita della pagina di SQL Server

Ci sono diversi motivi per cui i valori di PLE potrebbero avere un trend basso. È importante risolvere il problema perché la soluzione non è la stessa per tutte le cause principali. Ecco tre dei colpevoli che molto probabilmente rallenteranno il tuo PLE:

Memoria insufficiente

Se il carico di lavoro è in costante aumento e PLE sta diminuendo, è probabile che la memoria sia insufficiente. L'aggiunta di memoria potrebbe aiutare ad aumentare PLE, ma non renderà le query eseguite in modo più efficiente.

Operazioni costose

Se il carico di lavoro non è cambiato, ma è aumentata la domanda sul pool di buffer, è possibile che i valori anomali utilizzino più memoria. Verificare se ci sono lavori di manutenzione in esecuzione o ricostruzioni dell'indice in corso.

Statistiche non aggiornate

Le statistiche obsolete possono causare modifiche al piano di query. Ciò aumenta la domanda sul pool di buffer causando l'esecuzione di operazioni costose perché non sono sincronizzate con le nuove statistiche.

Come risolvere la bassa aspettativa di vita della pagina ottimizzando le query

Il modo migliore per correggere valori PLE bassi è andare all'origine e ottimizzare le query di SQL Server. Questo viene fornito con un bonus aggiuntivo perché l'ottimizzazione delle query migliorerà allo stesso tempo le prestazioni complessive del tuo sistema.

Ci sono diverse cose che vorrai fare che ti aiuteranno a ottimizzare le query per il massimo miglioramento di PLE:

  • Elimina gli indici inutilizzati
  • Unisci indici duplicati
  • Cerca query di grandi dimensioni
  • Scopri cosa c'è nel pool di buffer
  • Deframmenta gli indici
  • Aggiorna le statistiche
  • Elimina dati

Tracciamento dell'aspettativa di vita della pagina nel tempo

Sebbene PLE sia una metrica point-in-time, esaminare PLE nel tempo è un modo importante per identificare i problemi in anticipo e risolverli rapidamente prima che le prestazioni ne risentano in modo significativo.

Esistono molti modi per monitorare la metrica PLE nel tempo e identificare le query le cui transazioni causano una grande quantità di letture. Le DMV e gli eventi estesi in SQL Server sono i metodi collaudati e sono stati determinanti in questo processo di raccolta dei dati. Ma sono anche manuali e dispendiosi in termini di tempo e offrono vantaggi limitati quando si tratta di ottenere una prospettiva storica sulle prestazioni delle metriche nel tempo.

Una soluzione commerciale come Spotlight Cloud non solo fornisce ai DBA la possibilità di tenere traccia di PLE nel tempo immediatamente, ma analizza anche il carico di lavoro per identificare quali query e attività anomale stanno causando pressione sul pool di buffer in modo da poter isolare e correggere il problema e ottimizzare le prestazioni di SQL Server.

Originariamente pubblicato ad aprile 2019 e aggiornato a settembre 2020.