Télécharger la présentation
La présentation est en train de télécharger. S'il vous plaît, attendez
Publié parPerrine Gerard Modifié depuis plus de 9 années
1
Quelle(s) application(s) pour GDS ? Eddy Caron LIP ENS Lyon Join work with A. Vernois and J.-Y. L’Excellent LIP, Lyon V. Garonne CPPM/IN2P3, Marseille
2
Intro Gestion des données dans 3 applications susceptibles d’utiliser les résultats de GDS Bioinformatique: GriPPS Solveurs creux: TLSE Physique des particules: LHCb
3
Bioinformatique GriPPS The Grid Protein Pattern Scanning
4
Application bioinformatique: Contexte des banques de données de référence fichiers texte « à plat » de qq Mos � plusieurs Gos mise � jour : de quotidienne à mensuelle nombre et volume augmentent rapidement Requêtes en très grand nombre indépendantes impliquant 1 ou 2 banques temps d'exécution linéaire
5
Analyse des logs A partir des logs de NPS@ : des requêtes plus fréquentes que d'autres blast sur sp.fas : 77% des requêtes globalement, l'utilisation reste la même On peut utiliser l'analyse des requêtes précédentes comme point de départ.
6
Quelques chiffres Source: Traces du serveur NPS@ de l’IBCP Number of databanks m23 Number of algorithms p8 Number of couple algorithm databanks80 Number of requests88730 Size of smallest databanks1 MB Size of largest databanks12 GB
7
Solveurs Creux : Grid TLSE
8
http://www.enseeiht.fr/lima/tlse Grid TLSE: expert site for sparse linear solvers Tests for Large Systems of Equations Coordinated by ENSEEIHT-IRIT, Toulouse Funded by ACI GRID Goal Provide a friendly test environment for expert and non-expert users of sparse direct linear algebra software Easy access to software and tools, a wide range of computer architectures, matrix collections On a user’s specific problem, compare execution time / accuracy / memory usage / of various sparse solvers public domain as well as commercial, sequential as well as parallel Find best parameter values / reordering heuristics on a given problem
9
Request Examples Memory required to factor a matrix Error analysis as a function of the threshold pivoting value Minimum time on a given computer to factor a given unsymmetric matrix Which ordering heuristic is the best for solving a given problem
10
Why using a grid ? Sparse linear algebra software makes use of sophisticated algorithms for (pre/post)-processing the matrix Multiple parameters interfere for the efficient execution of sparse linear solvers Ordering Amount of memory Architecture of the target computer Available libraries Determining the best combination of parameter values is multi-parametric problem Combinatorial nature of these parameters The installation of any sparse solver library on a new architecture can be a nightmare ! Testing different architectures Always using the latest version of each library
11
Is it realistic ? Time to send the data can be more important than the computation itself ! But Large number of independent requests Time to answer is not critical Data persistency between elementary requests easy to express Clear need for the users ! Managing software and hardware testing from a PSE
12
Architecture ClientExpert Expert Site Grid TLSE Websolve Weaver DIET Database Matrix Collections History Log Files Scenarios Services StaticDynamic Connection Synthetic Results Expertise Request Solver Runs Partial Results Requests Results Consult/Modify Stats Client Provided Matrix Consult Modify Writes scenarios, deploy new software Sends experiment requests
13
Data management in GRID TLSE Access to large collections of sparse matrices (URLs of files outside the DIET architecture) Matrix files can be large (sometimes a few GBytes in worst cases). Each server manages a cache mechanism. Use DIET plug-in schedulers (or load function) to help choosing the platform, example: if matrix file is not in cache (on disk) then server_adequacy= «bad» (the request will first download the file) else server_adequacy = «good» (the file is already available) endif Requires at least the matrix name to be passed to the SeDs before choosing.
14
Data management in GRID TLSE Management of temporary data could be done using persistency/replication mechanisms within DIET Example: the user asks for the impact of reordering on his matrix for different solvers and platforms Some services (MUMPS, UMFPACK, …) first compute permutations files. Permutation files are then applied to different solvers on different platforms to perform the actual computation. Results of elementary requests are presented to the user through the web interface. Permutation files must be cleaned when the user’s (meta) request has completed.
15
Physique des particules
16
Expérience LHCb Installée auprès du futur collisionneur proton-proton le Large Hadron Collider a Genève (CERN) avec trois autres expériences Démarrage prévue en 2007 Étude précise de la violation de CP dans les systèmes de mésons beaux produits lors de collisions proton-proton 40x106 collisions par secondes Taux de données: 200 Ko/200Hz Chaque collision ou évènement est indépendant : La taille d’un évènement varie selon la physique observée: LHCb (physique rare), 3 Mo
17
Caractéristiques Gros volumes de données à: Analyser Générer par simulation de Monte-Carlo Stockage de l’ordre de 1.3 péta octets par an Partager 500 utilisateurs répartis sur 20 sites dans le monde
18
LHCb: Types d’applications Production de données: Produire un montant donné en une période fixée Analyse de données: Extraire la physique des données Appliquer un algorithme sur un ensemble de données
19
DIRAC: Caractéristiques des applications Production de données Traitement des données Analyse de données Application Multiparamétriques Pas de dépendances de données Production de données CPU Bound Gros grain Dépendances de données Production de résultats I/O Bound Petit grain Planifié Pour une expérience Puissance de calcul/période «High Troughput Computing» (HTC) Chaotique/aléatoire Pour un utilisateur Temps de réponses/Job « High Performance Computing »(HPC)
20
LHCb: Data Challenge 2004 Produire et analyser des données en vue de préparer la mise en service du LHC (2007) Avoir 10 % des données du système final: 50 To de données/trois mois~150 000 jobs 20 sites ~2000 Worker Nodes Grande hétérogénéité des ressources Analyser ces données Appliquant au préalable une sélection des fichiers intéressant par l’intermédiaire d’un service de méta-data
21
*approximatif car en cours de redéfinition, au moins un facteur 2… Ordre de grandeur* Par simulation: 700 To par an, ~2 000 000 fichiers Taille des fichiers: ~1 Go Sécable par événement de 3 Mo Par acquisition du détecteur: Équivalent Analyse: De 1 à 100 fichiers Fichiers pouvant être lus partiellement Traités par événement Dépendances aux données peuvent être indéterminées au départ de la tâche
22
Outils usuelles de gestion des données Mass storage, storage classique Primitives de transferts: BBFTP, grid-ftp, etc. File catalog: correspondance logical file name, physical file name Meta-data catalog: permets de sélectionner les data sets intéressant Pas encore d’outils standards: Replica Manager (local/global) File transfer service Pending file transfer service …
23
Références http://project-lcg-gag.web.cern.ch/project-lcg- gag/LCG_GAG_Docs/HEPCAL-prime.doc http://project-lcg-gag.web.cern.ch/project-lcg- gag/LCG_GAG_Docs/HEPCAL-prime.doc http://lcg.web.cern.ch/LCG/sc2/GAG/HEPCAL-II.doc
24
Question et Conclusion Conclusion : Il reste une question Question : Quelle(s) application(s) cible(s) pour GDS ?
Présentations similaires
© 2024 SlidePlayer.fr Inc.
All rights reserved.