http://summit.solidq.com/madrid/2013/ ¡Vente al Summit!
Uno de los aspectos más importantes a la hora de realizar un troubleshooting es el paralelismo. En esta sesión daremos una vuelta completa al paralelismo en SQL Server, Hablaremos de parámetros de configuración, planes de ejecución paralelos, operadores paralelos y mucho más. Además veremos cómo monitorizar y detectar problemas de paralelismo y las posibles soluciones.
3. SQL Server por defecto utiliza todos los cores disponibles
para resolver planes de ejecución paralelos
La idea es utilizar los cores extras, para reducir el tiempo
de respuesta utilizando múltiples CPUs
El tiempo computacional suele ser mas elevado, pero el tiempo
efectivo suele ser menor
En sistemas OLTP puros, se suele premiar serializabilidad
Pocos sistemas son OLTP puros
Consultas paralelas
Introducción
4. Mejora lineal con el nº de CPU en scans
No solo select, tambien reconstrucciones de índices por ejemplo
Paralelismo
Beneficios
5. SQLOS
Crea un scheduler por cada CPU lógica
Es como un gestor de recursos…como un SO
Scheduler
Como una CPU lógica
Trabajan en modo cooperativo, no como en Windows
Facilitan “data locality”
Worker
Son como “logical threads” (ejecutan tareas)
Solo un worker puede ser ejecutado por un scheduler al
mismo tiempo
Task
Unidad de trabajo para un worker (sentencia simple)
Asignada a un worker que no la soltará
Modelo de ejecución de SQL Server
Conceptos
SQLOS
Memory Node
CPU Node
Scheduler
Worker
Task
6. Generación de planes de ejecución
¿Por qué un plan paralelo enOLTP no es buena señal?
Stage 0
Reglas básicas de evaluacion usando hash y nested join
Si el coste del plan es menor a 0.2 usar este plan
Stage 1
Explorar mas reglas incluso alterando el orden de los join
Stage 2
Explorar todas las opciones y optar por el plan menos
costoso tras un nº limitado de exploraciones
CUIDADO, TIEMPO LIMITADO!!! (timeout)
if(best_plan_for_now.cost<1) return(best_plan_for_now)
else if(MAXDOP>1
and best_plan.cost > threshold for parallelism)
return(MIN(create_paralel_plan().cost, best_plan_for_now))
7. Nivel hardware
NUMA
Nivel de instancia
Soft-NUMA (affinity mask)
Degree of parallelism
Cost threshold for parallelism
Max worker threads
Parámetro -P
Nivel de conexión
Resource Governor usando MAXDOP
Cláusula DBCC OPTIMIZE_WHATIF
Nivel de sentencia
Cláusula MAXDOP
Conocimiento de construcciones T-SQL
CROSS APPLY
Funciones…
Paralelismo
Mecanismos decontrol
8. Usadas para establecer qué procesadores pueden
utilizarse por una instancia SQL Server
También llamado Soft-NUMA
No controlan vinculación a RAM
Affinity mask
CPU Affinity mask
12. Distribución de filas basada en 3 tipos
Hash
Los valores de filas obtienen hash y cada hilo se responsabiliza de un
rango hash
Round-robin
Los valores de las filas se envían al siguiente hilo de la lista
Broadcast
Todas las filas se envian a todos los hilos
Range
Determina a que hilo enviar la fila evaluando una funcion de rango
sobre una columna
Rara y usada en algunos parallel index recreation
Demand
Se usa un modo pull en lugar de push como en las otras.
Envia la fila al thread que se la está pidiendo
Aparece en tablas particionadas
Operadores exchange
Distribute streams
13. Consume múltiples fuentes y produce multiples fuentes
No se modifican las filas
Se reducen filas si aparece un operador bitmap
Operadores exchange
Repartition streams
14. Consume múltiples hilos y produce un único hilo
Combina resultados
Es el que mayor % de esperas suele generar
Operadores exchange
Gather streams
15. Añadir más CPU
Añade más poder computacional
No resuelve problemas de rendimiento automágicamente
Escribir código multi-hilo perfecto es muy difícil
Cada vez es mas fácil escribir código paralelo
El que haya trabajado con .NET 4.5 lo habrá visto
SQL Server tiene mucho camino hecho con 12+ años experiencia
Hay un coste inherente asociado al paralelismo
Mover un problema a modo paralelo y viceversa conlleva un gasto
¿compensa siempre ir a modo paralelo?
Paralelismo
¿Es la solución?
20. Depende de como programemos
Plan óptimo 100% paralelo
Plan subóptimo 90% paralelo
Plan subóptimo en serie
Planes subóptimos en serie
SQL Server anula la posibilidad de ejecutar la consulta en paralelo
Clausulas y/o estructuras de datos que no paralelizan
Cuidado como programas!!!
Enemigos del paralelismo
Planes de ejecución subóptimos
24. Operaciones en memoria
SORT y HASH JOIN
Memory grants
Operaciones costosas
SQL Server tiende a paralelizar
Lógico pensar que en paralelo debe ir más rápido
Distribución de filas por threads
Asignación de memoria equitativa por thread
Distribución de filas “no tan equitativa”
¿Cómo están distribuidos tus datos?
La memoria y el paralelismo
27. ¿Cuándo aplicar MAXDOP?
ALTER INDEX, Statistics operations …
Agregaciones (AVG, MAX,…)
Recuerda que existe Resource Governor
¿Cuándo aplicar “max degree of parallelism”?
Recomendación = #physical_cores
Sistemas OLTP deberian configurarse a 1
Siempre que veamos alto % de esperas CXPACKET
¿Cuándo aplicar “cost threshold for parallelism?
Cuando quieras cambiar el nº de operaciones paralelas
estadísticamente
Paralelismo
Buenas prácticas
28. No hay una solución maestra!!
Si observas esperas CXPACKET reduce MAXDOP
En OLTP puro pensar en 1 suele ser correcto
Considera Resource Governor
Si ves planes de ejecucion suboptimos, considera
actualizar estadísticas
Re escribe la consulta para hacerla mas eficiente
Para maximizar el paralelismo evita el uso de:
Tablas variables
Funciones
Consultas recursivas
Paralelismo
Buenas prácticas
29. Trace flag 8002
Posibilitamos que los schedulers utilicen cualquier CPU en el
affinity mask
Por defecto quedan vinculados a la CPU en la que fueron
creados
Trace flag 8017
Solo arrancan los schedulers in la mascara de afinidad con
is_online=1.
Se liberan recursos consumidos por schedulers offline hidden
Trace flag 8021
En casos donde se reporta erroneamente el nº de nodos
NUMA, lo arregla
Trace flag 8025
SQL Server asume NUMA NODE=0 como el de mayor carga, y
se lanza sobre el 1. Este TF evita este swap
Bonus final
Trace flags interesantes
30. Activa todas las revisiones del optimizador de consultas
SQL Server trae optimizaciones del motor no activadas según CU o
SP
Esto facilita a dev de sql el que exista comportamiento predecible en
cada update
Ojo, testéalo porque puede producir rendimientos no deseados
Trace flag 4199
Por defecto viene a off y debemos activarlo
DBCC TRACEON(4199)
A nivel de instancia con –P4199 en sql server configuration manager
A partir de SQL Server 2005 SP3
http://support.microsoft.com/kb/974006
Bonus final
Trace flag mágico
31. Si quieres disfrutar de las mejores sesiones de
nuestros mentores de España y Latino América,
ésta es tu oportunidad.
http://summit.solidq.com/madrid/
Síguenos: