A memory expansion management method, device, electronic device and storage medium

Abstract

The embodiment of the present application discloses a memory expansion management method, device, electronic device and storage medium, the method comprising: monitoring the service request flow of the current application; when the service request flow is less than the preset flow lower limit, using Balloon to reduce the Java heap memory specification of the current application and release the memory; when the service request flow is greater than the preset flow upper limit, removing Balloon and restoring the Java heap memory specification of the current application. In this way, according to the monitored service request flow of the application, by dynamically adjusting the Java heap memory specification, it is possible to achieve "peak-shifting" shared memory of multiple applications, avoid wasting memory resources, and reduce the overall occupation of physical memory by the application, thereby increasing the deployment density of the application on the electronic device.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a memory expansion management method, device, electronic device and storage medium. Background Art

[0002] Java is a widely used computer programming language that has the characteristics of cross-platform, object-oriented, and generic programming. It is widely used in enterprise-level Web application development and mobile application development. When starting a Java application, you need to set the Java Virtual Machine (JVM) parameters to ensure that the program can run in the planned direction.

[0003] The "+Xmx" in the JVM parameter indicates the maximum value of the Java heap memory. Once "+Xmx" is set, it cannot be modified after the Java application is started. In this case, the Java application must be restarted to modify the parameter. However, the amount of requests processed by online services is not constant. For example, the number of requests received is high only at certain times, while the number of requests received is low most of the time. In order to ensure the availability of the Java application, the resources required by the application are usually set to the peak traffic standard. However, not so many resources are needed during non-peak traffic periods, which can easily lead to a large waste of resources. Summary of the invention

[0004] The present application provides a memory expansion management method, device, electronic device and storage medium, which can dynamically adjust the Java heap memory specifications to avoid wasting memory resources.

[0005] The technical solution of this application is implemented as follows:

[0006] In a first aspect, an embodiment of the present application provides a memory expansion management method, the method comprising:

[0007] Monitor the service request traffic of the current application;

[0008] When the service request flow is less than the preset flow lower limit, Balloon is used to reduce the Java heap memory specification of the current application and release the memory;

[0009] When the service request flow is greater than a preset flow upper limit, the Balloon is removed and the Java heap memory specification of the current application is restored.

[0010] In a second aspect, an embodiment of the present application provides a memory expansion management device, which is applied to an electronic device. The memory expansion management device includes a monitoring unit and a memory management unit, wherein:

[0011] The monitoring unit is configured to monitor the service request flow of the current application;

[0012] The memory management unit is configured to use Balloon to reduce the Java heap memory specification of the current application and release memory when the service request traffic is less than the preset traffic lower limit; and to remove the Balloon and restore the Java heap memory specification of the current application when the service request traffic is greater than the preset traffic upper limit.

[0013] In a third aspect, an embodiment of the present application provides an electronic device, the electronic device comprising a memory and a processor, wherein:

[0014] The memory is used to store a computer program that can be run on the processor;

[0015] The processor is used to execute the memory expansion and contraction management method as described in the first aspect when running the computer program.

[0016] In a fourth aspect, an embodiment of the present application provides a computer storage medium, which stores a computer program. When the computer program is executed by at least one processor, the memory expansion and contraction management method as described in the first aspect is implemented.

[0017] The memory expansion and contraction management method, device, electronic device and storage medium provided in the embodiment of the present application monitor the service request flow of the current application; when the service request flow is less than the preset flow lower limit, the balloon is used to reduce the Java heap memory specification of the current application and release the memory; when the service request flow is greater than the preset flow upper limit, the balloon is removed to restore the Java heap memory specification of the current application. In this way, by monitoring the service request flow of the application, when it is detected that the service request flow is small, the Java heap memory specification is reduced and the memory is released through the balloon, and the released memory can be provided to other applications with larger service request flow; and when it is detected that the service request flow is large, the balloon can also be removed to restore the Java heap memory specification; thus, by dynamically adjusting the Java heap memory specification, multiple applications can be shared in a "peak-shifting" manner, reducing the overall occupation of physical memory by the application, thereby increasing the deployment density of the application on the electronic device and avoiding waste of memory resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 A flowchart of a memory expansion management method provided in an embodiment of the present application;

[0019] Figure 2 A flowchart of another memory expansion management method provided in an embodiment of the present application;

[0020] Figure 3 A schematic diagram of the architecture of a container system provided in an embodiment of the present application;

[0021] Figure 4 A schematic diagram of the working principle of a Balloon technology provided in an embodiment of the present application;

[0022] Figure 5 A schematic diagram of an implementation process based on Balloon technology provided in an embodiment of the present application;

[0023] Figure 6 A flowchart of another memory expansion management method provided in an embodiment of the present application;

[0024] Figure 7 A schematic diagram of the composition structure of a memory expansion management device provided in an embodiment of the present application;

[0025] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application

[0026] Fig. 9 A schematic diagram of the specific hardware structure of an electronic device provided in an embodiment of the present application;. DETAILED DESCRIPTION

[0027] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. It is understood that the specific embodiments described herein are only used to explain the related applications, rather than to limit the applications. It should also be noted that, for ease of description, only the parts related to the related applications are shown in the drawings.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0029] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0030] It should be pointed out that the terms "first\second\third" involved in the embodiments of the present application are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0031] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations:

[0032] Derived from Control Groups (CGroup): CGroup is a mechanism provided by the Linux kernel that can limit the resources used by a single process or multiple processes. It can achieve fine-grained control over resources such as the Central Processing Unit (CPU) and memory. For example, the lightweight container Docker uses the resource limitation capability provided by CGroup to complete resource control of CPU, memory, and other parts.

[0033] Out Of Memory (OOM): refers to the situation where there is unreclaimable memory or too much memory is used in the application system, which eventually causes the memory required for the program to run to be greater than the maximum memory that can be provided. At this point, the program can no longer run.

[0034] It is understandable that Java is a widely used computer programming language with cross-platform, object-oriented, and generic programming features. It is widely used in enterprise-level World Wide Web (Web) application development and mobile application development. Java is different from general compiled languages ​​or interpreted languages. It first compiles the source code into bytecode, and then relies on virtual machines on various platforms to interpret and execute the bytecode, thus having the cross-platform feature of "write once, run everywhere". Due to its unique charm, Java has always been one of the favorite languages ​​of developers. Even most of the code of Android, one of the two major mobile operating systems, is written in Java.

[0035] Specifically, when a Java application is started, the Java Virtual Machine (JVM) parameters need to be set to ensure that the program can run in the planned direction. The "+Xmx" in the JVM parameters indicates the maximum value of the Java heap memory. Once this parameter is set, it cannot be modified after the Java application is started. To modify this parameter, the Java application must be restarted. Generally speaking, the amount of requests processed by online services is not constant, and most of them have a tidal effect, that is, the number of requests received is large only at certain times, while the number of requests received is low most of the time. Due to the limitation of JVM parameters, in order to ensure the availability of Java applications when the number of requests received is large, especially when the number of requests reaches the peak flow, application developers generally set the resources required by the application to the peak flow standard. Since the time when the application is at peak flow is very short compared to the service time of the application, the application does not need so many resources in general, which results in a large waste of resources. In addition, when a Java application is cold started, the performance of a Java application that has not been warmed up cannot reach the optimal level. If it directly faces the peak flow at this time, it will also cause online service jitter.

[0036] Based on this, the embodiment of the present application provides a memory expansion and contraction management method, the basic idea of ​​which is: monitor the service request flow of the current application; when the service request flow is less than the preset flow lower limit, use Balloon to reduce the Java heap memory specification of the current application and release the memory; when the service request flow is greater than the preset flow upper limit, remove Balloon and restore the Java heap memory specification of the current application. In this way, by monitoring the service request flow of the application, when it is detected that the service request flow is small, the Java heap memory specification is reduced and the memory is released through Balloon, and the released memory can be provided to other applications with larger service request flow; and when it is detected that the service request flow is large, Balloon can also be removed to restore the Java heap memory specification; thus, by dynamically adjusting the Java heap memory specification, multiple applications can be realized to share memory in a "peak-shifting" manner, reduce the overall occupation of physical memory by the application, and thus increase the deployment density of the application on the electronic device and avoid waste of memory resources.

[0037] The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0038] In one embodiment of the present application, see Figure 1 , which shows a flow chart of a memory expansion management method provided by an embodiment of the present application. Figure 1 As shown, the method may include:

[0039] S101. Monitor the service request flow of the current application.

[0040] It should be noted that the memory expansion management method provided in the embodiment of the present application can be applied to a memory expansion management device, or an electronic device integrated with the device. Here, the electronic device may include a server, a host, and the like.

[0041] It should also be noted that in the embodiments of the present application, the application generally refers to a Java application. On the one hand, once the "+Xmx" in the JVM parameter is set, it cannot be modified after the Java application is started; on the other hand, the application developer must set this parameter to be less than the CGroup limit of the container, otherwise it will trigger the OOM of the container and cause the application to be killed by the system. If the application developer sets a large Java heap memory in advance for possible traffic peaks, it will inevitably cause a lot of resource waste because the time when the application is at peak traffic is very short relative to the service time of the application. Therefore, how to dynamically and elastically scale the Java heap without restarting the Java application has become an urgent problem to be solved. The embodiments of the present application mainly propose solutions to the problem that in the prior art, Java applications cannot dynamically modify the Java heap size, resulting in a lot of resource waste.

[0042] It should also be noted that in the embodiments of the present application, the service request traffic of the application is also referred to as application traffic. It can be understood that when the service request traffic is large, the application needs to process many service requests, and at this time the Java heap needs to have a larger memory; when the service request traffic is small or there is no traffic, the application needs to process fewer service requests, and at this time a smaller Java heap memory can meet the demand.

[0043] In addition, the embodiments of the present application can monitor the service request flow of the application by deploying an agent module on the electronic device. Therefore, in some embodiments, an agent module can be deployed in the electronic device; the monitoring of the service request flow of the current application can include: monitoring the service request flow of the current application through the agent module.

[0044] S102: When the service request flow is less than the preset flow lower limit, Balloon is used to reduce the Java heap memory specification of the current application and release the memory.

[0045] It should be noted that when the service request traffic of the current application is less than the preset traffic lower limit, it means that for the current application, only a small number of service requests need to be processed or no service requests need to be processed. At this time, the actual working memory of the application, that is, the Java heap memory used by the application, is much smaller than the preset Java heap memory that enables the application to cope with the traffic peak. For example: for a certain application, when the service request traffic is the traffic peak, the Java heap memory specification needs to be set to 8G to cope with the traffic peak, but when the service request traffic is not at the traffic peak, for example, when the service request traffic is less than the preset traffic lower limit, only 1G of Java heap memory is required to meet the operation of the application, and the other 7G memory is not used by the application. At this time, Balloon can be used to reduce the Java heap memory specification of the application to 1G, and the excess 7G memory is released. The released 7G memory is returned to the operating system and can be used by other applications at the traffic peak.

[0046] It should also be noted that in the embodiments of the present application, multiple containers can be deployed on an electronic device, and at least one application can be run on each container. In addition, the container may include a container or a virtual machine that runs an application, that is, both the container and the virtual machine can be used as an environment for running the application, which will not affect the implementation of the embodiments of the present application and the realization of the technical effects.

[0047] In the embodiment of the present application, taking running an application on a container as an example, the Java heap of the application refers to the memory allocated to the Java application on the container in which it runs, so releasing the memory of the Java heap is equivalent to releasing the memory of the container.

[0048] It should also be noted that the embodiment of the present application uses the Balloon technology to achieve the change of the Java heap memory specifications. Balloon means a balloon, which has volume but no mass. In the embodiment of the present application, it means that although a space is occupied in the Java heap of the JVM, it does not actually occupy a physical memory page. This part of the memory can be returned to the operating system for the convenience of other applications. In this way, multiple applications share physical memory, so that more applications can be run under the same memory conditions through the method provided in the embodiment of the present application.

[0049] Specifically, in some embodiments, when the service request traffic is less than the preset traffic lower limit, reducing the Java heap memory specification in the current application and releasing the memory by using Balloon may include:

[0050] Balloon is used to occupy a position in the Java heap of the current application, the free memory occupied by Balloon is released, and the Java heap memory specification of the current application is adjusted first;

[0051] The first adjustment is used to indicate reducing the Java heap memory specification of the current application.

[0052] It should be noted that when it is monitored that the service request traffic of the current application is less than the preset traffic lower limit, a Balloon is placed in the Java heap of the current application to occupy the position, and the free memory in the position occupied by the Balloon is released and returned to the operating system, and the Java memory specification of the current application is reduced through the first adjustment.

[0053] S103: When the service request flow is greater than the preset flow upper limit, Balloon is removed and the Java heap memory specification of the current application is restored.

[0054] It should be noted that if the service request flow of the current application is monitored to be greater than the preset flow upper limit, for example, the flow peak is reached, and the Java heap memory that can only meet the application running under normal circumstances cannot cope with the peak flow, then the Java heap memory specification needs to be restored to ensure sufficient memory to handle a large number of service requests. At this time, the Balloon occupying the Java heap is removed and the Java heap memory specification is restored. In the embodiment of the present application, the preset flow lower limit may be less than or equal to the preset flow upper limit.

[0055] In some embodiments, the method may further include: reserving Guarantee memory through the Agent module; wherein the Guarantee memory is used to ensure that the electronic device does not experience a memory overflow when the Balloon is removed from the Java heap of the current application or a Full GC signal is detected.

[0056] It should be noted that the free memory of the Java heap can be released through the Balloon technology, but there is a prerequisite for elastically scaling the Java heap memory using the Balloon technology (which may also be referred to as the Java Balloon technology in the embodiment of the present application), which is that the Balloon object must be immovable. The movement of the Balloon object will cause the physical memory pages released through the Balloon to be reloaded back into the physical memory. If the physical memory is insufficient at this time, OOM will occur. In order to avoid this situation, the embodiment of the present application can also reserve a portion of the physical memory (i.e., Guarantee memory) in the host in advance through the Agent module, and use the Guarantee memory when OOM may occur. The Guarantee memory can provide time-sharing sharing for a group of containers running Java applications. This ensures that when the Balloon is removed from the Java heap of the current application or the Full GC signal is detected, there will be no memory overflow, which will cause the application to be killed by the system.

[0057] Further, when the Guarantee memory is used to restore the Java heap memory specification, in some embodiments, when the service request traffic is greater than the preset traffic upper limit, removing the Balloon and restoring the Java heap memory specification of the current application may include:

[0058] After Balloon is removed, the Guarantee memory is allocated to the Java heap of the current application, and a second adjustment is made to the Java heap memory specification of the current application to restore the Java heap memory specification of the current application;

[0059] The second adjustment is used to indicate increasing the Java heap memory specification of the current application.

[0060] It should be noted that when the service request traffic is greater than the preset traffic upper limit, after removing the Ballon, the Guarantee memory can be allocated to the Java heap of the current application, and the Java heap memory specification can be adjusted for the second time to increase the Java heap memory specification so that the Java heap memory specification is restored to a size sufficient to cope with the traffic peak.

[0061] It can be seen that Guarantee memory can ensure that when Balloon fails, that is, when there are multiple applications on the electronic device at peak traffic, and the memory of the electronic device is insufficient to support the restoration of the Java heap memory specifications of multiple applications at peak traffic, the Java heap memory specifications can be restored through Guarantee memory to avoid OOM caused by insufficient memory.

[0062] Furthermore, when Guarantee memory is used to ensure that the application does not have a memory overflow phenomenon when performing Full GC, the method may also include:

[0063] After the Full GC signal is detected by the Agent module, it is determined whether the Guarantee memory meets the preset conditions;

[0064] If the Guarantee memory meets the preset conditions, the Guarantee memory is used to restore the Java heap memory specification of the current application, and the current application is notified to perform garbage collection operations;

[0065] If the Guarantee memory does not meet the preset condition, continue to execute the step of determining whether the Guarantee memory meets the preset condition.

[0066] It should be noted that in the embodiment of the present application, the Guarantee memory can prevent the application from having a memory overflow when performing garbage collection (Full Garbage Collection, Full GC), thereby causing the application to be killed by the operating system. However, if a piece of Guarantee memory is reserved for each application in the electronic device, the memory utilization rate of the electronic device will not be reduced. Therefore, the embodiment of the present application can also prevent the application from having a memory overflow by sharing the Guarantee memory by multiple applications, and also ensure the memory utilization rate of the electronic device.

[0067] Specifically, in order to prevent multiple applications from executing Full GC at the same time and causing memory overflow, when an application is about to perform Full GC, the Agent module will first determine whether the Guarantee memory meets the preset conditions. If the Guarantee memory meets the preset conditions, the Guarantee memory will be used to restore the Java heap memory specifications of the current application and notify the current application to perform garbage collection operations; if the Guarantee memory does not meet the preset conditions, the judgment will continue.

[0068] Regarding determining whether the Guarantee memory satisfies a preset condition, in some specific embodiments, determining whether the Guarantee memory satisfies a preset condition may include:

[0069] If the Guarantee memory is greater than or equal to the memory required to restore the Java heap memory specification of the current application, it is determined that the Guarantee memory meets the preset conditions;

[0070] If the Guarantee memory is less than the memory required to restore the Java heap memory specification of the current application, it is determined that the Guarantee memory does not meet the preset condition.

[0071] It should be noted that when judging whether the Guarantee memory meets the preset conditions, it can be judged whether the Guarantee memory is currently sufficient, that is, whether the current remaining memory of the Guarantee memory is sufficient to restore the Java heap memory specifications of the current application. If the Guarantee memory is sufficient, the Java heap memory specifications of the current application will be restored; if the Guarantee memory is insufficient, it means that the Guarantee memory may be used by other applications at this time, which is insufficient to restore the Java heap memory specifications of the current application. It is necessary to continue to judge until other applications have finished using and released the Guarantee memory. At this time, the Guarantee memory can be used to restore the Java heap memory specifications of the current application. In addition, since the time an application uses the Guarantee memory is usually within one millisecond, the use of the Guarantee memory will not affect the normal operation of the application.

[0072] After the current application completes garbage collection, the larger Java heap memory is no longer needed and the memory can be released. Therefore, in some embodiments, the method may further include:

[0073] After the Java heap memory specification of the current application is restored and the current application successfully performs garbage collection, the Agent module is used to perform a Balloon refresh operation to reduce the Java heap memory specification of the current application and release memory to restore the Guarantee memory.

[0074] It should be noted that after the current application performs garbage collection, the memory needs to be returned to the Guarantee memory. Specifically, the Agent module can be used to perform a refresh of the Balloon, use the Balloon again to occupy a position in the Java heap, reduce the Java heap memory specification, and return the memory allocated to the Java heap from the Guarantee memory to the Guarantee memory, that is, restore the Guarantee memory.

[0075] In some embodiments, a plurality of containers are deployed in the electronic device, and the number of applications running on each container is at least one;

[0076] Accordingly, when the service request flow is greater than the preset flow upper limit, removing Balloon and restoring the Java heap memory specification of the current application may include:

[0077] Get the physical memory released by Balloon from applications running on several containers;

[0078] After Balloon is removed, the physical memory is allocated to the Java heap of the current application, and the Java heap memory specification of the current application is adjusted for the second time to restore the Java heap memory specification of the current application;

[0079] The second adjustment is used to indicate increasing the Java heap memory specification of the current application.

[0080] It should be noted that in the embodiment of the present application, several containers can be deployed on the electronic device, and at least one application can be run on each container. In this way, for the current application, when its service request traffic is greater than the preset traffic upper limit, after the Balloon is removed, the Java heap memory specification of the current application can be adjusted for the second time through the memory released by the Java heap of other applications running on the electronic device to restore the Java heap memory specification of the current application.

[0081] For example, four containers are deployed on an electronic device, and the electronic device can provide 100G memory. Four applications A, B, C and D are respectively run on the four containers deployed on the electronic device. The preset specifications are used to indicate the memory size of the Java heap that is sufficient to cope with the peak traffic. Among them, the preset specification of A's Java heap is 40G, and the memory required for daily operation is 10G; the preset specification of B's ​​Java heap is 40G, and the memory required for daily operation is 20G; the preset specification of C's Java heap is 40G, and the memory required for daily operation is 20G; the preset specification of D's Java heap is 40G, and the memory required for daily operation is 10G. In this way, when none of the four applications are at the peak of traffic, their actual Java heap memory specifications are 10G, 20G, 20G and 10G respectively, that is, a total of 60G is required to meet the daily operation of the four applications. In the four Java heaps, the positions without allocated memory are occupied by Balloons of different specifications, and there is 40G of memory released by the Java heap in the electronic device. If at a certain moment, it is monitored that the service request traffic of C and D is greater than the preset traffic upper limit, for example, reaching the traffic peak, then you only need to remove the balloons of C and D, and allocate the idle 40G memory on the host to the Java heaps of C and D respectively, restoring them to the preset specifications, which is sufficient to handle the service requests under the traffic peak; and after the traffic peak ends, release the idle memory not used by C and D again so that other applications can use this part of the memory during the traffic peak.

[0082] It can be seen that in the above example, for an electronic device that can provide 100G of memory, if the memory scaling management method provided in the embodiment of the present application is not adopted, for the four applications A, B, C and D, since the preset specifications of their Java heaps are all 40G, then at most only two Java applications can be run; after adopting the memory scaling management method provided in the embodiment of the present application, at least four applications A, B, C and D can be run simultaneously, thereby improving the density of application deployment on the electronic device.

[0083] In this way, when the service request traffic of the application is small, Balloon is used to occupy space in the Java heap and perform memory management; when the service request traffic is large, Balloon is removed and the Java heap memory specifications of the application are restored; thereby achieving memory sharing among multiple applications on electronic devices, and dynamically scaling the Java heap memory specifications according to the service request traffic to meet the Java heap memory requirements of applications in devices with different service request traffic, greatly saving resources.

[0084] This embodiment provides a memory expansion management method, by monitoring the service request flow of the current application; when the service request flow is less than the preset flow lower limit, the Balloon is used to reduce the Java heap memory specification of the current application and release the memory; when the service request flow is greater than the preset flow upper limit, the Balloon is removed to restore the Java heap memory specification of the current application. In this way, by monitoring the service request flow of the application, when it is detected that the service request flow is small, the Java heap memory specification is reduced and the memory is released through the Balloon, and the released memory can be provided to other applications with larger service request flows; and when the service request flow is large, the Balloon can also be removed to restore the Java heap memory specification; thus, by dynamically adjusting the Java heap memory specification, multiple applications can be "peak-shifted" to share memory, reduce the overall occupation of physical memory by the application, further improve the deployment density of the application on the electronic device, and avoid waste of memory resources. In addition, since a portion of the Guarantee memory is reserved on the electronic device, the Java heap memory specification can also be restored when the Balloon fails or the application needs to perform garbage collection, avoiding OOM and causing the application to be killed by the system. Moreover, since the Java heap memory specifications are dynamically scaled during application operation, there is no need to restart the application when a traffic peak arrives, and a hot start of the application is achieved, allowing the application to directly reach the optimal state to cope with traffic peaks without jitter.

[0085] In another embodiment of the present application, see Figure 2 , which shows a flow chart of another memory expansion management method provided by an embodiment of the present application. Figure 2 As shown, the method may include:

[0086] S201, deploying an Agent module on a host.

[0087] It should be noted that see Figure 3 , which shows a schematic diagram of the architecture of a container system provided in an embodiment of the present application. The memory expansion management method provided in an embodiment of the present application can be based on Figure 3 The container system shown in the figure is implemented, and the container system runs on an electronic device, such as a server or a host. Figure 3 As shown, several containers ( Figure 3 3 containers are shown in the figure, but the actual number is not specifically limited), and several applications are running on each container (the figure shows that each container runs one application, but the actual number is not specifically limited), and each application (also referred to as a Java application, a Java process, or a Java Process in the embodiment of the present application) is allocated a certain amount of Java heap memory; Figure 3 In , working memory refers to the memory actually used by the application at runtime.

[0088] In addition, since the application runs on the container in the embodiment of the present application, the expansion and contraction of the Java heap memory is also the expansion and contraction of the container memory. Therefore, in the subsequent description, sometimes the release of Java heap memory is also written as the release of container memory, or the expansion and contraction of Java heap specifications is written as the expansion and contraction of container specifications, etc.

[0089] In the embodiment of the present application, an agent (i.e., the Agent module in the aforementioned embodiment) can be deployed on the electronic device, and the specifications of the group of containers on the electronic device and the Java heap configuration of the application in the container can be managed through the Agent module to ensure that OOM does not occur after the group of containers is vertically reduced (i.e., the specifications of the container are reduced). In the embodiment of the present application, when there are multiple electronic devices, the Agent module can be deployed on each electronic device to manage each electronic device separately.

[0090] In the embodiment of the present application, the Agent module mainly performs the following two functions: one is to monitor the service request flow of the application and elastically scale the Java heap memory specifications of the application in the managed container; the other is to allocate and manage the use of Guarantee memory to ensure that only one container can obtain Guarantee memory at the same time (when the Guarantee memory is large, there is also the possibility that multiple containers use Guarantee memory at the same time).

[0091] S202. The Agent module reserves a Guarantee memory in the electronic device.

[0092] It should be noted that in the embodiment of the present application, a certain size of Guarantee memory is reserved in the electronic device through the Agent module. Guarantee memory refers to a part of physical memory reserved in the host, which can be used by low-power applications when performing garbage collection. The size of the Guarantee memory can be set in combination with the actual usage scenario, and the embodiment of the present application does not specifically limit this. By using Guarantee memory, it can be ensured that the container does not have OOM when the Balloon mechanism fails.

[0093] It should also be noted that, since the Balloon technology can release the memory of the Java heap, there is a prerequisite for elastically scaling the Java heap memory specifications using the Balloon technology, which is to ensure that the Balloon object cannot be moved. The movement of the Balloon object will cause the physical memory page released by the Balloon to be reloaded back into the physical memory. If the physical memory is insufficient at this time, OOM will occur. In order to avoid this situation, the embodiment of the present application reserves a portion of the physical memory, namely the Guarantee memory, in advance, and uses the memory when the container may experience OOM. The Guarantee memory can be shared by a group of containers running Java applications in a time-sharing manner.

[0094] S203. Reduce the Java heap memory through Balloon and return the released memory to the operating system.

[0095] It should be noted that the Agent module can be used to release Balloon in the Java heap of the application in the container for placeholder, and part of the Java heap memory occupied by the application in the stock application can be released and returned to the operating system, so as to reduce the memory usage of the application. For example, the application developer initially sets an 8G Java heap, but the application only needs 1G of memory for normal operation, then the Agent module can be used to release the excess memory and modify the Java heap memory specification to 1G. Since in the embodiment of the present application, the application runs on the container, and a container only runs one application, it is equivalent to modifying the container specification to 1G.

[0096] See also Figure 4 , which shows a schematic diagram of the working principle of a Balloon technology provided by an embodiment of the present application. Balloon means a balloon, which has volume but no mass. Here, it means that although it occupies a space in the Java heap of the JVM, it does not actually occupy physical memory pages. This part of memory can be returned to the operating system for the convenience of other Java applications. That is, the Balloon technology can release the memory in the Java heap and return it to the operating system. Figure 4As shown in the figure, the Java heap logical space refers to the memory allocation at the container level. When implementing the Balloon technology, Balloon is used to occupy the pre-allocated Java object, and the memory page of the object is marked as MADV-DONTNEED. From the perspective of the container / virtual machine, this part of the memory has been allocated and occupied, and no other objects will be allocated on this memory; from the perspective of the operating system, this part of the physical memory page has been released, and other pages can be loaded, thereby realizing the release of memory. In addition, the working memory may not be continuous in the physical memory. Figure 4 The use of continuous addresses is only for convenience and does not affect the actual results.

[0097] See also Figure 5 , which shows a schematic diagram of an implementation process based on Balloon technology provided in an embodiment of the present application. Figure 5 As shown in the figure, when the application is in a no-traffic state (i.e., no service request) and the Java heap size needs to be reduced, the Agent module can use the Attach method (i.e., directly put the code into the running application and perform the operation) to put a certain specification of Balloon into the Java heap to occupy the place. At this time, the application detects the existence of the Balloon and will no longer use the Java heap memory, and then return the memory occupied by the Balloon to the operating system. When the service request traffic comes and the Java heap size needs to be increased, the Balloon in the Java heap is removed through the Attach technology. When the Java application detects that the Balloon no longer exists, it will reuse the entire Java heap, thereby realizing the elastic scaling of the Java heap.

[0098] S204, the Agent module monitors service request traffic and garbage collection signals.

[0099] It should be noted that, on the one hand, when the Agent module monitors the arrival of a large amount of service request traffic, that is, the service request traffic is greater than the preset traffic upper limit, for example, when the traffic peak is reached, the Balloon in the Java heap is removed and the Java heap memory specification is restored; on the other hand, when the Agent module monitors the Full GC signal sent by the application, it tries to obtain the resource lock. If the resource lock is obtained, the application is allowed to perform garbage collection. Otherwise, it continues to wait until the resource lock is obtained before allowing the application to perform garbage collection.

[0100] It should also be noted that the resource lock is a restriction on the Guarantee memory, which is used to ensure that only one container can obtain the Guarantee memory at the same time. In other words, if multiple applications send Full GC signals, the Guarantee can obtain the resource lock according to the order in which the applications send the signals. The application that sends the signal first will then restore the Java heap memory specification of the application and allow it to perform garbage collection. After the application completes garbage collection, the Guarantee memory used by it will be released through Balloon for use by the next application when performing garbage collection.

[0101] It should also be noted that in the embodiment of the present application, the function of the Guarantee memory is to prevent the application from being killed by the operating system due to OOM when the application performs Full GC. However, if a piece of Guarantee memory is reserved for each application in the electronic device, the memory usage rate of the electronic device will not be reduced. Therefore, the embodiment of the present application also proposes a mechanism for multiple applications to share the Guarantee memory. The specific implementation method is as follows: Figure 6 , which shows a flow chart of another memory expansion management method provided by an embodiment of the present application, and the method is described with the Agent module as the main body. Figure 6 As shown, the method may include:

[0102] S601: Receive a GC event message sent by an application.

[0103] It should be noted that when a Java application needs to execute Full GC, a request message, such as a GC Event message, is sent to the Java scaling agent.

[0104] S602: Determine whether the Guarantee memory is sufficient.

[0105] It should be noted that after receiving the GC event message sent by the Java application, the Agent module determines whether the current Guarantee memory is sufficient, because there is a possibility that the Guarantee memory is used by other applications and is insufficient to support the recovery of the container specifications of the current application.

[0106] If the judgment result is yes, execute step S603; otherwise, execute and continue with step S602.

[0107] It should also be noted that if the Guarantee memory is insufficient, this step will continue to be executed. When other applications return the Guarantee memory and it is determined that the Guarantee memory is sufficient, step S603 will be executed.

[0108] S603. Release the Guarantee memory.

[0109] S604: Restore the container specification of the application.

[0110] It should be noted that when it is determined that the Guarantee memory is sufficient, the Agent module releases the Guarantee memory to restore the application's container specifications, that is, to restore the application's Java heap memory specifications.

[0111] S605: Notify the application to perform a garbage collection operation.

[0112] S606. Refresh Balloon.

[0113] S607. Reduce the container specifications of the application.

[0114] S608. Restore the Guarantee memory.

[0115] It should be noted that after the application's container specifications are restored, the Agent module notifies the application to perform garbage collection operations, and after the application performs garbage collection operations, refreshes Balloon and reduces the application's container specifications, that is, returns the guaranteed memory used by the Java heap to restore the Guarantee memory.

[0116] That is to say, in order to prevent multiple applications from executing Full GC at the same time and causing OOM, the Agent module can add a GC callback mechanism in the application through the Java Virtual Machine Tool Interface (JVMTI). When a Full GC occurs in the application, a GC event message is first sent to the Agent module. After receiving the GC event message, the Agent module determines whether the Guarantee memory is sufficient. If the Guarantee memory is sufficient, the Agent module first restores the container specification of the application, and then notifies the application to start the garbage collection operation. After the application completes the garbage collection, the Agent module is notified to perform the refresh Balloon operation and reduce the container specification of the application.

[0117] In summary, the embodiments of the present application mainly solve the problem that in the prior art, Java applications cannot dynamically modify the Java heap size, resulting in a large amount of resource waste. Since these applications do not need to provide services all the time, but will always occupy CPU and memory resources, and cannot directly release the memory of most containers when the application is in the traffic trough, for applications that take a long time to start, it may be too late to reapply for the deployment of containers in the face of traffic peaks. Therefore, a technology for multi-machine sharing elastic scaling of Java heaps is provided, where "multi-machine" means multi-virtual / multi-container, and dynamic elastic scaling of Java heap memory specifications is achieved through multi-machine shared memory. When the application does not need to provide services, the memory usage of the application is reduced, and the resource specifications of the container are reduced, which can significantly improve resource utilization. In addition, the embodiments of the present application can be implemented from the user state, without upgrading or modifying the operating system kernel, and there are no special requirements for the Java virtual machine version and GC algorithm. No application customization and transformation are required, which is more convenient for upgrading and deployment.

[0118] like Figure 3 As shown, an embodiment of the present application can deploy an Agent module on an electronic device running a group of Java application containers, and manage the specifications of this group of containers and the Java heap configuration of the application in the container through the Agent module to ensure that OOM does not occur in this group of containers after vertical shrinking. By releasing the Balloon in the Java heap of the application in the container through the Agent module, part of the Java heap memory occupied by the Java application in the existing application can be released and returned to the operating system, thereby reducing the memory usage of the application. For example, the application developer initially sets an 8G Java heap, but the application only needs 1G of memory for normal operation, then the Agent module can be used to release the excess memory and modify the container specifications to 1G. Using Guarantee memory can ensure that the container does not OOM when the Balloon mechanism fails. Before the application traffic arrives, the Balloon in the Java heap is removed through the Agent module to restore the application container to normal specifications. This approach not only helps service providers deploy more applications within limited hosts, but also ensures that applications can be quickly restored to normal status during traffic peaks. It also avoids the problem of online service jitter caused by traffic peaks, which occurs when applications are cold started and fail to reach the optimal level due to lack of warm-up.

[0119] In short, the service scaling management method provided in the embodiment of the present application may mainly include the following steps:

[0120] Step 1. Deploy the Agent module on the electronic device; Step 2. The Agent module reserves the Guarantee memory to prevent the application OOM caused by the increase of memory during Full GC; Step 3. Reduce the Java heap memory through Balloon and return the released memory to the system; Step 4. The Agent module monitors the service request traffic and Full GC signal; Step 4.1. Monitor the Full GC signal and try to obtain the resource lock. If the resource lock is obtained, the application is allowed to perform garbage collection, otherwise wait for the resource lock to be obtained before performing garbage collection; Step 4.2. Monitor the arrival of the traffic peak, remove the Balloon, and restore the Java heap memory.

[0121] It can be seen that the embodiment of the present application can realize that different container applications on the same electronic device share Java heap memory by deploying an Agent module on the electronic device. The main technical points include Balloon technology, Guarantee memory and Agent module. Figure 4 It can be seen that when the application is in a state of no traffic and needs to reduce the size of the Java heap, the Agent module can put a certain specification of Balloon into the Java heap to occupy a place through the Attach method. When the application detects the existence of the Balloon, it will no longer use the heap memory, and then return the memory occupied by the Balloon to the operating system. When traffic comes and the Java heap size needs to be increased, the Balloon in the Java heap is removed through the Attach technology. When the application detects that the Balloon no longer exists, it will reuse the entire Java heap. In this way, the elastic scaling of the Java heap is achieved.

[0122] In addition, the function of Guarantee memory is to prevent OOM from occurring when the application is performing Full GC, thereby causing the application to be killed by the operating system. However, if a piece of Guarantee memory is reserved for each application, it will be found that the memory usage rate of the electronic device has not been reduced. Therefore, the embodiment of the present application also proposes a technology for multiple applications to share Guarantee memory, and the specific implementation method is as follows: Figure 6In order to prevent multiple applications from executing Full GC at the same time and causing OOM, the Agent module adds a GC callback mechanism in the application through JVMTI. That is, when a Full GC occurs in the application, it will first send a GC Event message to the Agent module. After receiving the message, the Agent module will determine whether the Guarantee memory is sufficient. If the Guarantee memory is sufficient, the Agent module will first restore the container specifications of the application, and then notify the application to start the garbage collection operation. After the execution is completed, the Agent module will be notified to perform the refresh Balloon operation and reduce the container specifications of the application.

[0123] The embodiment of the present application provides a memory expansion management method. The specific implementation of the above embodiment is described in detail through the above embodiment. It can be seen that, on the one hand, the memory expansion management method proposed in the embodiment of the present application can be applied to the scenario of multiple application combination deployment with obvious traffic peak-shifting attributes, and the overall occupation of physical memory by application time-sharing reuse is reduced, thereby improving the application deployment density. On the other hand, the embodiment of the present application also proposes a mechanism for sharing Guarantee memory to prevent low-power containers from generating OOM when the Balloon mechanism fails. The technical principle is to reserve a Guarantee memory in advance, and to realize the time-sharing reuse of Guarantee memory in low-power containers by monitoring events in low-power containers that may cause the Balloon mechanism to fail, so as to ensure that a group of containers does not have OOM in a low-power state. In short, the embodiment of the present application not only realizes the dynamic expansion of the Java heap, so that multiple applications share physical memory, and improve the application deployment density on electronic devices, but also avoids the generation of OOM when the Balloon mechanism fails through the Guarantee memory mechanism.

[0124] In another embodiment of the present application, see Figure 7 , which shows a schematic diagram of the composition structure of a memory expansion management device 70 provided in an embodiment of the present application. Figure 7 As shown, the memory expansion management device 70 may include a monitoring unit 701 and a memory management unit 702, wherein:

[0125] A monitoring unit 701 is configured to monitor the service request flow of the current application;

[0126] The memory management unit 702 is configured to use Balloon to reduce the Java heap memory specification of the current application and release memory when the service request traffic is less than the preset traffic lower limit; and to remove the Balloon and restore the Java heap memory specification of the current application when the service request traffic is greater than the preset traffic upper limit.

[0127] In some embodiments, the memory management unit 702 is also configured to utilize the Balloon to occupy a position in the Java heap of the current application, release the free memory occupied by the Balloon, and make a first adjustment to the Java heap memory specification of the current application; wherein the first adjustment is used to indicate reducing the Java heap memory specification of the current application.

[0128] In some embodiments, an agent module is deployed in the electronic device 70; the memory management unit 702 is further configured to monitor the service request flow of the current application through the agent module.

[0129] In some embodiments, the memory management unit 702 is further configured to reserve Guarantee memory through the Agent module; wherein the Guarantee memory is used to ensure that the electronic device does not experience memory overflow when the Balloon is removed from the Java heap of the current application or a garbage collection Full GC signal is detected.

[0130] In some embodiments, the memory management unit 702 is further configured to allocate the Guarantee memory to the Java heap of the current application after removing the Balloon, and make a second adjustment to the Java heap memory specification of the current application to restore the Java heap memory specification of the current application; wherein the second adjustment is used to indicate an increase in the Java heap memory specification of the current application.

[0131] In some embodiments, the memory management unit 702 is further configured to determine whether the Guarantee memory meets a preset condition after detecting a Full GC signal through the Agent module; and if the Guarantee memory meets the preset condition, use the Guarantee memory to restore the Java heap memory specification of the current application, and notify the current application to perform a garbage collection operation; and if the Guarantee memory does not meet the preset condition, continue to execute the step of determining whether the Guarantee memory meets the preset condition.

[0132] In some embodiments, the memory management unit 702 is further configured to determine that the Guarantee memory meets the preset condition if the Guarantee memory is greater than or equal to the memory required to restore the Java heap memory specification of the current application; and determine that the Guarantee memory does not meet the preset condition if the Guarantee memory is less than the memory required to restore the Java heap memory specification of the current application.

[0133] In some embodiments, the memory management unit 702 is further configured to, after the current application performs a garbage collection operation, perform a refresh operation on the Balloon through the Agent module, reduce the Java heap memory specification of the current application and release memory to restore the Guarantee memory.

[0134] In some embodiments, several containers are deployed in the electronic device 70, and the number of applications running on each container is at least one; the memory management unit 702 is also configured to obtain the physical memory released by the applications running on the several containers using the balloon; and after removing the balloon, allocate the physical memory to the Java heap of the current application, and make a second adjustment to the Java heap memory specification of the current application to restore the Java heap memory specification of the current application; wherein the second adjustment is used to indicate an increase in the Java heap memory specification of the current application.

[0135] It can be understood that in this embodiment, a "unit" can be a part of a circuit, a part of a processor, a part of a program or software, etc., and of course it can also be a module, or it can be non-modular. Moreover, the components in this embodiment can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional module.

[0136] If the integrated unit is implemented in the form of a software function module and is not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment is essentially or the part that contributes to the prior art or the whole or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) or a processor to perform all or part of the steps of the method described in this embodiment. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk, etc., various media that can store program codes.

[0137] Therefore, this embodiment provides a computer storage medium, which stores a computer program. When the computer program is executed by at least one processor, the steps of the memory expansion and contraction management method described in any one of the above embodiments are implemented.

[0138] In another embodiment of the present application, based on the composition of the above-mentioned memory expansion management device 70 and the computer storage medium, see Figure 8 , which shows a schematic diagram of the composition structure of an electronic device 80 provided in an embodiment of the present application. Figure 8 As shown, the electronic device 80 at least includes the memory expansion and contraction management device 70 described in any one of the aforementioned embodiments.

[0139] In another embodiment of the present application, see Fig. 9 , which shows a specific hardware structure diagram of an electronic device 80 provided in an embodiment of the present application. Fig. 9 As shown, it may include: a communication interface 801, a memory 802 and a processor 803; each component is coupled together through a bus system 804. It is understood that the bus system 804 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 804 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Figure 8 Various buses are labeled as bus system 804. Among them, the communication interface 801 is used for receiving and sending signals in the process of sending and receiving information between other external network elements;

[0140] A memory 802, used to store a computer program that can be run on the processor 803;

[0141] The processor 803 is configured to execute, when running the computer program:

[0142] Monitor the service request traffic of the current application;

[0143] When the service request flow is less than the preset flow lower limit, the memory balloon is used to reduce the Java heap memory specification of the current application and release the memory;

[0144] When the service request flow is greater than a preset flow upper limit, the Balloon is removed and the Java heap memory specification of the current application is restored.

[0145] It can be understood that the memory 802 in the embodiment of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus random access memory (DRRAM). The memory 802 of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0146] The processor 803 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit or software instructions in the processor 803. The above processor 803 may be a general processor, a digital signal processor (Digital Signal Processor, DSP), an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), a field programmable gate array (Field Programmable Gate Array, FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in the embodiments of the present application can be directly embodied as a hardware decoding processor to be executed, or the hardware and software modules in the decoding processor are combined and executed. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 802, and the processor 803 reads the information in the memory 802 and completes the steps of the above method in combination with its hardware.

[0147] It is understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), general purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described in the present application, or a combination thereof.

[0148] For software implementation, the techniques described herein can be implemented by modules (e.g., procedures, functions, etc.) that perform the functions described herein. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

[0149] Optionally, as another embodiment, the processor 803 is further configured to execute the method described in any one of the aforementioned embodiments when running the computer program.

[0150] For the electronic device 80, by monitoring the service request traffic of the application, when it is detected that the service request traffic is small, the Java heap memory specification is reduced through Balloon and the memory is released. The released memory can be provided to other applications with larger service request traffic; and when it is detected that the service request traffic is large, the Balloon can be removed to restore the Java heap memory specification; thus, by dynamically adjusting the Java heap memory specification, multiple applications can share memory in a "peak-shifting" manner, reducing the overall occupancy of the application on the physical memory, thereby increasing the deployment density of the application on the electronic device and avoiding waste of memory resources.

[0151] The above description is only a preferred embodiment of the present application and is not intended to limit the protection scope of the present application.

[0152] It should be noted that, in this application, the terms "include", "comprises" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "includes a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0153] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0154] The methods disclosed in several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0155] The features disclosed in several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0156] The features disclosed in several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

[0157] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A memory expansion management method, characterized in that: Applied to electronic equipment, the method comprises: Monitor the service request flow of the current application; the current application is a Java application; When the service request flow is less than the preset flow lower limit, the memory balloon is used to reduce the Java heap memory specification of the current application and release the memory; When the service request flow is greater than a preset flow upper limit, the Balloon is removed and the Java heap memory specification of the current application is restored; Among them, an agent module is deployed in the electronic device, and a guaranteed Guarantee memory is reserved through the Agent module; wherein the Guarantee memory is used to ensure that the electronic device will not have a memory overflow phenomenon when the Balloon is removed from the Java heap of the current application or a garbage collection Full GC signal is detected.

2. The method according to claim 1, characterized in that When the service request flow is less than the preset flow lower limit, reducing the Java heap memory specification in the current application by using Balloon and releasing the memory includes: Using the Balloon to occupy a position in the Java heap of the current application, releasing the free memory occupied by the Balloon, and performing a first adjustment on the Java heap memory specification of the current application; The first adjustment is used to indicate reducing the Java heap memory specification of the current application.

3. The method according to claim 1, characterized in that The monitoring of the service request flow of the current application includes: The service request flow of the current application is monitored through the Agent module.

4. The method according to claim 1, characterized in that When the service request flow is greater than a preset flow upper limit, removing the Balloon and restoring the Java heap memory specification of the current application includes: After removing the Balloon, allocating the Guarantee memory to the Java heap of the current application, and performing a second adjustment on the Java heap memory specification of the current application to restore the Java heap memory specification of the current application; The second adjustment is used to indicate increasing the Java heap memory specification of the current application.

5. The method according to claim 1, characterized in that The method further comprises: After the Agent module detects the Full GC signal, it is determined whether the Guarantee memory meets the preset conditions; If the Guarantee memory meets the preset conditions, the Java heap memory specification of the current application is restored using the Guarantee memory, and the current application is notified to perform a garbage collection operation; If the Guarantee memory does not meet the preset conditions, continue to execute the step of determining whether the Guarantee memory meets the preset conditions.

6. The method according to claim 5, characterized in that The determining whether the Guarantee memory satisfies a preset condition includes: If the Guarantee memory is greater than or equal to the memory required to restore the Java heap memory specification of the current application, it is determined that the Guarantee memory meets the preset condition; If the Guarantee memory is less than the memory required to restore the Java heap memory specification of the current application, it is determined that the Guarantee memory does not meet the preset condition.

7. The method according to claim 5, characterized in that The method further comprises: After the current application executes the garbage collection operation, the Agent module executes the operation of refreshing the Balloon, reduces the Java heap memory specification of the current application and releases the memory to recover the Guarantee memory.

8. The method according to any one of claims 1 to 7, characterized in that: A plurality of containers are deployed in the electronic device, and the number of applications running on each container is at least one; Correspondingly, when the service request flow is greater than the preset flow upper limit, removing the Balloon and restoring the Java heap memory specification of the current application includes: Obtaining physical memory released by the Balloon using the applications running on the plurality of containers; After removing the Balloon, allocating the physical memory to the Java heap of the current application, and performing a second adjustment on the Java heap memory specification of the current application to restore the Java heap memory specification of the current application; The second adjustment is used to indicate increasing the Java heap memory specification of the current application.

9. A memory expansion management device, characterized in that: Applied to electronic equipment, the memory expansion management device comprises a monitoring unit and a memory management unit, wherein: The monitoring unit is configured to monitor the service request flow of the current application; the current application is a Java application; The memory management unit is configured to use Balloon to reduce the Java heap memory specification of the current application and release memory when the service request flow is less than a preset flow lower limit; and remove Balloon and restore the Java heap memory specification of the current application when the service request flow is greater than a preset flow upper limit; The electronic device is deployed with an agent module and a memory management unit, and is also configured to reserve a guarantee memory through the agent module; wherein the guarantee memory is used to ensure that the electronic device does not experience a memory overflow when the balloon is removed from the Java heap of the current application or a garbage collection Full GC signal is detected.

10. An electronic device, characterized in that: The electronic device comprises a memory and a processor, wherein: The memory is used to store a computer program that can be run on the processor; The processor is used to execute the memory expansion and contraction management method according to any one of claims 1 to 8 when running the computer program.

11. A computer storage medium, characterized in that: The computer storage medium stores a computer program, and when the computer program is executed by at least one processor, the memory expansion and contraction management method according to any one of claims 1 to 8 is implemented.

Images