La virtualización es muy popular para las organizaciones:les permite utilizar mejor el hardware mediante la combinación de varios servidores en un solo host, brinda capacidades HA y reduce varios costos, como calefacción/refrigeración, licencias de SQL Server y hardware. He estado involucrado en numerosos proyectos con organizaciones para ayudarlas a migrar de entornos físicos a virtuales y les he ayudado a experimentar estos beneficios.
Lo que quiero compartir con ustedes en este artículo es un problema peculiar que encontré mientras trabajaba con Hyper-V en Windows Server 2012 R2 usando memoria dinámica. Debo admitir que la mayor parte de mi conocimiento de la virtualización ha sido con VMware, sin embargo, eso está cambiando ahora.
Cuando trabajo con SQL Server en VMware, siempre recomiendo establecer reservas de memoria, por lo que cuando encontré esta función de memoria dinámica con Hyper-V, tuve que investigar un poco. Encontré un artículo (Guía de configuración de memoria dinámica de Hyper-V) que explica muchos de los beneficios y requisitos del sistema para usar la memoria dinámica. Esta característica es genial en cuanto a cómo puede proporcionar a una máquina virtual más o menos memoria sin tener que apagarla.
Experimentando con Hyper-V, descubrí que el aprovisionamiento de máquinas virtuales es sencillo y fácil de aprender. Con poco esfuerzo pude construir un entorno de laboratorio para simular la experiencia que estaba teniendo mi cliente. El mérito es de mi jefe por proporcionarme un hardware increíble con el que trabajar. Estoy ejecutando un Dell M6800 con un procesador i7, 32 GB de RAM y dos SSD de 1 TB. Esta bestia es mejor que muchos servidores en los que he trabajado.
Con VMware Workstation 11 en mi computadora portátil, creé un invitado de Windows Server 2012 R2 con 4 vCPU, 24 GB de RAM y 100 GB de almacenamiento. Una vez que se creó y parchó el invitado, agregué el rol de Hyper-V y aprovisioné un invitado en Hyper-V. El nuevo invitado se creó con Windows Server 2012 R2 con 2 vCPU, 22 GB de RAM y 60 GB de almacenamiento con SQL Server 2014 RTM.
Realicé tres conjuntos de pruebas, cada una con memoria dinámica. Para cada prueba, utilicé el generador de datos SQL de Red Gate contra la base de datos AdventureWorks2014 para llenar el grupo de búfer. Para la primera prueba, comencé con 512 MB para el valor de RAM de inicio, ya que esa es la cantidad mínima de memoria para iniciar Windows Server 2012 R2 y el grupo de búfer dejó de aumentar alrededor de los 8 GB.
Para cada prueba, truncaría mi tabla de prueba, cerraría el invitado, modificaría la configuración de la memoria y volvería a iniciar el invitado. Para la segunda prueba, aumenté la RAM de inicio a 768 MB y el grupo de búfer solo aumentó a poco más de 12 GB de tamaño.
Para la tercera y última prueba, aumentó la RAM de inicio a 1024 MB, ejecutó el generador de datos y el grupo de búfer pudo aumentar a poco menos de 16 GB.
Hacer un poco de matemática con estos valores muestra que el grupo de búfer no puede crecer más de 16 veces la RAM de inicio. Esto puede ser muy problemático para SQL Server si la RAM de inicio es inferior a 1/16 del tamaño de la memoria máxima. Pensemos en un invitado de Hyper-V con 64 GB de RAM que ejecuta SQL Server con un valor de RAM de inicio de 1 GB. Hemos observado que el grupo de búfer no podría usar más de 16 GB con esta configuración, pero si configuramos el valor de RAM de inicio en 4096 MB, entonces el grupo de búfer podría aumentar 16 veces, lo que nos permite usar los 64 GB.
Las únicas referencias que pude encontrar acerca de por qué el grupo de búfer está limitado a 16 veces el valor de RAM de inicio estaban en las páginas 8 y 16 del documento técnico, Mejores prácticas para ejecutar SQL Server con HVDM. Este documento explica que, dado que el valor de la memoria caché del búfer se calcula en el momento del inicio, es un valor estático y no crece. Sin embargo, si SQL Server detecta que se admite Hot Add Memory, aumenta el tamaño reservado para el espacio de direcciones virtuales para el grupo de búfer en 16 veces la memoria de inicio. Este documento también establece que este comportamiento afecta a SQL Server 2008 R2 y versiones anteriores; sin embargo, mi prueba se realizó en Windows Server 2012 R2 con SQL Server 2014, por lo que me comunicaré con Microsoft para actualizar el documento de mejores prácticas.
Dado que la mayoría de los DBA de producción no aprovisionan máquinas virtuales ni trabajan mucho en ese espacio, y los ingenieros de virtualización no están estudiando la última y mejor tecnología de SQL Server, puedo entender cómo esta información importante sobre cómo el grupo de búfer maneja la memoria dinámica es desconocida para muchos. de la gente.
Incluso seguir los artículos puede ser engañoso. En el artículo Guía de configuración de memoria dinámica de Hyper-V, la descripción de la RAM de inicio dice:
Especifica la cantidad de memoria necesaria para iniciar la máquina virtual. El valor debe ser lo suficientemente alto para permitir que se inicie el sistema operativo invitado, pero debe ser lo más bajo posible para permitir una utilización óptima de la memoria y tasas de consolidación potencialmente altas.¿Utilización óptima de la memoria para quién, el host o el invitado? Si un administrador de virtualización estuviera leyendo esto, probablemente determinaría que significa la memoria mínima permitida para iniciar el sistema operativo.
Ser responsable de SQL Server significa que debemos conocer otras tecnologías que pueden influir en nuestro entorno. Con la introducción de las SAN y la virtualización, debemos comprender completamente cómo las cosas en esos entornos pueden afectar negativamente a SQL Server y, lo que es más importante, cómo comunicar de manera efectiva las inquietudes a las personas responsables de esos sistemas. Un DBA no necesariamente necesita saber cómo aprovisionar almacenamiento en una SAN o cómo aprovisionar o ser capaz de administrar un entorno VMWare o Hyper-V, pero debe conocer los conceptos básicos de cómo funcionan las cosas.
Al conocer los conceptos básicos sobre cómo funciona una SAN con arreglos de almacenamiento, redes de almacenamiento, rutas múltiples, etc., así como también cómo funciona el hipervisor con la programación de CPU y la asignación de almacenamiento dentro de la virtualización, un DBA puede comunicarse mejor y solucionar problemas cuando surgen problemas. . A lo largo de los años, he trabajado con éxito con varios administradores de virtualización y SAN para crear estándares para SQL Server. Estos estándares son exclusivos de SQL Server y no se aplican necesariamente a servidores web o de aplicaciones.
Los DBA realmente no pueden confiar en los administradores de virtualización y SAN para comprender completamente las mejores prácticas para SQL Server, independientemente de lo bueno que sea, por lo que debemos educarnos lo mejor que podamos sobre cómo sus áreas de experiencia pueden afectarnos.
Durante mis pruebas, utilicé una consulta de la publicación de blog de Paul Randal, Problemas de rendimiento de la memoria del grupo de búfer desperdiciada, para determinar cuánto grupo de búfer estaba usando la base de datos AdventureWorks2014. He incluido el siguiente código:
SELECT
(CASE WHEN ([database_id] = 32767)
THEN N'Resource Database'
ELSE DB_NAME ([database_id]) END) AS [DatabaseName],
COUNT (*) * 8 / 1024 AS [MBUsed],
SUM (CAST ([free_space_in_bytes] AS BIGINT)) / (1024 * 1024) AS [MBEmpty]
FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id]; Este código también es excelente para solucionar problemas sobre cuál de sus bases de datos consume la mayor parte de su grupo de búfer, de modo que pueda saber en qué base de datos debe enfocarse para ajustar las consultas de alto costo. Si tiene una tienda de Hyper-V, consulte con su administrador para ver si la memoria dinámica se puede configurar de tal manera que afecte negativamente a su servidor.
