Hierarchy-Based In-Memory Management System for Graph Databases

Abstract

The present invention discloses a hierarchical graph database memory management system, belonging to the technical field of database management systems, including: a hierarchical memory tracker module, which organizes multiple-level memory trackers using a tree-like hierarchical architecture, wherein each level of memory tracker is built-in with a reservation mechanism for implementing elastic allocation of memory resources according to hierarchical reservation information; a memory usage definition module, which is used to generate differentiated memory monitoring metrics according to thread scenario characteristics, including operator-level fine-grained monitoring metrics in single-thread scenarios and global monitoring metrics in multi-thread scenarios; a hybrid memory allocator module, which integrates the hierarchical monitoring logic of the hierarchical memory tracker module, is used to obtain the memory status in real time, and dynamically execute memory allocation and recycling operations according to hierarchical reservation information. This application reduces the possibility of the usage counter of the parent-level memory tracker becoming a bottleneck through the hierarchical memory tracker and the reservation mechanism, and improves the efficiency of memory allocation and release.

Description

Technical Field

[0001] The present invention relates to the technical field of database management systems, and in particular to a hierarchical-based in-memory management system for graph databases. Background Art

[0002] In a database management system (DBMS), memory management is a key issue that directly affects the performance and stability of the system. As the complexity of the database system increases, it is necessary to efficiently track and manage memory resources to balance efficiency and functionality.

[0003] However, existing technical solutions each have their own deficiencies:

[0004] 1. Directly use the system's native memory allocation mechanism to apply for and release memory. This method cannot perform fine-grained tracking of the memory usage of the database system, and because there is no quota management, it cannot prevent the situation where the database service process is killed due to the database system running out of memory.

[0005] 2. Through a single memory manager to specifically manage modules with large memory requirements (such as execution layer operators, etc.). This method cannot monitor all the memory used by the database management system, lacks a global perspective, and at the same time, in a multi-threaded situation, a single memory manager may become a performance bottleneck.

[0006] 3. Through the method of a timer, query the memory usage status at regular intervals, and during the process of the database system executing a query, prevent the memory of the database service process from exceeding the rated usage by inserting memory checkpoints. This method, due to being a periodic detection mechanism, has a certain time delay, cannot achieve real-time monitoring of memory usage, and at the same time, cannot achieve memory management at the query / operator granularity.

[0007] In summary, the existing memory management methods generally face the following challenges: lack of fine-grained tracking of the memory usage of different components, making it difficult to achieve accurate memory quota management and detailed memory analysis, resulting in unreasonable memory resource allocation, and there may be a situation where some components over-occupy memory while other components are short of memory; in a multi-threaded environment, the statistics and update of memory usage may cause thread safety problems, affecting the stability of the system; and it cannot take into account the memory quota management from the global to the fine-grained inside the database system. Summary of the Invention

[0008] The purpose of the present invention is to provide a hierarchical-based in-memory management system for graph databases to solve the problems that the existing memory management methods can neither perform fine-grained tracking of the memory usage of each component, nor ensure multi-thread safety, and at the same time, cannot take into account the memory quota management from the global to the fine-grained inside the database system.

[0009] To achieve the above object, the present application adopts the following technical solutions:

[0010] A hierarchical graph database memory management system of the present application includes:

[0011] A hierarchical memory tracker module that organizes multiple-level memory trackers using a tree-like hierarchical architecture, where each level of memory tracker has a built-in reservation mechanism for flexibly allocating memory resources according to hierarchical reservation information;

[0012] A memory usage definition module for generating differentiated memory monitoring metrics based on thread scenario characteristics, including operator-level fine-grained monitoring metrics in a single-thread scenario and global monitoring metrics in a multi-thread scenario;

[0013] A hybrid memory allocator module that integrates the hierarchical monitoring logic of the hierarchical memory tracker module, for real-time obtaining the memory status and dynamically performing memory allocation and recycling operations according to the hierarchical reservation information.

[0014] Preferably, the hierarchical memory tracker module includes:

[0015] A global memory tracker, as the root node, manages the global memory limit and usage. When the total memory usage exceeds the global memory limit, a memory allocation exception is triggered;

[0016] A query memory tracker, mounted as a child node under the global memory tracker, has a configurable maximum reserved memory and an optional maximum usable memory limit, and supports dynamically applying for memory from the parent level;

[0017] An operator memory tracker, as a child node of the query memory tracker, can be configured with a smaller maximum reserved memory and obtains memory resources using a multi-level parent application mechanism;

[0018] A network memory tracker, mounted as a child node under the global memory tracker, for memory management of remote procedure calls, can be independently configured with a maximum reserved memory and a maximum usable memory limit, and supports dynamically applying for memory from the parent level.

[0019] Preferably, the maximum usable memory limit of the query memory tracker can be dynamically adjusted through session configuration or query parameters. When the cumulative application amount of the child-level tracker exceeds the maximum usable limit, a cascading memory release is triggered.

[0020] Preferably, the reservation mechanism includes:

[0021] When performing memory allocation, the child-level tracker preferentially uses the local reserved memory. When the local reserved memory is insufficient, it applies to its parent level for the maximum reserved memory block;

[0022] When performing memory release, the child tracker first determines whether the sum of the local reserved memory and the memory release amount exceeds the local maximum reserved memory. If it exceeds, it returns the maximum reserved memory block to its parent.

[0023] Preferably, the reservation mechanism further includes setting different reservation granularities at different levels to balance the application efficiency and monitoring accuracy.

[0024] Preferably, the reservation application adopts a batch pre-allocation strategy, and the single application amount of the operator-level tracker is its maximum reserved memory value.

[0025] Preferably, the operator-level fine-grained monitoring metrics in the single-thread scenario include the current memory amount, historical peak, cumulative allocation / release amount, and the distribution of allocation size histograms;

[0026] The global monitoring metrics in the multi-thread scenario include the atomized current memory amount and historical peak, supporting thread safety in a concurrent environment.

[0027] Preferably, the hybrid memory allocator module includes:

[0028] A general memory allocator for injecting tracking logic into memory allocation and release operations and recording the memory usage status;

[0029] An STL-specific memory allocator for adapting standard containers through template specialization technology and injecting customized tracking logic into container memory operations.

[0030] Preferably, the system further includes a debugging module for determining whether the memory usage meets the expectations.

[0031] Preferably, the system further includes a benchmark testing module for timing and counting memory allocation and release operations according to test cases to determine the system performance.

[0032] The present invention has the following beneficial effects:

[0033] Through the hierarchical memory tracker and the reservation mechanism, the possibility of the usage counter of the parent memory tracker becoming a bottleneck is reduced, and the efficiency of memory allocation and release is improved; also in the multi-thread scenario, the use of atomic counters ensures thread safety in the concurrent scenario of memory usage statistics. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0035] Figure 1 It is a schematic structural diagram of a hierarchical graph database memory management system provided by an embodiment of the present application;

[0036] Figure 2 It is a comparison chart of the latency time under benchmark tests;

[0037] Figure 3 It is a comparison chart of the throughput under benchmark tests. Detailed implementation manners

[0038] To make the technical solution of the present application clearer, the following further describes the present invention in detail with reference to the accompanying drawings and specific embodiments. The terms "first", "second", etc. in the claims and the description of the present application are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence. It should be understood that such terms can be interchanged under appropriate circumstances. This is only a way of distinguishing objects with the same attributes when describing the embodiments of the present application. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, so that a process, method, system, product or device comprising a series of units does not have to be limited to those units, but may include other units not clearly listed or inherent to these processes, methods, products or devices.

[0039] Glossary:

[0040] Memory Tracker: A module responsible for tracking the memory resources used by each component in the database management system. Through the Memory Tracker, memory quota management and detailed memory analysis can be achieved.

[0041] Layered Memory Tracker: Since the core components involved in query execution have a hierarchical structure, the memory tracker also adopts a layered design. Trackers at different levels have different functions and attributes, such as different parent trackers, reserved memory sizes and limits, etc.

[0042] Reserve: Each sub-memory tracker reserves a certain memory quota for itself. When performing memory allocation and release operations, the child tracker first attempts to obtain memory from the reserved memory or return the memory to the local, in order to reduce the calls to the parent tracker and avoid the usage counter of the parent tracker becoming a bottleneck.

[0043] Memory Usage Definition: Memory trackers at different levels have different definitions of memory usage, mainly considering thread access situations and detailed allocation metrics. For example, the memory usage definition in a single-threaded scenario is different from that in a multi-threaded scenario, and more detailed memory allocation information is also recorded in a debug build.

[0044] Allocator: The module used for memory allocation, including the ordinary allocator and the STL-compatible allocator. They both wrap a memory tracker pointer to track the number of bytes allocated from them and route to the system's memory allocation functions (such as jemalloc).

[0045] As Figure 1 shown, this embodiment provides a hierarchical graph database memory management system, including:

[0046] Hierarchical Memory Tracker Module, which organizes multi-level memory trackers using a tree-like hierarchical architecture. Each level of memory tracker has a built-in reservation mechanism to implement elastic allocation of memory resources according to hierarchical reservation information;

[0047] Memory Usage Definition Module, which generates differentiated memory monitoring metrics according to thread scenario characteristics, including operator-level fine-grained monitoring metrics in a single-threaded scenario and global monitoring metrics in a multi-threaded scenario;

[0048] Hybrid Memory Allocator Module, which integrates the hierarchical monitoring logic of the Hierarchical Memory Tracker Module to obtain the memory status in real time and dynamically perform memory allocation and recycling operations according to hierarchical reservation information.

[0049] In the embodiments of the present disclosure, the graph database memory management system mainly includes three parts: the hierarchical memory tracker module, the memory usage definition module, and the hybrid allocator module.

[0050] Furthermore, the hierarchical memory tracker module includes:

[0051] Global Memory Tracker, as the root node, manages the global memory limit and usage. When the total memory usage exceeds the global memory limit, a memory allocation exception is triggered;

[0052] Query Memory Tracker, which is mounted under the Global Memory Tracker as a child node, has a configurable maximum reserved memory and an optional maximum usable memory limit, and supports dynamically applying for memory from the parent;

[0053] Operator Memory Tracker, as a child node of the Query Memory Tracker, has a configurable smaller maximum reserved memory and obtains memory resources using a multi-level parent application mechanism;

[0054] The network memory tracker, which is mounted as a child node under the global memory tracker, is used for the memory management of remote procedure calls. It can be independently configured with the maximum reserved memory and the maximum available memory limit, and supports dynamically applying for memory from the parent level.

[0055] Among them, the hierarchical memory tracker module has a hierarchical structure, including a global memory tracker MemoryTracker as the root node. <global>and multiple hierarchically organized child trackers. Further, the child trackers each include a plurality of query memory trackers MemoryTracker that have the global memory tracker as their parent node <query>and the network memory tracker MemoryTracker <rpc>, and multiple operator memory trackers MemoryTracker with the query memory tracker as the parent node <operator>。

[0056] Global Memory Tracker MemoryTracker <global>At the top of the hierarchical structure, it is a memory tracker with a global singleton scope, having no parent and no reserved memory. As the root node, it is responsible for managing the global memory limit and memory usage. When the memory usage exceeds the global limit, a std::bad_alloc exception is thrown, causing the query that triggered the limit to fail, and the memory occupied by the query is released accordingly.

[0057] The global memory limit is affected by the total system memory size and the configuration item memory_ratio. Memory_ratio is a value between 0 and 1, representing the proportion of the global memory limit to the total system memory. Assuming the total system memory is 100G and the memory_ratio is configured to 0.9, the global available memory is 100G * 0.9 = 90G.

[0058] Query memory tracker MemoryTracker <query>It is a memory tracker within a single query range, with its parent being the global memory tracker. The maximum reserved memory size can be determined based on experience and benchmark results and is a compiler-configurable value. In the embodiments of the present disclosure, the default value is 64KB. By default, there is no limit on the maximum limit of the query memory tracker. If you want to limit the maximum available memory for a certain query, it is supported to set it through session configuration or query parameters, such as setting the query parameter memory_limit = 102400 bytes.

[0059] Operator Memory Tracker MemoryTracker <operator>It is a memory tracker within the operator scope, whose parent is the query memory tracker. The maximum reserved memory size can also be configured, with a default of 4KB, and there is no limit on the maximum available memory.

[0060] Furthermore, the reservation application adopts a batch pre-allocation strategy, and the single application volume of the operator-level tracker is its maximum reserved memory value.

[0061] The operator memory tracker can only apply to its parent for one maximum reserved memory block each time.

[0062] Network memory tracker MemoryTracker <rpc>It is a content tracker for network RPCs, which is used to track memory usage related to remote procedure calls (RPCs). Its maximum reserved memory is the same as that of the query memory tracker, and the maximum available memory is determined by the parameter rpc_max_memory. For example, if rpc_max_memory = 10GB, during remote execution, if the memory used by the RPC exceeds the limit, a std::bad_alloc exception will also be thrown, causing the query that triggered the exception to fail and releasing the query memory.

[0063] It should be noted here that a reservation mechanism is built into the query memory tracker, the network memory tracker, and the operator memory tracker. Since the child tracker needs to report the memory usage to its parent tracker, in order to avoid the usage counter of the parent tracker becoming a bottleneck due to frequent reporting, in the embodiments of the present disclosure, a certain memory quota will be reserved for each memory tracker, and the memory allocation efficiency will be optimized through the reservation mechanism.

[0064] Furthermore, the reservation mechanism includes:

[0065] When allocating memory, the child tracker preferentially uses the local reserved memory. When the local reserved memory is insufficient, it requests the largest reserved memory block from its parent;

[0066] When releasing memory, the child tracker first determines whether the sum of the local reserved memory and the memory release amount exceeds the local maximum reserved memory. If it exceeds, it returns the largest reserved memory block to its parent.

[0067] Specifically, the reservation mechanism includes that each time memory is allocated (alloc), the child tracker first tries to obtain the requested memory size from the local reserved memory. If the local reserved memory meets the request size, the size is subtracted from the reserved memory; otherwise, it obtains another reservation from its parent tracker. For example, if the remaining reservation of the child tracker is 30KB and the current application requires 40KB, and the local reserved memory is not enough, it will ask its parent tracker for a memory block of its own maximum reserved size (assuming 64KB). After obtaining it, the child tracker has (30 + 64)KB. After subtracting 40KB, the remaining 54KB is used as its reserved memory.

[0068] This reservation mechanism also includes that each time memory is released (dealloc), the child tracker first adds the requested memory size to the reserved memory. If the local reserved memory size after addition does not exceed the maximum reserved size, it will not trigger a release to the parent; otherwise, it returns the local maximum reserved size to its parent tracker and retains the remaining part as the local reservation.

[0069] Furthermore, the reservation mechanism also includes setting different reservation granularities at different levels to balance the application efficiency and monitoring accuracy.

[0070] It should be specifically pointed out here that the maximum reserved memory sizes of trackers at different levels are different. A larger reserved memory will reduce the allocation calls to the parent tracker, but an overly large reserved memory will make the parent tracker have a coarser observation granularity of the overall memory. Assuming that the maximum reservation of the operator memory tracker is 10 MB, the granularity of the memory quota application that its parent tracker can observe is 10 MB, and the parent tracker cannot see finer granularity.

[0071] The memory usage definition module can define the memory usage tracking mechanisms in single-threaded and multi-threaded scenarios respectively.

[0072] Furthermore, the operator-level fine-grained monitoring metrics in the single-threaded scenario include the current memory amount, historical peak value, cumulative allocation / release amount, and the distribution of allocation size histograms;

[0073] The global monitoring metrics in the multi-threaded scenario include the atomized current memory amount and historical peak value, supporting thread safety in a concurrent environment.

[0074] Specifically, it is defined only for single-threaded scenarios such as the operator operation MemoryUsage <operator>The memory usage tracking mechanism is actually to determine the memory usage monitoring indicators in the thread scenario, including tracking the current memory consumption (amount) and peak memory (peak). This system also includes a debugging module. Therefore, the memory statistics function is also extended in the debugging mode, such as recording the allocation size histogram, dividing the intervals into [0,32B], [32B,128B], [128B,512B], [512B,1KiB], [1KiB,4KiB], [4KiB,32KiB], [32KiB,+∞), tracking unpaired release operations and marking suspicious memory blocks, and generating a memory life cycle heat map to assist in leakage analysis. Among them, the debugging mode is mainly used to determine whether the system's memory usage meets expectations; it is defined for multi-threaded scenarios such as global or query-level MemoryUsage<Global |Query> The memory usage tracking mechanism is actually to determine the memory usage monitoring indicators in the thread scenario, including the atomic current memory consumption and historical peak value, and support thread safety in a concurrent environment.

[0075] Furthermore, the hybrid memory allocator module includes:

[0076] A general memory allocator that injects tracing logic into memory allocation and deallocation operations and records memory usage status;

[0077] STL-specific memory allocator, used to adapt standard containers through template specialization technology and inject customized tracking logic into container memory operations.

[0078] Two allocators, Allocator and StlAllocator, are set in the hybrid memory allocator module. Among them, Allocator is a general memory allocator, which is associated with a specific memory tracker through the createFrom method, and provides allocate, reallocate, and deallocate methods to record memory usage in conjunction with the memory tracker. The allocate method is used to allocate memory of a specified size and record the amount of allocated memory in the memory tracker. The reallocate method is used to reallocate memory and update the records in the memory tracker. The deallocate method is used to release the specified memory and update the records in the memory tracker.

[0079] StlAllocator is an STL-specific allocator used in C++ standard library STL containers. When a large number of STL structures are used in the execution engine layer of the graph database system, this allocator can be used as a direct replacement for the default allocator of the C++ standard library STL. It also records memory allocation and release based on the current memory tracker, and mainly provides allocate and deallocate methods.

[0080] That is, when the STL structure is referenced in the graph database system, StlAllocator is used for memory allocation and release; while when the STL structure is not referenced in the graph database system but memory needs to be allocated, such as some data structures for storing in-memory graphs and in-memory tables, Allocator is used for memory allocation and release.

[0081] It should be particularly noted here that when calling the allocate method to record the amount of memory already allocated in the memory tracker, since the statistical path is reported level by level upwards, if the reserved memory at a certain level meets its current memory application amount, there is no need to report upwards, but directly deduct from the reservation. After all, the reserved memory at this time is the amount that has been applied from its parent tracker before, and the parent tracker knows the use of this part of the memory.

[0082] This embodiment reduces the possibility that the usage counter of the parent memory tracker becomes a bottleneck through the hierarchical memory tracker and the reservation mechanism, improving the efficiency of memory allocation and release; also in a multi-threaded scenario, the thread safety in the concurrent scenario of memory usage statistics is ensured by using an atomic counter.

[0083] Furthermore, the system also includes a benchmark test module for timing and counting the memory allocation and release operations according to test cases to determine the system performance.

[0084] This system also provides performance verification, which is mainly implemented through the benchmark test module. The purpose of performance verification is to comprehensively and accurately evaluate the performance of the memory allocation and release operations in this embodiment. Through benchmark testing, the performance differences under different memory management methods can be quantified, providing data support for the effectiveness and superiority of this embodiment. Specifically, the embodiments of the present disclosure focus on the latency and throughput metrics during the memory allocation and release processes to measure the performance of this solution in actual applications.

[0085] During benchmark testing, a series of test cases were designed, covering different memory allocation sizes from 8 bytes to 4KB to comprehensively evaluate the performance of this embodiment in different scenarios. And each test case contains an allocation operation and a release operation, which are measured as a basic operation unit.

[0086] During benchmark testing, two sets of comparative tests were also conducted. One is the default group, that is, the test results obtained by making malloc / free calls using the system's default memory application and release scheme, and the other is the tracked group, which are the test results obtained by operating the allocate / deallocate of the allocator after enabling the memory tracker.

[0087] As Figure 2 shown, the test results in terms of latency indicate that when a memory tracker is added to the memory allocation code path, the latency of the allocation operation increases by approximately 1 nanosecond (ns) on average. This result shows that although the introduction of the memory tracker has a certain impact on performance, this impact is within an acceptable range. Through detailed analysis, it is found that this increase in latency is mainly due to the fact that the memory tracker requires additional operations to record memory allocation information, thus increasing a certain amount of overhead.

[0088] As Figure 3 shown, for the default system malloc / free calls and the allocator operations with the memory tracker enabled, when the allocation size exceeds 256 bytes, the throughput of both reaches the limit of the memory bandwidth (the memory bandwidth of the processor is generally between 50GB / s - 100GB / s). This indicates that in the scenario of larger memory allocations, the performance of this embodiment is comparable to that of traditional memory management methods and will not have an obvious impact on the overall performance of the system.

[0089] At the same time, this embodiment also realizes refined memory usage statistics, such as being able to count the memory usage of operators at the execution layer, and memory usage control at the query level, such as setting its maximum available memory to 102,400 bytes. These are all capabilities that the system default memory application and release scheme do not have.

[0090] Through benchmark tests, the performance of this solution in memory allocation and release operations is verified. The test results show that while ensuring the effectiveness and reliability of fine-grained memory management, the impact of this embodiment on system performance is also within an acceptable range. And in the scenario of larger memory allocations, the throughput of this embodiment is comparable to that of traditional memory management methods, demonstrating its feasibility and superiority in practical applications.

[0091] This embodiment also clarifies the performance impact of adding a hierarchical memory tracker to the allocation code path and the throughput characteristics of different allocators through benchmark tests, enabling developers to select appropriate allocators according to specific requirements.

[0092] The above-described embodiments only represent several implementation manners of the present invention. Their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present invention, several modifications and improvements can still be made, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the present invention patent shall be subject to the appended claims.< / operator> < / rpc> < / operator> < / query> < / global> < / operator> < / rpc> < / query> < / global>

Claims

1. A hierarchical graph database in-memory management system, characterized in that, including: a hierarchical memory tracker module that organizes multi-level memory trackers using a tree-like hierarchical architecture, where each level of memory tracker has a built-in reservation mechanism for elastic allocation of memory resources according to hierarchical reservation information; a memory usage definition module for generating differentiated memory monitoring metrics based on thread scenario characteristics, including operator-level fine-grained monitoring metrics in single-thread scenarios and global monitoring metrics in multi-thread scenarios; a hybrid memory allocator module that integrates the hierarchical monitoring logic of the hierarchical memory tracker module to obtain the memory status in real time and dynamically perform memory allocation and recycling operations according to the hierarchical reservation information; wherein, the hierarchical memory tracker module includes: a global memory tracker, as the root node, managing the global memory limit and usage, and triggering a memory allocation exception when the total memory usage exceeds the global memory limit; a query memory tracker, mounted as a child node under the global memory tracker, having a configurable maximum reserved memory and an optional maximum usable memory limit, and supporting dynamic memory application from the parent level; an operator memory tracker, as a child node of the query memory tracker, with a configurable smaller maximum reserved memory, and obtaining memory resources using a multi-level parent application mechanism; a network memory tracker, mounted as a child node under the global memory tracker, for memory management of remote procedure calls, with an independently configurable maximum reserved memory and maximum usable memory limit, and supporting dynamic memory application from the parent level.

2. The hierarchical graph database memory management system according to claim 1, wherein The maximum usable memory limit of the query memory tracker can be dynamically adjusted through session configuration or query parameters, and a cascaded memory release is triggered when the cumulative application amount of the child tracker exceeds the maximum usable limit.

3. The hierarchical graph database memory management system according to claim 1, wherein The reservation mechanism includes: When performing memory allocation, the child tracker preferentially uses local reserved memory, and when the local reserved memory is insufficient, it applies for the maximum reserved memory block from its parent; When performing memory release, the child tracker first judges whether the sum of the local reserved memory and the memory release amount exceeds the local maximum reserved memory. If it exceeds, it returns the maximum reserved memory block to its parent.

4. The hierarchical graph database memory management system according to claim 3, characterized in that The reservation mechanism also includes setting different reservation granularities at different levels to balance application efficiency and monitoring accuracy.

5. The hierarchical graph database memory management system according to claim 4, characterized in that, The reservation application adopts a batch pre-allocation strategy, and the single application amount of the operator-level tracker is its maximum reserved memory value.

6. The hierarchical graph database in-memory management system according to claim 1, wherein, The operator-level fine-grained monitoring metrics in single-thread scenarios include the current memory amount, historical peak value, cumulative allocation / release amount, and distribution of allocation size histograms; The global monitoring metrics in multi-thread scenarios include the atomized current memory amount and historical peak value, supporting thread safety in a concurrent environment.

7. A hierarchical graph database in-memory management system according to claim 1, characterized in that, The hybrid memory allocator module includes: a general memory allocator for injecting tracking logic into memory allocation and release operations and recording the memory usage status; an STL-specific memory allocator for adapting standard containers through template specialization technology and injecting customized tracking logic into container memory operations.

8. A hierarchical graph database in-memory management system according to claim 1, characterized in that, The system also includes a debugging module for judging whether the memory usage meets the expectations.

9. The hierarchical graph database in-memory management system according to claim 1, wherein The system also includes a benchmark testing module for timing and counting memory allocation and release operations according to test cases to determine the system performance.

Images