sql-server - mssql - sql server 2017 on linux and docker containers
Tamaño de archivo de página O/S de Windows apropiado para SQL Server (8)
¿Alguien sabe una buena regla general para el tamaño de archivo de paginación apropiado para un servidor de Windows 2003 que ejecuta SQL Server?
Si busca un alto rendimiento, querrá evitar la paginación por completo, por lo que el tamaño del archivo de página será menos significativo. Invierta en la mayor cantidad de RAM posible para el servidor de bases de datos.
Cuanto mayor sea, mejor será el tamaño del conjunto de trabajo de la aplicación, donde empezará a obtener rendimientos decrecientes. Puede intentar encontrar esto aumentando o disminuyendo lentamente el tamaño hasta que vea un cambio significativo en las tasas de aciertos de caché. Sin embargo, si la tasa de aciertos de caché es superior al 90%, probablemente estés bien. En general, debe vigilar esto en un sistema de producción para asegurarse de que no haya superado su asignación de RAM.
Recientemente tuvimos algunos problemas de rendimiento con uno de nuestros SQL Server que no pudimos restringir por completo, y en realidad usamos uno de nuestros tickets de asistencia de Microsoft para ayudarlos a solucionar los problemas. Apareció el tamaño óptimo de archivo de paginación para usar con SQL Server, y la recomendación de Microsoft es que sea 1 1/2 veces la cantidad de RAM .
Independientemente del tamaño de la memoria RAM, aún necesita un archivo de paginación al menos 1.5 veces la cantidad de RAM física. Esto es cierto, incluso si tiene una máquina de RAM de 1 TB, necesitará un archivo de paginación de 1.5 TB en el disco (suena loco, pero es cierto).
Cuando un proceso solicita memoria a MEM_COMMIT a través de VirtualAlloc / VirtualAllocEx, el tamaño solicitado debe reservarse en el archivo de paginación. Esto fue cierto en el primer sistema Win NT, y sigue siendo cierto en la actualidad, ver Administrar la memoria virtual en Win32 :
Cuando se confirma la memoria, se asignan páginas físicas de memoria y se reserva espacio en un archivo de paginación .
Descubierto algunos casos extremos extraños, SQL Server siempre pedirá páginas MEM_COMMIT. Y dado que SQL utiliza una política de administración de memoria dinámica que reserva por adelantado la mayor cantidad posible de agrupaciones de almacenamientos intermedios (reservas y confirmaciones en términos de VAS), SQL Server solicitará al iniciar una gran reserva de espacio en el archivo de paginación. Si el archivo de paginación no tiene el tamaño correcto, los errores 801/802 comenzarán a aparecer en el archivo y las operaciones de ERRORLOG de SQL.
Esto siempre causa cierta confusión, ya que los administradores suponen erróneamente que una gran RAM elimina la necesidad de un archivo de paginación. En verdad, sucede lo contrario, una RAM grande aumenta la necesidad de un archivo de paginación, solo por el funcionamiento interno del administrador de memoria de Windows NT. El archivo de paginación reservado es, afortunadamente, nunca usado.
Después de mucha investigación, nuestros servidores SQL dedicados que ejecutan Enterprise x64 en Windows 2003 Enterprise x64 no tienen archivo de página.
Simplemente, el archivo de página es un caché para los archivos que el SO administra y el SQL tiene su propio sistema de administración de memoria interna.
El artículo de MS al que se hace referencia no califica que el consejo es para el sistema operativo que ejecuta servicios listos para usar, como el uso compartido de archivos.
Tener un archivo de página simplemente carga la E / S del disco porque Windows está intentando ayudar, cuando solo el SO SQL puede hacer el trabajo.
Con el debido respeto a Remus (a quien respeto mucho), estoy totalmente en desacuerdo. Si su archivo de página es lo suficientemente grande como para admitir un volcado completo, realizará un volcado completo cada vez. Si tiene una gran cantidad de RAM, esto puede causar que una pequeña señal se convierta en una interrupción importante.
NO querrá que su servidor tenga que escribir 1 TB de RAM en el disco si hay un problema transitorio de una sola vez. Si hay un problema recurrente, puede aumentar el archivo de página para capturar un volcado completo. Esperaría a hacer esto hasta que PSS (o alguien más calificado para analizar un volcado completo) te haya pedido que solicite la captura de un volcado completo. Un porcentaje extremadamente pequeño de DBA sabe cómo analizar un vertedero completo. Un mini-volcado es suficiente para solucionar la mayoría de los problemas que aparecen de todos modos.
Además, si su servidor está configurado para permitir un volcado total de 1 TB y se produce un problema recurrente, ¿cuánto espacio libre de disco recomendaría tener a mano? Podría llenar una SAN completa en un solo fin de semana.
Un archivo de página de 1.5 * RAM era la norma en los días en que tenía la suerte de tener un servidor SQL con 3 o 4 GB de RAM. Este ya no es el caso. Dejo el archivo de la página en el tamaño y la configuración predeterminados de Windows en todos los servidores de producción (a excepción de un servidor SSAS que está experimentando la presión de la memoria).
Y solo por aclaración, he trabajado con servidores que van desde 2 GB de RAM a 2 TB de RAM. Después de más de 11 años, solo tuve que aumentar el archivo de paginación para capturar un volcado completo una vez.
Según Microsoft, "a medida que aumenta la cantidad de RAM en una computadora, la necesidad de un archivo de página disminuye". A continuación, el artículo describe cómo usar los registros de rendimiento para determinar qué parte del archivo de la página se está utilizando en realidad . Intente configurar su archivo de página en la memoria del sistema 1.5X para comenzar, luego realice la monitorización recomendada y realice los ajustes desde allí.
Cómo determinar el tamaño de archivo de página apropiado para las versiones de 64 bits de Windows
En este caso, la recomendación normal de 1.5 veces la RAM física total no es la mejor. Esta recomendación muy general se proporciona bajo la suposición de que toda la memoria está siendo utilizada por procesos "normales", que generalmente pueden mover sus páginas menos usadas al disco sin generar problemas de rendimiento masivos para el proceso de aplicación al que pertenece la memoria.
Para los servidores que ejecutan SQL Server (generalmente con cantidades muy grandes de RAM), la mayoría de la memoria RAM física está comprometida con el proceso de SQL Server y debe estar (si está configurada correctamente) bloqueada en la memoria física, evitando que se pagine en el archivo de paginación . SQL Server maneja su propia memoria con mucho cuidado teniendo en cuenta el rendimiento, y usa una gran parte de la RAM asignada a su proceso como memoria caché de datos para reducir la E / S del disco. No tiene sentido publicar esas páginas de caché de datos en el archivo de paginación, ya que el único propósito de tener esos datos en la RAM en primer lugar es reducir las E / S de disco. (Tenga en cuenta que el sistema operativo Windows también utiliza RAM disponible como memoria caché de disco para acelerar el funcionamiento del sistema). Dado que SQL Server ya administra su propio espacio de memoria, este espacio de memoria no debe considerarse "paginable" y no se incluye en un cálculo de archivo de paginación tamaño.
Con respecto a MEM_COMMIT mencionado por Remus, la terminología es confusa porque en el lenguaje de la memoria virtual, "reservado" nunca se refiere a la asignación real, sino a evitar el uso de un espacio de direcciones (no espacio físico) por otro proceso. La memoria disponible para ser "comprometida" es básicamente igual a la suma de la RAM física y el tamaño del archivo de paginación, y hacer un MEM_COMMIT simplemente disminuye la cantidad disponible en el grupo comprometido. No asigna una página coincidente en el archivo de paginación en ese momento. Cuando se escribe una página de memoria comprometida, es cuando el sistema de memoria virtual asigna una página de memoria física y posiblemente coloca otra página de memoria desde la RAM física al archivo de paginación. Consulte la referencia de la función VirtualAlloc de MSDN.
El sistema operativo Windows hace un seguimiento de las presiones de memoria entre los procesos de la aplicación y su propio mecanismo de caché de disco y decide cuándo debe pasar las páginas de memoria no bloqueadas de las físicas al archivo de paginación. Según tengo entendido, tener un archivo de paginación demasiado grande en comparación con el espacio de memoria real no bloqueado puede hacer que Windows canalice la memoria de la aplicación hacia el archivo de paginación, lo que hace que esas aplicaciones sufran las consecuencias de errores de página (rendimiento lento).
Siempre que el servidor no ejecute otros procesos que requieren mucha memoria, un tamaño de archivo de paginación de 4GB debería ser suficiente. Si ha configurado SQL Server para permitir el bloqueo de páginas en la memoria, también debería considerar establecer la configuración de memoria máxima de SQL Server para que deje algo de RAM física disponible para el sistema operativo y otros procesos.
Los errores 802 en SQL Server indican que el sistema no puede comprometer más páginas para la memoria caché de datos. Aumentar el tamaño del archivo de paginación solo ayudará en esta situación en la medida en que Windows pueda enviar la memoria desde procesos que no son de SQL Server. Permitir que la memoria de SQL Server crezca en el archivo de paginación en esta situación podría eliminar los mensajes de error, pero es contraproducente, debido al punto anterior sobre el motivo de la caché de datos en primer lugar.