KR102607808B1 - Dynamic reallocating resources for optimized job performance in distributed heterogeneous computer system - Google Patents

Abstract

An apparatus for dynamically reallocating resources to provide optimized job performance in a distributed heterogeneous computer system including a plurality of computer nodes is provided. The apparatus includes an application injector for operating at least one job to be performed on at least one of the computer nodes. The device further includes a collector for dynamically collecting workload values on each computer node. The device further includes a job notifier for determining known and unknown jobs on each computer node. The apparatus further includes a job optimizer for determining a data distribution vector based on workload values and known and unknown jobs on each computer node. The data distribution vector defines the amount of data to be distributed to computer nodes to perform at least one job.

Description

{DYNAMIC REALLOCATING RESOURCES FOR OPTIMIZED JOB PERFORMANCE IN DISTRIBUTED HETEROGENEOUS COMPUTER SYSTEM}

The present invention relates to heterogeneous computer systems, and more specifically, to a distributed heterogeneous computer system and method including a plurality of computer nodes that dynamically reallocate resources for optimized job performance.

Advances in fields as diverse as manufacturing, advertising, healthcare, finance, etc. are associated with visioning automated systems with minimal user intervention. The three important parts for such a system are sense, process, and react. Regarding sensing, newer devices are equipped with large numbers of sensors. Additionally, these sensors continuously generate large amounts of data. Therefore, there will be a demand for huge processing clusters required to process this much data. The results of this processing can be converted into automated actions to fully recognize the vision of the automated system.

The associated processing method of setting up a processing cluster aims to maximize performance and does not necessarily consider heat, energy, and other reliability factors. This increases installation and operating costs in corresponding systems such as coolers that require installation to reduce heat. Moreover, applications developed to run on their clusters are designed specifically for these systems and include hardware specific optimization. So updates in the hardware of existing systems require corresponding updates in applications to include optimizations. Application developers and system designers may not have the expertise to perform appropriate optimization for the systems involved. Additionally, application developers may not have knowledge of other applications competing in the system. This complicates the application update task on an hourly basis and may cause the performed optimization tasks to be inaccurate.

Another processing method involves searching for various computing/computer nodes that may themselves contain dedicated task schedulers. Task schedulers can usually be implemented to maximize performance. However, task schedulers may or may not consider energy optimization. Even if task schedulers take energy optimization into account, it is impossible to achieve a broad energy optimization point for the system due to limited visibility of all computing nodes at a given task scheduler level. Applications that rely on task schedulers for energy optimization may not achieve extensive optimization, resulting in uncontrolled and unmonitored waste of energy.

Moreover, while applications are written for maximized performance, they are not actually considered on the computing node on which the application runs. For example, besides various computing nodes, only some nodes are used extensively and generate heat and damage the computing nodes. These systems require ongoing management, which results in high management costs.

Embodiments may provide a distributed heterogeneous computer system including a plurality of computer nodes that dynamically reallocate resources for optimized job performance.

Embodiments may provide an application injector at at least one computer node from a plurality of computer nodes that invokes at least one job to be performed.

Embodiments may provide a collector on at least one computer node that dynamically collects workload values from each of the computer nodes.

Embodiments may provide a job informer at at least one computer node that determines known and unknown jobs at each of the computer nodes.

Embodiments may provide a job optimizer at at least one node that determines a data distribution vector based on known and unknown jobs and workload values at each of the computer nodes. The data distribution vector defines the size of data to be distributed to a plurality of nodes to perform at least one job.

Embodiments may provide a mechanism to separate the application layer and optimization layer.

Accordingly, embodiments may provide distributed heterogeneous computer systems. A distributed heterogeneous computer system may include a plurality of computer nodes, and each of the plurality of computer nodes may be functionally connected to a network through a network interface to provide data communication between the computer nodes. Each of the computer nodes may include at least one job to be performed. The distributed heterogeneous computer system may also include an application injector on at least one node of the plurality of computer nodes that invokes at least one job to be performed. Additionally, the distributed heterogeneous computer system may include a collector on at least one computer node that dynamically collects workload values from each of the computer nodes. The distributed heterogeneous computer system may also include a job informer at at least one computer node that determines known and unknown jobs at each of the computer nodes. Additionally, the distributed heterogeneous computer system may include a job optimizer in at least one computer node that determines a data distribution vector based on known and unknown jobs and workload values in each of the computer nodes. The data distribution vector may define the total amount of data distributed to a plurality of nodes to perform at least one job.

Additionally, embodiments may provide an apparatus for dynamically reallocating resources for optimized computer performance in a distributed heterogeneous computer system including a plurality of computer nodes. The apparatus may include an application injector configured to invoke at least one job to be performed on at least one computer node of the plurality of computer nodes. The device may also include a collector configured to dynamically collect workload values from each of the computer nodes. The device may also include a job informer configured to determine known and unknown jobs at each of the computer nodes. The apparatus may also include a job optimizer configured to determine a data distribution vector based on known and unknown jobs and workload values at each of the computer nodes. The data distribution vector can define the total amount of data to be distributed across a plurality of nodes to perform at least one job.

Additionally, embodiments may provide a method for dynamically reallocating resources for optimized job performance in a distributed heterogeneous computer system. The method may include calling, by the artificial injector, at least one job to be performed on at least one computer node of the plurality of computer nodes. Additionally, the method may include dynamically collecting workload values from each of the computer nodes by a collector. Additionally, the method may include determining known and unknown jobs at each of the computer nodes by a job informer. Additionally, the method may include determining, by the job optimizer, a data distribution vector based on known and unknown jobs and workload values at each of the computer nodes. The data distribution vector can define the total amount of data to be distributed across a plurality of nodes to perform at least one job.

In some embodiments, the workload value may be a function of at least one of a performance metric, a reliability metric, additional factors, and a data distribution rate.

In some embodiments, the data distribution vector may be stored in a lookup table.

In some embodiments, the method may feed back lookup table entries containing the difference between the actual time and the expected time to run at least one job.

In some embodiments, the performance of at least one job on each of the computer nodes of the system may be periodically optimized by a refresher in the computer system.

In some embodiments, the refresher may dynamically determine a time interval for optimizing the performance of at least one job of each computer node of the system using the difference between the actual time and the expected time for running at least one job.

In some embodiments, the variance vector may be determined using at least one of a linear optimization model and a non-linear optimization model.

These and other aspects of the embodiments will be better understood when considered in conjunction with the following detailed description and accompanying drawings. However, it is to be understood that the following detailed description, which refers to exemplary embodiments and various detailed descriptions thereof, is given by way of example and not limitation. Various changes and modifications may be made within the scope of the embodiments without departing from the technical spirit of the present invention, and the embodiments may include all such modifications.

According to the present invention, it may be possible to free application developers from optimization tasks. In other words, fast updates may be possible. Because the optimization tasks are performed independently and include complete visibility of all computer nodes, a wide range of optimization values can be achieved. Accordingly, the reliability of individual computer nodes is improved and improved cost savings are ensured. Moreover, the present invention can help save energy from an overall system perspective.

Advantages, features and other aspects of specific embodiments of the present invention may become more apparent with reference to the following detailed description and drawings.
1 shows a block diagram of a computer node with application processes connected to an optimization process in a related technical field.
Figure 2 shows a block diagram of a computer node with separate application processes and optimization processes, according to some embodiments.
3 shows a distributed heterogeneous computer system including a plurality of computer nodes that dynamically reallocate resources for optimized job performance, according to some embodiments.
Figure 4 shows a block diagram of a computer node with separate application and optimization layers to achieve extensive optimization, according to some embodiments.
Figure 5 is a flowchart showing a method of dynamically reallocating resources for optimized job performance in a distributed heterogeneous computer system, according to some embodiments.
FIG. 6 is a conceptual diagram showing various operations of an application injector that calls jobs between different computer nodes, according to some embodiments.
Figure 7 is a conceptual diagram showing various operations included in the optimization process/optimization layer according to an embodiment of the present invention.
Figure 8 shows a block diagram of a collector for dynamically collecting workload values from each computer node, according to some embodiments.
Figure 9A shows an example of an optimization process for obtaining a data distribution vector for a completion task node, according to some embodiments.
FIG. 9B shows an example of a generalization process for converting a data variance vector to a normal vector, according to some embodiments.
10 shows a job informer/task information repository that maintains information storage for different tasks running in a distributed heterogeneous system, according to some embodiments.
11 is a flowchart showing a method of generating task information for an unknown task identifier, according to some embodiments.
12 shows an example scenario in which a refresher is triggered for an optimization process, according to some embodiments.
13 is a block diagram showing a use case in the manufacturing industry, according to some embodiments.
14 is a flowchart showing a real-time operation system of a distributed heterogeneous computer system, according to some embodiments.
Figure 15 shows a computing environment applying a distributed heterogeneous computer system and method for dynamically allocating resources for optimized job performance according to an embodiment of the present invention.

Various embodiments of the present invention will be described in detail with reference to the attached drawings. In the following detailed description, specific descriptions, such as detailed configurations and elements, are provided simply to enable a general understanding of embodiments of the present invention. Therefore, it will be well understood by those skilled in the art that the embodiments described in the text can be modified in various ways without departing from the technical spirit and scope of the present invention. Furthermore, well-known functions and structures will be omitted for convenience and clarity of explanation.

Additionally, the various embodiments described in the text are not necessarily mutually exclusive, and these embodiments may be combined with one or more embodiments to form other new embodiments. In the text, the term “or” refers to the non-exclusive or, unless otherwise defined. The examples used in the text are considered simply to help those skilled in the art understand how to implement the embodiments. Accordingly, the examples should not be considered limiting to the scope of the embodiments.

As is common in the technical field to which the present invention pertains, embodiments are described and illustrated in terms of the described function or blocks that perform the functions. These blocks, referred to herein as units or modules, are analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic devices, active electronic devices, optical devices, hardware circuits, etc. It can be physically implemented and can be selectively driven by firmware or software. For example, circuits may be mounted on a substrate support such as one or more semiconductor chips or a printed circuit board. The circuits that make up the block are implemented by dedicated hardware or processors (one or more programmed microprocessors and associated circuits), or a combination of dedicated hardware to perform some functions of the block, and the processor performs other functions of the block. You can. Each block of the embodiments may be physically divided into two or more communicating distinct blocks without departing from the scope of the present invention. Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the invention.

Accordingly, embodiments may provide an apparatus for dynamically reallocating resources for optimized job performance in a distributed heterogeneous computer system including a plurality of computer nodes. The apparatus may include an application injector configured to invoke at least one job to be performed on at least one computer node of the plurality of computer nodes. Additionally, the device may include a collector configured to dynamically collect workload values from each of the computer nodes. Additionally, the device may include a job informer configured to determine known and unknown jobs in each of the computer nodes. Additionally, the device may include a job optimizer configured to determine a data distribution vector based on known and unknown jobs and workload values in each of the computer nodes. The data distribution vector can define the total amount of data to be distributed across a plurality of nodes to perform at least one job.

Unlike conventional systems and methods, the proposed method and system can achieve extensive optimization of computer nodes by separating the application process and optimization process so that more complex nonlinear optimization techniques can be used. Additionally, the proposed method and system can be expanded horizontally as well as vertically. This may make it possible to use a variety of computer nodes to expand from an embedded device to a complete hierarchical computer cluster.

Unlike conventional systems and methods, the system and method of the present invention can separate the application development and optimization processes. That is, it may be possible to free application developers from optimization tasks, allowing for faster updates. Because the optimization task is performed independently and with complete visibility of all computer nodes (e.g., 100a to 100n in Figure 3), a wide range of optimization values can be achieved, thereby reducing the visibility of individual computer nodes. Reliability is improved and cost savings are guaranteed.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Referring to the following drawings, particularly FIGS. 1 to 15, embodiments of the present invention are shown. In the following drawings, similar reference symbols collectively indicate corresponding features throughout the drawings.

1 shows a block diagram of a computer node 100 with an application process coupled to an optimization process, in some related art field. In conventional methods, the developer must write an optimization process and data distribution technique (eg, OpenVX). Data distribution can be performed using conventional methods in which an optimization process is attached to the processor on which the application process is running. Therefore, complex optimization techniques cannot be implemented, and a sub-optimal distribution vector must suffice. Additionally, conventional methods include less visibility of computer node 100 and other active tasks. Additionally, conventional methods do not scale in a multi-computer cluster environment (e.g., Hadoop cluster) and manage some types of tasks such as input/output (I/O) intensive tasks, random memory access, etc. Can not.

Industry 4.0 includes visibly smarter and more automated equipment. As a result, getting massive sensory data generated by current devices requires a lot of data processing in real time to ensure utilization in action performance mechanisms and automated decision making. In other words, the demand for large data centers, especially in the manufacturing sector, will continue to increase in the future. Setting up a new data center faces a variety of challenges in addition to those mentioned previously. However, issues such as energy optimization, improved reliability, and continuous performance updates will have a significant impact on the overall operating costs of data centers and manufacturing. Even if manufacturers manage to save just $1 per device per day, this could result in savings of millions of dollars per year. Considering this, excluding manufacturing facility costs, the penalty due to facility outage and the maintenance costs of manufacturing are very large.

Figure 2 shows a block diagram of a computer node 100 with separate application processes and optimization processes, according to some embodiments. As shown in Figure 2, application processes and distribution techniques are separated. Therefore, application developers or application process developers do not need to consider data distribution vectors. An application associated with an application process can simply query the data distribution vector for tasks. However, data distribution can be performed separately, and complex non-linear optimizations can be used to ensure that the system is stable.

Because the application process and data distribution techniques are separated, the application process and data distribution techniques can have more visibility of all other computer nodes as well as all other active tasks. Unlike conventional systems and methods using the computer node 100 of FIG. 1, the proposed method using the computer node 100 of FIG. 2 can be easily expanded to a multi-computer cluster environment, I /O Can manage all types of tasks such as intensive tasks, random memory access, etc.

Unlike conventional systems and methods, the proposed system and method can distribute tasks generated from application layers over a broad scale of computer nodes 100, thereby without affecting the minimum required performance. , reliability can also be improved while minimizing the cost involved in distributing tasks.

Conventional systems and methods can provide a static linkage between the application development (i.e., technology) and optimization processes. Application developers may be concerned with optimizations. In other conventional systems and methods, some designs are proposed such as an improved compiler for heterogeneous computing. In these types of designs, applications are developed in such a way that the compiler uses the same process for optimization, but the compiler is specified as Open Computing Language (OpenCL). Similarly, other designs are proposed such as design frameworks for heterogeneous computing. In this kind of design framework, applications that do not adhere to the design framework cannot benefit from optimization.

The problem with prior art systems and methods is based on a fixed connection between application development and optimization process configuration. These problems limit the use of conventional systems and methods. However, developers do not include system-level visibility (of other applications running on the system along with their application). Therefore, optimization is application specific. However, in the proposed system and method, the application process and optimization process can be separated from each other. Additionally, developers can have complete system level visibility. In other words, application developers do not need to consider data distribution vectors.

3 includes a plurality of computer nodes 100a to 100n (which may be referred to herein as computer nodes 100) to dynamically reallocate resources for optimized job performance, according to some embodiments. A distributed heterogeneous computer system 300 is shown. In some embodiments, the distributed heterogeneous computer system 300 may include a plurality of computer nodes 100a to 100n. Each of the computer nodes 100 is functionally connected to the network 301 through a network interface to enable data communication between the computer nodes 100, for example, between the computer node 100a and the computer node 100b. Data communication can be provided.

Each of the computer nodes 100 may include an application layer 110 (e.g., 110a, 110b, 110n) and an optimization layer 120 (e.g., 120a, 120b, 120n). The application layer 110 (or application process) may query a data distribution vector for a plurality of tasks. The optimization layer 120 may separately process data distribution. Detailed functions of the application layer 110 and optimization layer 120 are described in more detail with reference to FIG. 4 .

Figure 4 shows a block diagram of a computer node 100 in which an application layer 110 and an optimization layer 120 are separated to achieve extensive optimization, according to some embodiments. In some embodiments, computer node 100 may include an application layer 110 and an optimization layer 120. The application layer 110 may include application specific components 111 and an application injector 112 (AI). The optimization layer 120 includes a collector 121, job optimizer 122, refresher 123, job informer 124, look-up table (LT) manager 125, query interface 126, and LT. It may include (127).

Application-specific configurations 111 may be configured to share data load and task type with AI 112. In some embodiments, AI 112 may be configured to invoke at least one job to be performed on computer node 110. In some examples, AI 112 may be a very light weight component that acts as a connector between application specific components 111 and optimization layer 120.

After receiving the task type and data load, AI 112 may query the optimization layer 120 to obtain a data distribution vector. Depending on the data distribution vector, tasks may be scheduled among different computer nodes 100 with data loads of the distribution vector. However, the overhead generated by the AI 112 can be ignored because the AI 112 runs in O(1) time.

The configurations of the optimization layer 120 are described below.

The collector 121 may be configured to dynamically collect workload values from each of the computer nodes 100. In some embodiments, the collector 121 basically performs the task of collecting parameters (parameters related to performance, parameters related to reliability, parameters related to energy, etc.) of the distributed heterogeneous computer system 300 of FIG. 3 for each node. It can be processed with . Additionally, the parameters of the distributed heterogeneous computer system 300 may be classified into two categories, such as fixed and dynamic. A detailed description of the fixed and dynamic categories will be explained with reference to FIG. 8. Additionally, the collector 121 may essentially define a concept hierarchy (abstraction) that can be extended to a specific computer node 100 in specific use-case scenarios.

Refresher 1223 may be configured to trigger activation of optimization layer 120. Additionally, the refresher 123 may trigger the collector 121 to update parameters of the distributed heterogeneous computer system 300. The job optimizer 122 may be configured to optimize tasks based on parameters collected for all tasks listed in the job informer 124 (or task information repository). In some examples, activation may be an external trigger signal based on a use-case scenario that is periodic or non-periodic.

Job informer 124 may be configured to determine known and unknown jobs in each of the computer nodes 100. Additionally, the job informer 124 may be configured to maintain and store a knowledge base for tasks running in the distributed heterogeneous computer system 300. In some examples, the knowledge base may be created manually before distributed heterogeneous computer system 300 is installed. In some other examples, the knowledge base may be automatically created over a period of time. Moreover, the job informer 124 determines the time complexity, nature (e.g., memory intensive, processor intensive, or I/O intensive), type (e.g., critical or normal), and expected completion. It may be configured to store information associated with tasks, such as time. Each task listed in the job informer 124 is given a unique task identifier.

Additionally, the job optimizer 122 may be configured to determine a data distribution vector based on known and unknown jobs and workload values in each of the computer nodes 100. The data distribution vector may define the size of data to be distributed to other computer nodes 100 to perform at least one job. In some embodiments, the workload value may be a function of performance metrics, reliability metrics, extra factors, data distribution ratio, and combinations thereof. there is.

In some examples, job optimizer 122 may optimize jobs/tasks based on a mathematical model specifically designed to optimize task execution time and energy consumed. The selected mathematical model may be linear, nonlinear, stochastic, or a combination thereof (e.g., a hybrid model) based on a use-case scenario for the distributed heterogeneous computer system 300. Additionally, the job optimizer 122 can receive parameters collected from the collector 121 and information stored in the job informer 124 as input. In addition, the job optimizer 122 uses a simplex method, interior-point method, and gradient descent/ascent method applicable to the cost-function model. ) can be implemented. The obtained result may be a data distribution vector for each of the tasks listed in the job informer 124. Additionally, the data distribution vector may be stored in the LT 127 and cached.

Each row entry in LT 127 may be associated with a unique task identifier maintained in job informer 124, and corresponding floating entries may define a data distribution vector. The sum of the floating entries in each row is equal to 1.0. A higher floating value of a computer node 100 for a task may mean that a given computer node 100 is better suited to managing higher data for the task at that time. The expected completion time entry may be a theoretical value for tasks in units per data size. A task for a given data size can be expected to be completed within the time for the data size. LT 127 may be configured to maintain a variance between actual driving times and theoretical estimated times. The difference corresponding to the maximum value may be reported by the application running the task. Table 1 below shows an example lookup table.

Task ID computer node (100a) computer node (100b) Computer Node (100c) Computer Node (100d) Computer Node (100n) Expected completion time (units/data) Difference (unit/data) One 0.2 0.1 0.3 0.3 0.1 1.2 0.02 2 0.1 0.2 0 0.4 0.3 3.1 0.1 3 0 0 0 0 One 2.5 0.005

In some embodiments, device/computer node 100 may include a lookup table manager 125 in at least one computer node 100 that stores the data distribution vector in LT 127. The LT manager 125 may be configured to maintain the LT 127 and provide a query interface 126 to the AI 112 to retrieve the data distribution vector. The LT manager 125 can define a hashing technique to quickly index and retrieve the content of the LT 127. The LT manager 125 may provide an interface through which the AI 112 queries and retrieves data distribution vectors for tasks driven by the AI 112. The functionality of AI 112 may be intended to fetch a data distribution vector for a specific task identifier from LT 127. The time complexity involved is O(1).

Unlike conventional systems and methods, the proposed optimization process can operate AI 112 independently. AI 112 may be designed using techniques to communicate with optimization layer 120. The communication technique may be a socket based, an inter process communication to an inter task communication. This may separate optimization layer 120 from AI 112. In other words, any application design using any language can take advantage of the optimization layer 120. This can lead application developers away from task optimization. Instead, they can focus more on application development, which reduces overall development time.

Figure 5 is a flowchart 500 showing a method of reallocating resources for optimized job performance in a distributed heterogeneous computer system 300 according to embodiments of the present invention. At operation 502 , the method may include invoking at least one job to be performed on the computer node 100 . In some embodiments, the method may cause AI 112 to invoke at least one job to be performed on computer node 100. In some embodiments, at least one job to be performed on the computer node 100a among the plurality of computer nodes 100a to 100n may be called. In some other examples, at least one job to be performed on the computer node 100b among the plurality of computer nodes 100a to 100n may be called.

At operation 504, the method may include dynamically collecting workload values from each of the computer nodes 100. The method may allow the collector 121 to dynamically collect workload values from each of the computer nodes 100. At operation 506 , the method may include determining known and unknown jobs at each of the computer nodes 100 . The method may allow the job informer 124 to determine known and unknown jobs in each of the computer nodes 100.

At operation 508 , the method may include determining a data distribution vector based on known and unknown jobs and workload values at each of the computer nodes 100 . The method may allow the job optimizer 122 to determine a data distribution vector based on known and unknown job and workload values in each of the computer nodes 100. In some embodiments, the data distribution vector may define the total amount of data distributed to a plurality of computer nodes 110a to 100n to perform at least one job.

At operation 510, the method may include storing the data distribution vector. The method may cause LT 127 to store the data distribution vector. At operation 512, the method may include periodically managing (e.g., optimizing) the performance of at least one job on each of the computer nodes 100 of the distributed heterogeneous computer system 300. The method may allow the refresher 123 to periodically manage (eg, optimize) the performance of at least one job in each of the computer nodes 100 of the distributed heterogeneous computer system 300.

The various operations, actions, blocks, steps, etc. in method and flowchart 500 may be performed in the order shown, in a different order, or simultaneously. Additionally, in some embodiments, some of the operations, actions, blocks, steps, etc. may be omitted, added, modified, or skipped without departing from the scope of the present invention.

FIG. 6 is a conceptual diagram 600 showing various operations of the AI 122 that calls jobs between other computer nodes 100 according to embodiments of the present invention.

At operation 602, the method may include calling a task including data information and task information. The method may allow the AI 112 to call a task including data information and task information. At operation 604, the method may include querying the LT manager 125 for a data distribution vector for a particular task identifier. The method may allow the AI 112 to inquire with the LT manager 125 about the data distribution vector for a specific task identifier.

At operation 606, the method may include receiving a data distribution vector for the corresponding task identifier from the LT manager 125. The method may allow the AI 112 to receive a data distribution vector for the corresponding task identifier from the LT manager 125. At operation 608, the method may include scheduling the task according to the data distribution vector. The method may allow the AI 112 to schedule tasks according to the data distribution vector.

In operation 610, the method transmits the variance time-taken per byte-data by the task to the LT manager 125, which can serve as incremental data for optimization. You can. The method may allow the AI 112 to transmit the difference in time consumed per byte-data by task to the LT manager 125, which can serve as incremental data for optimization.

Various operations, actions, blocks, steps, etc. in the method and conceptual diagram 600 may be performed in the order shown, in a different order, or simultaneously. Additionally, in some embodiments, some of the operations, actions, blocks, steps, etc. may be omitted, added, modified, or skipped without departing from the scope of the present invention.

FIG. 7 is a conceptual diagram 700 showing various operations included in the optimization process/optimization layer 120, according to some embodiments. The optimization layer 120 may run only one instance in the distributed heterogeneous computer system 300. Additionally, the optimization layer 120 can start its processes by triggering the LT manager 125 and the job optimizer 122 in parallel. The LT manager 125 can start a query and response service and listen to queries received from the AI 112. Queries may be one of the types described below.

Data distribution vector query : AI 112 can obtain an optimized data distribution vector by starting a query for a specific task identifier. Additionally, the LT manager 125 may fetch the data distribution vector from the LT 127. If the data distribution vector is unavailable in the LT 127, the LT 127 may respond with a default distribution vector. In some embodiments, the received data distribution vector query expected by LT manager 125 may have the following format:

Query Type="Data Distribution Vector", Task ID='1"

Additionally, upon receiving the data distribution vector query described above, LT manager 125 may respond with the following value.

Task ID="1", Node1 =0.2, Node2 =0.1, Node3 =0.3, Node4 =0.3, Node N=0.1, Expected Time=1.2

Table entries may contain the same meaning as LT (127) entries. The task identifier field of the above-described query may be NULL, indicating an unknown task.

Feedback query: After scheduling the task based on the data distribution vector, the AI 112 can return the time-variance consumed per byte to the LT manager 125. . Additionally, the LT manager 125 can update information to the LT 127 only if the received value is greater than the current value in the LT 127. An example feedback query may have the following format:

Query Type="Feedback", Task ID='1", Variance Report=0.02

Upon receiving the feedback query, if the reported difference is maximum, LT manager 125 may update the variance entry of LT 127. AI 112 may not wait for acknowledgment from LT manager 125.

Shutdown query: The LT manager 125 may receive an asynchronous shutdown query from external sources. Upon receiving a shutdown query, LT manager 125 may initiate a shutdown request to job optimizer 122.

Query Type=" Shutdown"

The optimization layer 120 may perform the task of optimization. After each iteration, the optimization layer 120 may output a data distribution vector for all tasks known to the distributed heterogeneous computer system 300. This data distribution will be assumed to be valid until the next iteration.

A detailed description of the collector 121 will be explained in conjunction with FIG. 8. A detailed description of the job optimizer 122 will be described together with FIGS. 9A and 9B. A detailed description of the job informer 124 will be described together with FIG. 10. A detailed description of the refresher will be explained in conjunction with FIG. 12.

FIG. 8 shows a block diagram of a collector 121 that dynamically collects workload values from each of the computer nodes 100, according to some embodiments. The collector 121 includes a data input 121a, a static collector 121b, a dynamic collector 121c, a data output 121d, an internal clock 121e, and a trigger processor 121f. It can be included.

The collector 121 may be configured to collect parameter values requested by the job optimizer 122. The static collector 121b may collect static parameters (eg, maximum memory capacity, maximum processor clock speed, etc.). Fixed parameters may not change periodically or may change due to external events such as hardware upgrades. Therefore, the fixed collector 121b can be called through the data input interface only when an external event occurs and the trigger event is processed through the trigger processor 121f.

The dynamic collector 121c may be configured to collect dynamic parameters (e.g., memory usage, current processor usage, and processor temperature, etc.), which may be collected periodically through the interface of the data input 121a. You can. The dynamic collector 121c may perform sampling of continuous data in response to the internal clock 121e. In some embodiments, collector 121 may be designed in such a way that collector 121 can be expanded, for example, new collectors may be added later based on system configuration updates. The collector 121 may output a value (eg, through an interface of the data data output 121d) as a “key=value” pair. The key may define the unique parameter name considered by the optimization mathematical model.

Figure 9A shows an example of an optimization process to obtain a data distribution vector for a completed task load, according to some embodiments. Job optimizer 122 may receive data from collector 121 and job informer 124 and then begin an optimization technique (e.g., a simple method in a linear optimization problem). The job optimizer 122 may start an optimization operation based on the mathematical framework proposed below.

“D” is a data distribution vector that minimizes the execution time “t” according to the set of constants C={C _p } for each of m computer nodes 100. It is assumed that "P" can be a function that can act independently and simultaneously with respect to important resources.

The value of "P" can range from 1 to m, and p can be an element of the set K P, which is a subset of K with the maximum number of elements of _P. Additionally, individual execution times t _p can be used to measure performance metrics (e.g., computer node speed, node data capacity, or P _p applicability), reliability metrics (e.g., mean time between failures (MTBF), ) or R _p ), additional factors (e.g., task nature metrics, data nature metrics, task-node affinity, energy affinity, or E _p ), and data dispersion rates referred to by D _k It may contain a function of (%). The framework described above may include a convex surface with a single minimum, i.e., a unique solution exists if the Jacobian matrix is positive. Parameters (C _p , P _p , R _p ) may be generated from the collector 121 . The parameter (E _p ) may be generated from the job informer 124. The function f may describe the mathematical model used for optimization (which may be linear/nonlinear, stochastic, or hybrid).

In the first step, the number of floating point operations (FLOPs, flops) required per data unit can be calculated for all tasks listed in the job informer 124 based on task complexity. This load can be added to all tasks to obtain the total load. Total load can now be applied to the mathematical framework described above, including C _p , P _p , R _p , and E _p . Additionally, optimization techniques such as simplex method, gradient decrease/increase, inner point method, etc. can be used to solve the mathematical model. After the first step, the task may be left with a single data distribution vector for the total load.

For example, assume the total load is 60 flops/unit (=20+30+10), as shown in Figure 9A. The value of collector 121 can be given as Matrix Collector "I _c " [2, 3, 1] for three different collectors. Assume that the heterogeneous computer system includes four different computer nodes 100, and that all tasks have the same affinity to the computer nodes 100. The optimization model can be considered as follows.

Time = 60 * Ic * A * cn1 + 60 * Ic * B * cn2 + 60 * Ic * C * cn3 + 60 * Ic * D * cn4

In the above-described equation, variables cn1, cn2, cn3, and cn4, which are data distribution values for each computer node 100, can be determined. For given constants A, B, C, and D (which depend on the mathematical model), the total time can be minimized. For example, a given constant could be:

A = Transpose [2.5, 3.5, 0.5]

B = Transpose [0.8, 1.17, 0.167]

C = Transpose [0.65, 0.875, 0.125]

D = Transpose [1.25, 1.75, 0.25]

Additionally, performing the simple technique can cause the optimal values of cn1, cn2, cn3, and cn4 to be 0.1, 0.3, 0.4, and 0.2, respectively.

FIG. 9B shows an example of a normalization process for converting a data variance vector into a normal vector, according to some embodiments.

In a second step, job optimizer 122 may use the data distribution vector of the total load and normalize the total load for all tasks listed with job informer 124. Normalization can be performed based on the load contribution of a task to the total load to obtain its data distribution vector. The normalized vector for every task may be updated in LT 127.

FIG. 10 shows a job informer/task information storage 124 that maintains information about different tasks running in the distributed heterogeneous computer system 300, according to some embodiments.

Job informer 124 may store task identifier, complexity, and additional optimization model parameters. The task identifier may be a unique task identifier given to the task. Complexity can be defined by the following notations: 1, 2, e1, e2, etc. At this time, 1 = O(n), 2 = O(n ² ), e1 = O(e ⁿ ), and e ² = O(e ^{n^2} ). Additional parameters may relate to data access behaviors, computer node preferences, etc. Job informer 124 may include two steps to obtain required information.

User Configuration File loader: A user of the distributed heterogeneous computer system 300 may provide a configuration file containing information associated with a commonly known task. Job informer 124 can also load and update its information stores. The format of the configuration file is implementation dependent.

Automatic Analysis: Automatic analysis may include gathering required information and analyzing unknown tasks, and may update information in job informer 124. Unknown tasks may be those tasks for which the user does not provide any information. Whenever the LT manager 125 receives a data distribution query with a “task identifier” filled with NULL, the LT manager 125 may provide a unique task identifier to the unknown task, and the job informer 125 You can trigger it to begin analysis of an unknown task and attempt to gather the required information.

FIG. 11 is a flowchart 1100 showing a method for generating task information for an unknown task identifier, according to some embodiments. At operation 1102, the method includes inputting a query to the LT manager 125 for a data distribution vector for a particular task identifier. In some embodiments, the method may cause AI 112 to enter a query to LT Manager 125 for a data distribution vector for a specific task identifier.

At operation 1104, the method may include determining whether the requested task identifier is present or absent in the job informer 124. In some embodiments, the method may allow the LT manager 125 to determine whether the requested task identifier exists or does not exist in the job informer 124. If the task identifier is not in job informer 124, job informer 124 may start an automatic analysis process (e.g., calibration) at operation 1106. If the job informer 124 determines that a task identifier exists, the job informer 124 may return the requested task information in operation 1108.

At operation 1106, the method may include starting an automatic analysis process to determine information about the task identifier. If the information is not valid for a particular task identifier, the task identifier may be marked with a calibration tag. The method may allow the job informer 124 to start an automatic analysis process to determine information about the task identifier. If the information is not valid for a particular task identifier, the task identifier may be marked with a redaction tag.

In operation 1110, the method may include mapping unknown tasks to known tasks using automatic analysis and returning a data distribution vector for the known task model. The method may allow the job informer 124 to map unknown tasks to known tasks using automatic analysis and return a data distribution vector for the known task model.

In operation 1112, the method may include analyzing variance over a fixed number of iterations. The method may allow the job informer 124 to analyze differences for a fixed number of iterations using automatic analysis. In operation 1114, the method may include calculating a mean square error (MSE) based on analysis of differences computed over a fixed number of iterations. The method may cause the job informer 124 to calculate a mean square error (MSE) based on an analysis of differences computed over a fixed number of iterations. Additionally, the same process can be repeated for all unknown task identifiers along with all known task models.

In operation 1116, the method may include marking the known task with a minimum mean square error (minimum MSE) as the best fit result for the unknown task. The method may allow the job informer 124 to mark a known task with a minimum mean square error (minimum MSE) as the best fit result for an unknown task. For example, the task model that results in the minimum mean square error can be used as the optimal task model for an unknown task.

At operation 1118, the method may include performing calibration to remove calibration tags for unknown task identifiers. The method may allow the job informer 124 to perform calibration to remove calibration tags for unknown task identifiers. At operation 1120, the method may include updating the unknown task identifier with information of the optimal task model to: The method may allow the job informer 124 to store/update the unknown task identifier with information of the optimal task model for the following.

The various operations, actions, blocks, steps, etc. in method and flowchart 1100 may be performed in the order shown, in a different order, or simultaneously. Additionally, in some embodiments, some of the operations, actions, blocks, steps, etc. may be omitted, added, modified, or skipped without departing from the scope of the present invention.

Unlike conventional systems and methods, the proposed system can help save energy (from the perspective of the entire system: processor + heat sink / cooler / fan + board + disk / memory, etc.). In summary, the total energy consumed is the sum of the energies consumed and provided by computer nodes 100 (e.g., processor, cooler/fan system, disk access drivers, memory, and other components on the board). It can be proportional. Additionally, the energy wasted by computer nodes 100 is directly related to the area of the temperature profile, which in turn depends on the processing load and rate.

Since the temperature profile and its first derivative are continuous, the average value is given by the equation below.

That is, the average temperature is directly related to the energy wasted by computer nodes 100. Achieving energy savings in computer nodes by maintaining the processor core temperature of computer nodes 100 at an optimal level may be important in a first order approximation. (It may be important, to first order of approximation, to maintain processor core temperature of the computer nodes 100 at optimum level to achieve energy saving in the computer nodes 100.) This can be achieved by coolers and fan system. This is not a simple method because their systems consume energy to operate. A better alternative is to distribute operations among a plurality of computer nodes 100 so that the energy consumption of the overall system is suppressed. The distributed heterogeneous computer system 300 will be considered to be comprised of processors and co-processors, with tasks running simultaneously on the processors and co-processors.

Case I. Constant clock frequency : When a task is performed, the processor frequency will be assumed to remain constant. (i.e. no over-clocking or under-clocking.)

Sub-Case 1 : Data distribution between computer nodes 100 is virtually identical.

Sub-Case 2 : Data distribution among computer nodes 100 is not substantially equal.

Case Ⅱ. Dynamic clock frequency : The latest processors in computer nodes 100 are equipped with a PROCHOT# signal that allows the processors to change their frequency to prevent overheating. This will change the processing speed of the computer nodes 100 and the rate at which they heat up. Energy bias is calculated for a distributed heterogeneous computer system 300 containing two identical processors. The energy bias can reflect the total amount of energy saved using the proposed method.

is the energy required when there is no data dispersion, and is the energy required when d ₁ data is provided to the first same processor and is the energy required when d ₂ data is provided to the second same processor. They are given by the following equations:

Unlike conventional systems and methods, the proposed method can perform theoretical analysis of the reliability of a distributed heterogeneous computer system 300. Reliability (as defined by the probability of failure or the inverse of the failure rate) is a temperature dependent object, and it decreases with increasing temperature. That is, it is important to maintain temperatures at levels below average. To facilitate a better understanding, the case without data distribution will be considered compared to the optimized data distribution. When using the proposed method, comparing the case where a single processor manages all data load and the case using the proposed data distribution when multiple processors/auxiliary processes are present, the energy consumption is lower in the latter case. It can be further reduced. This applies to optimal data distribution and random/local data distribution using the proposed method. Local data distribution techniques do not have complete visibility like local processor schedulers. That is, from established relationships, the average temperature is relatively low in the latter case. That is, it can result in low failure rate, high MTBF and ultimately high reliability.

Unlike conventional systems and methods, the proposed method is less dependent on the system and environment. In some embodiments where the proposed system and method demonstrate low dependency on the system and environment, the proposed system may essentially include two systems with different configurations. The first system may be comprised of a slower processor (eg, a slow CPU) and a slower secondary processor (eg, a slow GPU). The second system may consist of a faster processor and a faster GPU.

An example application may be developed for blurring images using the proposed methods and systems described above. The selected system configurations allow the second system to be considered an upgraded version of the first system. The developed blur application can be optimized for the first system. In the current scenario involving an update of a first system to a second system, applications optimized for the first system may require to be updated. However, in the text, if an application is developed using the proposed method, it can be run on a second system using similar optimizations. This can be experienced by modifying the optimization technique to obtain a different data distribution vector for every call.

Figure 12 shows an example scenario where refresher 123 is triggered for an optimization process, according to some embodiments. Refresher 123 may trigger the start of the next iteration of the optimization processor described above. Triggers can be due to periodic timer expiration or external factors. Timer-based triggers can be used to start the next optimization iteration after some time interval. The timer period may be increased or decreased based on the difference entries of the LT 127 for the previous repeated operation.

The refresher 123 may follow a multiplicative increase and additive decrease (MIAD) method that changes the timer section/time stamp based on feedback. If the MSE is lower than the user-specified threshold, the timer period may be increased, otherwise the timer period may be decreased. An external signal can be triggered to start the next repetitive operation only when the system has experienced some changes. If the difference reported by all active applications is lower than the threshold, the timestamp of the refresher 123 may be incremented. If the differences reported by all active applications do not fall within a specified threshold, the timestamp of the refresher 123 may be decreased. The mean square error (MSE) may be calculated using the difference value entry in LT 127.

13 is a block diagram showing a manufacturing industry use case, according to some embodiments. In this manufacturing industry use case scenario, equipment sensor data, along with other data (generating up to 60 TB per year), is processed into a processing super-cluster called a data lake. Can be processed simultaneously by super-cluster). Use of the proposed mechanism can mitigate degradation of reliability (and extended downtime) during hardware/software upgrades and during the addition of new systems (or tasks). The upgrade will be performed optimally and therefore smoothly.

Unlike conventional systems and methods, the proposed system and method can be proposed as part of a fabrication application writing standard according to the Industry 4.0 initiative. Unlike conventional systems and methods, the proposed system can play a very important role in creating the IT infrastructure backbone required to analyze the huge data generated during chip manufacturing operations, and the analyzed results can be used to analyze the huge data generated during chip manufacturing operations. It can be used to directly maximize production.

In the case of the manufacturing industry after fabrication sizes change from 14nm to 10nm and beyond, the total amount of data generated can increase exponentially, requiring huge processing clusters to analyze the data. The small amount of energy saved in the process can provide huge benefits to the entire production line by lowering operating costs. The proposed system and method can play a very important role in energy savings in processing clusters in the manufacturing industry.

In conventional systems and methods, hardware upgrades for an existing software layer can create an unsynchronized solution due to the strong coupling of application processes and optimization processes with hardware. However, because the proposed system and method can separate the optimization process and the application process, the cost of hardware upgrades can be much lower compared to conventional upgrade mechanisms.

FIG. 14 is a flowchart 1400 showing a real-time operating system (RTOS) of the distributed heterogeneous computer system 300, according to some embodiments.

At operation 1402, the method may include receiving an input critical process/task including a critical time (T _c ) for completion. The method may allow AI 112 to receive an incoming critical process/task including a critical time (T _c ) for completion.

At operation 1404, the method may include transmitting an incoming threshold process request to the query interface 126. The method may cause the AI 112 to transmit an incoming critical process request to the query interface 126.

At operation 1406, the method may include responding with an expected time (T _Reply ) to complete the input critical process. The method may allow the query interface 126 to respond with an estimated time (T _Reply ) to complete the input critical process.

At operation 1408, the method may include checking whether the threshold time is less than the expected time for completion. The method may have AI 112 check whether the threshold time is less than the expected time for completion. If the AI 112 determines that T _c < T _Reply , the AI 112 rejects the task launch in operation 1410. Otherwise, in operation 1412, the AI 112 rejects the task launch. can be accepted.

Real-time operating systems are one of the use-cases that can support the proposed method. In the manufacturing industry, there may be some time-critical tasks (eg, scheduling) that require a real-time operating system. Currently, devices (EQs) that perform their tasks may rely on special drive systems that utilize real-time drive systems. This can result in the division of the EQ into two groups, one that can operate in a real-time drive system and the other in a normal drive system. Application developers may need to design software separately for both operating systems. However, the proposed method can inherently provide application developers with the benefits of using Soft-RTOS such as constraints while developing applications. When the AI 112 inquires about the data distribution vector for the task, the data distribution vector may include the expected completion time. Using these expected completion times, application developers can decide whether or not to schedule critical tasks. Enabling decisions on the application side is called Soft-RTOS, such as constraints.

The proposed method and system can help achieve Soft-RTOS on heterogeneous computer nodes (100). Data distribution vectors can be computed for the task indicating running in an optimized manner that takes into account all system parameters. Therefore, depending on the time constraints and data load provided by the task in a real-time operating system scenario, the proposed method and system can determine whether the task will be performed within the expected time or not.

Computational needs are increasing due to the popularity of hardware-free test bed simulators. Huge servers are sometimes required to simulate real hardware and enable hardware-intended software development. In these kinds of scenarios, the proposed method can be easily scaled up, save energy, and improve reliability.

Currently, there is no operating system that provides optimized data distribution for tasks between heterogeneous computer nodes 100. The proposed method can be created as part of a driving system so that data distribution for tasks between heterogeneous computer nodes 100 can be smoothly distributed. This can help save battery energy, increase device reliability, and enable optimal use of different computer nodes 100.

Figure 15 shows a computing environment 1502 applying a distributed heterogeneous computer system and method for dynamically reallocating resources for optimized job performance, according to some embodiments. As shown in FIG. 15 , the computing environment 1502 includes at least one processing unit 1504 equipped with a control unit 1506 and an arithmetic processing unit (ALU) 1508, a memory 1510, and a storage unit 1512. ), a plurality of networking devices 1516, and a plurality of input/output (I/O) devices 1514.

Processing unit 1504 can process instructions of the proposed method. Processing unit 1504 may receive commands from the control unit and perform processing thereof. Additionally, arithmetic operations included in the execution of instructions may be computed with the help of the ALU 1508.

Storage unit 1512 may include one or more computer-readable storage media. Storage unit 1512 may include non-volatile storage components. Examples of such non-volatile storage components include magnetic hard disks, optical disks, floppy disks, flash memories, electrically programmable memories (e.g., EPROM), and/or electrically erasable and programmable memory. There may be EEPROM. Additionally, in some examples, storage unit 1512 may be considered a non-transitory storage medium. The term “non-transitory” may indicate that the storage medium is not embodied in a carrier wave or propagated signal. However, the term “non-transitory” should not be interpreted to mean that the storage unit 1512 cannot be moved. In some examples, storage unit 1512 may be configured to store more information than memory. In some examples, a non-transitory storage medium may store data that may change over time (e.g., data in random access memory (RAM) or cache memory).

Embodiments described in the text may be implemented through at least one software program that runs on at least one hardware device and controls components by performing network management functions. 1 to 15 may include blocks that may be at least one of hardware devices or a combination of hardware devices and software modules.

The above descriptions of specific embodiments can present the general content of the technical idea as a whole so that those skilled in the art can adapt and modify the specific embodiments for various applications without departing from the general idea by applying current knowledge. Therefore, these applications and modifications are to be considered to be understood within the spirit and meaning of equivalents of the described embodiments. It will be understood that the terms or phraseology used in the text are for explanatory purposes and are not limiting. Therefore, although the embodiments are described in terms of specific embodiments, those skilled in the art will recognize that the embodiments may be implemented with modifications within the spirit and scope of the embodiments described in the text.

Claims (20)

In a distributed heterogeneous computer system,
comprising a plurality of computer nodes,
Each of the plurality of computer nodes is functionally connected to a network through a network interface to provide data communication between the plurality of computer nodes,
Each of the plurality of computer nodes:
application layer;
an optimization layer separate from the application layer; and
Comprising one or more processors configured to perform operations of the application layer and the optimization layer,
The application layer is:
an application injector configured to invoke at least one job to be performed; and
An application-specific configuration configured to share a task type of the at least one job indicating whether the at least one job is normal or critical and a data load for the at least one job with the application injector,
The optimization layer is:
a collector configured to dynamically collect a workload value that is a function of at least one of a data performance metric, a reliability metric, an additive factor, and a data distribution ratio for each of the plurality of computer nodes;
a job informer configured to determine respective types of known jobs and unknown jobs for each of the plurality of computer nodes;
Based on the workload value and the respective types of the known jobs and the unknown jobs for each of the plurality of computer nodes, the data to be distributed to the plurality of computer nodes to perform the at least one job a job optimizer configured to determine a data distribution vector defining each size of load;
a lookup table configured to store the data distribution vector; and
a lookup table manager configured to maintain the lookup table and provide a query interface to the application injector;
The application injector transmits a query for the task identifier of the at least one job to the lookup table manager through the query interface, receives the data distribution vector from the lookup table manager through the query interface, and operates the data distribution. further configured to schedule the at least one job based on a vector,
the lookup table manager is further configured to transmit the data distribution vector from the lookup table to the application injector in response to the query,
The application injector is further configured to return a consumption time difference per byte to the lookup table management after scheduling the at least one job based on the data distribution vector,
The lookup table manager is further configured to update the difference entry in the lookup table if the returned time difference is greater than the current value of the difference entry in the lookup table.
According to claim 1,
The job informer is further configured to perform automatic analysis of the unknown jobs in response to the lookup table manager.
According to claim 1,
The optimization layer is
It further includes a refresher configured to dynamically determine a time interval for managing the performance of the at least one job in each of the plurality of computer nodes using the difference between the expected time of running the at least one job and the actual time. A distributed heterogeneous computer system.
According to claim 1,
A distributed heterogeneous computer system wherein the data distribution vector is determined using at least one of a linear optimization model and a non-linear optimization model.
According to claim 1,
A distributed heterogeneous computer system wherein the application injector acts as a connector between the application specific configuration and the optimization layer.
In a distributed heterogeneous computer system,
comprising a plurality of computer nodes,
Each of the plurality of computer nodes is functionally connected to a network through a network interface to provide data communication between the plurality of computer nodes,
Each of the plurality of computer nodes:
application layer;
an optimization layer separate from the application layer; and
Comprising one or more processors configured to perform operations of the application layer and the optimization layer,
The application layer is:
an application injector configured to invoke at least one job to be performed; and
An application-specific configuration configured to share a task type of the at least one job indicating whether the at least one job is normal or critical and a data load for the at least one job with the application injector,
The optimization layer is:
a collector configured to dynamically collect a workload value that is a function of at least one of a data performance metric, a reliability metric, an additive factor, and a data distribution ratio for each of the plurality of computer nodes;
a job informer configured to determine respective types of known jobs and unknown jobs for each of the plurality of computer nodes;
Based on the workload value and the respective types of the known jobs and the unknown jobs for each of the plurality of computer nodes, the data to be distributed to the plurality of computer nodes to perform the at least one job a job optimizer configured to determine a data distribution vector defining each size of load;
a lookup table configured to store the data distribution vector; and
a lookup table manager configured to maintain the lookup table and provide a query interface to the application injector;
The application injector transmits a query for the task identifier of the at least one job to the lookup table manager through the query interface, receives the data distribution vector from the lookup table manager through the query interface, and operates the data distribution. further configured to schedule the at least one job based on a vector,
the application injector is further configured to receive a request for the critical task along with a critical time to complete the critical task, and transmit the request for the critical task to the query interface,
The query interface is configured to respond to the application injector with an estimated time for the critical task.
According to claim 6,
The application injector:
determine whether the critical time is less than the expected time;
if the critical time is less than the expected time, reject task launch for the critical task;
If the critical time is not less than the expected time, the distributed heterogeneous computer system is further configured to accommodate the task launch for the critical task.
According to claim 6,
A distributed heterogeneous computer system wherein the data distribution vector is determined using at least one of a linear optimization model and a non-linear optimization model.
According to claim 6,
The optimization layer is
It further includes a refresher configured to dynamically determine a time interval for managing the performance of the at least one job in each of the plurality of computer nodes using the difference between the expected time of running the at least one job and the actual time. A distributed heterogeneous computer system.
According to claim 6,
A distributed heterogeneous computer system wherein the application injector acts as a connector between the application specific configuration and the optimization layer.


delete delete delete delete delete delete delete delete delete delete

Images