La resolución de problemas de rendimiento es un arte y una ciencia. El arte proviene de la experiencia (y del aprendizaje de las experiencias de otros) y la ciencia proviene de pautas bien conocidas sobre qué hacer en qué escenarios.
O al menos eso es lo que me gusta pensar y enseñar.
En realidad, muchos DBA y desarrolladores practican lo que yo llamo "solución automática de problemas de rendimiento". Esto sucede comúnmente cuando un problema de rendimiento ha llegado a la etapa crítica con, por ejemplo, consultas agotadas, procesos que se ejecutan lentamente o fallan, usuarios descontentos y la administración desea respuestas y acción rápida.
El 'instintivo' proviene de hacer un análisis superficial del problema y llegar a la conclusión (en realidad es agarrar una pajita) que el síntoma más frecuente debe ser la causa raíz y tratar de abordar eso, con poco o ningún éxito. a menudo utilizando consejos equivocados o francamente incorrectos que se encuentran en línea. Esto genera mucha frustración y pérdida de tiempo, y a menudo conduce a la pérdida de dinero cuando la organización decide tratar de solucionar el problema con hardware actualizando el servidor y/o el subsistema de E/S, solo para descubrir que el problema sigue ahí. , o vuelve a aparecer bastante rápido.
El análisis de las estadísticas de espera es una de las áreas en las que es más fácil actuar instintivamente, y en esta publicación voy a hablar sobre algunos de los tipos de espera comunes y los errores que la gente comete al respecto. No hay margen en un artículo como este para profundizar en qué hacer en cada caso, pero te daré suficiente información para orientarte en la dirección correcta.
LCK_M_XX
La mayoría de la gente asume que si las esperas de bloqueo son las más frecuentes, entonces el problema debe ser algún tipo de problema de bloqueo. A menudo lo es, como la falta de un índice no agrupado adecuado que provoque una exploración de tabla en niveles de aislamiento REPEATABLE_READ o SERIALIZABLE que se convierta en un bloqueo de tabla S. (Y como sugerencia rápida, si cree que nunca usará SERIALIZABLE, lo hará si usa transacciones distribuidas:todo se convierte a SERIALIZABLE en secreto, lo que puede provocar bloqueos y puntos muertos inesperados).
Sin embargo, a menudo ocurre que el bloqueo está causado por otra cosa. Bajo el nivel de aislamiento predeterminado READ_COMMITTED, los bloqueos que cubren los cambios se retienen hasta que la transacción se confirma y bloqueará las lecturas y otras actualizaciones en la(s) misma(s) fila(s). Si algo impide que se confirme una transacción, eso podría causar que aparezca un bloqueo.
Por ejemplo, si la base de datos se duplica sincrónicamente, la transacción no puede comprometerse y liberar sus bloqueos hasta que los registros se hayan enviado al espejo y se hayan escrito en la unidad de registro del espejo. Si la red está muy congestionada, o si hay una contención de E/S masiva en el espejo, esto podría retrasar seriamente la operación de espejo y, por lo tanto, hacer que la transacción tarde mucho más en confirmarse. Esto parecería un bloqueo, pero la causa raíz es la contención de recursos relacionada con la duplicación.
Para las esperas de bloqueo, a menos que la causa sea obvia al mirar el plan de consulta, bloquee el recurso (por ejemplo, nivel de tabla que indica escalamiento de bloqueo o nivel de aislamiento, siga la cadena de bloqueo (usando un script que recorra la columna blocking_session_id en sys.dm_exec_requests y luego mire para ver qué está esperando el hilo en la cabeza de la cadena de bloqueo. Eso apuntará hacia la causa raíz.
ASYNC_NETWORK_IO
El nombre de este causa mucha confusión. ¿En qué palabra te enfocas? RED. La causa de este tipo de espera normalmente no tiene nada que ver con la red. Realmente debería llamarse WAITING_FOR_APP_ACK (reconocimiento), o algo similar, ya que eso es exactamente lo que está sucediendo:SQL Server ha enviado algunos datos a un cliente y está esperando que el cliente reconozca que ha consumido los datos.
Una de mis demostraciones favoritas para hacer cuando enseño sobre las estadísticas de espera es ejecutar una consulta que devuelve un gran conjunto de resultados en Management Studio y ver cómo el servidor acumula esperas ASYNC_NETWORK_IO. Claramente, no hay ninguna red involucrada, es solo SSMS que tarda mucho en responder a SQL Server. Está haciendo lo que se conoce como RBAR (Row-By-Agonizing-Row), donde solo se extrae una fila a la vez de los resultados y se procesa, en lugar de almacenar en caché todos los resultados y luego responder inmediatamente a SQL Server y proceder a procesar el filas en caché.
Esta es la causa principal de las esperas de ASYNC_NETWORK_IO:diseño deficiente de la aplicación. Luego vería si el servidor que ejecuta el código de la aplicación tiene un problema de rendimiento, incluso si el código de la aplicación en sí está bien diseñado. De vez en cuando es la red, pero eso es raro en mi experiencia.
OLEDB
La reacción instintiva común aquí es equiparar este tipo de espera con servidores vinculados. Sin embargo, este tiempo de espera se volvió más común cuando se envió SQL Server 2005, porque 2005 contenía una gran cantidad de nuevos DMV, y los DMV en su mayoría usan OLE DB de forma oculta. Antes de buscar problemas con el servidor vinculado, verificaría si una herramienta de monitoreo está ejecutando DMV constantemente en el servidor.
Si tiene servidores vinculados, continúe con la solución de problemas yendo al servidor vinculado y mirando las estadísticas de espera allí para ver cuál es el problema más frecuente y luego continúe con el mismo análisis.
Otra cosa que puede causar esperas de OLEDB es DBCC CHECKDB (y los comandos relacionados). Utiliza un conjunto de filas OLE DB para comunicar información entre sus subsistemas Procesador de consultas y Motor de almacenamiento.
Otras Esperas
Algunas de las otras esperas que provocan reacciones instintivas son CXPACKET, PAGEIOLATCH_XX, SOS_SCHEDULER_YIELD y WRITELOG, y las cubriré en mi publicación el próximo mes.
Resumen
Cuando tenga un problema de rendimiento, tómese el tiempo para comprender los datos que está viendo y realice más investigaciones para ayudar a reducir la causa raíz del problema. No se limite a aferrarse a lo que parezca ser la principal estadística de espera y siga el primer consejo que encuentre en línea (a menos que sea de una fuente conocida y confiable) o es probable que no resuelva su problema, e incluso puede empeorarlo.
En lo que respecta a las estadísticas generales de espera, puede encontrar más información sobre cómo usarlas para solucionar problemas de rendimiento en:
- La serie de publicaciones de mi blog, que comienza con Estadísticas de espera o, por favor, dígame dónde le duele
- Mi biblioteca de tipos de espera y clases de bloqueo aquí
- Curso de capacitación en línea My Pluralsight SQL Server:solución de problemas de rendimiento mediante estadísticas de espera
- Asesor de rendimiento de SQL Sentry
Esta fue la primera de una serie de publicaciones que haré en el transcurso de este año que hablan sobre las (re)acciones instintivas en torno a SQL Server y por qué no es lo correcto. Hasta la próxima, ¡feliz resolución de problemas!
