A memory management method and system for a database
Patent Information
- Application Number
- CN202611107345.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-24
- Publication Date
- 2026-10-23
AI Technical Summary
然而,该方法具有显著的滞后性
(1)在内存检测方面,实现了从进程级到页级的细粒度监控。通过利用数据库管理系统的扩展接口和系统视图,能够采集数据页的访问频率和最近访问时间,并基于最近最少使用算法计算各数据页的权重,从而精确识别热点数据页。相较于现有技术仅能获取进程级内存占用,本申请方案可区分数据库内部不同组件的内存消耗,定位高频访问的具体数据页,为缓存优化提供更准确的依据。
Smart Images

Figure CN122963785A_ABST
Abstract
Description
Technical Field
[0001] Applications generally relate to the field of database technology, and in particular to a database memory management method and system. Background Technology
[0002] Currently, database memory management mainly relies on the following three types of methods.
[0003] The first approach involves using operating system-level monitoring tools to obtain the overall memory usage of the server. However, these tools can only monitor process-level memory usage and cannot differentiate the specific memory consumption of different components within the database, such as query operations, transaction processing, and caching. When the database's shared buffer usage is too high, administrators cannot use these tools to identify which queries or transactions are causing the memory pressure.
[0004] The second approach utilizes the database's built-in monitoring capabilities to provide information on the backend processes of the current connection and some memory metrics. However, this type of monitoring still offers relatively coarse-grained monitoring, making it difficult to deeply analyze the dynamic changes in memory allocation. For example, it cannot track the details of temporary memory allocation in the query's working memory for a single query.
[0005] The third type of method is log backtracking analysis, which locates memory problems by parsing error messages in database logs. However, this method has a significant time lag. When a complex query fails to execute due to insufficient memory, administrators need to manually retrieve the logs to locate the problem, and real-time alerts cannot be provided during the query execution process.
[0006] In summary, existing database memory management technologies generally suffer from low detection accuracy and poor real-time performance. Specifically, existing tools cannot distinguish the memory consumption of individual components within the database, nor can they accurately track access frequency and memory usage at the data page level; log analysis requires waiting for problems to occur before backtracking, making it difficult to provide real-time alerts when memory usage approaches thresholds. Furthermore, adjusting memory-related parameters mainly relies on manual experience, lacking data-driven adaptive optimization methods, which can easily lead to insufficient or wasted memory resources.
[0007] Based on the above problems, there is an urgent need for a closed-loop management solution that can achieve fine-grained memory monitoring, adaptive parameter optimization, and real-time leak detection, so as to improve the efficiency of database memory management and system stability. Summary of the Invention
[0008] This disclosure addresses some of the shortcomings mentioned in the background art by providing a database memory management method and system.
[0009] In a first aspect, embodiments of this disclosure provide a database memory management method, comprising the following steps: By utilizing the extended interface and system view of the database management system, the access frequency and recent access time of data pages are collected, and hot data pages are identified accordingly; and by parsing the write-ahead log of the database management system, the transaction status is obtained, and memory leaks are detected based on the memory allocation and release records of the transactions. A reinforcement learning model is constructed, and multi-dimensional state indicators, including cache hit rate and query latency, are input into the reinforcement learning model to obtain adjustment values for the memory configuration parameters of the database management system, and these adjustment values are applied. The changes in the performance metrics of the database management system after applying the adjusted values are obtained, the optimization effect is evaluated, and the results are fed back to the reinforcement learning model to update the model parameters.
[0010] In one embodiment of the first aspect, the step of collecting the access frequency and recent access time of data pages using the extended interface and system view of the database management system further includes: The system view collects data page information at a preset frequency through a background process. The data page information includes at least the page number, access count, and last access time. The data in the system view comes from an enabled extended interface for recording and querying memory allocation details.
[0011] In one embodiment of the first aspect, the step of identifying hotspot data pages further includes: Based on the Least Recently Used algorithm, the number of accesses and the timeliness factor determined by the time interval between the current time and the last access time are weighted and calculated to obtain the weight of each data page. A hotspot distribution map is generated based on the weights, and the data pages accessed frequently are marked as hotspot data pages.
[0012] In one embodiment of the first aspect, the step of obtaining the transaction status by parsing the write-ahead log of the database management system and detecting memory leaks based on the transaction's memory allocation and release records further includes: Parse log entries in the write-ahead log directory to extract transaction identifiers and operation types, including commit and abort; Construct a transaction lifecycle timeline to record memory allocation and release events for each transaction; The transaction identifier is associated with the memory allocation record. When it is detected that the transaction status of any transaction is aborted and that the transaction has allocated but not released memory blocks, the memory block is identified as a leak candidate.
[0013] In one embodiment of the first aspect, the reinforcement learning model is a dual deep Q-network model, comprising a target network and a policy network; The multidimensional status indicators include cache hit rate, average query latency, memory fragmentation index, and number of active connections; The adjustment value is an action value that makes discrete adjustments to the parameters of working memory, maintenance working memory, and shared buffer.
[0014] In one embodiment of the first aspect, the reinforcement learning model is updated during training based on a reward function, and the value of the reward function is determined by a weighted calculation based on three factors: changes in cache hit rate, the ratio of the current query latency to the baseline latency before parameter adjustment, and the exponential growth of memory fragmentation.
[0015] In one embodiment of the first aspect, the step of applying the adjustment value further includes: The configuration after applying the adjusted values was simulated in an isolated sandbox environment to verify its impact on query performance and memory usage. After successful verification, the configuration corresponding to the adjusted value is dynamically loaded through the database configuration reload mechanism without restarting the database management system.
[0016] In one embodiment of the first aspect, the step of evaluating the optimization effect further includes: Compare the changes in the number of temporary files and query response time before and after applying the adjusted values; If the number of temporary files decreases and the query response time shortens, the optimization is deemed effective.
[0017] In one embodiment of the first aspect, it further includes: By using a long short-term memory network model, based on the amount of historical backup data, the number of concurrent transactions, and the distribution characteristics of data types, the memory requirements for future periods are predicted to help determine the adjustment range of the memory configuration parameters.
[0018] In a second aspect, embodiments of this disclosure provide a database memory management system, employing a database memory management method as described in the first aspect, comprising: The memory detection module is used to obtain the access frequency and recent access time of data pages by utilizing the extended interface and system view of the database management system, so as to identify hot data pages and detect memory leaks by parsing the write-ahead log and transaction status. The parameter optimization module is used to input multi-dimensional state indicators, including cache hit rate and query latency, into a pre-built reinforcement learning model to obtain and apply the adjusted values of memory configuration parameters. The closed-loop feedback module is used to obtain the changes in database performance indicators after applying the adjusted values, evaluate the optimization effect, and feed it back to the reinforcement learning model to update its model parameters.
[0019] This disclosure proposes a database memory management method and system, which has the following beneficial effects: (1) In terms of memory detection, fine-grained monitoring from the process level to the page level is achieved. By utilizing the extended interface and system view of the database management system, the access frequency and recent access time of data pages can be collected, and the weight of each data page can be calculated based on the least recently used algorithm, thereby accurately identifying hot data pages. Compared with the existing technology, which can only obtain process-level memory usage, the solution of this application can distinguish the memory consumption of different components within the database, locate the specific data pages with high frequency of access, and provide a more accurate basis for cache optimization.
[0020] (2) In terms of memory leak detection, the real-time performance of detection is significantly improved. By parsing the write-ahead log to obtain transaction status information and constructing a transaction lifecycle timeline, and associating the transaction identifier with memory allocation records, memory leaks can be determined in real time when a transaction is abnormally terminated and there are unreleased memory blocks. Compared with the existing technology that relies on log backtracking analysis and has the lag problem of waiting for the problem to occur before it can be located, the solution of this application achieves timely response to memory leak events.
[0021] (3) Regarding parameter optimization, data-driven adaptive adjustment is achieved, eliminating reliance on manual experience. By constructing a reinforcement learning model, multi-dimensional state indicators such as cache hit rate and query latency are used as inputs, and the output is the adjustment value for memory configuration parameters, which is dynamically applied after sandbox verification. Compared with the existing technology that sets parameters based on fixed empirical values, the solution in this application can continuously optimize memory parameter configuration according to the actual operating status of the database, thereby improving memory resource utilization while reducing query latency.
[0022] (4) In terms of overall architecture, a closed-loop management process integrating memory detection, parameter optimization, and effect feedback was constructed. By evaluating the changes in performance indicators after parameter adjustment and feeding the evaluation results back to the reinforcement learning model to update the model parameters, the optimization strategy can be continuously improved as the database operating status changes, thereby enhancing the automation level of database memory management and system stability. Attached Figure Description
[0023] Figure 1 Here is a diagram of a database memory management system architecture according to this disclosure; Figure 2 This is a flowchart of a database memory management method according to the present disclosure. Detailed Implementation
[0024] The present application / disclosure will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application / disclosure and are not intended to limit the scope of the present application / disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present application / disclosure are shown in the accompanying drawings, not the entire structure.
[0025] Example 1 Figure 1 The system architecture of this database memory management system, as disclosed herein, includes a memory detection module 10, a parameter optimization module 20, and a closed-loop feedback module 30. Reference will be made below. Figure 1 This disclosure provides a detailed description of a database memory management system.
[0026] The memory detection module 10 is used to obtain the access frequency and recent access time of data pages by utilizing the extended interface and system view of the database management system, in order to identify hot data pages, and to detect memory leaks by parsing the write-ahead log and transaction status.
[0027] In this embodiment, the memory detection module 10 includes a page-level memory monitoring unit 110 and a memory leak detection unit 120, wherein, The page-level memory monitoring unit 110 uses the database's extended interface and system view to collect data page access information and identify hot data pages.
[0028] In this embodiment, the database extension interface can be, for example, the pg_stat_statements extension in a PostgreSQL database. This extension can generate a statistical record for each executed query statement, which includes details of memory allocation such as the number of hits on the shared buffers, the size occupied, and the execution time. The system view can be, for example, the pg_buffercache view in a PostgreSQL database. This view displays information about each data page currently residing in the shared buffer, on a page-by-page basis, including the page number, the relation it belongs to, and the number of times the page has been accessed.
[0029] In this embodiment, the memory detection module 10 uses a specially written background worker process (BackgroundWorker) to periodically query the pg_buffercache view at a preset frequency of seconds, and collects and caches data such as page number, access count and last access timestamp, providing raw data for subsequent hot spot analysis.
[0030] The memory leak detection unit 120 is used to detect memory leaks in real time by parsing the database's write-ahead logs and transaction status.
[0031] In this embodiment, the write-ahead log (WAL) is, for example, the WAL log entries in the pg_xlog directory of the PostgreSQL database. The memory detection module 10, by parsing these WAL log entries, can extract the transaction identifier (Transaction ID) and operation type. The operation type explicitly indicates whether the final state of the transaction is COMMIT or ABORT. During system operation, a memory allocation and release event record is maintained for each active transaction. The memory detection module 10 uses the transaction identifier as the association key to associate the final state of a transaction with all its memory operation history throughout its lifecycle, forming a complete timeline for each transaction. When the final state of a transaction is identified as ABORTED, the memory detection module 10 immediately searches the timeline of that transaction to check for any memory blocks that have been allocated to the transaction but have not been released by the time the transaction is aborted. If such memory blocks exist, they are explicitly identified as candidates for memory leaks.
[0032] The parameter optimization module 20 is used to build a reinforcement learning model. It inputs multi-dimensional state indicators, including cache hit rate and query latency, into the pre-built reinforcement learning model to obtain the adjustment value of the memory configuration parameters and applies the adjustment value.
[0033] In this embodiment, the reinforcement learning model specifically adopts the Double Deep Q-Network (DDQN) model. The structure of this model consists of two neural networks with the same structure but different parameter update frequencies. One is called the policy network (Q_policy), which is used to select actions in a given state; the other is called the target network (Q_target), which is used to evaluate the value of the actions. This dual network structure is designed to solve the problem of value overestimation in the traditional Q-learning algorithm.
[0034] In one embodiment, to train and infer the DDQN model, a complete state space, action space, and reward function are defined. The state space design incorporates various factors affecting database memory efficiency, ultimately forming a state vector with ten dimensions. These dimensions specifically include: buffer hit rate (buffer_hit_rate), used to measure the service efficiency of the shared cache; average query latency (avg_query_latency), reflecting the current system's response speed; memory fragmentation index (fragmentation_index), measuring the dispersion of memory space; and active connections (active_connections), representing the current system's concurrent load. In addition, the state vector also incorporates other metrics that indirectly reflect memory pressure, such as the number of temporary files (temp_files) generated and the frequency of checkpoint triggering. These metrics collectively constitute a representation of the database's operating state.
[0035] In one embodiment, the action space defines the tuning actions that the parameter optimization module 20 can take. The action space in this embodiment is designed as a set of discrete tuning operations, each corresponding to adjusting a specific database memory parameter to a specified value. These parameters include: single-operation working memory parameters, such as the `work_mem` parameter in a PostgreSQL database; maintenance operation working memory parameters, such as the `maintenance_work_mem` parameter; and shared buffer size parameters, such as the `shared_buffers` parameter. For each parameter, the selectable tuning target value is a preset discrete level. For example, for `work_mem`, selectable levels include 64MB, 128MB, 256MB, etc.; for the `maintenance_work_mem` parameter, selectable discrete tuning target values include 256MB, 512MB, 1GB; and for the `shared_buffers` parameter, selectable discrete tuning target values include 1GB, 2GB, 4GB.
[0036] In one embodiment, the design of the reward function directly determines the direction of model evolution. The reward function in this embodiment comprehensively measures the gains and costs of a single parameter adjustment. Specifically, the reward value calculation incorporates changes in three aspects: first, an increase in cache hit rate, which is a direct performance gain; second, a change in query latency, measured as the ratio of the current latency to the baseline latency before adjustment, with a smaller ratio indicating a more significant performance improvement; and third, a change in memory fragmentation. The specific formula for this reward function is: Formula (1) The baseline latency is defined as the average query latency before the current parameter adjustment action is executed; the fragmentation growth is defined as the difference between the memory fragmentation index after the adjustment and before the adjustment.
[0037] The formula for calculating the memory fragmentation index is: Formula (2) The design of the reward function makes the optimization objective of the model to improve the hit rate, reduce query latency, and suppress the growth of memory fragmentation.
[0038] In one embodiment, regarding model training and updating, this embodiment employs an update rule unique to the DDQN algorithm to iteratively optimize the neural network weights. This update rule decouples action selection from action value evaluation. When calculating the target Q-value of a state-action pair, the policy network first selects the action that maximizes its output value from all possible actions in the next state, and then the target network evaluates the value of performing this action. This approach effectively avoids the overestimation problem caused by directly using the maximum output of the target network for evaluation, resulting in a significant improvement in model convergence speed compared to traditional Q-learning. Specifically, the DDQN model update rule is as follows: Formula (3) As an example, the complete process of the parameter optimization module 20 performing dynamic adjustments includes three stages: model inference, sandbox validation, and production deployment. First, the parameter optimization module collects the status information of the backend writer through system views in the database, such as the `pg_stat_bgwriter` view in PostgreSQL. This includes buffer allocation counts (`buffers_alloc`) and backend write counts (`buffers_backend`), and combines this information with other data sources to construct a complete ten-dimensional state vector. Next, this state vector is input into the trained DDQN model. After forward inference, the model outputs a specific parameter adjustment suggestion, such as "It is recommended to adjust the `work_mem` parameter to 128MB". Before directly applying this adjustment to the production environment, the system first initiates a sandbox validation stage. This sandbox environment is a database test instance with the same configuration as the production environment but isolated from it. In this sandbox, the system simulates the application of the suggested parameter configuration and replays or runs a typical production query load to verify whether the adjusted configuration does indeed have a positive and effective impact on query performance and memory usage. Production deployment will only proceed after the sandbox verification process confirms that the adjustment is effective and poses no risk of degradation. During production deployment, the system uses the database's dynamic configuration reload mechanism, such as executing the PostgreSQL `pg_ctl reload` command, to load and apply the new parameter values. The entire process does not require restarting the database service, thus ensuring business continuity.
[0039] The closed-loop feedback module 30 is used to obtain the changes in database performance indicators after the application adjustment values, evaluate the optimization effect, and feed back to the reinforcement learning DDQN model to update its model parameters.
[0040] In this embodiment, during the optimization effect evaluation stage, the closed-loop feedback module 30 continuously monitors and compares key performance indicators before and after parameter adjustment. The main evaluation criteria include two indicators that directly reflect memory usage efficiency: one is the number of temporary files (temp_files) generated. This indicator is directly related to the rationality of parameter settings such as work_mem. If work_mem is set too small, the database will be forced to frequently write temporary data to temporary files on the disk. Therefore, a reduction in the number of temporary files indicates that the optimization action is effective. The second is the query response time, i.e., the time elapsed from initiating a query to returning a result. A shorter response time demonstrates an improvement in the overall system performance. The closed-loop feedback module 30 records the time of this adjustment, the specific parameters adjusted and their values before and after the change, as well as the quantitative improvement ratio of the above performance indicators, forming a structured optimization report.
[0041] In this embodiment, during the model iteration phase, the closed-loop feedback module 30 packages all the experience data generated during the current round of parameter optimization and feeds it back to the DDQN model as a training sample. This training sample specifically includes the following data: the state vector before parameter adjustment, the action selected by the parameter optimization module (i.e., which parameter was specifically adjusted and what its adjusted value is), the new state vector the system enters after parameter adjustment, and the actual reward value calculated according to the reward function formula. The DDQN model stores this training sample in the experience replay pool and extracts it for use in subsequent training batches to update the neural network weights of the policy network and the target network. Through this continuous feedback iteration, the DDQN model's understanding of various database operating states and the accuracy of its optimization decisions will continuously improve.
[0042] Example 2 Figure 2 To illustrate a database memory management method flowchart based on this disclosure, and its application to the system described above, reference will be made below. Figure 2 This disclosure provides a detailed description of a database memory management method.
[0043] Step 101: Using the extended interface and system view of the database management system, collect the access frequency and recent access time of data pages, and identify hot data pages accordingly; and obtain the transaction status by parsing the write-ahead log of the database management system, and detect memory leaks based on the memory allocation and release records of transactions.
[0044] In this embodiment, page-level memory monitoring and memory leak detection are implemented through two parallel sub-processes, respectively.
[0045] In one embodiment, within the page-level memory monitoring subprocess, the system administrator pre-enables the `pg_stat_statements` extension module for the PostgreSQL database. Once enabled, this extension continuously records execution statistics for each query received by the database, including key memory allocation details such as the size of the shared buffer (`shared_buffers`) and the number of hits. Simultaneously, a custom background worker process created by the system is periodically scheduled and executed at a rate of one second. This background worker process queries the `pg_buffercache` system view, and the query results set includes the page number of each data page in the current shared buffers, the cumulative number of times that page has been accessed, and the timestamp of the last access to that page. This collected raw data forms the basis for hotspot analysis.
[0046] In one embodiment, after data collection is complete, the system enters the hotspot analysis phase. The purpose of hotspot analysis is to accurately identify frequently accessed "hot data pages" from a massive amount of data pages that should be prioritized for caching. This embodiment uses a weighted formula based on the Least Recently Used (LRU) algorithm to quantify the popularity of each data page. The system calculates a comprehensive access weight for each data page, which takes into account both the frequency and timeliness of access. The specific calculation formula is as follows: Formula (4) The number of visits reflects the historical activity of a data page throughout the statistical period, serving as a long-term indicator of its importance. The (current time - last access time) value calculates the time interval since the page was last accessed, and its reciprocal becomes a timeliness factor. The shorter the interval, the larger the timeliness factor value. This penalizes pages with high historical access counts but long periods of inactivity, while rewarding recently accessed pages. The coefficients 0.7 and 0.3 in the formula represent the trade-off between long-term value and short-term timeliness. After calculating the weight of each data page using this formula, the system sorts all weights to generate a hotspot distribution map. In this map, high-weight index pages or transaction log pages are clearly marked. These markings directly guide subsequent cache optimization strategies, such as increasing the residency priority of these hotspot pages in the shared cache.
[0047] In one embodiment, in the memory leak detection subprocess, the system identifies unreleased memory blocks in real time based on the transaction lifecycle. First, the system starts a log parsing process that continuously reads and parses entries in the Write-Ahead Log (WAL) file located in the pg_xlog subdirectory of the PostgreSQL data directory. From each log entry, the parsing process extracts two key fields: the transaction identifier (Transaction ID) and the operation type. The operation type explicitly records whether a transaction was successfully committed (COMMIT) or aborted (ABORT). Simultaneously, during normal database operation, the memory management component records the logs of each memory block allocation and release, noting which transaction identifier triggered the operation. The system correlates these two information flows to construct a transaction lifecycle timeline for each active transaction. This timeline records all events of the transaction in chronological order, from its start, memory allocation, to its end (commit or abort).
[0048] Based on this transaction lifecycle timeline, the system executes explicit leak detection logic: the system checks each completed transaction, and if a transaction's status is found to be ABORTED (abnormally terminated), it immediately examines the memory allocation and deallocation records in the corresponding transaction's lifecycle timeline. If it finds memory blocks that have been allocated but have no corresponding deallocation records, the system determines that these memory blocks are leaky blocks that failed to be properly reclaimed due to the abnormal termination of the transaction. This detection method does not require waiting for the system to report an explicit out-of-memory error, nor does it require administrators to search logs afterward; it can proactively detect leaks immediately after a transaction is terminated.
[0049] Step 102: Construct a reinforcement learning model. Input multi-dimensional state indicators, including cache hit rate and query latency, into the reinforcement learning model to obtain adjustment values for the memory configuration parameters of the database management system, and apply these adjustment values.
[0050] In this embodiment, a Dual Deep Q-Network (DDQN) model is used. During the model construction phase, the state space is defined as a state vector composed of ten dimensions, which cover cache hit rate, average query latency, memory fragmentation index, number of active connections, and other indicators such as the number of temporary files and checkpoint frequency. The action space is defined as a set of discrete adjustment actions for the three parameters work_mem, maintenance_work_mem, and shared_buffers. The reward function and memory fragmentation index are calculated according to formulas (1) and (2). During training, the DDQN model uses its unique update rule to avoid overestimation of value. This rule can be expressed as: the target Q-value equals the immediate reward plus a discount factor multiplied by the target network's value assessment of the next state and the optimal action selected by the policy network. This mechanism of separating selection and evaluation significantly improves the model's convergence speed compared to traditional Q-learning.
[0051] In one embodiment, after the model is built, it enters the online dynamic tuning process. The system collects data in real time, obtaining status indicators such as buffers_alloc and buffers_backend of the backend writer through the pg_stat_bgwriter view, and combines this with other data sources to generate a complete ten-dimensional state vector representing the current database operating status. This state vector is input into the trained DDQN model for inference operations, and the model outputs a specific parameter adjustment suggestion, such as suggesting that work_mem be adjusted from the current 64MB to 128MB. The system does not immediately push this suggestion to the production environment, but first starts sandbox verification. In a test database isolated from the production environment, the system applies the adjustment suggestion, simulates production load for performance testing, and verifies the actual impact of the adjustment on query performance and memory usage. Only when the sandbox verification results confirm that the action brings positive effects or does not cause performance degradation will the system enter the actual deployment stage. During production deployment, the system calls the PostgreSQL pg_ctl reload command, which sends a signal to the database master process to reread and load the new parameter values in the configuration file. The entire process does not interrupt the database service and is imperceptible to online business operations.
[0052] In step 103, the changes in the performance indicators of the database management system after the application adjustment value are obtained, the optimization effect is evaluated and fed back to the reinforcement learning model to update the model parameters.
[0053] In this embodiment, during the optimization effect evaluation phase, the system uses a comparative analysis to focus on the changes in two key metrics: the number of temporary files (temp_files) and query response time before and after parameter adjustments. If the number of temporary files significantly decreases after adjustment, it indicates that due to the reasonable adjustment of parameters such as work_mem, data that was previously forced to be written to disk temporary files due to insufficient working memory can now be processed in memory. If the query response time is significantly shortened, this directly demonstrates an improvement in the overall system performance. Based on this, the system generates an optimization report containing details such as adjustment time, parameter values before and after adjustment, and quantitative changes in performance metrics.
[0054] In one embodiment, during the model iteration phase, the system feeds back the empirical data generated throughout the entire adjustment cycle—namely, the pre-adjustment state, the actions performed, the post-adjustment state, and the actual reward value calculated based on the reward function—as a complete training sample to the DDQN model. The model uses this sample to update its neural network weights, thereby continuously enhancing its ability to fit the mapping relationship between the database state and the optimal tuning strategy.
[0055] As an example, the system also integrates a deep learning-based prediction function to enhance the ability to predict and respond to periodic load fluctuations. Specifically, the system includes a prediction model based on Long Short-Term Memory (LSTM) networks. This LSTM prediction model is designed to receive a series of time-related external features as input, including: the historical backup data size (backup_size), the number of concurrent transactions (active_connections), and the distribution of specific data types, such as the proportion of JSONB data in all data. After learning the input feature sequence, the LSTM model outputs a predicted value for the total database memory requirement over a future period. This predicted value can be used as prior knowledge or a constraint, input into the parameter optimization module to help determine the adjustment range of the DDQN model's output action, or to preemptively call the parameter optimization process to expand resources before predicting an upcoming load peak, thereby further improving the system's stability under complex load environments. Experiments show that the prediction error rate of this LSTM prediction model can be controlled below 5%.
[0056] This disclosure provides a database memory management method and system. By integrating a memory detection module, a parameter optimization module, and a closed-loop feedback module into a unified whole, it successfully improves the precision of memory management from the traditional process level to the data page level; it switches the parameter optimization method from relying on manual experience to data-driven reinforcement learning; and it shifts the detection timeliness of memory leaks from post-event retrospective to real-time perception based on transaction logs. This significantly reduces the manpower costs of database operation and maintenance, improves the stability and responsiveness of database services, and is particularly suitable for industries such as finance and telecommunications that have strict requirements for high availability and real-time monitoring compliance of databases.
[0057] In a third aspect, embodiments of this disclosure provide an electronic device including a memory and a processor, wherein the memory stores a program that runs on the processor, and the processor, when running the program, performs the steps of a database memory management method as described in the second aspect. In a fourth aspect, embodiments of this disclosure provide a computer-readable storage medium having computer instructions stored thereon, which, when executed, perform the steps of a database memory management method as described in the second aspect.
Claims
1. A database memory management method, characterized in that, Includes the following steps: By utilizing the extended interface and system view of the database management system, the access frequency and recent access time of data pages are collected, and hot data pages are identified accordingly; and by parsing the write-ahead log of the database management system, the transaction status is obtained, and memory leaks are detected based on the memory allocation and release records of the transactions. A reinforcement learning model is constructed, and multi-dimensional state indicators, including cache hit rate and query latency, are input into the reinforcement learning model to obtain adjustment values for the memory configuration parameters of the database management system, and these adjustment values are applied. The changes in the performance metrics of the database management system after applying the adjusted values are obtained, the optimization effect is evaluated, and the results are fed back to the reinforcement learning model to update the model parameters.
2. The database memory management method according to claim 1, characterized in that, The step of collecting the access frequency and recent access time of data pages using the extended interface and system view of the database management system further includes: The system view collects data page information at a preset frequency through a background process. The data page information includes at least the page number, access count, and last access time. The data in the system view comes from an enabled extended interface for recording and querying memory allocation details.
3. The database memory management method according to claim 2, characterized in that, The step of identifying hot data pages further includes: Based on the Least Recently Used algorithm, the number of accesses and the timeliness factor determined by the time interval between the current time and the last access time are weighted and calculated to obtain the weight of each data page. A hotspot distribution map is generated based on the weights, and the data pages accessed frequently are marked as hotspot data pages.
4. The database memory management method according to claim 2, characterized in that, The step of obtaining transaction status by parsing the write-ahead log of the database management system and detecting memory leaks based on the memory allocation and release records of the transactions further includes: Parse log entries in the write-ahead log directory to extract transaction identifiers and operation types, including commit and abort; Construct a transaction lifecycle timeline to record memory allocation and release events for each transaction; The transaction identifier is associated with the memory allocation record. When it is detected that the transaction status of any transaction is aborted and that the transaction has allocated but not released memory blocks, the memory block is identified as a leak candidate.
5. The database memory management method according to claim 1, characterized in that, The reinforcement learning model is a dual-deep Q-network model, which includes a target network and a policy network; The multidimensional status indicators include cache hit rate, average query latency, memory fragmentation index, and number of active connections; The adjustment value is an action value that makes discrete adjustments to the parameters of working memory, maintenance working memory, and shared buffer.
6. A database memory management method according to claim 5, characterized in that, The reinforcement learning model is updated during training based on a reward function. The value of the reward function is determined by a weighted calculation based on three factors: changes in cache hit rate, the ratio of the current query latency to the baseline latency before parameter adjustment, and the exponential growth of memory fragmentation.
7. A database memory management method according to claim 1 or 5, characterized in that, The step of applying the adjusted value further includes: The configuration after applying the adjusted values was simulated in an isolated sandbox environment to verify its impact on query performance and memory usage. After successful verification, the configuration corresponding to the adjusted value is dynamically loaded through the database configuration reload mechanism without restarting the database management system.
8. A database memory management method according to claim 1 or 5, characterized in that, The step of evaluating the optimization effect further includes: Compare the changes in the number of temporary files and query response time before and after applying the adjusted values; If the number of temporary files decreases and the query response time shortens, the optimization is deemed effective.
9. A database memory management method according to claim 1, characterized in that, Also includes: By using a long short-term memory network model, based on the amount of historical backup data, the number of concurrent transactions, and the distribution characteristics of data types, the memory requirements for future periods are predicted to help determine the adjustment range of the memory configuration parameters.
10. A database memory management system, employing the database memory management method as described in claims 1-9, characterized in that, include: The memory detection module is used to obtain the access frequency and recent access time of data pages by utilizing the extended interface and system view of the database management system, so as to identify hot data pages and detect memory leaks by parsing the write-ahead log and transaction status. The parameter optimization module is used to input multi-dimensional state indicators, including cache hit rate and query latency, into a pre-built reinforcement learning model to obtain and apply the adjusted values of memory configuration parameters. The closed-loop feedback module is used to obtain the changes in database performance indicators after applying the adjusted values, evaluate the optimization effect, and feed it back to the reinforcement learning model to update its model parameters.