Cosa dice l'aspettativa di vita della pagina sull'istanza?

Ho installato un software di monitoraggio su alcune istanze di SQL Server nell'ambiente. Sto cercando di trovare colli di bottiglia e risolvere alcuni problemi di prestazioni. Voglio scoprire se alcuni server hanno bisogno di più memoria.

Sono interessato a un contatore: aspettativa di vita della pagina. Sembra diverso su ogni macchina. Perché cambia spesso in alcuni casi e cosa significa?

Dai un'occhiata ai dati dell'ultima settimana raccolti su alcune macchine diverse. Cosa puoi dire su ogni istanza?

Istanza di produzione pesantemente usata (1):

Istanza di produzione moderatamente usata (2)

Istanza di prova usata raramente (3)

Istanza di produzione molto usata (4)

Istanza di prova usata moderatamente (5)

Data warehouse molto utilizzato (6)

EDIT: sto aggiungendo l'output di SELECT @@ VERSION per tutti questi server:

Instance 1: Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) 
Jun 17 2011 00:54:03 Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 2: Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) 
Oct 19 2012 13:38:57 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 3: Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 
May 14 2014 18:34:29 
    Copyright (c) Microsoft Corporation
 Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Instance 4: Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64) Jun 28 2012 08:36:30 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 5: Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 
May 14 2014 18:34:29 
Copyright (c) Microsoft Corporation
 Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Instance 6: Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 
Apr 2 2010 15:48:46 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Ho anche eseguito la seguente query sui computer:

SELECT DISTINCT memory_node_id
FROM sys.dm_os_memory_clerks

e ha restituito 2 o 3 righe per ciascun server:

Instance 1: 0; 64; 1
Instance 2: 0; 64
Instance 3: 0; 64
Instance 4: 0; 64
Instance 5: 0; 64
Instance 6: 0; 64; 1

Cosa significa? Questi server eseguono NUMA?

Tratto da MSDN: - https://msdn.microsoft.com/en-us/library/ms189628.aspx

Aspettativa di vita della pagina: indica il numero di secondi in cui una pagina rimarrà nel pool di buffer senza riferimenti.

SQL cerca sempre pagine di dati in memoria. Se una pagina di dati non è in memoria, SQL dovrà andare sul disco (eseguire un'operazione di I / O fisica) per recuperare i dati necessari per soddisfare una richiesta. Se il contatore PLE è basso, ciò indica che le pagine di dati in memoria vengono regolarmente sovrascritte con nuove pagine provenienti da operazioni di I / O fisiche. Le operazioni di I / O fisiche sono costose, il che significa che le prestazioni dell'istanza SQL saranno influenzate negativamente. Quindi vorrai che il tuo contatore PLE sia il più alto possibile.

Ignora qualsiasi consiglio che vedi online che menzioni 300 come una buona soglia per questo contatore

Questa soglia viene dai giorni in cui la memoria era limitata (si pensi ai sistemi a 32 bit). Ora abbiamo sistemi a 64 bit che possono avere TB di RAM, quindi questo consiglio è molto obsoleto.

Prima cosa, hai limitato la memoria di SQL? In tal caso, quanta memoria disponibile è rimasta? Il limite può essere aumentato?

La seconda cosa che avrei cercato sui tuoi server è: ci sono lavori di manutenzione in esecuzione? Controllare i lavori che eseguono ricostruzioni dell'indice, aggiornare le statistiche o le operazioni DBCC CHECKDB. Eseguono una grande quantità di letture e potrebbero essere la ragione del tuo rivestimento piatto PLE,

Successivamente, quando si utilizza SQL Server 2008 +, è possibile impostare una sessione di eventi estesi per acquisire query in arrivo che eseguono una grande quantità di letture. Ecco il codice per farlo: -

CREATE EVENT SESSION [QueriesWithHighLogicalReads] ON SERVER 
ADD EVENT sqlserver.sql_batch_completed(
   ACTION(sqlserver.client_hostname,sqlserver.database_name,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_stack,sqlserver.username)
     WHERE ([logical_reads]>200000))
ADD TARGET package0.event_file(SET filename=N'C:\SQLServer\XEvents\QueriesWithHighLogicalReads.xel')
GO

Ciò acquisirà tutte le query sul server che eseguono oltre 200000 letture logiche. Non so quanta memoria hai su ciascun server, quindi potresti voler modificare quella cifra. Una volta creato questo, puoi avviare la sessione eseguendo: -

ALTER EVENT SESSION [QueriesWithHighLogicalReads]
ON SERVER
STATE = START;
GO

E quindi interrogare la sessione eseguendo: -

WITH CTE_ExecutedSQLStatements AS
(SELECT
[XML Data],
[XML Data].value('(/event[@name=''sql_statement_completed'']/@timestamp)[1]','DATETIME')    AS [Time],
[XML Data].value('(/event/data[@name=''duration'']/value)[1]','int')                        AS [Duration],
[XML Data].value('(/event/data[@name=''cpu_time'']/value)[1]','int')                        AS [CPU],
[XML Data].value('(/event/data[@name=''logical_reads'']/value)[1]','int')                   AS [logical_reads],
[XML Data].value('(/event/data[@name=''physical_reads'']/value)[1]','int')                  AS [physical_reads],
[XML Data].value('(/event/action[@name=''sql_text'']/value)[1]','varchar(max)')             AS [SQL Statement]
FROM
    (SELECT 
    OBJECT_NAME              AS [Event], 
    CONVERT(XML, event_data) AS [XML Data]
FROM 
    sys.fn_xe_file_target_read_file
('C:\SQLServer\XEvents\QueriesWithHighLogicalReads*.xel',NULL,NULL,NULL)) as v)

SELECT
[SQL Statement]     AS [SQL Statement],
SUM(Duration)       AS [Total Duration],
SUM(CPU)            AS [Total CPU],
SUM(Logical_Reads)  AS [Total Logical Reads],
SUM(Physical_Reads) AS [Total Physical Reads]
FROM
CTE_ExecutedSQLStatements
GROUP BY
[SQL Statement]
ORDER BY
[Total Logical Reads] DESC
GO

Fai attenzione quando esegui questo! Il file può avere dimensioni piuttosto grandi, quindi testalo prima su un'istanza di sviluppo. È possibile impostare il max. dimensione del file ma non l'ho inclusa qui. Ecco il link MSDN per eventi estesi: - https://msdn.microsoft.com/en-us/library/hh213147.aspx

Monitora questa sessione regolarmente e, si spera, dovrebbe raccogliere tutte le domande in arrivo che rivestono il tuo PLE.

Ulteriori letture -

Blog MSDN su PLE - http://blogs.msdn.com/b/mcsukbi/archive/2013/04/12/sql-server-page-life-expectancy.aspx

Video sulla creazione di eventi estesi - https://dbafromthecold.wordpress.com/2014/12/05/video-identifying-large-queries-using-extended-events/ (È dal mio blog quindi mi dispiace per l'autopromozione spudorata )

L'aspettativa di vita della pagina è una misura di quanto ci si può aspettare che una pagina che è stata appena letta dal disco rimanga in memoria prima che venga espulsa da qualcos'altro o venga distrutta (cioè quella pagina viene allocata su disco in quanto non è necessario per conservare una copia memorizzata nella cache).

Come misura generale, maggiore è la velocità con cui verrà elaborato il modello di caricamento perché le cose vengono mantenute in memoria. Se è molto basso, ciò potrebbe indicare un problema di prestazioni causato dalla fame di memoria.

Il fatto che la lettura sia bassa non significa sempre che ci sia un problema: ad esempio potrebbe essere basso dopo una massiccia quantità una tantum di processi che hanno utilizzato molte pagine, quindi le hanno inserite e lasciate cadere per fare spazio a più. Il grafico che sembra cadere alla fine di ogni giorno, ad esempio, potrebbe essere causato da lavori amministrativi notturni (backup, archiviazione dei dati, altri processi durante la notte).