Staged out-of-memory avoidance module for a database system
The staged OOM Avoidance module for database systems addresses memory pressure by rejecting new connections, prioritizing memory-intensive components, and dynamically resizing the buffer pool, ensuring efficient memory management and preventing system crashes.
Patent Information
- Application Number
- PCT/IB2023/057458
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-07-21
- Publication Date
- 2025-01-30
AI Technical Summary
Database systems face challenges in managing memory efficiently during high memory pressure, leading to potential system crashes or performance degradation.
A staged Out-Of-Memory (OOM) Avoidance module that progressively addresses memory pressure by rejecting new connections and queries, identifying and prioritizing memory-intensive components, dynamically resizing the buffer pool, and releasing CPU resources to optimize memory release.
Effectively manages memory pressure by prioritizing memory-intensive components, dynamically resizing the buffer pool, and releasing CPU resources, thereby preventing system crashes and maintaining performance during high memory usage.
Description
[0001] Staged Out-Of-Memory Avoidance Module for a Database System
[0002] Here in this invention, we have a staged Out-Of-Memory (OOM) Avoidance module for a database system. When there is memory pressure, the first stage of OOM Avoidance module rejects new database connection requests and new queries by existing database connections. Further after execution of the first stage of OOM Avoidance module of the database system, if the memory pressure persists, then in the second stage we identify which database component is consuming most amount of memory with the help of memory profiling threads (like if jemalloc is used then perform jemalloc memory profiling). For example the purge subsystem or component of the database might be consuming more memory to clean up or garbage collect stale data and hence to accelerate the above we may yield the CPU (Central Processing Unit) to the purge threads of the database system along with aborting current active transactions (skipping long running transactions) to fast track the release of memory pressure. Further after execution of the second stage of OOM Avoidance module of the database system, if the memory pressure persists, then in the third stage we dynamically resize the buffer pool of the database system to a smaller size so that other threads of the database system (apart from query processing threads which use buffer pool) have enough memory to execute their tasks. Note after the memory pressure is released, we can dynamically resize the buffer pool of the database system to its original size and start accepting new database connection requests and new queries of existing database connections.
Claims
Following are the claims for this invention1. Here, we have a staged Out-Of-Memory (OOM) Avoidance module for a database system. When there is memory pressure, the first stage of OOM Avoidance module rejects new database connection requests and new queries by existing database connections.
2. Further after execution of the first stage of OOM Avoidance module of the database system, if the memory pressure persists, then in the second stage we identify which database component is consuming most amount of memory with the help of memory profiling threads (like if jemalloc is used then perform jemalloc memory profiling).
3. For example the purge subsystem or component of the database might be consuming more memory to clean up or garbage collect stale data and hence to accelerate the above we may yield the CPU (Central Processing Unit) to the purge threads of the database system along with aborting current active transactions (skipping long running transactions) to fast track the release of memory pressure.
4. Further after execution of the second stage of OOM Avoidance module of the database system, if the memory pressure persists, then in the third stage we dynamically resize the buffer pool of the database system to a smaller size so that other threads of the database system (apart from query processing threads which use buffer pool) have enough memory to execute their tasks.
5. Note after the memory pressure is released, we can dynamically resize the buffer pool of the database system to its original size and start accepting new database connection requests and new queries of existing database connections.