none
Memoria Virtual

    Pregunta

  • Estimados.

    Tengo un SS2005 con 24 GB de RAM, segun entiendo lo recomendado es que el minimo de la memoria virtual sea 1.5 veces la ram en este caso serian 36 GB y al maximo deber se el doble del minimo en este caso seria 72 GB.

    Estoy en lo correcto ? pues el maximo esta seteado en 5GB que consecuencias me traeria esto ?? ademas de que la BD esta en el disco D y la memoria virtual esta en el disco C:

     

    Atento a sus comentarios.

    CristianPM.

    jueves, 14 de julio de 2011 22:14

Respuestas

  • Hola.

    Por otros hilos que has iniciado, presupongo que cuando hablas de memoria virtual estás refiriéndote al fichero de paginación.

    Asumiendo esa suposición, para el caso de SQL Server no valen esas reglas que estás aplicando, ya que hay que evitar, sí o sí, que SQL Server use el fichero de paginación, el rendimiento sería pésimo. Así, crea tu fichero de paginación con 2 ó 4 Gb a lo sumo, lo justo para que te quepa un dump resumido. Y como siempre, limita el máximo de memoria que SQL Server puede tomar, para tu caso, comienza con 20 ó 22 Gb y de ahí es posible que debas seguir reduciendo.

    Dejarlo a su libre albedrío o ponerle 1.5 veces el tamaño de la memoria física que tenga el servidor es un error. Cabría un dump completo de la memoria, pero ¿de qué te serviría eso en caso de que se produzca un dump? De nada, no lo ibas a analizar. Y por contra, el servidor funcionará con un tamaño de memoria que no es el que realmente tiene, distorsionando su comportamiento (no sentiría presión de memoria, aunque así fuera, porque va a seguir contando con el fichero de paginación).


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande

    • Marcado como respuesta CristianPM viernes, 15 de julio de 2011 16:15
    viernes, 15 de julio de 2011 7:42
    Moderador
  • Totalmente de acuerdo con Alberto. Yo en tu caso me centraria en tener bien configurada la gestion de memoria RAM que hace SQL, en muchos casos esta configuración no es correcta y es la fuente de los problemas. A modo de resumen te comento:

    Que hay 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 el 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.


     Norman M. Pardell 

    ||Microsoft Certified IT Professional|| Database Administrator. Database Developer. SQL Server 2008

    • Marcado como respuesta CristianPM viernes, 15 de julio de 2011 16:15
    viernes, 15 de julio de 2011 9:27
  • Mi sugerencia es dejar que el sistema operativo gestione la memoria virtual... Como dice Carlos, también se puede probar a ver que tal, pero, por lo menos en lo que he ensayado, me ha ido muy bien dejando que el SO maneje el tamaño del archivo de paginación.

    Saludos,

     

     


    Guillermo Taylor F.

    IT Pro & Xbox gamer

    My blog

    • Marcado como respuesta CristianPM viernes, 15 de julio de 2011 16:15
    viernes, 15 de julio de 2011 1:04

Todas las respuestas

  • Que tal:

    No necesariamente  esa informacion est totalmente cierta, ahi influyen muchos factores, tales como Diseño de la BD, consultas manejo de indices, etc.

    Lo mejor que debe hacer es probar cada configuración y ajustarla a la mas adecuada de acuerdo a sus necesidades. Puede iniciar colocando la Memoria virtual en 24 GB e ir asignando los limites de memoria  a sql. Ir verificando el rendimiento con los contadores de memoria . Estos contadores le daran una aproximación mas exacta del comportamiento y de lo que debe realizar para afinar el servidor.

     

    Ahora si solo tiene 2 discos distribuya las bases de datos del sistema y las de usuario en los dos discos, ya que de plano va a tener problemas de rendimiento debido al corto número de spindles para la busqueda y actualizacion de datos.

     

    Un saludo,


    Saludos, Carlos A. Si la respuesta le ayudó, por favor márquela como útil.
    jueves, 14 de julio de 2011 22:26
  • Mi sugerencia es dejar que el sistema operativo gestione la memoria virtual... Como dice Carlos, también se puede probar a ver que tal, pero, por lo menos en lo que he ensayado, me ha ido muy bien dejando que el SO maneje el tamaño del archivo de paginación.

    Saludos,

     

     


    Guillermo Taylor F.

    IT Pro & Xbox gamer

    My blog

    • Marcado como respuesta CristianPM viernes, 15 de julio de 2011 16:15
    viernes, 15 de julio de 2011 1:04
  • Hola.

    Por otros hilos que has iniciado, presupongo que cuando hablas de memoria virtual estás refiriéndote al fichero de paginación.

    Asumiendo esa suposición, para el caso de SQL Server no valen esas reglas que estás aplicando, ya que hay que evitar, sí o sí, que SQL Server use el fichero de paginación, el rendimiento sería pésimo. Así, crea tu fichero de paginación con 2 ó 4 Gb a lo sumo, lo justo para que te quepa un dump resumido. Y como siempre, limita el máximo de memoria que SQL Server puede tomar, para tu caso, comienza con 20 ó 22 Gb y de ahí es posible que debas seguir reduciendo.

    Dejarlo a su libre albedrío o ponerle 1.5 veces el tamaño de la memoria física que tenga el servidor es un error. Cabría un dump completo de la memoria, pero ¿de qué te serviría eso en caso de que se produzca un dump? De nada, no lo ibas a analizar. Y por contra, el servidor funcionará con un tamaño de memoria que no es el que realmente tiene, distorsionando su comportamiento (no sentiría presión de memoria, aunque así fuera, porque va a seguir contando con el fichero de paginación).


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande

    • Marcado como respuesta CristianPM viernes, 15 de julio de 2011 16:15
    viernes, 15 de julio de 2011 7:42
    Moderador
  • Totalmente de acuerdo con Alberto. Yo en tu caso me centraria en tener bien configurada la gestion de memoria RAM que hace SQL, en muchos casos esta configuración no es correcta y es la fuente de los problemas. A modo de resumen te comento:

    Que hay 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 el 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.


     Norman M. Pardell 

    ||Microsoft Certified IT Professional|| Database Administrator. Database Developer. SQL Server 2008

    • Marcado como respuesta CristianPM viernes, 15 de julio de 2011 16:15
    viernes, 15 de julio de 2011 9:27