Cómo determinar la correcta configuración de SQL Server

Resumen

En este artículo se describe los siguientes valores de configuración y las consideraciones para su uso:
  • Máscara de afinidad
  • Agrupación compacta
  • Max Async IO
  • Max Worker Threads
  • Memoria
  • Aumento de prioridad
  • Set Working Set Size
SQL Server puede obtener un muy alto nivel de rendimiento con relativamente poco ajuste de la configuración. Puede obtener altos niveles de rendimiento mediante adecuada en las aplicaciones y el diseño de la base de datos y no mediante el ajuste de configuración extensa. Consulte la sección "Referencias" de este artículo para obtener información acerca de cómo solucionar diversos problemas de rendimiento de SQL Server.


Al solucionar un problema de rendimiento, el grado de mejora que está disponible en el ajuste de la configuración es típicamente modesto a menos que actualmente tiene el sistema configurado correctamente. En SQL Server versión 7.0 y posterior, SQL Server utiliza el ajuste de la configuración automática y es muy raro que los valores de configuración (configuración avanzada especialmente) necesitan realizar ningún cambio. Por lo general, no realice una configuración de SQL Server cambiar sin razón abrumadora y no sin cuidado metódico pruebas para comprobar la necesidad de que el cambio de configuración. Debe establecer una línea de base antes de cambiar de la configuración de modo que se puede medir el beneficio después del cambio.


Si no tiene SQL Server correctamente configurado, algunas configuraciones podrían desestabilizar el servidor o pueden hacer que SQL Server se comporte de forma errática. Años de experiencia en soporte con muchos entornos diferentes indican que los ajustes de configuración no predeterminada podrían tener resultados comprendidos entre neutral y muy negativa.

Si se realiza un cambio configuración, debe realizar riguroso pruebas antes y después del cambio para evaluar el grado de mejora de rendimiento metódico.

SQL Server versión 7.0 y posterior basados en escenarios reales, puede lograr un nivel muy alto de rendimiento sin ningún ajuste de la configuración manual.

En SQL Server versión 7.0 y posterior, no hace cambios en la configuración para las conexiones de usuarios, bloqueosy Abrir los objetos ya que, de forma predeterminada, SQL Server ajusta dinámicamente estos valores.

Máscara de afinidad

La configuración de máscara de afinidad hace referencia a cómo firmemente un subproceso está enlazado a ninguna CPU en concreto. De forma predeterminada, Microsoft Windows NT y Microsoft Windows 2000 utilizan la afinidad "suave", que intenta volver a programar un subproceso en la CPU donde ejecutaron por última vez. Sin embargo, si esto no es posible, un subproceso puede ejecutar en una CPU distinta.

En la práctica, si cambia la configuración de máscara de afinidad de la predeterminada sólo en raras ocasiones ayuda a rendimiento y con frecuencia se degradará el rendimiento.

Máscara de afinidad restringe de SQL Server a un subconjunto de la CPU disponibles y permite que otros competidores servicios mejor CPU acceso. En la mayoría de los casos, no necesita esto porque SQL Server se ejecuta con prioridad normal. El programador de subprocesos de Windows NT o Windows 2000 ajusta dinámicamente las prioridades de los subprocesos de todos los subprocesos que compiten para asegurarse de que tienen una oportunidad justa CPU disponibles en todo.

No ajustar la máscara de afinidad , salvo en condiciones muy inusuales. Si decide ajustar la máscara de afinidad, realizar pruebas metódico rigurosas antes y después del cambio para comprobar la necesidad y el grado de mejora.


Agrupación compacta

De forma predeterminada, SQL Server utiliza un subproceso por cada SPID activo o proceso de usuario. Estos subprocesos operan en una configuración agrupada para mantener el número de subprocesos manejable. La configuración avanzada opción "agrupación ligera" (que a veces se denomina "Modo de intraprocesos") utiliza la compatibilidad con Windows NT "fibra" esencialmente manejar diversos contextos de ejecución con un único subproceso.


Basado en la experiencia real de la producción, no es necesario utilizar el modo de intraprocesos excepto en circunstancias muy raras. Lightweight pooling es sólo resulta útil si se cumplen todas las condiciones siguientes. Debe determinar si es realmente apropiada mediante pruebas muy controladas.
  • Grandes servidores con varios procesadores están en uso.
  • Todos los servidores se ejecutan en o cerca de la capacidad máxima.
  • Un lote de cambios de contexto se produce (más de 20.000 por segundo).
Para buscar el cambio de contexto, utilice Monitor de rendimiento, seleccione los subprocesos de contador, seleccione el objeto cambios de contexto/s "y, a continuación, seleccione esta opción para capturar todas las instancias de SQL Server.
SQL Mail en SQL Server 2000 o en SQL Server 2005 no se admite si el servidor se ejecuta en modo de fibra. SQL Mail no se admite en SQL Server 2000 de 64 bits. Para obtener más información, vea el tema "Diferencias entre las versiones de 64 bits y 32 bits" en libros en pantalla de SQL Server 2000 (64-bit Edition).
Para obtener información adicional, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

308604 PRB: SQLMail no se admite cuando se ejecuta el servidor en modo de fibra

CORREGIR 303120 : ConnectionWrite error cuando utiliza la agrupación ligera

Max Async IO

SQL Server 7.0: el valor de configuración max async IO está disponible en SQL Server 7.0. Podría ser apropiado cambiar esta configuración si tiene un sistema RAID rápido y una forma de medir el beneficio. No cambie esta configuración a menos que tenga una línea de base por el que se va a medir el resultado. Supervisar la actividad del disco y busque problemas de cola de disco. Para obtener información adicional, consulte los siguientes temas en libros en pantalla de SQL Server:
  • "opción max async IO"
  • "Supervisar la actividad del disco"
  • "Identificar cuellos de botella"
SQL Server 2000 y versiones posterior: en SQL Server 2000 y versiones posterior, no puede cambiar la opción de configuración max async IO . SQL Server 2000 y versiones posterior ajusta automáticamente esta configuración.

Max Worker Threads

De forma predeterminada, el valor de la opción max worker threads es 255 en SQL Server 2000. Por lo tanto, hasta 255 trabajo se pueden crear subprocesos. Utilizar la configuración predeterminada de 255 en la mayoría de los casos. Esto no significa que sólo puede establecer conexiones de usuario 255. Un sistema puede tener miles de conexiones de usuario (que básicamente se multiplexan hasta 255 subprocesos de trabajo) y en general, los usuarios no suelen percibir los retrasos. En tal caso, sólo 255 consultas se pueden ejecutar simultáneamente, pero esto es multiplexado hacia abajo al número de CPU disponibles, por lo que sólo se percibe la naturaleza simultánea, independientemente del número de subprocesos de trabajo configurados.

Nota: De forma predeterminada, el valor de la opción max worker threads es 0 en SQL Server 2005 y SQL Server 2008.

Si configura un número de subprocesos de trabajo en un valor que es mayor que el valor predeterminado, que es casi siempre contraproducente y disminuye el rendimiento debido a la sobrecarga de recursos y programación. Sólo aumentar este valor en circunstancias muy especiales y cuando metódico rigurosas pruebas demuestra que es útil para ello.


Memoria


Vea el tema de libros en pantalla de SQL Server "Optimizar el rendimiento utilizando memoria opciones de configuración Server" para obtener información acerca de la configuración de memoria.

Para obtener más información acerca de cómo configurar la memoria para los servidores agrupados de SQL, consulte "Consideraciones de uso" en el tema de libros en pantalla de SQL Server, "Crear un clúster de conmutación por error."

Para obtener información adicional, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

274750 cómo configurar la memoria para más de 2 GB en SQL Server

Optimización de la memoria simple se requiere 224818 si SQL Server 7.0 y Exchange 5.5 Service Pack 2 se instalan en BackOffice Small Business Server 4.5

316749 PRB: puede no haber suficiente memoria virtual con gran número de bases de datos

Aumento de prioridad

De forma predeterminada, el valor de aumento de prioridad es 0, lo que hace que SQL Server para ejecutarse con una prioridad normal si ejecuta SQL Server en un equipo monoprocesador o en un equipo (SMP) de multiprocesador simétrico. Si establece la opción priority boost a 1, el proceso de SQL Server se ejecuta con una prioridad alta. Esta configuración no ejecutar el proceso de SQL Server con la máxima prioridad de sistema operativo.

Basado en la experiencia de soporte real, es necesario utilizar la opción priority boost para un buen rendimiento. Si utiliza la opción priority boost, puede interferir con servidor suave funciona bajo ciertas condiciones y no debe utilizarla excepto en circunstancias muy poco habituales. Por ejemplo, servicios de soporte técnico de Microsoft puede utilizar la opción priority boost cuando investiga un problema de rendimiento.

IMPORTANTE No utilice la opción priority boost para los servidores agrupados que ejecutan SQL Server 7.0 y versiones posteriores.

Set Working Set Size

No cambie establecer tamaño del conjunto de trabajo de la configuración predeterminada. Con el valor predeterminado es 0, el Administrador de memoria virtual de Windows NT o Windows 2000 puede determinar el tamaño del conjunto de trabajo de SQL Server. Al instalar SQL Server, el programa de instalación indicará automáticamente Windows NT o Windows 2000 para optimizar el rendimiento para aplicaciones de red. El Administrador de memoria virtual de Windows NT o Windows 2000, por tanto, lo recorta, muy poco conjunto de trabajo que sólo mínimamente interfiere con el conjunto de trabajo de las instancias de SQL Server.

Este cambio no suele proporciona ninguna ventaja de rendimiento. Basado en casos de soporte real, el cambio de esta configuración normalmente hace más daño que beneficio.

Si cambia a establecer tamaño del conjunto de trabajo, también puede ser una causa de los mensajes de error de SQL Server 844 o 845. Consulte la sección "Referencias" de este artículo para obtener más información acerca de las causas comunes de los mensajes de error 844 y 845.

Referencias

Para obtener información adicional, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

310834 PRB: las causas comunes de los mensajes de error 844 o 845 (errores de tiempo de espera de pestillo búfer)

298475 cómo solucionar problemas de rendimiento de aplicaciones

243589 cómo solucionar problemas de consultas de ejecución lenta en SQL Server 7.0 o posterior

243588 cómo solucionar problemas de rendimiento de consultas ad-hoc

224587 cómo solucionar problemas de rendimiento de aplicaciones con SQL Server

Valores de configuración adecuados 6.5 de SQL Server 166967

254321 agrupado de SQL Server qué hacer, contras y advertencias básicas

Consideraciones de rendimiento 297864 para realizar una actualización desde SQL Server 6.5

Propiedades

Id. de artículo: 319942 - Última revisión: 17 ene. 2017 - Revisión: 1

Comentarios