Method and apparatus for detecting anomalous behavior in a series of software application executions

Description

FIELD OF THE INVENTION

[0001] The present invention relates to the profiling of software applications executed on an information processing device, in particular in order to detect aberrant behaviors among the executions.

[0002] It applies in particular to the field of high-performance computing on supercomputers. CONTEXT OF THE INVENTION

[0003] Some software applications involve extremely large amounts of processing, due to the volume of data to be processed and / or the complexity of the processing to be performed on this data.

[0004] Examples include weather forecasting applications, digital image processing applications, for example medical imaging, physical simulation applications (material strength calculations, aerodynamic calculations, etc.), neural network learning, chemical object modeling applications (structure and property calculations, molecular modeling, etc.), financial or insurance simulation applications, cryptanalysis applications, etc.

[0005] In some cases, applications also obey real-time or near-real-time constraints.

[0006] One challenge is therefore to reduce and control the computing times for these applications. To do this, they can be executed on powerful information processing devices, such as supercomputers. Users can therefore choose to run their application on a processing device, generally remote, via a telecommunications network.

[0007] A supercomputer or supercomputer is a computer designed to achieve the highest possible performance with the techniques known at the time of its design, particularly with regard to computing speed. The science of supercomputers is called "high performance computing" (in English: " high-performance computing » or HPC).

[0008] However, information processing devices, and in particular supercomputers, are complex systems, and the interactions between software applications and these are further complicated by the multiple configuration parameters of the applications and the processing device, as well as by the competition between the different applications executed simultaneously on the same processing device.

[0009] Also, users often experience lower efficiency of their applications than they expected.

[0010] Application execution analysis tools have been proposed to help understand potential problems, including bottlenecks that affect the execution time of all or part of the applications.

[0011] Profiling tools allow you to collect measurements of certain parameters while an application is running.

[0012] For example, code profiling allows you to obtain measurements, during the execution of an application, including the list of functions called and the time spent in each of them, the use of the processor(s), the use of memory, etc. Code profiling can typically be implemented by instrumenting the source code by adding instructions to it.

[0013] Input / output profiling tools have also been proposed, such as the "Bull IO Instrumentation" tool. This tool is part of a suite of other tools that, downstream, allow the analysis of the measurements collected by the profiling tool.

[0014] However, these tools mainly target the profiling of application executions.

[0015] However, according to the inventors, it would also be interesting to profile the applications themselves, in order to deduce conclusions about their behavior and thus make it possible to refine execution parameters for the application. Prior art US 2006 / 020924 A1 (LO KEVIN H [US] ET AL) January 26, 2006 describes a system for monitoring and comparing series of performance measurements (footprints) of an application to a reference trace (baseline), in order to detect possible abnormal behavior. SUMMARY OF THE INVENTION

[0016] An objective of the present invention is to provide a solution that at least partially overcomes this shortcoming of the state of the art. In particular, the invention aims to detect aberrant behavior among the different executions of the same application.

[0017] The invention is defined by the attached independent claims. the executions for which an aberration has been detected

[0018] Other characteristics and advantages of the invention will appear on reading the following description of a preferred embodiment of the invention, given by way of example and with reference to the appended drawings. BRIEF DESCRIPTION OF THE FIGURES

[0019] The accompanying drawings illustrate the invention: There figure 1 schematically represents an example of an organizational chart according to an embodiment of the invention. The figure 2 illustrates examples of activities of 3 executions of the same application, according to an embodiment of the invention DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[0020] There figure 1 illustrates a flowchart according to one embodiment of the invention. This flowchart is illustrative and aims above all to better explain the invention.

[0021] In a step S1, application executions are triggered in collaboration with a profiling tool. One or more distinct applications may be subject to one or more executions each.

[0022] We can call " job ", these executions of an application. In computing, the English term "job" (which is difficult to translate into French without misinterpretation) can be considered as a unit of work or execution of this work. A job therefore combines the identification of an application and the identification of the contextual elements of its application: the underlying hardware context (execution resources: supercomputer nodes, etc.) and the data to be processed.

[0023] Different profiling tools can be used to collect, for each execution of an application, at least one time series of measurement points.

[0024] An example of a tool is the "Bull IO Instrumentation" input / output profiler. This tool is described on the Atos website: http: / / www.atos.net

[0025] Bull IO Instrumentation is an intuitive profiling tool that helps system administrators, developers, and product support experts analyze I / O activity generated by HPC tasks. Role-based access control is included to provide different levels of information to various predefined user groups: system administrators, operators, or regular users. This tool collects, stores, and displays a set of I / O-related metrics through a very user-friendly graphical interface.

[0026] Other profiling tools can also be used. The invention is in fact independent of the profiling tool used, as long as it can generate time series of parameter values representative of the behavior of application executions.

[0027] For example, we can cite the BEO tool, “ Bull Energy Optimizer ", or the BDPO tool, " Bull Dynamic Power Optimization ", which specialize in profiling the energy consumption of all components of the information processing platform (CPU, file system, etc.) in order to enable its optimization.

[0028] There are other proprietary tools as well, such as LLView, offered by the Julich Supercomputer Center, and open source tools such as Prometheus.

[0029] Each measurement point associates a value with the parameter, or metric, being measured.

[0030] The measurement points are typically spaced at an interval that can be constant and pre-set. The value of the measurement point is then representative of this time interval. This time interval can be sized according to a compromise that allows both to closely monitor the evolution of the measured parameter over time but also to avoid overloading the system by collecting too many measurements. A typical example of a time interval is 5 seconds

[0031] Many types of parameters can be monitored and measured in this way.

[0032] These settings can affect different aspects of the behavior of executions, or jobs.

[0033] In particular, these parameters may concern the inputs and outputs of application executions. Indeed, it is noted that HPC applications (" High Performance Computing") spend a significant portion of their execution time performing input / output. The volumes of data being processed are in themselves a significant cause of application execution performance issues: the networks used to exchange data have a finite bandwidth, so read and write times cannot be lower than a theoretical minimum. Other factors can also have a significant impact. For example, the concurrent execution of two applications or the same application can lead to access conflicts to common storage resources, which impacts performance. The way a given application performs its input / output can also significantly impact performance in the case where it saturates storage equipment by requesting the processing of a very large number of small operations.

[0034] Measuring parameters representative of the inputs / outputs of application executions therefore provides a good indicator of application performance.

[0035] Here again, different input / output parameters can be used, and the invention is independent of the type of parameters. These essentially depend on the profiling tool and the type of applications and information processing device. As non-limiting examples, mention may be made of the read input / output volume, the write input / output volume, the read input / output time, the write input / output time, etc.

[0036] For a given measured parameter, the succession of values captured over time forms a time series.

[0037] In general, several measurements are carried out simultaneously, on as many parameters.

[0038] As stated in the Wikipedia page, "a time series, or chronological series, is a sequence of numerical values representing the evolution of a specific quantity over time" (source: https: / / fr.wikipedia.org / wiki / Sérietemporel)

[0039] When multiple application executions occur at the same time, a set of time series can be collected, each associated with a given application execution.

[0040] One challenge is to determine, from these time series, the behavior of these applications in order, in particular, to better understand the underlying problems and improve the conditions of their subsequent executions to optimize performance.

[0041] However, in practice it turns out that each execution of the same application can be the subject of a separate execution context.

[0042] Indeed, at least two situations can arise which influence its own behavior, and therefore the respective time series.

[0043] First, depending on the times at which the execution of an application is triggered, the available resources of the information processing device may be distinct. For example, in the case where the information processing device is a supercomputer shared between several clients, it is more or less loaded depending on the clients' requests.

[0044] Therefore, a first execution of an application can be triggered on a first set of resources (for example 10 nodes of the supercomputer), while a second execution of the same application can be triggered on a second set of resources (for example 2 nodes of the supercomputer).

[0045] On the other hand, two executions of the same application can be triggered on a different volume of data. For example, an application taking digital images as input can be executed with images of very different resolutions. Therefore, the time series relating to the input / output parameter measurements will have substantially different values.

[0046] For at least these reasons, the proposals of the state of the art do not allow to determine, from the time series of each execution, a nominal behavior for the application, which would be invariant (or little varying) with respect to the contexts of each execution.

[0047] It follows that these state-of-the-art proposals cannot allow either the detection of aberrant behavior of a particular execution, or the triggering of actions on the basis of such nominal behavior.

[0048] There figure 2illustrates this situation and allows us to better understand the influence of the execution context.

[0049] Each of the three curves represents a time series relating to the same input / output parameter for 3 distinct executions of the same application.

[0050] In this example, the three curves show the same general behavior: a first phase during which the measured parameter has a low value (the application is busy performing internet processing and little or no input / output). a second phase, during which the measured parameter has a high value (the application is performing input / output) a third phase during which the measured parameter has a low value (the application is busy performing internet processing and little or no input / output.

[0051] Curve (a) represents a reference execution: the application performs internal processing for 20 minutes, then I / O for 20 minutes with a volume of 10 GB, then internal processing again for 20 minutes.

[0052] Curve (b) represents execution on doubled resources (twice as many supercomputer nodes): the application performs 10 minutes of internal processing, then 10 minutes of input / output with a volume of 10 GB, then another 10 minutes of internal processing.

[0053] Curve (c) represents an execution on resources identical to those of curve (a) but with double data: the application performs internal processing for 20 minutes, then inputs / outputs for 20 minutes with a volume of 20 GB, then internal processing again for 20 minutes.

[0054] State-of-the-art methods for comparing runs based on time series of measured run parameters involve calculating distances between those time series.

[0055] However, measuring the distance between any pair of time series (a), (b), (c) does not yield a zero value, nor even a constant value. Therefore, measuring such a distance does not easily allow us to determine possible aberrant behavior between different executions of the same application.

[0056] For example, the DTW algorithm for “ Dynamic Time Warping» (dynamic time warping) is an algorithm for measuring the similarity between two sequences that may vary over time. It has been used in video, audio, computer graphics, bioinformatics, etc., and can be applied in any situation where the data can be transformed into a linear representation. A famous application is in automatic speech recognition, where it is necessary to take into account highly variable speaking rates.

[0057] Generally speaking, DTW is a method that searches for an optimal matching between two time series, under certain restrictions. The time series are deformed by nonlinear transformation of the time variable, to determine a measure of their similarity, independent of certain nonlinear transformations of time.

[0058] This algorithm can be used to calculate a distance between two time series that takes into account a time scale or a phase shift.

[0059] However, the DTW algorithm is very sensitive to differences in values between time series. Thus, in the example of the figure 2 , the values are very different between curves (a) and (b), as well as between curves (a) and (c), so the respective distances between (a) and (b) and between (a) and (c), according to the DTW algorithm, will be large.

[0060] In other words, the DTW algorithm does not allow minimizing a distance between time series belonging to executions of the same application. It therefore appears that the DTW algorithm would not allow determining an aberrant behavior of an execution, and would therefore not allow determining a coherent set of executions to determine a nominal, or invariant, behavior specific to the application itself.

[0061] Furthermore, the DTW algorithm is a complex algorithm that requires the construction of an N1xN2 matrix, where N1 and N2 are the numbers of measurement points in the two time series whose distance is calculated. Also, calculating a distance according to the DTW algorithm generates a computational complexity of o(N 2< ), as well as a memory footprint also of o(N 2< ).

[0062] One aspect of the invention consists of determining a way of calculating the distance between two time series which is truly representative of the behavior of the application over time and not very sensitive to fluctuations in values or duration caused by the availability of computing resources or by the volume of data to be processed.

[0063] To do this, a step S2 is proposed for formatting the time series obtained for the set of executions, by adjusting, for each time series, its length, its values and its number of measurement points. This adjustment consists of modifying the length and / or the values and / or the number of points of one or more time series in order to make them match the length and / or the values and / or the number of points of a given time series (called "reference").

[0064] According to a preferred embodiment, the formatting is carried out by pairs of time series within this set.

[0065] Alternatively, it is possible to perform all executions at once. However, this approach is less efficient because it is more expensive in terms of execution time.

[0066] A first adjustment concerns the length of the time series.

[0067] Indeed, each time series can have a variable number of measurement points: this variability can be inherent to the type of parameter measured, but also to the settings of the profiling tool. It may be possible, for example, to indicate different intervals between measurement points depending on the parameters measured.

[0068] Since time series can therefore have variable lengths, in order to be able to compare them better, they can be normalized on a reference interval. This reference interval can be the interval of one of the time series (the shortest, for example), or a "neutral" interval, for example [0; 1].

[0069] Any time series of length n ('n' being the number of measurement points) can thus be fitted by projecting each measurement point of this series towards a reference interval.

[0070] If we take the example of a reference interval [0;1] and if we assume that the measurement points are equidistant in time (i.e. obey a periodic measurement of a parameter), we can write that the adjusted time series is the set: t j j = 1 n , avec t j = j − 1 n − 1 with n, the number of measurement points, and tj the measurement point j, with j ∈ [1; n ] and j an integer.

[0071] A second adjustment concerns the values of the time series.

[0072] This adjustment can be seen as a normalization of the time series values.

[0073] There are several ways to do this. For example, it is possible to normalize the values by projecting them onto a reference interval, assigning the high and low values of this interval to the maximum and minimum values, respectively, of the time series being compared.

[0074] According to one embodiment, the values of each time series are normalized by a total quantity corresponding to all the values for this time series. According to one embodiment, this quantity is an approximation of the integral of the time series with respect to time.

[0075] This quantity can be calculated as the sum of all these values. This quantity thus calculated forms an approximation of the integral of the time series (that is, graphically, the area under the curve providing the values for each measurement point).

[0076] If the time series to be compared do not share the same sampling rate (period between two measurement points), more precise methods can be used to estimate the integral of the time series. Examples include the Simson method or the trapezoidal method. Many other methods exist for approximating an integral. The Wikipedia page on the numerical calculation of an integral lists several of them: https: / / fr.wikipedia.org / wiki / Numerical calculation of an integral

[0077] In the case of a multi-valued time series, i.e. associating several values with the same measurement point, each value must be taken separately to be normalized with the associated integral quantity.

[0078] A third adjustment concerns the number of points in the time series.

[0079] Even though time series have been adjusted in length, they may still have a different number of measurement points. In order to compare two time series, and to calculate a metric between them, such as a distance, the number of points is adjusted.

[0080] To do this, we interpolate a set of additional measurement points so that the number of measurement points in the time series is equal to the number of measurement points in a longer time series of all executions of the application in question.

[0081] In other words, if we consider two time series, the shorter time series is interpolated in order to obtain a number of measurement points equal to that of the longer time series, by adding additional "artificial" measurement points (i.e. calculated and not measured).

[0082] These additional measurement points must not add information or change the semantic content of the time series. Also, these additional measurement points must be located on the curve of the time series.

[0083] According to one embodiment, the measurement points of the time series to be adjusted are replaced by these additional measurement points which have as abscissas those of the longest time series. In this way, the abscissas of all the time series are identical.

[0084] Different interpolation techniques exist and can be used for this adjustment step.

[0085] In particular, the value to be assigned to an interpolated measurement point can be determined by a function that can locally approximate the curve of the time series.

[0086] For example, if the curve has sinusoidal behavior, one can use a spline or polynomial approximation to locally approximate the curve and determine the value of the additional point.

[0087] If the values vary little over an interval around the additional point, linear interpolation may be sufficient to determine the value of that additional point.

[0088] After this S2 formatting step, we can measure a similarity between two time series independently of the linear transformations on the x (time) and y (values) scales of each of them.

[0089] In other words, the time series thus normalized are no longer sensitive to the influence of different data volumes for different executions of the same application, or of different computing resources.

[0090] In a step S3, a metric is calculated between two time series among the time series collected for the set of executions. This metric aims to quantify a dissimilarity between time series and can notably take the form of a distance between time series.

[0091] Due to the adjustments made previously, the metric is normally minimal for executions corresponding to the same application.

[0092] Therefore, this metric calculation can make it possible, in a step S4, to detect an aberration within the execution set.

[0093] Indeed, if a time series of an execution has a metric (or distance, for example) that is too important with the time series of other executions of the same application, then we can estimate that this execution has aberrant behavior.

[0094] As a reminder, in statistics, an aberrant data (in English " outlier ") is a value or observation that is "distant" from other observations made on the same phenomenon, that is, it contrasts greatly with the "normally" measured values.

[0095] This aberration may correspond to a malfunction of the application during this execution, or a malfunction of the execution context or the profiling tool. In any case, the time series corresponding to this execution must be considered as not representative of the application.

[0096] Also, the detection of an aberration allows at least two actions: alert the user about this aberration exclude the corresponding execution in determining a nominal behavior for the application.

[0097] Different distances may be used, in step S4, to enable the detection of an aberrant execution from the time series. As non-exhaustive examples well known to those skilled in the art, we can cite: the Euclidean distance, or L2, the L1 distance, the Miwkovski distance, the Manhattan distance, the Cosine distance, the Chebyshev distance, etc.

[0098] According to one embodiment of the invention, the distance is calculated on the cumulative sums of the values of the time series.

[0099] We can write this calculation by the following expression: d t 1 ; t 2 = d ∑ i = 1 j t 1 i j ∑ i = 1 j t 2 i j in which: d(t1; t2)represents the distance between the two time series t1 and t2; t 1 i And t 2 i represent the i th value of, respectively, the time series t1 and the time series t2; ∑ i = 1 j t 1 i And ∑ i = 1 j t 2 i therefore form the cumulative sums at rank j of the values of the time series t1 and t2, respectively, the distance d ( t 1; t 2) is then expressed as a distance 'd' between the two sets of values (expressed by the curved braces) formed by these cumulative sums.

[0100] Based on these cumulative sums, it is possible to apply a distance function d, in order to obtain a distance value between two time series.

[0101] For example, it is possible to evaluate the average of the absolute values of the differences between the values of the time series of the same rank j in the two series. In other words: d t 1 ; t 2 = 1 N ∑ j = 1 N ∑ i = 1 j t 1 i − ∑ i = 1 j t 2 i O

[0102] In some cases, time series are multivariate, i.e., they associate a plurality of values with a single measurement point. In other words, a time series grouping several parameter measurements can be associated with a single execution of an application.

[0103] The procedure described below remains valid in this case.

[0104] In step S3, the calculation of a metric between two time series can be achieved by calculating the metrics (as previously described) for each component of the time series, and then calculating an overall metric combining these different distances.

[0105] Thus, if the time series t1, t2 associate with each measurement point X values t 11 , t 12 ... t 1x , respectively t 21 , t 22 ... t 2x , we can calculate x distances dk of components by: d k t 1 ; t 2 = d ∑ i = 1 j t 1 ki j ∑ i = 1 j t 2 ki j

[0106] We can then calculate a global distance from these x distance dk (t1; t2) in different ways, for example by a Minkowski distance.

[0107] More specifically, we can combine the component distances as many orthogonal coordinates, so that the global distance d(t1; d2) can be expressed: d t 1 ; t 2 = ∑ k = 1 x d k t 1 ; t 2 2

[0108] From this distance, we can detect an aberration within the collected time series and therefore executions of applications having aberrant behavior.

[0109] For example, we can calculate distances between several pairs (possibly all) of time series obtained for the different executions of the same application.

[0110] If a distance is greater than a threshold, then one of the two time series concerned can be considered an outlier. By cross-referencing several calculated distances, we can discriminate which one is actually an outlier. If a distance is greater than a threshold and if we have already established that one of the two time series has distances lower than the threshold compared to other series, then we can directly deduce that the other series is an outlier.

[0111] The threshold can be predefined but can also be self-adaptive depending on the different distance values obtained.

[0112] In a step S5, information on the execution corresponding to the aberrant time series can be provided to a user via a human-machine interface. For example, this information can contain data identifying this execution and its execution context (name of the application, execution date, execution parameters set by the user, volume of data processed, etc.). The user can then search for the cause of this aberrant execution, in order to possibly ignore the results of this execution and / or remedy the underlying problems.

[0113] Furthermore, in a step S6, execution optimization parameters for the application can be automatically determined, from the executions of the same application by excluding the executions for which an aberration has been detected.

[0114] Indeed, once the aberrant time series are discarded, the remaining time series can be used to describe the normal behavior of the application. Based on this normal behavior, we can automatically determine how to optimize subsequent executions of the application.

[0115] Also, a step of selecting an acceleration module for an application can be provided, from the executions of the same application, excluding the executions for which an aberration has been detected.

[0116] As previously explained, once the aberrant time series are discarded, the remaining time series are used to describe the normal behavior of the application. Based on normal behavior, an acceleration module can be automatically selected from a catalog of available modules. Each of the available modules can indeed have particular application conditions and the selection aims to determine which modules have application conditions that best match the normal behavior of the application.

[0117] For example, the Atos company's "Small Read Optimizer" (SRO) acceleration module is described on the company's website or in articles such as Robert, Sophie & Zertal, Soraya & Goret, Gael, "Auto-tuning of IO accelerators using black-box optimization", 1022-1027. 10.1109 / HPCS48598.2019.9188173 (2019).

[0118] This module seeks to optimize readings and writings of small volumes (typically less than 4 kilobytes) but multiple and concentrated in time, by recovering frequently accessed blocks in advance to put them in buffer memory.

[0119] Another available module may be the “Smart Burst Buffer” (SBB) module, also from Atos.

[0120] The choice between these two modules (and others) can be based on an analysis of the application's behavior with respect to inputs / outputs. This analysis can be carried out using time series from a profiling tool.

[0121] The invention makes it possible to exclude from these time series aberrant series whose presence could have disrupted the analysis and caused the selection of a non-optimal acceleration module.

[0122] Furthermore, it can be planned to determine the parameters of the chosen acceleration module. For example, the SRO module has 4 parameters and the SBB module a dozen.

[0123] Other parameters that can significantly impact the execution of an application can also be automatically determined, such as the parameters of a parallelization tool (those of the MPI interface, "Message Passing Interface", for example), or even parameters internal to the application itself.

[0124] According to one embodiment, this automatic optimization step can be performed iteratively.

[0125] Thus, the same application is executed several times by changing its execution parameters. By means of the method of the invention, it is possible to eliminate aberrations, and to consider the normal behavior of the application and evaluate different performances linked to the use of a different set of parameter sets.

[0126] At each iteration, the parameters can be changed deductively, i.e. by taking into account the parameters already executed. Different strategies are then possible to browse the space of possible parameter values in order to obtain an optimal parameter set.

[0127] According to one embodiment, the method described can be implemented by an aberrant behavior detection device. This device can be a software module implemented on a computer, i.e. any information processing platform. In particular, this platform can be implemented by a set of circuits co-located in a centralized server or distributed within a distributed server or among a set of servers. This set of servers can include “server farm” or cloud computing arrangements (“ cloud computing ”) .

[0128] This computer can be the same as the information processing platform on which the supervised applications are executed, or another platform to which it is connected via communication means in order to collect the time series.

[0129] The invention is defined by the claims.

Claims

1. Method for detecting outlier behavior in a set of executions of one or more applications on an information processing device, said method being implemented by an outlier behavior detection device, said devices being connected to each other via communication means and comprised in an information processing platform integrated in a centralized server or distributed over a set of servers, said method comprising the steps of - triggering (S1) said set of executions in collaboration with a profiling tool comprised in said information processing platform and connected to said devices, in order to collect, for each execution, at least one time series of measurement points assigning, for each measurement point, a value to a measured parameter; - automatically formatting (S2) the time series obtained for said set, by adjusting by normalization, for each time series, its length, its values and its number of measurement points, said normalization of the length comprising projecting the measurement points of said time series onto a reference interval, said normalization of its values comprising dividing the values of said numerical series by a total quantity corresponding to the set of values for said time series and said normalization of the number of measurement points comprising interpolating a set of additional measurement points so that the number of measurement points of said time series is equal to the number of measurement points of a longer time series of said set; - calculating (S3) a metric between two time series among the time series collected for said set of executions; - detecting (S4) an outlier from a comparison of said metric with a threshold; - excluding, for the same application, executions of said set for which an outlier was detected; and - determining normal application behavior from the remaining executions.

2. Method according to the preceding claim, wherein formatting is performed in pairs of time series within said set.

3. Method according to either of the preceding claims, comprising providing (S5) information corresponding to said outlier to a user via a human-machine interface.

4. Method according to any of the preceding claims, comprising automatically determining (S6) execution optimization parameters for an application from the remaining executions of the same application, said automatic determination comprising repeatedly executing said application with different sets of execution parameters and evaluating application performances related to the use of said sets of execution parameters considering the normal behavior of the application.

5. Method according to any of the preceding claims, comprising a step of selecting an acceleration module for an application, from the executions of the same application, excluding the executions for which an outlier was detected.

6. Method according to claim 1, wherein said total quantity is an approximation of the integral of said time series with respect to time.

7. Method according to any of the preceding claims, wherein said metric is calculated on the cumulative sums of the values of said time series.

8. Computer program comprising instructions which, when the program is executed by a computer, cause said computer to perform the method according to any of the preceding claims.

9. Device for detecting outlier behavior in a set of executions of one or more applications on an information processing device, said devices being connected to each other and comprised in an information processing platform integrated into a centralized server or distributed over a set of servers, said outlier behavior detection device comprising means for: - triggering said set of executions in collaboration with a profiling tool comprised in said information processing platform and connected to said devices, in order to collect, for each execution, at least one time series of measurement points assigning, for each measurement point, a value to a measured parameter; - automatically formatting the time series obtained for said set, by normalizing, for each time series, its length, its values and its number of measurement points, the normalization of the length comprising projecting the measurement points of said time series onto a reference interval, the normalization of its values comprises dividing the values of said numerical series by a total quantity corresponding to the set of values for said time series and the normalization of the number of measurement points comprises interpolating a set of additional measurement points so that the number of measurement points of said time series is equal to the number of measurement points of a longer time series of said set; - calculating a metric between two time series among the time series collected for said execution set; - detecting an outlier from a comparison of said metric with a threshold; - excluding, for the same application, the executions of said set for which an outlier was detected; and - determining normal application behavior from the remaining executions.

10. Device according to claim 9, comprising means for further providing information corresponding to said outlier to a user via a human-machine interface.

11. Device according to either claim 9 or claim 10, comprising means for further automatically determining execution optimization parameters for an application, from the remaining executions of the same application, said means being designed to execute said application a plurality of times with different sets of execution parameters and to evaluate the application performances related to the use of said sets of execution parameters considering the normal behavior of the application.