Blog gratis
Reportar
Editar
¡Crea tu blog!
Compartir
¡Sorpréndeme!
img
img

 

 

SQL Server
Blog. (Apuntes y Recopilaciones) por Norman M. Pardell

img
img

Asignar la cantidad correcta de Memoria para SQL Server

SQL SERVER usa dos tipos de memoria; una llamada BUFFER POOL – que está restringida por el parámetro de max server memory, y otra como proceso como tal que no está restringida y que puede llegar a ocupar dependiendo de las diferentes cargas de proceso entre 1 a 2 gb.

 

En SQL Server se pueden diferenciar dos grandes secciones de memoria:

 

-Memoria para paginas (Datos)

 

-Memoria del proceso de SQL

 

Sobre la memoria de proceso de SQL no tenemos control ninguno y SQL va a consumir la que crea necesaria (Normalmente en torno a 200M-300M) dependerá de servidores enlazados, proveedores de acceso, etc... y que puede llegar a ocupar dependiendo de las diferentes cargas de proceso entre 1 a 2 gb

 

Sobre la memoria de páginas tenemos más flexibilidad, podemos controlar su tamaño máximo “max server memory” tamaño minimo “min server memory” e incluso podemos habilitar una opción “lock pages in memory” que hace que las páginas de datos no puedan ser eliminadas por otros procesos del sistema.

 

En este artículo tenemos información sobre “max server memory” y “min server memory”:

http://msdn.microsoft.com/en-us/library/ms178067.aspx

 

Para configurar “max server memory” ejecutaremos:

 

sp_configure 'show advanced options', 1;

GO

RECONFIGURE;

GO

sp_configure 'max server memory', 3071;

GO

RECONFIGURE;

GO

 

Cambiamos el valor 3071 (valor en megas) por el que nos sea más conveniente.

 

Otros conceptos de la memoria de páginas:

 

Hay una diferencia fundamental entre las versiones de 32 bits y 64 bits de SQL Server.

En 32bits Windows divide el espacio de memoria(4GB) en dos bloques de 2GB, 2GB para el Kernel y 2GB para el proceso, por tanto sin ninguna opción avanzada más SQL Solo va a consumir 2GB de máximo (paginas + proceso)

En 64bits Windows divide rl espacio de memoria(16TB) en dos bloques de 8TB, 8TB para el Kernel y 8TB para el proceso por tanto en 64bits SQL va a consumir toda la memoria con la que esté configurado en “max server memory” + memoria para el proceso de SQL.

 

32 bits y más de 2GB para la memoria de páginas:

 

En las ediciones de 32bits existe la opción de usar más de 2GB, esta memoria extra solo se puede usar para páginas de memoria, el uso de esta memoria está apoyado en una API de Windows llamada AWE. Si AWE está activo SQL 32bits será capaz de usar tanta RAM para páginas como la especificada en “max server memory”

Más información sobre AWE: http://msdn.microsoft.com/es-es/library/ms190673(v=SQL.105).aspx

 

64bits y lock pages in memory:

 

En ediciones de 64 bits existe la posibilidad de habilitar “lock pages in memory” lo que provocara que el sistema operativo no pueda reclamar RAM a sql server en caso de necesitarlo, se recomienda ser prudente con esta opción, mientras que en Windows 2003 puede ser beneficioso esta opción en Windows 2008 no se considera tan necesario, de todas formas la activación de esta opción dependerá del entorno y uso de la base de datos.

Más información: http://msdn.microsoft.com/es-es/library/ms190730.aspx

 

Tanto AWE como “lock pages in memory” hacen que el sistema operativo no pueda reclamar esa memoria para otros procesos.

 

Contadores de Memoria a nivel de Sistema Operativo:

 

Yo siempre recomiendo usar los contadores del Performance Monitor:

Memory: Pages/sec. Indica el número de páginas que entran y salen de la caché en cada segundo. Su valor debe situarse muy cercano a 0. Si es mayor a 25 de forma continuada, tal vez no tengamos un problema de rendimiento, pero lo que es seguro es que la memoria no está siendo gestionada adecuadamente. Si se dispara este contador, quiere decir que la memoria física (RAM) esta siendo utilizada, en mas de un 85% , por este motivo esta paginando en disco, estaríamos en el caso de decir que el servidor necesita un aumento de  memoria RAM (física). (Si el contador no marca nada, quiere decir la memoria física asume toda la carga). Si hay picos, y estos se recuperan rápidamente  no es alarmante hay que estudiarlo.

Memory: Availability Mb (ó Kb ó Bytes, lo que más cómodo resulte). En general, debemos contar con 5 Mb de memoria libres (y disponibles) como mínimo.

 

SQL Server: Memory Manager: Total Server Memory y Target Server Memory. Estos dos contadores del mismo objeto nos dicen el total de memoria que tenemos y la memoria que necesitamos. "Total" debe ser igual que "Target". Si esto no es así, y "Total" es menor que "Target", es un indicio claro de un problema en la memoria, ya que tenemos menos de la que necesitamos.

 

Buffer Manager: "Total Pages", "Database Pages" y "Free Pages". Nos dan una idea de cómo anda el uso de la memoria de SQL Server.

 

Un contador muy interesante a vigilar es el "Buffer Cache Hit Ratio", que te da el porcentaje de aciertos en el caché a la hora de acceder a las páginas del disco. Debería tener un valor alto, del orden del 90%; si es menor, significa que le has asignado poca memoria al SQL Server. Si está siempre en el 100%, entonces vas sobrado de memoria

 

En alguna ocasión, aunque encontrareis a alguien que os dirá que si el servidor está dedicado a SQL Server, no le limites la memoria, que SQL puede tener picos en los que esa memoria le venga bien, y es mejor dejar que él la administre, salvo escenarios concretos en los que convenga limitarla… Yo siempre aconsejo que en SQL Server siempre debemos tener limitada la memoria, incluso aunque la máquina sea dedicada para SQL Server y sólo exista una instancia. Es recomendable limitarla porque hay que asegurarse que el sistema operativo disponga de memoria suficiente para trabajar. De penderá de la versión del sistema operativo, la cantidad de memoria que debamos impedir que use SQL Server.

 

Aunque en la mayoría de los casos para SQL Server toda memoria es siempre poca, así que cuanta más tenga, mejor responderá (y más importante será limitar el tamaño máximo).

 

Si os decidís a ajustar la memoria que usa SQL Server, fijaros sobre todo en los contadores de rendimiento: buffer cache hit ratio, que no baje significativamente. Y preguntar las sensaciones de los desarrolladores o usuarios que usan la aplicación que ataca a tu base de datos, no sea que perciban que les va lento.

 

Apunte y recopilación por Norman M. Pardell

Puedes consultarme, si deseas cualquier aclaración, pregunta o sugerencia en: Contacto, contestaré tan pronto como me sea posible.

publicado por normanmpardell a las 18:33 · Sin comentarios  ·  Recomendar
Comentarios (0) ·  Enviar comentario
Esta entrada no admite comentarios.
img
.Sobre mí
FOTO

Norman M. Pardell

MCITP: Database Administrator & Database Developer, SQL Server 2008. MCC Award Certificate. Consultor Senior de bases de datos en Capgemini España, S.L. Asesoramiento en implementación, desarrollo y gestión de bases de datos en grandes compañías. Actualmente, asignado a proyecto en compañía líder en el sector energético global. Más de 10 años trabajando con SQL Server (y otros gestores de BBDD)

» Ver perfil

img
.Secciones
» Inicio
img
.Enlaces
» Microsoft MSDN Foros
» Windows Server 2012
img
.Más leídos
» Asignar la cantidad correcta de Memoria para SQL Server
» Base de Datos Sospechosa (Suspect)
» Como modificar la Intercalación (Collation) en SQL Server
» Como renombrar una instancia de SQL Server. sp_dropserver. sp_addserver
» Detectar bloqueos. SQL Server V.2005 y superiores
» Funciones SQL Server. Funciones escalares y funciones con valores de tabla.
» Integridad y corrupción en las bases de datos: DBCC CHECKDB
» Log de transacciones ( .ldf ). SQL Server.
» Migrando SQL Server 2005, 2008, 2008 R2 a SQL Server 2012
» Transacciones activas. SQL server 2008
img
.Nube de tags [?]
                                                           
img img
FULLServices Network | Crear blog | Privacidad