WO2025196552A1 - 内存调度 - Google Patents

内存调度

Info

Publication number
WO2025196552A1
WO2025196552A1 PCT/IB2025/052263 IB2025052263W WO2025196552A1 WO 2025196552 A1 WO2025196552 A1 WO 2025196552A1 IB 2025052263 W IB2025052263 W IB 2025052263W WO 2025196552 A1 WO2025196552 A1 WO 2025196552A1
Authority
WO
WIPO (PCT)
Prior art keywords
memory
application
container group
actual
actual memory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/IB2025/052263
Other languages
English (en)
French (fr)
Inventor
毛亮
郭森明
李颜良
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cloud Intelligence Singapore Holding Pvt Ltd
Original Assignee
Cloud Intelligence Singapore Holding Pvt Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cloud Intelligence Singapore Holding Pvt Ltd filed Critical Cloud Intelligence Singapore Holding Pvt Ltd
Publication of WO2025196552A1 publication Critical patent/WO2025196552A1/zh
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45583—Memory management, e.g. access or allocation

Definitions

  • the present disclosure relates to the field of cloud computing technology, and in particular to memory scheduling.
  • Containerization is a virtualization technology that allows applications and their dependencies to be packaged into an independent, portable runtime environment. By creating containers on a host machine and deploying applications in the containers, isolation and restriction between applications can be achieved.
  • K8s (short for Kubemetes) is an open source container orchestration platform used to automate the deployment, scaling, and management of containers.
  • a pod is the basic deployment unit, consisting of one or more containers, in which user applications are deployed.
  • the memory resources occupied by a Pod are limited by configuring a memory request (Request) and a memory limit (Limit) for the Pod.
  • a Pod can use the memory request amount, but is not allowed to exceed the memory limit.
  • the memory usage of a Pod changes dynamically. If the memory usage of a Pod is lower than its memory request amount, the unused memory is still occupied by the Pod, which will cause a waste of memory resources.
  • 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.
  • 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 part of the memory application requested by the application based on the actual memory usage information of the application to obtain the actual memory usage of the application; determining the 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.
  • 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 worker node to obtain actual memory usage information of the application; and releasing part of the memory requested by the application according to the actual memory usage information of the application to obtain the actual memory usage of the application.
  • the embodiment of the present disclosure also provides a memory scheduling device, comprising: a monitoring module, a release module, a determination module, and an adjustment module;
  • the monitoring module is used to monitor the actual memory usage information of an application in a container group including at least one container;
  • the release module is used to release part of the memory request of the application according to the actual memory usage information of the application to obtain the actual memory usage of the application;
  • the determination module is used to determine the actual memory requirement of the container group according to the actual memory usage of each application in the container group;
  • the adjustment module is used to adjust the memory request allocated to the container group according to the actual memory requirement of the container group.
  • An embodiment of the present disclosure provides a memory scheduling system, comprising: at least one working node and a scheduling controller; at least one container group is deployed on the working 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; based on the actual memory usage information of the application, release part of the memory requested by the application from the working node to obtain the actual memory usage of the application; and, based on the actual memory usage of each application in the same container group, determine the actual memory requirement of the container group; and based on the actual memory requirement of the container group, determine the actual memory requirement of the container group.
  • Request amount adjust the memory request amount allocated to the container group.
  • An embodiment of the present disclosure also 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.
  • the present disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps of the above-described method.
  • the present disclosure also provides a computer program product, which includes a computer program/instructions.
  • the processor is enabled to implement the steps in the above method embodiment.
  • the memory elastic release function provided by the operating environment of the application is used to dynamically release part of the memory application requested by the application from the working node to obtain the actual memory usage of the application; further, the actual memory demand of the container group is determined based on the actual memory usage of each application in the container group, and the memory request allocated to the container group is dynamically adjusted according to the actual memory demand of the container group, thereby achieving elastic scaling of the container group's memory request, and further achieving reasonable utilization of memory resources, avoiding memory resource waste, and the saved memory resources can be used for scheduling and allocation by the operating system, thereby improving memory resource utilization.
  • Figure 1a is a schematic diagram of the structure of a memory scheduling system provided by an exemplary embodiment of the present disclosure
  • Figure 1b is a schematic diagram of the structure of a memory scheduling system provided by an exemplary embodiment of the present disclosure
  • FIG2 is a schematic diagram of the structure of another memory scheduling system provided by another exemplary embodiment of the present disclosure.
  • FIG3 is a schematic diagram of the structure of another memory scheduling system provided by another exemplary embodiment of the present disclosure.
  • FIG4 is a schematic diagram of the working relationship of various parts of the memory scheduling system provided by an exemplary embodiment of the present disclosure
  • Figure 5 is a flowchart of a memory scheduling method provided by an exemplary embodiment of the present disclosure.
  • FIG6 is a flowchart of another memory scheduling method provided by another exemplary embodiment of the present disclosure.
  • FIG7 is a schematic diagram of the structure of a memory scheduling device provided by an exemplary embodiment of the present disclosure.
  • FIG8 is a schematic diagram of the structure of another memory scheduling device provided by another exemplary embodiment of the present disclosure.
  • Figure 9 is a schematic diagram of the structure of an electronic device provided by another exemplary embodiment of the present disclosure.
  • the user information including but not limited to user device information, user personal information, etc.
  • data including but not limited to data used for analysis, stored data, displayed data, etc.
  • the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation portals for users to choose to authorize or refuse.
  • the various models involved in this disclosure are in accordance with Comply with relevant laws and standards.
  • the container technology is involved.
  • the container is an isolated environment that carries user applications.
  • the container is deployed on a working node.
  • the working node can be a device that can provide various resources such as computing, storage, and network and has a certain computing power, such as a terminal device such as a computer or a mobile phone, or a server device such as a traditional server, a cloud server, or a server cluster.
  • a terminal device such as a computer or a mobile phone
  • a server device such as a traditional server, a cloud server, or a server cluster.
  • the embodiments of the present disclosure do not limit the deployment environment of the container.
  • the container can be not only a container deployed in a K8S environment, but also a container implemented using 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).
  • the container group is the basic deployment unit, including one or more containers.
  • the user's application is deployed in the container.
  • Each container in the container group shares the same resources and local network.
  • the containers in the same container group can communicate with each other while maintaining a certain degree of isolation.
  • a container group refers to a collection of containers, which includes one or more containers. This collection has the same or similar functions as the container group in K8S, 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.
  • the memory resources occupied by the container group are limited by configuring the memory request and memory limit for the container group; the container group applies for memory resources from the operating system of the working node where it is located, and the memory resources applied by the container group are further allocated to the applications in each container.
  • the memory request and memory limit are used to allocate resources at the container granularity.
  • Each container can set its own memory request and memory limit, and the sum of the memory request of all containers in the container group is the memory request of the container group.
  • the memory request of the container group is used when scheduling the container group. Only when the working node has sufficient available memory (i.e., the memory request) will the container group be scheduled to the working node.
  • the memory limit of the container group is used to limit the maximum memory resource that the container group can consume.
  • 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.
  • the memory collection and collection policy are controlled by the operating system internally and are difficult to intervene externally. This will result in the idle memory of the application not being reclaimed in time, resulting in a waste of memory resources.
  • the application can return the idle memory to the operating system, due to the memory request limit of the container group, this part of the memory will still be occupied by the container group, and the operating system will still be unable to schedule this part of the memory for use by other container groups.
  • the working node has enough memory, due to the resource policy at the container group level, other container groups will not be able to be deployed or use this part of the idle memory resources due to insufficient memory resources.
  • the embodiment of the present disclosure provides a memory scheduling method, which uses the memory elastic release function provided by the running environment of the application to dynamically release part of the memory application requested by the application from the working node to obtain the actual memory usage of the application; further, based on the actual memory usage of each application in the container group, the actual memory demand of the container group is determined, and then according to the actual memory demand of the container group, the memory request amount allocated to the container group is dynamically adjusted, thereby realizing elastic scaling of the memory request amount of the container group, and further realizing reasonable utilization of memory resources, avoiding memory resource waste, and the saved memory resources can be used for scheduling and allocation by the operating system, thereby improving memory resource utilization.
  • FIG1a and FIG1b are schematic diagrams of the structure 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 elastic memory scaling of a container group, but is not limited to the Kubernetes environment.
  • 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.
  • “worker node” may be referred to as "node.”
  • the scheduling controller 101 is used to monitor the actual memory usage information of the application; release part of the memory application requested by the application from the working node according to 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 according to the actual memory usage of each application in the same container group; and adjust the memory request amount allocated to the container group according to the actual memory requirement of the container group.
  • FIG1a shows only one working node, but this does not mean that the technical solution of the present disclosure is only applicable to one working node.
  • the present disclosure does not limit the number of working nodes.
  • FIG1a shows container groups A-N, each of which includes one or more containers.
  • FIG1a illustrates an example in which each container group includes container 1-container x.
  • FIG1a uses container 1 in container group N as an example to illustrate the memory scheduling solution for the application provided by the embodiment of the present disclosure.
  • Other containers (such as container x) can refer to container 1
  • containers in other container groups such as container group A) can also refer to container 1 in container group N.
  • the subsequent figures are similar to FIG1a, and the signal flow relationship of container 1 in container group N is used as an example for explanation, and will not be repeated in the subsequent embodiments.
  • each container also runs an application runtime environment
  • the scheduling controller 101 includes: a memory management module 1012 deployed in the runtime environment, and a memory scheduling node 101L deployed outside the container group.
  • the application's runtime environment is the application's runtime carrier, responsible for providing the application with runtime conditions and related resources.
  • the specific implementation may vary depending on the programming language used by the application.
  • the application's 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 embodiment does not limit the type of programming language.
  • the virtual machine based on the programming language is JVM (Java Virtual Machine), and the application is a Java program; or, 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.
  • a memory management module 1012 is added to the aforementioned operating 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 information, dynamically release a portion of the memory requested by the application from a worker node to obtain 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).
  • the application can dynamically request memory resources from the worker node's operating system as needed. It should be noted that the total amount of memory resources requested by the application from the worker node's operating system 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 operating system based on the memory request amount.
  • a memory management module 1012 to the application's running environment, it is possible to monitor the actual memory usage information of the application, dynamically release free memory, and return the free memory to the OS.
  • the system 100 of this embodiment further includes: a memory scheduling node 1011, which is used to determine the actual memory requirement of the container group based on the actual memory usage of each application in the same container group, wherein the actual memory requirement of the container group can be determined based on the actual memory of all applications in the same container group, for example, it can be the sum of the actual memory of all applications in the container group, or the weighted sum of the actual memory of all applications in the container group, or several times the sum of the actual memory of all applications in the container group, and so on; furthermore, according to the actual memory requirement of the container group, the memory request amount allocated to the container group is dynamically adjusted.
  • a memory scheduling node 1011 which is used to determine the actual memory requirement of the container group based on the actual memory usage of each application in the same container group, wherein the actual memory requirement of the container group can be determined based on the actual memory of all applications in the same container group, for example, it can be the sum of the actual memory of all applications in the container group, or the weighted
  • 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. This is done based on the actual memory usage of each application within the container group, determining the actual memory requirement of the container group. The memory request amount allocated to the container group is dynamically adjusted based on memory demand, thereby achieving elastic scaling of the container group's memory request amount, saving memory resources and helping to improve memory resource utilization.
  • the memory resources that can be provided by the OS of the working node refer to the total memory that can be allocated by the node; when deploying applications 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 that can be considered during K8S scheduling. During scheduling, it is ensured that the memory request amount of all container groups on the node does not exceed the memory resources that can be provided by the OS of the node.
  • the memory management module 1012 when monitoring the actual memory usage information of the 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 the GC operation, so as to obtain the actual memory usage information of the application.
  • the embodiments of the present disclosure do not limit the conditions for triggering GC operations configured through the parameter configuration interface.
  • the conditions may be the time interval described above, or a threshold reached by memory usage (the set threshold being less than a default usage threshold), or other triggering conditions that can increase the frequency of GC operations.
  • the embodiments of the present disclosure do 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.
  • the memory management module 1012 will modify the user's modified virtual machine (such as JVM) parameters under the user's authorization when the application is started, and add some parameters so that the virtual machine can actively trigger the GC operation when it is relatively idle.
  • the parameters of the modified virtual machine 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. The modification of these parameters is aimed at reducing the memory resources occupied by the application.
  • 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.
  • the actual memory usage information may include the memory size occupied by live objects, the free memory size, and the total memory size currently requested by the application.
  • 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, including: 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 the memory release function provided by the OS of the working node where the container group is located based on the memory release amount, returning part of the application's memory application amount to the OS to obtain the application's actual memory usage.
  • the actual memory usage in the historical period can be combined, and the actual memory usage can be taken as the peak value, average value, etc. of the memory usage in the historical period.
  • the average value of the actual memory usage in the historical period is used to predict the actual memory requirement of the application.
  • determining the memory release amount if the actual memory demand of the application is less than the current memory request of the application, a threshold value may be optionally set. When the actual memory demand of the application is less than the current memory request of the application and is also less than the threshold value, the memory release amount is determined.
  • 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 demand of the application and the current memory request of the application. For example, if the application type is a video application that consumes a lot of memory, when determining the memory release amount, a small amount of memory may be released to ensure high performance and a good user experience.
  • 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 period.
  • 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.
  • the method by which the memory scheduling node 1011 obtains the actual memory usage of each application is not limited. For example, it can adopt a pull method or a push method. In actual applications, different methods can be selected according to needs.
  • the pull method when the pull method is adopted, the memory scheduling node 1011 regularly pulls the actual memory usage of each application from the application.
  • the push method when the push method is adopted, the application actively sends its actual memory usage to the memory scheduling node 1011.
  • an indicator server can also be used to obtain the actual memory usage of the application.
  • the memory scheduling system 100 further includes: an indicator server 201 for collecting the actual memory usage of each application on the working node, and aggregating the actual memory usage of each application in the same container group and providing it to the memory scheduling node 1011, so that the memory scheduling node 1011 can determine the actual memory requirement of the container group based on the aggregation result corresponding to the same container group.
  • the actual memory usage of each application in the same container group can be directly summed or weighted summed to obtain the aggregation result. It is noted that any method that obtains the corresponding aggregation result based on the actual memory usage of the application is applicable to the embodiments of the present disclosure.
  • 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.
  • 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 to the outside world in the form of an API.
  • the collection component is used to collect monitoring data about the container.
  • the proxy component is used to report status information about the container group and/or worker nodes to the outside world. It is also used to receive modification information sent from the outside world and to modify relevant information about the container group. For example, the proxy component can be used to modify the container group's memory request.
  • 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.
  • the aggregation results can be multiplied by a preset coefficient to obtain the actual memory requirement of the container group, where the preset coefficient can be set based on historical experience.
  • the actual memory requirement of the container group can also be determined based on the aggregation results corresponding to the same container group using a machine learning model.
  • 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; the memory scheduling node 1011 is further configured to obtain at least one resource elasticity policy from the policy configuration node 301 and adjust the memory request amount configured for the container group when the actual memory demand of the container group satisfies at least one resource elasticity policy.
  • the configuration interface can be a command interface, a file interface or an interactive interface (such as a web page, etc.), and this disclosure does not limit this.
  • the resource elasticity policy configured by the user includes: non-customized policy and customized policy; non-customized policy is a set of preset resource elasticity policies, from which the user can select one or more non-customized policies through the policy interface, including but not limited to: perturbation policy and threshold policy; wherein, the perturbation policy refers to judging whether the fluctuation of the actual memory demand of the container group within the set time period is within a certain fluctuation range. This policy is to ensure that, for example, the fluctuation range is set to 30%.
  • the threshold policy refers to judging whether the actual memory demand of the container group exceeds a certain memory safety threshold.
  • the memory safety threshold refers to the minimum memory value to ensure system stability and avoid memory overflow. For example, the memory safety threshold is set to 50%. When the actual memory demand of the container group exceeds 50%, the judgment result is yes.
  • the fluctuation range and memory safety threshold are predefined.
  • customized policies are user-configured based on user needs. Users can configure one or more customized policies.
  • at least one resource elasticity policy includes at least one user-defined 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.
  • 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.
  • 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 memory request of the container group.
  • the custom policy (referred to as the comparison policy) determines whether the actual memory requirement of the container group is not greater than 20% of the memory request currently allocated to the container group. If not, the judgment result is yes.
  • the user defines the priority of the container group in the policy description information. In this case, 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.
  • the memory request allocated to the container group is dynamically adjusted.
  • Each of the at least one resource elasticity policy has a preset corresponding adjustment policy.
  • at least one resource elasticity policy includes a threshold policy, and the adjustment policy corresponding to the threshold policy is to adjust the container group's request to be equal to the demand.
  • at least one resource elasticity policy includes a comparison policy, and the adjustment policy corresponding to the comparison policy is to adjust the container group's demand to be greater than a set percentage of the memory request and less than the container group's memory request.
  • the specific implementation method of adjusting the memory request amount configured for the container group is not limited.
  • the system 100 of this embodiment allows the container to adjust the CPU and memory resources allocated to the container group without restarting (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; the workload receives the adjustment request.
  • the container group's memory request is modified, thereby reducing the actual memory occupied by the user's container group.
  • a rich policy extension mechanism is provided to extend the corresponding resource elasticity policy to adapt to User needs change. Furthermore, the introduction of custom policies, especially manual policies, can ensure the stability of elastic scaling behavior.
  • the present disclosure also provides a memory scheduling system 400, which is deployed in a K8S container cluster environment.
  • the system 400 includes: at least one working node 103, a memory scheduling node 1011, an indicator server 201, and a policy configuration node 301.
  • Each working 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 operating environment JVM.
  • a memory management module 1012 is provided in the JVM.
  • the memory scheduling node 1011 obtains at least one resource elasticity policy from the policy configuration node 301 and executes the judgment operation corresponding to each resource elasticity policy (such as the disturbance policy, threshold policy, and custom policy in FIG4 ).
  • 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.
  • the memory scheduling node 1011 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, and container group N implements scaling of the application's memory request 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.
  • S501 For a container group including at least one container, monitor actual memory usage information of an application in at least one container.
  • S502 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.
  • S503 Determine the actual memory requirement of the container group based on the actual memory usage of each application in the container group.
  • S504 Adjust the memory request amount allocated to the container group according to the actual memory demand of the container group.
  • the execution subject of each step of the method provided in the above embodiment can be the same device, or the method can be executed by different devices.
  • the execution subject of steps 501 to 502 can be the memory management module 1012 in the above system embodiment
  • the execution subject of steps 503 and 504 can be the memory management module 1012 in the above system 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.
  • the method when 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 the 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.
  • predicting the actual memory requirement of an application based on the actual memory usage information of the application includes: 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 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.
  • the method when determining the amount of memory released, includes: determining the amount of memory released 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 amount of the application.
  • the method when adjusting the memory request amount configured for the container group based on the actual memory demand of the container group, includes: obtaining at least one resource elasticity policy pre-configured by the 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.
  • 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 the fluctuation of the actual memory demand of the container group within a set time period is within the fluctuation range of 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 the 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 at least one of the above judgment operations is yes, determining that the actual memory demand of the container group satisfies at least one resource elasticity policy.
  • FIG6 is a memory scheduling method provided in an embodiment of the present disclosure. As shown in FIG6 , the method includes the following steps.
  • when scanning the memory space requested by the application from the corresponding working node to obtain the actual memory usage information of the application it includes: based on a pre-configured time interval for triggering garbage collection (GC) operations, periodically performing GC operations on the memory space requested 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 operating environment when the application is started.
  • GC garbage collection
  • the method when 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 demand based on the application's actual memory usage information; determining the memory release amount when the application's actual memory demand 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.
  • the method further includes: during the application program's execution, if the application program's actual memory demand exceeds the application program's actual memory usage, dynamically requesting memory space from the worker node. It should be noted that this request is made by the application program to the worker node, not by the memory management module 1012.
  • FIG7 is a memory scheduling device provided by an exemplary embodiment of the present disclosure.
  • the memory scheduling device 700 includes: a monitoring module 71, a release module 72, a determination module 73, and an adjustment module 74.
  • a monitoring module 71 configured to monitor actual memory usage information of an application in a container group including at least one container.
  • a release module 72 configured to release part of the memory application of the application according to the actual memory usage information of the application, so as to obtain the actual memory usage of the application.
  • Determination module 73 determines the actual memory requirement of the container group based on the actual memory usage of each application in the container group.
  • An adjustment module 74 configured to adjust the memory request amount allocated to the container group according to the actual memory requirement of the container group.
  • the monitoring module 71 when the monitoring module 71 monitors the actual memory usage information of an application in at least one container, it is specifically used to: based on a pre-configured time interval for triggering garbage collection (GC) operations, periodically perform GC operations on the memory space requested 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 operating environment when the application is started.
  • GC garbage collection
  • the adjustment module 74 is further used to: when the application is started, reconfigure 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.
  • the release module 72 when the release module 72 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 occupancy of the application, it is specifically used to: predict the actual memory requirement of the application according to the actual memory usage information of the application; determine the memory release amount when the actual memory requirement of the application is less than the current memory application amount of the application; and call the memory release function provided by the OS of the working node where the container group is located according to the memory release amount, and return part of the memory application amount of the application to the OS to obtain the actual memory occupancy of the application.
  • the release module 72 when the release module 72 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.
  • the release module 72 when determining the memory release amount, is specifically used 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.
  • the determination module 73 when determining the actual memory requirement of the container group based on the actual memory usage of each application in the container group, is specifically configured to: obtain 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 determine the actual memory requirement of the container group based on the memory aggregation information corresponding to the container group.
  • the adjustment module 74 when the adjustment module 74 adjusts the memory request amount configured for the container group based on the actual memory demand of the container group, it includes: obtaining at least one resource elasticity policy pre-configured by the user; and dynamically 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.
  • 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 disturbance policy, determining whether the fluctuation of the actual memory demand of the container group 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; 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; 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.
  • the adjustment module 74 is further used to: respond to a configuration operation initiated by a user through a policy configuration interface, and obtain 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.
  • 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.
  • a scanning module 81 is used to 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.
  • a release module 82 configured to release part of the memory application amount of the application according to the actual memory usage information of the application, so as to obtain the actual memory usage of the application.
  • the release module 82 is further used to: when the application is started, reconfigure 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.
  • the memory scheduling device 800 further includes an application module, which is specifically used to: during the operation of the application, if the actual memory demand of the application is greater than the actual memory usage of the application, dynamically apply for memory space from the working node.
  • 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.
  • Memory 94 for storing 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.
  • 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.
  • SRAM static random access memory
  • EEPROM electrically erasable programmable read-only memory
  • EPROM erasable programmable read-only memory
  • PROM programmable read-only memory
  • ROM read-only memory
  • 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 the memory application requested by the application based on the actual memory usage information of the application to obtain the actual memory usage of the application; determine the actual memory requirement of the container group based on the actual memory usage of each application in the container group; and adjust the memory request allocated to the container group based on the actual memory requirement of the container group.
  • the processor 95 when the processor 95 obtains the actual memory usage information of an application in at least one container, it is specifically configured to: periodically perform a 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.
  • GC garbage collection
  • the processor 95 is further configured to: when the application is started, configure the parameters The configuration interface reconfigures the initial memory size of the application so that after startup, the application requests 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.
  • the processor 95 when the processor 95 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 occupancy of the application, it is specifically used to: predict the actual memory requirement of the application according to the actual memory usage information of the application; determine the memory release amount when the actual memory requirement of the application is less than the current memory application amount of the application; and call the memory release function provided by the OS of the working node where the container group is located according to the memory release amount, and return part of the memory application amount of the application to the OS to obtain the actual memory occupancy of the application.
  • the processor 95 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.
  • the processor 95 when determining the amount of memory released, is specifically configured to: determine the amount of memory released based on at least one of the type of the 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 amount of the application.
  • the processor 95 when determining the actual memory requirement of the container group based on the actual memory usage of each application in the container group, is specifically configured to: obtain 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 determine the actual memory requirement of the container group based on the memory aggregation information corresponding to the container group.
  • the processor 95 when the processor 95 adjusts the memory request amount configured for the container group based on the actual memory demand of the container group, the processor 95 includes: obtaining at least one resource elasticity policy pre-configured by the user; and dynamically 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.
  • 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, judging whether the fluctuation of the actual memory demand of the container group within a set time period is within the fluctuation range of the disturbance policy; when the at least one resource elasticity policy includes a threshold policy, judging whether the actual memory demand of the container group exceeds the memory safety threshold in the threshold policy; when the 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 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.
  • the processor 95 is further configured to: respond to a configuration operation initiated by a user through a policy configuration interface, and obtain 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.
  • the electronic device also includes: a communication component 96, a display 97, a power supply component 98, an audio component 99 and other components.
  • FIG9 only schematically shows some components, which does not mean that the electronic device only includes the components shown in FIG9 .
  • the components in the dotted box in FIG9 are optional components, not mandatory components, and the specific components depend on the product form of the working node.
  • the working node of this embodiment can be implemented as a terminal device such as a desktop computer, a laptop computer, a smart phone or an I0T device, or a server-side device such as a conventional server, a cloud server or a server array.
  • the working node of this embodiment is implemented as a terminal device such as a desktop computer, a laptop computer, a smart phone or a server array, it can be Includes the components within the dashed box in Figure 9; if the working node of this embodiment is implemented as a server-side device such as a conventional server, cloud server, or server array, the components within the dashed box in Figure 9 may not be included.
  • the embodiment of the present disclosure also provides an electronic device, the implementation structure of which is the same as or similar to the implementation structure of the electronic device shown in FIG9 , and can be implemented with reference to the structure of the electronic device shown in FIG9 .
  • the difference between the electronic device provided in this embodiment and the electronic device in the embodiment shown in FIG9 is mainly that the functions implemented by the processor executing the computer program stored in the memory are different.
  • its processor executes the computer program stored in the memory, which can be used to: 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; release part of the memory requested by the application based on the actual memory usage information of the application to obtain the actual memory usage of the application.
  • the processor when the processor scans the memory space requested by the application from the corresponding working node to obtain the actual memory usage information of the application, it is specifically used to: based on a pre-configured time interval for triggering garbage collection (GC) operations, periodically perform GC operations on the memory space requested 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 operating environment when the application is started.
  • GC garbage collection
  • 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 the application is started, it 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.
  • the processor when the processor 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 occupancy of the application, it is specifically used to: predict the actual memory demand of the application according to the actual memory usage information of the application; determine the memory release amount when the actual memory demand of the application is greater than the current memory application amount of the application; and call the memory release function provided by the OS of the working node where the container group is located according to the memory release amount, and return part of the memory application amount of the application to the OS to obtain the actual memory occupancy of the application.
  • the processor is further configured to: dynamically request 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 running of the application.
  • the embodiments of the present disclosure also provide a computer-readable storage medium storing a computer program.
  • the processor is enabled to implement the steps in the above method embodiments.
  • an embodiment of the present disclosure also provides a computer program product, which includes a computer program/instructions.
  • the processor is enabled to implement the steps in the above method embodiment.
  • 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.
  • SRAM static random-access memory
  • EEPROM electrically erasable programmable read-only memory
  • EPROM erasable programmable read-only memory
  • PROM programmable read-only memory
  • ROM read-only memory
  • magnetic memory magnetic memory
  • flash memory magnetic disk or optical disk.
  • the above-mentioned communication component is configured to facilitate wired or wireless communication between the device where the communication component is located and other devices. Communication.
  • 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.
  • the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.
  • the communication component also includes a near-field communication (NFC) module to facilitate short-range communication.
  • the NFC module can be implemented based on radio frequency identification (RFID), infrared data association (IrDA), ultra-wideband (UWB), Bluetooth (BT), or other technologies.
  • RFID radio frequency identification
  • IrDA infrared data association
  • UWB ultra-wideband
  • Bluetooth Bluetooth
  • 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, the screen may be implemented as a touch screen to receive input signals from a user.
  • the touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensor may not only sense the boundaries of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation.
  • 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.
  • the audio component may be configured to output and/or input audio signals.
  • the audio component includes a microphone (MIC), which is configured to receive external audio signals when the device in which the audio component is located is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode.
  • the received audio signals may be further stored in a memory or transmitted via a communication component.
  • the audio component further includes a speaker for outputting audio signals.
  • embodiments of the present disclosure may be provided as methods, systems, or computer program products.
  • the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects.
  • 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.
  • 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 blocks in the block diagram.
  • These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are performed on the computer or other programmable device to produce a computer-implemented process, whereby 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 blocks in the block diagram.
  • a computing device includes one or more processors (Central Processing Units, CPUs), input/output interfaces, network interfaces, and memory.
  • processors Central Processing Units, CPUs
  • input/output interfaces input/output interfaces
  • network interfaces network interfaces
  • memory volatile and non-volatile memory
  • Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM), 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.
  • RAM random access memory
  • RAM Access Memory
  • ROM Read Only Memory
  • Flash RAM Flash RAM
  • Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology.
  • the 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 technology, 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 medium that can be used to store information that can be accessed by a computing device.
  • computer-readable media does not include transitory media such as modulated data signals and carrier waves.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本公开实施例提供一种内存调度方法、设备、系统、存储介质及程序产品。在本公开实施例中，利用承载应用程序的运行环境为应用程序提供的内存弹性释放功能，动态释放所述应用程序从工作节点申请的部分内存申请量，以得到所述应用程序的实际内存占用量；进一步，以容器组内各应用程序的实际内存占用量为依据，确定容器组的实际内存需求量，根据容器组的实际内存需求量，动态调整配置给容器组的内存请求量，从而实现容器组内存请求量的弹性伸缩，进而实现内存资源的合理利用，避免了内存资源浪费。

Description

内存调度 技术领域
[01]本公开涉及云计算技术领域， 尤其涉及内存调度。 背景技术
[02]容器化是一种虚拟化技术， 它允许将应用程序及其依赖项打包到一个独立的、 可移 植的运行环境中。 通过在宿主机上创建容器， 在容器中部署应用程序， 可以实现应用程 序之间的隔离和限制。
[03] K8s（ Kubemetes的简称）作为一个开源的容器编排平台， 用于实现容器的自动化部 署、 扩缩和管理。 在 K8s环境中， 容器组（ Pod）是基本的部署单元， 包括一个或多个 容器， 用户的应用程序部署在容器中。
[04]在 K8s环境中， 通过为 Pod配置内存请求量（Request）和内存限制量（Limit） , 以限制 Pod占用的内存资源。 理想情况下， Pod可以使用内存请求量， 但不允许超过内 存限制量。 实际场景中， Pod的内存使用是动态变化的， 如果 Pod的内存使用量低于其 内存请求量， 未被使用的内存依然被 Pod占用， 这会造成内存资源浪费。 发明内容
[05]本公开的多个方面提供一种内存调度方法、 设备、 系统、 存储介质及程序产品， 用 以释放容器组的空闲内存， 避免内存资源浪费。
[06]本公开实施例提供一种内存调度方法， 包括： 针对包含至少一个容器的容器组， 监 测所述至少一个容器中的应用程序的实际内存使用信息 ;根据所述应用程序的实际内存 使用信息， 释放所述应用程序的部分内存申请量， 以得到所述应用程序的实际内存占用 量； 才艮据所述容器组内各应用程序的实际内存占用量， 确定所述容器组的实际内存需求 量； 才艮据所述容器组的实际内存需求量， 调整配置给所述容器组的内存请求量。
[07]本公开实施例还提供一种内存调度方法， 包括： 扫描承载于容器中的应用程序从所 属工作节点申请的内存空间， 以得到所述应用程序的实际内存使用信息； 根据所述应用 程序的实际内存使用信息， 释放所述应用程序的部分内存申请量， 以得到所述应用程序 的实际内存占用量。
[08]本公开实施例还提供一种内存调度装置， 包括： 监测模块、 释放模块、 确定模块以 及调整模块； 监测模块， 用于针对包含至少一个容器的容器组， 监测所述至少一个容器 中的应用程序的实际内存使用信息； 释放模块， 用于根据所述应用程序的实际内存使用 信息， 释放所述应用程序的部分内存申请量， 以得到所述应用程序的实际内存占用量; 确定模块， 才艮据所述容器组内各应用程序的实际内存占用量， 确定所述容器组的实际内 存需求量； 调整模块， 用于才艮据所述容器组的实际内存需求量， 调整配置给所述容器组 的内存请求量。
[09]本公开实施例提供一种内存调度系统， 包括： 至少一个工作节点和调度控制器； 所 述工作节点上部署有至少一个容器组， 所述容器组包括至少一个容器， 所述容器中运行 有应用程序； 所述调度控制器， 用于监测所述应用程序的实际内存使用信息； 根据所述 应用程序的实际内存使用信息，释放所述应用程序从所述工作节点申请的部分内存申请 量 ， 以得到所述应用程序的实际内存占用量； 以及， 根据同一容器组内各应用程序的 实际内存占用量， 确定所述容器组的实际内存需求量； 才艮据所述容器组的实际内存需 求量， 调整配置给所述容器组的内存请求量。
[10]本公开实施例还提供一种电子设备， 包括： 存储器和处理器； 所述存储器， 用于存 储计算机程序， 所述处理器与所述存储器耦合， 用于执行所述计算机程序， 以用于实现 以上所述方法中的步骤。
[11]本公开实施例还提供一种存储有计算机程序的计算机可读存储介质， 当所述计算机 程序被处理器执行时， 致使处理器能够实现以上所述方法中的步骤。
[12]本公开实施例还提供一种计算机程序产品，该计算机程序产品包括计算机程序/指令, 当计算机程序 /指令被处理器执行时， 致使处理器能够实现上述方法实施例中的步骤。
[13]在本公开实施例中， 利用承载应用程序的运行环境为应用程序提供的内存弹性释放 功能， 动态释放所述应用程序从工作节点申请的部分内存申请量， 以得到所述应用程序 的实际内存占用量； 进一步， 以容器组内各应用程序的实际内存占用量为依据， 确定容 器组的实际内存需求量， 才艮据容器组的实际内存需求量， 动态调整配置给容器组的内存 请求量， 从而实现容器组内存请求量的弹性伸缩， 进而实现内存资源的合理利用， 避免 了内存资源浪费， 节省的内存资源可供操作系统调度分配， 提高内存资源利用率。 附图说明
[14]此处所说明的附图用来提供对本公开的进一步理解， 构成本公开的一部分， 本公开 的示意性实施例及其说明用于解释本公开， 并不构成对本公开的不当限定。 在附图中：
[15]图 la为本公开一示例性实施例提供的一种内存调度系统的结构示意图；
[16]图 lb为本公开一示例性实施例提供的一种内存调度系统的结构示意图；
[17]图 2为本公开另一示例性实施例提供的另一种内存调度系统的结构示意图；
[18]图 3为本公开又一示例性实施例提供的另一种内存调度系统的结构示意图；
[19]图 4为本公开一示例性实施例提供的内存调度系统的各部分工作关系的示意图；
[20]图 5为本公开一示例性实施例提供的一种内存调度方法的流程示意图；
[21]图 6为本公开又一示例性实施例提供的又一种内存调度方法的流程示意图；
[22]图 7为本公开一示例性实施例提供的一种内存调度装置的结构示意图；
[23]图 8为本公开又一示例性实施例提供的又一种内存调度装置的结构示意图；
[24]图 9为本公开又一示例性实施例提供的一种电子设备的结构示意图。 具体实施方式
[25]为使本公开的目的、 技术方案和优点更加清楚， 下面将结合本公开具体实施例及相 应的附图对本公开技术方案进行清楚、 完整地描述。 显然， 所描述的实施例仅是本公开 一部分实施例， 而不是全部的实施例。 基于本公开中的实施例， 本领域普通技术人员在 没有做出创造性劳动前提下所获得的所有其他实施例， 都属于本公开保护的范围。
[26]需要说明的是， 本公开所涉及的用户信息 （包括但不限于用户设备信息、 用户个人 信息等 ）和数据（包括但不限于用于分析的数据、 存储的数据、 展示的数据等） ， 均为 经用户授权或者经过各方充分授权的信息和数据， 并且相关数据的收集、 使用和处理需 要遵守相关国家和地区的相关法律法规和标准， 并提供有相应的操作入口， 供用户选择 授权或者拒绝。 另夕卜， 本公开涉及的各种模型 （包括但不限于语言模型或大模型）是符 合相关法律和标准规定的。
[27]在本公开实施例中， 涉及容器技术， 容器是承载用户应用程序的隔离环境， 容器部 署在工作节点上， 工作节点可以是能够提供计算、 存储、 网络等各种资源并具有一定计 算能力的设备， 例如电脑、 手机等终端设备， 传统服务器、 云服务器、 服务器集群等服 务器设备， 对此不做限定。 另外， 本公开实施例也并不限定容器的部署环境， 例如， 容 器不仅可以是部署在 K8S环境中的容器， 还可以是采用 OpenShift（是由 Red Hat公司 推出的一个基于 Kubernetes的统一平台）、 Docker Swarm（ D ocker公司提供的容器编排 工具 ）等其他容器技术实现的容器。 其中， 在本实施例的容器环境中， 容器组是基本的 部署单元， 包括一个或多个容器， 用户的应用程序部署在容器中， 容器组中的每个容器 共享相同的资源和本地网络， 同一容器组的容器之间可以彼此通信， 但同时保持一定程 度的隔离。
[28]需要说明的是， 在本公开实施例中， 容器组是指容器的集合， 该集合中包括一个或 多个容器，该集合与 K8S中容器组的功能相同或相似，均可实现本公开技术方案。因此， 在本公开实施例中， 将可以实现本公开技术方案的容器的集合， 统称为容器组。
[29]其中，在本公开实施例的容器环境中，通过为容器组配置内存请求量和内存限制量， 以限制容器组占用的内存资源； 其中， 容器组向其所在工作节点的操作系统申请内存资 源， 容器组申请的内存资源进一步分配给各个容器内的应用程序。 在具体实现上， 采用 内存请求量和内存限制量对资源进行容器粒度的分配，每个容器都可以单独设定其内存 请求量和内存限制量， 将容器组中所有容器的内存请求量之和为容器组的内存请求量。 容器组的内存请求量用于在调度容器组时， 只有当工作节点有足够多的可用内存（即内 存请求量 ） ， 才会将该容器组调度至该工作节点上。 容器组的内存限制量则用于限制容 器组最大可以消耗的内存资源上限。
[30]在本公开实施例中， 由工作节点的操作系统的收集策略决定应用程序申请的内存资 源是否返还给操作系统， 但内存收集以及收集策略均由操作系统内部控制， 外部难以干 预。这会导致应用程序的闲置内存不能够及时被回收，造成内存资源浪费。退一步来说， 即使应用程序能够将闲置内存返还给操作 系统， 也会因为容器组的内存请求量的限制， 导致这部分内存仍旧被该容器组占据，操作系统依旧无法将这部分内存调度给其它容器 组使用， 从而导致工作节点的内存即使够用， 也会因为容器组层面的资源策略导致其余 容器组因内存资源不足而无法被部署或者无法使用这部分闲置内存资源。
[31]针对在容器组内存资源使用率低时， 被容器组占用的内存无法释放， 从而造成内存 资源浪费的技术问题， 本公开实施例提供一种内存调度方法， 利用承载应用程序的运行 环境为应用程序提供的内存弹性释放功能，动态释放所述应用程序从工作节点申请的部 分内存申请量， 以得到所述应用程序的实际内存占用量； 进一步， 以容器组内各应用程 序的实际内存占用量为依据， 确定容器组的实际内存需求量， 才艮据容器组的实际内存需 求量， 动态调整配置给容器组的内存请求量， 从而实现容器组内存请求量的弹性伸缩， 进而实现内存资源的合理利用， 避免了内存资源浪费， 节省的内存资源可供操作系统调 度分配， 提高内存资源利用率。
[32]以下结合附图， 详细说明本公开各实施例提供的技术方案。 图 la和图 lb为本公开 一示例性实施例提供的一种内存调度系统的结构示意图。本实施例可应用于 K8S容器集 群环境中， 用以实现容器组的内存弹性伸缩， 但不限于 K8S环境。
[33]如图 la所示， 该系统 100包括： 至少一个工作节点 103和调度控制器 101; 每个工 作节点 103上部署有至少一个容器组， 每个容器组包括至少一个容器， 每个容器中运行 有应用程序。 其中， 为了便于描述， 在本公开实施例的部分描述中， 可以将 “工作节点” 简称为 “节点”。 [34]在本实施例中， 调度控制器 101 , 用于监测应用程序的实际内存使用信息； 根据应 用程序的实际内存使用信息， 释放应用程序从工作节点申请的部分内存申请量， 以得到 应用程序的实际内存占用量； 以及， 根据同一容器组内各应用程序的实际内存占用量， 确定容器组的实际内存需求量； 才艮据容器组的实际内存需求量， 调整配置给容器组的内 存请求量。
[35]需要说明的是， 图 la中仅示出一个工作节点，但不代表本公开技术方案仅适用于一 个工作节点的情况， 本公开对工作节点的数量不作限制。 同时， 在图 la中， 示出了容 器组 A-N, 每个容器组中包括一个或多个容器， 在图 la中， 以每个容器组包括容器 1- 容器 x为例进行图示。 另外， 在图 la中， 以容器组 N中的容器 1为例对本公开实施例 提供的针对应用程序的内存调度方案进行示例，其他容器（例如容器 x）可参考容器 1 , 其他容器组 （例如容器组 A）中的容器也可参考容器组 N中的容器 1。 后续附图与图 la 类似， 均以容器组 N中的容器 1的信号流向关系进行举例说明，在后续实施例中不再赘 述。
[36]进一步可选地， 如图 lb所示， 每个容器中还运行有应用程序的运行环境，调度控制 器 101包括：部署在运行环境中的内存管理模块 1012, 以及部署在容器组外部的内存调 度节点 101 L
[37]在本实施例中， 应用程序的运行环境是应用程序的运行载体， 负责为应用程序提供 运行条件和相关资源， 在具体实现上会因应用程序采用的编程语言的不同而有所不同。 在一可选实施例中， 应用程序的运行环境可以实现为基于编程语言的虚拟机， 相应地， 应用程序为基于该编程语言实现的应用程序； 本公开实施例并不限定编程语言的类型。 可选地， 若编程语言为 java（—种广泛使用的计算机编程语言） ， 则基于编程语言的虚 拟机为 JVM（ Java Virtual Machine, Java虚拟机） ， 应用程序为 java程序； 或者， 可选 地， 若编程语言为 ruby（一种面向对象、 指令式、 函数式、 动态的通用编程语言） ， 则 基于编程语言的虚拟机为 YARV （Yet another Ruby VM, 基于 ruby的虚拟机） ， 相应 地， 应用程序为 ruby程序。 在本公开实施例中， 如图 lb所示， 在上述运行环境中增设 内存管理模块 1012; 内存管理模块 1012, 用于监测应用程序的实际内存使用信息； 根 据应用程序的实际内存使用信息，动态释放应用程序从工作节点申请的部分内存申请量 , 以得到应用程序的实际内存占用量。 这里的 “释放 ”是指将应用程序从工作节点申请的部 分内存申请量归还给 OS （ Operating System, 操作系统） 。 进一步可选地， 在应用程序 运行过程中， 若发现内存资源不足， 应用程序可以按需向工作节点的操作系统动态申请 内存资源， 需要注意的是， 应用程序向工作节点的操作系统申请内存资源的总量不应该 超过预先为应用程序所属容器组配置的内存请求量， 其中， 容器组会才艮据内存请求量向 工作节点的操作系统申请内存资源。 相比于传统技术方案， 在本公开实施例中， 通过在 应用程序的运行环境中增设内存管理模块 1012,可以监测应用程序的实际内存的使用信 息， 并动态释放掉空闲内存， 将空闲内存归还给 OS。
[38]进一步， 如图 lb所示， 在本实施例的系统 100中还包括： 内存调度节点 1011 , 用 于根据同一容器组内各应用程序的实际内存占用量， 确定容器组的实际内存需求量， 其 中，该容器组的实际内存需求量可以才艮据同一容器组中所有应用程序的实际内存量确定, 例如可以是该容器组中所有应用程序的实际内存量之和，也可以是该容器组中所有应用 程序的实际内存量的加权求和，还可以是该容器组中所有应用程序的实际内存量之和的 若干倍， 等等； 进而， 根据容器组的实际内存需求量， 动态调整配置给该容器组的内存 请求量。 在本实施例中， 通过内存调度节点 1011与内存管理模块 1012相互配合， 在内 存管理模块 1012能够动态释放应用程序从工作节点申请的部分内存申请量的基础上， 内存调度节点 1011据此可以动态调整配置给该容器组的内存请求量， 以容器组内各应 用程序的实际内存占用量为依据， 确定容器组的实际内存需求量， 才艮据容器组的实际内 存需求量， 动态调整配置给容器组的内存请求量， 从而实现容器组内存请求量的弹性伸 缩， 节约内存资源， 有利于提高内存资源利用率。
[39]在本实施例中， 工作节点的 OS可以提供的内存资源是指该节点可用于分配的总内 存量； 当在容器环境中部署应用程序时， 可以为每个容器配置其内存请求量和内存限制 量， 内存申请量是应用程序从工作节点的 OS申请的内存大小 （等于内存请求量） ， 以 满足自身的内存需求； 应用程序所属的容器组的内存申请量是指该容器组内所有容器的 内存请求量之和，应用程序所属的容器组的内存申请量是 K8S调度时考虑的重要参数之 一， 在调度时确保节点上所有容器组的内存申请量不会超过该节点的 OS可以提供的内 存资源。
[40]在一可选实施例中， 应用程序的运行环境还可以对外提供参数配置接口， 允许用户 对应用程序的相关参数进行配置。 基于此， 在应用程序启动时， 通过其运行环境提供的 参数配置接口重新配置应用程序的初始内存大小， 以使应用程序在启动后按照重新配置 的初始内存大小向工作节点申请内存空间； 其中， 重新配置的初始内存大小小于默认的 初始内存大小。 通过这种方式， 可以在应用程序启动时尝试寻求最合适的内存大小， 以 减少内存占用。
[41]进一步， 为了便于获取应用程序的实际内存使用信息， 还可以在应用程序启动时通 过其运行环境提供的参数配置接口为应用程序配置触发 GC（ Garbage Collection, 垃圾 回收）操作的时间间隔， 以便于将 GC操作从被动触发变更为主动触发， 进而便于统计 应用程序的实际内存使用信息。 其中， 被动触发 GC操作是指在应用程序的内存资源使 用量达到默认使用量阈值的情况下触发的 GC操作， 主动触发 GC操作是指根据设定的 时间间隔周期性触发的 GC操作。 基于此， 内存管理模块 1012在监测至少一个容器中 的应用程序的实际内存使用信息时 ,基于预先配置的触发垃圾回收 GC操作的时间间隔 , 周期性对应用程序从容器组所在工作节点申请到的内存空间进行 GC操作， 以得到应用 程序的实际内存使用信息。 可选地， 本公开实施例并不限定通过参数配置接口配置的触 发 GC操作的条件， 可以是如上述的时间间隔， 也可以是内存使用量达到的阈值（该设 定阈值小于默认使用量阈值）等各种能够提高 GC操作执行频率的触发条件。
[42]需要说明的是， 在本公开实施例中， 基于预先配置的触发垃圾回收 GC操作的时间 间隔， 周期性对应用程序从容器组所在工作节点申请到的内存空间进行 GC操作， 是在 虚拟机原有的垃圾回收机制上新增的 GC操作， 原有的垃圾回收机制也是可以正常运行 的。 原有的垃圾回收机制可以是上文中提到的基于默认使用量阈值被动触发 GC操作的 机制。
[43]其中， 本公开实施例并不限定通过参数配置接口进行相关参数调整的时机， 可以是 在应用程序启动时进行调整，也可以在应用程序运行过程中随时通过参数配置接口进行 相关参数的调整。
[44]以应用程序的运行环境为基于编程语言的虚拟机（例如 JVM）为例， 为了实现主动 触发 GC操作， 提高 GC操作被触发的频率， 内存管理模块 1012在应用程序启动时， 会 在用户授权的情况下修改用户的修改虚拟机 （如 JVM）的参数， 并追加部分参数， 以使 得虚拟机在较为空闲的情况， 主动触发 GC操作。 其中， 修改虚拟机（如 JVM）的参数 包括但不限于以下至少一种： 垃圾收集算法、 最大堆内存大小、 最小堆内存大小以及初 始堆内存大小， 对这些参数的修改以减少应用程序占用的内存资源为目标。 追加的部分 参数包括以下至少一种： GC的回收周期和回收策略参数， 其中， 回收策略参数是指垃 圾收集算法在执行的过程中会暴露的回收策略参数，例如可以是确定哪些对象占用的内 存资源应该被回收的策略参数，也可以是确定哪些对象占用的内存资源不应该被回收的 策略参数， 当然， 本公开实施例也允许增加一些回收策略参数， 新增的策略参数的目的 是为了准确且合理确定应用程序需要被回收的内存资源为目标， 在实现主动触发 GC操 作的基础上， 可以更加准确确定应用程序需要被回收的内存资源， 据此达到监测应用程 序的实际内存使用信息的目的。其中，堆内存是指基于 java语言编写的应用程序的内存。
[45]在本实施例中，执行 GC操作可以得到应用程序中被标记的存活对象和 /或死亡对象, 其中， 当对象已死时（不会再使用）就该回收对应的内存区域， 当对象存活时（有可能 使用 ）就不能回收， 其中， 本公开并不限定对象存活判定算法， 可选地， 可以采用引用 计数法， 通过给每个添加一个引用计数器来追踪该对象的引用数量， 每当对象新增一个 引用时， 计数器加 1 , 当引用失效时， 计数器减 1 , 当计数器变为 0时， 则意味着该对 象不会再被使用。 在另一可选实施例中， 也可采用可达性分析算法， 可达性分析算法作 为 JVM垃圾回收机制的核心， 从一组称为“ GC Roots,,的根对象开始， 沿引用关系向下 搜索， 搜索过程经过的路径称为引用链； 如果某个对象到所有 “GC Roots”都没有引用链 相连时， 则认为该对象是不可达的， 即判定为该对象已死。 如何判定对象是否存活的方 式， 可以是 GC策略中预置的回收策略参数， 也可以作为上述实施例提到的被追加的回 收策略参数实现。
[46]进一步可选地， 根据应用程序中被标记的存活对象和/或垃圾对象占用的内存空间， 得到应用程序的实际内存使用信息。 可选地， 实际内存使用信息可以包括存活对象占用 的内存大小、 空闲内存大小以及应用程序当前申请的内存大小总和等。
[47]在本实施例中，对应用程序从容器组所在工作节点申请到的内存空间进行 GC操作， 可以将应用程序所占用的内存空间进行规整， 即存活对象对应的内存空间保留， 而对死 亡对象对应内存空间进行回收， 回收的内存空间依旧归该应用程序， 可被该应用程序继 续使用，当然，这部分内存空间也属于应用程序所属的容器组的内存申请量中的一部分。 然而， 从提高内存资源利用率的角度来看， 最终需要在 OS层面完成空闲内存的回收， 因此， 需要内存管理模块 1012动态释放应用程序的部分内存申请量， 在此说明， 在本 公开实施例中 ， 回收是指将空闲内存回收至容器组层面， 释放是指将空闲内存归还给 OS 层面。
[48]为了将空闲内存归还给 OS层面， 在一可选实施例中， 内存管理模块 1012在根据应 用程序的实际内存使用信息， 动态释放应用程序的部分内存申请量， 以得到应用程序的 实际内存占用量时， 包括： 根据应用程序的实际内存使用信息， 预测应用程序的实际内 存需求量； 在应用程序的实际内存需求量小于应用程序当前的内存申请量的情况下， 确 定内存释放量;根据内存释放量,调用容器组所在工作节点的 OS提供的内存释放函数， 将应用程序的部分内存申请量归还 OS, 以得到应用程序的实际内存占用量。
[49]在一可选实施例中， 内存管理模块 1012在根据应用程序的实际内存使用信息，预测 应用程序的实际内存需求量时， 包括： 根据应用程序的实际内存使用信息， 结合应用程 序在历史时段内的实际内存占用量、 应用程序的运行规律信息、 应用程序所处的应用场 景以及应用程序在历史时段内的实际内存使用信息中的至少一种，预测应用程序的实际 内存需求量。 例如， 可以根据应用程序当前的实际内存使用信息， 得到存活对象占用的 内存大小、 空闲内存大小以及当前的内存大小总和， 其中， 空闲内存大小则为可以释放 的内存总量。 进一步， 可以结合历史时段内的实际内存占用量， 该实际内存占用量可以 取历史时间段内的内存占用量的峰值、 平均值等， 可选地， 以历史时间段内的实际内存 占用量的平均值为预测应用程序的实际内存需求量。 又例如， 还可以结合历史时段内的 应用程序的运行规律信息， 分析出用户活动的高峰和低谷， 基于此预测内存需求变化， 在高峰时期， 通常意味着更多的并发用户访问， 会导致预测应用程序的实际内存需求量 显著增加； 相反， 在低谷时期， 则可以削减预测应用程序的实际内存需求量。 再例如， 还可结合历史时段内的应用程序所处的应用场景， 如该应用程序为电商平台， 且将迎来 促销活动， 则基于历史时间段内的数据， 预测应用程序的实际内存需求量可能会额外增 加 30 %。
[50]进一步， 在应用程序的实际内存需求量小于应用程序当前的内存申请量的情况下， 确定内存释放量时， 可选地， 可以设定一个阈值， 当在应用程序的实际内存需求量小于 应用程序当前的内存申请量的情况下， 同时小于该阈值时， 确定内存释放量。 可选地， 确定内存释放量， 包括： 才艮据应用程序的类型、 应用程序所处的应用场景以及应用程序 的实际内存需求量与应用程序当前的内存申请量的差值中的至少一种，确定内存释放量。 例如， 若应用程序的类型为视频类等比较耗费内存的应用， 则在确定内存释放量时， 可 以少量释放， 以保证高性能和良好的用户体验。 又例如， 如该应用程序为电商平台， 且 将迎来促销活动 （高峰期场景） ， 也可少量释放， 以应对活动期间用户访问量激增带来 的内存消耗。 再例如， 在应用程序的实际内存需求量与应用程序当前的内存申请量的差 值较大时， 说明此时的分配给应用程序的内存大小是冗余的， 基于此， 可以大量释放； 相反地， 若差值较小， 则说明此时分配给应用程序的内存大小是较为紧张的， 基于此， 可以少量释放。
[51]其中，在本公开实施例中，并不限定内存调度节点 1011获取各应用程序的实际内存 中占用量的方式， 例如可以是采用 pull（拉取）的方式， 也可以采用 push的方式， 在实 际应用中可根据需求选用不同的方式。 可选地， 在采用 pull方式时， 内存调度节点 1011 定期从应用程序拉取各应用程序的实际内存中占用量。 可选地， 在采用 push方式时， 应用程序主动将其实际内存占用量发送给内存调度节点 101 L
[52]在另一可选实施例中， 还可以利用指标服务器来获取应用程序的实际内存占用量， 如图 2所示， 内存调度系统 100还包括： 指标服务器 201 , 用于采集工作节点上各个应 用程序的实际内存占用量， 并对同一容器组内各应用程序的实际内存占用量进行聚合后 提供给内存调度节点 1011 , 以供内存调度节点 1011根据同一容器组对应的聚合结果确 定容器组的实际内存需求量。 可选地， 可以将同一容器组内各应用程序的实际内存占用 量直接求和或加权求和， 以得到聚合结果， 在此说明， 凡是根据应用程序的实际内存占 用量得到对应的聚合结果的均适用于本公开实施例。
[53]在一示例中， 在本实施例中， 指标服务器 201中存储了各节点的监测数据， 并提供 API以供分析和使用， 这些监测数据包括但不限于工作节点上各个容器组内各应用程序 的实际内存占用量。 具体地， 在工作节点上还可以部署代理组件和采集组件， 指标服务 器通过汇聚和转换来自代理组件和采集组件的监测数据，并以 API方式暴露出去供外部
（如内存调度节点 1011）访问。 其中， 采集组件是用于收集关于容器的监测数据； 代理 组件一方面用于向外部汇报容器组和/或工作节点的相关状态信息，另一方面用于接收外 部发送的修改信息， 用来修改容器组的相关信息， 例如可通过该代理组件来修改容器组 的内存请求量。
[54]在本公开实施例中， 并不限定才艮据同一容器组对应的聚合结果确定容器组的实际内 存需求量的方式。 在一可选实施例中， 可以将聚合结果乘以预设系数， 以得到容器组的 实际内存需求量， 其中， 预设系数可以根据历史经验值进行设置。 在另一种可选实施例 中，还可以借助机器学习模型来根据同一容器组对应的聚合结果确定容器组的实际内存 需求量。
[55]进一步可选地， 如图 3所示， 内存调度系统 100还可以包括： 策略配置节点 301 , 用于面向用户提供策略配置接口，接收用户通过策略配置接口配置的至少一种资源弹性 策略； 内存调度节点 1011还用于从策略配置节点 301获取至少一种资源弹性策略， 并 在容器组的实际内存需求量满足至少一种资源弹性策略的情况下，调整配置给容器组的 内存请求量。 [56]在本实施例中，配置接口可以是命令接口、文件接口或者交互界面（如 web页面等）， 本公开对此不作限制。
[57]其中， 用户配置的资源弹性策略包括： 非自定义策略和自定义策略； 非自定义策略 是一组预置的资源弹性策略，用户可以通过策略接口从中选择一种或多种非自定义策略, 非自定义策略包括但不限于： 扰动策略和阈值策略等； 其中， 扰动策略是指判断容器组 的实际内存需求量在设定时间段内的波动情况是否位于一定的波动范围内，该策略是为 了确保例如设定波动范围为 30 % , 当容器组的实际内存需求量在设定时间段内 （如 1 小时）的波动情况小于或等于 30 %时， 则判断结果为是； 阈值策略是指判断容器组的实 际内存需求量是否超过一定的内存安全阈值， 内存安全阈值是指为了确保系统稳定避免 内存溢出的最小内存值，例如设定内存安全阈值为 50 % , 当容器组的实际内存需求量超 过 50 %时， 则判断结果为是。 可选地， 关于波动范围和内存安全阈值是预定义的。
[58]相对于非自定义策略， 自定义策略是用户根据需求自行配置的， 用户可配置一种或 多种自定义策略， 可选地， 至少一种资源弹性策略至少包括用户的自定义策略。 自定义 策略包括手动策略和根据自定义的策略描述信息自动生成的策略； 其中， 手动策略是指 可以临时增加的策略， 允许用户在必要时对资源弹性策略进行手动干预， 从而进行即时 调整。 此外， 自定义策略在根据自定义的策略描述信息自动生成的策略时， 策略描述信 息中可以包括策略相关的信息， 例如设定占比或优先级等， 进而从策略描述信息中解析 出自定义策略。 在一示例中， 用户在策略描述信息中定义了容器组的实际内存需求量小 于容器组的内存请求量的 20 % （设定占比）， 则该自定义策略（简称为比较策略）为判 断容器组的实际内存需求量是否不大于当前分配给容器组的内存请求量的 20 % ,不大于 则判断结果为是； 在另一示例中， 用户在策略描述信息中定义了容器组的优先级， 则自 定义策略 （简称为优先级策略）为判断容器组的优先级是否低于设定的优先级， 低于则 判断结果为是， 一般来说， 优先级越高， 则代表该容器组越重要， 其内存请求量也就越 不容易被释放。
[59]需要说明的是， 非自定义策略和自定义策略均可单独使用， 也可结合使用， 本公开 对此不作限制。 当用户通过策略配置接口配置的至少一种资源弹性策略后， 需根据所述 至少一种资源弹性策略分别执行对应的判断操作 ,在所述至少一种资源弹性策略对应的 判断操作的判断结果均为是的情况下，确定容器组的实际内存需求量满足所述至少一种 资源弹性策略。
[60]进一步， 在容器组的实际内存需求量满足至少一种资源弹性策略的情况下， 动态调 整配置给容器组的内存请求量。 其中， 至少一种资源弹性策略中， 每一种资源弹性策略 都预设有对应的调整策略。 在一示例中， 至少一种资源弹性策略包括阈值策略， 阈值策 略对应的调整策略是将容器组的请求量调整至与需求量相等。 在另一示例中， 至少一种 资源弹性策略包括比较策略， 比较策略对应的调整策略是将容器组的需求量调整至大于 内存请求量的设定占比， 同时小于容器组的内存请求量。
[61]在本公开实施例中， 并不限定调整配置给容器组的内存请求量的具体实现方式， 在 一示例中， 本实施例的系统 100允许容器在无需重启的情况下（原地升级） ， 调整分配 给容器组的 CPU和内存资源， 基于此， 在容器组的实际内存需求量满足至少一种资源 弹性策略的情况下， 内存调度节点 1011生成对工作负载的调整请求， 该调整请求可以 实现为 Patch请求，该 Patch请求是一种 HTTP请求方法，用于将局部修改应用到资源， 容器组通过工作 负载实现应用程序的内存请求量的伸缩； 工作负载在接收到调整请求
（如 Patch请求）后， 修改容器组的内存请求量， 从而实现用户的容器组实际占据内存 的降低。
[62]在本实施例中， 提供了丰富的策略扩展机制， 可以扩展相应的资源弹性策略以适应 用户的需求变化。 此外， 自定义策略的介入尤其是手动策略， 可以保证弹性伸缩行为的 稳定性。
[63]进一步， 本公开实施例还提供一种内存调度系统 400, 该系统 400部署在 K8S容器 集群环境中， 该系统 400包括： 至少一个工作节点 103和内存调度节点 1011、指标服务 器 201以及策略配置节点 301; 每个工作节点 103上部署有至少一个容器组， 每个容器 组包括至少一个容器， 每个容器中运行有应用程序及其运行环境 JVM。 在 JVM中提供 有内存管理模块 1012。
[64]如图 4所示， 内存调度系统 400的各部分工作关系的示意图。 为了突出各部分的功 能， 在图 4中对各个部分的包含关系不进行限定， 例如将内存管理模块 1012从 JVM中 抽离出， 并对其功能进行拆解， 以流程的方式展示内存管理模块 1012的功能。 同时需 要说明的是，图 4中以容器组 N中的容器 1对本公开实施例中提供的内存调度方法进行 举例说明， 并不代表本公开实施例提供的内存调度方法仅适用于容器 1或单一容器， 本 公开对容器组的数量以及每个容器组包含的容器数量不作限制。
[65]在本实施例中， 基于预置启动命令， 主动触发垃圾回收 GC操作， 周期性对应用程 序从容器组所在工作节点申请到的内存空间进行 GC操作， 以得到应用程序的实际内存 使用信息； 其中， 触发 GC操作的时间间隔是在应用程序启动时通过其运行环境 JVM 提供的参数配置接口为应用程序配置的。
[66]进一步， 内存管理模块 1012根据应用程序的实际内存使用信息，动态释放应用程序 的部分内存申请量， 以得到所述应用程序的实际内存占用量； 如图 4所示， 经历步骤② 处理后， 应用程序实际占用量降低。
[67]指标服务器 201采集工作节点上应用程序的实际内存占用量， 并对容器组 N内各应 用程序的实际内存占用量进行聚合后提供给内存调度节点 1011; 内存调度节点 1011在 接收到聚合结果后， 根据容器组 N对应的聚合结果确定容器组 N的实际内存需求量。
[68]进一步， 内存调度节点 1011从策略配置节点 301获取至少一种资源弹性策略，并执 行每一种资源弹性策略 （如图 4中的扰动策略、 阈值策略以及自定义策略）对应的判断 操作， 在每一种资源弹性策略对应的判断操作的判断结果均为是的情况下， 确定容器组 N 的实际内存需求量满足至少一种资源弹性策略。
[69]在容器组 N的实际内存需求量满足至少一种资源弹性策略的情况下， 内存调度节点 1011生成对工作负载的 Patch请求，容器组 N通过工作负载实现应用程序的内存请求量 的伸缩； 工作负载在接收到 Patch请求后， 修改容器组 N的内存请求量， 从而实现用户 的容器组 N实际占据内存的降彳氐。
[70]图 5为本公开实施例提供的一种内存调度方法，如图 5所示，该方法包括以下步骤。
[71] S501: 针对包含至少一个容器的容器组， 监测至少一个容器中的应用程序的实际内 存使用信息。
[72] S502: 根据应用程序的实际内存使用信息， 释放应用程序的部分内存申请量， 以得 到应用程序的实际内存占用量。
[73] S503:根据容器组内各应用程序的实际内存占用量，确定容器组的实际内存需求量。
[74] S504: 才艮据容器组的实际内存需求量， 调整配置给容器组的内存请求量。
[75]需要说明的是， 上述实施例所提供方法的各步骤的执行主体均可以是同一设备， 或 者， 该方法也由不同设备作为执行主体。 比如， 步骤 501至步骤 502的执行主体可以为 上述系统实施例中的内存管理模块 1012,步骤 503和步骤 504的执行主体可以为上述系 统实施例中的内存调度节点 1011; 等等。
[76]在一可选实施例中，监测至少一个容器中的应用程序的实际内存使用信息时，包括： 基于预先配置的触发垃圾回收 GC操作的时间间隔， 周期性对应用程序从容器组所在工 作节点申请到的内存空间进行 GC操作， 以得到应用程序的实际内存使用信息； 其中， 触发 GC操作的时间间隔是在应用程序启动时通过其运行环境提供的参数配置接口为应 用程序配置的。
[77]在一可选实施例中， 所述方法还包括： 在应用程序启动时， 通过参数配置接口重新 配置应用程序的初始内存大小， 以使应用程序在启动后按照重新配置的初始内存大小向 工作节点申请内存空间； 其中， 重新配置的初始内存大小小于默认的初始内存大小。
[78]在一可选实施例中， 在根据应用程序的实际内存使用信息， 释放应用程序的部分内 存申请量， 以得到应用程序的实际内存占用量时， 包括： 根据应用程序的实际内存使用 信息， 预测应用程序的实际内存需求量； 在应用程序的实际内存需求量小于应用程序当 前的内存申请量的情况下， 确定内存释放量； 才艮据内存释放量， 调用容器组所在工作节 点的 O S提供的内存释放函数， 将应用程序的部分内存申请量归还 OS, 以得到应用程 序的实际内存占用量。
[79]在一可选实施例中， 在根据应用程序的实际内存使用信息， 预测应用程序的实际内 存需求量时， 包括： 根据应用程序的实际内存使用信息， 结合应用程序在历史时段内的 实际内存占用量、 应用程序的运行规律信息、 应用程序所处的应用场景以及应用程序在 历史时段内的实际内存使用信息中的至少一种， 预测应用程序的实际内存需求量。
[80]在一可选实施例中， 在确定内存释放量时， 包括： 根据应用程序的类型、 应用程序 所处的应用场景以及应 用程序的实际内存需求量与应用程序当前的内存申请量的差值 中的至少一种， 确定内存释放量。
[81]在一可选实施例中， 在才艮据容器组内各应用程序的实际内存占用量， 确定容器组的 实际内存需求量时， 包括： 从指标服务器获取容器组对应的内存聚合信息， 内存聚合信 息是指标服务器对容器组内各应用程序的实际内存占用量进行聚合得到的；根据容器组 对应的内存聚合信息， 确定容器组的实际内存需求量。
[82]在一可选实施例中， 在才艮据容器组的实际内存需求量， 调整配置给容器组的内存请 求量时， 包括： 获取用户预先配置的至少一种资源弹性策略； 在容器组的实际内存需求 量满足至少一种资源弹性策略的情况下， 调整配置给容器组的内存请求量。
[83]在一可选实施例中， 所述方法还包括执行以下至少一种判断操作： 在至少一种资源 弹性策略包括扰动策略的情况下，判断容器组的实际内存需求量在设定时间段内的波动 情况是否位于扰动策略中的波动范围内；在至少一种资源弹性策略包括阈值策略的情况 下， 判断容器组的实际内存需求量是否超过阈值策略中的内存安全阈值； 在至少一种资 源弹性策略包括比较策略的情况下，判断容器组的实际内存需求量是否不大于当前分配 给容器组的内存请求量的设定占比；在上述至少一种判断操作的判断结果均为是的情况 下， 确定容器组的实际内存需求量满足至少一种资源弹性策略。
[84]在一可选实施例中，所述方法还包括:响应用户通过策略配置接口发起的配置操作， 获取用户配置的至少一种资源弹性策略， 至少一种资源弹性策略至少包括用户的自定义 策略。
[85]图 6为本公开实施例提供的一种内存调度方法，如图 6所示，该方法包括以下步骤。
[86] S601: 扫描承载于容器中的应用程序从所属工作节点申请的内存空间， 以得到应用 程序的实际内存使用信息。 [87] S602: 根据应用程序的实际内存使用信息， 释放应用程序的部分内存申请量， 以得 到应用程序的实际内存占用量。
[88]在一可选实施例中， 在扫描所述应用程序从所属工作节点申请的内存空间， 以得到 应用程序的实际内存使用信息时， 包括： 基于预先配置的触发垃圾回收 GC操作的时间 间隔， 周期性对应用程序从所述容器组所在工作节点申请到的内存空间进行 GC操作, 以得到应用程序的实际内存使用信息； 其中， 触发 GC操作的时间间隔是在应用程序启 动时通过其运行环境提供的参数配置接口为应用程序配置的。
[89]在一可选实施例中， 所述方法还包括： 在应用程序启动时， 通过参数配置接口重新 配置应用程序的初始内存大小， 以使应用程序在启动后按照重新配置的初始内存大小向 所述工作节点申请内存空间；其中，重新配置的初始内存大小小于默认的初始内存大小。
[90]在一可选实施例中， 在根据应用程序的实际内存使用信息， 释放应用程序的部分内 存申请量， 以得到应用程序的实际内存占用量时， 包括： 根据应用程序的实际内存使用 信息， 预测应用程序的实际内存需求量； 在应用程序的实际内存需求量大于应用程序当 前的内存申请量的情况下， 确定内存释放量； 才艮据内存释放量， 调用容器组所在工作节 点的 O S提供的内存释放函数， 将应用程序的部分内存申请量归还 OS, 以得到应用程 序的实际内存占用量。
[91]在一可选实施例中， 所述方法还包括： 在应用程序运行过程中， 若应用程序的实际 内存需求量大于应用程序的实际内存占用量， 向工作节点动态申请内存空间。 需要说明 的是， 这个申请动作是应用程序向工作节点申请的， 而不是内存管理模块 1012。
[92]关于本实施例方法中各步骤的详细实施方式以及有益效果已经在前述实施例中进行 了详细描述， 此处将不做详细阐述说明。
[93]另夕卜， 在上述实施例及附图中的描述的一些流程中， 包含了按照特定顺序出现的多 个操作， 但是应该清楚了解， 这些操作可以不按照其在本文中出现的顺序来执行或并行 执行， 操作的序号如 501、 502等， 仅仅是用于区分开各个不同的操作， 序号本身不代 表任何的执行顺序。 另夕卜， 这些流程可以包括更多或更少的操作， 并且这些操作可以按 顺序执行或并行执行。 需要说明的是， 本文中的 “第一”、 “第二 ”等描述， 是用于区分不 同的消息、 设备、 模块等， 不代表先后顺序， 也不限定 “第一 ”和 “第二 ”是不同的类型。
[94]图 7为本公开一示例性实施例提供的一种内存调度装置， 如图 7所示， 内存调度装 置 700包括： 监测模块 71、 释放模块 72、 确定模块 73以及调整模块 74。
[95]监测模块 71 , 用于针对包含至少一个容器的容器组， 监测所述至少一个容器中的应 用程序的实际内存使用信息。
[96]释放模块 72, 用于根据所述应用程序的实际内存使用信息， 释放所述应用程序的部 分内存申请量， 以得到所述应用程序的实际内存占用量。
[97]确定模块 73, 才艮据所述容器组内各应用程序的实际内存占用量， 确定所述容器组的 实际内存需求量。
[98]调整模块 74, 用于才艮据所述容器组的实际内存需求量， 调整配置给所述容器组的内 存请求量。
[99]在一可选实施例中，监测模块 71监测至少一个容器中的应用程序的实际内存使用信 息时， 具体用于： 基于预先配置的触发垃圾回收 GC操作的时间间隔， 周期性对应用程 序从容器组所在工作节点申请到的内存空间进行 GC操作， 以得到所述应用程序的实际 内存使用信息； 其中， 触发 GC操作的时间间隔是在所述应用程序启动时通过其运行环 境提供的参数配置接口为所述应用程序配置的。 [100]在一可选实施例中， 调整模块 74还用于： 在所述应用程序启动时， 通过所述参数 配置接口重新配置所述应用程序的初始内存大小， 以使所述应用程序在启动后按照重新 配置的初始内存大小向所述工作节点申请内存空间； 其中， 重新配置的初始内存大小小 于默认的初始内存大小。
[101]在一可选实施例中， 释放模块 72在根据所述应用程序的实际内存使用信息， 释放 所述应用程序的部分内存申请量，以得到所述应用程序的实际内存占用量时，具体用于： 根据所述应用程序的实际内存使用信息， 预测所述应用程序的实际内存需求量； 在所述 应用程序的实际内存需求量小于所述应用程序当前的内存申请量的情况下，确定内存释 放量;根据所述内存释放量，调用所述容器组所在工作节点的 OS提供的内存释放函数， 将所述应用程序的部分内存申请量归还 OS , 以得到所述应用程序的实际内存占用量。
[102]在一可选实施例中， 释放模块 72在根据所述应用程序的实际内存使用信息， 预测 所述应用程序的实际内存需求量时，具体用于：根据所述应用程序的实际内存使用信息， 结合所述应用程序在历史时段内的实际内存占用量、 所述应用程序的运行规律信息、 所 述应用程序所处的应用 场景以及所述应用程序在历史时段内的实际内存使用信息中的 至少一种， 预测所述应用程序的实际内存需求量。
[103]在一可选实施例中， 释放模块 72在确定内存释放量时， 具体用于： 根据所述应用 程序的类型、所述应用程序所处的应用场景以及所述应用程序的实际内存需求量与所述 应用程序当前的内存申请量的差值中的至少一种， 确定所述内存释放量。
[104]在一可选实施例中， 确定模块 73在才艮据所述容器组内各应用程序的实际内存占用 量， 确定所述容器组的实际内存需求量时， 具体用于： 从指标服务器获取所述容器组对 应的内存聚合信息， 所述内存聚合信息是指标服务器对所述容器组内各应用程序的实际 内存占用量进行聚合得到的； 根据所述容器组对应的内存聚合信息， 确定所述容器组的 实际内存需求量。
[105]在一可选实施例中， 调整模块 74在根据所述容器组的实际内存需求量， 调整配置 给所述容器组的内存请求量时， 包括： 获取用户预先配置的至少一种资源弹性策略； 在 所述容器组的实际内存需求量满足所述至少一种资源弹性策略的情况下， 动态调整配置 给所述容器组的内存请求量。
[106]在一可选实施例中， 调整模块 74还用于执行以下至少一种判断操作： 在所述至少 一种资源弹性策略包括扰动策略的情况下，判断所述容器组的实际内存需求量在设定时 间段内的波动情况是否位于所述扰动策略中的波动范围内；在所述至少一种资源弹性策 略包括阈值策略的情况下，判断所述容器组的实际内存需求量是否超过所述阈值策略中 的内存安全阈值； 在所述至少一种资源弹性策略包括比较策略的情况下， 判断所述容器 组的实际内存需求量是否不大于当前分配给所述容器组的内存请求量的设定占比； 在上 述至少一种判断操作的判断结果均为是的情况下，确定所述容器组的实际内存需求量满 足所述至少一种资源弹性策略。
[107]在一可选实施例中， 调整模块 74还用于： 响应用户通过策略配置接口发起的配置 操作， 获取用户配置的至少一种资源弹性策略， 所述至少一种资源弹性策略至少包括用 户的自定义策略。
[108]图 8为本公开实施例提供的一种内存调度装置， 如图 8所示， 内存调度装置 800 包括： 扫描模块 81和释放模块 82 „
[109]扫描模块 81 ,用于扫描承载于容器中的应用程序从所属工作节点申请的内存空间， 以得到所述应用程序的实际内存使用信息。 [110]释放模块 82, 用于根据所述应用程序的实际内存使用信息， 释放所述应用程序的 部分内存申请量， 以得到所述应用程序的实际内存占用量。
[111]在一可选实施例中， 扫描模块 81在扫描所述应用程序从所属工作节点申请的内存 空间， 以得到所述应用程序的实际内存使用信息时， 具体用于： 基于预先配置的触发垃 圾回收 GC操作的时间间隔， 周期性对所述应用程序从所述容器组所在工作节点申请到 的内存空间进行 GC操作， 以得到所述应用程序的实际内存使用信息； 其中， 触发 GC 操作的时间间隔是在所 述应用程序启动时通过其运行环境提供的参数配置接口为所述 应用程序配置的。
[112]在一可选实施例中， 释放模块 82还用于： 在所述应用程序启动时， 通过所述参数 配置接口重新配置所述应用程序的初始内存大小， 以使所述应用程序在启动后按照重新 配置的初始内存大小向所述工作节点申请内存空间； 其中， 重新配置的初始内存大小小 于默认的初始内存大小。
[113]在一可选实施例中， 释放模块 82在根据所述应用程序的实际内存使用信息， 释放 所述应用程序的部分内存申请量，以得到所述应用程序的实际内存占用量时，具体用于： 根据所述应用程序的实际内存使用信息， 预测所述应用程序的实际内存需求量； 在所述 应用程序的实际内存需求量大于所述应用程序当前的内存申请量的情况下，确定内存释 放量;根据所述内存释放量，调用所述容器组所在工作节点的 OS提供的内存释放函数， 将所述应用程序的部分内存申请量归还 OS , 以得到所述应用程序的实际内存占用量。
[114]在一可选实施例中， 内存调度装置 800还包括申请模块， 申请模块具体用于： 在 所述应用程序运行过程中，若所述应用程序的实际内存需求量大于所述应用程序的实际 内存占用量， 向所述工作节点动态申请内存空间。
[115]图 9为本公开又一示例性实施例提供的一种电子设备的结构示意图。如图 9所示， 该电子设备包括： 存储器 94和处理器 95。
[116]存储器 94, 用于存储计算机程序， 并可被配置为存储其它各种数据以支持在计算 平台上的操作。这些数据的示例包括用于在计算平台上操作的任何应用程序或方法的指 令， 联系人数据， 电话簿数据， 消息， 图片， 视频等。
[117]存储器 94可以由任何类型的易失性或非易失性存储设备或者它们的组合实现， 如 静态随机存取存储器 （SRAM） , 电可擦除可编程只读存储器（EEPROM） , 可擦除可 编程只读存储器 （EPROM） , 可编程只读存储器 （PROM） , 只读存储器 （ROM） , 磁存储器， 快闪存储器， 磁盘或光盘。
[118]处理器 95, 与存储器 94耦合， 用于执行存储器 94中的计算机程序， 以用于： 针 对包含至少一个容器的容器组，监测所述至少一个容器中的应用程序的实际内存使用信 息； 根据所述应用程序的实际内存使用信息， 释放所述应用程序的部分内存申请量， 以 得到所述应用程序的实际内存 占用量； 根据所述容器组内各应用程序的实际内存占用 量， 确定所述容器组的实际内存需求量； 才艮据所述容器组的实际内存需求量， 调整配置 给所述容器组的内存请求量。
[119]在一可选实施例中， 处理器 95在至少一个容器中的应用程序的实际内存使用信息 时， 具体用于： 基于预先配置的触发垃圾回收 GC操作的时间间隔， 周期性对应用程序 从容器组所在工作节点申请到的内存空间进行 GC操作， 以得到所述应用程序的实际内 存使用信息； 其中， 触发 GC操作的时间间隔是在所述应用程序启动时通过其运行环境 提供的参数配置接口为所述应用程序配置的。
[120]在一可选实施例中， 处理器 95还用于： 在所述应用程序启动时， 通过所述参数配 置接口重新配置所述应用程序的初始内存大小， 以使所述应用程序在启动后按照重新配 置的初始内存大小向所述工作节点申请内存空间； 其中， 重新配置的初始内存大小小于 默认的初始内存大小。
[121]在一可选实施例中， 处理器 95在根据所述应用程序的实际内存使用信息， 释放所 述应用程序的部分内存申请量， 以得到所述应用程序的实际内存占用量时， 具体用于： 根据所述应用程序的实际内存使用信息， 预测所述应用程序的实际内存需求量； 在所述 应用程序的实际内存需求量小于所述应用程序当前的内存申请量的情况下，确定内存释 放量;根据所述内存释放量，调用所述容器组所在工作节点的 OS提供的内存释放函数， 将所述应用程序的部分内存申请量归还 OS , 以得到所述应用程序的实际内存占用量。
[122]在一可选实施例中， 处理器 95在根据所述应用程序的实际内存使用信息， 预测所 述应用程序的实际内存需求量时， 具体用于： 根据所述应用程序的实际内存使用信息， 结合所述应用程序在历史时段内的实际内存占用量、 所述应用程序的运行规律信息、 所 述应用程序所处的应用 场景以及所述应用程序在历史时段内的实际内存使用信息中的 至少一种， 预测所述应用程序的实际内存需求量。
[123]在一可选实施例中， 处理器 95在确定内存释放量时， 具体用于： 才艮据所述应用程 序的类型、所述应用程序所处的应用场景以及所述应用程序的实际内存需求量与所述应 用程序当前的内存申请量的差值中的至少一种， 确定所述内存释放量。
[124]在一可选实施例中，处理器 95在根据所述容器组内各应用程序的实际内存占用量， 确定所述容器组的实际内存需求量时， 具体用于： 从指标服务器获取所述容器组对应的 内存聚合信息， 所述内存聚合信息是指标服务器对所述容器组内各应用程序的实际内存 占用量进行聚合得到的； 根据所述容器组对应的内存聚合信息， 确定所述容器组的实际 内存需求量。
[125]在一可选实施例中， 处理器 95在根据所述容器组的实际内存需求量， 调整配置给 所述容器组的内存请求量时， 包括： 获取用户预先配置的至少一种资源弹性策略； 在所 述容器组的实际内存需求量满足所述至少一种资源弹性策略的情况下，动态调整配置给 所述容器组的内存请求量。
[126]在一可选实施例中， 处理器 95还用于执行以下至少一种判断操作： 在所述至少一 种资源弹性策略包括扰动策略的情况下，判断所述容器组的实际内存需求量在设定时间 段内的波动情况是否位于所述扰动策略中的波动范围内；在所述至少一种资源弹性策略 包括阈值策略的情况下，判断所述容器组的实际内存需求量是否超过所述阈值策略中的 内存安全阈值； 在所述至少一种资源弹性策略包括比较策略的情况下， 判断所述容器组 的实际内存需求量是否不大于当前分配给所述容器组的内存请求量的设定占比； 在上述 至少一种判断操作的判断结果均为是的情况下，确定所述容器组的实际内存需求量满足 所述至少一种资源弹性策略。
[127]在一可选实施例中， 处理器 95还用于： 响应用户通过策略配置接口发起的配置操 作， 获取用户配置的至少一种资源弹性策略， 所述至少一种资源弹性策略至少包括用户 的自定义策略。
[128]进一步，如图 9所示，该电子设备还包括：通信组件 96、显示器 97、电源组件 98、 音频组件 99等其它组件。 图 9中仅示意性给出部分组件， 并不意味着电子设备只包括 图 9所示组件。 另外， 图 9中虚线框内的组件为可选组件， 而非必选组件， 具体可视工 作节点的产品形态而定。 本实施例的工作节点可以实现为台式电脑、 笔记本电脑、 智能 手机或 I0T设备等终端设备， 也可以是常规服务器、云服务器或服务器阵列等服务端设 备。 若本实施例的工作节点实现为台式电脑、 笔记本电脑、 智能手机等终端设备， 可以 包含图 9中虚线框内的组件； 若本实施例的工作节点实现为常规服务器、 云服务器或服 务器阵列等服务端设备， 则可以不包含图 9中虚线框内的组件。
[129]本公开实施例还提供一种电子设备， 该电子设备的实现结构与图 9 所示电子设备 的实现结构相同或类似， 可参照图 9所示电子设备的结构实现。 本实施例提供的电子设 备与图 9所示实施例中电子设备的区别主要在于： 处理器执行存储器中存储的计算机程 序所实现的功能不同。 对本实施例提供的电子设备来说， 其处理器执行存储器中存储的 计算机程序， 可用于： 扫描承载于容器中的应用程序从所属工作节点申请的内存空间， 以得到所述应用程序的实际内存使用信息； 根据所述应用程序的实际内存使用信息， 释 放所述应用程序的部分内存申请量， 以得到所述应用程序的实际内存占用量。
[130]在一可选实施例中， 处理器在扫描所述应用程序从所属工作节点申请的内存空间， 以得到所述应用程序的实际内存使用信息时， 具体用于： 基于预先配置的触发垃圾回收 GC 操作的时间间隔， 周期性对所述应用程序从所述容器组所在工作节点申请到的内存 空间进行 GC操作， 以得 到所述应用程序的实际内存使用信息； 其中， 触发 GC操作的 时间间隔是在所述应用程序 启动时通过其运行环境提供的参数配置接口为所述应用程 序配置的。
[131]在一可选实施例中， 处理器还用于： 在所述应用程序启动时， 通过所述参数配置 接口重新配置所述应用程序的初始内存大小， 以使所述应用程序在启动后按照重新配置 的初始内存大小向所述工作节点申请内存空间； 其中， 重新配置的初始内存大小小于默 认的初始内存大小。
[132]在一可选实施例中， 处理器在根据所述应用程序的实际内存使用信息， 释放所述 应用程序的部分内存申请量， 以得到所述应用程序的实际内存占用量时， 具体用于： 根 据所述应用程序的实际内存使用信息， 预测所述应用程序的实际内存需求量； 在所述应 用程序的实际内存需求量大于所述应用程序当前的内存申请量的情况下，确定内存释放 量； 根据所述内存释放量， 调用所述容器组所在工作节点的 OS提供的内存释放函数， 将所述应用程序的部分内存申请量归还 OS , 以得到所述应用程序的实际内存占用量。
[133]在一可选实施例中， 处理器还用于： 在所述应用程序运行过程中， 若所述应用程 序的实际内存需求量大于所述应用程序的实际内存占用量， 向所述工作节点动态申请内 存空间。
[134]关于本实施例方法中各步骤的详细实施方式以及有益效果已经在前述实施例中进 行了详细描述， 此处将不做详细阐述说明。
[135]相应地， 本公开实施例还提供一种存储有计算机程序的计算机可读存储介质， 计 算机程序被处理器执行时， 致使处理器能够实现上述方法实施例中的各步骤。
[136]相应地， 本公开实施例还提供一种计算机程序产品， 该计算机程序产品包括计算 机程序/指令， 当计算机程序/指令被处理器执行时， 致使处理器能够实现上述方法实施 例中的步骤。
[137]上述存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现， 如静态随机存取存储器 ( 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 ) , 磁存储器， 快闪存储器， 磁盘或光盘。
[138]上述通信组件被配置为便于通信组件所在设备和其他设备之间有线或无线方式的 通信。通信组件所在设备可以接入基于通信标准的无线网络，如 WiFi, 2G、 3G、 4G/LTE. 5G 等移动通信网络， 或它们的组合。 在一个示例性实施例中， 通信组件经由广播信道 接收来自外部广播管理系统的广播信号或广播相关信息。 在一个示例性实施例中， 通信 组件还包括近场通信 ( Near Field Communication, NFC )模块， 以促进短程通信。例如， 在 NFC模块可基于射频识别 ( Radio Frequency Identification, RFID )技术， 红外数据协 会 ( Infrared Data Association, IrDA )技术， 超宽带 ( Ultra Wide Band, UWB )技术， 蓝牙 ( BlueTooth, BT )技术和其他技术来实现。
[139]上述显示器包括屏幕，其屏幕可以包括液晶显示器 ( Liquid Crystal Display, LCD ) 和触摸面板 ( TouchPanel, TP ) 。 如果屏幕包括触摸面板， 屏幕可以被实现为触摸屏, 以接收来自用户的输入信号。 触摸面板包括一个或多个触摸传感器以感测触摸、 滑动和 触摸面板上的手势。 触摸传感器可以不仅感测触摸或滑动动作的边界， 而且还检测与触 摸或滑动操作相关的持续时间和压力。
[140]上述电源组件， 为电源组件所在设备的各种组件提供电力。 电源组件可以包括电 源管理系统， 一个或多个电源， 及其他与为电源组件所在设备生成、 管理和分配电力相 关联的组件。
[141] _h述音频组件， 可被配置为输出和 /或输入音频信号。 例如， 音频组件包括一个麦 克风 ( Microphone, MIC ) , 当音频组件所在设备处于操作模式， 如呼叫模式、 记录模 式和语音识别模式时， 麦克风被配置为接收外部音频信号。 所接收的音频信号可以被进 一步存储在存储器或经由通信组件发送。在一些实施例中，音频组件还包括一个扬声器, 用于输出音频信号。
[142]本领域内的技术人员应明白， 本公开的实施例可提供为方法、 系统、 或计算机程 序产品。 因此， 本公开可采用完全硬件实施例、 完全软件实施例、 或结合软件和硬件方 面的实施例的形式。 而且， 本公开可采用在一个或多个其中包含有计算机可用程序代码 的计算机可读存储介质 (包括但不限于磁盘存储器、只读光盘 ( Compact Disc Read-Only Memory, CD-ROM ) 、 光学存储器等)上实施的计算机程序产品的形式。
[143]本公开是参照根据本公开实施例的方法、 设备 (系统) 、 和计算机程序产品的流 程图和 /或方框图来描述的。应理解可由计算机程序指令实现流程图和 /或方框图中的 每一流程和 /或方框、 以及流程图和 /或方框图中的流程和 /或方框的结合。 可提供这 些计算机程序指令到通用计算机、 专用计算机、 嵌入式处理机或其他可编程数据处理设 备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行 的指令产生用于实现在 流程图一个流程或多个流程和 /或方框图一个方框或多个方框 中指定的功能的装置。
[144]这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定 方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指 令装置的制造品，该指令装置实现在流程图一个流程或多个流程和 /或方框图一个方框 或多个方框中指定的功能。
[145]这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上， 使得在计 算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机 或其他可编程设备上执行 的指令提供用于实现在流程图一个流程或多个流程和 /或方 框图一个方框或多个方框中指定的功能的步骤。
[146]在一个典型的配置中，计算设备包括一个或多个处理器 ( Central Processing Unit, CPU ) 、 输入 /输出接口、 网络接口和内存。
[147]内存可能包括计算机可读介质中的非永久性存储器， 随机存取存储器 ( Random Access Memory , RAM） 和 /或非易失性内存等形式， 如只读存储器 （ROM） 或闪存 （ flash RAM） 。 内存是计算机可读介质的示例。
[148]计算机可读介质包括永久性和非永久性、 可移动和非可移动媒体可以由任何方法 或技术来实现信息存储。 信息可以是计算机可读指令、 数据结构、 程序的模块或其他数 据。 计算机的存储介质的例子包括， 但不限于相变内存 （ Phase-change Random Access Memory, PRAM）、静态随机存取存储器 （SRAM）、 动态随机存取存储器 （ Dynamic Random Access Memory, DRAM） 、 其他类型的随机存取存储器 （RAM） 、 只读存储 器 （ROM） 、 电可擦除可编程只读存储器 （EEPROM） 、 快闪记忆体或其他内存技 术、 只读光盘只读存储器 （CD-ROM）、数字多功能光盘 （ Digital Video Disc , DVD） 或其他光学存储、 磁盒式磁带， 磁带磁盘存储或其他磁性存储设备或任何其他非传输介 质， 可用于存储可以被计算设备访问的信息。 按照本文中的界定， 计算机可读介质不包 括暂存电脑可读媒体 （ transitory media） , 如调制的数据信号和载波。
[149]还需要说明的是， 术语 “包括”、 “包含 ”或者其任何其他变体意在涵盖非排他性的包 含， 从而使得包括一系列要素的过程、 方法、 商品或者设备不仅包括那些要素， 而且还 包括没有明确列出的其他要素， 或者是还包括为这种过程、 方法、 商品或者设备所固有 的要素。 在没有更多限制的情况下， 由语句 “包括一个 ..... ”限定的要素， 并不排除在包 括要素的过程、 方法、 商品或者设备中还存在另外的相同要素。
[150]以上仅为本公开的实施例而已，并不用于限制本公开。对于本领域技术人员来说， 本公开可以有各种更改和变化。 凡在本公开的精神和原理之内所作的任何修改、 等同替 换、 改进等， 均应包含在本公开的权利要求范围之内。

Claims

权利要求书
1、 一种内存调度方法， 包括： 针对 包含至少一个容器的容器组，监测所述至少一个容器中的应用程序的实际内存 使用信息； 根据所述应用程序 的实际内存使用信息， 释放所述应用程序的部分内存申请量， 以 得到所述应用程序的实际内存占用量； 才艮据所述容器组内各应用程序的实际内存占用量，确定所述容器组的实际内存需求 量； 才艮据所述容器组的实际内存需求量， 调整配置给所述容器组的内存请求量。
2、 根据权利要求 1所述的方法， 其中， 监测所述至少一个容器中的应用程序的实 际内存使用信息， 包括： 基于预先配置 的触发垃圾回收 GC操作的时间间隔， 周期性对所述应用程序从所述 容器组所在工作节点申请到的内存空间进行 GC操作， 以得到所述应用程序的实际内存 使用信息； 其 中， 触发 GC操作的时间间隔是在所述应用程序启动时通过其运行环境提供的参 数配置接口为所述应用程序配置的。
3、 根据权利要求 2所述的方法， 还包括： 在所述应用程序启动时 ，通过所述参数配置接口重新配置所述应用程序的初始内存 大小， 以使所述应用程序在启动后按照重新配置的初始内存大小向所述工作节点申请内 存空间； 其 中， 重新配置的初始内存大小小于默认的初始内存大小。
4、 根据权利要求 1所述的方法， 其中， 根据所述应用程序的实际内存使用信息， 释放所述应用程序的部分内存申请量， 以得到所述应用程序的实际内存占用量， 包括: 根据所述应用程序 的实际内存使用信息， 预测所述应用程序的实际内存需求量； 在所述应 用程序的实际内存需求量小于所述应用程序当前的内存申请量的情况下， 确定内存释放量； 根据所述 内存释放量， 调用所述容器组所在工作节点的 OS提供的内存释放函数， 将所述应用程序的部分内存申请量归还 OS , 以得到所述应用程序的实际内存占用量。
5、 根据权利要求 4所述的方法， 其中， 根据所述应用程序的实际内存使用信息， 预测所述应用程序的实际内存需求量， 包括： 根据所述应用程序 的实际内存使用信息，结合所述应用程序在历史时段内的实际内 存占用量、 所述应用程序的运行规律信息、 所述应用程序所处的应用场景以及所述应用 程序在历史时段内的实际内存使用信息中的至少一种，预测所述应用程序的实际内存需 求量。
6、 根据权利要求 1所述的方法， 其中， 根据所述容器组内各应用程序的实际内存 占用量， 确定所述容器组的实际内存需求量， 包括： 从指标服务 器获取所述容器组对应的内存聚合信息，所述内存聚合信息是指标服务 器对所述容器组内各应用程序的实际内存占用量进行聚合得到的； 才艮据所述容器组对应的内存聚合信息， 确定所述容器组的实际内存需求量。
7、根据权利要求 6任一项所述的方法，其中，根据所述容器组的实际内存需求量， 调整配置给所述容器组的内存请求量， 包括： 获取用户预先配置 的至少一种资源弹性策略； 在所述容 器组的实际内存需求量满足所述至少一种资源弹性策略的情况下，调整配 置给所述容器组的内存请求量。
8、 根据权利要求 7所述的方法， 其中， 还包括执行以下至少一种判断操作： 在所述至少一种 资源弹性策略包括扰动策略的情况下，判断所述容器组的实际内存 需求量在设定时间段内的波动情况是否位于所述扰动策略中的波动范围内； 在所述至少一种 资源弹性策略包括阈值策略的情况下，判断所述容器组的实际内存 需求量是否超过所述阈值策略中的内存安全阈值； 在所述至少一种 资源弹性策略包括比较策略的情况下，判断所述容器组的实际内存 需求量是否不大于当前分配给所述容器组的内存请求量的设定占比； 在上述至少一种判 断操作的判断结果均为是的情况下，确定所述容器组的实际内存 需求量满足所述至少一种资源弹性策略。
9、 根据权利要求 7所述的方法， 还包括： 响应用户通过策略配置接 口发起的配置操作，获取用户配置的至少一种资源弹性策 略， 所述至少一种资源弹性策略至少包括用户的自定义策略。
10、 一种内存调度方法， 包括： 扫描承载于容 器中的应用程序从所属工作节点申请的内存空间， 以得到所述应用程 序的实际内存使用信息； 根据所述应用程序 的实际内存使用信息， 释放所述应用程序的部分内存申请量， 以 得到所述应用程序的实际内存占用量。
11、 根据权利要求 10所述的方法， 其中， 扫描所述应用程序从所属工作节点申请 的内存空间， 以得到所述应用程序的实际内存使用信息， 包括： 基于预先配置 的触发垃圾回收 GC操作的时间间隔， 周期性对所述应用程序从所述 容器组所在工作节点申请到的内存空间进行 GC操作， 以得到所述应用程序的实际内存 使用信息； 其 中， 触发 GC操作的时间间隔是在所述应用程序启动时通过其运行环境提供的参 数配置接口为所述应用程序配置的。
12、 根据权利要求 10-11任一项所述的方法， 还包括： 在所述应用程序启动时 ，通过所述参数配置接口重新配置所述应用程序的初始内存 大小， 以使所述应用程序在启动后按照重新配置的初始内存大小向所述工作节点申请内 存空间； 其 中， 重新配置的初始内存大小小于默认的初始内存大小。
13、 一种内存调度系统， 包括： 至少一个工作节点和调度控制器； 所述工作节点上 部署有至少一个容器组， 所述容器组包括至少一个容器， 所述容器中运行有应用程序； 所述调度控制 器， 用于监测所述应用程序的实际内存使用信息； 根据所述应用程序 的实际内存使用信息， 释放所述应用程序从所述工作节点申请的部分内存申请量， 以得 到所述应用程序的实际内存占用量； 以及， 根据同一容器组内各应用程序的实际内存占 用量， 确定所述容器组的实际内存需求量； 才艮据所述容器组的实际内存需求量， 调整配 置给所述容器组的内存请求量。
14、 根据权利要求 13所述的系统， 其中， 所述容器中还运行有应用程序的运行环 境， 所述调度控制器包括： 部署在所述运行环境中的内存管理模块， 以及部署在所述容 器组外部的内存调度节点； 所述 内存管理模块， 用于监测所述应用程序的实际内存使用信息； 根据所述应用程 序的实际内存使用信息， 释放所述应用程序从所述工作节点申请的部分内存申请量， 以 得到所述应用程序的实际内存占用量； 所述 内存调度节点， 用于根据同一容器组内各应用程序的实际内存占用量， 确定所 述容器组的实际内存需求量； 才艮据所述容器组的实际内存需求量， 调整配置给所述容器 组的内存请求量。
15、 根据权利要求 14所述的系统， 还包括： 指标服务 器， 用于采集所述工作节点上各个应用程序的实际内存占用量， 并对同一 容器组内各应用程序的实际内存占用量进行聚合后提供给所述内存调度节点， 以供所述 内存调度节点根据同一容器组对应的聚合结果确定所述容器组的实际内存需求量。
16、 根据权利要求 14或 15所述的系统， 还包括： 策略配置节点 ， 用于面向用户提供策略配置接口， 接收用户通过所述策略配置接口 配置的至少一种资源弹性策略； 所述 内存调度节点具体用于： 从所述策略配置节点获取所述至少一种资源弹性策略, 并在所述容器组的实际内存需求量满足所述至少一种资源弹性策略的情况下，调整配置 给所述容器组的内存请求量。
17、 一种电子设备， 包括： 存储器和处理器； 其中， 所述存储器， 用于存储计算机 程序， 所述处理器与所述存储器耦合， 用于执行所述存储器中的计算机程序， 以用于实 现权利要求 1-12任一项所述方法中的步骤。
18、 一种存储有计算机程序 /指令的计算机可读存储介质， 其中， 当所述计算机程序 被处理器执行时,致使所述处理器能够实现权利要求 1-12中任一项所述方法中的步骤。
19、 一种计算机程序产品， 包括： 计算机程序 /指令， 其中， 当所述计算机程序 /指 令被处理器执行时， 致使所述处理器能够实现权利要求 1-12 中任一项所述方法中的步 骤。
PCT/IB2025/052263 2024-03-18 2025-03-03 内存调度 Pending WO2025196552A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202410309118.6 2024-03-18
CN202410309118.6A CN120704846A (zh) 2024-03-18 2024-03-18 内存调度方法、设备、系统、存储介质及程序产品

Publications (1)

Publication Number Publication Date
WO2025196552A1 true WO2025196552A1 (zh) 2025-09-25

Family

ID=97119387

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2025/052263 Pending WO2025196552A1 (zh) 2024-03-18 2025-03-03 内存调度

Country Status (2)

Country Link
CN (1) CN120704846A (zh)
WO (1) WO2025196552A1 (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111240825A (zh) * 2018-11-29 2020-06-05 深圳先进技术研究院 Docker集群的内存配置方法、存储介质、计算机设备
CN113656182A (zh) * 2021-08-23 2021-11-16 北京沃东天骏信息技术有限公司 一种内存伸缩管理方法、装置、电子设备以及存储介质
CN114968718A (zh) * 2022-05-26 2022-08-30 于军 一种内存管理的方法及内存管理系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111240825A (zh) * 2018-11-29 2020-06-05 深圳先进技术研究院 Docker集群的内存配置方法、存储介质、计算机设备
CN113656182A (zh) * 2021-08-23 2021-11-16 北京沃东天骏信息技术有限公司 一种内存伸缩管理方法、装置、电子设备以及存储介质
CN114968718A (zh) * 2022-05-26 2022-08-30 于军 一种内存管理的方法及内存管理系统

Also Published As

Publication number Publication date
CN120704846A (zh) 2025-09-26

Similar Documents

Publication Publication Date Title
US20210194988A1 (en) Systems and methods for dynamic multi-access edge allocation using artificial intelligence
US9100854B2 (en) Quality of service application controller and user equipment application profiler
Avgeris et al. Adaptive resource allocation for computation offloading: A control-theoretic approach
WO2021233261A1 (zh) 一种多任务动态资源调度方法
WO2020207264A1 (zh) 网络系统、服务提供与资源调度方法、设备及存储介质
CN107506240B (zh) 后台应用程序管控方法、装置、存储介质及电子设备
WO2020207265A1 (zh) 网络系统、管控方法、设备及存储介质
US20120102503A1 (en) Green computing via event stream management
CN106997351B (zh) 一种资源缓存管理方法及系统和装置
WO2017041556A1 (zh) 虚拟资源调度方法、装置及系统
WO2014206266A1 (zh) 一种云计算环境下的自动伸缩方法和系统
JP7161560B2 (ja) 人工知能開発プラットフォームの管理方法及び装置、媒体
WO2023221846A1 (zh) 计算集群及其数据采集方法、设备及存储介质
CN108632309B (zh) 一种升级窄带物联网终端的方法及装置
WO2024164894A1 (zh) 流量控制与数据复制方法、节点、系统及存储介质
KR20230139130A (ko) 멀티 클라우드 컴퓨팅 인프라 관리 장치 및 방법
CN107566493A (zh) 一种面向复杂用户需求的代理节点创建方法、代理服务方法和系统
KR101890046B1 (ko) 전력 소비 감소를 위한 동시적 네트워크 애플리케이션 스케줄링
Tsenos et al. Energy efficient scheduling for serverless systems
CN109002381A (zh) 进程通信监控方法、电子装置及计算机可读存储介质
CN118916162A (zh) 算力调度方法、装置、设备及存储介质
CN114691299B (zh) 一种基于Serverless的边缘计算资源管理系统
CN118890657A (zh) 一种移动基站算力管理方法及相关装置
CN118689662A (zh) 基于分布式的资源调整方法、设备以及存储介质
Carpen-Amarie et al. Towards energy-aware IaaS-PaaS co-design

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25773301

Country of ref document: EP

Kind code of ref document: A1