¿Qué dice Page Life Expectancy sobre la instancia?

He instalado software de monitoreo en algunas instancias de SQL Server en el entorno. Estoy tratando de encontrar cuellos de botella y solucionar algunos problemas de rendimiento. Quiero saber si algunos servidores necesitan más memoria.

Estoy interesado en un contador: la esperanza de vida de la página. Se ve diferente en cada máquina. ¿Por qué cambia a menudo en algunos casos y qué significa?

Eche un vistazo a los datos de la última semana reunidos en algunas máquinas diferentes. ¿Qué puedes decir sobre cada instancia?

Instancia de producción muy utilizada (1):

Isancia de producción moderadamente utilizada (2)

Instancia de prueba raramente utilizada (3)

Instancia de producción muy utilizada (4)

Instancia de prueba utilizada moderadamente (5)

Almacén de datos muy utilizado (6)

EDITAR: estoy agregando la salida de SELECT @@ VERSION para todos estos servidores:

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)

También ejecuté la siguiente consulta en las máquinas:

SELECT DISTINCT memory_node_id
FROM sys.dm_os_memory_clerks

y devolvió 2 o 3 filas para cada servidor:

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

Qué significa eso? ¿Estos servidores ejecutan NUMA?

Tomado de MSDN: - https://msdn.microsoft.com/en-us/library/ms189628.aspx

Esperanza de vida de la página: indica el número de segundos que una página permanecerá en el grupo de búferes sin referencias.

SQL siempre busca páginas de datos en la memoria. Si una página de datos no está en la memoria, SQL tendrá que ir al disco (realizar una operación de E / S física) para recuperar los datos que necesita para completar una solicitud. Si su contador PLE es bajo, eso indica que las páginas de datos en la memoria se sobrescriben regularmente con nuevas páginas que provienen de operaciones físicas de E / S. Las operaciones físicas de E / S son costosas, lo que significa que el rendimiento de su instancia de SQL se verá afectado negativamente. Por lo tanto, querrá que su contador PLE esté lo más alto posible.

Ignore cualquier consejo que vea en línea que mencione 300 como un buen umbral para este contador

Este umbral proviene de los días en que la memoria era limitada (piense en los sistemas de 32 bits). Ahora tenemos sistemas de 64 bits que pueden tener TB de RAM, por lo que este consejo está muy desactualizado.

Lo primero, ¿ha limitado la memoria de SQL? Si es así, ¿cuánta memoria disponible queda? ¿Se puede aumentar el límite?

La segunda cosa que estaría buscando en sus servidores es, ¿hay algún trabajo de mantenimiento en ejecución? Verifique los trabajos que realizan reconstrucciones de índice, estadísticas de actualización u operaciones DBCC CHECKDB. Estos realizan una gran cantidad de lecturas y podrían ser la razón de su revestimiento plano PLE,

A continuación, mientras usa SQL Server 2008 +, puede configurar una sesión de evento extendido para capturar consultas entrantes que realizan una gran cantidad de lecturas. Aquí está el código para hacerlo: -

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

Esto capturará todas las consultas en su servidor que realicen más de 200000 lecturas lógicas. No sé cuánta memoria tiene en cada servidor, por lo que es posible que desee modificar esa cifra. Una vez que esto se haya creado, puede iniciar la sesión ejecutando: -

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

Y luego consulta la sesión ejecutando: -

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

¡Tenga cuidado al ejecutar esto! El archivo puede crecer bastante grande, así que pruébelo primero en una instancia de desarrollo. Puede establecer el máximo. tamaño del archivo pero no lo he incluido aquí. Aquí está el enlace de MSDN para eventos extendidos: - https://msdn.microsoft.com/en-us/library/hh213147.aspx

Monitoree esta sesión de forma rutinaria y con suerte debería recibir cualquier consulta que se encuentre en línea recta en su PLE.

Otras lecturas -

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

Video sobre la configuración de eventos extendidos: https://dbafromthecold.wordpress.com/2014/12/05/video-identifying-large-queries-using-extended-events/ (Es de mi propio blog, lo siento mucho por la descarada autopromoción )

La expectativa de vida de la página es una medida de cuánto tiempo puede esperar que una página que se acaba de leer del disco permanezca en la memoria antes de que otra cosa la expulse o se destruya (es decir, esa página se desasigna en el disco para que no sea necesario para mantener una copia en caché en la RAM).

Como medida general, cuanto mayor sea, más rápido se procesará su patrón de carga porque las cosas se mantienen en la memoria. Si es muy bajo, esto podría indicar un problema de rendimiento causado por la falta de memoria.

Sin embargo, la lectura baja no siempre significa que hay un problema: por ejemplo, podría ser bajo después de una gran cantidad de procesos únicos que utilizaron muchas páginas, por lo que los trajeron y los dejaron para dejar espacio para más. Su gráfico que parece caer al final de cada día, por ejemplo, podría ser causado por trabajos administrativos nocturnos (copia de seguridad, archivo de datos, otro procesamiento nocturno).