Adapting to changing resource performance in grid query processing Anastasios Gounaris Jim Smith Norman W. Paton Paul Watson Rizos Sakellariou University of Newcastle Alvaro A.A. Fernandes upon Tyne University of Manchester Publié le septembre 2005 présenté par : Michel EL RAHI

Plan Introduction Définitions Problème Approche Evaluation Conclusion & critiques 2

Introduction Le traitement de requête de grille est particulièrement approprié où il y a un besoin d'intégrer et analyser l'information de différentes sources pendant des périodes spécifiques. les ressources de grille, aussi bien qu'être hétérogènes, peuvent également montrer le comportement imprévisible et volatil. Indisponibilité des statistiques précises sur le temps de compilation et les conditions d'exécution d'évolution. 3 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

Definitions OGSA-DQP (Grid Query Evaluator Service): 1.Un processeur de requête distribué exposé aux utilisateurs. 2.Maintient la compilation et l’évaluation des requêtes. 3.Soutient l'accès aux services multiples de grille. Grid Data Service Factory (GDSF): 1.Représente les ressources de données. 2. Expose les capacités et les metadonnées. DefinitionsProblèmeApprocheEvaluationConclusion et critiques 4 Introduction

Definitions Grid Data Service (GDS): 1.Créer par GDSF. 2.Utiliser pour l’accès aux ressources de données. GDQS (Grid Distributed Query Service): 1.Accepte des requêtes d'utilisateur. Il lance la compilation et l'optimisation des requêtes pour rapporter des plans d'exécution. GQES (Grid Query Evaluator Service): 1.Un moteur d'évaluation qui est capable de courir un sous plan d'un plan distribué de requête produit par un GDQS. 2.L'exécution distribuée de requête est donc effectuée par un ensemble de GQES qui communiquent en échangeant des tuples. 5 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

Definitions Exécution d’une requête: 6 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

Problème Grille. Ralentissement dans une machine ! Diminution de la performance du système entier.!!! Solution aborder par le système… 7 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

Approche Une architecture pour le traitement adaptatif de requête qui est caractérisé par les dispositifs suivants: non centralisé, orienté service, et ses composants communiquent d’une manière asynchrone. L'AGQES (Adaptive Grid Query Evaluator Service) est configuré de la façon suivante: Le MonitoringEventDetector est en activité dans chaque emplacement évaluant un fragment de requête. Il doit également y avoir un Diagnoser activé et un répondeur. Supposant un sous plan P est divisé à travers n machines, et que P i, i = 1... n, est le fragment sous plan envoyé à l’i eme AGQES. C(P i ) = coût par tuple pour chaque sous plan. 8 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

AGQES (Adaptive Grid Query Evaluator Service) MonitoringEventDetector Diagnoser Responder (répondeur) Query Engine MonitoringEventDetector Diagnoser Responder (répondeur) Query Engine Submit plan fragment subscribe raw monitoring events Adpt execution Send notificationsubscribe Send notification AGQES 9 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

AGQES (Adaptive Grid Query Evaluator Service) Surveillance (monitoring): oLe moteur de requête produit des notifications des deux types suivants: 1.M1, qui contient des informations sur le coût de traitement d'un tuple. 2.M2, qui contient des informations sur le coût de communication d'un buffer sortant des tuples. oCes notifications de bas niveau sont envoyés au MonitoringEventDetector, qui: 1.Groupe les notifications de deux types M1 et M2. 2.Calcule la moyenne du coût de fonctionnement. 3.Produit une notification à envoyer à Diagnoser si la valeur moyenne change par rapport à un seuil. 10 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

AGQES (Adaptive Grid Query Evaluator Service) Surveillance (monitoring):  Un exemple des paramètres pris en défaut: 1.La fréquence de surveillance pour le moteur de requête est un notification pour chaque 10 tuples produits (pour M1) et un notification pour chaque buffer envoyé (pour M2). 2.Le seuil pour produire des notifications pour le Diagnosers est placé à 20%. 11 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

AGQES (Adaptive Grid Query Evaluator Service) Évaluation: oL'évaluation est effectuée par le Diagnoser. Il recueille l'information produite par MonitoringEventDetectors pour établir s'il y a un déséquilibre de charge de travail. oLe Diagnoser se rend compte de la politique de distribution courante de tuple, qui est représentée comme vecteur W = (w 1, w 2... w n ), où le w i représente la proportion de tuples qui est envoyée à p i. oW'= (w' 1, w' w' n ) = vecteur équilibré calculé par le diagnoser. oLe coût par tuple c(p i ) pour un sous plan peut être calculé de deux manières: 1.A1, qui tient compte seulement des notifications du type M1. 2.A2, qui tient compte en plus des notifications du type M2. 12 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

AGQES (Adaptive Grid Query Evaluator Service) Réponse: oLe répondeur reçoit des notifications au sujet de déséquilibre du Diagnoser sous forme de vecteurs augmentés proposés W' de distribution de charge de travail. oLa distribution de données peut changer de deux manières: 1.R1, où les tuples dans les recovery logs sont redistribués selon la nouvelle politique de distribution de données. Nous appelons cette redistribution rétrospective. 2.R2, où les tuples dans les buffers et les recovery logs ne sont pas affectés. Nous appelons cette redistribution prospective. 13 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

Évaluation Q1: select EntropyAnalyser(p.sequence) from protein sequences p; Q2: select i.ORF2 from protein sequences p, protein interactions i where i.ORF1=p.ORF ; Trois machines RedHat Linux 9 connectées par un réseau de 100 mb/s sont utilisées pour l’évaluation. 14 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

Évaluation 1.Augmentation de 45% quand l'adaptation est permise par opposition à 253% quand elle n’est pas permise. 2.Une augmentation de 57% quand l'adaptation est permise. 3.Dans le cas du déséquilibre et de l’adaptation, le système fait courir 1,31 fois plus lent au lieu de 1,71. Query- Response No ad / no imb Ad / no imb No ad / imb Ad / imb Q1 – R Q1 – R Q2 – R le coût d’appel d’un WS dans une machine est 10 fois plus que dans l'autre 15 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

Évaluation (a) Performance de Q1 pour l’adaptation prospective R2; (b) Performance de Q1 pour différentes politiques de l’adaptation. 16 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

Évaluation (a) Performance de Q2 pour l’adaptation rétrospective; (b) Performance de Q1 pour l’adaptation prospective et pour une donnée de taille double. 17 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

Évaluation Performance de Q1 pour l’adaptation rétrospective. 18 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

Conclusion et critiques Conclusion 1.Cette proposition est une bonne solution sur le problème de charge de travail dynamique. 2.Particulièrement l’implémentation pour cette proposition est sur les environnements comme la grille. Critiques 1.Manque de la structuration. 2.Utilise seulement trois machines semblables pour l'évaluation.!!!!!! 3.Plusieurs idées sont répétées plusieurs fois. 4.Pas de comparaison avec les anciennes approches sur ce sujet. 19 DefinitionsProblèmeApprocheEvaluationConclusion et critiquesIntroduction

Merci pour votre attention !