Tienes algunos problemas con SQL Server. De vez en cuando tienes períodos en los cuales incluso la ejecución de un simple SELECT demora más de un minuto. Durante este período, el uso de CPU y memoria en el servidor tienen una apariencia normal. Haz realizado algún control básico sobre el servidor utilizando el monitor de rendimiento, pero con esto no se ha descubierto nada y ya no tienes más ideas. ¿Cuál sería el siguiente paso en el diagnóstico del problema?
Te pones a revisar los procesos que están corriendo en el servidor SQL Server y ves que la mayoría tiene un tipo de espera CXPACKET.
CXPACKET
El tipo de espera (waittype) CXPacket del SQL Server está involucrado en la ejecución de consultas en paralelo. Esto indica que el SPID está esperando en un proceso paralelo para completar o iniciar. El waittype CXPacket se produce al tratar de sincronizar el iterador de intercambio de procesador de consulta. Un excesivo tipo de espera CXPacket suele ser resuelto por los DBAs, pero puede indicar un problema con la cláusula WHERE en la consulta SQL Server.
Para aplicaciones OLTP donde se requiere un óptimo rendimiento del SQL Server, CXPacket superior al 5% del tiempo total de ejecución de la consulta indica un problema. El paralelismo reduce el rendimiento del SQL Server para aplicaciones OLTP. El CXPacket indica el funcionamiento de múltiples CPUs en paralelo, cada ejecución de una parte de la consulta. Por lo general una buena aplicación OLTP optimizada no debe paralelizarse a menos que un índice este faltando, existe una cláusula WHERE incompleta, o la consulta no es una verdadera operación OLTP.
Soluciones
En la optimización del rendimiento del SQL Server, a veces el costo de romper en partes una consulta en paralelo y poner los resultados de muchos campos de nuevo juntos es más que el coste de ejecutar la consulta sin tener que utilizar paralelismo. En esos casos, estos tipos de espera son numerosos y de larga duración. Las consultas que están altamente balanceadas para una sub consulta u otra son la causa común de estos. Si, por ejemplo, la consulta recupera los registros de cuatro tablas y una de ellas tiene la mayoría de los registros, y el paralelismo causa de que se trate de difundir a través de varios hilos, tres de ellos tendrían que esperar al más grande y ver tiempos de espera para el Intercambio. Hay muchas sugerencias para el cuidado de estos tipos de espera en el SQL Server, uno de los más comunes es desactivar el paralelismo, a veces sólo para esa consulta, a veces para todo el servidor.
Para comprobar si hay paralelismo:
sp_configure 'max degree of parallelism'
Si el máximo grado de paralelismo = 0, es posible que desee utilizar alguna de las siguientes opciones:
- Desactivar paralelismo completamente para cargas de trabajo OLTP: establece el máximo grado de paralelismo en 1.
sp_configure 'max degree of parallelism', 1 GO RECONFIGURE
- Limita el paralelismo estableciendo el máximo grado de paralelismo a un número inferior al número total de CPUs. Por ejemplo, si tiene 8 procesadores, establece el grado máximo de paralelismo a <= 4.
sp_configure 'max degree of parallelism', 4 GO RECONFIGURE
