Separated soft memory management method under multi-application deployment scene

Abstract

The invention discloses a separated soft memory management method under a multi-application deployment scene. According to the method, the difference of a soft memory system and a separated memory system in system architecture is fully considered, a unified object metadata format is designed to be compatible with reconstruction and remote access semantics, and a metadata and actual data separated storage form is adopted to support efficient unloading and recycling of a remote memory; during running, the soft memory of the application program is managed by utilizing the object pool, memory fragments are reduced by adopting a log structured distribution mode, and higher distribution efficiency is realized; the memory recovery strategy is adaptively adjusted according to the medium type and the utilization rate of the soft memory, the strategy based on swap-out, evacuation and forced recovery is realized by setting different threshold values, and the memory allocation is dynamically adjusted by monitoring local and remote soft memory resources and combining the potential revenue of an application program. And efficient utilization of soft memory resources in a multi-application deployment environment is ensured.

Description

Technical Field

[0001] The present invention belongs to the technical field of distributed system memory management and system performance optimization, and particularly relates to a separate soft memory management method in a multi-application deployment scenario. Background Art

[0002] In modern data centers, the rapid development of technologies such as cloud computing, big data, and artificial intelligence has driven a surge in demand for memory resources, yet low memory utilization remains widespread. For one thing, in multi-application deployment scenarios, inter-application memory management relies primarily on static local memory allocation, lacking dynamic resource adjustment across nodes. This prevents flexible allocation of memory resources based on actual task demands, leading to resource waste. Furthermore, the lack of local memory scalability, particularly in distributed computing scenarios, has become increasingly prominent, with significant imbalances in the allocation and use of memory resources between nodes, further limiting the scalability and flexibility of data centers.

[0003] "Storage instead of computation" is a classic concept in system design. Soft memory is a flexible virtual memory abstraction with unmap and rebuild semantics, allowing applications to use idle memory to store any reconfigurable cached data of their choice while ensuring program correctness and efficiency. The paper [Yifan Qiao, Zhenyuan Ruan, Haoran Ma, Adam Belay, Miryung Kim, and Harry Xu. 2024. Harvesting Idle Memory for Application-managed Soft State with Midas. In 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24). USENIX Association, Santa Clara, CA. https: / / www.usenix.org / conference / nsdi24 / presentation / qiao] proposes a soft memory runtime system based on object-level granularity. It models multi-application deployment scenarios as an optimization problem and uses a hill climbing algorithm to dynamically adjust the soft memory quotas of multiple applications to achieve optimal overall performance in a single-machine multi-application deployment scenario. This system addresses the issues caused by static memory allocation to a certain extent. However, this system is limited to managing local memory resources and cannot meet the needs of cross-node memory resource adjustment. Especially when the system is in a memory-constrained situation, the constant contention for soft memory between applications will lead to frequent rebuilds, resulting in significant access latency.

[0004] With the development of modern high-speed communication technologies, the performance of remote memory access has significantly improved. The paper [Zhenyuan Ruan, Malte Schwarzkopf, Marcos K. Aguilera, and Adam Belay. 2020. AIFM: High-Performance, Application-Integrated Far Memory. In USENIX Symposium on Operating Systems Design and Implementation (OSDI). 315–332.] proposes a high-performance split memory system. This system aims to integrate remote memory into applications, providing split memory services with similar latency to local DRAM access, thereby expanding available memory capacity and improving application performance. However, this system's application scenario is limited to a single application, and it does not fully consider the resource contention between local and remote memory in multi-application deployment scenarios, nor does it fully consider how to achieve optimal scheduling for overall performance. Furthermore, the system's scalability is limited due to its lack of support for dynamic resizing of remote memory capacity.

[0005] Given the above, while existing soft memory runtime systems can dynamically adjust the soft memory quota of each application in local memory to optimize overall system performance, with the continuous development of interconnect technology and separate memory systems, local soft memory systems are expected to further expand their capabilities. This will help further improve memory utilization and application execution efficiency in data centers. The main challenges in implementing an object-level application integration runtime system that supports separate soft memory management are:

[0006] 1. Unify the object metadata design paradigm for soft memory systems and separate memory systems; make object reconstruction semantics and remote access semantics compatible, avoiding the introduction of excessive latency that affects system memory management complexity and application execution efficiency.

[0007] 2. Design a dynamic and efficient memory reclamation method to meet the elastic scaling requirements of memory under different load conditions. For gradual memory load conditions, adopt a moderate object memory reclamation strategy to reduce the impact of memory rebuilds on overall system performance. For bursty memory load conditions, adopt an aggressive object memory reclamation strategy to support rapid release of memory resources and ensure timely system responsiveness.

[0008] 3. Optimize local and remote memory allocation strategies for multi-application deployment scenarios. When coordinating memory resource scheduling, the system ensures that overall performance is optimized when allocating memory based on current local and remote memory capacity limitations and comprehensive consideration of factors such as computation, access, and reconstruction latency. Summary of the Invention

[0009] In view of the above, the present invention provides a method for separate soft memory management in a multi-application deployment scenario. It combines the high-level programming abstractions of soft memory and separate memory, and maximizes the overall system performance through collaboration between the application integration runtime and the global coordinator. The system designs a unified object metadata format at the object-level granularity to be compatible with reconstruction semantics and remote access semantics; at the same time, it designs a dynamic and efficient memory recovery method in the memory management mechanism to adapt to the elastic scaling requirements of memory under different load conditions; finally, it optimizes the local and remote memory allocation strategy in the multi-application deployment scenario on the global coordinator, so that it can dynamically adjust the ratio and quota of local and remote memory of each application, ensuring the optimization of the overall system throughput and latency in the multi-application deployment scenario.

[0010] The separated soft memory management method in a multi-application deployment scenario includes the following steps:

[0011] Global coordinator initialization: Start the global coordinator to monitor and manage local and remote soft memory resources, and interact with all registered applications through inter-process communication (IPC).

[0012] Application integration runtime initialization: For each application, the application integration runtime is started. The runtime manages soft memory by creating an object pool of the corresponding type, establishes a connection with the global coordinator through IPC, and registers as a client of the global coordinator.

[0013] Memory allocation: Log-structured allocation is used to allocate soft memory for objects at runtime. The metadata and actual data of an object are stored separately. Metadata is stored in a specific metadata space, and actual data is stored in soft memory pages.

[0014] Memory access: At runtime, read and write requests for objects are processed using copy access. If the accessed soft memory is lost due to recycling, the object data is rebuilt according to the reconstruction parameters provided by the application.

[0015] Memory reclamation: At runtime, the system adaptively executes different reclamation strategies based on the current soft memory medium type and usage rate, including swap-based reclamation strategy, evacuation-based reclamation strategy, forced reclamation strategy, and unload reclamation strategy.

[0016] Resource monitoring and statistics: The global coordinator regularly sends instructions to each application through IPC to count each application's soft memory usage and potential benefits, including the number of access hits, access misses, rebuild triggers, and business processing delays.

[0017] Memory scheduling optimization: The global coordinator models the memory scheduling problem as an optimization problem based on the system's soft memory capacity and the potential benefits of each application. It optimizes the overall system performance by dynamically adjusting the soft memory quota of each application.

[0018] Beneficial effects of the present invention:

[0019] The present invention combines the high-level programming abstractions of soft memory and separated memory, and can achieve collaboration between the application integration runtime and the global coordinator in multi-application deployment scenarios to maximize the overall system performance.

[0020] The present invention fully considers the differences in system architecture between soft memory systems and separate memory systems, designs a unified object metadata format to be compatible with reconstruction and remote access semantics, adopts the form of separate storage of metadata and actual data to support efficient unloading and recovery of remote memory, eliminating the delay overhead caused by frequent access to remote memory metadata; at runtime, an object pool is used to manage the soft memory of the application, and a log-structured allocation method is used to reduce memory fragmentation and achieve higher allocation efficiency; the memory recovery strategy is adaptively adjusted according to the medium type and usage rate of the soft memory, and strategies based on swapping out, evacuation and forced recovery are implemented by setting different thresholds to cope with different load conditions; the global coordinator models the memory scheduling problem as an optimization problem, monitors local and remote soft memory resources, and dynamically adjusts memory allocation in combination with the potential benefits of the application, models the memory scheduling problem as an optimization problem and uses the hill climbing method to solve it, ensuring the efficient utilization of soft memory resources in a multi-application deployment environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 This is the overall architecture diagram of the separated soft memory management system in the multi-application deployment scenario of the present invention;

[0022] Figure 2 Schematic diagram of object metadata management and log structured distribution;

[0023] Figure 3 Schematic diagram of the exchange-based recycling strategy process;

[0024] Figure 4 This is a flow chart of the uninstall recovery strategy;

[0025] Figure 5This is a graph showing the overall throughput and P99 latency experimental results of the separated soft memory management system of the present invention and other mainstream methods in a multi-application deployment scenario. DETAILED DESCRIPTION

[0026] In order to describe the present invention more specifically, the technical solution of the present invention is described in detail below with reference to the accompanying drawings and specific embodiments.

[0027] This application provides a separate soft memory management method in a multi-application deployment scenario, including the following steps:

[0028] (1) For any application, the application-integrated runtime manages the allocation, access, and recycling of its soft memory. For any type of object, the runtime manages it by creating an object pool of the corresponding type and communicating with the global coordinator through IPC.

[0029] When creating an object pool during runtime, the application integration in step (1) first establishes a connection with the global coordinator via IPC. The object pool is registered as a client on the global coordinator and is allocated a default amount of initial soft memory. The runtime manages available soft memory through the object pool, providing basic soft memory services such as allocation, access, and release to the application. When there is excess memory, some soft memory is returned to the global coordinator. When there is insufficient memory, a memory recycling mechanism is triggered, responding to expansion, contraction, and information statistics instructions sent by the global coordinator.

[0030] like Figure 1 As shown, the CPU server must run a daemon process, the global coordinator, to manage all soft memory applications deployed on it. For any application, the user creates an object pool using the system's predefined soft memory data structure. During construction, the object pool actively establishes a connection with the global coordinator and registers with the global coordinator as a client.

[0031] The application calls the allocator to perform memory allocation through the interface provided by the runtime. When local or remote memory is exhausted, the collector adaptively implements different recycling strategies based on the soft memory medium type and usage.

[0032] The runtime tracks the application's soft memory usage, including metrics such as access hits, access misses, rebuild triggers, business processing latency, per-byte rebuild latency, object rebuild latency, and remote access latency. This information is regularly provided to the global coordinator via IPC. For scaling commands sent by the global coordinator, the runtime updates the available soft memory capacity of the object pool in real time.

[0033] (2) For memory allocation, the runtime uses a log-structured allocation method to allocate soft memory for objects. The metadata and actual data of the object are stored separately, with the metadata stored in a specific metadata space and the actual data stored in the soft memory page.

[0034] like Figure 2 As shown in (b), the runtime manages the available soft memory of the object pool at a page granularity. Soft memory is divided into 2MB pages, with sequential allocation within the pages. Data for objects of the same type is closely adjacent within the page. Objects are divided into large objects and small objects based on whether they occupy more than 32KB of bytes. Small object data is indivisible and stored as a whole in the soft memory page. Large object data is divided into as few parts as possible based on the page capacity and linked together in a linked list using object metadata.

[0035] The runtime defines two states for soft memory pages: available state and sealed state, to indicate whether there is still free space in the page. When a page is fully allocated, it will be marked as "sealed" and await subsequent cleanup operations. At this time, the runtime will allocate a new clean page for use. Soft memory pages are managed using a dedicated linked list based on their states. For application memory allocation requests, priority is given to using pages in the available state for allocation. If the allocation fails, a new page is allocated to continue the allocation operation. Among them, the fully allocated page will change from the available state to the sealed state and be placed in a dedicated linked list for sealed pages. The memory reclaimer will only recycle pages in the sealed state.

[0036] like Figure 2 As shown in (b), object metadata and actual data are stored separately. Each object pool maintains a metadata space. For any soft memory page, the metadata space allocates a separate metadata area to store metadata information of all objects in the page. The metadata area is a fixed-size memory segment with a size of Where: PageSize is the number of bytes occupied by the soft memory page, ObjectSize is the number of bytes occupied by the actual data of a single object, and MetaSize is the number of bytes occupied by the metadata of a single object. By traversing the metadata area, you can obtain the metadata information of all objects in the page.

[0037] (3) For memory access, the runtime uses copy access to process the read and write requests of the object. If the accessed soft memory is lost due to recycling, the object data is rebuilt according to the reconstruction parameters provided by the application.

[0038] Because large object data is split into several parts and stored in different soft memory pages, the addresses between soft memory pages are not necessarily continuous, which means that the original data cannot be directly accessed through native pointers. Therefore, the runtime uses copy access to handle object read and write requests, that is, access will create a temporary copy of the object data.

[0039] Because soft memory pages are subject to reclaim at any time, reclaiming them will naturally cause read and write requests to fail. Therefore, applications must provide the object's reconstruction parameters when accessing soft memory objects. In the event of an access failure, the runtime leverages the reconstructible nature of soft memory to reconstruct the object data using the reconstruction function passed in when the object pool was created and the provided reconstruction parameters. The reconstructed object is then reallocated as a new object to the soft memory page for subsequent access.

[0040] like Figure 2 As shown in (b), due to the system's split-memory nature, objects may reside in the soft memory pages of a remote memory server. Therefore, when objects reside in remote memory, the runtime performs a swap-in operation: first, the swapped-in object is reallocated as a new object to a local soft memory page. Then, the data is transferred to the local server over the network and written to the allocated memory area. Finally, metadata is used to mark the remote object as released. When the remote memory is exhausted, the memory collector reclaims this memory.

[0041] (4) For memory recycling, different recycling strategies are adaptively executed according to the medium type and usage rate of the current soft memory at runtime.

[0042] The memory reclamation process consists of two phases: the scanning phase and the reclamation phase.

[0043] The scanning phase is used to determine the memory pages that need to be recycled. During the scanning phase, the recycler takes the memory page from the sealed page dedicated linked list, counts the access counts of all objects in the page by scanning the metadata area corresponding to the page, and decrements the access counts of the objects one by one. For objects with an access count of 0, that is, the object has not been accessed in the recent period, it is marked as a cold object. For objects with a cold object ratio less than α cold The page is marked as a cold page. Here we define α cold = 0.9. This process will continue until the soft memory usage drops to the target level.

[0044] The recycling phase is used to migrate hot objects to new memory pages and release cold pages. During the recycling phase, different recycling strategies are adopted for different memory load conditions, that is, a milder recycling strategy is adopted when the memory pressure is low, and a more aggressive recycling strategy is adopted when the memory pressure is high. Specifically, the collector defines three thresholds: T swap ,T reclaim ,Tforce , where T swap <T reclaim <T force Here we define T swap =0.85,T reclaim =0.95,T force =0.99.

[0045] When the local memory usage reaches T swap When the memory reclaimer executes a swap-based recycling strategy, it first scans the local soft memory pages marked as "sealed", and for cold pages with low access frequency and a large proportion of cold objects, it migrates the hot objects and cold objects in the pages to other memory pages and cache pages respectively, and finally swaps out the cache pages to the remote memory and releases the scanned cold pages; (that is, swaps out the cold objects in the cold pages to the remote memory pages at the page granularity). Figure 3 As shown in the figure, in step ①, hot objects in the cold page are migrated to other local pages, and cold objects in the cold page are migrated to the cache page. Cache pages are local memory pages temporarily allocated for use and automatically released after the swap is completed. In step ②, the cold page is recycled and released. In step ③, if a cold object in the buffer page is accessed during the swap process, it is migrated from the buffer page to another local page. In step ④, when the buffer page is full, the data is transferred to the remote memory page over the network and the object metadata is updated to complete the swap. The buffer page is then recycled and released.

[0046] When the remote memory usage reaches T swap When the CPU server records the migration results, it sends them to the memory server to complete the migration. Finally, the scanned pages are released.

[0047] Remote memory pages contain two types of objects: the first type is cold objects that have been swapped out from local memory pages to remote memory pages and have not yet been accessed. These objects are valid because they may be accessed in the future. The second type is cold objects that have been swapped back from remote memory pages to local memory pages and released. These objects are invalid because they have already been released. Therefore, the main goal of the offload recovery strategy is to migrate valid objects in remote memory pages and reclaim the memory occupied by invalid objects. Figure 4 As shown, in step 1, the CPU server scans the metadata area of the memory page to determine the migration plan, which includes the original address of the valid object in the memory page and the destination address after migration. In step 2, the CPU server sends the migration plan to the memory server. In step 3, the memory server completes the data migration of the valid object according to the migration plan. In step 4, after receiving the confirmation signal, the CPU server updates the object metadata and releases the page.

[0048] When the local memory usage reaches T reclaim When , the collector executes an evacuation-based reclamation strategy. That is, it first scans the local soft memory pages marked as "sealed". For cold pages, it migrates the hot objects in the pages to other memory pages and directly releases the cold objects, finally releasing the scanned cold pages. During the execution process, unlike the swap-based reclamation strategy, the collector directly releases the cold objects in the cold pages.

[0049] When the local or remote memory usage reaches T force When , the collector implements a forced reclamation strategy. This means directly releasing local soft memory pages marked as "sealed." When memory usage drops to the target value, the memory collector stops. During this process, the collector removes memory pages from the dedicated linked list of sealed pages and directly releases them without scanning them. This process continues until memory usage drops to the target level.

[0050] (5) Use the global coordinator to monitor and manage available local and remote soft memory resources. The coordinator communicates with all applications registered on it using IPC and regularly counts the soft memory usage and potential benefits of each application. L ,G F .

[0051] The global coordinator sends statistical information to all clients every 5 seconds to track the soft memory usage of the application. The statistical indicators include the number of access hits, the number of access misses, the number of reconstruction triggers, the business processing delay, the unit byte reconstruction delay, the object reconstruction delay, and the remote access delay. Based on the statistical indicators, the global coordinator calculates the local and remote potential benefits G of each application. L ,G F The potential gain G is calculated as follows:

[0052]

[0053] Where: T R is the soft memory reconstruction delay, T A is the access delay of soft memory, Miss is the number of times the soft memory reconstruction is triggered within a certain period of time, S is the number of bytes occupied by the object data, T E Processing delay for the application.

[0054] Furthermore, Indicates the latency benefit difference between direct reconstruction and soft memory access per byte of data. Indicates the proportion of reconstruction delay in the business processing process. For local memory, soft memory access delay T A can be ignored; for remote memory, soft memory access involves network communication, T AThis cannot be ignored. Applications with less soft memory will experience more rebuild misses due to frequent memory reclamation, thereby increasing potential revenue. The extent of this potential revenue increase depends on the rebuild latency per byte and the proportion of rebuild latency in business processing. A higher rebuild latency means that allocating more memory can significantly improve performance, while a higher proportion of rebuild latency in business processing means that allocating more memory can significantly improve business processing efficiency.

[0055] (6) The global coordinator calculates the system soft memory capacity and the potential benefits of each application G L ,G F The memory scheduling problem is modeled as an optimization problem, and overall system performance is optimized by adjusting the soft memory quota of each application. Specifically, when the soft memory capacity is expanded, the coordinator triggers the expansion mechanism to allocate more soft memory to applications with greater potential benefits. When the soft memory capacity is reduced, the coordinator triggers the reduction mechanism to reclaim soft memory from applications with smaller potential benefits. When the potential benefits between applications change, the coordinator triggers the coordination mechanism to reclaim soft memory from applications with smaller potential benefits and allocate it to applications with greater potential benefits.

[0056] The global coordinator models the memory coordination and allocation problem in a multi-application deployment scenario as an optimization problem. It uses a hill-climbing approach to gradually approach an allocation solution that optimizes the overall system performance. The optimization problem is defined as follows:

[0057]

[0058] Among them, M L is the local soft memory capacity available to the system, M F is the remote soft memory capacity available to the system, m L,i ,m F,i denote the local and remote soft memory quotas of application i, G L,i ,G F,i denote the potential benefits of application i on local and remote soft memory, respectively.

[0059] Specifically, when the soft memory capacity is expanded, the global coordinator calculates Allocate soft memory to applications with high potential benefits; when the soft memory capacity is reduced, the global coordinator calculates Reclaim soft memory from applications with small potential benefits; when the potential benefits between applications change, the global coordinator calculates Reclaim soft memory from applications with little potential gain, computing Allocate soft memory for applications with high potential benefits. Where ΔM is the change in soft memory of the system, Δm iis the soft memory change of application i, M revoke ,M grant Coordinates the amount for predefined soft memory units.

[0060] After completing the above steps, the separated soft memory management in the multi-application deployment scenario is completed. It is tested on four real-world applications with different reconstruction delays and compared with the mainstream method. Figure 5 The throughput and P99 latency of the entire system and each application are shown, where Rosin represents the system of the present invention.

[0061] As can be seen, Rosin outperforms other baselines in overall throughput and P99 latency, particularly when the ratio of local to remote soft memory is 1:5. Compared to the local soft memory system Midas and the split memory system AIFM, Rosin achieves 1.30x and 1.23x higher overall throughput, respectively, and reduces tail latency by 10% to 20%. As the ratio of local soft memory increases, the performance gap between baselines decreases due to a lower contribution to remote access latency.

[0062] The above description of the embodiments is intended to facilitate understanding and application of the present invention by those skilled in the art. It is apparent that those skilled in the art can readily make various modifications to the above embodiments and apply the general principles described herein to other embodiments without requiring creative effort. Therefore, the present invention is not limited to the above embodiments. Any improvements or modifications made by those skilled in the art based on the disclosure of the present invention should fall within the scope of protection of the present invention.

Claims

1. A separate soft memory management method in a multi-application deployment scenario, characterized in that: The following steps are involved: Global coordinator initialization: Start the global coordinator to monitor and manage local and remote soft memory resources, and interact with all registered applications through inter-process communication (IPC). Application integration runtime initialization: For each application, the application integration runtime is started. The runtime manages soft memory by creating an object pool of the corresponding type, establishes a connection with the global coordinator through IPC, and registers as a client of the global coordinator. Memory allocation: Log-structured allocation is used to allocate soft memory for objects at runtime. The metadata and actual data of an object are stored separately. Metadata is stored in a specific metadata space, and actual data is stored in soft memory pages. Memory access: At runtime, read and write requests for objects are processed using copy access. If the accessed soft memory is lost due to recycling, the object data is rebuilt according to the reconstruction parameters provided by the application. Memory reclamation: At runtime, the system adaptively executes different reclamation strategies based on the current soft memory medium type and usage rate, including swap-based reclamation strategy, evacuation-based reclamation strategy, forced reclamation strategy, and unload reclamation strategy. Resource monitoring and statistics: The global coordinator regularly sends instructions to each application through IPC to count each application's soft memory usage and potential benefits, including the number of access hits, access misses, rebuild triggers, and business processing delays. Memory scheduling optimization: The global coordinator models the memory scheduling problem as an optimization problem based on the system's soft memory capacity and the potential benefits of each application. It optimizes the overall system performance by dynamically adjusting the soft memory quota of each application.

2. The method for separate soft memory management in a multi-application deployment scenario according to claim 1, characterized in that: When creating the object pool, the runtime first establishes a connection with the global coordinator through IPC. The object pool is registered as a client on the global coordinator and is allocated a default amount of initial soft memory.

3. The method for separate soft memory management in a multi-application deployment scenario according to claim 1, characterized in that: The runtime uses a log-structured memory allocation method, specifically: Soft memory is divided into 2MB pages at page granularity. Each page is allocated sequentially, and data of objects of the same type are closely adjacent in the page. When a page is fully allocated, it is marked as "sealed" and the runtime allocates a new clean page for use.

4. The method for separate soft memory management in a multi-application deployment scenario according to claim 3, characterized in that: The specific method of storing the object metadata and actual data separately is as follows: A metadata space is maintained for each object pool. For any soft memory page, the metadata space allocates a separate metadata area to store metadata information of all objects in the page.

5. The method for separate soft memory management in a multi-application deployment scenario according to claim 1, characterized in that: The memory reclamation strategy includes: When the local memory usage reaches the first threshold, the swap-based recycling strategy is triggered to swap out cold objects to remote memory; When the local memory usage reaches the second threshold, the evacuation-based recycling strategy is triggered to directly release cold objects; When the local memory usage reaches the third threshold, the forced recycling policy is triggered, and the local soft memory pages marked as "sealed" are directly released; When the remote memory usage reaches the fourth threshold, the unloading and recycling strategy is triggered to migrate valid objects in the remote memory and release the memory occupied by invalid objects.

6. The method for separate soft memory management in a multi-application deployment scenario according to claim 1, characterized in that: The potential gain is calculated as follows: Where: T R is the soft memory reconstruction delay, T A is the access delay of soft memory, Miss is the number of times the soft memory reconstruction is triggered within a certain period of time, S is the number of bytes occupied by the object data, T E Processing delay for the application.

7. The method for separate soft memory management in a multi-application deployment scenario according to claim 1, characterized in that: The memory scheduling problem is modeled as an optimization problem, specifically defined as: Where: M L is the local soft memory capacity available to the system, M F is the remote soft memory capacity available to the system, m L，i , m F，i denote the local and remote soft memory quotas of application i, G L，i , G F，i denote the potential benefits of application i on local and remote soft memory, respectively.

8. The method for separate soft memory management in a multi-application deployment scenario according to claim 1, characterized in that: The global coordinator gradually approaches the allocation scheme that optimizes the overall system performance through a hill climbing method, specifically including: When soft memory capacity is expanded, more soft memory is allocated to applications with greater potential benefits; When soft memory capacity shrinks, reclaim soft memory from applications with smaller potential benefits; When the comparative relationship of potential benefits between applications changes, soft memory is reclaimed from applications with smaller potential benefits and allocated to applications with larger potential benefits.

Images