Performance tuning method, electronic device and storage medium for cluster operating system
By reasonably planning the allocation of performance acquisition tasks and equipment performance analysis in a super-large-scale cluster operating system, the problem of monitoring data processing delay is solved, real-time monitoring and equipment performance tuning is achieved, and the overall performance and resource utilization of the system are improved.
Patent Information
- Application Number
- CN202510734657.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-04
- Publication Date
- 2025-08-15
- Estimated Expiration
- 2045-06-04
AI Technical Summary
In the super-large-scale cluster operating system, the management cluster causes the computing resources and network bandwidth to be double-squeeze when processing massive monitoring data, resulting in untimely performance monitoring, affecting operation and maintenance efficiency and effect, especially in the scenario of sudden load surges.
By obtaining the collection task set, simulate the allocation to the management terminal, predict the execution time and completion time of the performance acquisition task, and reasonably plan the task allocation and analyze the performance status of the equipment for tuning based on the simulation allocation strategy of iterative optimization.
Real-time processing and decision-making response to monitoring data flow is realized, the allocation efficiency and accuracy of performance acquisition tasks are improved, task waiting time is reduced, and equipment operation efficiency and stability are improved.
Smart Images

Figure CN120276865B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data processing technology, and in particular to a performance tuning method, electronic device, and storage medium for a cluster operating system. Background Art
[0002] In recent years, with the rapid development of cloud computing and distributed system architectures, large-scale server clusters have become widely used in key areas such as data centers, financial trading platforms, and the Internet of Things. To ensure stable system operation, performance tuning systems for modern cluster operating systems require full-stack performance monitoring of underlying hardware resources (including CPU, memory, disk arrays, and network devices), operating system status, and upper-layer service components (such as database systems and distributed storage systems like Ceph). Traditional architectures typically adopt a centralized management model, with a single management cluster responsible for collecting multi-dimensional metrics (covering real-time indicators such as CPU utilization, memory page fault rate, disk IOPS, and network packet loss rate), synchronizing software and hardware configuration information, and handling exception alerts.
[0003] However, with the exponential growth of cluster size and the increasing sophistication of monitoring metrics (for example, Ceph storage clusters must simultaneously monitor dozens of sub-metrics, including OSD status, PG distribution, and RADOS layer latency), existing technologies have exposed serious architectural flaws. While managing core responsibilities such as routine task scheduling and resource allocation, the management cluster also needs to process and analyze massive amounts of monitoring data in real time, which doubles up on both computing resources and network bandwidth. Especially in scenarios with sudden load surges (such as a surge in distributed transactions leading to cascading monitoring alarms), the management node's processing delay for monitoring data can exceed the metric collection interval, resulting in a persistent data lag. This results in inadequate and untimely cluster performance monitoring, impacting the efficiency and effectiveness of the cluster operating system's operations.
[0004] Therefore, there is an urgent need to develop a method that can promptly realize real-time processing and decision-making response of monitoring data streams in ultra-large-scale cluster operating systems, so as to timely improve the overall performance and resource utilization of the system. Summary of the Invention
[0005] The purpose of this application is to provide a performance tuning method, electronic device and storage medium for a cluster operating system to solve the above problems.
[0006] To achieve the above objectives, in a first aspect, the present application proposes a performance tuning method for a cluster operating system, the method comprising:
[0007] Get a collection task set, the collection task set is a set formed by periodic task subsets for N collection devices deployed with a cluster operating system, the i-th task subset in the collection task set is the i-th task subset. The performance collection task is the jth performance collection task for the i-th collected device;
[0008] Simulate the allocation of the collection task set to M management terminals, and predict the simulated execution time and simulated completion time of each performance collection task based on the task generation time and simulation allocation result of each performance collection task;
[0009] Iteratively optimize the simulation allocation strategy based on the execution cycle, task generation time, simulation execution time, and simulation completion time of each performance collection task, and allocate performance collection tasks according to the optimized task simulation allocation strategy;
[0010] Based on the performance indicator data obtained by each management terminal executing the assigned performance collection task, the device performance status of each collected device is analyzed, and the performance of the collected device is optimized according to the device performance status.
[0011] In some embodiments, iteratively optimizing the simulation allocation strategy based on the execution cycle, task generation time, simulation execution time, and simulation completion time of each performance collection task, and allocating the performance collection tasks according to the optimized task simulation allocation strategy, includes:
[0012] Calculate the task completion time and task execution time of the performance collection task corresponding to the task according to the task generation time, simulation execution time and simulation completion time of each performance collection task;
[0013] The performance collection task whose task completion time and / or task execution time exceeds the corresponding execution cycle is treated as a task to be called out, and the task to be called out is assigned to one of the terminals to be transferred in. The terminal to be transferred in is a management terminal among the M management terminals, excluding the terminal to be scheduled that simulates the execution of the task to be called out under the current simulation allocation strategy.
[0014] In some implementations, allocating the task to be transferred out to one of the terminals to be transferred in includes:
[0015] Calculate the comprehensive turnover rate corresponding to the entire collection task set when each terminal to be transferred in simulates executing the task to be transferred out. The comprehensive turnover rate is the weighted sum of the individual turnover rates of each performance collection task. The individual turnover rate is the quotient of the task completion time and the task execution time of the corresponding performance collection task.
[0016] The terminal to be transferred in, corresponding to the simulated allocation strategy with the smallest comprehensive turnover, is used as the target transfer-in terminal, and the task to be transferred out is allocated to the target transfer-in terminal.
[0017] In some implementations, allocating the task to be transferred out to one of the terminals to be transferred in includes:
[0018] Calculate the comprehensive turnover corresponding to the entire collection task set when each terminal to be transferred simulates the execution of the task to be transferred out and the associated tasks. The comprehensive turnover is the weighted sum of the individual turnovers of each performance collection task. The individual turnover is the quotient of the task completion time and the task execution time of the corresponding performance collection task. The associated tasks are performance collection tasks that belong to the same task subset as the task to be transferred out.
[0019] The terminal to be transferred in, corresponding to the simulated allocation strategy with the smallest comprehensive turnover, is used as the target transfer-in terminal, and the tasks to be transferred out and the associated tasks are allocated to the target transfer-in terminal.
[0020] In some implementations, allocating the task to be transferred out to one of the terminals to be transferred in includes:
[0021] Determine a target transfer-in terminal from a plurality of terminals to be transferred-in, and calculate a first execution integrated duration change and a second execution integrated duration change of the target transfer-in terminal respectively;
[0022] When the second execution integrated duration change is greater than the first execution integrated duration change, only the to-be-called task is assigned to the target transfer-in terminal;
[0023] When the second comprehensive execution duration change is less than or equal to the first comprehensive execution duration change, allocating both the task to be transferred out and an associated task to the target transfer-in terminal, where the associated task is a performance collection task that belongs to the same task subset as the task to be transferred out;
[0024] The first comprehensive execution duration change is the weighted cumulative increase in the simulated execution duration of the originally assigned performance collection task of the target transfer-in terminal after only the task to be transferred out is added;
[0025] The second comprehensive execution duration change is the cumulative increase in the simulated execution duration of the originally allocated performance collection task after the target transfer-in terminal adds the task to be transferred out and the associated task.
[0026] In some embodiments, iteratively optimizing the simulation allocation strategy based on the execution cycle, task generation time, simulation execution time, and simulation completion time of each performance collection task, and allocating the performance collection tasks according to the optimized task simulation allocation strategy, includes:
[0027] Calculate the task completion time and task execution time of the performance collection task corresponding to the task according to the task generation time, simulation execution time and simulation completion time of each performance collection task;
[0028] The performance collection tasks whose task completion time and / or task execution time exceeds the corresponding execution cycle are treated as tasks to be called out;
[0029] Calculate the influence of each performance collection task simulated and executed by the terminal to be scheduled on the tasks to be transferred out, and select a preset number of performance collection tasks with the highest influence as the tasks to be transferred out;
[0030] The task to be transferred out is assigned to one of the terminals to be transferred in, where the terminal to be transferred in is a management terminal among the M management terminals excluding the terminal to be scheduled that simulates executing the task to be transferred out under the current simulation allocation strategy.
[0031] In some implementations, the performing performance tuning on the collected device according to the device performance status includes:
[0032] Determine the collected devices with abnormal performance status as devices to be processed;
[0033] Acquiring task execution information of the device to be processed, and filtering out tasks corresponding to the abnormal type of the device performance status from the task execution information as tasks to be processed;
[0034] The performance of the device to be processed is optimized according to several resource requirement combinations of the task to be processed.
[0035] In some implementations, the performance tuning of the device to be processed according to several resource requirement combinations of the task to be processed includes:
[0036] Determining whether the performance indicator data associated with the device to be processed meets at least one of the several resource requirement combinations;
[0037] If so, reallocating resources of the device to be processed for the task to be processed based on the satisfied resource requirement combination;
[0038] If not, a collected device that meets at least one resource requirement combination is determined as a backup device based on the performance indicator data of other collected devices, so as to transfer the to-be-processed task to the backup device.
[0039] In a second aspect, the present application provides an electronic device, comprising:
[0040] one or more processors;
[0041] a memory for storing one or more programs,
[0042] When the one or more programs are executed by the one or more processors, the one or more processors are enabled to execute the performance tuning method of the cluster operating system as described above.
[0043] In a third aspect, the present application proposes a storage medium storing executable instructions, which, when executed by a processor, causes the processor to execute the performance tuning method for a cluster operating system as described above.
[0044] Compared with the prior art, the advantages of this application include:
[0045] First, by acquiring a collection task set formed from a subset of periodic tasks for the devices being collected and simulating their assignment to management terminals, the simulated execution and completion times of each performance collection task can be predicted in advance. This helps rationally plan the allocation of performance collection tasks, avoiding problems such as task backlogs, data lags, and untimely performance monitoring, thereby improving the efficiency and accuracy of performance collection task assignment. Second, by iteratively optimizing the simulated assignment strategy, the task assignment strategy can be continuously adjusted to better adapt to the actual operating environment, reducing task wait times and execution times, and improving the overall performance of the management terminal cluster. Third, by analyzing the performance indicator data obtained from each management terminal executing the assigned performance collection task, the performance status of each device being collected can be accurately assessed. Based on this detailed performance status data, targeted performance tuning can be performed on the collected devices, improving their operational efficiency and stability. BRIEF DESCRIPTION OF THE DRAWINGS
[0046] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope of the present application.
[0047] Figure 1 This is a diagram of an application scenario of a performance tuning method for a cluster operating system in one embodiment;
[0048] Figure 2 A system architecture diagram of a performance tuning method for a cluster operating system in one embodiment;
[0049] Figure 3 A schematic flow chart of a method for optimizing the performance of a cluster operating system according to an embodiment;
[0050] Figure 4A flowchart illustrating an embodiment of iteratively optimizing a simulation allocation strategy based on the execution cycle, task generation time, simulation execution time, and simulation completion time of each performance collection task, and allocating performance collection tasks according to the optimized task simulation allocation strategy;
[0051] Figure 5 A flowchart illustrating another embodiment of iteratively optimizing a simulation allocation strategy based on the execution cycle, task generation time, simulation execution time, and simulation completion time of each performance collection task, and allocating performance collection tasks according to the optimized task simulation allocation strategy;
[0052] Figure 6 Schematic diagram of the structure of the electronic device involved in the performance tuning method of the cluster operating system in the embodiment of the present application. DETAILED DESCRIPTION
[0053] In order to make the purpose, technical solutions and advantages of this application more clearly understood, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.
[0054] All terms (including technical and scientific terms) used in this application have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.
[0055] For example, the terms "first", "second", etc. used in this application may be used in this article to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish a first element from another element. For example, without departing from the scope of this application, the first execution integrated duration can be referred to as the second execution integrated duration, and similarly, the second execution integrated duration can be referred to as the first execution integrated duration. Both the first execution integrated duration and the second execution integrated duration are execution integrated durations, but they are not the same execution integrated duration.
[0056] For example, the terms "include", "comprising", etc. used in this application indicate the existence of features, steps, operations and / or components, but do not exclude the existence or addition of one or more other features, steps, operations or components.
[0057] As mentioned above, while the management cluster (e.g., M management terminals) undertakes core responsibilities such as scheduling and resource allocation for routine tasks (e.g., performance collection tasks for N collected devices), it also needs to process real-time aggregation and analysis of massive amounts of monitoring data, resulting in its computing resources and network bandwidth being double-crowded. Especially in scenarios with sudden load surges (such as chain monitoring alarms caused by a surge in distributed transactions), the processing delay of performance collection data by a certain management terminal in the management cluster will exceed the indicator collection interval period, forming a continuous data lag effect, resulting in insufficient timeliness in performance monitoring of the collected devices in the cluster, affecting the operation and maintenance efficiency and effectiveness of the cluster operating system. Therefore, there is an urgent need to develop a method that can timely realize real-time processing and decision-making response for monitoring data streams in ultra-large-scale cluster operating systems, so as to timely improve the overall performance and resource utilization of the system. To this end, the present application proposes a performance tuning method, electronic device, and storage medium for a cluster operating system, which can timely realize real-time processing and decision-making response for monitoring data streams in ultra-large-scale cluster operating systems.
[0058] The performance tuning method of the cluster operating system in this application can be applied to Figure 1 In the application scenario shown, combined with Figure 1 and Figure 2 As shown, the cluster operating system environment includes M cluster devices (i.e., a cluster of collected devices) and N management terminals (i.e., a cluster of management terminals), namely cluster device 1 (i.e., collected device 1), cluster device 2 (i.e., collected device 2), ..., cluster device N (i.e., collected device N), management terminals 1, management terminal 2, ..., management terminal M. Each cluster device / collected device functions as a device node, and each management terminal functions as a management node. Each collected device and each management terminal is deployed with the cluster operating system. The M management terminals monitor the performance of these N collected devices through the deployed cluster operating system, collecting performance metrics of each collected device in real time at a preset frequency. These performance metrics may include one or more of CPU utilization, I / O interface read / write speed, memory usage, network bandwidth and latency, disk usage, number of concurrent users, throughput, and response time (RT). As will be appreciated, N is typically much larger than M.
[0059] Each service probe (agent, e.g., Service Probe 1 through Service Probe N) in the service probe layer is deployed on each device node in the cluster operating system. It collects real-time performance data from the device nodes and transmits the data via a distributed message queue. The middleware and storage layer stores this received performance data and may include one or more components such as MySQL, Redis, and OSS cloud storage. For example, RabbitMQ message queues may be used for asynchronous processing, and Redis may be used for data caching. Operations and maintenance personnel can access various management terminals and visual web applications through the front-end presentation layer (e.g., an app and / or web browser) to perform configuration management, data collection and analysis, and issue tuning instructions. The NGINX service in the gateway layer primarily implements load balancing for management terminals, distributing requests from the front-end to management nodes. The cluster operating system deployed in each node can be a domestically produced cluster operating system, such as the Kylin operating system. The collected devices can be servers, databases, and other related equipment.
[0060] In one embodiment, Figure 1 and Figure 2 、 Figure 3 As shown, the embodiment of the present application proposes a performance tuning method for a cluster operating system, which can be applied to Figure 1 The scenario shown includes the following steps:
[0061] Step S10: Obtain a collection task set.
[0062] In this embodiment, the collection task set is a set formed by periodic task subsets of N collection devices deployed with the cluster operating system. The first task in the subset The performance collection task is for The first device to be collected A performance collection task.
[0063] Specifically, the relevant operation and maintenance personnel can log in to the web management terminal and configure the device information (such as server information and / or database information) of the collected devices to be monitored on the configuration management page of the management terminal. In the relevant collected device information table, record the IP address and port information of the collected server, and the IP address, port, username, password, database name, etc. of the collected database to be monitored.
[0064] Configure the performance metrics to be collected, such as one or more metrics including CPU performance, memory performance, disk performance, network performance, software and hardware information, databases, and distributed storage (CEPH). Also configure the frequency for collecting each performance metric. The collection frequency (collection period) for each performance metric can be the same or different, and the frequency (collection period) for the same performance metric can also be the same or different for different devices being collected. Provide a task record table that records information such as the performance metrics to be collected and the frequency of collection. Based on the configuration information in the device information table and the task record table, the system's task generator generates a list of pending tasks. This list represents the aforementioned collection task set.
[0065] It can be understood that each task in the collection task set is a task that needs to be repeatedly executed in real time periodically. All performance collection tasks for the same collected device constitute the task subset of the collected device. i , for the collected device S i The jth performance collection task is performance collection task d ij , i=1,2,……N, record the collected device S i The total number of performance collection tasks (i.e., the number of devices being collected S i Corresponding performance collection task subset D i The total number of performance collection tasks in a i , the total number of performance collection tasks in the collection task set It is understandable that the task subsets corresponding to different collected devices can be the same or different, and the total number of a i They may be the same or different.
[0066] In some embodiments, the monitoring requirements of each collected device for performance indicators are obtained, and periodic performance collection tasks are formulated based on the monitoring requirements. The performance collection tasks are not limited to the collection and processing of key performance indicators such as CPU usage, memory occupancy, disk I / O, and network traffic. The periodic task subsets of all collected devices are integrated to form a collection task set. Each task subset contains multiple performance collection tasks for a specific collected device, and each performance collection task has a clear execution cycle and task generation time. The task generation time is determined according to the collection frequency (collection cycle) of the configured performance collection task. For example, for a performance collection task with a certain CPU occupancy, the collection frequency is set to collect once every 10 seconds. The task generation time of the performance collection task can be 14:59:00, 14:59:10, 14:59:20, 14:59:30, 14:59:40, etc.
[0067] Understandably, the performance collection tasks within a collection task set change dynamically as the operating status and performance metrics of the device cluster being collected change. By constructing a collection task set, we ensure the integrity and periodicity of performance data, providing accurate data support for performance tuning.
[0068] Step S20: simulate the allocation of the collection task set to M management terminals, and predict the simulated execution time and simulated completion time of each performance collection task based on the task generation time and simulation allocation result of each performance collection task.
[0069] In this implementation, the management terminal is the entity responsible for executing the performance collection task, which can be a physical server, virtual machine, or other computing unit. The simulation execution moment refers to the time point when the management terminal is predicted to start executing a certain performance collection task during the simulation allocation phase. The simulation completion moment refers to the time point when the management terminal is predicted to complete executing a certain performance collection task during the simulation allocation phase. The management terminal can periodically execute the assigned performance collection task until it receives a stop execution instruction for the performance collection task.
[0070] Because the tasks in the collection task set are fixed and the resource pools of each management terminal are known, the management terminal's execution status (including the execution time, completion time, execution duration, and completion duration) for each performance collection task under different performance states (management terminal resource pool, assigned performance collection tasks) can be predicted based on the management terminal's historical execution results for each performance collection task. The system's cluster monitor defines an environment to simulate task scheduling scenarios for a task subset, including the aforementioned D tasks and the status information of M management terminals. Based on this, a simulated allocation strategy for the task subset is formed. This simulated allocation strategy defines the performance collection tasks assigned to each management terminal and the execution order of each performance collection task.
[0071] In some implementations, a task allocation model is established based on the task attributes of each performance collection task (generation time, execution cycle, CPU / memory / I / O resource requirements) and the resource pool of the management terminal (computing power benchmark, concurrency capacity, and real-time load status). For example, this task allocation model is a deep reinforcement learning model, and the mapping relationship between each performance collection task and the resource pool of the management terminal is determined based on the deep reinforcement learning model. A discrete timeline simulation engine dynamically triggers an initial allocation decision based on the task generation time of each performance collection task. Based on this initial allocation decision, a subset of tasks in the collection task set is allocated to M management terminals, generating a simulated allocation result. The initial allocation decision can be based on principles such as round-robin, load balancing, and performance optimization.
[0072] In some embodiments, the simulation execution time is determined based on the position of each performance collection task in the task queue of the assigned management terminal (the execution order of the performance collection tasks). The simulation completion time is determined based on the simulation execution time and the benchmark execution time of each performance collection task. In particular, each performance collection task is in a dynamically changing state in the corresponding task queue. For example, at a certain moment, the performance collection task d ij At the head of the task queue, after completing the performance collection task d ij After the execution of the performance collection task d ij In frozen state. Based on this performance collection task d ij The collection cycle, when the performance collection task d ij , the next task generation time, the performance collection task d ij is activated and the performance collection task d is generated again ij , at this time the performance collection task d ij At the end of the task queue.
[0073] In some embodiments, the simulation completion time is determined based on the simulated execution time, benchmark execution time, and dynamic correction factors (such as CPU preemption delay and I / O bandwidth competition coefficient) of each performance collection task, where the dynamic correction factors can be predicted based on the historical execution data of the management terminal and the performance model of the management terminal.
[0074] Step S30 , iteratively optimizing the simulation allocation strategy based on the execution cycle, task generation time, simulation execution time, and simulation completion time of each performance collection task, and allocating the performance collection tasks according to the optimized task simulation allocation strategy.
[0075] In this embodiment, the system predicts the simulated execution and completion times for each management terminal's assigned performance collection tasks under various simulation allocation strategies. Based on the execution cycle, task generation time, simulated execution time, and simulation completion time, the system calculates the execution efficiency for the task set. Based on this efficiency, it calculates the loss function for the corresponding task allocation model, adjusts the parameters in the task allocation model, and optimizes the task allocation model and simulation allocation strategy.
[0076] By iteratively optimizing the simulation allocation strategy, we can continuously adjust the task allocation and timely realize the real-time processing and decision-making response of the performance collection data stream of the ultra-large-scale cluster of collected equipment.
[0077] After completing the iterative optimization of the simulation allocation strategy, each performance collection task in the collection task set may be allocated to the M management terminals according to the final optimized simulation allocation strategy, so that each management terminal executes the allocated performance collection task.
[0078] Step S40 , based on the performance indicator data obtained by each management terminal executing the assigned performance collection task, analyze the device performance status of each collected device, and perform performance tuning on the collected device according to the device performance status.
[0079] In this embodiment, performance indicator data refers to the data obtained after the management terminal executes a performance collection task, including CPU usage, memory utilization, disk I / O, network traffic, and other information. Device performance status refers to the performance status of the collected device, derived from a comprehensive analysis of the performance indicator data. This data may include the device's computing power, storage resources, network bandwidth, and other information. By executing the assigned performance collection task, the management terminal can obtain the performance indicator data for the corresponding collected device, such as determining that the CPU utilization of a particular collected device is 88%.
[0080] By analyzing the performance status of each collected device, it is possible to identify whether the corresponding collected device has reached a performance bottleneck. When the performance bottleneck is reached, the tasks being executed in the collected device can be migrated, such as migrating the collected device S that is in the performance bottleneck to i A computing task in the process is migrated to the collected device S j , collected by the device S j Processing is performed to achieve performance tuning for the collected equipment, thereby improving the overall performance of the cluster operating system.
[0081] In one embodiment, Figure 4 As shown, step S30 includes:
[0082] Step A10 , calculating the task completion duration and task execution duration of the performance collection task corresponding to the task according to the task generation time, simulation execution time and simulation completion time of each performance collection task.
[0083] In this embodiment, task completion duration T1 refers to the time interval from task creation time T0 to simulation completion time Tb, reflecting the total time required for the performance collection task from creation to completion. Task execution duration T2 refers to the time interval from simulation execution time Ta to simulation completion time Tb, reflecting the actual execution time of the performance collection task on the management terminal. Specifically, T1 = Tb - T0; T2 = Tb - Ta.
[0084] By calculating the task completion time and task execution time, we can quantify the performance of the performance acquisition task in the time dimension, providing data support for the subsequent identification of tasks to be called out.
[0085] Step A20 : The performance collection task whose task completion time and / or task execution time exceeds the corresponding execution cycle is regarded as a task to be transferred out, and the task to be transferred out is allocated to one of the terminals to be transferred in.
[0086] In this embodiment, the terminal to be transferred to is the management terminal among the M management terminals, excluding the terminal to be scheduled that simulates the execution of the task to be transferred out under the current simulation allocation strategy.
[0087] The execution cycle Tf refers to the periodic interval of the performance collection task, that is, the time interval between two consecutive times when the task is generated. For example, a performance collection task is generated every 10 seconds, and its execution cycle is 10 seconds. Tasks to be transferred out refer to performance collection tasks whose task completion time and / or task execution time exceeds the corresponding execution cycle, indicating that these tasks may be delayed or inefficient under the current allocation strategy. That is, performance collection tasks with T1>Tf and / or T2>Tf are tasks to be transferred out. (Simulation) The management terminal that executes the task to be transferred out is the terminal to be scheduled. Among the M management terminals, the other management terminals except the terminal to be scheduled are the terminals to be transferred in.
[0088] Optionally, a target transfer-in terminal may be selected from multiple transfer-in terminals, and the transfer-out task may be assigned to the target transfer-in terminal. Specifically, the target transfer-in terminal may be selected based on one or more factors, such as the load level, resource abundance, and overall turnover rate of each transfer-in terminal. For example, the transfer-in terminal with the lightest load, the most abundant resources, or the lowest overall turnover rate of the simulated transfer may be selected as the target transfer-in terminal.
[0089] As an optional implementation method for assigning the task to be transferred out to one of the terminals to be transferred in, the comprehensive turnover corresponding to the entire collection task set is calculated when each terminal to be transferred in simulates the execution of the task to be transferred out. The comprehensive turnover takes the terminal to be transferred in corresponding to the simulated allocation strategy with the smallest comprehensive turnover as the target transfer-in terminal, and assigns the task to be transferred out to the target transfer-in terminal.
[0090] By calculating the comprehensive turnover rate, we can quantify the efficiency of different management terminals in simulating the execution of tasks to be transferred out, and provide a basis for selecting the optimal target transfer terminal.
[0091] Among them, turnover is used to measure the completion efficiency of the task, which is related to the task completion time and task execution time. The single turnover y is used to measure the completion efficiency of a single task, and the comprehensive turnover Y is used to measure the task completion efficiency of the entire collection task set. It can be the weighted sum of the single turnovers of all performance collection tasks, that is, for each performance collection task in the collection task set, each performance collection task is completed once, and the weighted sum of the single turnovers of each performance collection task is obtained. Among them, single turnover = task completion time / task execution time, that is, y = T1 / T2. Let the performance collection task d ij The single turnover degree is y ij , the comprehensive turnover Y is:
[0092] .
[0093] For the The weight of the performance collection task. Optionally, the weight of each performance collection task can be set to 1, or different weights can be set according to the priorities of different performance collection tasks.
[0094] Optionally, the comprehensive turnover can be used as the loss function of the corresponding task allocation model, or based on the comprehensive turnover as a part of the loss function of the task allocation model, the task allocation model can be iteratively optimized, thereby iteratively optimizing the simulation allocation strategy.
[0095] This task allocation model can be a deep reinforcement learning model, consisting of two neural networks: an actor network and a critic network. The actor network is responsible for selecting a simulated task allocation strategy for performance collection tasks to management terminals, while the critic network is responsible for evaluating the state value of the current simulated task allocation strategy. Before iterating the model and optimizing the simulated task allocation strategy, network parameters, including the learning rate and discount factor, are initialized. By interacting with the environment, experience with states, actions, rewards, and next states is collected. This collected experience is used to update the parameters of the actor and critic networks. The deep reinforcement learning model is then iteratively optimized based on the calculated comprehensive turnover Y, ultimately resulting in an optimized task allocation strategy.
[0096] As another optional implementation method for assigning the task to be transferred out to one of the terminals to be transferred in, the comprehensive turnover corresponding to the entire collection task set is calculated when each terminal to be transferred in simulates the execution of the task to be transferred out and the associated tasks. The terminal to be transferred in corresponding to the simulated allocation strategy with the smallest comprehensive turnover is used as the target transfer-in terminal, and the task to be transferred out and the associated tasks are assigned to the target transfer-in terminal.
[0097] Among them, the associated task is the performance collection task that belongs to the same task subset as the task to be called out, that is, the performance collection task d ij and performance collection tasks d ik Belong to the same task subset, when the performance collection task d ij When the task is to be called out, the performance collection task d ik For this performance collection task d ij Since the performance collection task and its associated tasks are all periodic collection tasks for the same collected device, if the performance collection task and its associated tasks are distributed to multiple management terminals for execution, it is easy to cause task allocation confusion. Therefore, here, all performance collection tasks belonging to the same task subset can be transferred out at the same time to avoid multiple management terminals collecting data from the same collected device at the same time, which consumes too many scheduling resources.
[0098] For example, assume there is a device being collected data, whose task subset includes three performance collection tasks: Task A, Task B, and Task C. Task A is the task to be transferred. Tasks B and C are associated with Task A. Task A has a completion time of 15 seconds and a task execution time of 10 seconds, with a single turnover of 15 / 10 = 1.5. Task B has a completion time of 20 seconds and a task execution time of 10 seconds, with a single turnover of 20 / 10 = 2.0. Task C has a completion time of 25 seconds and a task execution time of 15 seconds, with a single turnover of 25 / 15 ≈ 1.67. Assume there are two terminals to be transferred, Terminal X and Terminal Y. After simulating the execution of these three tasks, the overall turnover of the entire collection task set for Terminal X is 150, while that for Terminal Y is 180. Terminal X, therefore, has higher execution efficiency and serves as the target transfer terminal to receive Tasks A, B, and C.
[0099] As another optional implementation method for assigning the task to be transferred out to one of the terminals to be transferred in, a target transfer-in terminal is determined from multiple terminals to be transferred in, and the first execution comprehensive duration change and the second execution comprehensive duration change of the target transfer-in terminal are calculated respectively; when the second execution comprehensive duration change is greater than the first execution comprehensive duration change, only the task to be transferred out is assigned to the target transfer-in terminal; when the second execution comprehensive duration change is less than or equal to the first execution comprehensive duration change, both the task to be transferred out and the associated tasks are assigned to the target transfer-in terminal, and the associated tasks are performance collection tasks that belong to the same task subset as the task to be transferred out.
[0100] The duration change is used to reflect the change in the execution duration of each performance collection task by the management terminal after the task allocation strategy is changed. The weighted cumulative increase in the simulated execution time of the originally assigned performance collection task after only the task to be transferred out is added to the target transfer terminal; the change in the second execution comprehensive time After adding the pending tasks and associated tasks to the target transfer-in terminal, the cumulative increase in the simulated execution time of the originally assigned performance collection tasks. The associated tasks are performance collection tasks that belong to the same task subset as the pending tasks.
[0101] Specifically, you can set the first execution comprehensive duration change , the second execution comprehensive duration changes Where n is the number of performance collection tasks originally assigned to the target terminal. The original execution time of the kth original task in the originally assigned performance collection task, To increase only the simulation execution time of the kth task in the originally assigned performance collection task after the task to be called out, To increase the simulated execution time of the kth task in the originally assigned performance collection task after the task to be called out and the associated task, The weight coefficient for transferring only pending tasks is determined based on the dispersion of the performance collection tasks within the task subset to which the pending tasks belong. Dispersion reflects the degree to which performance collection tasks within the same task subset are distributed across multiple management terminals. A higher dispersion increases the weight (penalty factor) of the corresponding performance collection task.
[0102] In one embodiment, ,in, L O To be transferred out of the task, L C For the associated tasks of the task to be transferred out, Indicates the correlation between the task to be called out and its associated tasks. It is a customizable collaborative gain coefficient, which can be a fixed value or a value adaptively determined based on the number of originally allocated performance acquisition tasks in the target transfer terminal. The larger the number of originally allocated performance acquisition tasks, the smaller the collaborative gain coefficient.
[0103] Optionally, tasks to be called out L O Associated tasks L C The more dispersed they are (i.e., assigned to multiple different management terminals), the higher the relevance and the greater the corresponding weight; L O Associated tasks L C The closer the correlation, the higher the degree of correlation. The correlation can be calculated based on a combination of one or more appropriate correlation coefficient calculation models, such as the Pearson correlation coefficient and the Spearman rank correlation coefficient. The specific values of the coefficients / parameters involved in the correlation coefficient calculation model can be determined based on the relationship between the task to be called and its associated tasks, thereby obtaining an appropriate degree of correlation.
[0104] for example , It represents the Pearson correlation coefficient calculated according to the Pearson model, which is used to capture the linear correlation between the task to be called and its associated tasks. Represents the Spearman rank correlation coefficient calculated according to the Spearman model, which is used to capture the monotonic nonlinear correlation between the task to be called and its associated tasks. , represents the mixing ratio parameter, which can be set according to the specific relationship between the task to be called out and its associated tasks.
[0105] Furthermore, you can simply set . T O1 is the first quantity of tasks to be transferred out, T C1 The second number of associated tasks of the task to be called out.
[0106] when When , only the tasks to be transferred out are assigned to the target transfer-in terminal; when When transferring out, the tasks to be transferred out and the related tasks are assigned to the target transfer-in terminal.
[0107] For example, assuming that there are four periodic performance collection tasks for a certain device to be collected, when one of the performance collection tasks is used as a task to be called out (i.e. T O1 =1), then the remaining three performance collection tasks are the associated tasks of the task to be called out (i.e. T C1 =3). For the target terminal determined by the task to be transferred out, the simulated execution time of all the original performance collection tasks is 100 seconds. When only the task to be transferred out is added, the simulated execution time of only executing all the original performance collection tasks increases to 115 seconds. Although the execution time is only increased by 15 seconds, based on the above weighted summation method, the calculated first execution comprehensive duration changes When adding tasks to be called out and associated tasks at the same time, the simulation execution time of executing all the original performance collection tasks increases to 120 seconds, and the overall execution time of the second machine changes At this time, if the first execution comprehensive duration calculated according to the above embodiment is still less than 20 seconds (i.e. ), only the task to be transferred out is assigned to the target transfer terminal; if the calculated first execution comprehensive duration change is greater than or equal to 20 seconds (i.e. ), the tasks to be transferred out and the associated tasks are all assigned to the target transfer-in terminal.
[0108] This implementation introduces a penalty factor to adjust the calculation of the weighted cumulative increase in duration. This aims to maintain the integrity of task subsets during task scheduling decisions. Specifically, whenever feasible, the entire task subset (including the pending task and its associated tasks) is moved together, rather than individually. This reduces the scheduling complexity and resource coordination overhead associated with task fragmentation, thereby improving task scheduling efficiency and resource utilization.
[0109] In another embodiment, Figure 5 As shown, step S30 includes:
[0110] Step B10 , respectively calculating the task completion duration and task execution duration of the performance collection task corresponding to the task according to the task generation time, simulation execution time and simulation completion time of each performance collection task.
[0111] Step B20: The performance collection tasks whose task completion time and / or task execution time exceeds the corresponding execution period are treated as tasks to be called out.
[0112] In this embodiment, the execution cycle refers to the periodic interval of a performance collection task, that is, the time interval between two consecutive task generation. Pending tasks are performance collection tasks whose completion duration and / or execution duration exceeds the corresponding execution cycle. This indicates that these tasks may be delayed or executed inefficiently under the current allocation strategy.
[0113] Step B30 , calculating the impact of each performance collection task simulated and executed by the to-be-scheduled terminal on the tasks to be transferred out, and taking a preset number of performance collection tasks with the highest impact as the tasks to be transferred out.
[0114] In this embodiment, the "to-be-scheduled terminal" refers to the management terminal that simulates executing the task to be dispatched under the current simulated allocation policy. The "impact" refers to the degree to which other performance collection tasks on the to-be-scheduled terminal affect the execution efficiency of the task to be dispatched. The "to-be-transferred tasks" refer to a preset number of performance collection tasks with the highest impact, which are selected for transfer from the to-be-scheduled terminal.
[0115] In some implementations, the impact of each performance collection task on the scheduled terminal on the task to be called out is calculated separately. The impact can be comprehensively evaluated based on factors such as resource occupancy, execution priority, and dependencies between tasks of the task to be called out.
[0116] In some implementations, the resource types required by the task to be called out are identified, such as CPU, memory, disk I / O, etc. The occupancy rate of each performance collection task on the terminal to be scheduled on each resource type required by the task to be called out is calculated. For example, for each performance collection task i , which is in the resource type r Occupancy rate Ui , r It can be expressed as: Ui , r =Performance collection task i In resource type r Occupancy / resource type on r Based on the occupancy rate of each performance collection task on the terminal to be scheduled on each resource type required by the task to be called out, the influence of each performance collection task on the terminal to be scheduled on the task to be called out is calculated. For example, for each performance collection task i , its influence IiIt can be expressed as: .in, R It is a collection of resource types required for the task to be transferred out. Wr Is the resource type r The weight of the resource is set according to its impact on task execution. r The weight can be dynamically adjusted according to the real-time status of the task to be called out and the load of the terminal to be scheduled.
[0117] Step B40: assigning the task to be transferred out to one of the terminals to be transferred in. The terminal to be transferred in is a management terminal among the M management terminals, excluding the terminal to be scheduled that simulates executing the task to be transferred out under the current simulation allocation strategy.
[0118] In this embodiment, the target transfer-in terminal can be determined from multiple transfer-in terminals according to the above-mentioned method of calculating turnover, and the transfer-out task can be assigned to the target transfer-in terminal, or the transfer-out task and its associated tasks can be assigned to the target transfer-in terminal.
[0119] By analyzing the performance execution tasks that have the greatest impact on the tasks to be transferred out, the tasks to be transferred out are determined and assigned to the target transfer-in terminals instead of directly transferring out the tasks to be transferred out. This can further improve the comprehensive collection efficiency of the performance collection tasks in the collection task set.
[0120] As an implementation method for optimizing the performance of the collected devices based on their performance status, a performance status threshold can be pre-set. When the device performance status exceeds the threshold, the device is determined to be abnormal. Furthermore, the collected devices with abnormal performance status are identified as devices to be processed.
[0121] Obtain task execution information for the device to be processed. This information includes information such as the resource requirements of each currently executing task in the device's task list. Filter the task execution information to identify the abnormal type of device performance status as the task to be processed. For example, if the device performance status of the device to be processed is at high risk of GPU overload, select tasks with high CPU resource requirements as the task to be processed.
[0122] Performance tuning is performed on the processing device based on several resource requirement combinations for the pending tasks. A resource requirement combination refers to the different resource combinations that may be required during the execution of the pending task, including CPU, memory, disk I / O, and so on. Furthermore, due to the dynamic changes in the task's execution environment and requirements, resource requirement combinations are not fixed and may exist in multiple combinations due to resource compensation. Resource compensation refers to adjusting the task's resource usage to partially or fully shift the demand for one resource to another in order to optimize task execution efficiency and device performance. For example, the CPU load of certain tasks can be reduced through GPU acceleration, thereby reducing the demand for CPU resources.
[0123] Specifically, determine whether the performance indicator data associated with the device to be processed meets at least one of several resource requirement combinations; if so, reallocate the resources of the device to be processed for the task to be processed based on the satisfied resource requirement combination; if not, determine the collected device that meets at least one resource requirement combination as the backup device based on the performance indicator data of other collected devices, so as to transfer the task to be processed to the backup device.
[0124] For example, suppose the resource requirements for a pending task are as follows: Combination 1: 10% CPU requirement, 20% GPU requirement; Combination 2: 5% CPU requirement, 30% GPU requirement. The performance metrics of the pending device show that the CPU utilization available for the pending task is 5% and the GPU utilization is 40%. Because the pending device currently allocates only 5% of the CPU utilization and 20% of the GPU utilization to the pending task based on the resource requirements of Combination 1, the pending task is experiencing an anomaly. However, the performance metrics of the pending device now meet the requirements of Combination 2 (CPU utilization 5% ≤ 5%, GPU utilization 40% ≥ 30%). Therefore, Combination 2 can be selected as the resource requirement combination for optimization, allocating 10% more GPU utilization to the pending task.
[0125] For another example, suppose the resource requirement combinations for the pending task include: Combination 1: CPU requirement 10%, GPU requirement 20%; Combination 2: CPU requirement 5%, GPU requirement 30%. The performance indicator data of the pending device shows that the CPU usage that can be allocated to the pending task is 5%, and the GPU usage is 20%. At this time, it is determined that the performance indicator of the pending device does not meet the conditions of combination 1 or combination 2. Therefore, based on the performance indicator data of other collected devices, the collected device that meets at least one resource requirement combination is determined to be the backup device. For example, there are also devices B and C. Among them, the CPU usage that can be allocated to device B is 10%, and the GPU usage is 20%. The CPU usage that can be allocated to device C is 5%, and the GPU usage is 30%. It is detected that device C meets combination 2 of the pending task, so the pending task is transferred to device C.
[0126] In the performance tuning method of the cluster operating system proposed in the embodiment of the present application, on the one hand, by obtaining the collection task set formed by the periodic task subset for the collected device and simulating the allocation to the management terminal, the simulated execution time and the simulated completion time of each performance collection task can be predicted in advance. This helps to rationally plan the allocation of performance collection tasks, avoid problems such as task accumulation, data lag and untimely performance monitoring, and improve the efficiency and accuracy of the allocation of performance collection tasks. On the other hand, by iteratively optimizing the simulation allocation strategy, the task allocation strategy can be continuously adjusted to make it more adaptable to the actual operating environment, reduce the waiting time and execution time of the task, and improve the overall performance of the management terminal cluster. On the third hand, by analyzing the performance indicator data obtained by each management terminal executing the assigned performance collection task, the device performance status of each collected device can be accurately evaluated. Based on these detailed performance status data, the performance of the collected device can be targeted to improve the operating efficiency and stability of the collected device.
[0127] In one embodiment, a computer-readable storage medium is provided, on which executable instructions are stored. When the instructions are executed by a processor, the processor executes the steps in the above-mentioned method embodiments.
[0128] In one embodiment, an electronic device is also provided, comprising one or more processors; a memory, wherein one or more programs are stored in the memory, wherein when the one or more programs are executed by one or more processors, the one or more processors execute the steps in the above-mentioned method embodiments.
[0129] In one embodiment, Figure 6, which shows a schematic diagram of the structure of an electronic device for implementing an embodiment of the present application. Electronic device 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 602 or programs loaded from storage unit 608 into random access memory (RAM) 603. RAM 603 also stores various programs and data required for the operation of electronic device 600. CPU 601, ROM 602, and RAM 603 are connected to each other via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.
[0130] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, mouse, and the like; an output section 607 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and speakers; a storage section 608 including devices such as a hard disk; and a communication section 609 including a network interface card such as a LAN card or a modem. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. Removable media 611, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 610 as needed, so that computer programs read from the removable media can be installed in the storage section 608 as needed.
[0131] In particular, according to embodiments of the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer-readable medium carrying instructions. In such embodiments, the instructions can be downloaded and installed from a network via communication portion 609 and / or installed from removable media 611. When the instructions are executed by central processing unit (CPU) 601, the various method steps described in this application are performed.
[0132] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some or all of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.
[0133] Furthermore, those skilled in the art will appreciate that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are intended to be within the scope of this application and to form different embodiments. For example, any of the above embodiments may be used in any combination. The information disclosed in this background section is intended solely to enhance understanding of the overall background of this application and should not be construed as an admission or any form of implication that such information constitutes prior art known to those skilled in the art.
Claims
1. A performance tuning method for a cluster operating system, characterized in that: The method comprises: Get a collection task set, the collection task set is a set formed by periodic task subsets for N collection devices deployed with a cluster operating system, the i-th task subset in the collection task set is the i-th task subset. The performance collection task is the jth performance collection task for the i-th collected device; Simulate the allocation of the collection task set to M management terminals, and predict the simulated execution time and simulated completion time of each performance collection task based on the task generation time and simulation allocation result of each performance collection task; Iteratively optimize the simulation allocation strategy based on the execution cycle, task generation time, simulation execution time, and simulation completion time of each performance collection task, and allocate performance collection tasks according to the optimized task simulation allocation strategy; Analyze the performance status of each collected device based on the performance indicator data obtained by each management terminal when executing the assigned performance collection task, and perform performance tuning on the collected device according to the device performance status; The simulation allocation strategy is iteratively optimized based on the execution cycle, task generation time, simulation execution time and simulation completion time of each performance acquisition task, and performance acquisition tasks are allocated according to the optimized task simulation allocation strategy, including: calculating the task completion time and task execution time of the performance acquisition task corresponding to the task according to the task generation time, simulation execution time and simulation completion time of each performance acquisition task, and treating the performance acquisition task whose task completion time and / or task execution time exceeds the corresponding execution cycle as a task to be called out, and allocating the task to be called out to one of the terminals to be transferred in. The terminal to be transferred in is a management terminal among M management terminals, excluding the terminal to be scheduled that simulates the execution of the task to be called out under the current simulation allocation strategy.
2. The performance tuning method of a cluster operating system according to claim 1, characterized in that: Allocating the task to be transferred out to one of the terminals to be transferred in comprises: Calculate the comprehensive turnover rate corresponding to the entire collection task set when each terminal to be transferred in simulates executing the task to be transferred out. The comprehensive turnover rate is the weighted sum of the individual turnover rates of each performance collection task. The individual turnover rate is the quotient of the task completion time and the task execution time of the corresponding performance collection task. The terminal to be transferred in, corresponding to the simulated allocation strategy with the smallest comprehensive turnover, is used as the target transfer-in terminal, and the task to be transferred out is allocated to the target transfer-in terminal.
3. The performance tuning method of a cluster operating system according to claim 1, characterized in that: The allocating the task to be transferred out to one of the terminals to be transferred in comprises: Calculate the comprehensive turnover corresponding to the entire collection task set when each terminal to be transferred simulates the execution of the task to be transferred out and the associated tasks. The comprehensive turnover is the weighted sum of the individual turnovers of each performance collection task. The individual turnover is the quotient of the task completion time and the task execution time of the corresponding performance collection task. The associated tasks are performance collection tasks that belong to the same task subset as the task to be transferred out. The terminal to be transferred in, corresponding to the simulated allocation strategy with the smallest comprehensive turnover, is used as the target transfer-in terminal, and the tasks to be transferred out and the associated tasks are allocated to the target transfer-in terminal.
4. The performance tuning method of a cluster operating system according to claim 1, characterized in that: The allocating the task to be transferred out to one of the terminals to be transferred in comprises: Determine a target transfer-in terminal from a plurality of terminals to be transferred-in, and calculate a first execution integrated duration change and a second execution integrated duration change of the target transfer-in terminal respectively; When the second execution integrated duration change is greater than the first execution integrated duration change, only the to-be-called task is assigned to the target transfer-in terminal; When the second comprehensive execution duration change is less than or equal to the first comprehensive execution duration change, allocating both the task to be transferred out and an associated task to the target transfer-in terminal, where the associated task is a performance collection task that belongs to the same task subset as the task to be transferred out; The first comprehensive execution duration change is the weighted cumulative increase in the simulated execution duration of the originally assigned performance collection task of the target transfer-in terminal after only the task to be transferred out is added; The second comprehensive execution duration change is the cumulative increase in the simulated execution duration of the originally allocated performance collection task after the target transfer-in terminal adds the task to be transferred out and the associated task.
5. The performance tuning method of a cluster operating system according to claim 1, characterized in that: The iterative optimization of the simulation allocation strategy based on the execution cycle, task generation time, simulation execution time, and simulation completion time of each performance collection task, and the performance collection task allocation according to the optimized task simulation allocation strategy, include: Calculate the task completion time and task execution time of the performance collection task corresponding to the task according to the task generation time, simulation execution time and simulation completion time of each performance collection task; The performance collection tasks whose task completion time and / or task execution time exceeds the corresponding execution cycle are treated as tasks to be called out; Calculate the influence of each performance collection task simulated and executed by the terminal to be scheduled on the tasks to be transferred out, and select a preset number of performance collection tasks with the highest influence as the tasks to be transferred out; The task to be transferred out is assigned to one of the terminals to be transferred in, where the terminal to be transferred in is a management terminal among the M management terminals excluding the terminal to be scheduled that simulates executing the task to be transferred out under the current simulation allocation strategy.
6. The performance tuning method of a cluster operating system according to claim 1, characterized in that: The performing performance tuning on the collected device according to the device performance status includes: Determine the collected devices with abnormal performance status as devices to be processed; Acquiring task execution information of the device to be processed, and filtering out tasks corresponding to the abnormal type of the device performance status from the task execution information as tasks to be processed; The performance of the device to be processed is optimized according to several resource requirement combinations of the task to be processed.
7. The performance tuning method of a cluster operating system according to claim 6, characterized in that: The step of optimizing the performance of the device to be processed according to the combinations of resource requirements of the task to be processed includes: Determining whether the performance indicator data associated with the device to be processed meets at least one of the several resource requirement combinations; If so, reallocating resources of the device to be processed for the task to be processed based on the satisfied resource requirement combination; If not, a collected device that meets at least one resource requirement combination is determined as a backup device based on the performance indicator data of other collected devices, so as to transfer the to-be-processed task to the backup device.
8. An electronic device, characterized in that: include: one or more processors; a memory for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors are enabled to execute the performance tuning method for a cluster operating system according to any one of claims 1 to 7.
9. A storage medium, characterized in that: The storage medium stores executable instructions, and when the instructions are executed by the processor, the processor executes the performance tuning method for the cluster operating system according to any one of claims 1 to 7.
Citation Information
Patent Citations
Task distributing method and scanner
CN103699443A
Task scheduling method and device, computer equipment and storage medium
CN115437770A