Estoy tratando de encontrar una forma sensata de entender si la max server memory (mb)
configuración es adecuada (ya sea más baja o más alta, o permanecer como está). Soy consciente de que max server memory (mb)
siempre debe ser lo suficientemente bajo como para dejar espacio para el sistema operativo, etc.
El entorno que estoy viendo tiene varios cientos de servidores; Necesito una fórmula confiable que pueda usar para determinar si el tamaño actual de la agrupación de almacenamientos intermedios es apropiado, ya que la RAM tiene un costo por GB asignado a cada servidor. Todo el entorno está virtualizado y la RAM "física" asignada a una VM se puede cambiar fácilmente hacia arriba o hacia abajo.
Tengo una instancia particular de SQL Server que estoy viendo ahora con un PLE de 1,100,052 segundos, lo que equivale a 12.7 días (la cantidad de tiempo que el servidor ha estado activo). El servidor tiene una configuración de memoria máxima del servidor de 2560 MB (2.5 GB), de los cuales solo 1380 MB (1.3 GB) están realmente comprometidos.
He leído varios artículos, incluido uno de Jonathan Keheyias ( publicación ) y otro de Paul Randal ( publicación ), y varios otros. Jonathan recomienda que el monitoreo de un PLE por debajo de 300 por 4 GB de agrupación de almacenamiento intermedio sea demasiado bajo. Para la instancia de SQL Server anterior, el 300 * (2.5 / 4) = 187
resultado es un PLE de destino realmente muy bajo por debajo de 300. Esta instancia tiene 290 GB de datos de SQL Server (sin incluir archivos de registro), y solo se usa para pruebas de integración. Suponiendo que los últimos 12 días son representativos del uso típico de este servidor, diría que la max server memory (mb)
configuración podría reducirse.
En el otro extremo de la escala, tengo otro servidor de prueba de integración con un PLE de 294, que tiene una max server memory (mb)
configuración de solo 1 GB. Este servidor tiene solo 224 MB de datos de SQL Server sin incluir registros, y está ejecutando algunas bases de datos BizFlow. Este servidor podría beneficiarse de una max server memory (mb)
configuración más alta .
Creo que un buen punto de partida para objetivos a los que se les puede asignar demasiada memoria podría incluir mirar:
SELECT
RamMB = physical_memory_in_bytes / 1048576
, BufferPoolCommittedMB = bpool_committed * 8192E0 / 1048576
, BufferPoolCommitTargetMB = bpool_commit_target * 8192E0 / 1048576
, PercentOfDesiredSizeMB = CONVERT(INT,(CONVERT(DECIMAL(18,2),bpool_committed)
/ bpool_commit_target) * 100)
FROM sys.dm_os_sys_info;
Si BufferPoolCommitTargetMB / BufferPoolCommittedMB
es mayor que 1, el servidor no está utilizando todo el grupo de búferes. Si la máquina en cuestión también tiene un PLE mayor que "x", entonces podría ser un buen candidato para una disminución en max server memory (mb)
.
Dado que el Buffer Manager:Lazy writes/sec
contador de rendimiento rastrea el número de veces que SQLOS ha escrito páginas en el disco entre puntos de control debido a la presión de la memoria, esto podría ser otra buena cosa a tener en cuenta.
DECLARE @WaitTime DATETIME;
SET @WaitTime = '00:00:15';
DECLARE @NumSeconds INT;
SET @NumSeconds = DATEDIFF(SECOND, 0, @WaitTime);
DECLARE @LazyWrites1 BIGINT;
DECLARE @LazyWrites2 BIGINT;
SELECT @LazyWrites1 = cntr_value
FROM sys.dm_os_performance_counters dopc
WHERE (
dopc.counter_name LIKE 'Lazy writes/sec%' COLLATE SQL_Latin1_General_CP1_CI_AS
)
AND dopc.object_name = 'MSSQL$' + CONVERT(VARCHAR(255),
SERVERPROPERTY('InstanceName')) + ':Buffer Manager';
WAITFOR DELAY @WaitTime;
SELECT @LazyWrites2 = cntr_value
FROM sys.dm_os_performance_counters dopc
WHERE (
dopc.counter_name LIKE 'Lazy writes/sec%' COLLATE SQL_Latin1_General_CP1_CI_AS
)
AND dopc.object_name = 'MSSQL$' + CONVERT(VARCHAR(255),
SERVERPROPERTY('InstanceName')) + ':Buffer Manager';
SELECT LazyWritesPerSecond = (@LazyWrites2 - @LazyWrites1) / @NumSeconds;
El código anterior supone que el servidor está bajo carga durante los 15 segundos que tarda en ejecutarse; de lo contrario, informará 0; que podría ser un falso negativo engañoso.
¿Debo también mirar las PAGELATCHIO_*
estadísticas de espera o algún otro tipo de espera como un indicador de la presión de la memoria, o la falta de ella?
Mi pregunta es, ¿cómo puedo determinar de manera confiable un valor objetivo "bueno" para PLE y max server memory (mb)
?
fuente
max server memory (mb)
, y como tal soy bastante reacio a reducir su tamaño. Sin embargo, algunas otras instancias tienen 1,000,000 + PLE, y como tales son candidatos potenciales bastante obvios para una caída de RAM. Claramente, la reducción de la RAM provocará un aumento de la OIA, y no estoy seguro de lo que el costo de que será.max server memory
entorno es una especie de cosa de pollo y huevo; cuanto menor sea lamax server memory
configuración, menor será el PLE mínimo "aceptable", por lo que podría quedar atrapado en una espiral cada vez más baja. Estoy seguro de que, como mencionas, el rendimiento del usuario se verá afectado en algún momento .El T-SQL actual que estoy usando para evaluar PLE vs
max server memory
es:Este código compara el PLE con un PLE "aceptable" mínimo para la cantidad de
max server memory
sistema que ha configurado. Si el PLE es apreciablemente más alto que el número aceptable, sugiere un máximo de 10% más bajomax server memory
. Si el PLE es más bajo que el PLE aceptable, sugiere un máximo de 10% másmax server memory
.Si la cantidad real de agrupación de almacenamiento intermedio comprometida es menor que el tamaño de la agrupación de almacenamiento intermedio de destino, sugiere reducir
max server memory
a esa cantidad, más algo de memoria adicional para subprocesos, escrituras diferidas, etc.El código también analiza varios contadores de rendimiento para cosas como Lazy Writes / second, Free List Stalls y Batch Requests.
El código no es perfecto, lo comparto aquí para obtener información y para el beneficio de los futuros usuarios de SO.
fuente