Configuraciones en maquinas virtuales (Memoria - LOCK PAGES IN MEMORY)
Como hemos visto un poco sobre memoria últimamente quería tocar un tema importante, que en la actualidad es de un uso cotidiano en las empresas y hasta para aquellos que quieren aprender, las máquinas virtuales, sean estas en VMWARE, Hyper-v, Red Hat, Citrix, etc.
Primero tenemos que estar conscientes de que no importa que tan parecidas sean a una máquina física, nunca tendrán las características de una máquina física, aunque claro que su costo es mas ínfimo, de fácil escalabilidad y control. Pero esto viene con un costo, su velocidad es menor, existe una nueva capa de control que puede alterar el comportamiento de las máquinas, en la capa física o host de las mismas. Para esto el primer paso es saber que debemos de pedirle a nuestra área de infraestructura y saber si la versión de Sistema operativo es soportada por el virtualizador. Para esto podemos acudir a esta página de Windows si usamos estos sistemas operativos (http://windowsservercatalog.com), como nota recuerden que ya pronto sale de soporte el Windows Server 2003, así que planean sus migraciones.
Aquí encontramos el primer problema, que pasa cuando un proveedor de virtualización dice si soportar el OS y Microsoft dice que no es compatible al 100%, problemas y aunque el área de soporte intentara ayudarlos, están limitados porque no son expertos en estas herramientas de virtualización.
Entre las características que son más prominentes en las máquinas virtuales está el hecho de poder hacer un overcommit de recursos, a que nos referimos, en que la máquina virtual se le dan una cantidad de recursos que no tiene el host físico o que no siempre pueden estar disponibles para la misma. El overcommit es básicamente cuando existe algún modelo de balanceo de recursos, por ejemplo tenemos 20 máquinas virtuales, cada una con 4gb, pero el host solo tiene 64gb, aunque cada máquina tienen 4gb lo que hace el virtualizador es mover recursos de manera dinámica tomando de una máquina que no los está usando a una que si los requiere. En teoría es muy útil y nos permite mantener un buen número de máquinas usando el mayor % de recursos.
Pero qué pasa cuando SQL Server quiere acceder a una página de información que subió de memoria de una consulta anterior, de algún plan que debería estar en memoria, en el mejor de los casos hará un nuevo plan y volverá a hacer la petición al storage, lo cual creara una demora, ahora aún mayor porque fue y busco algo que ya no existe, luego lo busca de nuevo en el storage, lo sube a memoria y entrega el resultado, en el peor de los casos nos topares con un mensaje parecido a:
- "There is insufficient memory to run this query"
- No levantara de instancia
- Hará un crash generando un dump con invalid memory Access
Las recomendaciones por lo tanto para SQL son, no usa overcommit de memoria, en máquinas virtuales usar “LOCK PAGES IN MEMORY” bajo las políticas locales en la cuenta que levanta SQL Server, y tener el plan de energía en high performance.
- Para hacer esto debemos de primero poner el max memory settings.
- Tenemos que verificar que cuenta es la que esta levantando el servicio de SQL Server, lo podemos ver por medio de services.msc o por medio del SQL Server Configuration Manager.
- Una vez que tengamos este valor ponemos "secpol.msc"
- Aquí buscaremos en "Local Policies" > "User Rights Assigments" > "Lock pages in memory" y añadiremos la cuenta de servicio, reiniciamos la instancia y listo.
Comentarios
Publicar un comentario