Method and system for predicting load of computing power server

Abstract

The invention discloses a computing power server load prediction method and system, and belongs to the field of data processing, the computing power server load prediction method comprises the following steps: collecting historical load data of a computing power server, and preprocessing the historical load data, the preprocessing comprising data cleaning, time window construction, and data set division; constructing an LSTM (Long Short Term Memory) model, and training the LSTM model; predicting a future computing power server load through an LSTM model; compared with the prior art, the method has the beneficial effects that the overall computing resource utilization rate is effectively improved by collecting the historical load data of the computing power server, training the LSTM model, finally predicting the future computing power server load through the LSTM model and allocating the computing resources according to the predicted data; meanwhile, abnormal tasks are recognized, and the abnormal tasks are processed in time when appearing, so that other tasks are prevented from being affected.

Description

Technical Field

[0001] The present invention belongs to the field of data processing, and in particular relates to a method and system for predicting the load of a computing power server. Background Art

[0002] Computing servers are servers designed specifically for high-performance computing. They process complex computing tasks by optimizing hardware configurations (such as multi-core CPUs, GPUs, large-capacity memory, high-speed storage, etc.) and are suitable for high-load scenarios such as artificial intelligence training, scientific simulations, and big data analysis.

[0003] Since the load of computing servers fluctuates over time (for example, there is a significant difference between business peak and off-peak periods), the computing resource allocation strategy lacks the ability to dynamically adjust. During high-load periods, overload will occur due to insufficient allocation of computing resources, while during low-load periods, computing resources will be idle due to excessive allocation, ultimately resulting in low overall computing resource utilization. If the load of computing servers can be predicted and computing resources can be allocated accordingly, the overall computing resource utilization will be effectively improved. Summary of the Invention

[0004] Based on this, it is necessary to provide a computing power server load prediction method and system to address the above problems.

[0005] The embodiment of the present invention is implemented as follows: a computing power server load prediction method includes the following steps:

[0006] Collect historical load data of computing servers and preprocess the historical load data, including data cleaning, building time windows, and dividing data sets;

[0007] Build an LSTM model and train the LSTM model;

[0008] Predict future computing server loads using the LSTM model.

[0009] In one embodiment, the present invention provides a method for predicting the load of a computing power server, wherein the method collects historical load data of the computing power server and preprocesses the historical load data. The preprocessing includes the steps of data cleaning, building a time window, and dividing the data set, specifically including:

[0010] Collect historical load data of computing servers at fixed intervals (e.g., 5 minutes). Features of historical load data include CPU utilization, task queue length, and time (whether it is a weekend).

[0011] Perform data cleaning on historical load data and use linear interpolation to fill missing values for shutdown or breakpoint data;

[0012] Build a time window, define the input window, use the historical load data of the past 36 time points (every 5 minutes, 36 time points in 3 hours) as input, define the prediction target, and predict the CPU utilization at the next 12 time points (1 hour);

[0013] Divide the data set and divide the historical load data in chronological order. The first 80% of the data is used as the training set, and the last 20% of the data is used as the test set to ensure that the test set does not contain future information of the training set to avoid data leakage.

[0014] In one embodiment, the present invention provides a method for predicting the load of a computing server, wherein the steps of constructing an LSTM model and training the LSTM model specifically include:

[0015] Build an LSTM model. The LSTM model consists of an input layer, an LSTM layer, a dropout layer, and an output layer. The input layer receives data from 36 time points. The LSTM layer has two layers. The first layer has 128 neurons and retains the time series output to capture short-term dependencies. The second layer has 64 neurons and only outputs the results of the last time step to capture long-term dependencies. The dropout layer adds 20% random neurons after each LSTM layer to prevent overfitting. The output layer outputs the predicted CPU utilization value for the next 12 time points.

[0016] Add an attention layer to the LSTM model to focus on key time points (such as periods of sudden increase in tasks);

[0017] Train the LSTM model by inputting historical load data at 36 time points in the training set and outputting predicted CPU utilization at 12 time points. Monitor the loss changes of the training set and validation set to ensure that the LSTM model is not overfitting.

[0018] In one embodiment, the present invention provides a method for predicting the load of a computing server, wherein the step of predicting the future load of the computing server using an LSTM model specifically includes:

[0019] Use a stream processing framework (such as Kafka+Flink) to obtain the latest historical load data for the 36 time points.

[0020] Data cleaning was performed on the historical load data of the latest 36 time points. For shutdown or breakpoint data, missing values were filled using linear interpolation.

[0021] The cleaned historical load data for the latest 36 time points is input into the LSTM model, which then outputs a CPU utilization prediction sequence for the next 12 time points.

[0022] If the CPU utilization peak is predicted to exceed the first threshold (such as 85%) at the next 12 time points, the computing server expansion is triggered.

[0023] In one embodiment, the present invention provides a method for predicting the load of a computing server, wherein the step of predicting the future load of the computing server using an LSTM model further includes:

[0024] Use a stream processing framework (such as Kafka + Flink) to obtain historical load data from the last two time points. If the CPU utilization peak exceeds the second threshold (such as 95%) for a period of time, check the task log to identify abnormal tasks and further determine whether the abnormal tasks are high-load processes or memory leaks. (Use top / htop or nvidia-smi to locate high-load processes and use valgrind or AddressSanitizer to detect memory leaks.)

[0025] For high-load process tasks, use containerization technology (such as Docker / Kubernetes) to isolate the problem container to prevent it from affecting other tasks; then forcibly terminate the high-load process task (you can use kill -9 or the task manager to force termination);

[0026] For memory leak tasks, generate a core dump file (gcore) for the leaking process and use memory analysis tools (gdb or MAT) to locate the leaking code segment. If it is a known issue, perform a temporary fix by replacing the dynamic library (such as LD_PRELOAD). If there is no fix, restart the service and record a status snapshot for subsequent analysis.

[0027] In one embodiment, the present invention provides a computing server load prediction system, comprising:

[0028] The data collection module is used to collect historical load data of computing servers and preprocess the historical load data. The preprocessing includes data cleaning, building time windows, and dividing data sets.

[0029] Model building and training module, used to build and train LSTM models;

[0030] The load prediction module is used to predict the future computing server load through the LSTM model.

[0031] In one embodiment, the present invention provides a computing server load prediction system, wherein the data collection module includes:

[0032] The historical load data collection unit is used to collect historical load data of computing servers at fixed time points (such as 5 minutes). The characteristics of historical load data include CPU utilization, task queue length, and time (whether it is a weekend).

[0033] The historical load data cleaning unit is used to clean the historical load data and fill in the missing values using linear interpolation for shutdown or breakpoint data;

[0034] The time window construction unit is used to construct a time window, define the input window, take the historical load data of the past 36 time points (every 5 minutes, 36 time points in 3 hours) as input, define the prediction target, and predict the CPU utilization rate at the next 12 time points (1 hour);

[0035] The data set partitioning unit is used to partition the data set and divide the historical load data in chronological order. The first 80% of the data is used as the training set, and the last 20% of the data is used as the test set to ensure that the test set does not contain future information of the training set to avoid data leakage.

[0036] In one embodiment, the present invention provides a computing server load prediction system, wherein the model building and training module includes:

[0037] The model building unit is used to build an LSTM model. The LSTM model consists of an input layer, an LSTM layer, a dropout layer, and an output layer. The input layer receives data from 36 time points. The LSTM layer has two layers. The first layer has 128 neurons and retains the time series output to capture short-term dependencies. The second layer has 64 neurons and only outputs the results of the last time step to capture long-term dependencies. The dropout layer adds 20% random neurons after each LSTM layer to prevent overfitting. The output layer outputs the predicted CPU utilization value for the next 12 time points.

[0038] The model optimization unit is used to add an attention layer to the LSTM model to focus on key time points (such as periods of sudden increase in tasks);

[0039] The model training unit is used to train the LSTM model. It inputs historical load data at 36 time points in the training set and outputs predicted CPU utilization at 12 time points. It monitors the loss changes of the training set and validation set to ensure that the LSTM model is not overfitting.

[0040] In one embodiment, the present invention provides a computing server load prediction system, wherein the load prediction module includes:

[0041] The latest data acquisition unit is used to obtain the latest historical load data for the 36 time points through a stream processing framework (such as Kafka+Flink).

[0042] The latest data cleaning unit is used to clean the historical load data of the latest 36 time points. For shutdown or breakpoint data, linear interpolation is used to fill in missing values;

[0043] The future load forecasting unit is used to input the historical load data of the latest 36 time points after data cleaning into the LSTM model and output the CPU utilization prediction sequence of the next 12 time points;

[0044] The computing power expansion unit is used to trigger the expansion of the computing power server if it is predicted that the CPU utilization peak will exceed a first threshold (such as 85%) at 12 time points in the future.

[0045] In one embodiment, the present invention provides a computing server load prediction system, wherein the load prediction module includes:

[0046] The abnormal task identification unit is used to obtain historical load data from the latest two time points through a stream processing framework (such as Kafka + Flink). If the CPU utilization peak exceeds the second threshold (such as 95%) for a period of time, the unit checks the task log to identify the abnormal task and further determines whether the abnormal task is a high-load process task or a memory leak task. (The high-load process task is further located using top / htop or nvidia-smi, and the memory leak task is detected using valgrind or AddressSanitizer.)

[0047] The high-load process task processing unit is used to isolate the problematic container using containerization technology (such as Docker / Kubernetes) to prevent it from affecting other tasks. It can also forcibly terminate the high-load process task (using kill -9 or the task manager).

[0048] The memory leak task processing unit is used to generate a core dump file (gcore) for the leaking process for memory leak tasks and locate the leaking code segment using memory analysis tools (gdb or MAT). If it is a known issue, a temporary fix is completed through dynamic library replacement (such as LD_PRELOAD). If there is no fix, the service is restarted and a status snapshot is recorded for subsequent analysis.

[0049] Compared with the existing technology, the beneficial effects of the present invention are: the present invention collects historical load data of computing servers, trains the LSTM model, and finally predicts the future computing server load through the LSTM model, allocates computing resources according to the predicted data, and effectively improves the overall computing resource utilization; at the same time, it identifies abnormal tasks and handles them in a timely manner when they occur to avoid affecting other tasks. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 A flowchart of a computing power server load prediction method provided in an embodiment of the present invention.

[0051] Figure 2 A schematic diagram of the process of collecting and processing historical load data provided by an embodiment of the present invention.

[0052] Figure 3 A schematic diagram of the process of building and training an LSTM model provided in an embodiment of the present invention.

[0053] Figure 4 A schematic diagram of the process of predicting load using an LSTM model provided in an embodiment of the present invention.

[0054] Figure 5 A schematic diagram of the process of detecting and processing abnormal tasks provided by an embodiment of the present invention.

[0055] Figure 6 A schematic diagram of a computing server load forecasting system provided in an embodiment of the present invention.

[0056] Figure 7 A schematic diagram of a data collection module provided in an embodiment of the present invention.

[0057] Figure 8 A schematic diagram of a model construction training module provided in an embodiment of the present invention.

[0058] Figure 9 This is a schematic diagram of the first part of the load forecasting module provided in an embodiment of the present invention.

[0059] Figure 10 This is a schematic diagram of the second part of the load forecasting module provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0060] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be 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 the present invention and are not intended to limit the present invention.

[0061] It is understood that the terms "first," "second," etc., used herein may be used to describe various elements, but unless otherwise specified, these elements are not limited by these terms. These terms are only used to distinguish a first element from another element. For example, a first xx script may be referred to as a second xx script, and similarly, a second xx script may be referred to as a first xx script without departing from the scope of this application.

[0062] In one embodiment, Figure 1As shown, a computing server load prediction method includes the following steps:

[0063] Step S1: Collect historical load data of computing servers and preprocess the historical load data. The preprocessing includes data cleaning, building time windows, and dividing data sets.

[0064] Step S2: constructing an LSTM model and training the LSTM model;

[0065] Step S3: predict the future computing server load through the LSTM model.

[0066] Collect historical load data of computing servers. The specific implementation method is to use the sar command in the Linux system (sysstat package needs to be installed) to record historical load data regularly, for example, collect data every 5 minutes and save it as a log file, support tracing the historical load of the past 30 days, and mark different time periods, such as Saturdays, Sundays, holidays, etc., to distinguish special time periods from regular time periods; pre-process the collected historical load data, clean the historical load data, build time windows, divide the data sets, define the input window, use the historical load data of the past 36 time points (5 minutes once, 3 hours or 36 time points) as input, define the prediction target, and predict the CPU utilization of the next 12 time points (1 hour); here, 5 minutes is used as the time point, and there is no limit in actual use The length of the time points also has no limit on how many time points can be used as input or output. The 36 time points in the historical load data in the dataset are used as input, the predicted data are the 12 time points output by the LSTM model, and the actual data are the 12 time points after the 36 time points in the historical load data. The predicted data and actual data are compared to train the LSTM model, so that the LSTM model can predict the future computing server load with more accurate results. The latest 36 time points of historical load data are obtained through a stream processing framework (such as Kafka+Flink), and these data are pre-processed and input into the LSTM model. The LSTM model outputs load forecast data for the next 12 time points. The load can be specifically expressed as CPU utilization. Computing resources are allocated according to the predicted data, effectively improving the overall computing resource utilization.

[0067] In one embodiment, Figure 2 As shown, step S1 collects historical load data of the computing server and preprocesses the historical load data. The preprocessing includes data cleaning, building a time window, and dividing the data set. Specifically, it includes:

[0068] Step S11: Collect historical load data of the computing server at fixed time points (e.g., 5 minutes). The characteristics of the historical load data include CPU utilization, task queue length, and time (whether it is a weekend).

[0069] Step S12: Clean the historical load data and fill in missing values using linear interpolation for shutdown or breakpoint data.

[0070] Step S13: Build a time window, define the input window, use the historical load data of the past 36 time points (5 minutes every time, 3 hours, or 36 time points) as input, define the prediction target, and predict the CPU utilization rate at the next 12 time points (1 hour);

[0071] Step S14, divide the data set, divide the historical load data in chronological order, use the first 80% of the data as the training set, and the last 20% of the data as the test set to ensure that the test set does not contain future information of the training set to avoid data leakage.

[0072] The specific process of step S12 is:

[0073] Detect missing values and check timestamp continuity: Ensure data is arranged at fixed intervals (e.g., 5 minutes). If there are timestamp jumps, interpolate the missing time points. Mark missing values: Use pandas to identify NaN or placeholders (e.g., -999).

[0074] Resample the time series. If the timestamps are discontinuous, you need to fill the time axis first.

[0075] Missing values are filled using linear interpolation. For single-point missing values, the missing value is calculated using linear interpolation between the previous valid value (prev) and the next valid value (next). For consecutive missing values, if valid data exists before and after the missing segment, the entire missing segment is treated as a linear transition between the beginning and the end. Edge case handling: For missing data at the beginning, if the first data point is missing and forward interpolation is not possible, a NaN value can be temporarily retained or filled with the next valid value. For missing data at the end, if the last data point is missing, the value is filled with the next valid value before or after, or NaN is retained.

[0076] The specific code can be:

[0077] import pandas as pd

[0078] # 1. Create a time series with missing values

[0079] timestamps = pd.date_range(start='2025-03-01 00:00', periods=6, freq='5T')

[0080] cpu_usage = [65.2, 68.5, None, None, 72.3, 75.0]

[0081] df = pd.DataFrame({'timestamp': timestamps, 'cpu_usage': cpu_usage})

[0082] df.set_index('timestamp', inplace=True)

[0083] # 2. Resample and fill the timeline (to ensure time continuity)

[0084] full_range = pd.date_range(start=df.index.min(), end=df.index.max(),freq='5T')

[0085] df = df.reindex(full_range)

[0086] # 3. Linear interpolation to fill missing values

[0087] df['cpu_usage'] = df['cpu_usage'].interpolate(method='linear')

[0088] # Output results

[0089] print(df)

[0090] In one embodiment, Figure 3 As shown, the step S2, constructing an LSTM model and training the LSTM model, specifically includes:

[0091] Step S21, constructing an LSTM model, which includes an input layer, an LSTM layer, a dropout layer, and an output layer; the input layer receives data from 36 time points; the LSTM layer has two layers, the first layer has 128 neurons, retains the time series output, and captures short-term dependencies; the second layer has 64 neurons, and only outputs the results of the last time step to capture long-term dependencies; the dropout layer adds 20% random neurons after each LSTM layer to prevent overfitting; the output layer outputs the predicted CPU utilization value for the next 12 time points;

[0092] Step S22: Add an attention layer based on the LSTM model to focus on key time points (such as periods of sudden increase in tasks);

[0093] In step S23, the LSTM model is trained by inputting historical load data at 36 time points of the training set and outputting predicted CPU utilization at 12 time points. The loss changes of the training set and the validation set are monitored to ensure that the LSTM model is not overfitted.

[0094] The introduction of an attention layer in the LSTM model enables the model to dynamically focus on key time points in the historical time series (such as periods of CPU spikes), thereby improving its ability to capture sudden load patterns. Through weight distribution, historical periods with significant impact on the forecast target (such as load changes 30 minutes before a task spike) are amplified, enhancing key features. This alleviates the LSTM model's forgetfulness caused by long sequences by directly linking remote key events with the current forecast, optimizing long-sequence dependencies. By visualizing attention weights, the model's decision-making basis can be analyzed (for example, a sudden load spike triggered by a memory leak at a specific moment is highlighted), improving interpretability.

[0095] In one embodiment, Figure 4 As shown, step S3, in which the future computing server load is predicted using the LSTM model, specifically includes:

[0096] Step S31: Obtain the latest 36 historical load data at time points through a stream processing framework (such as Kafka+Flink).

[0097] Step S32: Clean the historical load data of the latest 36 time points and fill in missing values using linear interpolation for shutdown or breakpoint data.

[0098] Step S33: Input the cleaned historical load data of the latest 36 time points into the LSTM model, and output a CPU utilization prediction sequence for the next 12 time points.

[0099] In step S34, if it is predicted that the CPU utilization peak will exceed a first threshold (such as 85%) at 12 time points in the future, the computing server capacity expansion is triggered.

[0100] If the computing server capacity has been expanded three times within 10 minutes, further expansion operations will be suspended, an alarm will be triggered, and manual intervention will be required to avoid system anomalies or failures. This can cause multiple expansions in a short period of time to fail to effectively resolve the problem. For example, the newly added server may not be properly registered with the load balancer, or there may be a bug in the application, resulting in increased resource waste instead of increased processing capacity.

[0101] In one embodiment, Figure 5 As shown, the step S3, in which the future computing power server load is predicted by the LSTM model, further includes:

[0102] Step S35: Use a stream processing framework (such as Kafka + Flink) to obtain the historical load data for the last two time points. If the CPU utilization peak exceeds a second threshold (such as 95%) for a duration of one time point, check the task log to identify the abnormal task, and further determine whether the abnormal task is a high-load process task or a memory leak task (further use top / htop or nvidia-smi to locate the high-load process task, and use valgrind or AddressSanitizer to detect the memory leak task).

[0103] Step S36: For high-load process tasks, use containerization technology (such as Docker / Kubernetes) to isolate the problem container to prevent it from affecting other tasks; then forcibly terminate the high-load process task (you can use kill -9 or the task manager to forcibly terminate it).

[0104] Step S37: For memory leak tasks, generate a core dump file (gcore) for the leaking process and locate the leaking code segment using a memory analysis tool (gdb or MAT). If it is a known issue, perform a temporary fix by replacing the dynamic library (such as LD_PRELOAD). If there is no fix, restart the service and record a status snapshot for subsequent analysis.

[0105] When handling high-load processes, you can quickly control resource usage and reduce system risks in the following two ways:

[0106] Containerized Isolation Technology: Leverages Docker or Kubernetes to isolate resources and dynamically schedule problematic tasks. By limiting container CPU and memory quotas (e.g., cgroups), this prevents individual containers from exceeding resource limits and impacting host stability. Combined with Kubernetes' Pod eviction policy, this technology automatically migrates abnormal containers to idle nodes, achieving fault isolation and self-healing. This technology is suitable for production environments where service continuity must be guaranteed.

[0107] Forcibly terminate the abnormal process: Use operating system commands (such as kill -9 PID) or the Task Manager to directly terminate the runaway process, immediately releasing occupied CPU resources. This method is suitable for scenarios where resource exhaustion occurs suddenly and tasks can be interrupted. This method is an emergency measure and may cause task interruption, but it can quickly stop the loss.

[0108] The two methods can be used in combination, isolating first and then terminating, to avoid resource contention and reduce the risk of data loss. They can also be used separately.

[0109] In one embodiment, Figure 6 As shown, a computing server load prediction system includes:

[0110] Data collection module 1 is used to collect historical load data of computing servers and preprocess the historical load data, including data cleaning, building time windows, and dividing data sets;

[0111] Model building and training module 2 is used to build and train the LSTM model;

[0112] Load prediction module 3 is used to predict the future computing server load through the LSTM model.

[0113] The LSTM model is trained based on historical load data, making its output more accurate in predicting CPU utilization. By integrating historical load data from the most recent 36 time points, the LSTM model outputs a sequence of CPU utilization predictions for the next 12 time points. The number of time points for integrating historical load data and outputting CPU utilization can be arbitrarily set. For example, integrating historical load data from 10 time points can produce a sequence of CPU utilization predictions for the next three time points.

[0114] In one embodiment, Figure 7 As shown, the data collection module 1 includes:

[0115] The historical load data collection unit 11 is used to collect historical load data of the computing power server at fixed time points (such as 5 minutes). The characteristics of the historical load data include CPU utilization, task queue length, and time (whether it is a weekend).

[0116] The historical load data cleaning unit 12 is used to clean the historical load data and fill in the missing values using linear interpolation for shutdown or breakpoint data;

[0117] The time window construction unit 13 is used to construct a time window, define an input window, take the historical load data of the past 36 time points (5 minutes every time, 3 hours, i.e. 36 time points) as input, define a prediction target, and predict the CPU utilization rate at the next 12 time points (1 hour);

[0118] The data set partitioning unit 14 is used to partition the data set, and divide the historical load data in chronological order, with the first 80% of the data as the training set and the last 20% of the data as the test set, to ensure that the test set does not contain future information of the training set and avoid data leakage.

[0119] The data volume of the training set, which accounts for 80%, is usually sufficient to capture long-term trends (such as seasonality and cyclicality) while avoiding overfitting; the test set, which accounts for 20%, provides sufficient future data to verify the generalization ability of the model, and the consumption of computing resources is controllable.

[0120] In one embodiment, Figure 8As shown, the model building training module 2 includes:

[0121] Model construction unit 21 is used to build an LSTM model. The LSTM model includes an input layer, an LSTM layer, a dropout layer, and an output layer. The input layer receives data at 36 time points. The LSTM layer has two layers. The first layer has 128 neurons, which retains the time series output and captures short-term dependencies. The second layer has 64 neurons, which only outputs the results of the last time step and captures long-term dependencies. The dropout layer adds 20% random neurons after each LSTM layer to prevent overfitting. The output layer outputs the predicted CPU utilization value for the next 12 time points.

[0122] Model optimization unit 22, used to add an attention layer based on the LSTM model to focus on key time points (such as periods of sudden increase in tasks);

[0123] The model training unit 23 is used to train the LSTM model, input the historical load data of 36 time points in the training set, and output the predicted CPU utilization at 12 time points; monitor the loss changes of the training set and the validation set to ensure that the LSTM model is not overfitted.

[0124] Without the DROPOUT layer, some neurons may become overly dependent on specific features or time steps (such as data at a few time points in an LSTM model), resulting in decreased model generalization. The DROPOUT layer randomly discards neurons, forcing the network to independently learn valid features, avoiding over-reliance on a small number of neurons and thus preventing overfitting.

[0125] In one embodiment, Figure 9 As shown, the load forecasting module 3 includes:

[0126] The latest data acquisition unit 31 is used to obtain the latest historical load data at 36 time points through a stream processing framework (such as Kafka+Flink).

[0127] The latest data cleaning unit 32 is used to clean the historical load data of the latest 36 time points and fill in the missing values using linear interpolation for shutdown or breakpoint data;

[0128] The future load prediction unit 33 is used to input the latest 36 time point historical load data after data cleaning into the LSTM model and output a CPU utilization prediction sequence for the next 12 time points;

[0129] The computing power expansion unit 34 is used to trigger the expansion of the computing power server if it is predicted that the CPU utilization peak will exceed a first threshold (such as 85%) at 12 time points in the future.

[0130] The functions of the latest data acquisition unit 31 and the latest data cleaning unit 32 are similar to those in the data collection module 1, except that they acquire the latest 36 time point historical load data and perform data cleaning on them.

[0131] In one embodiment, Figure 10 As shown, the load forecasting module 3 includes:

[0132] The abnormal task identification unit 35 is configured to obtain the historical load data of the latest two time points through a stream processing framework (such as Kafka + Flink). If the CPU utilization peak exceeds a second threshold (such as 95%) for a duration of one time point, the abnormal task is identified by checking the task log, and further determining whether the abnormal task is a high-load process task or a memory leak task (further using top / htop or nvidia-smi to locate the high-load process task, and using valgrind or AddressSanitizer to detect the memory leak task).

[0133] The high-load process task processing unit 36 is used to use containerization technology (such as Docker / Kubernetes) to isolate the problem container for the high-load process task to prevent it from affecting other tasks; and forcibly terminate the high-load process task (which can be forced to terminate by using kill -9 or the task manager).

[0134] The memory leak task processing unit 37 is used to generate a core dump file (gcore) for the leaking process for memory leak tasks, locate the leaking code segment through memory analysis tools (gdb or MAT); if it is a known problem, complete a temporary repair through dynamic library replacement (such as LD_PRELOAD); if there is no repair solution, restart the service and record a status snapshot for subsequent analysis.

[0135] The memory leak task processing first uses the core dump file (gcore) to generate a complete memory snapshot of the process, and uses memory analysis tools (gdb or MAT) to analyze the heap memory allocation pattern and locate the code segment where the memory is not released. If the leak point is confirmed to be a known defect (such as a third-party library vulnerability), the repaired dynamic library is injected through dynamic library replacement (such as LD_PRELOAD) to overwrite the original function, achieving a non-stop hot repair. If the problem cannot be solved immediately, the service is proactively restarted to release the leaked memory, and snapshot information such as the stack and memory mapping at the time of the failure is saved, providing complete on-site data for subsequent root cause analysis and code repair. This takes into account both the accuracy of problem diagnosis and the guarantee of service availability, avoiding the difficulty of reproducing the problem due to blind restart, and quickly restoring business in an emergency.

[0136] It should be understood that, although the various steps in the flow chart of each embodiment of the present invention are shown in sequence according to the indication of the arrows, these steps are not necessarily performed in sequence according to the order indicated by the arrows. Unless otherwise specified herein, the execution of these steps is not strictly limited in order, and these steps can be performed in other orders. Moreover, at least a portion of the steps in each embodiment may include a plurality of sub-steps or a plurality of stages, and these sub-steps or stages are not necessarily performed at the same time, but can be performed at different times, and the execution order of these sub-steps or stages is not necessarily performed in sequence, but can be performed in turn or alternately with at least a portion of other steps or sub-steps or stages of other steps.

[0137] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware through a computer program. The program can be stored in a non-volatile computer-readable storage medium. When executed, the program can include the processes of the above-described method embodiments. Any reference to memory, storage, database, or other media used in the various embodiments provided herein may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct RAMbus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM).

[0138] The technical features of the above-mentioned embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above-mentioned embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0139] The above-described embodiments merely illustrate several implementations of the present invention, and while their descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art would be able to make numerous variations and improvements without departing from the spirit of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be determined by the appended claims.

[0140] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

[0141] In addition, it should be understood that although this specification is described in terms of implementation methods, not every implementation method contains only one independent technical solution. This narrative method of the specification is only for the sake of clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment can also be appropriately combined to form other implementation methods that can be understood by those skilled in the art.

Claims

1. A computing server load prediction method, characterized in that: The computing power server load prediction method includes the following steps: Collect historical load data of computing servers and preprocess the historical load data, including data cleaning, building time windows, and dividing data sets; Build an LSTM model and train the LSTM model; Predict future computing server loads using the LSTM model.

2. The computing server load prediction method according to claim 1, characterized in that: The historical load data of the computing power server is collected and preprocessed. The preprocessing includes data cleaning, building a time window, and dividing the data set. Specifically, the following steps are included: Collect historical load data of computing servers at fixed time points. The characteristics of historical load data include CPU utilization, task queue length, and time. Perform data cleaning on historical load data and use linear interpolation to fill missing values for shutdown or breakpoint data; Build a time window, define the input window, use the historical load data of the past 36 time points as input, define the prediction target, and predict the CPU utilization at the next 12 time points; Divide the data set and divide the historical load data in chronological order. The first 80% of the data is used as the training set, and the last 20% of the data is used as the test set to ensure that the test set does not contain future information of the training set to avoid data leakage.

3. The computing server load prediction method according to claim 1, characterized in that: The steps of constructing the LSTM model and training the LSTM model specifically include: Build an LSTM model. The LSTM model consists of an input layer, an LSTM layer, a dropout layer, and an output layer. The input layer receives data from 36 time points. The LSTM layer has two layers. The first layer has 128 neurons and retains the time series output to capture short-term dependencies. The second layer has 64 neurons and only outputs the results of the last time step to capture long-term dependencies. The dropout layer adds 20% random neurons after each LSTM layer to prevent overfitting. The output layer outputs the predicted CPU utilization value for the next 12 time points. Add an attention layer to the LSTM model to focus on key time points; Train the LSTM model by inputting historical load data at 36 time points in the training set and outputting predicted CPU utilization at 12 time points. Monitor the loss changes of the training set and validation set to ensure that the LSTM model is not overfitting.

4. The computing server load prediction method according to any one of claims 1 to 3, characterized in that: The step of predicting the future computing server load using the LSTM model specifically includes: Obtain the latest 36 historical load data points through the stream processing framework; Data cleaning was performed on the historical load data of the latest 36 time points. For shutdown or breakpoint data, missing values were filled using linear interpolation. The cleaned historical load data for the latest 36 time points is input into the LSTM model, which then outputs a CPU utilization prediction sequence for the next 12 time points. If the CPU utilization peak is predicted to exceed the first threshold at 12 time points in the future, the computing server expansion is triggered.

5. The computing server load prediction method according to claim 4, characterized in that: The step of predicting the future computing power server load using the LSTM model further includes: Use the stream processing framework to obtain historical load data from the last two time points. If the CPU utilization peak exceeds the second threshold for a period of time, check the task log to identify abnormal tasks and further determine whether the abnormal task is a high-load process task or a memory leak task. For high-load process tasks, use containerization technology to isolate the problem container to prevent it from affecting other tasks; then forcefully terminate the high-load process task; For memory leak tasks, a core dump file is generated for the leaking process, and the leaking code segment is located using memory analysis tools. If it is a known issue, a temporary fix is completed by replacing the dynamic library. If there is no fix, the service is restarted and a status snapshot is recorded for subsequent analysis.

6. A computing server load prediction system, characterized in that: include: The data collection module is used to collect historical load data of computing servers and preprocess the historical load data. The preprocessing includes data cleaning, building time windows, and dividing data sets. Model building and training module, used to build and train LSTM models; The load prediction module is used to predict the future computing server load through the LSTM model.

7. The computing server load prediction system according to claim 6, characterized in that: The data collection modules include: The historical load data collection unit is used to collect historical load data of computing servers at fixed time points. The characteristics of historical load data include CPU utilization, task queue length, and time. The historical load data cleaning unit is used to clean the historical load data and fill in the missing values using linear interpolation for shutdown or breakpoint data; The time window construction unit is used to construct a time window, define the input window, take the historical load data of the past 36 time points as input, define the prediction target, and predict the CPU utilization rate at the next 12 time points; The data set partitioning unit is used to partition the data set and divide the historical load data in chronological order. The first 80% of the data is used as the training set, and the last 20% of the data is used as the test set to ensure that the test set does not contain future information of the training set to avoid data leakage.

8. The computing server load prediction system according to claim 6, characterized in that: The model building and training modules include: The model building unit is used to build an LSTM model. The LSTM model consists of an input layer, an LSTM layer, a dropout layer, and an output layer. The input layer receives data from 36 time points. The LSTM layer has two layers. The first layer has 128 neurons and retains the time series output to capture short-term dependencies. The second layer has 64 neurons and only outputs the results of the last time step to capture long-term dependencies. The dropout layer adds 20% random neurons after each LSTM layer to prevent overfitting. The output layer outputs the predicted CPU utilization value for the next 12 time points. Model optimization unit, used to add an attention layer based on the LSTM model to focus on key time points; The model training unit is used to train the LSTM model. It inputs historical load data at 36 time points in the training set and outputs predicted CPU utilization at 12 time points. It monitors the loss changes of the training set and validation set to ensure that the LSTM model is not overfitting.

9. The computing server load prediction system according to any one of claims 6 to 8, characterized in that: The load forecasting module includes: The latest data acquisition unit is used to obtain the latest 36 time points of historical load data through the stream processing framework; The latest data cleaning unit is used to clean the historical load data of the latest 36 time points. For shutdown or breakpoint data, linear interpolation is used to fill in missing values; The future load forecasting unit is used to input the historical load data of the latest 36 time points after data cleaning into the LSTM model and output the CPU utilization prediction sequence of the next 12 time points; The computing power expansion unit is used to trigger the expansion of the computing power server if it is predicted that the CPU utilization peak will exceed the first threshold at 12 time points in the future.

10. The computing server load prediction system according to claim 9, characterized in that: The load forecasting module includes: An abnormal task identification unit is used to obtain the historical load data of the latest two time points through the stream processing framework. If the CPU utilization peak exceeds the second threshold for a duration of one time point, the abnormal task is identified by checking the task log and further determining whether the abnormal task is a high-load process task or a memory leak task; The high-load process task processing unit is used to isolate the problem container using containerization technology for high-load process tasks to prevent them from affecting other tasks; and then forcibly terminate the high-load process tasks; The memory leak task processing unit is used to generate core dump files for the leaking process for memory leak tasks and locate the leaking code segment through memory analysis tools. If it is a known problem, a temporary fix is completed by replacing the dynamic library. If there is no fix solution, the service is restarted and a status snapshot is recorded for subsequent analysis.

Images