WO2005010633A2 - Procédé de gestion de l'exécution d'au moins un programme sur plusieurs calculateurs - Google Patents

Procédé de gestion de l'exécution d'au moins un programme sur plusieurs calculateurs Download PDF

Info

Publication number
WO2005010633A2
WO2005010633A2 PCT/FR2004/001911 FR2004001911W WO2005010633A2 WO 2005010633 A2 WO2005010633 A2 WO 2005010633A2 FR 2004001911 W FR2004001911 W FR 2004001911W WO 2005010633 A2 WO2005010633 A2 WO 2005010633A2
Authority
WO
WIPO (PCT)
Prior art keywords
program
computer
execution
request
input data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2004/001911
Other languages
English (en)
Other versions
WO2005010633A3 (fr
Inventor
Michel Mars
Cyril Grisier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of WO2005010633A2 publication Critical patent/WO2005010633A2/fr
Publication of WO2005010633A3 publication Critical patent/WO2005010633A3/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load

Definitions

  • the present invention relates to a method for managing the execution of at least one program on several computers. More specifically, the invention relates to a method for managing the execution of at least one program associated with a list of input data necessary for the execution of this program, the program being suitable for execution distributed by a manager of processing on several computers thanks to the distribution of its input data.
  • This method includes a step of receiving a request to execute the program.
  • This method assumes that the program input data is decorrelated, so that it can be processed separately. Thus, it is possible to distribute the execution of this program on several computers, each of them partially carrying out the calculation taking into account only a part of the input data. Then the different results given by each of the calculators are combined to form a final result.
  • the problem with such a distribution of the execution of a program is that it generally does not take account of information on the respective computing capacities of the computers. Thus, if one of the computers has a computation capacity inferior to the others, it risks being entirely called upon when a complex calculation is launched, to the point of reaching saturation and thus delaying the final result of this calculation, while other larger capacity computers are only partially used.
  • the object of the invention is to remedy this drawback by providing a method for managing the execution of a program, capable of regulating the distribution of the execution of the program on the various computers while making the most of the capacities of the available computers.
  • the subject of the invention is a method for managing the execution of at least one program associated with a list of input data necessary for the execution of this program, the program being suitable for distributed execution.
  • a computer is selected from a plurality of computers according to an availability criterion, a priori, to execute this request ; - We test whether the selected computer has sufficient resources to execute the entire request; If not, we select a part of the input data on which we consider that the selected computer has sufficient resources to execute the program, and we generate from the request, a first sub-request to execute the program. on this selected part of the input data and at least one second sub-request for execution of the program on the rest of the input data.
  • the method according to the invention proposes, on the one hand, the choice of a computer for performing a partial contributory calculation of the final result, and on the other hand, the extraction, for this selected computer, of a subset optimal input data that will be processed by it so that it is not saturated.
  • the election of a computer combined with an a priori dimensioning of the calculation which will be carried out by this computer allows load balancing ensuring never to exceed the limits of any of the computers requested.
  • Such a method therefore eliminates any risk of saturation of the computers, regardless of the number of requests to be executed.
  • a method for managing the execution of a program according to the invention may also include one or more of the following characteristics: the first sub-query is executed on the selected computer; the criterion of availability of a computer to execute a request is directly linked to the comparison of the number of processes, originating from the processing manager, running on this computer with the number of processes, originating from the processing manager, executable simultaneously on this calculator; the criterion for the availability of a computer to execute a request is the ratio of the number of processes originating from the processing manager running on this computer to the number of processes originating from the processing manager executable simultaneously on this computer, and the selected calculator is the one for which this ratio is the lowest; the availability criterion of a computer to execute a query is weighted by the estimation of a load coefficient dependent on the resources of the computer, in particular the number of processes running on the computer at the time of the test or the RAM used; during the test step of the selected computer, the number of input data of the request is compared to an estimated maximum number of input data that the selected computer is
  • NE e E ⁇ NE R .- ⁇ -. CE + ⁇ ) ⁇ NP, where: E () is the Whole Part function, NE e is the number of input data that the selected computer is a priori capable of processing , NE R is the number of input data of the request, NP e is the number of processes coming from the processing manager executable simultaneously on the selected calculator, ⁇ NR, is the sum on all the calculators of the number of processes coming from the processing manager executable simultaneously on each computer, and CE is the spreading coefficient.
  • FIG. 1 represents a structural diagram of a management system for the implementation implementing a method according to the invention
  • FIG. 2 illustrates the successive steps of a method for managing the execution of a program according to the invention
  • - Figure 3 shows a block diagram of the combination of partial results of a query executed according to the management method of Figure 2
  • FIG. 1 shows a system comprising a user terminal 10, a processing manager 12 and computers 14 ⁇ ..., 14 n .
  • the term “processing manager 12” is understood here to mean a processing management server. But one could also designate by this expression software installed on such a server.
  • the user terminal 10 is, for example, a microcomputer of the conventional type suitable for transmitting requests for executing programs to the processing manager 12.
  • the processing manager 12 is also a microcomputer of the conventional type, comprising means storage, such as a memory 15, for the at least temporary storage of a waiting list 17 of requests from one or more user terminals such as the terminal 10, and for the storage of results 50 at least partial from the execution of requests from the list 17.
  • Each computer 14j is connected to the processing manager 12 and is provided with at least one processor.
  • the computer 14 ⁇ comprises a single processor 16 ⁇
  • the computer 14 2 comprises four processors 16 2 , 16 3 , 16 4 , 16 and the computer 14 n comprises two processors 16 m ., and 16 m .
  • the computers are therefore not all identical: some are single-processor, while others are dual-processor or multi-processor. As can be seen in FIG.
  • a user returns to the user terminal 10 a request R ⁇ (P, D) for executing a program P associated with a list D of data input.
  • This request R ⁇ P, D) is then sent to the processing manager 12 and we go to a step 22 of classifying this request Ri in the waiting list 17 of requests.
  • the waiting list 17 comprises for example other requests already received by the processing manager 12, either from the same user terminal 10, or from any other user terminal. These requests can be, for example, requests to execute the same program P associated with another list of data, or requests to execute other programs associated with other input data.
  • the decorrelation of these input data means that it is possible to carry out executions of the program P on each of them separately.
  • List D of input data can comprise several hundred thousand input data, these being simple or multivalued.
  • the decorrelation of these input data is a sine qua non condition for the distribution of the execution of the program P over several computers 14,.
  • the requests from the waiting list 17 are classified in order of priority of execution.
  • the priority of the requests on the waiting list 17 can be defined in different ways, such as by a system of a priori definition of priorities which would consist in entering a priority number during the step 18 of entering each request, or again, such as by a FIFO type processing principle consisting of processing requests by order of arrival.
  • step 24 of electing a priority request corresponding to the first request of the waiting list 17.
  • the priority request is the request previously received by the processing manager 12 during step 18, that is to say the request R ⁇ P, D).
  • the priority request could of course have been one of the other requests contained in the list 17.
  • the processing manager 12 calculates for each of the computers 14, the value np / NP, where np, represents the number of processes running on the computer 14, and NP, the number of processes executable simultaneously on this computer 14 ,.
  • a process corresponds to the execution of a program by a computer on input data associated with this program.
  • the elected calculator 14 ⁇ is the calculator 14, for which the value np / NP, is the smallest.
  • it is possible to choose the most available computer according to other criteria such as the estimation of a load coefficient, dynamically calculated on each computer taking into account the resources of each computer such as the number of active processes on the computer running at the time of the test or the RAM used.
  • step 26 of electing the computer consists of always choosing the least loaded computer.
  • the elected computer 14 e is determined, we pass to steps intended to determine the way of distributing the execution of the priority request R ⁇ (P, D).
  • the following two parameters are compared: NE m , n , representing the minimum number of input data to be processed on any computer 14, during the execution of a program, this parameter allowing not to distribute the priority request on more than one computer if it is deemed small a priori (that is to say fully acceptable by the smallest computer); NE R corresponding to the total number of input data that the priority request R ⁇ (P, D) must process, that is to say the number of input data appearing in the list D.
  • the step 28 for executing the priority request R ⁇ P, D) is optionally followed by a step 29 for processing the results, comprising for example the storage, formatting and display of the results on the interface of the terminal. user 10. If NE R > NE m ⁇ n , then we go to a step 30 for calculating the maximum number NE e of input data that the elected computer 14 e is a priori capable of processing.
  • the processing manager 12 takes into account different parameters: n Y l NP l representing the sum, on all the computers 14 radical of processes, originating from the processing manager 12, executable simultaneously on each computer 14, ; NP e corresponding to the number of processes, originating from the processing manager, executable simultaneously on the elected computer 14 e , and the value of which can be modified by the user and / or dynamically; and CE representing a spreading coefficient defined by the processing manager 12 and whose value can be modified by the user, and / or dynamically, this spreading coefficient making it possible, for all of the computers, to group together in a greater or lesser number of sub-requests the execution of the priority request R ⁇ (P, D).
  • the spreading coefficient CE is such that:
  • ⁇ () represents the "Whole Part" function.
  • a test step 31 consisting in comparing the number ⁇ E e calculated during step 30 with the total number NE R of input data that the priority request R ⁇ P, D) must process. This step makes it possible to determine whether the elected computer 14 e is able to execute the priority request R ⁇ P, D) in its entirety.
  • NE R ⁇ NE e that is to say if the resources available from the elected computer 14 e are sufficient to execute the priority request R ⁇ P, D) in its entirety, we then go to step 28 d ' complete execution of this priority request and the method is simultaneously carried over to step 24 of electing another priority request to be processed. If NE R > NE e , that is to say if the elected computer 14 ⁇ does not have sufficient resources to execute the priority request R ⁇ P, D) in its entirety, we then pass to two steps 32 and 34 for generating sub-requests from the priority request R ⁇ P, D).
  • Step 32 consists in generating a first sub-request R s ⁇ (P, D ⁇ which one of the processors of the elected computer 14 e is capable of processing.
  • This first sub -request R s ⁇ (P, D,) is such that the list D, contains NE e input data, NE e having been estimated during step 30.
  • Step 34 consists in generating a second sub-request R s2 (P, D 2 ), intended to be executed with the input data which are not included in the list D of input data on which the subquery R s ⁇ (P, D ⁇ . D 2 is the complement of D ⁇ in D and includes NE R -NE e input data.
  • the second subquery R S2 (P, D 2 ) generated is sent to the waiting list 17 of the requests. The process is then carried over to the classification step 22 of the requests of the waiting list 17.
  • the first sub-request R s ⁇ (P, D,) generated is sent to the elected computer 14 ⁇ which executes it during an execution step 40 and the method is at the same time carried over to step 24 of electing another request
  • the computer 14 e sends the results from step 40 to the processing manager 12.
  • This step 42 for sending re results is followed by a step 44 of storage by the processing manager 12 of the results of the execution of the first subquery R s1 (P, Di) in the memory 15.
  • the execution of a request such as the request R ⁇ P, D) entered during step 18, can lead, after the application of a method such as that described in FIG.
  • steps 44, 46 ⁇ 46 2 46 q for storing intermediate results are the results of the execution of all the subqueries generated from the query R ⁇ (P, D) in order to distribute the execution of this query R ⁇ P, D) on several computers 14d.
  • steps 44, 46 ! , 46 2 46 q for storing the results by the distribution manager 12 we go to a step 48 of combining all these results into a final result 50 of the request R ⁇ (P, D).
  • the final result 50 of the request R ⁇ P, D) is then sent to the user terminal
  • the management system can execute several programs Pi, P, ..., Pz transmitted in the form of requests by several user terminals.
  • the system can provide an information function of the progress of the execution of the requests.
  • a messaging system can report to each user client, in the case where the system comprises several user terminals 10, of the progress of its requests or, overall, of the progress of all the requests to a client administrator.
  • other conventional functions such as starting the execution of deferred requests, fault management, request synchronization mechanisms, or even a automatic stop allowing to stop a request whatever its status, running or in queue.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multi Processors (AREA)

Abstract

L'invention concerne un procédé de gestion de l'exécution d'au moins un programme (P) associé à une liste de données d'entrée (D) nécessaires à l'exécution de ce programme (P). Le programme est adapté pour une exécution distribuée sur plusieurs calculateurs (14i) grâce à la distribution de ses données d'entrée, et comporte une étape (18) de réception d'une requête (R1(P, D)) d'exécution du programme (P). Le procédé comporte en outre les étapes suivantes - On sélectionne (26) un calculateur (14e) parmi une pluralité de calculateurs (14i) selon un critère de disponibilité, a priori, à exécuter cette requête (R1(P, D)); - On teste (31) si le calculateur sélectionné (14e) a les ressources suffisantes pour exécuter la totalité de la requête (R1(P, D)); - Si on sélectionne (30) une partie (D1) des données d'entrée sur laquelle on estime que le calculateur sélectionné (14e) a les ressources suffisantes pour exécuter le programme (P), et l'on génère (32, 34) une première sous-requête (Rs1(P, D1)) d'exécution du programme (P) sur cette partie (D1).

Description

Procédé de gestion de l'exécution d'au moins un programme sur plusieurs calculateurs
La présente invention concerne un procédé de gestion de l'exécution d'au moins un programme sur plusieurs calculateurs. Plus précisément l'invention concerne un procédé de gestion de l'exécution d'au moins un programme associé à une liste de données d'entrée nécessaires à l'exécution de ce programme, le programme étant adapté pour une exécution distribuée par un gestionnaire de traitement sur plusieurs calculateurs grâce à la distribution de ses données d'entrée. Ce procédé comporte une étape de réception d'une requête d'exécution du programme. On sait que la taille et la complexité des programmes d'ordinateurs augmentent et qu'il est donc nécessaire d'en optimiser le temps de calcul. Une solution pour augmenter la vitesse d'exécution de ces calculs consiste à répartir l'exécution d'un programme sur plusieurs calculateurs selon une méthode connue sous le nom de parallélisation. Chaque calculateur possède un ou plusieurs processeurs pour l'exécution du programme. Cette méthode suppose que les données d'entrées du programme sont décorrélées, de façon à pouvoir les traiter séparément. Ainsi, il est possible de distribuer l'exécution de ce programme sur plusieurs calculateurs, chacun d'eux effectuant partiellement le calcul en ne tenant compte que d'une partie des données d'entrée. Ensuite les différents résultats donnés par chacun des calculateurs sont combinés pour former un résultat final. Le problème d'une telle distribution de l'exécution d'un programme consiste en ce qu'elle ne tient en général pas compte d'informations sur les capacités de calcul respectives des calculateurs. Ainsi, si l'un des calculateurs a une capacité de calcul inférieure aux autres, il risque d'être entièrement sollicité lorsqu'un calcul complexe est lancé, au point d'arriver à saturation et de retarder ainsi le résultat final de ce calcul, alors que d'autres calculateurs de capacité plus grande ne sont que partiellement sollicités. L'invention a pour but de remédier à cet inconvénient en fournissant un procédé de gestion de l'exécution d'un programme, capable de réguler la distribution de l'exécution du programme sur les différents calculateurs en profitant au mieux des capacités des calculateurs disponibles. A cet effet, l'invention a pour objet un procédé de gestion de l'exécution d'au moins un programme associé à une liste de données d'entrée nécessaires à l'exécution de ce programme, le programme étant adapté pour une exécution distribuée par un gestionnaire de traitement sur plusieurs calculateurs grâce à la distribution de ses données d'entrée, comportant une étape de réception d'une requête d'exécution du programme, caractérisé en ce qu'il comporte en outre les étapes suivantes : On sélectionne un calculateur parmi une pluralité de calculateurs selon un critère de disponibilité, a priori, à exécuter cette requête ; - On teste si le calculateur sélectionné a les ressources suffisantes pour exécuter la totalité de la requête ; Si non, on sélectionne une partie des données d'entrée sur laquelle on estime que le calculateur sélectionné a les ressources suffisantes pour exécuter le programme, et l'on génère à partir de la requête, une première sous-requête d'exécution du programme sur cette partie sélectionnée des données d'entrée et au moins une seconde sous-requête d'exécution du programme sur le reste des données d'entrée. Le procédé selon l'invention propose, d'une part, le choix d'un calculateur pour exécuter un calcul partiel contributif du résultat final, et d'autre part, l'extraction, pour ce calculateur sélectionné, d'un sous-ensemble optimal des données d'entrée qui seront traitées par celui-ci afin qu'il ne soit pas mis en état de saturation. Ainsi, l'élection d'un calculateur, combinée à un dimensionnement a priori du calcul qui sera effectué par ce calculateur permet un équilibrage de charge assurant de ne jamais dépasser les limites d'aucun des calculateurs sollicités. Un tel procédé élimine donc tout risque de saturation des calculateurs, quel que soit le nombre de requêtes à exécuter. Un procédé de gestion de l'exécution d'un programme selon l'invention peut en outre comporter l'une ou plusieurs des caractéristiques suivantes : on exécute la première sous-requête sur le calculateur sélectionné ; le critère de disponibilité d'un calculateur à exécuter une requête est directement lié à la comparaison du nombre de processus, issus du gestionnaire de traitement, en cours d'exécution sur ce calculateur au nombre de processus, issus du gestionnaire de traitement, exécutables simultanément sur ce calculateur ; le critère de disponibilité d'un calculateur à exécuter une requête est le rapport du nombre de processus issus du gestionnaire de traitement en cours d'exécution sur ce calculateur sur le nombre de processus issus du gestionnaire de traitement exécutables simultanément sur ce calculateur, et le calculateur sélectionné est celui pour lequel ce rapport est le plus faible ; le critère de disponibilité d'un calculateur à exécuter une requête est pondéré par l'estimation d'un coefficient de charge dépendant des ressources du calculateur, notamment le nombre de processus en cours d'exécution sur le calculateur au moment du test ou la mémoire vive utilisée ; lors de l'étape de test du calculateur sélectionné, on compare le nombre de données d'entrée de la requête à un nombre maximal estimé de données d'entrées que le calculateur sélectionné est a priori capable de traiter ; le nombre maximal de données d'entrées que le calculateur sélectionné est a priori capable de traiter est estimé à partir des paramètres suivants : le nombre de données d'entrée de la requête, la somme sur tous les calculateurs du nombre de processus, issus du gestionnaire de traitement, exécutables simultanément sur chaque calculateur, un nombre de processus, issus du gestionnaire de traitement, exécutables simultanément sur le calculateur sélectionné, et un coefficient d'étalement défini par le gestionnaire de traitement et permettant de diviser en un nombre plus ou moins grand de sous-requêtes l'exécution de la requête ; - le nombre maximal de données d'entrées que le calculateur sélectionné est a priori capable de traiter est estimé à partir de la formule suivante :
NEe = E{NER.-^-.CE + \) ∑ NP, où : E() est la fonction Partie Entière, NEe est le nombre de données d'entrées que le calculateur sélectionné est a priori capable de traiter, NER est le nombre de données d'entrée de la requête, NPe est le nombre de processus issus du gestionnaire de traitement exécutables simultanément sur le calculateur sélectionné, ^ NR, est la somme sur tous les calculateurs du nombre de processus issus du gestionnaire de traitement exécutables simultanément sur chaque calculateur, et CE est le coefficient d'étalement. - les valeurs du coefficient d'étalement et du nombre de processus, issus du gestionnaire de traitement, exécutables simultanément sur un calculateur sont modifiables par l'utilisateur, et ou de façon dynamique ; la partie des données d'entrée sur laquelle est générée la première sous- requête correspond au nombre maximal de données d'entrées que le calculateur sélectionné est a priori capable de traiter ; on sélectionne la requête parmi une liste de requêtes classées par ordre de priorité ; on renvoie dans la liste des requêtes la seconde sous-requête ; et on affecte à chaque requête de la liste un coefficient de priorité, et les requêtes de coefficients de priorité égaux sont classées par ordre d'arrivée dans la liste. L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés dans lesquels : la figure 1 représente un schéma structurel d'un système de gestion pour la mise en oeuvre d'un procédé selon l'invention ; la figure 2 illustre les étapes successives d'un procédé de gestion de l'exécution d'un programme selon l'invention ; - la figure 3 représente un schéma fonctionnel de la combinaison des résultats partiels d'une requête exécutée selon le procédé de gestion de la figure 2 ; On a représenté sur la figure 1 un système comportant un terminal utilisateur 10, un gestionnaire de traitement 12 et des calculateurs 14^ ..., 14n. On entend ici par « gestionnaire de traitement 12 » un serveur de gestion de traitement. Mais on pourrait aussi désigner par cette expression un logiciel installé sur un tel serveur. Le terminal utilisateur 10 est par exemple un micro-ordinateur de type classique adapté pour émettre des requêtes d'exécution de programmes vers le gestionnaire de traitement 12. Le gestionnaire de traitement 12 est lui aussi un micro-ordinateur de type classique, comportant des moyens de stockage, tels qu'une mémoire 15, pour le stockage au moins temporaire d'une liste d'attente 17 de requêtes en provenance d'un ou plusieurs terminaux utilisateurs tels que le terminal 10, et pour le stockage de résultats 50 au moins partiels provenant de l'exécution de requêtes issues de la liste 17. Chaque calculateur 14j est relié au gestionnaire de traitement 12 et est muni d'au moins un processeur. Ainsi, comme on le voit sur la figure 1 , le calculateur 14^ comporte un seul processeur 16^ le calculateur 142 comporte quatre processeurs 162, 163, 164, 16 et le calculateur 14n comporte deux processeurs 16m., et 16m. Les calculateurs ne sont donc pas tous identiques : certains sont monoprocesseurs, tandis que d'autres sont biprocesseurs ou multiprocesseurs. Comme on le voit sur la figure 2, lors d'une première étape de saisie 18, un utilisateur rentre sur le terminal utilisateur 10 une requête Rι(P, D) d'exécution d'un programme P associé à une liste D de données d'entrée. Cette requête R^P, D) est ensuite envoyée au gestionnaire de traitement 12 et l'on passe à une étape 22 de classement cette requête Ri dans la liste d'attente 17 de requêtes. La liste d'attente 17 comporte par exemple d'autres requêtes déjà reçues par le gestionnaire de traitement 12, soit du même terminal utilisateur 10, soit d'un autre terminal utilisateur quelconque. Ces requêtes peuvent être par exemple des requêtes d'exécution du même programme P associé à une autre liste de données, ou bien des requêtes d'exécution d'autres programmes associés à d'autres données d'entrée. Pour le bon fonctionnement du procédé selon l'invention, il est important de noter que les données d'entrée figurant dans la liste D de données d'entrée sont décorrélées. La décorrélation de ces données d'entrée signifie qu'il est possible d'effectuer des exécutions du programme P sur chacune d'entre elles de façon séparée. La liste D de données d'entrée peut comporter plusieurs centaines de milliers de données d'entrée, celles-ci étant simples ou multivaluées. La décorrélation de ces données d'entrée est une condition sine qua non de la distribution de l'exécution du programme P sur plusieurs calculateurs 14,. Lors de l'étape 22 de classement, on classe les requêtes de la liste d'attente 17 par ordre de priorité d'exécution. La priorité des requêtes de la liste d'attente 17 peut être définie de différentes façons, telles que par un système de définition a priori des priorités qui consisterait à rentrer un numéro de priorité lors de l'étape 18 de saisie de chaque requête, ou encore, telles que par un principe de traitement du type FIFO consistant à traiter les requêtes par ordre d'arrivée. Après l'étape 22 de classement de la liste d'attente 17, on passe à une étape 24 d'élection d'une requête prioritaire, correspondant à la première requête de la liste d'attente 17. Pour simplifier les notations dans la suite de la description, on suppose que la requête prioritaire est la requête précédemment reçue par le gestionnaire de traitement 12 lors de l'étape 18, c'est-à-dire la requête R^P, D). La requête prioritaire aurait bien sûr pu être l'une des autres requêtes contenues dans la liste 17. Une fois que l'on connaît la requête prioritaire à exécuter, on passe à une étape 26 d'élection d'un calculateur parmi tous les calculateurs 14„ pour traiter au moins une partie de cette requête prioritaire. Le calculateur élu 14e correspond au calculateur le plus disponible parmi tous les calculateurs 14,. Pour choisir le calculateur élu 14e lors de l'étape 26, le gestionnaire de traitement 12 calcule pour chacun des calculateurs 14, la valeur np/NP, où np, représente le nombre de processus en cours d'exécution sur le calculateur 14, et NP, le nombre de processus exécutables simultanément sur ce calculateur 14,. Un processus correspond à l'exécution d'un programme par un calculateur sur des données d'entrées associée à ce programme. Le calculateur élu 14Θ est le calculateur 14, pour lequel la valeur np/NP, est la plus petite. Selon un autre mode de réalisation, il est possible de choisir le calculateur le plus disponible selon d'autres critères tels que l'estimation d'un coefficient de charge, calculé dynamiquement sur chaque calculateur en tenant compte des ressources de chaque calculateur telles que le nombre de processus actifs sur le calculateur en cours d'exécution au moment du test ou la mémoire vive utilisée. Dans ce cas, l'étape 26 d'élection du calculateur consiste à toujours choisir le calculateur le moins chargé. Une fois que le calculateur élu 14e est déterminé, on passe à des étapes destinées à déterminer la façon de distribuer l'exécution de la requête prioritaire Rι(P, D). Ainsi, lors d'une étape 27, on compare les deux paramètres suivants : NEm,n, représentant le nombre minimal de données d'entrées devant être traitées sur tout calculateur 14, lors de l'exécution d'un programme, ce paramètre permettant de ne pas distribuer la requête prioritaire sur plus d'un calculateur si celle-ci est jugée petite a priori (c'est à dire acceptable en totalité par le calculateur le plus petit) ; NER correspondant au nombre total de données d'entrée que la requête prioritaire Rι(P, D) doit traiter, c'est à dire au nombre de données d'entrées figurant dans la liste D. Si NER < NEmιn, c'est-à-dire si la requête prioritaire R,(P, D) doit traiter un nombre de données d'entrée plus faible que le nombre minimal de données d'entrées devant être traitées sur tout calculateur 14„ cela signifie que le calculateur élu 14e peut traiter l'intégralité des données d'entrée de la requête prioritaire R^P, D). On passe alors à une étape 28 d'exécution de la requête Rι(P, D) par le calculateur 14Θ et le procédé est simultanément reporté à l'étape 24 d'élection d'une autre requête prioritaire à traiter.
L'étape 28 d'exécution de la requête prioritaire R^P, D) est suivie éventuellement d'une étape 29 de traitement de résultats, comportant par exemple le stockage, le formatage et l'affichage des résultats sur l'interface du terminal utilisateur 10. Si NER > NEmιn, on passe alors à une étape 30 de calcul du nombre NEe maximal de données d'entrée que le calculateur élu 14e est a priori capable de traiter. Pour estimer NEe, le gestionnaire de traitement 12 prend en compte différents paramètres : n Yl NPl représentant la somme, sur tous les calculateurs 14„ du nombre de processus, issus du gestionnaire de traitement 12, exécutables simultanément sur chaque calculateur 14, ; NPe correspondant au nombre de processus, issus du gestionnaire de traitement, exécutables simultanément sur le calculateur élu 14e , et dont la valeur peut être modifiée par l'utilisateur et/ou de façon dynamique ; et CE représentant un coefficient d'étalement défini par le gestionnaire de traitement 12 et dont la valeur peut être modifiée par l'utilisateur, et/ou de façon dynamique, ce coefficient d'étalement permettant, pour l'ensemble des calculateurs, de regrouper en un nombre plus au moins grand de sous- requêtes l'exécution de la requête prioritaire Rι(P, D). Le coefficient d'étalement CE est tel que :
∑NP, O ≤ CE ≤ '=' min(NR, ) A partir de ces paramètres, le gestionnaire estime ΝΕe grâce à la formule : NR NE, = E(NER . e— .CE + 1) ∑ NP, ;=l Où Ε() représente la fonction « Partie Entière ». On passe ensuite à une étape de test 31 consistant à comparer le nombre ΝEe calculé lors de l'étape 30 au nombre total NER de données d'entrée que la requête prioritaire R^P, D) doit traiter. Cette étape permet de déterminer si le calculateur élu 14e est apte à exécuter la requête prioritaire R^P, D) dans sa totalité. Si NER < NEe, c'est-à-dire si les ressources disponibles du calculateur élu 14e sont suffisantes pour exécuter la requête prioritaire R^P, D) dans sa totalité, on passe alors à l'étape 28 d'exécution complète de cette requête prioritaire et le procédé est simultanément reporté à l'étape 24 d'élection d'une autre requête prioritaire à traiter. Si NER > NEe, c'est-à-dire si le calculateur élu 14θ n'a pas les ressources suffisantes pour exécuter la requête prioritaire R^P, D) dans sa totalité, on passe alors à deux étapes 32 et 34 de génération de sous-requêtes à partir de la requête prioritaire R^P, D). En effet, la liste D des données d'entrée associée à la requête prioritaire R^P, D) ne comportant que des données d'entrée décorrélées, il est possible de diviser la requête en plusieurs sous-requêtes portant sur un sous-ensemble de l'ensemble de données d'entrée D. L'étape 32 consiste à générer une première sous-requête Rsι(P, D^ que l'un des processeurs du calculateur élu 14e est capable de traiter. Cette première sous-requête Rsι(P, D,) est telle que la liste D, comporte NEe données d'entrée, NEe ayant été estimé au cours de l'étape 30. L'étape 34 consiste à générer une seconde sous-requête Rs2(P, D2), destinée à être exécutée avec les données d'entrée qui ne sont pas comprises dans la liste D de données d'entrées sur laquelle sera exécutée la sous-requête Rsι(P, D^. D2 est le complément de D^ dans D et comporte NER-NEe données d'entrée. Après l'étape 34, la seconde sous-requête RS2(P, D2) générée est envoyée dans la liste d'attente 17 des requêtes. Le procédé est alors reporté à l'étape de classement 22 des requêtes de la liste d'attente 17. Après l'étape 32, la première sous-requête Rsι(P, D,) générée est envoyée au calculateur élu 14β qui l'exécute lors d'une étape d'exécution 40 et le procédé est en même temps reporté à l'étape 24 d'élection d'une autre requête prioritaire à traiter. Ensuite, lors d'une étape 42, le calculateur 14e envoie les résultats issus de l'étape 40 au gestionnaire de traitement 12. Cette étape 42 d'envoi des résultats est suivie par une étape 44 de stockage par le gestionnaire de traitement 12 des résultats de l'exécution de la première sous-requête Rs1(P, Di) dans la mémoire 15. Comme on le voit sur la figure 3, l'exécution d'une requête telle que la requête R^P, D) saisie lors de l'étape 18, peut aboutir, après l'application d'un procédé tel que celui décrit sur la figure 2, à plusieurs étapes 44, 46^ 462 46q de stockage de résultats intermédiaires. Les résultats stockés au cours des étapes 44, 46!, 462, ..., 46q sont les résultats de l'exécution de toutes les sous-requêtes générées à partir de la requête Rι(P, D) afin de distribuer l'exécution de cette requête R^P, D) sur plusieurs calculateurs 14j. Après les étapes 44, 46!, 462 46q de stockage des résultats par le gestionnaire de distribution 12, on passe à une étape 48 de combinaison de tous ces résultats en un résultat final 50 de la requête Rι(P, D). Le résultat final 50 de la requête R^P, D) est ensuite envoyé au terminal utilisateur
10 qui traite ces résultats 50 sur son interface lors d'une étape 52 de traitement de résultats comportant notamment le formatage et l'affichage des résultats. Selon un autre mode de réalisation de l'invention, le système de gestion peut exécuter plusieurs programmes Pi, P , ..., Pz transmis sous forme de requêtes par plusieurs terminaux utilisateurs. De façon optionnelle, il est possible de doter le système d'une fonction d'information de l'avancement de l'exécution des requêtes. Un système de messagerie peut rendre compte à chaque client utilisateur, dans le cas où le système comporte plusieurs terminaux utilisateurs 10, de l'état d'avancement de ses requêtes ou de manière globale, de l'état d'avancement de toutes les requêtes à un client administrateur. Enfin, il est possible d'associer d'autres fonctions classiques à ce système de gestion telles qu'un démarrage de l'exécution des requêtes en différé, une gestion de pannes, des mécanismes de synchronisation de requêtes, ou encore une fonction d'arrêt automatique permettant d'arrêter une requête quel que soit son statut, en cours d'exécution ou en file d'attente. Il apparaît clairement qu'un procédé selon l'invention permet de distribuer l'exécution du programme P sur plusieurs calculateurs 14„ les étapes 26, 27, 30 et 31 de calcul du mode de distribution permettant de distribuer ces exécutions de façon optimale afin de réduire le temps global d'exécution.

Claims

REVENDICATIONS
1. Procédé de gestion de l'exécution d'au moins un programme (P) associé à une liste de données d'entrée (D) nécessaires à l'exécution de ce programme (P), le programme étant adapté pour une exécution distribuée par un gestionnaire de traitement (12) sur plusieurs calculateurs (14,) grâce à la distribution de ses données d'entrée, comportant une étape (18) de réception d'une requête (Rι(P, D)) d'exécution du programme (P), caractérisé en ce qu'il comporte en outre les étapes suivantes : On sélectionne (26) un calculateur (14e) parmi une pluralité de calculateurs (14,) selon un critère de disponibilité, a priori, à exécuter cette requête (Rι(P, D)) ; - On teste (31 ) si le calculateur sélectionné (14e) a les ressources suffisantes pour exécuter la totalité de la requête (Rι(P, D)) ; - Si non, on sélectionne (30) une partie (D^ des données d'entrée sur laquelle on estime que le calculateur sélectionné (14e) a les ressources suffisantes pour exécuter le programme (P), et l'on génère (32, 34) à partir de la requête (Rι(P, D)), une première sous- requête (Rsι(P, D^) d'exécution du programme (P) sur cette partie (DÏ) sélectionnée des données d'entrée et au moins une seconde sous-requête (RS2(P, D2)) d'exécution du programme (P) sur le reste (D2) des données d'entrée.
2. Procédé de gestion de l'exécution d'au moins un programme (P) selon la revendication 1 , caractérisé en ce que l'on exécute la première sous-requête (Rsι(P, D^) sur le calculateur sélectionné (14e).
3. Procédé de gestion de l'exécution d'au moins un programme (P) selon la revendication 1 ou 2, caractérisé en ce que le critère de disponibilité d'un calculateur (14,) à exécuter une requête (Rι(P, D)) est directement lié à la comparaison du nombre (np,) de processus, issus du gestionnaire de traitement (12), en cours d'exécution sur ce calculateur (14,) au nombre (NP,) de processus, issus du gestionnaire de traitement (12), exécutables simultanément sur ce calculateur (14,).
4. Procédé de gestion de l'exécution d'au moins un programme (P) selon la revendication 3, caractérisé en ce que le critère de disponibilité d'un calculateur (14,) à exécuter une requête (Rι(P, D)) est le rapport du nombre (np,) de processus, issus du gestionnaire de traitement (12), en cours d'exécution sur ce calculateur (14,) sur le nombre (NP,) de processus, issus du gestionnaire de traitement (12), exécutables simultanément sur ce calculateur (14,), et en ce que le calculateur sélectionné (14θ) est celui pour lequel ce rapport est le plus faible.
5. Procédé de gestion de l'exécution d'au moins un programme (P) selon la revendication 3 ou 4, caractérisé en ce que le critère de disponibilité d'un calculateur (14,) à exécuter une requête (Rι(P, D)) est pondéré par l'estimation d'un coefficient de charge dépendant des ressources du calculateur (14,), notamment le nombre de processus en cours d'exécution sur le calculateur au moment du test ou la mémoire vive utilisée.
6. Procédé de gestion de l'exécution d'au moins un programme (P) selon l'une quelconque des revendications 1 à 5, caractérisé en ce que, lors de l'étape de test (26) du calculateur sélectionné (14e), on compare le nombre (NER) de données d'entrée de la requête (Rι(P, D)) à un nombre (NEe) maximal estimé de données d'entrées que le calculateur sélectionné (14e) est a priori capable de traiter.
7. Procédé de gestion de l'exécution d'au moins un programme (P) selon la revendication 6, caractérisé en ce que le nombre (NEΘ) maximal de données d'entrées que le calculateur (14e) sélectionné est a priori capable de traiter est estimé à partir des paramètres suivants : le nombre (NER) de données d'entrée de la requête (Rι(P, D)) ; n la somme NPt ) sur tous les calculateurs (14i) du nombre (NPi) de processus, issus du gestionnaire de traitement (12), exécutables simultanément sur chaque calculateur (14i) ; un nombre (NPe) de processus, issus du gestionnaire de traitement (12), exécutables simultanément sur le calculateur sélectionné (14e) ; et un coefficient d'étalement (CE) défini par le gestionnaire de traitement (12) et permettant de diviser en un nombre plus ou moins grand de sous-requêtes l'exécution de la requête (Rι(P, D)).
8. Procédé de gestion de l'exécution d'au moins un programme (P) selon la revendication 7, caractérisé en ce que le nombre (NEe) maximal de données d'entrées que le calculateur (14e) sélectionné est a priori capable de traiter est estimé à partir de la formule suivante : NR NEe = E(NER. —.CE + 1) , où E() représente la fonction Partie Entière. ∑NP,
9. Procédé de gestion de l'exécution d'au moins un programme (P) selon la revendication 8, caractérisé en ce que les valeurs du coefficient d'étalement (CE) et du nombre (ΝPe) de processus, issus du gestionnaire de traitement (12), exécutables simultanément sur un calculateur (14,) sont modifiables par l'utilisateur, et/ou de façon dynamique.
10. Procédé de gestion de l'exécution d'au moins un programme (P) selon l'une quelconque des revendications 6 à 9, caractérisé en ce que la partie (D,) des données d'entrée sur laquelle est générée la première sous-requête (Rsι(P, D^) correspond au nombre (NEe) maximal de données d'entrées que le calculateur sélectionné (14β) est a priori capable de traiter.
11. Procédé de gestion de l'exécution d'au moins un programme (P) selon l'une quelconque des revendications 1 à 10, caractérisé en ce que l'on sélectionne (24) la requête (Rι(P, D)) parmi une liste de requêtes (17) classées (22) par ordre de priorité.
12. Procédé de gestion de l'exécution d'au moins un programme (P) selon la revendication 11 , caractérisé en ce que l'on renvoie dans la liste des requêtes (17) la seconde sous-requête (Rs2(P, D2)).
13. Procédé de gestion de l'exécution d'au moins un programme (P) selon la revendication 1 1 ou 12, caractérisé en ce que l'on affecte à chaque requête de la liste un coefficient de priorité, et en ce que les requêtes de coefficients de priorité égaux sont classées (22) par ordre d'arrivée dans la liste (17).
PCT/FR2004/001911 2003-07-21 2004-07-19 Procédé de gestion de l'exécution d'au moins un programme sur plusieurs calculateurs Ceased WO2005010633A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0308876A FR2858074A1 (fr) 2003-07-21 2003-07-21 Procede de gestion de l'execution d'au moins un programme sur plusieurs calculateurs
FR03/08876 2003-07-21

Publications (2)

Publication Number Publication Date
WO2005010633A2 true WO2005010633A2 (fr) 2005-02-03
WO2005010633A3 WO2005010633A3 (fr) 2005-06-30

Family

ID=33560968

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2004/001911 Ceased WO2005010633A2 (fr) 2003-07-21 2004-07-19 Procédé de gestion de l'exécution d'au moins un programme sur plusieurs calculateurs

Country Status (2)

Country Link
FR (1) FR2858074A1 (fr)
WO (1) WO2005010633A2 (fr)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5349682A (en) * 1992-01-31 1994-09-20 Parallel Pcs, Inc. Dynamic fault-tolerant parallel processing system for performing an application function with increased efficiency using heterogeneous processors
US5748892A (en) * 1996-03-25 1998-05-05 Citrix Systems, Inc. Method and apparatus for client managed flow control on a limited memory computer system
EP0969367A3 (fr) * 1998-05-28 2001-07-11 Compaq Computer Corporation Système et méthode utilisé(e)s dans un système d'ordinateur pour distribuer des tâches entre des sous-systèmes entrée-sortie multitraitement
US6859834B1 (en) * 1999-08-13 2005-02-22 Sun Microsystems, Inc. System and method for enabling application server request failover

Also Published As

Publication number Publication date
WO2005010633A3 (fr) 2005-06-30
FR2858074A1 (fr) 2005-01-28

Similar Documents

Publication Publication Date Title
EP1043658A1 (fr) Procédé d&#39;amélioration des performances d&#39;un système multiprocesseur comprenant une file d&#39;attente de travaux et architecture de système pour la mise en oeuvre du procédé
EP1805611B1 (fr) Procede d&#39;ordonnancement de traitement de tâches et dispositif pour mettre en oeuvre le procede
US10726027B2 (en) Cognitive elasticity of cloud applications
EP3286647A1 (fr) Placement d&#39;une tâche de calcul sur un processeur fonctionnellement asymetrique
EP2480969A1 (fr) Systeme et procede de gestion de l&#39;execution entrelacee de fils d&#39;instructions
US8898126B1 (en) Method and apparatus for providing concurrent data insertion and updating
US8612597B2 (en) Computing scheduling using resource lend and borrow
FR2871256A1 (fr) Commande de flot de dispositif de stockage
FR2769105A1 (fr) Dispositif et procede de prise en compte de l&#39;execution d&#39;une tache sur un systeme informatique
WO2005010633A2 (fr) Procédé de gestion de l&#39;exécution d&#39;au moins un programme sur plusieurs calculateurs
FR3078462A1 (fr) Procede et dispositif de controle d&#39;un acces a une ressource d&#39;un systeme informatique par des applications logicielles
US12339863B2 (en) Method for scheduling offloading snippets based on large amount of DBMS task computation
EP2545449A1 (fr) Procédé de configuration d&#39;un système informatique, programme d&#39;ordinateur et système informatique correspondants
EP3850486A1 (fr) Procédé et circuit de multiplexage temporel d&#39;accès concurrents à une ressource informatique
WO2023173193A1 (fr) Système et procédé d&#39;optimisation d&#39;un outil de simulation
WO2011058260A1 (fr) Procede et dispositif d&#39;optimisation d&#39;execution d&#39;applications logicielles dans une architecture multiprocesseur comprenant plusieurs controleurs d&#39;entree/sortie et unites de calcul secondaires
BE1029586B1 (fr) Adaptation a une defaillance potentielle pour gestion de projet
US12619487B2 (en) Classifier validation
FR3106224A1 (fr) Programmation optimale de requêtes pour l’optimisation de l’utilisation de ressources
EP4213024A1 (fr) Procédé de partage d&#39;image, programme d&#39;ordinateur et système mettant en oeuvre un tel procédé
US20230053928A1 (en) Classifier validation
FR2980007A1 (fr) Procede, dispositif et programme d&#39;ordinateur pour allouer dynamiquement des ressources d&#39;un cluster a l&#39;execution de processus d&#39;une application
FR3151924A1 (fr) Plateforme pour l’exécution d’applications avioniques, procédé et programme d’ordinateur associés
FR3007547A1 (fr) Procede de transfert de donnees dans un environnement dynamique
FR3105473A3 (fr) Dispositif et procede de calcul de disponibilite

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase