Test de performance des charges de travail de production pour Ingres et Vector

L'une des principales préoccupations des clients d'Ingres et de Vector dont les systèmes doivent subir des changements importants, tels que des mises à niveau de versions majeures, des migrations de systèmes d'exploitation, des versions logicielles majeures, des volumes d'utilisation accrus, etc. est de savoir comment tester correctement la base de données dans des conditions réalistes au sein d'un environnement de test.

Certains clients ont entendu parler de l'outil requête, Recording and Playback), développé par Actian Professional Services, lors de réunions d'utilisateur . Cet outil vise à tester la base de données Ingres ou Vector dans des conditions proches de la production en enregistrant puis en lisant une charge de travail de production dans un environnement de test. Le reste de ce billet décrit plus en détail l'outil et son utilisation.

enregistrement de la requête

La requête Recording piece of QRP utilise le tracepoint "SC930", qui produit un enregistrement de toutes les requêtes lancées contre la base de données pendant la période où le tracepoint a été activé. La sortie de SC930 est essentiellement une série de fichiers texte, contenant les requêtes, les paramètres, les types de données, les données, etc. - c'est-à-dire la charge que nous voulons tester. L'utilisation du point de contrôle et les détails du format de sortie qu'il produit sont décrits plus en détail ici :

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

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

Ce point de contrôle - qui est généralement un moyen non documenté de modifier le comportement d'Ingres et de Vector - est désormais officiellement pris en charge et documenté dans les manuels des produits. En fait, une syntaxe supplémentaire a été ajoutée dans les dernières versions pour faciliter son utilisation (recherchez "SET SERVER_TRACE" dans les manuels), afin que vous puissiez l'utiliser vous-même pour une analyse ad hoc des requête . Par exemple, vous pouvez maintenant activer le traçage des requête uniquement pour des utilisateurs spécifiques qui exécutent des requêtes sur une base de données spécifique et dont le temps d'exécution dépasse une certaine durée, ce qui facilite grandement son utilisation à des fins de diagnostic - voir ici pour plus de détails pour Ingres et ici pour Vector v5.

L'utilisation du point de trace SC930 signifie que la partie de l'opération relative à l'enregistrement de la requête peut fonctionner sur les anciennes versions d'Ingres et de Vector qui ne support pas encore support server_trace.

requête Playback

Le playback est un ensemble d'outils séparé, écrit initialement par l'équipe Professional Services d'Actian, décrit dans le dépôt Github d'Actianici (avec des versions binaires également publiées sur Github mais le code source principal maintenu dans SVN ici), qui est conçu pour rejouer chaque requête sur votre système de test dans le même ordre et le même timing relatif que celui dans lequel elle a été enregistrée.

Dans ce contexte, on entend par "requête" toute instruction SQL pouvant être exécutée dans la base de données Ingres ou Vector. En fait, même si la "requête" est une requête SQL non valide, Playback essaiera de la rejouer et, si elle est non valide, elle échouera comme elle l'aurait fait lors de l'enregistrement.

La lecture est, pour l'essentiel, composée de deux éléments essentiels.

• Prétraitement :
  • Preprocess reformate les fichiers de sortie du SC930 de manière à ce qu'ils soient divisés en sessions individuelles et que chaque session, connexion et requête soit ordonnée par un horodatage. Cela nous a permis de nous assurer que nous pouvions lire chaque session en tant que thread séparé au bon moment, indépendamment de ce qui se passe dans les autres threads.
  • Preprocess est écrit en C# et peut fonctionner avec les environnements MONO ou .Net.
  • Cette opération ne doit être exécutée qu'une seule fois par enregistrement.
  • Les fichiers de sortie peuvent être exécutés sur un serveur et lus ailleurs.
• Lecture :
  • Un travail de lecture de base ouvre les fichiers individuels produits par le prétraitement et soumet un fil d'exécution distinct pour chaque session dans le même ordre et au même moment. Les threads doivent ensuite exécuter toutes les requêtes de ce fichier dans le même ordre et au même moment.
  • La lecture est écrite en C et fait appel aux fonctions standard de la bibliothèque SQL d'Ingres Embarqué , ce qui est sans doute le moyen le plus rapide de soumettre une requête à une base de données Ingres ou Vector, que ce soit localement ou sur un réseau.
  • Cette opération peut être exécutée autant de fois que vous le souhaitez.

La lecture peut aider à tester les conséquences de l'ajout d'une charge au système, de changements dans le matériel, tels que la réduction des cœurs ou de la mémoire, l'augmentation des volumes de données ou des utilisateurs, ainsi que l'établissement de lignes de base des performances pour tester ensuite les mises à niveau ou les correctifs. Par exemple, nous pouvons exécuter la lecture à une vitesse deux fois plus élevée pour tester l'impact d'une plus grande sollicitation des ressources du système. Une charge plus importante peut mettre en évidence des problèmes liés au système, à l'application, à la configuration de la base de données, etc. afin qu'ils puissent être résolus avant la transition.

Considérations relatives à la lecture

J'ai dit plus haut que l'outil pouvait recréer des "conditions proches de la production", mais il ne sera jamais parfait. Tout d'abord, les incohérences matérielles, même sur des serveurs dont les spécifications sont apparemment identiques, peuvent entraîner des différences. Ensuite, il est possible d'accéder à la base de données de différentes manières et en utilisant différents langages, chacun ayant ses propres particularités. Il existe également des aspects intéressants concernant le calendrier de soumission des requête dans un environnement litigieux. En outre, l'application est souvent hébergée sur un ou plusieurs serveurs distincts ou machines clientes qui arrivent sur le réseau de différentes manières.

Pour cette raison, il n'est pas facile de procéder à une analyse comparative formelle permettant d'obtenir des résultats reproductibles de manière cohérente. Nous avons constaté que l'exécution de plusieurs lectures des mêmes fichiers de données peut donner des résultats différents en termes de durée d'exécution. Chaque session devrait démarrer dans le même ordre que la session d'origine, au même intervalle par rapport à l'heure de début globale et chaque requête devrait être dans le même ordre que la requête origine et, toutes choses égales par ailleurs, devrait démarrer au même intervalle (par rapport à l'heure de début), mais c'est rarement le cas pour les gros travaux de lecture.

Après de nombreuses heures de travail avec l'outil, nous pensons que même de très petits changements, qui sont souvent hors de notre contrôle, peuvent avoir une influence significative sur le temps d'exécution global. Des éléments tels qu'un disque "lent" ou défectueux, des ressources partagées dans un environnement VM, des différences mineures dans la vitesse de la mémoire/des cœurs, etc. sont autant de facteurs. N'oubliez pas que les requêtes de lecture s'exécutent déjà en 1/10 et 1/100 de seconde sur des machines puissantes et qu'il arrive que plus de 100 threads s'exécutent simultanément. Si une requête se désynchronise avec les autres threads, cela peut conduire à des résultats imprévisibles, tels que des requêtes agissant sur des tables vides (car la requête s'est exécutée avant que les données ne soient chargées), ou des requêtes de longue durée où la requête a démarré avant que les statistiques de l'optimiseur n'aient été générées. Actian recommande d'effectuer 3 à 4 exécutions et de prendre une moyenne lors des tests de performance.

La lecture comporte également des fonctions permettant de mesurer les performances des requête individuelles, le nombre de lignes, les sessions et le nombre de requêtes. Les statistiques de performance des requête peuvent évidemment aider à identifier les requêtes de longue durée, bien qu'en raison du paragraphe précédent, vous ne devriez vous concentrer que sur les domaines qui se reproduisent de manière cohérente sur plusieurs sessions ou rediffusions. Un ensemble de fichiers CSV est produit par chaque tâche de lecture, qui peut être chargé dans une feuille de calcul pour faciliter l'analyse de ces informations.

L'équipe Services d'Actian a utilisé l'outil dans le cadre de plusieurs engagements avec des clients et a obtenu de très bons résultats. Nous avons pu utiliser l'outil QRP pour configurer le nouveau serveur afin qu'il support mieux support charge de travail réelle de la production, ce qui a permis aux utilisateurs de bénéficier d'une expérience de mise en service beaucoup plus fluide que ce qui aurait été possible autrement, et d'une expérience meilleure que ce qui avait été réalisé dans le cadre de projets de mise à niveau antérieurs.

En résumé, QRP est vraiment utile et assez simple à utiliser, bien qu'il s'agisse d'un projet mené par la communauté, plutôt que d'un produit sous licence, de sorte qu'un peu d'ingénierie pratique sera nécessaire (par exemple, pour le construire à partir du dernier code source), de sorte que vous devriez avoir quelqu'un avec des compétences en développement à portée de main pendant l'installation. Il y a de bonnes informations à ce sujet sur les pages de la communauté Actian, comme les pré-requis et la disponibilité de la plateforme, que je vous recommande de lire avant de tenter l'expérience.

Des informations détaillées sur la configuration et l'utilisation de la lecture peuvent être trouvées ici :

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

Bien entendu, les nouvelles fonctionnalités et les corrections de bogues apportées par notre communauté sont les bienvenues ! De nombreuses améliorations seraient possibles, comme par exemple la construction d'une interface utilisateur pour suivre la progression au fur et à mesure - et je suis sûr que d'autres fonctionnalités s'imposeront d'elles-mêmes au fur et à mesure que vous l'utiliserez.

Si vous avez besoin d'une aide plus approfondie, contactez-moi ou l'un des membres de l'équipe à l'adresse services@actian.com. Nous serions très heureux de vous aider à démarrer avec l'outil, ou à mener un projet de mise à niveau en l'utilisant, et donc à obtenir un résultat harmonieux et prévisible.

À propos de Sean Paton

Sean Paton est Delivery Manager au sein de l'équipe des services professionnels du Royaume-Uni, où il dirige depuis plusieurs années la réalisation de nombreux projets de migration et de mise à niveau de plates-formes. Il a plus de 20 ans d'expérience avec Ingres.