Sesión para SQLPASS Spain sobre performance tuning en SQL Server

1. ¡OPTIMIZACIÓN! Lo que siempre has
querido saber para exprimir SQL
Server
Enrique Catala Bañuls
Mentor
SolidQ
ecatala@solidq.com

2. Enrique Catalá Bañuls
 Ingeniero Informático
 Mentor en SolidQ
 Microsoft Technical Ranger
 Colaborador destacado en MSDN Spain
 Microsoft Active Professional 2010
 Microsoft Certified Trainer
 Microsoft Certified IT Professional
 Database Developer 2008
 Database Administrator 2008
 Arquitecto de entre otros Health Check y SCODA
 Motero y piloto de ULM 

3. Agenda
 Configuraciones avanzadas de SQL Server
 NUMA
 Threads vs fibers
 IO Affinity Mask
 Max Degree of parallelism
 Configuracion de memoria
 Tempdb
 Configuraciones avanzadas de base de datos
 Log transacciones
 Date correlation optimization
 Parametrization
 Patrones para Developers
 Reducción de idas y venidas mediante el uso de TVP
 Las funciones en SQL Server, el desastre y su solución

4. Agenda
 Configuraciones avanzadas de SQL Server
 NUMA
 Threads vs fibers
 IO Affinity Mask
 Max Degree of parallelism
 Tempdb

5. NUMA
 Non-Uniform Memory Access
 Particionado hardware donde cada nodo a grandes rasgos
tiene subconjunto de CPU, memoria
 Interesa no salir del nodo
 Cada nodo NUMA tiene su propio lazywritter y su puerto
para finalización de E/S (el network listener)

6. NUMA
 SQL Server detecta automáticamente la configuración
NUMA
 Pensada para mejorar la escalabilidad de sistemas
multiprocesador
 Minimiza la latencia de acceso a memoria
 No hay que modificar aplicaciones ni tocar nada
 Podemos afinar: máscara de afinidad y Soft-NUMA

7. NUMA: Soft-NUMA
 Segmentamos afinidad de procesador (no memoria)
 Cada nodo numa software contiene Lazywritter y proceso E/S
 Diferencia obvia con NUMA hardware:
 En Soft-NUMA seguiremos teniendo un único nodo de memoria
 Solo provee afinidad a nivel de CPU
ALTER SERVER CONFIGURATION SET PROCESS AFFINITY CPU = 2 TO 5
 Si vemos esperas CXPACKET y LAZYWRITTER unidas, debemos
configurarlo
(escenario no NUMA)
 Segmentación multi-instancia

8. Thread vs fibers: Scheduler
 En entornos computacionales hay que dar solución al problema de la
multitarea (más procesos que CPU concurrentemente)
 El scheduler o programador se encarga de agendar a cada proceso un
tiempo finito de acceso a recursos de la máquina para ejecución
 Su eficiencia depende de:
 Nº de procesos simultaneos a agendar
 Latencia (tiempo entre que se solicita petición y se sirve)
 Prioridades e imparcialidad entre semejantes al asignar tiempo CPU
 SQL Server tiene su propio scheduler
 En windows los procesos poseen acceso exclusivo a recursos generalmente
 El scheduler de SQL Server facilita la cooperación entre procesos
 Mucho mas escalable en tareas de SQL Server pero mas complejo de diseñar

9. Thread vs fibers: SQL Server Workers
 El scheduler puede ser visto como una CPU lógica
 Un worker está asociado a un scheduler y solo a uno
 Haciendo una comparación, seria como los procesos en windows, pero que
corren sobre el scheduler
 Pueden ser thread o fiber (hilo o fibra)
 El scheduler se encarga de crear y destruir workers
 Se pueden explícitamente fijar mediante la máscara de afinidad a una CPU
concreta
 Se crean si el scheduler recibe petición de tarea a lanzar y no hay workers
inactivos
 Se destruyen despues de 15 minutos de inactividad o si hay presión de
memoria
 En un sistema x64 cada worker usa como mínimo 2Mb
 Cada core (sea o no hyperthreading) posee 1 worker al arrancar (OFFLINE si
se ha quitado de su máscara de afinidad)

10. Thread vs fibers
 Varias fibras pueden correr sobre un único hilo ya que son muy
ligeras (aprox 10 fibras/thread)
 «lightweight pooling option» a 1, activa uso de fibras
 Optimización de escenarios (aumento 15% rendimiento):
 Processor time: ~80%
 Context switches: >20k/sec
 ADVERTENCIA no son siempre la mejor opción:
 No se soporta CLR heterogeneo con consultas, SQL Mail, SQLXML,
…
 En escenarios como linked servers hay sobrecarga porque se obliga
a convertir la tarea a hilo

11. IO Affinity Mask
 Optimización escenarios con alto consumo de CPU por E/S
 Cada operación E/S en SQL Server necesita finalización
 Validación de bytes transferidos, no errores en SO, correcto nº de
página, checksum válido,…
 En definitiva, consumo de CPU
 La mascara de afinidad de E/S sirve para direccionar las
operaciones E/S a un scheduler oculto con un lazywriter que
que solo hace operaciones E/S
 Cuidado al configurar la mascara y la máscara de IO
MAL BIEN

12. NUMA y max degree of parallelism
 Siempre hay que afinar, sobre todo en sistemas OLTP
 Como norma general:
 Nunca exceder en MAXDOP el nº de hilos físicos por nodo NUMA
 Aproximadamente 6ms por petición y más de 200h
computacionales
wait type name wait time (ms) requests
CXPACKET 786556034 128110444
LATCH_EX 255701441 155553913
ASYNC_NETWORK_IO 129888217 19083082
PAGEIOLATCH_SH 83672746 2813207
WRITELOG 70634742 48398646
SOS_SCHEDULER_YIELD 47697175 176871743

13. NUMA y max degree of parallelism
 Se carga tabla en buffer cache
NUMA 0
 Cell 0: ms nodo NUMA 0
 Cell 1: ms nodo NUMA 1
 Cell 2: ms nodo NUMA 2
www.solidq.com

14. Configuracion de memoria
 Habilitar “Lock Pages in memory” siempre
 Se habilita mediante política a nivel de máquina para el usuario del
servicio
 Evita swapping de RAM a disco
 Trace flag “mágico” 
 834 (Large Page Allocation)
 Solo recomendable en Win 2008 R2 y SQL 2008 R2
 Medias de 10% de mejora de rendimiento obtenidas
 Tiene un gran pero…

15. Tempdb
 El “borrador” de SQL Server…no es solo donde van las #tablas 
 Precrear a un mínimo de 2xMemoria física
 El nº de ficheros de datos debe ser exáctamente igual nº de hilos
CPU
 IMPORTANTE: Todos precreados al mismo tamaño…TODOS
 Es buena idea separar tempdb de la lun de datos
 Excepcionalmente, si es un entorno OLTP altamente transaccional,
poner los datos y tempdb en la misma LUN para mejorar aleatoriedad
(ojo hablamos de sistemas de almacenamientos con mucho spindle)

16. Agenda
 Configuraciones avanzadas de BBDD
 Log de transacciones
 Date correlation optimization
 Parametrization

17. Log de transacciones
 Siempre almacenamiento dedicado exclusivo para el log de
transaciones
 Todo pasa por él
 Es secuencial
 No crees más de un fichero, no sirve de nada…
 Interesa máximo rendimiento en escrituras
 Cuidado con la fragmentación!
 Precrearlo con tamaño suficiente para que nunca crezca y si lo hace, que
lo haga a intervalos gordos.
 Ultima salida…recrear el log, asique no dejes que esto te ocurra
 Revisa usando “dbcc loginfo”

18. Date Correlation Optimization
 Configuración a nivel de base de datos
 Optimizar equi-joins entre dos tablas con date o datetime correladas a
las que aplicamos filtro
 Muy util en escenarios típicos de reporting o datawarehousing
ALTER DATABASE tu_Base_de_Datos
SET DATE_CORRELATION_OPTIMIZATION ON;

19. Date Correlation Optimization:
Beneficios
 SQL Server mantendrá estadísticas de correlación entre ambas tablas
 El efecto será que interna y transparentemente se crearán vistas
indexadas con la información necesaria
 SQL Server gestionará todas las casuísticas
 Añadirá nuevas estructuras cuando se cumplan
 Deshabilitará cuando algo deje de cumplirse
 Se encargará de ver si la consulta es mas eficiente usando la información
extra calculada

20. Date Correlation Optimization:
Restricciones
 Debe existir clave ajena de una columna entre las tablas
 Ambas tablas deben tener columnas datetime NOT NULL
 Al menos una de las columnas debe ser la clave principal de un
índice clústered
 Ambas tablas deben tener el mismo propietario
PRECAUCIÓN: En tablas altamente modificadas puede existir
detrimento de rendimiento por el mantenimiento interno que
producen las estadísticas

21. DEMO
DATE CORRELATION
OPTIMIZATION

22. Parametrización: Mejorar escenarios
ad-hoc (I)
 Optimize for ad-hoc workloads
 A nivel de instancia de SQL Server
 Solo útil para consultas ad-hoc livianas
 Almacena un pequeño código auxiliar en lugar del plan completo
(300 bytes vs >15k)
 Minimiza presión sobre el
cache de planes de ejecución
 Solo si se detecta reutilización,
se recompila y almacena en
cache

23. Mejorar escenarios ad-hoc (II)
 Force parametrization
 A nivel de base de datos
 Ocurre por cada statement. Cada batch puede tener múltiples statements
autoparametrizados
 Fuerza la parametrización de toda sentencia SELECT, UPDATE, INSERT y DELETE
 En ciertos escenarios, mejora enormemente el rendimiento a base de
reutilización de planes de ejecución
 PRECAUCIÓN: Testear siempre el entorno antes
de poner en producción. Puede que salgamos
perdiendo…
 Excepciones
 Statements dentro de SP, funciones,…
 Si ANSI_PADDING o ANSI_NULL = OFF
 Statements que referencian variables
 Statements en cursor

24.  Antes
% of memory used
0%
Datos reales
0%
0% 0% Compiled Plan Proc
4% 10%
14% Compiled Plan Trigger
Compiled Plan Adhoc
Compiled Plan Prepared
Extended Proc Proc uses number_ocurrencies
cacheobjtype percentage_memory_KB
Parse Tree UsrTab 1 6583 Compiled Plan 30,57
72%
Parse Tree Check 1 6 Parse Tree 0,01
Parse Tree View 1 13123 Compiled Plan Stu 0,00
2 3525 Compiled Plan 8,04
 Después 2
3
653 Parse Tree
2710 Compiled Plan
2,36
4,69
3 11 Parse Tree 2,85
3 1 Compiled Plan Stu 0,02
4 139 Parse Tree 0,43
4 2163 Compiled Plan 0,00
5 1998 Compiled Plan 1,98
5 41 Parse Tree 0,34
6 3578 Compiled Plan 2,03
6 333 Parse Tree 1,06
6 2 Extended Proc 0,00
7 2164 Compiled Plan 1,49
7 14 Parse Tree 0,04
8 1010 Compiled Plan 0,90
Más del 55% de la memoria de planes 8
9
118 Parse Tree
1113 Compiled Plan
0,36
0,81
de ejecución reutilizado menos de 10 9 8 Parse Tree 0,02
10 836 Compiled Plan 0,68
veces

25. Agenda
 Patrones para Developers
 Reducción de idas y venidas mediante el uso de TVP
 Las funciones en SQL Server, el desastre y su solución

26. TVP (Parámetros de tabla)
 Escenarios
 Actualización en lotes del servidor
 Parámetros en lote para usar en consultas
 Pasar una tabla entre rutinas
 Migración de otras bases de datos
 Los datos almacenados son tabulares!
 Criterio común
 Gran cantidad de datos pasados desde el cliente al servidor
 Aplicación de lógica de negocio antes de actualizar datos de forma persistente
 Ej. Data mining, sistemas de inventariado, herramientas ETL

27. TVP (Parámetros de tabla)
 Empaquetado de lógica de negocio
 Mejor modelo de programación
 Procesamos transacciones en orden de llegada
 Mejor manejabilidad (procedimiento almacenado lo puede hacer
todo)
 Rendimiento
 Reducción de idas y vueltas al servidor
 Operaciones basadas en conjuntos
 Transporte de datos eficiente
 Tipado Fuerte

28. TVP (Parámetros de tabla)
“Aprovecha las características TVP y MERGE en tus aplicaciones”
http://msdn.microsoft.com/es-es/sqlserver

29. Funciones en SQL Server
 Podemos definir las funciones de usuario en:
 Funciones inline
 Funciones multi-statement
 Tendamos a eliminar las funciones…¿pero todas?
 Problema:
 No son visibles en los planes de ejecución gráficos
 Producen malísimas estimaciones estadísticas que derivan en
inadecuados usos de NESTED LOOPS
 El código se interpreta en cada llamada (si no se usa bien)
 Por último y más importante: NO ES POSIBLE PARALELISMO

30. DEMO
FUNCIONES EN SQL SERVER.
EL DESASTRE Y SU SOLUCIÓN

31. Agenda
 Configuraciones avanzadas de SQL Server
 NUMA
 Threads vs fibers
 IO Affinity Mask
 Max Degree of parallelism
 Configuracion de memoria
 Tempdb
 Configuraciones avanzadas de base de datos
 Log transacciones
 Date correlation optimization
 Parametrization
 Patrones para Developers
 Reducción de idas y venidas mediante el uso de TVP
 Las funciones en SQL Server, el desastre y su solución

32. ¿ PREGUNTAS ?
ecatala@solidq.com
http://blogs.solidq.com/ElRinconDelDBA/default.aspx