Uno de los desafíos más difíciles en SQL Server es la resolución de problemas con la sensibilidad de los parámetros o la estimación de la cardinalidad que causan la degradación del rendimiento de una carga de trabajo. Por lo general, necesitará tener el plan de ejecución real de la declaración en ejecución para poder determinar la causa de la degradación del rendimiento. En SQL Server 2012, el evento extendido query_post_execution_showplan brinda la capacidad de capturar el plan de ejecución real para las declaraciones. Sin embargo, tan útil como parece, este evento no es algo que se pueda usar sin un impacto significativo en el rendimiento de la carga de trabajo que se ejecuta en el servidor.
En mi artículo Medición de la "sobrecarga del observador" de SQL Trace frente a eventos extendidos, mostré una comparación del impacto en el rendimiento de SQL Trace con una configuración idéntica que usa eventos extendidos en SQL Server 2012. En ese momento, originalmente hice las pruebas para ese artículo. También realicé muchas pruebas del evento query_post_execution_showplan en SQL Server 2012. Este evento se introdujo por primera vez en SQL Server 2012 CTP1 cuando muchos de los eventos de seguimiento se transfirieron a eventos extendidos para proporcionar paridad con SQL Trace. En ese momento, el evento solo tenía un subconjunto de las columnas que se incluyeron en el RTM final de SQL Server 2012.
Durante CTP1, envié un elemento de conexión solicitando que se creara una acción para permitir la recopilación del plan de ejecución real con eventos en SQL Server 2012. El objetivo era poder usar los eventos module_end o sql_statement_completed para identificar cuándo se ejecutaba un procedimiento. o declaración excede su duración normal. Por ejemplo, en el escenario de la sensibilidad de los parámetros, donde se genera un plan menos ideal para los valores normales de los parámetros, el evento se puede usar para recopilar el plan de ejecución real para esa declaración a través de una acción. En respuesta, el equipo de SQL Server agregó las columnas de duración y cpu_time al evento query_post_execution_showplan para permitir que las definiciones de predicado solo recopilen este evento para esos escenarios.
Desafortunadamente, esto no tiene los mismos beneficios que una implementación como acción hubiera tenido en el rendimiento. En el resto de esta publicación explicaré por qué.
Impacto en el rendimiento
En el momento en que realicé las pruebas para mi artículo anterior, también probé la sobrecarga asociada con el evento query_post_execution_showplan, principalmente porque estaba realmente interesado en usarlo en un par de sistemas de producción de clientes y antes de hacerlo necesitaba entender qué tipo de impacto que tendría el evento en su carga de trabajo. Estaba realmente consternado por los resultados que obtuve de mis pruebas originales, y después de que Aaron Bertrand validara mis resultados usando el arnés de prueba interno de SQL Sentry, archivé otro elemento de Connect que informaba los problemas de rendimiento que posteriormente se cerró como "Por diseño". .
Para probar el impacto en el rendimiento, se utilizó exactamente la misma carga de trabajo y configuración de reproducción distribuida del artículo Medición de la "sobrecarga del observador" del seguimiento de SQL frente a eventos extendidos. La única diferencia en los resultados de las pruebas que se muestran en este artículo es que se utilizó un sistema host más nuevo y potente para el entorno de VM. Las máquinas virtuales utilizadas eran exactamente las mismas, sin cambios en su configuración, y simplemente se copiaron en el nuevo sistema, por lo que la carga de trabajo de referencia pudo realizar la reproducción más rápido con un promedio más alto de solicitudes por segundo por lote. Los resultados de referencia se capturaron mediante una instalación estándar de SQL Server 2012 con solo la sesión de eventos system_health predeterminada ejecutándose en el servidor.
Para la comparación del impacto en el rendimiento del query_post_execution_showplan evento, se utilizó la siguiente definición de sesión de evento.
CREATE EVENT SESSION [query_post_execution_showplan Overhead] ON SERVER ADD EVENT sqlserver.query_post_execution_showplan( WHERE ([duration]=(5000000))); GO
Esta sesión en realidad no recopila los datos del evento usando un objetivo y usa un predicado en la duración de la duración del evento igual a 5000000 microsegundos, o cinco segundos de duración. Para la carga de trabajo de reproducción, la ejecución de ninguna declaración tiene una duración de exactamente cinco segundos, por lo que el evento query_post_execution_showplan nunca se activa en el servidor y cualquier degradación del rendimiento es estrictamente el resultado de la recopilación de datos del evento y luego de la evaluación del predicado. Los resultados de las pruebas se muestran en la Tabla 1 y se grafican en el Gráfico 2.
Tabla 1:sobrecarga del evento query_post_execution
Gráfico 2:sobrecarga del evento query_post_execution
Para esta ronda de pruebas, el rendimiento de la carga de trabajo se degrada en aproximadamente un 30 % con solo habilitar este evento en una sesión de evento, aunque no se activará para ninguno de los eventos que se reproducen en el servidor. La degradación general dependerá de la carga de trabajo real para el servidor, y es importante tener en cuenta que esta serie de pruebas refleja más el peor de los casos, ya que Distributed Replay se ejecutó en modo de estrés y el uso de la CPU en SQL Server se vinculó. al 94 % de media durante las pruebas.
Comprender el impacto en el rendimiento
La razón por la que este evento impone una sobrecarga tan significativa en el rendimiento se puede explicar a partir del ciclo de vida del evento en Eventos extendidos. Cuando se encuentra un punto crítico en el código de SQL Server asociado con un evento durante la ejecución, el código realiza una verificación booleana muy rápida para determinar si el evento está habilitado en alguna sesión de eventos activa en el servidor. Si el evento está habilitado para una sesión de evento activa, se recopilan todas las columnas de datos asociadas con el evento, incluidas las columnas personalizables que se hayan activado. En este punto, el evento evalúa cualquier predicado para las sesiones de eventos activas que recopilan el evento para determinar si el evento realmente se activará por completo.
Para el evento query_post_exection_showplan, todo el impacto en el rendimiento proviene de la sobrecarga asociada con la recopilación de datos. Incluso en el caso de que haya un predicado con una duración igual a cinco segundos, con solo activar el evento en una sesión de evento, debe recopilar el Showplan XML para cada instrucción que se ejecuta en el servidor solo para poder evaluar el predicado. y luego determine que el evento no se disparará. Por este motivo, se debe evitar el evento query_post_execution_showplan para las cargas de trabajo de producción. Para la carga de trabajo de reproducción de prueba, el evento tuvo que evaluarse aproximadamente 440 000 veces, aunque en realidad no se activa para la carga de trabajo y la sesión de evento que se está probando, ya que ninguno de los eventos de reproducción tiene una duración de exactamente cinco segundos. La información de recuento de eventos se recopiló agregando el objetivo event_counter a la sesión de eventos y eliminando el predicado de duración y luego volviendo a probar la carga de trabajo de reproducción con la siguiente definición de sesión.
CREATE EVENT SESSION [query_post_execution_showplan Overhead] ON SERVER ADD EVENT sqlserver.query_post_execution_showplan ADD TARGET package0.event_counter; GO
Comparación con eventos de activación rápida
Para proporcionar un marco de referencia para este impacto en el rendimiento, podemos observar la sobrecarga de activar un conjunto de eventos que se ejecutan con frecuencia en el servidor y realizar la misma carga de trabajo de reproducción. Dos de los eventos que se ejecutan con más frecuencia en SQL Server son los eventos lock_acquired y lock_released. Para comparar la sobrecarga de estos dos eventos, se puede usar la siguiente sesión de eventos, que recopila los eventos sin predicado para que cada ejecución se recopile y cuente con qué frecuencia se activan utilizando el objetivo event_counter.
CREATE EVENT SESSION [locking Overhead] ON SERVER ADD EVENT sqlserver.lock_acquired, ADD EVENT sqlserver.lock_released ADD TARGET package0.event_counter; GO
Para nuestra carga de trabajo de reproducción, estos dos eventos se activan aproximadamente 111 180 000 veces. Los gastos generales asociados con la recopilación de estos eventos se pueden ver en la Tabla 3 y el Gráfico 4.
Tabla 3:comparación de sobrecarga de bloqueo
Gráfico 4:comparación de sobrecarga de eventos de bloqueo
Como puede ver en los datos, el efecto de rendimiento de estos eventos es significativamente menor que para query_post_execution_showplan, aunque la definición de la sesión de bloqueo de eventos se configuró para permitir que todos los eventos se activen en el servidor, la sobrecarga total fue inferior al 1 % en general. . Tenga en cuenta que la sesión de eventos de bloqueo evaluó el equivalente a 500 veces más eventos y, en este caso, todos los eventos tuvieron que activarse para la sesión de eventos, mientras que el evento query_post_execution_showplan no tuvo que activarse después de ser evaluado.
Resumen
Si bien el evento query_post_execution_showplan brinda la capacidad de recopilar el plan de consulta real para una declaración que se ejecuta, el impacto en el rendimiento de la recopilación de datos solo para evaluar el evento lo convierte en algo que no es viable para el uso de producción. Como mínimo, se debe considerar la sobrecarga antes de usar este evento en una carga de trabajo de producción. Incluso la descripción del evento proporcionada por Microsoft reconoce que el evento puede tener un impacto significativo en el rendimiento (mi resaltado):
Ocurre después de que se ejecuta una instrucción SQL. Este evento devuelve una representación XML del plan de consulta real. El uso de este evento puede tener una sobrecarga de rendimiento significativa, por lo que solo debe usarse cuando se solucionan problemas o se supervisan problemas específicos durante breves períodos de tiempo.La descripción del evento se puede encontrar en la columna de descripción de la vista de catálogo sys.dm_xe_objects, o en la interfaz de usuario de Nueva sesión, como se muestra en la Figura 5 (mi resaltado):
Figura 5:descripción del evento de la interfaz de usuario de nueva sesión
Recomendaría comparar el rendimiento de cualquier evento con esta advertencia en la descripción antes de usarlo en un entorno de producción.
