Energy efficiency optimization scheduling method and system based on load prediction

Abstract

The invention discloses an energy efficiency optimization scheduling method and system based on load prediction, and relates to the technical field of energy efficiency optimization scheduling. The method comprises the steps of obtaining load prediction information of a server, and evaluating whether task migration is performed or not; if task migration is carried out, task performance information is obtained, and the server matching degree of task migration is obtained through evaluation according to the task performance information; task operation data are obtained, and operation perception intensity of task migration is obtained through evaluation; based on the operation perception intensity, historical information of the task is obtained, and the user acceptability of task migration is obtained through root evaluation; the migration degree of task migration is obtained through evaluation in combination with the server matching degree, the operation perception intensity and the user acceptability; whether the migration degree reaches a preset migration standard or not is judged, and if yes, migration scheduling is conducted on the task. According to the invention, the convenience and intelligence of energy efficiency optimization scheduling based on load prediction are improved.

Description

Technical Field

[0001] This application relates to the technical field of energy efficiency optimization scheduling, and in particular to an energy efficiency optimization scheduling method and system based on load forecasting. Background Technology

[0002] In the data center and cloud computing fields, server clusters, as the core infrastructure supporting digital services, are experiencing a continuously rising proportion of global electricity consumption. To achieve green and low-carbon goals, the industry generally adopts energy efficiency optimization scheduling technology based on load forecasting, which reduces energy consumption through dynamic allocation of server resources and task migration. Existing technologies mainly establish scheduling models based on physical indicators such as hardware resource utilization, electricity price fluctuation cycles, and cooling power consumption, directly mapping load forecasting results to server start / stop or task migration instructions. However, this method only focuses on energy cost savings and has a crude design for service continuity assurance mechanisms. In practice, task migration often leads to negative experiences such as service response delays, session connection interruptions, and instantaneous functional degradation. In scenarios such as financial transactions, online healthcare, and industrial control, millisecond-level interruptions can cause serious incidents such as user transaction failures, inaccurate remote surgical operations, and loss of production line control instructions, severely affecting service quality and causing inconvenience to users. Summary of the Invention

[0003] The purpose of this invention is to provide an energy efficiency optimization scheduling method and system based on load prediction to solve the problems mentioned in the background art.

[0004] Firstly, this application provides an energy efficiency optimization scheduling method based on load forecasting, which adopts the following technical solution: Obtain server load forecast information and assess whether to migrate tasks based on the load forecast information; If a task migration is performed, the task performance information is obtained, and the server matching degree for task migration is evaluated based on the task performance information. Acquire task execution data and assess the operational awareness intensity of task migration based on the task execution data; Based on the intensity of operational awareness, historical information of the task is obtained, and the user acceptance of task migration is evaluated based on the historical information. The migration degree of the task migration is obtained by combining server compatibility, perceived operational strength, and user acceptance. Determine whether the migration degree has reached the preset migration standard. If it has, then migrate and schedule the task.

[0005] Preferably, the step of obtaining server load prediction information and assessing whether to perform task migration based on the load prediction information is as follows: The total remaining resources of all servers are extracted based on the load prediction information. Historical usage information of the servers is collected, and the total fluctuating resources are evaluated based on the historical usage information. Determine whether the total remaining resources cover the total fluctuating resources. If they do, extract the server's independent remaining resources based on the load forecast information. Based on historical usage information, assess the server's independent fluctuation resources to determine if there are situations where the independent remaining resources cannot cover the independent fluctuation resources. If the task exists, then a task migration is performed. If the task does not exist, then a task migration is performed based on the difference between the total remaining resources and the total fluctuating resources.

[0006] Preferably, the step of collecting historical usage information of the server and assessing the total fluctuating resources based on the historical usage information is as follows: Obtain the predicted time point and calculate the average server resource usage at the historical predicted time point as the base usage value based on historical usage information; Collect incidental events that cause fluctuations in server resources and confirm whether these incidental events will inevitably occur at the predicted time points; If an unforeseen event is certain to occur at the predicted time point, the average resource usage value of the unforeseen event is recorded as the unforeseen fluctuation value. If an unplanned event does not necessarily occur at the predicted time, then estimate the probability of the unplanned event and determine whether the probability of occurrence meets the preset probability standard. If the preset probability standard is reached, it is determined that an occasional event will occur. The server's independent fluctuation resources are obtained by summing the occasional fluctuation values ​​of all possible occasional events and the basic usage value. The total fluctuation resources are obtained by summing the independent fluctuation resources of all servers.

[0007] Preferably, if task migration is performed, the steps of obtaining task performance information and evaluating the server compatibility for task migration based on the task performance information are as follows: Obtain server resource information and classify the servers into migration servers and receiving servers based on the server resource information; Find the tasks for migrating servers, and select the tasks that can be migrated as the migrated tasks; Collect the running conditions of the transferable tasks, and select the receiving servers that meet the running conditions as candidate servers from the receiving servers; Collect the task functions of the transferable tasks and determine whether the task functions are implemented after the transferable tasks are migrated to the candidate server; If the task function is not implemented, the degree of reduction in task function will be statistically determined. After migrating a migratable task to a candidate server, the degree of security and performance changes of the migratable task are statistically analyzed, and the matching degree of the candidate server is obtained by combining the degree of reduction in task functionality. Choose the server with the highest matching degree as the server matching degree for task migration.

[0008] Preferably, if the task function is not implemented, the step of calculating the degree of reduction in task function is as follows: The task functions that are not implemented after the task migration are recorded as disappearing functions. The total number of task functions is counted, and the ratio of the number of disappearing functions to the total number is counted to obtain the disappearing function percentage. Collect the average usage rate of the disappearing function and record it as the function usage rate; calculate the average usage rate of the transferable tasks and record it as the total usage rate. The ratio of the usage rate of a function to the total usage rate is used to obtain the core function rate. Combined with the total usage rate, the importance of the disappearing function is obtained. The functions implemented after the task migration are recorded as existing functions, and the degree of correlation between disappearing functions and existing functions is calculated. The degree of reduction in task functionality is determined by comprehensively evaluating the percentage of disappearing functions, their importance in use, and their relevance.

[0009] Preferably, the steps of obtaining historical information about the task based on the perceived intensity of operation, and assessing the user acceptance of task migration based on the historical information, are as follows: Obtain the user's historical operation information for the task, and assess the task's importance based on the historical operation information; Based on the intensity of operational awareness, historical complaint information of the task is collected, and user tolerance is assessed based on the historical complaint information. Based on the intensity of operational awareness, information on the operational stages of a task is collected, and the continuity value of task interaction is evaluated based on the operational stage information. User acceptance of task migration is obtained by combining task importance, user tolerance, and interaction continuity value.

[0010] Preferably, the step of obtaining the user's historical operation information for a task and assessing the task's importance based on that historical operation information is as follows: Determine whether the task is an occasional task. If the task is an occasional task, collect the task probability of occasional tasks. Determine whether there is any economic loss in completing the task. If there is an economic loss, calculate the average economic loss if the task fails. The system counts the number of times users access a task before it begins, and calculates the average number of refreshes and average access duration during the task operation based on historical operation information, thus obtaining the user's task attention level. Task importance is determined by combining task probability, average economic loss, and task attention.

[0011] Preferably, the steps of collecting historical complaint information for a task based on operational awareness intensity and assessing user tolerance based on this historical complaint information are as follows: Collect the user's objective corresponding to the task execution and determine whether all users can achieve their objective. If not all tasks can achieve the user's purpose, then the percentage of purpose achieved for each task will be calculated based on historical information. The correlation between the achievement of user objectives and the server is statistically analyzed, and the objective tolerance level is obtained by combining the achievement rate. Collect historical complaint information for tasks, and calculate the average complaint rate of the server corresponding to the task based on the historical complaint information. User tolerance is assessed by combining the target tolerance level and the average complaint rate.

[0012] Preferably, the steps of collecting task operation information based on operation awareness intensity and evaluating the task interaction continuity value based on the operation information are as follows: When the data collection task is running, the user refreshes the record, and the average tolerance of different running stages is calculated based on the refresh record. Obtain the operational awareness intensity at different stages and establish a correlation table between operational awareness intensity and average tolerance. The average tolerance level corresponding to different stages is obtained by searching the associated table and recorded as the tolerance threshold. Collect the real-time tolerance of different stages, filter the stages whose real-time tolerance reaches the tolerance threshold and record them as refresh stages; Record the steps that ran before the refresh step as historical steps, and determine whether the refresh step should restart the historical steps; If a historical step is restarted, the refresh step of the restarted historical step will be recorded as a restart step, and the number of restart steps will be counted. The average restart time of each restart stage is calculated, the number of restart stages is counted, and the continuous value of task interaction is obtained by combining the number of restart stages.

[0013] Secondly, this application provides an energy efficiency optimization scheduling system based on load forecasting, which adopts the following technical solution: An energy efficiency optimization scheduling system based on load forecasting includes: The migration judgment module obtains the server's load prediction information and evaluates whether to migrate the task based on the load prediction information. The matching evaluation module, if task migration is to be performed, obtains task performance information and evaluates the server matching degree of task migration based on the task performance information. The perception intensity module acquires task operation data and evaluates the operational perception intensity of task migration based on the task operation data. The user acceptance module obtains historical information about the task based on the intensity of operational awareness, and evaluates the user acceptance of the task migration based on the historical information. The migration assessment module combines server compatibility, operational awareness intensity, and user acceptance to evaluate the migration degree of the task migration. The migration scheduling module determines whether the migration degree has reached the preset migration standard. If the preset migration standard is reached, the task is migrated and scheduled.

[0014] In summary, this application includes at least one of the following beneficial technical effects: 1. Determine whether to migrate tasks based on server load. If migration is necessary, select migrateable tasks and assess whether the functionality is implemented after migration. If the functionality is not implemented, mark the unimplemented functionality as a "disappeared function," count the total number of functions, and calculate the percentage of disappeared functions out of the total. Calculate the core function rate based on function usage and task usage, and combine this with the total usage rate to determine the importance of the disappeared functions. Mark the implemented functions as "existing functions," and calculate the correlation between disappeared and existing functions. Combine the percentage of disappeared functions and usage importance to comprehensively evaluate the reduction in task functionality. Analyze the security and performance changes of migrateable tasks after migration to candidate servers, and combine this with the reduction in task functionality to determine the matching degree of candidate servers. Select the server with the highest matching degree as the server matching degree for task migration. Evaluate the perceived intensity of task migration based on task execution data, and evaluate the user acceptance of task migration based on historical task information and perceived intensity. Combine server matching degree, perceived intensity of execution, and user acceptance to evaluate the migration degree of task migration. When the migration degree reaches the preset migration standard, schedule the task migration. During the server task migration process, the suitability of migration is assessed from multiple aspects, taking into account not only the task completion status but also the user experience quality after migration. This reduces the inconvenience caused to users by server energy efficiency optimization scheduling and improves the convenience of energy efficiency optimization scheduling based on load prediction.

[0015] 2. Obtain the predicted time point and calculate the average server resource usage at the predicted time point based on historical usage information as the base usage value. Collect occasional events that cause server resource fluctuations and confirm whether these events will inevitably occur at the predicted time point. If the occasional event will inevitably occur at the predicted time point, calculate the average resource usage value of the occasional event as the occasional fluctuation value. If the occasional event will not necessarily occur at the predicted time point, estimate the probability of its occurrence, determine whether the event will occur based on the probability, and sum the occasional fluctuation values ​​of all possible occasional events with the base usage value to obtain the server's independent fluctuating resources. Summarize the independent fluctuating resources of all servers to obtain the total fluctuating resources. Determine whether the total remaining resources cover the total fluctuating resources and whether the independent remaining resources cover the independent fluctuating resources. If there is a mismatch, determine whether to perform task migration. Based on the current situation, predict the probability of occasional events and the resource usage of occasional events, and determine whether to perform task migration. This saves resources and reduces the probability of being unable to cope with emergencies, thereby reducing a series of problems such as server security and user usage caused by emergencies, and improving the security and predictability of energy efficiency optimization scheduling based on load prediction.

[0016] 3. If the task is sporadic, collect the task probability of sporadic tasks and calculate the average economic loss of task failure. Statistically analyze the number of user visits to the task before it starts, the average number of refreshes during the task operation, and the average access duration to obtain the user's task attention. Combine the task probability, average economic loss, and task attention to obtain the task importance. Collect the user's purpose corresponding to the task execution. If not all users can achieve their purpose, statistically analyze the percentage of purpose achievement based on historical information, and combine the strength of the correlation between purpose achievement and server performance to obtain purpose tolerance. Statistically analyze the average complaint rate of the server corresponding to the task, and combine purpose tolerance and average complaint rate to evaluate user tolerance. Statistically analyze the average tolerance of different operational stages based on the refresh records during task execution, establish a correlation table between the perceived intensity of different stages and the average tolerance, find the average tolerance corresponding to each stage, and record it as the tolerance threshold. Filter the stages where the real-time tolerance reaches the tolerance threshold and record them as refresh stages. The steps that ran before the refresh step are recorded as historical steps. If the refresh step restarts a historical step, the refresh step that restarts the historical step is recorded as a restart step. The number of restarted steps, the average restart time of restarted steps, and the step sequence number of restarted steps are counted to obtain the task interaction continuity value. Finally, the user acceptance of task migration is obtained by combining task importance, user tolerance, and interaction continuity value. The impact of task migration on user experience is evaluated by assessing user acceptance of task migration based on user attention to the task, tolerance, and interaction continuity, thereby further deciding whether to migrate the task. Selecting whether to migrate a task based on its impact on user service quality improves the server's service quality to users and enhances the convenience and intelligence of energy efficiency optimization scheduling based on load prediction. Attached Figure Description

[0017] Figure 1 This is a schematic diagram illustrating the specific steps of an embodiment of an energy efficiency optimization scheduling method based on load prediction according to the present invention.

[0018] Figure 2 This is a schematic diagram of the module connections of an embodiment of an energy efficiency optimization scheduling system based on load prediction according to the present invention. Detailed Implementation

[0019] The following examples and... Figures 1-2 The present invention will be described in further detail, but the embodiments of the present invention are not limited thereto.

[0020] This invention discloses an energy efficiency optimization scheduling method based on load forecasting, specifically including the following steps: Step S1: Obtain the server's load prediction information and assess whether to perform task migration based on the load prediction information.

[0021] Step S2: If task migration is to be performed, obtain task performance information and evaluate the server matching degree of task migration based on the task performance information.

[0022] Step S3: Obtain task execution data and evaluate the execution awareness intensity of task migration based on the task execution data.

[0023] Perceived operational intensity refers to the intensity of different task stages that users can feel during operation. In real-time task scheduling, the perceived intensity of user activity regarding task status exhibits significant stratification, determined by the closeness of the task stage to the user's goal. Take a concert ticket-buying system as an example: the moment a user clicks the "Buy Now" button, the system needs to lock inventory and create the order within 200 milliseconds. A delay in this step directly leads to ticket purchase failure, and the user's perceived intensity of this delay reaches its peak (e.g., a visually perceptible lag in the loading progress bar or a button color change). However, once the payment stage begins, when the system asynchronously pushes the payment request to the bank's gateway, the user can only perceive the background operation through a vague "Payment processing" status message. At this point, even if there is a 3-second delay in subtasks such as payment request queuing and encrypted communication with the bank interface, most people will accept a reasonable financial process wait. As for the final step of generating the ticket verification code, the system automatically calls a cryptographic service in the background to generate an encrypted token and synchronizes the data to the ticketing blockchain. Even if this process takes more than 10 seconds, users are in a state of zero awareness (perception coefficient ≈ 0) because there is no user interface feedback channel. They will only be passively aware of the process in extreme cases (such as not receiving the e-ticket email). The level of operational awareness can be assessed by experts or based on the degree of visualization of each step.

[0024] Step S4: Based on the intensity of operational awareness, obtain historical information about the task, and evaluate the user acceptance of the task migration based on the historical information.

[0025] Step S5: Combine server compatibility, operational awareness intensity, and user acceptance to evaluate the migration degree of the task migration.

[0026] The objective weights of server matching degree, operational perception intensity and user acceptance can be determined by using the entropy weight method, and the migration metric value can be output by weighted linear aggregation.

[0027] Step S6: Determine whether the migration degree has reached the preset migration standard. If the preset migration standard has been reached, then the task will be migrated and scheduled.

[0028] In practical applications, a server is a specific IT device that provides computing power and runs software applications in a network environment. It provides computing or application services to other client machines (such as personal computers, smartphones, ATMs, and other terminal devices), bringing convenience to people's lives. In daily applications, multiple servers exist, and due to task allocation and other reasons, some servers have idle resources. To optimize energy efficiency and reduce resource idleness, task migration is often used. Current technologies typically only consider resource idleness, without taking into account the inconvenience caused to users by task migration. If task migration causes significant inconvenience to users, then the migration becomes counterproductive. Therefore, whether to perform task migration needs to be evaluated from multiple perspectives. This allows for resource conservation while meeting user needs, minimizing user inconvenience, and improving user convenience in server energy efficiency optimization and scheduling.

[0029] The steps for obtaining server load forecast information and assessing whether to perform task migration based on this information are as follows: Step S11: Extract the total remaining resources of all servers based on the load prediction information, collect the historical usage information of the servers, and evaluate the total fluctuating resources based on the historical usage information.

[0030] Load prediction information includes real-time load usage information and load prediction related information. Therefore, the resource usage of the server can be obtained based on the real-time load usage information.

[0031] Step S12: Determine whether the total remaining resources cover the total fluctuating resources. If they cover the fluctuating resources, extract the server's independent remaining resources based on the load prediction information.

[0032] Step S13: Evaluate the server's independent fluctuation resources based on historical usage information to determine whether there are situations where the independent remaining resources cannot cover the independent fluctuation resources.

[0033] Within the overall volatility resource assessment method, specifically steps S111-S116, there is an independent volatility resource assessment method.

[0034] Step S14: If the task exists, determine whether to perform task migration; if not, determine whether to perform task migration based on the resource difference between the total remaining resources and the total fluctuating resources.

[0035] In practical applications, task migration presupposes sufficient resource consolidation. If remaining resources cannot cover fluctuating resources, server resource shortages may occur. In this case, tasks on servers with insufficient resources need to be migrated to other servers so that the server can meet subsequent load demands. If the total remaining resources of the servers and individual servers are sufficient to cover fluctuating resources, the difference between the total remaining resources and the total fluctuating resources is calculated. If this difference is not less than the total resources of a single server, task migration can proceed. This allows some servers to be shut down, saving resources. However, in deciding whether to migrate tasks, relying solely on real-time resource conditions may result in an inability to handle subsequent emergencies after migration. Therefore, predicting resource fluctuations based on load forecasting information is beneficial for optimizing server energy efficiency and better responding to unexpected situations.

[0036] The steps for collecting historical usage information from servers and assessing the total fluctuating resources based on this information are as follows: Step S111: Obtain the predicted time point and calculate the average server resource usage at the predicted time point in history as the base usage value based on historical usage information.

[0037] Server resource usage varies at different times. For example, in the morning, when most companies are holding video conferences, resource usage is higher. At night, when most users are asleep, server resource usage is lower.

[0038] Step S112: Collect occasional events that cause fluctuations in server resources and confirm whether the occasional events will inevitably occur at the predicted time point.

[0039] Collect all times that cause significant fluctuations in server resources, and determine whether they are occasional events based on the frequency and context of occurrence. For example, some entertainment tasks may increase server resource usage in the evening because most users are at work during the day. Events like watching TV or attending meetings occur at relatively fixed times and frequencies, so they are not occasional events. However, events like concert ticket rushes or major e-commerce promotions do not occur every day, and the timing varies each time, therefore they are considered occasional events.

[0040] Step S113: If the incidental event is bound to occur at the predicted time point, then the average resource usage value of the incidental event is recorded as the incidental fluctuation value.

[0041] Some events have predetermined times, such as concert ticket sales and e-commerce promotions, which are scheduled in advance. This allows us to determine whether the predicted time will necessarily occur.

[0042] Step S114: If the random event does not necessarily occur at the predicted time point, then estimate the probability of the random event and determine whether the probability of occurrence reaches the preset probability standard.

[0043] Some events are irregular and have no fixed time, making it difficult to know whether they will happen. For example, server load fluctuations caused by hot public opinion (social events) are unpredictable. The probability of such events occurring cannot be determined. Based on historical data, we can assess and statistically analyze the probability of their occurrence.

[0044] Step S115: If the preset probability standard is reached, it is determined that an occasional event will occur. The server's independent fluctuation resources are obtained by superimposing the occasional fluctuation values ​​of all possible occasional events and the basic usage value.

[0045] Step S116: Overlay the independent fluctuation resources of all servers to obtain the total fluctuation resources.

[0046] In practical applications, server resource usage is generally traceable, but resource fluctuations caused by unforeseen events cannot be ruled out. Therefore, when predicting server load, it is necessary to consider load changes caused by unforeseen events. This is beneficial for timely scheduling and response to future load changes and reduces unnecessary failures. Thus, when determining whether to migrate tasks, future load conditions need to be considered, leading to more accurate energy-efficient scheduling of the server. If the probability of an unforeseen event is high, it should be considered likely to occur, its resource fluctuations calculated, and contingency plans prepared in advance.

[0047] If task migration is to be performed, the steps for obtaining task performance information and assessing the server compatibility for task migration based on that information are as follows: Step S21: Obtain server resource information and classify the servers into migration servers and receiving servers based on the server resource information.

[0048] Servers with more remaining resources will be used as migration servers, while servers with less remaining resources will be used as receiving servers. Servers with more remaining resources will have fewer tasks, resulting in a smaller migration workload; therefore, resources can be saved by shutting down these servers.

[0049] Step S22: Locate the tasks for migrating servers and select the migrateable tasks as the migrateable tasks.

[0050] Some server tasks cannot be migrated due to data security or other reasons. Therefore, when distinguishing between a migration server and a receiving server, a server must have all its tasks that can be migrated to be considered a migration server.

[0051] Step S23: Collect the running conditions of the transferable tasks, and select receiving servers that meet the running conditions from the receiving servers as candidate servers.

[0052] The execution of tasks is also conditional; not all servers can meet the operating conditions of all tasks. For example, the training task of a certain autonomous driving model requires specific operators, and migrating to a server that only supports V100 will cause a drop in accuracy. Therefore, this server cannot meet the operating conditions of the training task.

[0053] Step S24: Collect the task functions of the transferable tasks and determine whether the task functions are implemented after the transferable tasks are migrated to the candidate server.

[0054] Step S25: If the task function is not implemented, the degree of reduction in task function is statistically determined.

[0055] Step S26: Calculate the security and performance changes of the migrateable tasks after they are migrated to the candidate servers, and combine this with the degree of reduction in task functionality to obtain the matching degree of the candidate servers.

[0056] The degree of safety variation is obtained through user evaluation, while the degree of performance variation is obtained by summing the differences between various performance indicators.

[0057] Step S27: Select the highest matching degree as the server matching degree for task migration.

[0058] In practical applications, not all server tasks are suitable for migration, and the running status of tasks is not the same on all servers. For example, poor storage performance can lead to worsened data processing latency. Medical image analysis (processing a 1GB DICOM file) on a high-performance server with a disk read / write speed of 4.5GB / s takes 22 seconds to complete. However, on a low-performance server with a read / write bandwidth limited to 200MB / s, the task is blocked for 8 minutes and fails due to timeout. Therefore, the functionality and performance of a task will differ when migrated to different servers. Consequently, the compatibility between different migration tasks and different servers varies. Therefore, assessing the compatibility between a task and different receiving servers based on the degree of task functionality reduction helps in selecting the most suitable server and reducing situations where tasks cannot be completed or perform poorly due to server-task incompatibility.

[0059] If the task functionality is not implemented, the steps to determine the degree of reduction in task functionality are as follows: Step S251: Record the task functions that are not implemented after the task migration as disappeared functions, count the total number of task functions, and count the ratio of the number of disappeared functions to the total number to obtain the percentage of disappeared functions.

[0060] Some tasks will become unusable after migration; these are referred to as missing functions. For example, the lack of hardware acceleration instruction sets may cause the computing module to crash. The video transcoding service (which relies on Intel AVX-512 instructions) could be completed in real time on the Intel Xeon Scalable server (which supports AVX-512) before the migration, but the transcoding function is unavailable on the AMD EPYC server (which only supports AVX2) after the migration.

[0061] Step S252: Collect the average usage rate of the disappearing function and record it as the function usage rate; calculate the average usage rate of the transferable tasks and record it as the total usage rate.

[0062] Step S253: Calculate the ratio of function usage rate to total usage rate to obtain the function core rate, and combine it with the total usage rate to obtain the usage importance of the disappearing function.

[0063] The importance of a task's disappearance function depends on two factors: its usage within the task and the overall usage of the task. If the task is rarely used, even if the disappearance function is a core function, it's not particularly important. Conversely, if the task has a high usage rate, even a peripheral function like disappearance might be significant. We can assign weights to the core usage rate and the overall usage rate, and then calculate the importance using a weighted summation method.

[0064] Step S254: Record the task functions implemented after the task migration as existing functions, and calculate the correlation between disappearing functions and existing functions.

[0065] The degree of association is obtained based on the co-use rate of disappearing and existing functions, that is, the ratio of the number of times disappearing and existing functions are used together to the total number of times existing functions are used.

[0066] Step S255: Combine the percentage of disappearing functions, usage importance, and relevance to comprehensively evaluate the degree of reduction in task functions.

[0067] In practical applications, a fuzzy logic reasoning system can be constructed, using the three indicators as input variables. These indicators are then mapped through a rule base (such as IF-THEN rules) to a membership function representing the degree of task functionality reduction, thus yielding the extent of the reduction. The matching of a task with a server requires considering not only changes in performance but also changes in functionality. The functionality implemented by the task is fundamental; a reduction in the task's functionality indicates a mismatch between the server and the task, meaning the server cannot support the task in fulfilling all its functions. Therefore, the greater the degree of functional reduction, the weaker the match between the task and the server.

[0068] Based on the perceived intensity of operation, the steps for obtaining historical information about the task and assessing user acceptance of task migration based on this historical information are as follows: Step S41: Obtain the user's historical operation information for the task, and evaluate the task importance based on the historical operation information.

[0069] Step S42: Based on the intensity of operational perception, collect historical complaint information of the task, and assess the user's tolerance level based on the historical complaint information.

[0070] Step S43: Based on the operational awareness intensity, collect the operational phase information of the task, and evaluate the continuous value of task interaction based on the operational phase information.

[0071] Step S44: Combine task importance, user tolerance, and interaction continuity value to obtain the user acceptance of task migration.

[0072] In practical applications, the Analytic Hierarchy Process (AHP) is used to compare the importance of task, user tolerance, and interaction continuity pairwise, forming a judgment matrix to derive weight ratios and synthesize a user acceptance decision score. Since the server serves the user, it would be counterproductive if the impact of task migration significantly affects user experience. By assessing the task's importance to the user, the user's tolerance for task migration, and the continuity of task interaction, the user's acceptance of the task migration is obtained.

[0073] The steps for obtaining the user's historical operation information for a task and assessing the task's importance based on this information are as follows: Step S411: Determine whether the task is an occasional task. If the task is an occasional task, collect the task probability of the occasional task.

[0074] An occasional task refers to a task that occurs only occasionally, without any pattern. If it is not an occasional task, the probability of its occurrence is determined based on the predicted time point; the task probability refers to the likelihood of the task occurring.

[0075] Step S412: Determine whether there is any economic loss in achieving the task. If there is an economic loss, calculate the average economic loss of the task failure.

[0076] Some task failures result in economic losses. For example, delays in financial trading orders (millisecond-level disasters) can cause high-frequency arbitrage strategies to fail, leading to missed price difference opportunities. However, some tasks, such as a TV series failing to play, do not cause economic losses. Whether or not an economic loss occurs is determined based on historical data; tasks with a higher proportion of economic losses are considered to have economic impact. The average economic loss is then calculated based on the average percentage of such losses.

[0077] Step S413: Count the number of times the user accesses the task before the task starts, and calculate the average number of refreshes and average access time during the task operation based on historical operation information, and obtain the user's task attention level.

[0078] By training a gradient boosting decision tree model (such as XGBoost), the task attention level can be directly predicted using the number of visits, the average number of refreshes during the task operation, and the average visit duration as feature inputs, and the task attention level as the label.

[0079] Step S414: Combine task probability, average economic loss, and task attention to obtain task importance.

[0080] In practical applications, the entropy weight method is used to determine the objective weights of task probability, average economic loss, and task attention. A weighted linear aggregation is then used to output a quantifiable value of task importance. A higher task probability generally indicates lower task importance, because even if the task fails, there is still a chance to succeed. However, for occasional events like concert ticket scalping, failure means a long wait before another opportunity to complete the task, thus increasing its importance. Higher average economic loss and higher task attention also indicate greater importance to the user, making the task more significant. Assessing task importance is beneficial for further evaluating user acceptance. The more important the task, the lower the user's acceptance of task migration, as migration would impact the task itself.

[0081] Based on the perceived intensity of operation, the steps for collecting historical complaint information about the task and assessing user tolerance based on this historical complaint information are as follows: Step S421: Collect the user's objective corresponding to the task execution and determine whether all users can achieve their objective.

[0082] Server tasks are designed to meet user needs, and each task has its own user objective. For example, the user objective of a concert ticket-grabbing task is to obtain concert tickets, while the user objective of a TV series viewing task is to watch the series. However, some tasks, due to their inherent characteristics, are destined not to satisfy all user objectives. For instance, if there are only 20,000 concert tickets available, but 100,000 people are trying to buy them, then some users will inevitably fail to obtain tickets and thus be unable to achieve their objective.

[0083] Step S422: If not all of them can achieve the user's purpose, then the percentage of purpose achievement corresponding to the task is calculated based on historical information.

[0084] The percentage of participants who can actually complete the task is called the completion percentage. For tasks where the number of participants cannot be known in advance, the number of participants can be estimated.

[0085] Step S423: Calculate the correlation strength between the achievement of the user's purpose and the server, and combine the achievement ratio to obtain the purpose tolerance level.

[0086] The achievement of a user's objective is sometimes not strongly dependent on the server. For example, in blockchain transaction signing (trust minimization) and cryptocurrency wallet transfer authorization, the private key performs the signing operation within the user's phone's secure chip (e.g., using the ECDSA algorithm), and the server only broadcasts the signature result, ensuring the private key never touches the network. In these cases, the correlation between the achievement of the user's objective and the server is relatively weak. The strength of the correlation between the achievement of the user's objective and the server is obtained by the server's participation percentage in the task implementation. By setting weights for both the correlation strength and the implementation percentage, the objective tolerance is calculated using a weighted summation method.

[0087] Step S424: Collect historical complaint information for the task, and calculate the average complaint rate of the server corresponding to the task based on the historical complaint information.

[0088] Step S425: Combine the target tolerance level and the average complaint rate to evaluate the user tolerance level.

[0089] In practical applications, Bayesian networks can be used to establish a probabilistic dependency model between goal tolerance and average complaint rate, inferring user tolerance through conditional probability. Higher goal tolerance and lower average complaint rate indicate higher user tolerance. Higher user tolerance corresponds to higher user acceptance, and user emotions vary depending on whether the task is completed or not. Conversely, lower user tolerance means less tolerance for the negative impact of task migration, resulting in lower task migration rate.

[0090] Based on the intensity of operational awareness, the steps for collecting task operational information and evaluating the task interaction continuity value based on this information are as follows: Step S431: Collect user refresh records during task execution, and calculate the average tolerance of different operation stages based on the refresh records.

[0091] The tolerance level for a task varies across different stages. By monitoring key user interactions during task execution (such as page refreshes, operation retries, and the frequency of impatient clicks), a user tolerance heatmap model is constructed. Taking e-commerce payment tasks as an example, when a user enters the "order submission" stage, if ≥2 refreshes are triggered within 3 seconds (tolerance threshold P95 = 1.8 seconds), the system automatically marks the tolerance coefficient for this stage as 0.15 (on a 0-1 scale, with lower values ​​indicating greater sensitivity). However, in the "product browsing" stage, refreshing 4 times per minute is still considered baseline behavior (tolerance coefficient 0.78). In other words, users can wait different amounts of time at different stages; shorter wait times indicate lower tolerance. The tolerance level for different stages is assessed by evaluating wait times.

[0092] Step S432: Obtain the operational perception intensity of different stages and establish a correlation table between operational perception intensity and average tolerance.

[0093] By mapping the operational perception intensity and average tolerance of each stage one by one, a correlation table is obtained.

[0094] Step S433: Find the average tolerance corresponding to different stages according to the association table and record it as the tolerance threshold.

[0095] Step S434: Collect the real-time tolerance of different stages, filter the stages whose real-time tolerance reaches the tolerance threshold and record them as refresh stages.

[0096] Real-time tolerance refers to the estimated waiting time when a task reaches a certain stage after migration. The tolerance level is calculated based on the estimated waiting time. If the real-time tolerance level reaches the tolerance threshold, it is determined that the user cannot continue to wait, and the stage is refreshed.

[0097] Step S435: Record the steps that ran before the refresh step as historical steps, and determine whether the refresh step should restart the historical steps.

[0098] Some steps are closely linked; if one step is refreshed, the entire process must be restarted from scratch, and all previous steps must be refreshed and restarted.

[0099] Step S436: If a historical step is restarted, the refresh step of the restarted historical step is recorded as a restart step, and the number of restart steps is counted.

[0100] Step S437: Calculate the average restart time of the restart process, count the number of restart process sequences, and combine the number of restart processes to obtain the task interaction continuity value.

[0101] In practical applications, a judgment matrix is ​​constructed using the Analytic Hierarchy Process (AHP) to determine the average restart time, the sequence number of restart stages, and the total number of restart stages. After calculating the comprehensive weights, the task interaction continuity value is evaluated. The smooth progress of a task significantly impacts user experience. Repeated refreshes and restarts during task execution cause considerable inconvenience. A longer average restart time, a higher sequence number of restart stages, and a greater number of restart stages result in a lower task interaction continuity value, as the task interaction is constantly interrupted. The sequence number of restart stages refers to their sequential number within the task. A higher sequence number indicates a greater user frustration and more inconvenience due to the interruption and restart at that point.

[0102] An energy efficiency optimization scheduling system based on load forecasting, which applies the energy efficiency optimization scheduling method based on load forecasting as described above, includes: The migration judgment module obtains the server's load prediction information and evaluates whether to migrate the task based on the load prediction information.

[0103] The matching and evaluation module, if task migration is to be performed, obtains task performance information and evaluates the server matching degree for task migration based on the task performance information.

[0104] The perception intensity module acquires task operation data and evaluates the operational perception intensity of task migration based on the task operation data.

[0105] The user acceptance module obtains historical information about the task based on the intensity of operational awareness, and evaluates the user acceptance of the task migration based on the historical information.

[0106] The migration assessment module combines server compatibility, operational awareness intensity, and user acceptance to evaluate the migration degree of the task.

[0107] The migration scheduling module determines whether the migration degree has reached the preset migration standard. If the preset migration standard is reached, the task is migrated and scheduled.

[0108] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. An energy efficiency optimization scheduling method based on load forecasting, characterized in that, Includes the following steps: Obtain server load forecast information and assess whether to migrate tasks based on the load forecast information; If a task migration is performed, the task performance information is obtained, and the server matching degree for task migration is evaluated based on the task performance information. Acquire task execution data and assess the operational awareness intensity of task migration based on the task execution data; Based on the intensity of operational awareness, historical information of the task is obtained, and the user acceptance of task migration is evaluated based on the historical information. The migration degree of the task migration is obtained by combining server compatibility, perceived operational strength, and user acceptance. Determine whether the migration degree has reached the preset migration standard. If it has, then migrate and schedule the task.

2. The energy efficiency optimization scheduling method based on load forecasting according to claim 1, characterized in that, The steps for obtaining server load forecast information and assessing whether to perform task migration based on this information are as follows: The total remaining resources of all servers are extracted based on the load prediction information. Historical usage information of the servers is collected, and the total fluctuating resources are evaluated based on the historical usage information. Determine whether the total remaining resources cover the total fluctuating resources. If they do, extract the server's independent remaining resources based on the load forecast information. Based on historical usage information, assess the server's independent fluctuation resources to determine if there are situations where the independent remaining resources cannot cover the independent fluctuation resources. If the task exists, then a task migration is performed. If the task does not exist, then a task migration is performed based on the difference between the total remaining resources and the total fluctuating resources.

3. The energy efficiency optimization scheduling method based on load forecasting according to claim 2, characterized in that, The steps for collecting historical usage information from servers and assessing the total fluctuating resources based on this information are as follows: Obtain the predicted time point and calculate the average server resource usage at the historical predicted time point as the base usage value based on historical usage information; Collect incidental events that cause fluctuations in server resources and confirm whether these incidental events will inevitably occur at the predicted time points; If an unforeseen event is certain to occur at the predicted time point, the average resource usage value of the unforeseen event is recorded as the unforeseen fluctuation value. If an unplanned event does not necessarily occur at the predicted time, then estimate the probability of the unplanned event and determine whether the probability of occurrence meets the preset probability standard. If the preset probability standard is reached, it is determined that an occasional event will occur. The server's independent fluctuation resources are obtained by summing the occasional fluctuation values ​​of all possible occasional events and the basic usage value. The total fluctuation resources are obtained by summing the independent fluctuation resources of all servers.

4. The energy efficiency optimization scheduling method based on load forecasting according to claim 1, characterized in that, If task migration is to be performed, the steps for obtaining task performance information and assessing the server compatibility for task migration based on that information are as follows: Obtain server resource information and classify the servers into migration servers and receiving servers based on the server resource information; Find the tasks for migrating servers, and select the tasks that can be migrated as the migrated tasks; Collect the running conditions of the transferable tasks, and select the receiving servers that meet the running conditions as candidate servers from the receiving servers; Collect the task functions of the transferable tasks and determine whether the task functions are implemented after the transferable tasks are migrated to the candidate server; If the task function is not implemented, the degree of reduction in task function will be statistically determined. After migrating a migratable task to a candidate server, the degree of security and performance changes of the migratable task are statistically analyzed, and the matching degree of the candidate server is obtained by combining the degree of reduction in task functionality. Choose the server with the highest matching degree as the server matching degree for task migration.

5. The energy efficiency optimization scheduling method based on load forecasting according to claim 4, characterized in that, If the task functionality is not implemented, the steps to determine the degree of reduction in task functionality are as follows: The task functions that are not implemented after the task migration are recorded as disappearing functions. The total number of task functions is counted, and the ratio of the number of disappearing functions to the total number is counted to obtain the disappearing function percentage. Collect the average usage rate of the disappearing function and record it as the function usage rate; calculate the average usage rate of the transferable tasks and record it as the total usage rate. The ratio of the usage rate of a function to the total usage rate is used to obtain the core function rate. Combined with the total usage rate, the importance of the disappearing function is obtained. The functions implemented after the task migration are recorded as existing functions, and the degree of correlation between disappearing functions and existing functions is calculated. The degree of reduction in task functionality is determined by comprehensively evaluating the percentage of disappearing functions, their importance in use, and their relevance.

6. The energy efficiency optimization scheduling method based on load forecasting according to claim 1, characterized in that, Based on the perceived intensity of operation, the steps for obtaining historical information about the task and assessing user acceptance of task migration based on this historical information are as follows: Obtain the user's historical operation information for the task, and assess the task's importance based on the historical operation information; Based on the intensity of operational awareness, historical complaint information of the task is collected, and user tolerance is assessed based on the historical complaint information. Based on the intensity of operational awareness, information on the operational stages of a task is collected, and the continuity value of task interaction is evaluated based on the operational stage information. User acceptance of task migration is obtained by combining task importance, user tolerance, and interaction continuity value.

7. The energy efficiency optimization scheduling method based on load forecasting according to claim 6, characterized in that, The steps for obtaining the user's historical operation information for a task and assessing the task's importance based on this information are as follows: Determine whether the task is an occasional task. If the task is an occasional task, collect the task probability of occasional tasks. Determine whether there is any economic loss in completing the task. If there is an economic loss, calculate the average economic loss if the task fails. The system counts the number of times users access a task before it begins, and calculates the average number of refreshes and average access duration during the task operation based on historical operation information, thus obtaining the user's task attention level. Task importance is determined by combining task probability, average economic loss, and task attention.

8. The energy efficiency optimization scheduling method based on load forecasting according to claim 6, characterized in that, Based on the perceived intensity of operation, the steps for collecting historical complaint information about the task and assessing user tolerance based on this historical complaint information are as follows: Collect the user's objective corresponding to the task execution and determine whether all users can achieve their objective. If not all tasks can achieve the user's purpose, then the percentage of purpose achieved for each task will be calculated based on historical information. The correlation between the achievement of user objectives and the server is statistically analyzed, and the objective tolerance level is obtained by combining the achievement rate. Collect historical complaint information for tasks, and calculate the average complaint rate of the server corresponding to the task based on the historical complaint information. User tolerance is assessed by combining the target tolerance level and the average complaint rate.

9. The energy efficiency optimization scheduling method based on load forecasting according to claim 6, characterized in that, Based on the intensity of operational awareness, the steps for collecting task operational information and evaluating the task interaction continuity value based on this information are as follows: When the data collection task is running, the user refreshes the record, and the average tolerance of different running stages is calculated based on the refresh record. Obtain the operational awareness intensity at different stages and establish a correlation table between operational awareness intensity and average tolerance. The average tolerance level corresponding to different stages is obtained by searching the associated table and recorded as the tolerance threshold. Collect the real-time tolerance of different stages, filter the stages whose real-time tolerance reaches the tolerance threshold and record them as refresh stages; Record the steps that ran before the refresh step as historical steps, and determine whether the refresh step should restart the historical steps; If a historical step is restarted, the refresh step of the restarted historical step will be recorded as a restart step, and the number of restart steps will be counted. The average restart time of each restart stage is calculated, the number of restart stages is counted, and the continuous value of task interaction is obtained by combining the number of restart stages.

10. An energy efficiency optimization scheduling system based on load forecasting, characterized in that, The energy efficiency optimization scheduling method based on load forecasting as described in any one of claims 1-9 includes: The migration judgment module obtains the server's load prediction information and evaluates whether to migrate the task based on the load prediction information. The matching evaluation module, if task migration is to be performed, obtains task performance information and evaluates the server matching degree of task migration based on the task performance information. The perception intensity module acquires task operation data and evaluates the operational perception intensity of task migration based on the task operation data. The user acceptance module obtains historical information about the task based on the intensity of operational awareness, and evaluates the user acceptance of the task migration based on the historical information. The migration assessment module combines server compatibility, operational awareness intensity, and user acceptance to evaluate the migration degree of the task migration. The migration scheduling module determines whether the migration degree has reached the preset migration standard. If the preset migration standard is reached, the task is migrated and scheduled.

Images