Como sabes, a poco que no estés totalmente desconectado del mundo tecnológico te habrás enterado de uno de los mayores bugs de la historia de la informática (Spectre y Meltdown) y que sus efectos son reales. Tan reales, que nosotros mismos en SolidQ lo hemos sufrido en nuestro propio software Query Analytics. En este post voy a tratar de darte un poco de luz sobre cómo proceder si detectas regresion de rendimiento en tu solución con SQL Server, contándote cómo lo he resuelto yo en mi propio sistema.
[box type=”info”] UPDATE: Intel confirma la regresion de rendimiento y además que el gran impacto está en I/O[/box]
TSQL Query Analytics es un software que funciona de forma transparente para nuestros clientes, de forma que si eres cliente de esta herramienta, tu lo que tienes es un sistema que se encarga de procesar todas las peticiones que llegan a tu sistema de SQL Server y las agrega en un Datawarehouse, que luego puedes analizar gráficamente, tiene un sistema de alertas proactivas,…
[box type=”shadow”]Para más información: http://www.solidq.com/es/tsql-query-analytics/[/box]TSQL Query Analytics está hospedado en Azure y obviamente lleva detrás una serie de bases de datos, que tu como buen usuario de la herramienta quieres consumir:
El problema vino con la sorpresa del bug y sus posteriores parches. Microsoft emitió una nota oficial el día 3 de Enero informando que ya estaban aplicados los parches a toda su infraestructura de Azure. Mi sorpresa vino al reincorporarme de vacaciones y ver como algunos de los reports de ciertos clientes estaban empezando a ir sospechosamente lentos…tanto que incluso en alguna ocasión incluso llegué a ver timeouts…
Lo que obviamente no es fruto de la casualidad y enseguida pensé que el bugfix aplicado tendría que ver. Ante esta tesitura, tenía 2 opciones:
- Subir la capacidad de máquina Azure hasta que el rendimiento vuelva a ser aceptable
- Ingeniera de software para exprimir las capacidades de la máquina actual
Desde luego una de las grandes ventajas de estar en Azure es que podria haber hecho 2 clicks y haber incrementado las capacidades de la máquina…pero esa solución facil tiene un coste monetario, que si estas leyendo este post quieres evitar. Dicho esto y como buen Mentor de SolidQ me dispuse a hacer con mi software, lo que suelo hacer con los clientes que me contratan: “optimizar la solución para abaratar costes dando el mejor rendimiento posible“. Ni que decir tiene que en SolidQ tenemos TSQL Query Analytics analizándose a si mismo, lo cual es una gran ventaja en este caso puesto que nos permite ver no solo los impactos de rendimiento, sino los causantes de los mismos. Veamos resultados arrojados por la herramienta, sobre su propio rendimiento (nuestros usuarios utilizando los dashboards, vamos):
Fijémonos en los tiempos medios a partir del día 2. Ese día, veo un restart de instancia SQL Server mirando el visor de eventos y es el día anterior a la nota de prensa de Microsoft por lo que es obvio que ese reinicio es el fix…y además todo cuadra. Fíjate en qué medida están incrementándose los tiempos.
[box] Prácticamente un 60% de caida de rendimiento[/box]
[box type=”info”]Recuerda que estamos viendo tiempos de un sistema que está mostrando resultados de análisis sobre 2 billones de queries[/box]
Ante esto, el día 9 de Enero estuve una mañana intensa analizando las posibles soluciones a aplicar para mejorar el rendimiento lo suficiente como para volver a rendir como lo hacia anteriormente. Encontrar la solución en este caso me fue bastante facil…tan facil como usar el mismo TSQL Query Analytics e ir a la pestaña “Comparison: Reliability“.
En dicha pestaña podemos ver de forma numérica el impacto real de la regresión de rendimiento sufrida. Para ello, simplemente comparé el día 3 de Enero (post parche) con el día 27 de diciembre (el miercoles anterior) para tener una comparación lo mas exacta posible.Veamos en detalle esta comparación:
Con esta información, puedo extraer las siguientes conclusiones.A igual nº de peticiones (~2,4% de diferencia):
- 11.6% incremento de coste CPU
- esto es lo que sufre la máquina extra sirviendo las mismas peticiones
- 64,89% incremento de duración
- Esto es lo que percibe el usuario, el tiempo de respuesta
Lo que me propuse por tanto fue bajar al máximo las operaciones de E/S, suponiendo que como todo eso no son ni mas ni menos que un montón de señales a bajo nivel, que además están llenas de operaciones adelantadas para tratar de obtener el dato que el motor cree que vas a necesitar luego, altamente paralelizables, multithread…pues bueno, que algo se notaría. Dicho esto, lo que hice fue simplemente irme a la pestaña “TOP 10 Query pattern weight (Reads/Writes)”
Y me dediqué a optimizar el top 3 de las peticiones tanto de lecturas como de escrituras. Las optimizaciones aplicadas pues dependieron del escenario…algunas fue modificar la indexación, otras fue cambiar algún tipo de datos, alguna re-escritura de funcion TVP,…pero sea como sea, la idea que quiero que te lleves es que la optimización consistió siempre DISMINUIR LA CARGA DE E/S del sistema. ¿Qué produjo la disminución de E/S?
Esto al final produjo una disminución de consumo de CPU
Que llevó a que el tiempo de resolución de consulta volviera a tiempos pre-fix, e incluso mejores:
Obviamente no dispongo de conocimientos internos de qué tipo de impacto tienen los parches, pero ten en cuenta que tienen regresiones de rendimiento importantes.En mi escenario, minimizar operaciones de E/S entraba en lo que imaginé como gran afectado…ya sabes operaciones facilmente paralelizables, multihilo y a bajo nivel (leete este excelente post de Chema Alonso al respecto para entender por qué llegué a esa conclusión).
Para finalizar, solo recordarte que los efectos de los parches a los bugs Spectre y Meltdown dependen de tu carga de operaciones. En mi caso está claramente relacionado con volúmenes de peticiones grandes a E/S, pero puede no ser tu caso. Sea como sea, recuerda que las implicaciones pueden ser bastante serias y que mas te vale estar prevenido.
