Pruebas de rendimiento de cargas de trabajo de producción para Ingres y Vector

Una de las principales preocupaciones de los clientes de Ingres y Vector cuyos sistemas deben someterse a un cambio significativo, como actualizaciones importantes de versión, migración de sistemas operativos, lanzamientos importantes de software, aumento del volumen de uso, etc., es cómo probar adecuadamente la base de datos en condiciones realistas en un entorno de pruebas.

Algunos clientes han oído hablar de la herramienta Query, Recording and Playback (QRP), desarrollada por Actian Professional Services, en reuniones de usuarios. La herramienta tiene como objetivo probar la base de datos Ingres o Vector en condiciones cercanas a la producción mediante la grabación y posterior reproducción de una carga de trabajo de producción en un entorno de prueba. El resto de este artículo describe la herramienta y su uso con más detalle.

Registro de consultas

La función de registro de consultas de QRP utiliza el tracepoint "SC930", que produce un registro de todas las consultas ejecutadas en la base de datos durante el tiempo en que el tracepoint estuvo activado. La salida de SC930 es esencialmente una serie de archivos de texto, que contienen las consultas, parámetros, tipos de datos, datos, etc. - es decir, la carga con la que pretendemos realizar la prueba. El uso del tracepoint y los detalles del formato de salida que produce se describen con más detalle aquí:

https://github.com/ActianCorp/Dynamic_Playback/wiki/Ingres-DBMS-Server-Query-Tracing

https://github.com/ActianCorp/Dynamic_Playback/wiki/SC930-Output-Page

Este tracepoint -que suele ser una forma no documentada de modificar el comportamiento de Ingres y Vector- está ahora soportado oficialmente y documentado en los manuales del producto. De hecho, en las últimas versiones se ha añadido una sintaxis adicional para que sea aún más fácil trabajar con él (busque "SET SERVER_TRACE" en los manuales), por lo que puede utilizarlo usted mismo para realizar análisis de consultas ad hoc. Por ejemplo, ahora puede habilitar el rastreo de consultas sólo para usuarios específicos que ejecuten consultas contra una base de datos específica que tarden más de un cierto período de tiempo en ejecutarse, facilitando mucho su uso para diagnósticos - vea aquí para más detalles para Ingres y aquí para Vector v5.

El uso del punto de rastreo SC930 significa que la parte de registro de consultas de la operación puede funcionar en versiones anteriores de Ingres y Vector que aún no soportan server_trace.

Reproducción de consultas

La reproducción es un conjunto separado de herramientas, escritas inicialmente por el equipo de Servicios Profesionales de Actian, descritas en el repositorio Github de Actian aquí (con versiones binarias también publicadas en Github pero el código fuente líder mantenido en SVN aquí), que está diseñado para reproducir cada consulta contra su sistema de prueba en el mismo orden y tiempo relativo en que se grabó.

"Consulta" en este contexto significa cualquier sentencia SQL que pueda ejecutarse contra la base de datos Ingres o Vector. De hecho, incluso si la "consulta" es SQL no válida, la reproducción intentará reproducirla y, si no es válida, fallará igual que cuando se grabó.

La reproducción se compone, en general, de dos piezas fundamentales.

• Preproceso:
  • Preprocess reformatea los archivos de salida del SC930 para dividirlos en sesiones individuales y ordenar cada sesión, conexión y consulta por una marca de tiempo. Esto se hizo para garantizar que pudiéramos reproducir cada sesión como un hilo separado en el momento correcto, independientemente de lo que esté sucediendo en otros hilos.
  • Preprocess está escrito en C# y puede ejecutarse en entornos MONO o .Net.
  • Sólo es necesario ejecutarlo una vez por grabación.
  • Los archivos de salida pueden ejecutarse en un servidor y reproducirse en otro.
• Reproducción:
  • Un trabajo de reproducción básico abre archivos individuales producidos por el preprocesamiento y envía un hilo separado para cada sesión en el mismo orden y tiempo. A continuación, los subprocesos deben ejecutar todas las consultas de ese archivo en el mismo orden y tiempo.
  • La reproducción está escrita en C llamando a funciones estándar de la biblioteca SQL Embarqué Ingres Embarqué , que es posiblemente la forma más rápida de enviar una consulta a una base de datos Ingres o Vector, ya sea localmente o a través de una red.
  • Se puede ejecutar tantas veces como se desee.

La reproducción puede ayudar a probar las consecuencias de añadir carga al sistema, cambios en el hardware, como la reducción de núcleos o de memoria, el aumento de los volúmenes de datos o de usuarios y también a tomar líneas de base de rendimiento para luego probar actualizaciones o parches. Por ejemplo, podemos ejecutar la reproducción al doble de velocidad para comprobar el impacto de una mayor contención por los recursos del sistema. Una mayor carga puede sacar a la luz problemas con el sistema, la aplicación, la configuración de la base de datos, etc., para poder solucionarlos antes de la migración.

Consideraciones sobre la reproducción

Antes he dicho que la herramienta podría recrear "condiciones cercanas a las de producción", ya que esto nunca va a ser perfecto. En primer lugar, las incoherencias de hardware, incluso en servidores con especificaciones aparentemente idénticas, pueden provocar diferencias. Además, se puede acceder a la base de datos de distintas maneras y con distintos lenguajes, cada uno con sus peculiaridades. También hay algunos aspectos interesantes con los plazos de envío de las consultas en un entorno conflictivo. Además, a menudo la aplicación se aloja en uno o varios servidores o máquinas cliente independientes que llegan a través de la red de diversas maneras.

Por este motivo, no es fácil realizar una evaluación comparativa formal que proporcione resultados repetibles de forma coherente. Hemos descubierto que al ejecutar varias reproducciones de los mismos archivos de datos se pueden obtener resultados de tiempo de ejecución diferentes. Cada sesión debería comenzar en el mismo orden que la sesión original, en el mismo intervalo desde la hora de inicio general y cada consulta debería estar en el mismo orden que la consulta original y, en igualdad de condiciones, debería comenzar en el mismo intervalo (a la hora de inicio); sin embargo, esto rara vez ocurre en los grandes trabajos de reproducción.

Después de muchas horas trabajando con la herramienta, creemos que incluso cambios muy pequeños, que a menudo están fuera de nuestro control, pueden tener una influencia significativa en el tiempo de ejecución global. Factores como un disco "lento" o defectuoso, recursos compartidos en un entorno VM, pequeñas diferencias en las velocidades de memoria/núcleo, etc., son todos factores. Recuerde que las consultas de reproducción ya se ejecutan en 1/10 y 1/100 de segundo en equipos potentes y, en ocasiones, pueden ejecutarse más de 100 subprocesos simultáneamente. Si una consulta se desincroniza con otros hilos, pueden producirse resultados impredecibles, como consultas que actúan sobre tablas vacías (ya que la consulta se ejecutó antes de que se cargaran los datos), o consultas de larga duración en las que la consulta comenzó antes de que se generaran las estadísticas del optimizador. Actian recomienda que se realicen 3-4 ejecuciones y se tome una media, cuando se ejecuten pruebas de rendimiento.

La reproducción también dispone de funciones para medir el rendimiento de las consultas individuales, el recuento de filas, las sesiones y el número de consultas. Las estadísticas de rendimiento de las consultas pueden, obviamente, ayudar a identificar las consultas de larga duración, aunque debido al párrafo anterior, sólo debe centrarse en las áreas que se repiten consistentemente a través de múltiples sesiones o repeticiones. Cada trabajo de reproducción genera un conjunto de archivos CSV que pueden cargarse en una hoja de cálculo para profundizar en esta información.

El equipo de Servicios de Actian ha utilizado la herramienta en bastantes compromisos con clientes y ha obtenido muy buenos resultados con ella. Un ejemplo reciente es su uso con un cliente que estaba llevando a cabo un proyecto de migración de plataforma para pasar a un servidor nuevo y más grande, en el que pudimos utilizar la herramienta QRP para configurar el nuevo servidor de modo que soportara mejor la carga de trabajo de producción real y, por lo tanto, proporcionó a los usuarios una experiencia de puesta en marcha mucho más fluida de lo que habría sido posible de otro modo, y una experiencia mejor que la que se había ofrecido nunca en proyectos de actualización anteriores.

En resumen, QRP es realmente útil y bastante sencillo de usar, aunque es un proyecto dirigido por la comunidad, en lugar de un producto con licencia, por lo que será necesaria cierta ingeniería práctica (por ejemplo, para construirlo a partir del código fuente más reciente), por lo que debería tener a alguien con conocimientos de desarrollo a mano durante la configuración. Hay algo de información en las páginas de la Comunidad Actian, tales como los requisitos previos y la disponibilidad de la plataforma, que le recomiendo que lea antes de intentarlo.

Encontrará información detallada sobre la configuración y el uso de la reproducción aquí:

https://github.com/ActianCorp/Dynamic_Playback/wiki/Dynamic-Playback-set-up-and-usage-page

Por supuesto, las nuevas funciones y las correcciones de errores de nuestra comunidad son bienvenidas. Muchas mejoras serían posibles, como la creación de una interfaz de usuario para supervisar el progreso a medida que ocurre, por ejemplo, y estoy seguro de que otras características se sugerirán por sí mismas a medida que la utilices.

Si necesita ayuda en profundidad, póngase en contacto conmigo o con alguien del equipo en services@actian.com. Estaremos encantados de ayudarle a empezar a utilizar la herramienta o a llevar a cabo un proyecto de actualización con ella y, por tanto, a obtener un resultado predecible y sin problemas.

Acerca de Sean Paton

Sean Paton es Director de Entrega del equipo de Servicios Profesionales del Reino Unido, donde ha dirigido la entrega de muchos compromisos de migración y actualización de plataformas durante varios años. Cuenta con más de 20 años de experiencia trabajando con Ingres.