Dynamic Tiering Pools for Database Memory Management

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing database replication systems face inefficiencies due to fixed and non-shared pool/cache resources, leading to excessive memory usage and scalability issues, especially in cloud environments with multiple replication paths.

Innovation Solution

Implementing dynamic tiering pools that are sharable across multiple clients/servers and adaptable in size based on workload, using a hierarchical model with a global and local pool structure, and incorporating aging and lock-free mechanisms for efficient memory management.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If fixed-size pools or caches are pre-allocated for each replication path, then data integrity and consistency are maintained, but memory usage becomes excessive and scalability is impeded

Engineering Contradiction:
Improvedata integrityVSAvoidmemory usage
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The patent implements a shared pool model where a single pool of memory resources serves multiple replication paths simultaneously, rather than allocating dedicated pools to each path. This universal pool is managed through reference counting mechanisms that allow multiple replication operations to share the same underlying memory resources, thereby reducing total memory consumption while maintaining data integrity through proper reference management.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent introduces dynamic pool management where the size and allocation of memory pools can change over time based on workload demands. Pools can be created, expanded, shrunk, and destroyed dynamically rather than being fixed in size. This dynamic behavior allows the system to adapt memory usage to actual replication needs, preventing both memory waste and insufficient resources.

Inventive Principle:
Principle #15Dynamics

2Reliability

If fixed-size pools are pre-allocated for each replication path, then data consistency is ensured, but the system cannot adapt when workload volume changes

Engineering Contradiction:
Improvedata consistencyVSAvoidworkload adaptability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent implements dynamic pool management where pools can be created, expanded, shrunk, and destroyed based on workload demands. The system monitors replication activity and automatically adjusts pool sizes and lifecycles accordingly, allowing the same pool infrastructure to handle both light and heavy workloads efficiently while maintaining data consistency through proper reference counting.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent changes the parameters of pool management from fixed to variable, allowing pool size, lifetime, and allocation characteristics to be dynamically adjusted based on replication workload conditions. This includes creating pools on-demand, expanding them when needed, and destroying them when no longer required, rather than maintaining static pool configurations.

Inventive Principle:
Principle #35Parameter changes

3Reliability

If separate pools are dedicated to each replication path, then data integrity is maintained, but resource utilization becomes inefficient

Engineering Contradiction:
Improvedata integrityVSAvoidresource utilization efficiency
Core Design Contradiction:
ReliabilityVSLoss of energy

Solution Approach 1:

The patent creates a universal pool infrastructure where the same memory resources can be shared across multiple replication paths simultaneously. Through reference counting and shared pool management, a single pool can serve multiple replication operations, eliminating the need for separate dedicated pools and thereby improving resource utilization efficiency while maintaining data integrity through proper reference management.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent merges multiple separate pool allocations into a single shared pool that serves multiple replication paths. By combining previously separate resources into a unified pool managed through reference counting, the system achieves better resource utilization while maintaining the isolation and integrity requirements of individual replication paths.

Inventive Principle:
Principle #5Merging (Combining)

4Device complexity

If fixed pools are used for each replication path, then implementation simplicity is maintained, but scalability to cloud environments is impeded

Engineering Contradiction:
Improveimplementation simplicityVSAvoidscalability
Core Design Contradiction:
Device complexityVSProductivity

Solution Approach 1:

The patent introduces dynamic pool management that automatically adapts to workload conditions, enabling the system to scale efficiently in cloud environments with multiple replication paths. The dynamic creation, expansion, and destruction of pools based on actual needs allows the system to handle variable workloads without manual intervention, achieving both scalability and operational simplicity.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS10929035B2Memory management via dynamic tiering pools
Publication Date: 2021.02.23 SAP SE
  • US10929035B2 patent drawing
  • US10929035B2 patent drawing
  • US10929035B2 patent drawing

AI summary

Disclosed herein are system, method, and computer program product (computer-readable storage medium) embodiments for implementing memory management via dynamic tiering pools. An embodiment operates by initializing a first memory pool of a first tier, and invoking first and second function calls to allocate memory to the first memory pool. Responsive to these function calls, an OS may allocate differently-sized memory elements for attachment to the first memory pool, from a memory free store managed by the OS. A second memory pool, of a second tier, may be further initialized, and a third function call may be invoked, to allocate memory to the second memory pool. Here, in response to the third function call, the first memory pool may reallocate the second memory element from the first memory pool for attachment to the second memory pool.