Container resource quota recommendation method and system for Java program optimization
By combining JVM memory management features and LSTM model to predict the heap memory usage of Java application, the problem of poor Java program resource quota recommendation in the existing technology is solved, more accurate resource quota recommendation is achieved, and resource utilization and the operation efficiency of Java applications are improved.
Patent Information
- Application Number
- CN202411887596.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-20
- Publication Date
- 2025-04-15
AI Technical Summary
The existing container resource quota recommendation method is not effective when targeting Java programs, resulting in waste of resources and degradation of performance.
By combining the memory management characteristics of JVM and the actual running data of Java applications, the JVM heap memory usage is predicted using the LSTM model, so as to accurately calculate the request and limit quota of CPU and memory.
It realizes more accurate resource quota recommendations, improves resource utilization, reduces the impact of JVM memory waste and frequent GC on performance, and ensures efficient operation of Java programs in containerized environments.
Smart Images

Figure CN119829204A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer technology, and in particular to a container resource quota recommendation method and system for optimizing Java programs. Background Art
[0002] In recent years, with the rapid development of cloud computing technology, it has become an inevitable trend for enterprises to migrate their businesses to the cloud. However, with the increase in the number of businesses on the cloud, the utilization rate of system resources has not been significantly improved. According to a 2023 Kubernetes cluster resource report, among the one billion Kubernetes cluster containers in the world, 59% of the containers have no CPU quota set, 49% of the containers have no memory quota configured, an average of 69% of the CPU quota is not used, and 18% of the memory resources are unused. These data show that there is a serious waste of resource allocation for many containers.
[0003] In order to optimize the resource utilization of the cluster, it is critical to accurately configure container resource quotas. However, the current resource quota recommendation method mainly relies on the analysis of general monitoring data such as CPU and memory in the container to give quota recommendations. Although this method solves the problem of resource allocation to a certain extent, it is not ideal for certain types of applications, such as Java programs.
[0004] Although the existing quota recommendation method based on container general CPU and memory monitoring data is universal, it has obvious shortcomings in the containerized scenario of Java programs. Java programs run on JVM (Java Virtual Machine), which manages memory through garbage collection mechanism (GC), so that Java programs will occupy actual unused memory resources during operation, such as unused heap memory, temporary memory that has not been recycled, and buffer memory.
[0005] Due to the characteristics of JVM, existing quota recommendation methods usually overestimate the actual memory requirements of Java programs, resulting in the allocation of memory quotas exceeding actual needs. This not only causes a waste of resources, but also may cause resource competition problems. In particular, when memory resources are tight, frequent GC operations by JVM will significantly affect the running efficiency of Java programs. In addition, existing methods do not take into account the dynamic memory management characteristics of JVM and the unique resource requirements of Java programs, making it difficult to provide accurate resource quota recommendations.
[0006] To solve these problems, a container resource quota recommendation method specifically for Java programs is needed. Summary of the invention
[0007] The purpose of the present invention is to provide a container resource quota recommendation method and system optimized for Java programs, which accurately calculates and recommends CPU and memory request and limit quotas for Java applications running in a Kubernetes cluster by combining the memory management characteristics of the JVM and the actual operation data of the application. The method can effectively avoid resource waste and application performance degradation caused by unreasonable resource quota settings, and ensure the efficient operation of Java programs in a containerized environment.
[0008] In order to solve the above technical problems, the present invention provides a container resource quota recommendation method for optimizing Java programs, comprising the following steps:
[0009] Obtain monitoring data; the monitoring data includes CPU usage and memory usage;
[0010] Recommend CPU resource quotas based on CPU usage;
[0011] Recommend memory resource quotas based on memory usage.
[0012] Preferably, recommending a memory resource quota based on memory usage specifically includes the following steps:
[0013] Determine the memory request value based on the maximum memory usage;
[0014] Get JVM monitoring indicators and OOM data based on memory usage;
[0015] According to the memory request value and JVM monitoring indicators, the JVM addition value and JVM reduction value are obtained;
[0016] The memory request is calculated based on the memory request value, JVM addition value, and JVM reduction value.
[0017] The memory limit is calculated based on the memory request value and OOM data.
[0018] Preferably, according to the memory request value and the JVM monitoring index, the JVM addition value and the JVM reduction value are obtained, which specifically includes the following steps:
[0019] Extract indicator features from JVM monitoring indicators; the indicator features include time features, statistical features, hysteresis features, rolling maximum values, and filling NaN values;
[0020] After scaling and sequence construction of indicator features, the features are input into the trained LSTM model to obtain the heap memory usage prediction results;
[0021] Based on the heap memory usage prediction results, the JVM addition value and JVM reduction value are calculated.
[0022] Preferably, the LSTM model includes an input layer, an LSTM layer, an output layer, a loss function and an optimizer, and an early stopping mechanism;
[0023] The input layer is used to accept input data of shape time steps and number of features;
[0024] The LSTM layer is set with 50 LSTM units and the activation function is ReLU, which is used to capture long-term dependencies and nonlinear relationships in time series;
[0025] The output layer is a single fully connected layer that outputs the predicted value of future heap usage;
[0026] Loss function and optimizer use mean square error as loss function and Adam optimizer for parameter optimization;
[0027] The early stopping mechanism sets the monitoring indicator as the loss of the validation set, and stops training if there is no improvement for 10 consecutive epochs.
[0028] Preferably, according to the heap memory usage prediction result, the JVM addition value and the JVM reduction value are calculated, which specifically includes the following steps:
[0029] Extract the maximum heap usage during the prediction period from the heap memory usage prediction result;
[0030] If Heap pre / jvm_memory_bytes_max{area="heap"}>0.7, then calculate:
[0031] JVM add =Heap pre / jvm_memory_bytes_committed-0.7
[0032] If Heap pre / jvm_memory_bytes_max{area="heap"}>0.4, then calculate:
[0033] JVM sub =0.4-Heap pre / jvm_memory_bytes_max{area="heap"}
[0034] Where: Heap pre is the maximum heap usage during the forecast period;
[0035] jvm_memory_bytes_used{area="heap"} is the actual usage of heap memory;
[0036] jvm_memory_bytes_committed is the amount of committed heap memory;
[0037] JVM add Add values to the JVM;
[0038] JVM sub Decrement the value for the JVM.
[0039] Preferably, the calculation formula of the memory request is:
[0040] M request =M max *(1+JVM add +JVM sub )
[0041] Where: M request M is the memory request; max It is the memory request value;
[0042] The calculation formula for the memory limit is:
[0043] M limit =M request *(1+M buffer )+M oom
[0044] Where: M limit M is the memory limit; buffer is the memory buffer value; M oom To prevent OOM, the memory value increases;
[0045] The memory increase value M to prevent OOM oom The calculation formula is:
[0046] M oom =MAX(M k *P b ,M min )
[0047] Where: M k The memory used when the container is killed; P b is the percentage buffer value; M min Minimum memory increase to prevent OOM.
[0048] Preferably, obtaining monitoring data specifically includes the following steps:
[0049] By requesting the API of the prometheus instance installed in the kubernetes cluster, we can obtain the workload and its corresponding Pod information, and establish the relationship between the workload, Pod and container.
[0050] Get the container resource quota set by the user;
[0051] Collect the CPU usage and memory usage of the container.
[0052] Preferably, after acquiring the monitoring data, the following steps are also included:
[0053] Preprocess the monitoring data:
[0054] For CPU usage, statistics are collected every 5 minutes over the past 7 days, and the 5-minute average is calculated to generate the CPU time series;
[0055] For memory usage, take the maximum value in the past 7 days as the maximum memory usage.
[0056] Preferably, the CPU resource quota recommendation is performed according to the CPU usage, specifically including the following steps:
[0057] Take the 95% percentile of CPU usage as the minimum resource requirement CPU request;
[0058] The 99th percentile of CPU usage is taken as the maximum resource requirement CPU limit.
[0059] The present invention also provides a container resource quota recommendation system optimized for Java programs, comprising:
[0060] An acquisition module is used to acquire monitoring data; the monitoring data includes CPU usage and memory usage;
[0061] CPU resource quota recommendation module, used to recommend CPU resource quotas based on CPU usage;
[0062] The memory resource quota recommendation module is used to recommend memory resource quotas based on memory usage.
[0063] Compared with the prior art, the present invention has the following beneficial effects:
[0064] 1. Accurate container resource quota recommendation to improve resource utilization:
[0065] Based on the running characteristics and actual monitoring data of Java programs, the present invention accurately predicts the peak value of JVM heap memory usage through the LSTM model, and provides a more accurate CPU and memory quota recommendation method. Compared with traditional methods, it can more accurately predict the resource requirements of Java programs, avoid waste and shortage of resources, and significantly improve the resource utilization of Kubernetes clusters.
[0066] 2. Dynamically adjust container resource quotas to improve application performance:
[0067] Through the dynamic adjustment strategy of the present invention, the resource quota of the container can be automatically adjusted as the application running state changes. In particular, the management of memory resources can effectively reduce the risk of OOM and avoid application crashes caused by insufficient memory. This real-time quota optimization strategy can improve the stability and operating efficiency of Java applications in a containerized environment.
[0068] 3. Reduce JVM memory waste and improve GC efficiency:
[0069] Since Java programs run on JVM, the present invention optimizes the allocation of memory resources by deeply analyzing and monitoring the memory usage of JVM. In particular, by dynamically adjusting the memory request value, the impact of unused memory and frequent GC operations on application performance is reduced, thereby improving memory utilization and program response speed.
[0070] 4. Solve the problem of Java program resource allocation and improve the performance of enterprise cloud applications:
[0071] This invention focuses on solving the resource quota problem of Java programs in containerized environments, and provides a more refined quota configuration method by combining JVM characteristics and actual operation data. This not only helps reduce the waste of resources in cloud applications, but also improves the overall performance of applications, especially for resource-sensitive Java applications. BRIEF DESCRIPTION OF THE DRAWINGS
[0072] The specific implementation modes of the present invention are further described in detail below with reference to the accompanying drawings.
[0073] Figure 1 It is a flow chart of a method for recommending container resource quotas optimized for Java programs according to the present invention;
[0074] Figure 2 Recommended quotas for CPU usage and memory usage DETAILED DESCRIPTION
[0075] Many specific details are set forth in the following description to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of the present invention, so the present invention is not limited to the specific implementation disclosed below.
[0076] The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.
[0077] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".
[0078] The present invention is further described in detail below in conjunction with the accompanying drawings:
[0079] Embodiment 1, a container resource quota recommendation method for optimizing Java programs, the method can provide more accurate CPU and memory quota recommendations based on the running characteristics of Java programs, thereby improving resource utilization and optimizing application performance, such as Figure 1 As shown, the architecture is as follows:
[0080] 1. The application runs as a container on the host machine.
[0081] 2. Kubelet monitors container metrics through cAdvisor.
[0082] 3. Prometheus obtains indicators from kubelet and stores indicator learning.
[0083] 4. The quota recommender of the present invention reads container indicators from prometheus, summarizes and analyzes them to obtain the recommended value of container quota.
[0084] like Figure 2 As shown, the container resource quota recommendation method of the present invention specifically includes the following steps:
[0085] 1. Allow the container to run in the environment with normal traffic for at least 7 days to accumulate monitoring data. Obtain and preprocess the monitoring data to obtain workload, Pod and its corresponding container information through the monitoring data, and calculate the average CPU usage and maximum memory usage of the container in the past 7 days.
[0086] 2. Recommended CPU resource quotas:
[0087] (1) Calculate the 95th percentile as the CPU request value
[0088] (2) Calculate the 99th percentile as the CPU limit value
[0089] 3. Recommendations for memory resource quotas:
[0090] (1) Calculate the maximum memory value during the 7-day monitoring period as the request value
[0091] (2) Combined with the memory management features of the JVM, further adjust the memory request value.
[0092] (3) Combine OOM data and request value to calculate the limit value.
[0093] The above steps are as follows:
[0094] 1. Monitoring Data Acquisition and Preprocessing
[0095] In the present invention, the acquisition and preprocessing of monitoring data are key steps to achieve resource quota recommendation:
[0096] Data acquisition: By requesting the prometheus instance API installed in the kubernetes cluster, use the kube_replicaset_owner and kube_pod_owner indicators to obtain the workload and its corresponding Pod information, and use kube_pod_container_info to establish the relationship between the workload and the Pod and container. Use the kube_pod_container_resource_limits and kube_pod_container_resource_requests indicators to obtain the container resource quota set by the user. The CPU usage and memory usage of the container are collected through the container_cpu_usage_seconds_total and container_memory_rss indicators. Based on the memory usage, JVM monitoring indicators and OOM data can be obtained; JVM monitoring indicators include actual heap memory usage, committed heap memory, maximum heap memory and other data; OOM data includes the memory M used when the container is killed. k And other data.
[0097] Data preprocessing: Process the monitoring data of the past 7 days. For CPU usage, count it every 5 minutes and calculate the 5-minute average; for memory usage, take the maximum value in 7 days as a reference. For multiple instances, take the maximum value of CPU usage in all instances for further analysis.
[0098] 2. CPU resource quota recommendation
[0099] In the CPU resource quota recommendation, the CPU request and limit are calculated using the time series analysis method:
[0100] (1) CPU request: The 95th percentile of the preprocessed CPU time series is taken as the recommended value to ensure that the CPU request can meet the application requirements during most of the running time and avoid resource waste.
[0101] (2) CPU limit: The 99th percentile of the preprocessed CPU time series is taken as the recommended value of the CPU limit to cope with CPU usage peaks in a short period of time and prevent performance degradation due to CPU resource exhaustion.
[0102] 3. Memory resource quota recommendation
[0103] The memory resource quota recommendation is divided into two parts: memory request and memory limit.
[0104] (1) Memory request: Basic memory recommendation. The basic memory request value M is determined based on the maximum memory usage. max . Analyze JVM monitoring, such as heap memory and GC frequency adjustment recommendation values to get M request JVM specific added value JVM add and JVM decreases the value JVM sub See the next chapter for the calculation of .
[0105] M request =M max *(1+JVM add +JVM sub )
[0106] (2) Memory limit: Combine the container's OOM data and add some buffer according to the configuration to reduce the occurrence of OOM. The formula is as follows:
[0107] M limit =M request *(1+M buffer )+M oom
[0108] OOM detection:
[0109] The indicator container_oom_events_total obtains the time when the container is OOM Killed.
[0110] The additional memory margin required is calculated using the following formula:
[0111] M oom =MAX(M k *P b ,M min )
[0112] in:
[0113] M oom : Prevent OOM memory from increasing value;
[0114] M k : The memory used when the container is killed;
[0115] P b : Percent buffer value, default value is 10%;
[0116] M min : The minimum memory increase value to prevent OOM, because the original memory limit may be very small, resulting in the adjusted program still OOM, the default value is 100MiB;
[0117] M buffer: In order to reduce the sudden memory demand of the program and cause OOM, it is necessary to configure a buffer for limit, that is, M buffer , the default value is 10% and can be configured.
[0118] The JVM memory optimization process in step 2 above is:
[0119] Since the JVM will occupy memory that is not actually used (such as unused heap memory, memory that has not been recycled, and buffer memory) when the program is running, the recommended memory quota of the Java program is higher than the actual one. On the contrary, if the available memory margin is small, the JVM will frequently perform GC, affecting the running efficiency of the main program.
[0120] According to IBM's JAVA SDK documentation, the garbage collector adjusts the heap size to keep the occupancy between 40% and 70% for the following reasons:
[0121] (1) A heap occupancy greater than 70% will result in more frequent GC cycles, resulting in reduced performance.
[0122] (2) A heap occupancy of less than 40% means infrequent GC cycles. However, these cycles can last longer than necessary, resulting in longer pause times and reduced performance.
[0123] Based on this, the memory quota recommendation strategy using JVM indicators is also designed around allowing the heap occupancy rate to fluctuate within a reasonable range.
[0124] 4.1 Situations where additional memory is required:
[0125] index:
[0126] (1)jvm_memory_bytes_used{area="heap"}: the actual amount of heap memory used.
[0127] (2) jvm_memory_bytes_committed{area="heap"}: the amount of committed heap memory, that is, the memory that the JVM has requested and allocated from the operating system.
[0128] (3) jvm_memory_bytes_max{area = "heap"}: the maximum value of the heap memory, that is, the maximum heap memory that the JVM can use.
[0129] Principle: When the actual amount of heap memory used approaches the maximum value of heap memory, it means that the heap memory is close to exhaustion, which may lead to frequent GC attempts to reclaim memory. If the amount of committed heap memory continues to grow and approaches the maximum value of heap memory, and the actual amount of heap memory used also remains high, it indicates that the JVM is close to its heap memory limit.
[0130] 4.2 Situations where memory reduction is required
[0131] Principle: Heap memory is free. If jvm_memory_bytes_used{area="heap"}(heap memory used) is far lower than jvm_memory_bytes_max{area="heap"}(the maximum value of heap memory) for a long time during runtime, it means that the actual heap memory used is far less than the allocated heap memory.
[0132] 4.3 Prediction of the maximum value of JVM heap memory usage based on LSTM model
[0133] 1. Key indicators:
[0134] jvm_memory_bytes_used{area="heap"}: actual usage of heap memory.
[0135] jvm_memory_bytes_max{area="heap"}: maximum value of heap memory.
[0136] 2. Feature Engineering
[0137] (1) Time characteristics:
[0138] Hour: Captures intraday periodic changes.
[0139] Day of Week: Captures periodic changes within the week.
[0140] (2) Statistical characteristics:
[0141] Moving Average: Calculates the moving average of heap usage over the past 60 minutes to smooth the data and capture trends.
[0142] Moving Standard Deviation: Measures the volatility of heap usage
[0143] (3) Lag Features:
[0144] Lag 1: Heap usage in the last minute.
[0145] Lag 2: Heap usage in the last two minutes.
[0146] (4) Rolling Max:
[0147] The maximum heap usage in the past 60 minutes, which helps predict future peaks
[0148] (5) Filling NaN values:
[0149] Backward Fill or other appropriate methods are used to fill NaN values generated by feature engineering.
[0150] 3. LSTM model construction and training
[0151] (1) Data preparation
[0152] 1.1. Feature Scaling (Normalization):
[0153] Use Min-Max scaling to scale the feature values to the range of [0,1] to improve the model training effect.
[0154] 1.2. Special sequence construction:
[0155] Convert the time series data into a shape suitable for LSTM input, i.e. (3D tensor) number of samples × time steps × number of features.
[0156] Setting the time step (Window Size) to 60 minutes means that data every 60 minutes is used to predict future heap usage.
[0157] 1.3. Special training set and validation set division:
[0158] The dataset is divided into chronological order, 80% as a training set and 20% as a validation set to prevent data leakage.
[0159] (2) Model Architecture
[0160] Input layer: accepts input data of shape (timesteps, number of features).
[0161] LSTM layer: 50 LSTM units are set, and the activation function is ReLU, which can capture long-term dependencies and nonlinear relationships in time series.
[0162] Output layer: A single fully connected layer that outputs the predicted value of future heap usage.
[0163] Loss function and optimizer: Use mean squared error (MSE) as the loss function and Adam optimizer for parameter optimization.
[0164] Early Stopping: Set the monitoring indicator to the loss of the validation set (val_loss). If there is no improvement for 10 consecutive epochs, stop training to prevent overfitting.
[0165] 4. Peak prediction
[0166] (1) Rolling Forecast:
[0167] Use the trained LSTM model to predict the heap memory usage for a period of time in the future (such as 1440 minutes, or one day).
[0168] Each time step is predicted, and the predicted value is used as the input of the next time step, and multi-step prediction is performed iteratively.
[0169] (2) Maximum value extraction:
[0170] The maximum heap usage during the forecast period is extracted from the forecast results as the future peak forecast.
[0171] The prediction result is the maximum possible value of the JVM heap memory. pre
[0172] If Heap pre / jvm_memory_bytes_max{area="heap"}>0.7, then calculate
[0173] JVM add =Heap pre / jvm_memory_bytes_committed-0.7
[0174] If Heap pre / jvm_memory_bytes_max{area="heap"}>0.4, then calculate
[0175] JVM sub =0.4-Heap pre / jvm_memory_bytes_max{area="heap"}
[0176] The container resource quota recommendation method for optimizing Java programs in this embodiment has the following advantages:
[0177] 1. Container resource quota recommendation method based on monitoring data and JVM memory management characteristics:
[0178] This embodiment collects the actual running data of Java applications in the Kubernetes cluster and combines the memory management characteristics of the JVM to accurately calculate the CPU and memory quotas of container resources. Through 7 days of data monitoring, this method can generate resource quota recommendations that better meet the needs of Java applications and avoid resource waste and shortage.
[0179] 2. Memory resource recommendation model and monitoring mechanism based on JVM feature optimization:
[0180] This embodiment combines the memory management mechanism of the JVM with specific monitoring data to propose a memory resource quota recommendation model for Java programs. The model accurately calculates memory request and limit values by analyzing data such as the JVM's heap memory usage, committed memory, and maximum memory. At the same time, based on the JVM's memory management characteristics (including unused heap memory, buffer memory, garbage collection frequency, etc.), the memory quota is dynamically adjusted to optimize the allocation of memory resources, reduce memory waste, and reduce performance degradation caused by frequent JVM GC.
[0181] 3. Automatically adjust memory quota to reduce OOM risk:
[0182] This embodiment dynamically adjusts the memory limit value and sets an appropriate buffer value by analyzing memory monitoring data (such as OOM events and heap memory usage) to reduce application crashes (OOM) caused by insufficient memory. At the same time, a certain proportion of redundancy is provided to cope with sudden memory demands.
[0183] In a certain AI computing power scheduling platform, multiple Java applications are deployed in a Kubernetes cluster to handle the scheduling of model training, reasoning and other tasks. Before using the present invention, some core applications on the platform were manually configured with unreasonable configurations due to the manual configuration of container memory and CPU quotas. They were often affected by resource preemption by other applications in the same cluster, resulting in frequent memory waste and CPU overload. Especially under peak load, the performance of Java programs fluctuates greatly, and response time delays occur, affecting the stability of tasks and the overall user experience.
[0184] After applying the method of this embodiment, the platform can accurately calculate the CPU and memory request and limit values of the container based on the actual Java application running data and JVM memory management characteristics, avoiding resource waste and competition. By real-time monitoring and dynamic adjustment of resource quotas, the problem of Java programs being interfered with by other tasks during operation is successfully solved, ensuring that the resources of key tasks are reasonably allocated.
[0185] In the several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of the modules, modules or units is only a logical function division, and there may be other division methods in actual implementation, for example, multiple units, modules or components can be combined or integrated into another device, or some features can be ignored or not executed.
[0186] The units may or may not be physically separated, and the components displayed as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.
[0187] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
[0188] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part, and / or installed from a removable medium. When the computer program is executed by the central processing unit (CPU), the above-mentioned functions defined in the method of the present invention are executed. It should be noted that the above-mentioned computer-readable medium of the present invention can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, but not limited to, a system, device or device of an electrical, magnetic, optical, electromagnetic, infrared segment, or semiconductor, or any combination of the above.
[0189] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.
[0190] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed by the present invention should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.
Claims
1. A container resource quota recommendation method for optimizing Java programs, characterized in that: The following steps are involved: Obtain monitoring data; the monitoring data includes CPU usage and memory usage; Recommend CPU resource quotas based on CPU usage; Recommend memory resource quotas based on memory usage.
2. The container resource quota recommendation method for Java program optimization according to claim 1 is characterized in that: Recommend memory resource quotas based on memory usage, including the following steps: Determine the memory request value based on the maximum memory usage; Get JVM monitoring indicators and OOM data based on memory usage; According to the memory request value and JVM monitoring indicators, the JVM addition value and JVM reduction value are obtained; The memory request is calculated based on the memory request value, JVM addition value, and JVM reduction value. The memory limit is calculated based on the memory request value and OOM data.
3. The container resource quota recommendation method for optimizing Java programs according to claim 2, characterized in that: According to the memory request value and JVM monitoring indicators, the JVM addition value and JVM reduction value are obtained, which specifically includes the following steps: Extract indicator features from JVM monitoring indicators; the indicator features include time features, statistical features, hysteresis features, rolling maximum values, and filling NaN values; After scaling and sequence construction of indicator features, the features are input into the trained LSTM model to obtain the heap memory usage prediction results; Based on the heap memory usage prediction results, the JVM addition value and JVM reduction value are calculated.
4. The container resource quota recommendation method for optimizing Java programs according to claim 3 is characterized in that: The LSTM model includes an input layer, an LSTM layer, an output layer, a loss function and an optimizer, and an early stopping mechanism; The input layer is used to accept input data of shape time steps and number of features; The LSTM layer is set with 50 LSTM units and the activation function is ReLU, which is used to capture long-term dependencies and nonlinear relationships in time series; The output layer is a single fully connected layer that outputs the predicted value of future heap usage; Loss function and optimizer use mean square error as loss function and Adam optimizer for parameter optimization; The early stopping mechanism sets the monitoring indicator as the loss of the validation set, and stops training if there is no improvement for 10 consecutive epochs.
5. The container resource quota recommendation method for Java program optimization according to claim 4 is characterized in that: According to the heap memory usage prediction results, the JVM addition value and JVM reduction value are calculated, which specifically includes the following steps: Extract the maximum heap usage during the prediction period from the heap memory usage prediction result; If Heap pre / jvm_memory_bytes_max{area="heap"}>0.7, then calculate: JVM add =Heap pre / jvm_memory_bytes_committed-0.7 If Heap pre / jvm_memory_bytes_max{area="heap"}>0.4, then calculate: JVM sub =0.4-Heap pre / jvm_memory_bytes_max{area="heap"} Where: Heap pre is the maximum heap usage during the forecast period; jvm_memory_bytes_used{area="heap"} is the actual usage of heap memory; jvm_memory_bytes_committed is the amount of committed heap memory; JVM add Add values to the JVM; JVM sub Decrement the value for the JVM.
6. The container resource quota recommendation method for optimizing Java programs according to claim 5, characterized in that: The calculation formula of the memory request is: M request =M max *(1+JVM add +JVM sub ) Where: M request M is the memory request; max It is the memory request value; The calculation formula for the memory limit is: M limit =M request *(1+M buffer )+M oom Where: M limit M is the memory limit; buffer is the memory buffer value; M oom To prevent OOM, the memory value increases; The memory increase value M to prevent OOM oom The calculation formula is: M oom =MAX(M k *P b ,M min ) Where: M k The memory used when the container is killed; P b is the percentage buffer value; M min Minimum memory increase to prevent OOM.
7. The container resource quota recommendation method for optimizing Java programs according to claim 6, characterized in that: Obtaining monitoring data includes the following steps: By requesting the API of the prometheus instance installed in the kubernetes cluster, we can obtain the workload and its corresponding Pod information, and establish the relationship between the workload, Pod and container. Get the container resource quota set by the user; Collect the CPU usage and memory usage of the container.
8. The container resource quota recommendation method for optimizing Java programs according to claim 7, characterized in that: After obtaining the monitoring data, the following steps are also included: Preprocess the monitoring data: For CPU usage, statistics are collected every 5 minutes over the past 7 days, and the 5-minute average is calculated to generate the CPU time series; For memory usage, take the maximum value in the past 7 days as the maximum memory usage.
9. The container resource quota recommendation method for Java program optimization according to claim 8, characterized in that: Recommend CPU resource quotas based on CPU usage, including the following steps: Take the 95% percentile of CPU usage as the minimum resource requirement CPU request; The 99th percentile of CPU usage is taken as the maximum resource requirement CPU limit.
10. A container resource quota recommendation system for Java program optimization, used to implement the container resource quota recommendation for Java program optimization as claimed in any one of claims 1 to 9, characterized in that: include: An acquisition module is used to acquire monitoring data; the monitoring data includes CPU usage and memory usage; CPU resource quota recommendation module, used to recommend CPU resource quotas based on CPU usage; The memory resource quota recommendation module is used to recommend memory resource quotas based on memory usage.