Tamaño de archivo de página recomendado para SQL 2008R2 en Windows 2008R2


25

Este artículo de Microsoft - Cómo determinar el tamaño de archivo de página apropiado para las versiones de 64 bits de Windows Server 2008 y / o Windows 2008 R2 proporciona orientación para calcular el tamaño de archivo de página para Windows 2008 y Windows 2008R2 de 64 bits. Sin duda, esto funciona bien para servidores de uso general. Me pregunto cuál es la guía para SQL Server 2008R2 que se ejecuta en Windows 2008 / R2 de 64 bits.

Supongo que queremos que tan poca información en la memoria llegue al archivo de la página, de lo contrario, SQL podría estar presionando el disco dos veces para obtener datos. ¿SQL Server incluso permite que los datos en la memoria lleguen al archivo de la página? He buscado libros en línea de SQL Server 2008 R2 en busca de orientación, pero aún no he encontrado ninguna mención al uso de archivos de página.

Este es un escenario de uso potencial: dado un servidor físico con 64 GB de RAM, ¿es necesario un archivo de paginación para los 64 GB de RAM completos? ¿Deberíamos prepararlo para 96 ​​GB de archivo de paginación? Eso parece un poco excesivo para un solo archivo. Sé que la sabiduría convencional ha sido que Windows acopla el archivo de paginación a la memoria en un intento de facilitar el intercambio de aplicaciones en la RAM, pero ¿es eso cierto? ¿Un archivo de paginación de menos de 64 GB obstaculizará el rendimiento aquí?

Respuestas:


15

No hay configuraciones especiales para SQL Server que solo usa memoria física normalmente

Simplemente haga lo que MS dice para Windows y listo

Ah, y compre más RAM de todos modos mientras somos uno el tema ... ;-)


6

Mira dentro lock pages in memory. De esta forma, puede dar preferencia a su cuenta de servicio SQL para usar la RAM disponible en lugar de paginar en el disco. Para leer más sobre las páginas bloqueadas en la memoria, consulte este enlace . Sigue un fragmento:

La opción Bloquear páginas de la política de Windows en memoria está deshabilitada de manera predeterminada. Este privilegio debe estar habilitado para configurar las Extensiones de ventana de dirección (AWE). Esta política determina qué cuentas pueden usar un proceso para mantener los datos en la memoria física, evitando que el sistema pagine los datos a la memoria virtual en el disco. En los sistemas operativos de 32 bits, establecer este privilegio cuando no se usa AWE puede afectar significativamente el rendimiento del sistema. No es necesario bloquear páginas en la memoria en sistemas operativos de 64 bits.

Pruebe esta función antes de usarla en sus sistemas.


44
"Bloquear páginas en la memoria" quizás podría describirse mejor como una protección, para evitar que el sistema operativo pagine la memoria SQL. support.microsoft.com/kb/918483
Mark Storey-Smith

4

Sí, para 64 GB de RAM necesita al menos 64 GB de archivo de intercambio (se recomiendan 96 GB). No por un posible intercambio, sino por el diseño del Administrador de memoria de Windows. He escrito sobre este problema antes en el tamaño del archivo de paginación del sistema en máquinas con RAM grande :

Cuando un proceso solicita MEM_COMMITmemoria 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 hoy en día. Vea Administración de 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.

La alternativa sería algo como el oom_killer .

Así que siga la recomendación, a veces las cosas son un poco más complejas de lo que parecen. Y ni siquiera he tocado las complicaciones traídas por AWE y el privilegio de bloqueo de páginas ...


Muy interesante ... ¿Cómo funciona entonces cuando configura un archivo de intercambio más pequeño que la RAM en la máquina? Si de hecho necesitamos reservar el espacio en el archivo de paginación para cada asignación de memoria, ¿no podríamos usar más memoria que el tamaño del archivo de página? No estoy seguro de cómo funciona en la práctica.
shlomoid

1
Así es exactamente como funciona en la práctica. Una región VA comprometida debe estar respaldada por una reserva de intercambio real. Una región VA reservada no tiene que serlo, pero SQL Server prácticamente nunca solicita reservas no comprometidas.
Remus Rusanu

2
No creo que esto sea correcto. Según tengo entendido de varias fuentes, como los libros de Windows Internals, el espacio de direcciones virtuales comprometido debe estar respaldado por algo físico , ya sea un archivo de página o RAM. Entonces, si intenta confirmar la memoria virtual> ([Memoria física que Windows ve] + [Tamaño del archivo de paginación]), recibirá el infame mensaje de error "Su sistema tiene poca memoria virtual". Mark Russinovich habla sobre esto en la sección titulada "memoria comprometida" aquí .
James L

55
Creo que puede confirmarse a sí mismo que las regiones de VA comprometidas no tienen que estar respaldadas por reservas de intercambio simplemente iniciando un sistema sin archivo de paginación y confirmando que Windows se inicia, y por lo tanto debe haber más de 0 bytes de VAS comprometidos.
James L

Esta publicación es incorrecta: es perfectamente posible ejecutarla sin un archivo de página si tiene más memoria que los requisitos máximos de confirmación. Sin embargo, significará que no puede escribir volcados de memoria.
Steve365
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.