Memory scheduling

Abstract

Embodiments of the present disclosure provide a memory scheduling method, device, and system, a storage medium, and a program product. In an embodiment of the present disclosure, a memory elastic release function is provided to an application by a runtime environment hosting the application, and is utilized to dynamically release a portion of memory requested by the application from a working node, so as to obtain actual memory usage of the application. Further, an actual memory demand amount of a pod is determined on the basis of the actual memory usage of each application within the pod, and a memory request amount configured for the pod is dynamically adjusted on the basis of the actual memory demand amount of the pod, thereby enabling elastic scaling of the memory request amount of the pod, achieving logical utilization of memory resources, and avoiding memory resource waste.

Description

[0001] Memory Scheduling Technology Field

[0002]

[0001] The present disclosure relates to the field of cloud computing technology, and in particular to memory scheduling.

[0003]

[0002] Containerization is a virtualization technology that allows applications and their dependencies to be packaged into an independent, portable runtime environment. By creating a container on a host machine and deploying applications in the container, isolation and restriction between applications can be achieved.

[0004] K8s (short for Kubemetes) is an open-source container orchestration platform used to automate the deployment, scaling, and management of containers. In the K8s environment, a pod is the basic deployment unit, consisting of one or more containers, in which user applications are deployed.

[0005]

[0004] In a K8s environment, memory resources occupied by a Pod are limited by configuring a memory request and a memory limit for the Pod. Ideally, a Pod can use the memory request but is not allowed to exceed the memory limit. In actual scenarios, the memory usage of a Pod changes dynamically. If the memory usage of a Pod is lower than its memory request, the unused memory is still occupied by the Pod, which results in a waste of memory resources.

[0006]

[0005] Various aspects of the present disclosure provide a memory scheduling method, device, system, storage medium, and program product for releasing free memory of a container group to avoid wasting memory resources.

[0007]

[0006] An embodiment of the present disclosure provides a memory scheduling method, comprising: monitoring actual memory usage information of an application in a container group including at least one container; releasing a portion of the application's memory request based on the application's actual memory usage information to obtain the application's actual memory usage; determining an actual memory requirement of the container group based on the actual memory usage of each application in the container group; and adjusting the memory request allocated to the container group based on the actual memory requirement of the container group.

[0008]

[0007] The embodiment of the present disclosure also provides a memory scheduling method, comprising: scanning the memory space requested by an application hosted in a container from its corresponding work node to obtain actual memory usage information of the application; and releasing part of the memory requested by the application based on the actual memory usage information of the application to obtain the actual memory occupancy of the application.

[0009]

[0008] An embodiment of the present disclosure further provides a memory scheduling device, comprising: a monitoring module, a release module, a determination module, and an adjustment module; the monitoring module is configured to monitor, for a container group including at least one container, actual memory usage information of an application in the at least one container; the release module is configured to release part of the memory request of the application based on the actual memory usage information of the application to obtain the actual memory usage of the application; the determination module is configured to determine the actual memory requirement of the container group based on the actual memory usage of each application in the container group; and the adjustment module is configured to adjust the memory request allocated to the container group based on the actual memory requirement of the container group.

[0010]

[0009] An embodiment of the present disclosure provides a memory scheduling system, comprising: at least one work node and a scheduling controller; at least one container group is deployed on the work node, the container group includes at least one container, and an application is running in the container; the scheduling controller is configured to monitor actual memory usage information of the application; release part of the memory request amount requested by the application from the work node based on the actual memory usage information of the application to obtain the actual memory usage of the application; and determine the actual memory requirement of the container group based on the actual memory usage of each application in the same container group; and adjust the memory request amount allocated to the container group based on the actual memory requirement of the container group.

[0011]

[0010] An embodiment of the present disclosure further provides an electronic device, comprising: a memory and a processor; the memory is used to store a computer program, and the processor is coupled to the memory and is used to execute the computer program to implement the steps in the above method.

[0012]

[0011] The embodiment of the present disclosure further provides a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above method.

[0013]

[0012] The embodiment of the present disclosure also provides a computer program product, which includes a computer program / instruction. When the computer program / instruction is executed by a processor, the processor is enabled to implement the steps in the above method embodiment.

[0014] In an embodiment of the present disclosure, the memory elastic release function provided by the runtime environment hosting the application is utilized to dynamically release a portion of the memory requested by the application from the working node to obtain the actual memory usage of the application. Furthermore, the actual memory usage of each application within the container group is used as a basis to determine the actual memory demand of the container group. Based on the actual memory demand of the container group, the memory request allocated to the container group is dynamically adjusted, thereby achieving elastic scaling of the container group's memory request and, in turn, achieving rational utilization of memory resources. This avoids memory resource waste and allows the saved memory resources to be scheduled and allocated by the operating system, thereby improving memory resource utilization. BRIEF DESCRIPTION OF THE DRAWINGS

[0015]

[0014] The drawings described herein are intended to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions are intended to explain the present disclosure and do not constitute an improper limitation of the present disclosure. In the drawings:

[0016]

[0015] FIG1a is a schematic structural diagram of a memory scheduling system provided by an exemplary embodiment of the present disclosure;

[0017]

[0016] FIG1b is a schematic structural diagram of a memory scheduling system provided by an exemplary embodiment of the present disclosure;

[0018]

[0017] FIG2 is a schematic diagram of the structure of another memory scheduling system provided by another exemplary embodiment of the present disclosure;

[0019]

[0018] FIG3 is a schematic diagram of the structure of another memory scheduling system provided by another exemplary embodiment of the present disclosure;

[0020]

[0019] FIG4 is a schematic diagram of the working relationship of various parts of a memory scheduling system provided by an exemplary embodiment of the present disclosure;

[0021]

[0020] FIG5 is a flow chart of a memory scheduling method provided by an exemplary embodiment of the present disclosure;

[0022]

[0021] FIG6 is a flow chart of another memory scheduling method provided by another exemplary embodiment of the present disclosure;

[0023]

[0022] FIG7 is a schematic structural diagram of a memory scheduling device provided by an exemplary embodiment of the present disclosure;

[0024]

[0023] FIG8 is a schematic structural diagram of another memory scheduling device provided by another exemplary embodiment of the present disclosure;

[0025]

[0024] FIG9 is a schematic diagram of the structure of an electronic device provided by another exemplary embodiment of the present disclosure.

[0026] To make the objectives, technical solutions, and advantages of the present disclosure more clearly apparent, the technical solutions of the present disclosure will be described clearly and completely below in conjunction with specific embodiments of the present disclosure and the corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present disclosure, and are not all of the embodiments. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort are within the scope of protection of the present disclosure.

[0027]

[0026] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of relevant data must comply with relevant laws, regulations, and standards of relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or reject. In addition, the various models involved in this disclosure (including but not limited to language models or large models) comply with relevant laws and standards.

[0028]

[0027] The embodiments of the present disclosure involve container technology. A container is an isolated environment that carries user applications. Containers are deployed on worker nodes. Worker nodes can be devices that can provide various resources such as computing, storage, and networking and have certain computing capabilities, such as terminal devices such as computers and mobile phones, or server devices such as traditional servers, cloud servers, and server clusters. Furthermore, the embodiments of the present disclosure do not limit the deployment environment of containers. For example, containers can be deployed not only in a Kubernetes environment, but also in other container technologies such as OpenShift (a unified platform based on Kubernetes launched by Red Hat) and Docker Swarm (a container orchestration tool provided by Docker). In the container environment of this embodiment, a container group is the basic deployment unit, including one or more containers. User applications are deployed in containers. Each container in a container group shares the same resources and local network. Containers in the same container group can communicate with each other while maintaining a certain degree of isolation.

[0029]

[0028] It should be noted that in the embodiments of the present disclosure, a container group refers to a collection of containers, including one or more containers. This collection has the same or similar functions as a container group in Kubernetes, and both can implement the technical solutions of the present disclosure. Therefore, in the embodiments of the present disclosure, a collection of containers that can implement the technical solutions of the present disclosure is collectively referred to as a container group.

[0030]

[0029] In the container environment of the embodiments of the present disclosure, a memory request and memory limit are configured for a container group to limit the memory resources occupied by the container group. The container group requests memory resources from the operating system of the worker node where it resides, and the memory resources requested by the container group are further allocated to the applications within each container. In a specific implementation, the memory request and memory limit are used to allocate resources at a container-level granularity. Each container can have its own memory request and memory limit set individually, and the sum of the memory requests of all containers in the container group is the container group's memory request. The container group's memory request is used when scheduling the container group. The container group will only be scheduled to a worker node if the worker node has sufficient available memory (i.e., the memory request). The container group's memory limit is used to limit the maximum memory resource consumption of the container group.

[0031] In the disclosed embodiment, the collection policy of the operating system of the working node determines whether the memory resources requested by the application are returned to the operating system. However, memory collection and the collection policy are both controlled internally by the operating system and are difficult to intervene externally. This can result in the application's idle memory not being reclaimed in a timely manner, resulting in wasted memory resources. Furthermore, even if the application is able to return the idle memory to the operating system, the container group's memory request limit will cause this portion of memory to remain occupied by the container group, and the operating system will still be unable to schedule this portion of memory for use by other container groups. Consequently, even if the working node has sufficient memory, other container groups may be unable to deploy or use this portion of idle memory resources due to insufficient memory resources due to the resource policy at the container group level.

[0032]

[0031] To address the technical problem that when the memory resource utilization rate of a container group is low, the memory occupied by the container group cannot be released, thereby causing memory resource waste, an embodiment of the present disclosure provides a memory scheduling method. The method utilizes the memory elastic release function provided by the runtime environment hosting the application to dynamically release part of the memory requested by the application from the working node to obtain the actual memory usage of the application. Furthermore, the actual memory demand of the container group is determined based on the actual memory usage of each application in the container group. The memory request allocated to the container group is dynamically adjusted based on the actual memory demand of the container group, thereby achieving elastic scaling of the container group's memory request and further achieving rational utilization of memory resources. This avoids memory resource waste and allows the saved memory resources to be scheduled and allocated by the operating system, thereby improving memory resource utilization.

[0033] The following describes in detail the technical solutions provided by various embodiments of the present disclosure, in conjunction with the accompanying drawings. Figures 1a and 1b are schematic diagrams of a memory scheduling system provided by an exemplary embodiment of the present disclosure. This embodiment can be applied in a Kubernetes container cluster environment to achieve memory elastic scaling for container groups, but is not limited to Kubernetes environments.

[0034]

[0033] As shown in FIG. 1a, the system 100 includes: at least one worker node 103 and a scheduling controller 101; at least one container group is deployed on each worker node 103, each container group includes at least one container, and each container runs an application. For ease of description, in some descriptions of the embodiments of this disclosure, "worker node" may be referred to simply as "node."

[0034] In this embodiment, the scheduling controller 101 is configured to monitor actual memory usage information of applications; release a portion of the memory requested by the applications from the worker nodes based on the actual memory usage information of the applications to obtain the actual memory usage of the applications; and determine the actual memory requirement of the container group based on the actual memory usage of each application in the same container group; and adjust the memory request allocated to the container group based on the actual memory requirement of the container group.

[0035]

[0035] It should be noted that FIG1a shows only one working node, but this does not mean that the technical solution of the present disclosure is applicable only to one working node. The present disclosure does not limit the number of working nodes. FIG1a also shows container groups AN, each of which includes one or more containers. FIG1a illustrates each container group including containers 1 through x. Furthermore, FIG1a uses container 1 in container group N as an example to illustrate the memory scheduling solution for applications provided in the embodiments of the present disclosure. Other containers (e.g., container x) can refer to container 1, and containers in other container groups (e.g., container group A) can also refer to container 1 in container group N. Subsequent figures are similar to FIG1a, and the signal flow relationship of container 1 in container group N is used as an example for illustration, and will not be further described in the subsequent embodiments.

[0036]

[0036] Further optionally, as shown in FIG. 1b, each container also runs an application runtime environment, and the scheduling controller 101 includes: a memory management module 1012 deployed in the runtime environment, and a memory scheduling node 1011 deployed outside the container group.

[0037] In this embodiment, the application runtime environment is the operating medium for the application and is responsible for providing the application with operating conditions and related resources. The specific implementation may vary depending on the programming language used by the application. In an alternative embodiment, the application runtime environment may be implemented as a virtual machine based on the programming language, and accordingly, the application is an application implemented based on the programming language. The disclosed embodiments do not limit the type of programming language. Alternatively, if the programming language is Java (a widely used computer programming language), the virtual machine based on the programming language is the JVM (Java Virtual Machine), and the application is a Java program. Alternatively, if the programming language is Ruby (an object-oriented, imperative, functional, dynamic general-purpose programming language), the virtual machine based on the programming language is YARV (Yet Another Ruby VM), and accordingly, the application is a Ruby program. In an embodiment of the present disclosure, as shown in FIG. 1b , a memory management module 1012 is added to the aforementioned runtime environment. Memory management module 1012 is configured to monitor the actual memory usage of an application and, based on the application's actual memory usage, dynamically release a portion of the memory requested by the application from a worker node to determine the application's actual memory usage. "Release" here refers to returning a portion of the memory requested by the application from a worker node to the OS (Operating System). Furthermore, if insufficient memory resources are detected during application execution, the application can dynamically request memory resources from the worker node's OS as needed. It should be noted that the total amount of memory resources requested by the application from the worker node's OS should not exceed the pre-configured memory request amount for the container group to which the application belongs. The container group then requests memory resources from the worker node's OS based on the memory request amount. Compared to conventional technical solutions, in an embodiment of the present disclosure, by adding memory management module 1012 to the application's runtime environment, the application's actual memory usage can be monitored and free memory can be dynamically released and returned to the OS.

[0038]

[0038] Furthermore, as shown in FIG. 1b , the system 100 of this embodiment further includes a memory scheduling node 1011, configured to determine an actual memory requirement of the container group based on the actual memory usage of each application in the same container group. The actual memory requirement of the container group may be determined based on the actual memory capacity of all applications in the same container group. For example, it may be the sum of the actual memory capacity of all applications in the container group, or the weighted sum of the actual memory capacity of all applications in the container group, or several times the sum of the actual memory capacity of all applications in the container group, etc. Furthermore, the memory request capacity allocated to the container group is dynamically adjusted based on the actual memory capacity of the container group. In this embodiment, the memory scheduling node 1011 cooperates with the memory management module 1012. Based on the memory management module 1012's ability to dynamically release some of the memory requested by applications from working nodes, the memory scheduling node 1011 can dynamically adjust the memory request allocated to the container group. The actual memory requirement of the container group is determined based on the actual memory usage of each application within the container group. The memory request allocated to the container group is then dynamically adjusted based on the actual memory requirement. This achieves elastic scaling of the container group's memory request, conserves memory resources, and improves memory resource utilization.

[0039]

[0039] In this embodiment, the memory resources that can be provided by the OS of the working node refer to the total amount of memory that can be allocated by the node; when deploying an application in a container environment, the memory request amount and memory limit amount can be configured for each container. The memory request amount is the memory size (equal to the memory request amount) requested by the application from the OS of the working node to meet its own memory needs; the memory request amount of the container group to which the application belongs refers to the sum of the memory request amounts of all containers in the container group. The memory request amount of the container group to which the application belongs is one of the important parameters considered during K8S scheduling. During scheduling, it is ensured that the memory request amounts of all container groups on the node do not exceed the memory resources that can be provided by the OS of the node.

[0040] In an optional embodiment, the application's runtime environment may further provide a parameter configuration interface to allow the user to configure relevant parameters of the application. Based on this, when the application starts, the application's initial memory size is reconfigured through the parameter configuration interface provided by the runtime environment, so that after startup, the application requests memory space from the working node according to the reconfigured initial memory size. The reconfigured initial memory size is smaller than the default initial memory size. In this way, the application can attempt to find the most appropriate memory size when it starts, thereby reducing memory usage.

[0041] Furthermore, to facilitate obtaining actual memory usage information of an application, a time interval for triggering a GC (Garbage Collection) operation can be configured for the application through a parameter configuration interface provided by its runtime environment when the application is started. This allows the GC operation to be changed from passively triggered to actively triggered, thereby facilitating the collection of statistics on the application's actual memory usage information. Passively triggering a GC operation refers to a GC operation triggered when the application's memory resource usage reaches a default usage threshold, while actively triggering a GC operation refers to a GC operation periodically triggered at a set time interval. Based on this, when monitoring the actual memory usage information of an application in at least one container, the memory management module 1012 periodically performs GC operations on the memory space requested by the application from the working node where the container group is located, based on the pre-configured time interval for triggering GC operations, to obtain the application's actual memory usage information. Optionally, the disclosed embodiments do not limit the conditions for triggering GC operations configured through the parameter configuration interface; they can be the aforementioned time interval, or various triggering conditions that can increase the frequency of GC operations, such as a threshold reached by memory usage (the set threshold being less than the default usage threshold).

[0042] It should be noted that, in the embodiments of the present disclosure, based on the pre-configured time interval for triggering garbage collection (GC) operations, periodic GC operations are performed on the memory space requested by the application from the worker node where the container group is located. This is a GC operation that is added to the existing garbage collection mechanism of the virtual machine, and the existing garbage collection mechanism can also operate normally. The existing garbage collection mechanism can be the mechanism mentioned above that passively triggers GC operations based on the default usage threshold.

[0043]

[0043] The embodiment of the present disclosure does not limit the timing of adjusting the relevant parameters through the parameter configuration interface. The adjustment can be made when the application is started, or the relevant parameters can be adjusted through the parameter configuration interface at any time during the operation of the application.

[0044] Taking an application's runtime environment as a programming language-based virtual machine (e.g., JVM) as an example, to proactively trigger garbage collection (GC) operations and increase the frequency of GC triggering, the memory management module 1012, with user authorization, modifies the user's virtual machine (e.g., JVM) parameters when the application is started, and adds some parameters so that the virtual machine proactively triggers GC operations when the virtual machine is relatively idle. The modified virtual machine (e.g., JVM) parameters include, but are not limited to, at least one of the following: garbage collection algorithm, maximum heap memory size, minimum heap memory size, and initial heap memory size. These parameters are modified to reduce the memory resources occupied by the application. The additional parameters include at least one of the following: GC collection cycle and collection policy parameters. Collection policy parameters are those exposed during the execution of the garbage collection algorithm. For example, they may determine which objects' memory resources should be reclaimed or which objects' memory resources should not be reclaimed. The disclosed embodiments also allow for the addition of additional collection policy parameters. The purpose of these additional policy parameters is to accurately and reasonably determine the memory resources that require reclaiming by the application. By proactively triggering GC operations, this can more accurately determine the memory resources that require reclaiming by the application, thereby enabling monitoring of the application's actual memory usage. Heap memory refers to the memory of applications written in the Java language.

[0045]

[0045] In this embodiment, executing the GC operation can obtain the live objects and / or dead objects marked in the application program. When the object is dead (will no longer be used), the corresponding memory area should be reclaimed. When the object is alive (may be used), it cannot be reclaimed. The present disclosure does not limit the object survival determination algorithm. Optionally, a reference counting method can be used to track the number of references to the object by adding a reference counter to each object. Whenever a new reference is added to the object, the counter is increased by 1. When the reference is invalid, the counter is decreased by 1. When the counter becomes 0, it means that the object will no longer be used. In another optional embodiment, a reachability analysis algorithm may also be used. This algorithm, as the core of the JVM garbage collection mechanism, starts from a set of root objects called "GC Roots" and searches downward along reference relationships. The path traversed during the search is called a reference chain. If an object has no reference chain connecting to all "GC Roots," the object is considered unreachable and is therefore dead. The method for determining whether an object is alive can be implemented as a preset collection policy parameter in the GC policy or as an additional collection policy parameter mentioned in the above embodiment.

[0046]

[0046] Further optionally, actual memory usage information of the application is obtained based on the memory space occupied by the marked live objects and / or garbage objects in the application. Optionally, the actual memory usage information may include the memory size occupied by the live objects, the free memory size, and the total memory size currently requested by the application.

[0047] In this embodiment, a GC operation is performed on the memory space requested by the application from the working node where the container group is located. This can regularize the memory space occupied by the application. Specifically, the memory space corresponding to live objects is retained, while the memory space corresponding to dead objects is reclaimed. The reclaimed memory space still belongs to the application and can continue to be used by the application. Of course, this memory space also constitutes part of the memory allocation of the container group to which the application belongs. However, from the perspective of improving memory resource utilization, free memory must ultimately be reclaimed at the OS level. Therefore, the memory management module 1012 is required to dynamically release part of the memory allocation of the application. It should be noted that in this embodiment, reclaiming refers to reclaiming free memory to the container group level, while releasing refers to returning free memory to the OS level.

[0048]

[0048] In order to return the free memory to the OS layer, in an optional embodiment, the memory management module 1012 dynamically releases part of the application's memory application amount based on the application's actual memory usage information to obtain the application's actual memory usage. The steps include: predicting the application's actual memory demand based on the application's actual memory usage information; determining the memory release amount when the application's actual memory demand is less than the application's current memory application amount; and calling a memory release function provided by the OS of the working node where the container group is located based on the memory release amount to return part of the application's memory application amount to the OS to obtain the application's actual memory usage.

[0049] In an optional embodiment, when the memory management module 1012 predicts the actual memory requirement of an application based on the actual memory usage information of the application, the following steps are performed: predicting the actual memory requirement of the application based on the actual memory usage information of the application, in combination with at least one of the actual memory usage of the application during a historical period, information about the operating patterns of the application, the application scenario in which the application is located, and the actual memory usage information of the application during the historical period. For example, based on the current actual memory usage information of the application, the sum of the memory size occupied by live objects, the free memory size, and the current memory size can be obtained, where the free memory size is the total amount of memory that can be released. Furthermore, the actual memory usage during the historical period can be combined, and the actual memory usage can be calculated as a peak value or an average value of the memory usage during the historical period. Optionally, the average value of the actual memory usage during the historical period is used to predict the actual memory requirement of the application. For another example, we can analyze the peaks and valleys of user activity based on the application's historical operating patterns over a period of time. Based on this, we can predict changes in memory demand. Peak periods typically indicate more concurrent user access, leading to a significant increase in the application's actual memory demand. Conversely, during valley periods, the actual memory demand can be reduced. For another example, we can also consider the application's application scenario over the historical period. For example, if the application is an e-commerce platform and is about to launch a promotion, based on the data from the historical period, we can predict that the application's actual memory demand may increase by an additional 30%.

[0050] Furthermore, when determining the memory release amount, if the actual memory requirement of an application is less than the current memory request of the application, a threshold may optionally be set. When the actual memory requirement of the application is less than the current memory request of the application and is also less than the threshold, the memory release amount is determined. Optionally, determining the memory release amount includes determining the memory release amount based on at least one of the type of application, the application scenario in which the application is located, and the difference between the actual memory requirement of the application and the current memory request of the application. For example, if the application is a relatively memory-intensive application such as a video application, a small amount of memory may be released when determining the memory release amount to ensure high performance and a good user experience. For another example, if the application is an e-commerce platform and is about to have a promotion (peak period scenario), a small amount of memory may also be released to cope with the memory consumption caused by the surge in user visits during the promotion. For another example, if the difference between the actual memory demand of an application and the current memory request of the application is large, it means that the memory allocated to the application at this time is redundant, based on which a large amount of memory can be released; on the contrary, if the difference is small, it means that the memory allocated to the application at this time is relatively tight, based on which a small amount of memory can be released.

[0051]

[0051] In the embodiment of the present disclosure, the method by which the memory scheduling node 1011 obtains the actual memory usage of each application is not limited. For example, a pull method or a push method may be used. In actual applications, different methods may be selected according to needs. Optionally, when the pull method is used, the memory scheduling node 1011 periodically pulls the actual memory usage of each application from the application. Optionally, when the push method is used, the application actively sends its actual memory usage to the memory scheduling node 1011.

[0052] In another optional embodiment, an indicator server can also be used to obtain the actual memory usage of an application. As shown in FIG2 , the memory scheduling system 100 further includes an indicator server 201 for collecting the actual memory usage of each application on a working node, aggregating the actual memory usage of each application within the same container group, and providing the aggregated information to the memory scheduling node 1011. The memory scheduling node 1011 then determines the actual memory requirement of the container group based on the aggregated information corresponding to the same container group. Alternatively, the actual memory usage of each application within the same container group can be directly summed or weighted to obtain an aggregated result. It should be noted that any method of obtaining an aggregated result based on the actual memory usage of an application is applicable to the embodiments of the present disclosure.

[0053]

[0053] In one example, in this embodiment, the indicator server 201 stores the monitoring data of each node and provides an API for analysis and use. The monitoring data includes but is not limited to the actual memory usage of each application in each container group on the working node. Specifically, an agent component and a collection component can also be deployed on the working node. The indicator server aggregates and converts the monitoring data from the agent component and the collection component and exposes them in the form of an API for external use.

[0054] (e.g., memory scheduling node 1011). The collection component is used to collect monitoring data about containers. The proxy component is used to report status information about container groups and / or worker nodes to the outside world and to receive modification information sent externally, which is used to modify relevant information about the container group. For example, the proxy component can be used to modify the container group's memory request.

[0055] In the embodiments of the present disclosure, the method for determining the actual memory requirement of a container group based on the aggregation results corresponding to the same container group is not limited. In an alternative embodiment, the aggregation results may be multiplied by a preset coefficient to obtain the actual memory requirement of the container group. The preset coefficient may be set based on historical experience. In another alternative embodiment, the actual memory requirement of the container group may be determined based on the aggregation results corresponding to the same container group using a machine learning model.

[0056]

[0055] Further optionally, as shown in FIG3 , the memory scheduling system 100 may further include: a policy configuration node 301 for providing a policy configuration interface to a user and receiving at least one resource elasticity policy configured by the user through the policy configuration interface; and a memory scheduling node 1011 for obtaining the at least one resource elasticity policy from the policy configuration node 301 and adjusting the memory request amount configured for the container group when the actual memory demand of the container group satisfies the at least one resource elasticity policy.

[0056] In this embodiment, the configuration interface may be a command interface, a file interface, or an interactive interface (such as a web page), which is not limited in this disclosure.

[0057]

[0057] User-configured resource elasticity policies include: non-customized policies and customized policies. Non-customized policies are a set of preset resource elasticity policies from which users can select one or more non-customized policies through a policy interface. Non-customized policies include, but are not limited to, perturbation policies and threshold policies. The perturbation policy determines whether the fluctuation of the actual memory demand of a container group within a set time period is within a certain fluctuation range. This policy ensures, for example, that the fluctuation range is set to 30%. When the fluctuation of the actual memory demand of the container group within the set time period (e.g., 1 hour) is less than or equal to 30%, the judgment result is yes. The threshold policy determines whether the actual memory demand of the container group exceeds a certain memory safety threshold. The memory safety threshold is the minimum memory value to ensure system stability and avoid memory overflow. For example, if the memory safety threshold is set to 50%, the judgment result is yes when the actual memory demand of the container group exceeds 50%. Optionally, the fluctuation range and memory safety threshold are predefined.

[0058]

[0058] In contrast to non-customized policies, customized policies are user-configured based on user needs. Users can configure one or more customized policies. Optionally, at least one resource elasticity policy includes at least one user-customized policy. Customized policies include manual policies and policies automatically generated based on customized policy description information. Manual policies are policies that can be added temporarily, allowing users to manually intervene in resource elasticity policies when necessary, thereby making immediate adjustments. In addition, when a customized policy is automatically generated based on customized policy description information, the policy description information may include policy-related information, such as a set percentage or priority, and the customized policy can be parsed from the policy description information. In one example, the user defines in the policy description information that the actual memory requirement of the container group is less than 20% (the set ratio) of the container group's memory request. The custom policy (referred to as the comparison policy) determines whether the actual memory requirement of the container group is no greater than 20% of the memory request currently allocated to the container group. If so, the judgment result is yes. In another example, the user defines the priority of the container group in the policy description information. The custom policy (referred to as the priority policy) determines whether the priority of the container group is lower than the set priority. If so, the judgment result is yes. Generally speaking, a higher priority indicates a more important container group, and its memory request is less likely to be released.

[0059]

[0059] It should be noted that both non-customized policies and customized policies can be used independently or in combination, and this disclosure does not limit this. After a user configures at least one resource elasticity policy through the policy configuration interface, a corresponding judgment operation must be performed based on the at least one resource elasticity policy. If the judgment operation corresponding to the at least one resource elasticity policy returns a positive result, it is determined that the actual memory demand of the container group meets the at least one resource elasticity policy.

[0060]

[0060] Furthermore, when the actual memory demand of the container group satisfies at least one resource elasticity policy, the memory request amount allocated to the container group is dynamically adjusted. Each of the at least one resource elasticity policy is preset with a corresponding adjustment policy. In one example, the at least one resource elasticity policy includes a threshold policy, and the adjustment policy corresponding to the threshold policy is to adjust the requested amount of the container group to be equal to the demand. In another example, the at least one resource elasticity policy includes a comparison policy, and the adjustment policy corresponding to the comparison policy is to adjust the demand of the container group to be greater than a set proportion of the memory request amount, but less than the memory request amount of the container group.

[0061]

[0061] In the embodiments of the present disclosure, the specific implementation method of adjusting the memory request amount configured for the container group is not limited. In one example, the system 100 of this embodiment allows the CPU and memory resources allocated to the container group to be adjusted without restarting the container (in-place upgrade). Based on this, when the actual memory demand of the container group meets at least one resource elasticity policy, the memory scheduling node 1011 generates an adjustment request for the workload. The adjustment request can be implemented as a Patch request, which is an HTTP request method for applying local modifications to resources. The container group implements the scaling of the memory request amount of the application through the workload; upon receiving the adjustment request, the workload

[0062] After a request (such as a Patch request), the container group's memory request amount is modified, thereby reducing the actual memory occupied by the user's container group.

[0063]

[0062] In this embodiment, a rich policy extension mechanism is provided, which can extend the corresponding resource elasticity policy to adapt to the changing needs of users. In addition, the intervention of custom policies, especially manual policies, can ensure the stability of elastic scaling behavior.

[0064] Furthermore, embodiments of the present disclosure provide a memory scheduling system 400. This system 400 is deployed in a Kubernetes container cluster environment. The system 400 includes at least one worker node 103, a memory scheduling node 1011, an indicator server 201, and a policy configuration node 301. Each worker node 103 is deployed with at least one container group, each container group includes at least one container, and each container runs an application and its runtime environment, a JVM. A memory management module 1012 is provided in the JVM.

[0065] FIG4 is a schematic diagram illustrating the working relationship of various components of a memory scheduling system 400. To highlight the functions of each component, FIG4 does not limit the inclusion relationship of the components. For example, the memory management module 1012 is extracted from the JVM, and its functions are disassembled to illustrate the functions of the memory management module 1012 in a process flow. It should also be noted that FIG4 uses container 1 in container group N as an example to illustrate the memory scheduling method provided in the embodiments of the present disclosure. This does not mean that the memory scheduling method provided in the embodiments of the present disclosure is only applicable to container 1 or a single container. The present disclosure does not limit the number of container groups or the number of containers contained in each container group.

[0066] In this embodiment, based on a preset startup command, a garbage collection (GC) operation is proactively triggered to periodically perform GC operations on the memory space requested by the application from the working node where the container group is located, so as to obtain information about the actual memory usage of the application. The time interval for triggering the GC operation is configured for the application when the application is started through the parameter configuration interface provided by the JVM in its runtime environment.

[0067]

[0066] Further, the memory management module 1012 dynamically releases part of the memory application amount of the application according to the actual memory usage information of the application to obtain the actual memory usage of the application; as shown in FIG4, after step ②, the actual memory usage of the application is reduced.

[0068] The indicator server 201 collects the actual memory usage of the applications on the working nodes, aggregates the actual memory usage of each application in the container group N, and provides it to the memory scheduling node 1011. After receiving the aggregated result, the memory scheduling node 1011 determines the actual memory requirement of the container group N based on the aggregated result corresponding to the container group N.

[0069]

[0068] Furthermore, the memory scheduling node 1011 obtains at least one resource elasticity policy from the policy configuration node 301 and performs a judgment operation corresponding to each resource elasticity policy (such as the disturbance policy, threshold policy, and custom policy in FIG4 ). If the judgment result of the judgment operation corresponding to each resource elasticity policy is yes, it is determined that the actual memory demand of the container group N satisfies at least one resource elasticity policy.

[0070] When the actual memory requirement of container group N satisfies at least one resource elasticity policy, the memory scheduling node 1011 generates a patch request for the workload. Container group N scales the memory request of the application program through the workload. After receiving the patch request, the workload modifies the memory request of container group N, thereby reducing the actual memory occupied by the user's container group N.

[0071]

[0070] FIG5 is a memory scheduling method provided by an embodiment of the present disclosure. As shown in FIG5, the method includes the following steps.

[0072]

[0071] S501: For a container group including at least one container, monitor actual memory usage information of an application in the at least one container.

[0073]

[0072] S502: According to the actual memory usage information of the application, release part of the memory application amount of the application to obtain the actual memory usage of the application.

[0074]

[0073] S503: Determine the actual memory requirement of the container group based on the actual memory usage of each application in the container group.

[0075]

[0074] S504: Adjust the memory request amount allocated to the container group according to the actual memory demand of the container group.

[0076] It should be noted that the execution entity of each step of the method provided in the above embodiment may be the same device, or the method may be executed by different devices. For example, the execution entity of steps 501 to 502 may be the memory management module 1012 in the above system embodiment, and the execution entity of steps 503 and 504 may be the memory scheduling node 1011 in the above system embodiment, and so on.

[0077]

[0076] In an optional embodiment, monitoring the actual memory usage information of an application in at least one container includes: periodically performing a garbage collection (GC) operation on the memory space requested by the application from the working node where the container group is located based on a pre-configured time interval for triggering the GC operation, so as to obtain the actual memory usage information of the application; wherein the time interval for triggering the GC operation is configured for the application through a parameter configuration interface provided by its running environment when the application is started.

[0078]

[0077] In an optional embodiment, the method further includes: when the application is started, reconfiguring the initial memory size of the application through the parameter configuration interface, so that the application applies for memory space from the working node according to the reconfigured initial memory size after startup; wherein the reconfigured initial memory size is smaller than the default initial memory size.

[0079]

[0078] In an optional embodiment, releasing part of the application's memory application amount based on the application's actual memory usage information to obtain the application's actual memory usage includes: predicting the application's actual memory requirement based on the application's actual memory usage information; determining a memory release amount when the application's actual memory requirement is less than the application's current memory application amount; and calling a memory release function provided by the OS of the working node where the container group is located based on the memory release amount to return part of the application's memory application amount to the OS to obtain the application's actual memory usage.

[0080]

[0079] In an optional embodiment, when predicting the actual memory requirement of an application based on the actual memory usage information of the application, it includes: predicting the actual memory requirement of the application based on the actual memory usage information of the application, combined with at least one of the actual memory occupancy of the application in a historical period, the operating rule information of the application, the application scenario in which the application is located, and the actual memory usage information of the application in a historical period.

[0081]

[0080] In an optional embodiment, when determining the memory release amount, the method includes: determining the memory release amount based on at least one of the type of application, the application scenario of the application, and the difference between the actual memory demand of the application and the current memory application amount of the application.

[0082]

[0081] In an optional embodiment, determining the actual memory requirement of the container group based on the actual memory usage of each application in the container group includes: obtaining memory aggregation information corresponding to the container group from an indicator server, where the memory aggregation information is obtained by aggregating the actual memory usage of each application in the container group by the indicator server; and determining the actual memory requirement of the container group based on the memory aggregation information corresponding to the container group.

[0083]

[0082] In an optional embodiment, adjusting the memory request amount configured for the container group according to the actual memory demand of the container group includes: obtaining at least one resource elasticity policy pre-configured by a user; and adjusting the memory request amount configured for the container group when the actual memory demand of the container group satisfies the at least one resource elasticity policy.

[0084]

[0083] In an optional embodiment, the method further includes performing at least one of the following judgment operations: when at least one resource elasticity policy includes a disturbance policy, judging whether fluctuations in the actual memory demand of the container group within a set time period are within a fluctuation range in the disturbance policy; when at least one resource elasticity policy includes a threshold policy, judging whether the actual memory demand of the container group exceeds a memory safety threshold in the threshold policy; when at least one resource elasticity policy includes a comparison policy, judging whether the actual memory demand of the container group is not greater than a set proportion of the memory request currently allocated to the container group; if the judgment result of all at least one of the above judgment operations is yes, determining that the actual memory demand of the container group satisfies the at least one resource elasticity policy.

[0085]

[0084] In an optional embodiment, the method further includes: responding to a configuration operation initiated by a user through a policy configuration interface, obtaining at least one resource elasticity policy configured by the user, wherein the at least one resource elasticity policy includes at least a user-defined policy.

[0086]

[0085] FIG6 is a memory scheduling method provided by an embodiment of the present disclosure. As shown in FIG6, the method includes the following steps.

[0087]

[0086] S601: Scan the memory space requested by the application hosted in the container from the corresponding work node to obtain the actual memory usage information of the application.

[0087] S602: Based on the actual memory usage information of the application, release part of the memory requested by the application to obtain the actual memory usage of the application.

[0088]

[0088] In an optional embodiment, when scanning the memory space applied for by the application from the corresponding working node to obtain the actual memory usage information of the application, the method includes: based on a pre-configured time interval for triggering a garbage collection (GC) operation, periodically performing a GC operation on the memory space applied for by the application from the working node where the container group is located to obtain the actual memory usage information of the application; wherein the time interval for triggering the GC operation is configured for the application through a parameter configuration interface provided by its running environment when the application is started.

[0089]

[0089] In an optional embodiment, the method further includes: when the application is started, reconfiguring the initial memory size of the application through a parameter configuration interface, so that after the application is started, the application applies for memory space from the working node according to the reconfigured initial memory size; wherein the reconfigured initial memory size is smaller than the default initial memory size.

[0090]

[0090] In an optional embodiment, releasing part of the application's memory application amount based on the application's actual memory usage information to obtain the application's actual memory usage includes: predicting the application's actual memory requirement based on the application's actual memory usage information; determining a memory release amount when the application's actual memory requirement is greater than the application's current memory application amount; and calling a memory release function provided by the OS of the working node where the container group is located based on the memory release amount to return part of the application's memory application amount to the OS to obtain the application's actual memory usage.

[0091] In an optional embodiment, the method further includes: during the application execution, if the actual memory requirement of the application is greater than the actual memory usage of the application, dynamically requesting memory space from the working node. It should be noted that this request is made by the application to the working node, not by the memory management module 1012.

[0092]

[0092] The detailed implementation and beneficial effects of each step in the method of this embodiment have been described in detail in the aforementioned embodiments and will not be elaborated here.

[0093]

[0093] In addition, some of the processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be understood that these operations may not be executed in the order in which they appear herein or may be executed in parallel. Operation sequence numbers, such as 501 and 502, are merely used to distinguish between different operations and do not represent any specific order of execution. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the terms "first" and "second" herein are used to distinguish between different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0094]

[0094] FIG7 is a memory scheduling device provided by an exemplary embodiment of the present disclosure. As shown in FIG7, the memory scheduling device 700 includes: a monitoring module 71, a release module 72, a determination module 73, and an adjustment module 74.

[0095]

[0095] The monitoring module 71 is configured to monitor, for a container group including at least one container, actual memory usage information of an application in the at least one container.

[0096]

[0096] The release module 72 is used to release part of the memory application amount of the application according to the actual memory usage information of the application to obtain the actual memory usage of the application.

[0097]

[0097] The determination module 73 determines the actual memory requirement of the container group according to the actual memory usage of each application in the container group.

[0098]

[0098] An adjustment module 74 is configured to adjust the memory request amount allocated to the container group according to the actual memory requirement of the container group.

[0099]

[0099] In an optional embodiment, when monitoring the actual memory usage information of an application in at least one container, the monitoring module 71 is specifically configured to: periodically perform a garbage collection (GC) operation on the memory space requested by the application from the working node where the container group is located based on a pre-configured time interval for triggering a garbage collection (GC) operation, so as to obtain the actual memory usage information of the application; wherein the time interval for triggering the GC operation is configured for the application through a parameter configuration interface provided by its running environment when the application is started.

[0100] In an optional embodiment, the adjustment module 74 is further configured to: reconfigure the initial memory size of the application through the parameter configuration interface when the application is started, so that after starting, the application applies for memory space from the working node according to the reconfigured initial memory size; wherein the reconfigured initial memory size is smaller than the default initial memory size.

[0100]

[0101] In an optional embodiment, when the release module 72 releases part of the application's memory application amount based on the application's actual memory usage information to obtain the application's actual memory usage, the release module 72 is specifically configured to: predict the application's actual memory requirement based on the application's actual memory usage information; determine the memory release amount when the application's actual memory requirement is less than the application's current memory application amount; and call a memory release function provided by the OS of the working node where the container group is located based on the memory release amount to return part of the application's memory application amount to the OS to obtain the application's actual memory usage.

[0101]

[0102] In an optional embodiment, when predicting the actual memory requirement of the application based on the actual memory usage information of the application, the release module 72 is specifically used to: predict the actual memory requirement of the application based on the actual memory usage information of the application, combined with at least one of the actual memory occupancy of the application in a historical period, the operating rule information of the application, the application scenario in which the application is located, and the actual memory usage information of the application in a historical period.

[0102]

[0103] In an optional embodiment, when determining the memory release amount, the release module 72 is specifically configured to: determine the memory release amount based on at least one of the type of the application, the application scenario of the application, and the difference between the actual memory requirement of the application and the current memory request amount of the application.

[0103]

[0104] In an optional embodiment, when determining the actual memory requirement of the container group based on the actual memory usage of each application in the container group, the determination module 73 is specifically configured to: obtain memory aggregation information corresponding to the container group from a metric server, where the memory aggregation information is obtained by aggregating the actual memory usage of each application in the container group by the metric server; and determine the actual memory requirement of the container group based on the memory aggregation information corresponding to the container group.

[0104]

[0105] In an optional embodiment, when adjusting the memory request amount configured for the container group based on the actual memory demand of the container group, the adjustment module 74 includes: obtaining at least one resource elasticity policy preconfigured by the user; and dynamically adjusting the memory request amount configured for the container group if the actual memory demand of the container group satisfies the at least one resource elasticity policy.

[0105]

[0106] In an optional embodiment, the adjustment module 74 is further configured to perform at least one of the following judgment operations: if the at least one resource elasticity policy includes a perturbation policy, determining whether fluctuations in the actual memory demand of the container group within a set time period are within a fluctuation range in the perturbation policy; if the at least one resource elasticity policy includes a threshold policy, determining whether the actual memory demand of the container group exceeds a memory safety threshold in the threshold policy; if the at least one resource elasticity policy includes a comparison policy, determining whether the actual memory demand of the container group is not greater than a set proportion of the memory request currently allocated to the container group; and if the judgment result of all at least one of the above judgment operations is yes, determining that the actual memory demand of the container group satisfies the at least one resource elasticity policy.

[0106]

[0107] In an optional embodiment, the adjustment module 74 is further configured to: in response to a configuration operation initiated by a user through a policy configuration interface, obtain at least one resource elasticity policy configured by the user, where the at least one resource elasticity policy includes at least a user-defined policy.

[0107]

[0108] FIG8 is a memory scheduling device provided by an embodiment of the present disclosure. As shown in FIG8 , the memory scheduling device 800 includes: a scanning module 81 and a release module 82.

[0108]

[0109] The scanning module 81 is used to scan the memory space requested by the application program hosted in the container from the corresponding working node to obtain the actual memory usage information of the application program.

[0110] The release module 82 is configured to release part of the memory application amount of the application according to the actual memory usage information of the application to obtain the actual memory usage of the application.

[0109]

[0111] In an optional embodiment, when scanning the memory space requested by the application from the corresponding working node to obtain actual memory usage information of the application, the scanning module 81 is specifically configured to: periodically perform a garbage collection (GC) operation on the memory space requested by the application from the working node where the container group is located based on a pre-configured time interval for triggering a garbage collection (GC) operation to obtain actual memory usage information of the application; wherein the time interval for triggering the GC operation is configured for the application through a parameter configuration interface provided by its runtime environment when the application is started.

[0110]

[0112] In an optional embodiment, the release module 82 is further configured to: reconfigure the initial memory size of the application through the parameter configuration interface when the application is started, so that the application applies for memory space from the working node according to the reconfigured initial memory size after startup; wherein the reconfigured initial memory size is smaller than the default initial memory size.

[0111]

[0113] In an optional embodiment, when the release module 82 releases part of the application's memory application amount based on the application's actual memory usage information to obtain the application's actual memory usage, the release module 82 is specifically configured to: predict the application's actual memory requirement based on the application's actual memory usage information; determine the memory release amount when the application's actual memory requirement is greater than the application's current memory application amount; and call a memory release function provided by the OS of the working node where the container group is located based on the memory release amount to return part of the application's memory application amount to the OS to obtain the application's actual memory usage.

[0112]

[0114] In an optional embodiment, the memory scheduling device 800 further includes an application module, which is specifically configured to: dynamically apply for memory space from the working node if the actual memory requirement of the application is greater than the actual memory usage of the application during the application is running.

[0113]

[0115] FIG9 is a schematic diagram of the structure of an electronic device provided by another exemplary embodiment of the present disclosure. As shown in FIG9 , the electronic device includes a memory 94 and a processor 95.

[0114]

[0116] Memory 94 is used to store computer programs and may be configured to store various other data to support operations on the computing platform. Examples of such data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, images, videos, etc.

[0115]

[0117] The memory 94 may be implemented by any type of volatile or nonvolatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0116]

[0118] The processor 95 is coupled to the memory 94 and is configured to execute a computer program in the memory 94 to: monitor, for a container group including at least one container, actual memory usage information of an application in the at least one container; release a portion of a memory request of the application based on the actual memory usage information of the application to obtain an actual memory usage of the application; determine an actual memory requirement of the container group based on the actual memory usage of each application in the container group; and adjust a memory request allocated to the container group based on the actual memory requirement of the container group.

[0117]

[0119] In an optional embodiment, when the processor 95 obtains actual memory usage information of an application in at least one container, it is specifically configured to: periodically perform a garbage collection (GC) operation on the memory space requested by the application from the working node where the container group is located, based on a pre-configured time interval for triggering a garbage collection (GC) operation, to obtain the actual memory usage information of the application; wherein the time interval for triggering the GC operation is configured for the application through a parameter configuration interface provided by its runtime environment when the application is started.

[0118]

[0120] In an optional embodiment, the processor 95 is further configured to: when the application is started, reconfigure the initial memory size of the application through the parameter configuration interface, so that after the application is started, the application applies for memory space from the working node according to the reconfigured initial memory size; wherein the reconfigured initial memory size is smaller than the default initial memory size.

[0119]

[0121] In an optional embodiment, when the processor 95 releases part of the application's memory application amount based on the application's actual memory usage information to obtain the application's actual memory usage, the processor 95 is specifically configured to: predict the application's actual memory requirement based on the application's actual memory usage information; determine a memory release amount when the application's actual memory requirement is less than the application's current memory application amount; and call a memory release function provided by the OS of the working node where the container group is located based on the memory release amount to return part of the application's memory application amount to the OS to obtain the application's actual memory usage.

[0120]

[0122] In an optional embodiment, when the processor 95 predicts the actual memory requirement of the application based on the actual memory usage information of the application, it is specifically used to: predict the actual memory requirement of the application based on the actual memory usage information of the application, combined with at least one of the actual memory occupancy of the application in a historical period, the operating rule information of the application, the application scenario in which the application is located, and the actual memory usage information of the application in a historical period.

[0121]

[0123] In an optional embodiment, when determining the memory release amount, the processor 95 is specifically configured to: determine the memory release amount based on at least one of the type of the application, the application scenario of the application, and the difference between the actual memory requirement of the application and the current memory request amount of the application.

[0122]

[0124] In an optional embodiment, when determining the actual memory requirement of the container group based on the actual memory usage of each application in the container group, the processor 95 is specifically configured to: obtain memory aggregation information corresponding to the container group from a metric server, where the memory aggregation information is obtained by aggregating the actual memory usage of each application in the container group by the metric server; and determine the actual memory requirement of the container group based on the memory aggregation information corresponding to the container group.

[0123]

[0125] In an optional embodiment, when the processor 95 adjusts the memory request amount configured for the container group based on the actual memory requirement of the container group, the processor 95 includes: obtaining at least one resource elasticity policy preconfigured by a user; and dynamically adjusting the memory request amount configured for the container group if the actual memory requirement of the container group satisfies the at least one resource elasticity policy.

[0124]

[0126] In an optional embodiment, the processor 95 is further configured to perform at least one of the following judgment operations: when the at least one resource elasticity policy includes a disturbance policy, determining whether a fluctuation in the actual memory demand of the container group within a set time period is within a fluctuation range in the disturbance policy; when the at least one resource elasticity policy includes a threshold policy, determining whether the actual memory demand of the container group exceeds a memory safety threshold in the threshold policy; when the at least one resource elasticity policy includes a comparison policy, determining whether the actual memory demand of the container group is not greater than a set proportion of the memory request currently allocated to the container group; if the judgment result of at least one of the above judgment operations is yes, determining that the actual memory demand of the container group satisfies the at least one resource elasticity policy.

[0125]

[0127] In an optional embodiment, the processor 95 is further configured to: in response to a configuration operation initiated by a user through a policy configuration interface, obtain at least one resource elasticity policy configured by the user, where the at least one resource elasticity policy includes at least a user-defined policy.

[0126]

[0128] Furthermore, as shown in FIG9 , the electronic device also includes other components, such as a communication component 96, a display 97, a power supply component 98, and an audio component 99. FIG9 only schematically illustrates some components, and does not mean that the electronic device only includes the components shown in FIG9 . Furthermore, the components within the dashed box in FIG9 are optional, not required, and the specific requirements depend on the product form factor of the working node. The working node of this embodiment can be implemented as a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or as a server-side device such as a conventional server, cloud server, or server array. If the working node of this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include the components within the dashed box in FIG9 ; if the working node of this embodiment is implemented as a server-side device such as a conventional server, cloud server, or server array, it may not include the components within the dashed box in FIG9 .

[0127]

[0129] An embodiment of the present disclosure also provides an electronic device whose implementation structure is the same as or similar to that of the electronic device shown in FIG. This electronic device can be implemented with reference to the structure of the electronic device shown in FIG. The electronic device provided in this embodiment differs primarily in the functions implemented by the processor executing a computer program stored in memory. In the electronic device provided in this embodiment, the processor executing the computer program stored in memory can be used to: scan the memory space requested by an application hosted in a container from its corresponding work node to obtain actual memory usage information for the application; and release a portion of the application's requested memory based on the application's actual memory usage information to obtain the application's actual memory usage.

[0128]

[0130] In an optional embodiment, when scanning the memory space requested by the application from the corresponding work node to obtain actual memory usage information of the application, the processor is specifically configured to: periodically perform a garbage collection (GC) operation on the memory space requested by the application from the work node where the container group is located based on a pre-configured time interval for triggering a GC operation to obtain actual memory usage information of the application; wherein the time interval for triggering the GC operation is configured for the application through a parameter configuration interface provided by its runtime environment when the application is started.

[0129]

[0131] In an optional embodiment, the processor is further configured to: when the application is started, reconfigure the initial memory size of the application through the parameter configuration interface, so that after starting, the application applies for memory space from the working node according to the reconfigured initial memory size; wherein the reconfigured initial memory size is smaller than the default initial memory size.

[0130]

[0132] In an optional embodiment, when the processor releases part of the application's memory application amount based on the application's actual memory usage information to obtain the application's actual memory usage, the processor is specifically configured to: predict the application's actual memory requirement based on the application's actual memory usage information; determine a memory release amount if the application's actual memory requirement is greater than the application's current memory application amount; and call a memory release function provided by the OS of the working node where the container group is located based on the memory release amount to return part of the application's memory application amount to the OS to obtain the application's actual memory usage.

[0131]

[0133] In an optional embodiment, the processor is further configured to: during the running of the application, if the actual memory requirement of the application is greater than the actual memory usage of the application, dynamically apply for memory space from the working node.

[0132]

[0134] The detailed implementation and beneficial effects of each step in the method of this embodiment have been described in detail in the aforementioned embodiments and will not be elaborated on here.

[0133]

[0135] Accordingly, an embodiment of the present disclosure further provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor is enabled to implement each step in the above method embodiment.

[0134]

[0136] Accordingly, an embodiment of the present disclosure further provides a computer program product, which includes a computer program / instructions. When the computer program / instructions are executed by a processor, the processor is enabled to implement the steps in the above method embodiments.

[0135]

[0137] The above-mentioned memory can be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0136]

[0138] The communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G, or other mobile communication networks, or a combination thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0137]

[0139] The display includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, it may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensors can detect not only the boundaries of a touch or slide action, but also the duration and pressure associated with the touch or slide action.

[0138]

[0140] The power supply assembly provides power to various components of the device in which the power supply assembly is located. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply assembly is located.

[0139]

[0141] The audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC). When the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode, the microphone is configured to receive external audio signals. The received audio signals can be further stored in a memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0140]

[0142] Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to magnetic disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0141]

[0143] The present disclosure is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each process flow and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, such that the instructions, when executed by the processor of the computer or other programmable data processing device, produce means for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams.

[0142]

[0144] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0143]

[0145] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0144]

[0146] In a typical configuration, a computing device includes one or more processors (Central Processing Unit, CPU), input / output interfaces, network interfaces, and memory.

[0145]

[0147] Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0146]

[0148] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can be implemented using any method or technology to store information. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

[0147]

[0149] It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, product, or apparatus comprising a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, product, or apparatus. In the absence of further limitations, the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, product, or apparatus comprising the elements.

[0148]

[0150] The above are merely examples of the present disclosure and are not intended to limit the present disclosure. Persons skilled in the art will readily appreciate that various modifications and variations are possible with the present disclosure. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present disclosure are intended to be encompassed by the claims of the present disclosure.

Claims

Claims 1. A memory scheduling method, comprising: For a container group including at least one container, monitor actual memory usage information of an application in the at least one container; According to the actual memory usage information of the application, part of the memory application of the application is released to obtain the actual memory usage of the application; and according to the actual memory usage of each application in the container group, the actual memory requirement of the container group is determined; The memory request amount allocated to the container group is adjusted according to the actual memory requirement of the container group.

2. The method according to claim 1, wherein: Monitoring actual memory usage information of an application in the at least one container includes: periodically performing a garbage collection (GC) operation on memory space requested by the application from a working node where the container group is located, based on a pre-configured time interval for triggering a GC operation, to obtain actual memory usage information of the application; wherein the time interval for triggering the GC operation is configured for the application through a parameter configuration interface provided by its runtime environment when the application is started.

3. The method according to claim 2, further comprising: When the application is started, the initial memory size of the application is reconfigured through the parameter configuration interface, so that the application applies for memory space from the working node according to the reconfigured initial memory size after startup; The reconfigured initial memory size is smaller than the default initial memory size.

4. The method according to claim 1, wherein: Releasing a portion of the application's memory application amount based on the application's actual memory usage information to obtain the application's actual memory usage, including: predicting the application's actual memory requirement based on the application's actual memory usage information; and determining a memory release amount if the application's actual memory requirement is less than the application's current memory application amount; According to the memory release amount, a memory release function provided by the OS of the working node where the container group is located is called to return part of the memory application amount of the application to the OS to obtain the actual memory usage of the application.

5. The method according to claim 4, wherein: Predicting the actual memory requirement of the application based on the actual memory usage information of the application, including: predicting the actual memory requirement of the application based on the actual memory usage information of the application, combined with at least one of the actual memory occupancy of the application in a historical time period, the operating rule information of the application, the application scenario in which the application is located, and the actual memory usage information of the application in a historical time period.

6. The method according to claim 1, wherein: Determining the actual memory requirement of the container group based on the actual memory usage of each application in the container group includes: obtaining memory aggregation information corresponding to the container group from a metrics server, where the memory aggregation information is obtained by aggregating the actual memory usage of each application in the container group by the metrics server; and determining the actual memory requirement of the container group based on the memory aggregation information corresponding to the container group.

7. The method according to any one of claims 6, wherein: Adjusting the memory request amount configured for the container group according to the actual memory demand of the container group includes: obtaining at least one resource elasticity policy preconfigured by a user; and adjusting the memory request amount configured for the container group if the actual memory demand of the container group satisfies the at least one resource elasticity policy.

8. The method according to claim 7, wherein: The method further includes performing at least one of the following judgment operations: when the at least one resource elasticity policy includes a disturbance policy, judging the actual memory of the container group; whether the fluctuation of the demand within a set time period is within the fluctuation range of the disturbance policy; if the at least one resource elasticity policy includes a threshold policy, determining whether the actual memory demand of the container group exceeds the memory safety threshold in the threshold policy; In a case where the at least one resource elasticity policy includes a comparison policy, determining whether the actual memory demand of the container group is not greater than a set proportion of the memory request currently allocated to the container group; If the judgment results of the at least one judgment operation are all yes, it is determined that the actual memory demand of the container group meets the at least one resource elasticity policy.

9. The method according to claim 7, further comprising: In response to a configuration operation initiated by a user through a policy configuration interface, at least one resource elasticity policy configured by the user is acquired, where the at least one resource elasticity policy includes at least a user-defined policy.

10. A memory scheduling method, comprising: Scan the memory space requested by the application hosted in the container from the corresponding working node to obtain the actual memory usage information of the application; According to the actual memory usage information of the application, part of the memory application amount of the application is released to obtain the actual memory usage of the application.

11. The method according to claim 10, wherein: Scanning the memory space requested by the application from the worker node to which it belongs to obtain actual memory usage information of the application, including: periodically performing a garbage collection (GC) operation on the memory space requested by the application from the worker node where the container group is located based on a pre-configured time interval for triggering a GC operation, to obtain actual memory usage information of the application; wherein the time interval for triggering the GC operation is configured for the application through a parameter configuration interface provided by its runtime environment when the application is started.

12. The method according to any one of claims 10 to 11, further comprising: When the application is started, the initial memory size of the application is reconfigured through the parameter configuration interface, so that the application applies for memory space from the working node according to the reconfigured initial memory size after startup; The reconfigured initial memory size is smaller than the default initial memory size.

13. A memory scheduling system, comprising: At least one worker node and a scheduling controller; At least one container group is deployed on the worker node, the container group includes at least one container, and an application is running in the container; the scheduling controller is configured to monitor actual memory usage information of the application; and based on the actual memory usage information of the application, release a portion of the memory requested by the application from the worker node to obtain the actual memory usage of the application; and, determining an actual memory requirement of the container group based on the actual memory usage of each application in the same container group; The memory request amount allocated to the container group is adjusted according to the actual memory requirement of the container group.

14. The system according to claim 13, wherein: The container also runs an application runtime environment. The scheduling controller includes: a memory management module deployed in the runtime environment, and a memory scheduling node deployed outside the container group. The memory management module is configured to monitor actual memory usage information of the application; and based on the actual memory usage information of the application, release a portion of the memory requested by the application from the worker node to obtain the actual memory usage of the application. The memory scheduling node is configured to determine the actual memory requirement of the container group based on the actual memory usage of each application in the same container group; and adjust the memory request allocated to the container group based on the actual memory requirement of the container group.

15. The system according to claim 14, further comprising: The indicator server is used to collect the actual memory usage of each application on the working node, and aggregate the actual memory usage of each application in the same container group and provide it to the memory scheduling node for the The memory scheduling node determines the actual memory requirement of the container group according to the aggregation result corresponding to the same container group.

16. The system according to claim 14 or 15, further comprising: A policy configuration node, configured to provide a policy configuration interface for users and receive at least one resource elasticity policy configured by the user through the policy configuration interface; The memory scheduling node is specifically configured to obtain the at least one resource elasticity policy from the policy configuration node, and adjust the memory request amount configured for the container group if the actual memory demand of the container group satisfies the at least one resource elasticity policy.

17. An electronic device, comprising: A memory and a processor; wherein the memory is used to store a computer program, and the processor is coupled to the memory and is used to execute the computer program in the memory to implement the steps in the method according to any one of claims 1 to 12.

18. A computer-readable storage medium storing a computer program / instruction, wherein: When the computer program is executed by a processor, the processor is enabled to implement the steps of the method according to any one of claims 1 to 12.

19. A computer program product comprising: A computer program / instruction, wherein, when the computer program / instruction is executed by a processor, the processor is enabled to implement the steps of the method according to any one of claims 1 to 12.

Images