Opciones de configuración de Procesador
Introducción
Ya hemos indicado que algunas opciones de configuración en Microsoft SQL Server pueden identificarse como avanzadas, por lo que en caso de utilizar el procedimiento almacenado de sistema sp_configure, se debe habilitar la posibilidad de despliegue de dichas opciones avanzadas.
Ahora
veremos las opciones que están relacionadas con el procesador, estas opciones
son:
Nombre de opción
|
Descripción
|
affinity I/O mask
|
máscara de afinidad de E /
S
|
affinity mask
|
máscara
de afinidad
|
affinity64 I/O mask
|
máscara affinity64 de E / S
|
affinity64 mask
|
máscara
affinity64
|
lightweight pooling
|
El planificador de modo de
usuario usa la agrupación liviana
|
max worker threads
|
Máximo de hilos de trabajo
|
priority boost
|
Aumento de prioridad
|
Opciones affinity mask y affinity I/O mask
Con el objetivo de llevar a cabo la multitarea, Microsoft Windows en ocasiones mueve los hilos de proceso entre los diferentes procesadores. Ésta asignación de procesadores a subprocesos específicos puede mejorar el rendimiento bajo cargas pesadas del sistema, ya que cada caché del procesador se carga repetidamente con datos al eliminar las recargas del procesador y reducir la migración de subprocesos en los procesadores (lo que reduce el cambio de contexto); tal asociación entre un hilo y un procesador se llama afinidad del procesador. Aunque es eficiente desde el punto de vista de un sistema operativo, esta actividad puede reducir el rendimiento de Microsoft SQL Server.
Microsoft SQL Server admite la afinidad del procesador mediante dos opciones de
máscara de afinidad: máscara de afinidad (de CPU) y máscara de afinidad de E / S. Es importante
indicar que estas opciones de configuración solo se utilizan para hasta 32
procesadores, en caso de que existan más procesadores, entonces el soporte de
afinidad de CPU y E / S para servidores con 33 a 64 procesadores requiere el
uso adicional de la máscara de affinity64 de CPU y de E / S, respectivamente,
por lo tanto, el soporte de afinidad para servidores con 33 a 64 procesadores
solo está disponible en sistemas operativos de 64 bits.
Microsoft ha anunciado que ésta característica se eliminará en una
versión futura de Microsoft SQL Server, por lo que se recomienda que ya no se
use esta característica, en su lugar sebe utilizarse la sentencia de Transact-SQL
ALTER SERVER CONFIGURATION.
Los cambios que se lleven a cabo en las máscaras de afinidad se producen
dinámicamente, lo que permite el inicio y el cierre a demanda de los
programadores de la CPU que vinculan los procesos de los subprocesos dentro de Microsoft SQL Server. Esto puede ocurrir a medida que las condiciones cambian en el
servidor. Las modificaciones a las
máscaras de bits de afinidad requieren que Microsoft SQL Server habiliten un nuevo
programador de CPU y deshabilite el programador de CPU existente. Los nuevos
lotes se pueden procesar en los planificadores nuevos o restantes.
Las tareas
de afinidad de E / S (como lazywriter y logwriter) se ven directamente
afectadas por la máscara de afinidad de E / S. Si las tareas de escritura
diferida y de escritura no están afinizadas, siguen las mismas reglas definidas
para las otras tareas permanentes como el monitor de seguridad o el punto de
control.
Para
garantizar que la nueva máscara de afinidad sea válida, es requerido el uso del
comando RECONFIGURE para verificar que las máscaras de CPU y de E / S sean mutuamente excluyentes. Si
este no es el caso, se informa un mensaje de error a la sesión del cliente y al
registro de errores del servidor Microsoft SQL Server, lo que indica que no se recomienda
dicha configuración.
Para
especificar la opción de configuración de máscara de afinidad de E / S, debe
usarse en conexión con la opción de configuración de máscara de afinidad. Es importante
no habilitar la misma CPU tanto en el conmutador de máscara de afinidad como en
la opción de máscara de afinidad de E / S. Los bits correspondientes a cada CPU
deben estar en uno de estos tres estados:
·
0
en la opción de máscara de afinidad y en la opción de máscara de afinidad de E
/ S.
·
1
en la opción de máscara de afinidad y 0 en la opción de máscara de afinidad de
E / S.
·
0
en la opción de máscara de afinidad y 1 en la opción de máscara de afinidad de
E / S.
NOTA:
Evite configurar la afinidad de CPU
en el sistema operativo Windows y también la máscara de afinidad en SQL Server.
Ya que se intentará lograr el mismo resultado, y si las configuraciones son
inconsistentes, por lo que pueden tener resultados impredecibles. La afinidad
de CPU de SQL Server se configura mejor utilizando la opción sp_configure en SQL Server.
Es
importante indicar que la afinidad dinámica está muy limitada por las licencias
de CPU. Microsoft SQL Server no permite ninguna configuración de opciones de máscara de
afinidad que viole la política de licencias.
La opción
de configuración de máscara de afinidad es una opción avanzada. Si se utiliza el
procedimiento almacenado del sistema sp_configure
para establecer la configuración, recuerde habilitar que se muestren las opciones
avanzadas. Después de ejecutar el comando RECONFIGURE el valor solicitado se
aplica inmediatamente sin necesidad de reiniciar los servicios de Microsoft SQL Server.
Como
ejemplo de opción de configuración de la máscara de afinidad, si los
procesadores 1, 2 y 5 se seleccionan como disponibles con los bits 1, 2 y 5
configurados en 1 y los bits 0, 3, 4, 6 y 7 configurados en 0, entonces se
especifica el valor decimal de 38. Recuerde que se numeran los bits de derecha
a izquierda y se obtiene el valor binario, que debe convertirse a un valor
decimal para indicarlo. La opción de máscara de afinidad comienza a contar los
procesadores de 0 a 31, de modo que en el ejemplo el contador 1 representa el
segundo procesador en el servidor.
sp_configure 'affinity mask', 38;
RECONFIGURE;
GO
De esta forma los procesadores 0, 3, 4, 6 y 7
pueden ser usados en una máscara de afinidad de E/S, si se desea que los procesadores
6 y 7 sean configurados en la máscara de afinidad de E/S, se puede especificar
el valor decimal de 192.
sp_configure 'affinity I/O
mask', 192;
RECONFIGURE;
GO
Opción lightweight pooling
Para
proporcionar un medio de reducir la sobrecarga del sistema asociada con la
excesiva conmutación de contexto que a veces se ve en entornos de
multiprocesamiento simétrico (SMP) se ha incluido la opción de configuración de
agrupación ligera (lightweight pooling).
Cuando hay una excesiva conmutación de contexto ésta opción puede proporcionar
un mejor rendimiento al realizar el cambio de contexto en línea, lo que ayuda a
reducir las transiciones entre el usuario y el anillo del núcleo.
El modo de
fibra está destinado a ciertas situaciones en las que el cambio de contexto de
los trabajadores de UMS es el cuello de botella crítico en el rendimiento.
Debido a que éste comportamiento es raro, el modo de fibra rara vez mejora el
rendimiento o la escalabilidad en un sistema típico. El cambio de contexto
mejorado que se ha encontrado en el sistema operativo Windows ha reducido la
necesidad del modo de fibra. No es recomendable que se utilice la programación
de modo de fibra en una operación de rutina. Esto puede disminuir el
rendimiento al inhibir los beneficios habituales del cambio de contexto y
porque algunos componentes de Microsoft SQL Server que usan Thread Local Storage (TLS) u
objetos propiedad de hilos, no pueden funcionar correctamente en modo fibra.
Si el valor
de la opción de configuración de agrupamiento ligero se establece en 1 hace que Microsoft SQL Server cambie a la programación de modo de fibra. El valor predeterminado
para esta opción de configuración es 0, indicando que no se active modo de fibra.
Ésta opción de configuración es una opción avanzada. Por lo que, sí se utiliza el
procedimiento almacenado del sistema sp_configure
para cambiar el valor de la configuración, debe permitir el despliegue de las
opciones avanzadas. La opción de configuración es clasificada como no dinámica,
por lo que el valor se aplica después de que se reinicien los servicios del Microsoft SQL
Server.
sp_configure 'lightweight
pooling', 1;
RECONFIGURE;
GO
Opción max worker threads
La opción de configuración max worker threads configura la cantidad de subprocesos de trabajo disponibles para los procesos de Microsoft SQL Server. Microsoft SQL Server utiliza los servicios de subprocesos nativos de los sistemas operativos para que uno o más subprocesos admitan cada red que Microsoft SQL Server admite simultáneamente, otro subproceso controla puntos de control de base de datos y un conjunto de subprocesos maneja a todos los usuarios. El valor predeterminado para esta opción de configuración max worker threads es 0. Este valor le permite a Microsoft SQL Server configurar de forma automática el número de subprocesos de trabajo al inicio de los servicios de Microsoft SQL Server. Es recomendable que se mantenga el valor de la opción de configuración de manera predeterminada, ya que esto es mejor para la mayoría de los sistemas. No obstante, dependiendo de la configuración del sistema, el valor de la opción de configuración de max worker threads puede ser cambiado a un valor específico para mejorar el rendimiento.
La
agrupación de subprocesos ayuda a optimizar el rendimiento cuando hay un gran
número de clientes conectados al servidor. En general, se crea un subproceso de
sistema operativo por separado para cada solicitud de consulta. Sin embargo,
con cientos de conexiones al servidor, el uso de un hilo por solicitud de
consulta puede consumir grandes cantidades de recursos del sistema. La opción
de configuración max worker threads
permite crear un conjunto de subprocesos de trabajo para atender un mayor
número de solicitudes de consulta, lo que mejora el rendimiento.
Esta opción
de configuración es una opción avanzada. Si existe sospecha que hay un problema
de rendimiento, probablemente no sea la disponibilidad de subprocesos de
trabajo. La causa es más probable que sea algo como E / S lo que hace que los
subprocesos de trabajo esperen. Lo mejor es encontrar la causa raíz de un
problema de rendimiento antes de cambiar el valor de la configuración de max worker threads.
La opción de configuración max
worker threads no toma en cuenta los subprocesos que se requieren para
todas las tareas del sistema, como los grupos de disponibilidad, Service
Broker, Lock Manager y otros. Si se supera el número de subprocesos
configurados, la siguiente consulta proporcionará información sobre las tareas
del sistema que han generado los subprocesos adicionales:
SELECT
s.session_id, r.command, r.[status],
r.wait_type, r.scheduler_id, w.worker_address,
w.is_preemptive, w.[state], t.task_state,
t.session_id, t.exec_context_id, t.request_id
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_exec_requests AS r
ON s.session_id = r.session_id
INNER JOIN sys.dm_os_tasks AS t
ON r.task_address = t.task_address
INNER JOIN sys.dm_os_workers AS w
ON t.worker_address = w.worker_address
WHERE s.is_user_process
=
0;
Si todos
los subprocesos de trabajo están activos con consultas de larga ejecución, Microsoft SQL
Server puede parecer insensible hasta que una cadena de trabajo finalice y esté
disponible. Si bien esto no es un defecto, a veces puede ser indeseable. Si un
proceso parece no responder y no se pueden procesar nuevas consultas, conéctese
a Microsoft SQL Server utilizando la conexión de administrador dedicada (DAC) y elimine
el proceso. Para evitar esto, aumente la cantidad de subprocesos máximo de
trabajo.
La opción
de configuración max worker threads
es una opción avanzada. Si se utiliza el procedimiento almacenado del sistema sp_configure para establecer la
configuración, recuerde habilitar que se muestren las opciones avanzadas. Asimismo,
ésta opción de configuración cuando se cambia de valor tendrá efecto
inmediatamente después de ejecutar RECONFIGURE, sin requerir que se reinicien
los servicios de Microsoft SQL Server.
Por ejemplo,
si se desea limitar el número máximo de trabajos en 900, se utiliza la
siguiente instrucción:
EXEC sp_configure 'max worker threads', 900;
RECONFIGURE;
GO
Opción priority boost
Normalmente Windows
Server tiene hilos programados para ejecutarse según su prioridad de
programación. Cada hilo tiene asignada una prioridad de programación y los
valores van desde cero (prioridad más baja) hasta 31 (prioridad más alta). De esta
forma se puede indicar que el sistema trata todos los hilos con la misma prioridad
como iguales. El sistema asigna intervalos de tiempo en forma de todos contra
todos con la máxima prioridad. Si ninguno de estos subprocesos está listo para
ejecutarse, el sistema asigna intervalos de tiempo de forma rotativa a todos
los subprocesos con la siguiente prioridad más alta. Si un hilo de mayor
prioridad está disponible para ejecutarse, el sistema deja de ejecutar el hilo
de menor prioridad (sin permitir que termine de usar su segmento de tiempo), y
asigna un corte de tiempo completo al hilo de mayor prioridad. La prioridad de
cada hilo está determinada por los siguientes criterios:
- La prioridad de clase de su proceso
- El nivel de prioridad del subproceso dentro de la clase de prioridad de su proceso
Si se establece el
valor de ésta opción de configuración priotity
boost en 1, entonces Microsoft SQL Server se ejecuta en una base de prioridad de 13
en el programador de Windows. El valor predeterminado de ésta opción de
configuración es 0, lo que significa una base de prioridad de 7 en Windows.
Es
importante indicar que elevar el valor de la prioridad demasiado alto puede
drenar los recursos del sistema operativo esencial y las funciones de red, dando
como resultado problemas al cerrar Microsoft SQL Server o al realizar otras tareas del
sistema operativo en el servidor.
NOTA:
Microsoft ha indicado que ésta característica se eliminará en una
versión futura de Microsoft SQL Server. Se recomienda no usar esta
característica.
Ésta opción
de configuración es una opción avanzada. Por lo que, sí se utiliza el
procedimiento almacenado del sistema sp_configure
para cambiar el valor de la configuración, debe permitir el despliegue de las
opciones avanzadas. La opción de configuración es clasificada como no dinámica,
por lo que el valor se aplica después de que se reinicien los servicios del Microsoft SQL
Server.
EXEC sp_configure 'priority boost', 1;
RECONFIGURE;
GO
Comentarios
Cuando se
llegue a cambiar el valor de la opción de configuración de una máscara de
afinidad (affinity mask) específica y
esta llega a violar la política de licencia, la ejecución del comando RECONFIGURE
informará por medio de un mensaje de error en la sesión del cliente y en el
registro de errores de Microsoft SQL Server, por lo que se requiriere que el
administrador de base de datos lleve a cabo la reconfiguración del valor de la opción
de configuración de la máscara de afinidad.
En Microsoft SQL
Server cuando se establece el valor de la opción de configuración ligthweight pooling en 1, como ya
mencionamos se establece el modo de fibra usa fibras de Windows, en lugar de
hilos, para dar servicio a los trabajadores de UMS (User mode Scheduler). Las
fibras de Windows son mecanismos de ejecución más livianos que los hilos, con
un hilo que generalmente alberga múltiples fibras. Debido a que la instalación
de ejecución básica en Windows sigue siendo el hilo, el código de Win32 que se
ejecuta en una fibra todavía se ejecuta a través de un hilo. Ya que los cambios
de contexto entre subprocesos típicamente ocurren mucho menos, y los costosos
cambios al modo kernel ocurren con menor frecuencia, las fibras son
construcciones en modo usuario de las que el núcleo no sabe nada. Los
conmutadores de contexto pueden ocurrir entre múltiples fibras alojadas por un
subproceso dado en lugar de entre subprocesos, así algunas operaciones que
normalmente requerirían un cambio al modo kernel pueden llevarse a cabo en modo
de usuario. El uso de fibras efectivamente enseña a los hilos a hacer
malabarismos.
En el caso
de la opción de configuración max worker
threads, podemos indicar que cuando el número real de solicitudes de
consultas es menor que la cantidad establecida en los hilos de trabajo máximo, entonces
se puede decir que un hilo maneja cada solicitud de consulta. Sin embargo, si
el número real de solicitudes de consulta excede la cantidad establecida en,
entonces Microsoft SQL Server agrupa los subprocesos de trabajo para que el siguiente
subproceso de trabajo disponible pueda gestionar la solicitud. Microsoft ha
indicado una tabla que muestra el número configurado automáticamente de
subprocesos máximo de trabajo para varias combinaciones de CPU y versiones de Microsoft SQL Server, la cual se puede observar en la documentación de Micrososft SQL Server.
Finalmente,
en el caso de la opción de configuración priority
boost, existe un precedente en equipos de soporte en el que se estableció habilitada
ésta opción, causando que los servidores no respondieran. Los movimientos
lentos de la IU / mouse / teclado son otros síntomas comunes de que ésta
configuración está interfiriendo con la capacidad del sistema operativo para
dar a los subprocesos (no SQL) su quantum deseado en la CPU. En un sistema de clúster,
tener los subprocesos de Microsoft SQL Server reforzado con prioridad puede interferir con
otros subprocesos críticos, como el hilo de sondeo IsAlive del supervisor de recursos, logrando que expiren, esto ocasionará
una conmutación por error no deseada. Por lo tanto, es recomendable que se establezca
la opción de configuración de mejora de prioridad en 1, especialmente en
instancias agrupadas.
En este
punto podemos decir que se han visto cada una de las opciones de configuración relativas
a procesador, estas mismas opciones aparecen en la pestaña de procesador de la
ventana de propiedades del servidor, como se puede observar en la siguiente
imagen:
Como se ha mencionado anteriormente, es posible realizar el cambio de alguna de las opciones de configuración en esta ventana, ya que los valores se muestran y están habilitados, es preferible llevar a cabo la modificación de estos valores con el procedimiento almacenado de sistema denominado sp_configure, de esta forma se puede mantener un control apropiado sobre los valores indicados en la opción de configuración.
No hay comentarios.:
Publicar un comentario