Patent Description:
Generally, database servers cache data pages, query execution plans, column store entries, locks, security tokens, and other data items to improve performance. In some scenarios, cache memory usage persists, even in the absence of an active user workload. This may have a negative cost impact for the serverless model. <CIT> describes methods and apparatus, including computer program products, that implement cache eviction for runtime systems. <CIT> describes efficiently determining which cache entries are to be evicted from memory and to incorporating a probability of reuse estimation in a cache entry eviction determination. <CIT> describes a system for policy based workload scaler includes a parameters engine to define external factors for a number of resources providing a number of cloud service workloads, a threshold engine to define a threshold value for the cloud service workloads from the number of resources, a priority engine to assign a priority to each of the number of cloud service workloads, and a service engine to reclaim resources from a first portion of cloud service workloads with a first priority and allocate the reclaimed resources to a second portion of cloud service workloads when the threshold value is exceeded and the external factors are exceeded.

Some aspects disclosed herein are directed to a solution for memory management of serverless databases that includes: detecting a trigger event for reclaiming memory from a serverless database instance; based at least on detecting the trigger event, determining whether memory is to be reclaimed; based at least on determining that memory is to be reclaimed, determining an amount of memory to be reclaimed; identifying memory to be reclaimed; and reclaiming the identified memory.

The various examples will be described in detail with reference to the accompanying drawings. References made throughout this disclosure relating to specific examples and implementations are provided solely for illustrative purposes but, unless indicated to the contrary, are not meant to limit all examples.

Some database instances tend to proactively cache data pages in a buffer pool, query execution plans, column store entries and segments, session information, security tokens, locks, and other data items, to improve performance. Traditionally, some relational databases have been designed to cache as much data as possible, since caching more objects generally helps (rather than hurting) performance. Such implementations typically evict cached objects only when there is memory pressure, such as when memory limits are reached or memory usage exceeds a threshold. Eviction for buffer pool pages is based on the LRU-<NUM> algorithm, in some examples. However, in the context of serverless databases where using more memory also incurs a higher monetary cost to the customer, the above approach of caching as many objects as possible may have a negative cost impact. This negative cost impact may be exacerbated when cache memory is not reduced as the user workload decreases.

Aspects of the disclosure provide solutions for memory management of serverless databases that include: based at least on detecting a trigger event, determining whether memory is to be reclaimed; based at least on determining that memory is to be reclaimed, determining an amount of memory to be reclaimed; identifying memory to be reclaimed; and reclaiming the identified memory. Disclosed solutions are flexible, enabling customization of the aggressiveness and manner of memory reclamation. This permits users to specify a tailored balance point between performance and cost, for arrangements that bill users based on resource usage (e.g., memory consumed by a serverless database). In some examples, users can specify a ramp-down parameter that is used to determine how much memory can be evicted in a particular reclamation event, time intervals (or another criteria) for triggering a reclamation event, and a definition for whether a cache is active. In some examples, users can specify an active cache utilization threshold for triggering a reclamation event, such as a fraction of the aggregate size of active cache entries relative to aggregate size of all cache entries.

Aspects of the disclosure operate in an unconventional way to improve memory management for serverless databases by shrinking cache memory while mitigating performance impact. In some examples, the service automatically and transparently scales resources to satisfy workload demand and charges users predominantly for the amount of computing resources actually consumed. In some examples, a user of a serverless database does not have a persistent connection to a server instance. During a configurable or fixed time interval (e.g., <NUM> minutes), some examples evaluate overall cache activeness ratio (e.g., the fraction of pages that had been accessed during a prior interval, a. , the "active cache utilization"). With some implementations, the overhead for computing the cache activeness ratio (e.g., active cache utilization) and required statistics are minimal. If the active cache utilization is below a predefined threshold (e.g., <NUM>%, or a configurable threshold, in some examples), a target memory size is set for the caches, for example for the entire cache and/or different individual caches. The target memory size is either pre-calculated or, in some examples is configurable. Some examples include a machine learning (ML) based determination of the target memory size as another policy configuration. In some examples, the target memory size is either pre-calculated, or is configurable by user, or is determined by an ML algorithm that evaluates historical usage patterns to optimize price and performance trade-offs.

The external and internal caches, including buffer pool, large caches, plan/object caches, and others, are then shrunk in accordance with the target memory size. For example, at a configurable or fixed time interval (e.g., one hour, or another interval), user activity is examined for a prior time period (e.g., the immediately prior <NUM> minutes or another configurable time duration). If there had been no user activity, all caches are flushed, and the memory is shrunk to a predefined minimum memory limit, which is configurable in some examples. In some examples, there are two primary classes of triggers for cache reclamation: (<NUM>) If database activity is low for a configurable time period, then cache reclamation occurs in steps over time (typically gradually) to a predefined minimum cache size. (<NUM>) If database activity is rapidly goes to nothing (e.g., CPU usage caused by user operations is zero) for a configurable time period, then all caches are flushed and shrunk to a predefined minimum limit. The configurable parameters, values, and definitions described herein are tuned based on historical performance data with an ML component.

In some examples, the parameters of the serverless memory management policy are configurable per instance of a database, such that serverless databases instances can have different policy parameter values. The implementation and policy are both parameterized and are adaptable for different tenants' policies, in some examples. The configuration of these parameter values can be performed internally by the service provider and configuration permissions can also be extended to the user (e.g., customer owner) of the serverless database instance. This configuration flexibility applies to any of the configurable parameters described herein. Aspects of the disclosure generalize to multiple types of caches, regardless of cache eviction policy and statistics stored. In some examples, the cache type (e.g., buffer pool, plan cache, column store cache, and other cache types) included within the scope of the memory reclamation policy defaults to all cache types. However, in some examples, the memory management policy allows inclusions or exclusions of specific cache types.

Aspects of the disclosure may be generalized to other types of caches in other database engines beyond SQL or cloud services, such as, for example, database engines running in an on-premises deployment. That is, SQL instances are available for users to run both in on-premises environments and cloud service environments. The flexible resource allocation enables service providers to offer more capacity to customers and increases availability of the services. Additionally, the memory reclamation policy for serverless databases also enables billing users more closely aligned with the users' perception of actual usage. This is because, if cache memory wasn't reclaimed based on measures of low active cache utilization, cache memory usage could remain high over time even when database usage by the customer workload is low or non-existent. This would mean that user's bills for memory would not align with variations over time in database usage and the pricing model could potentially become unfavorable. Billing accurately for actual memory usage incents customers to balance price-performance trade-offs when configuring memory reclamation parameters.

Aspects of the disclosure include automatic cache reclamation so that an individual customer can configure it easily to strike the appropriate balance between their database's performance and cost requirements. In some examples, settings of the configuration parameters are initially targeted for buffer pool memory, which is the predominant consumer of memory in many Azure SQL databases. However, the serverless memory management policy can target all SQL caches, not just the buffer pool. This includes, but not limited to, the query plan cache and column storage cache which may also consume a significant fraction of total cache memory. Memory usage thus becomes more efficient so that users pay only for actively-used memory, rather than for memory that had been reserved but not actually used. In some examples, the trimming parameters are tailored by the user to adjust to the user's preference for aggressiveness, such as frequency, trigger sensitivity for starting a reclamation cycle, the maximum allowable amount of memory to trim per cycle, and the definition of "actively-used" memory such as the time elapsed since latest cache hit in order to be considered active.

In some examples, there are multiple deployment models available for users to select. For example, a user is able choose between creating a single database deployment model and pool deployment model in which a pool of multiple database instances shares memory resources from the same underlying database instance. In some scenarios, the pool model generally appeals to users employing multiple databases for a common application.

<FIG> illustrates an environment <NUM> that advantageously employs memory management for serverless databases. A database node <NUM> provides serverless databases as a cloud service to tenant environments <NUM>, <NUM> and others, across a network <NUM>. Database node <NUM> includes at least one processor <NUM> and a memory <NUM>. In some examples, the various components <NUM>-<NUM> shown for database node <NUM> reside within memory <NUM> and form various portions of data 912a and instructions 912b of <FIG>. Processor <NUM>, memory <NUM>, and network <NUM> are described in further detail in relation to <FIG>.

Database node <NUM> has a database engine <NUM>, which includes data and computer-executable instructions that, upon execution, provide for serverless database instances <NUM> and <NUM>, although a different number of instances may exist. In operation, a user node <NUM> within tenant environment <NUM> interfaces with serverless database instance <NUM> to retrieve data for consumption and/or provide data for storage. A timer <NUM> provides timer events as inputs for trigger events and permits measuring time elapsed since a cache item has been accessed. Some cache areas of memory <NUM> are illustrated: a buffer pool <NUM>, a large cache <NUM>, a query plan cache <NUM>, and free memory <NUM>. Although a single manifestation of each of buffer pool <NUM>, a large cache <NUM>, query plan cache <NUM>, and free memory <NUM>, it should be understood that SQL cache memory resides within each database instance (aka SQL instance). That is, each of serverless database instances <NUM> and <NUM> has its own buffer pool <NUM>, a large cache <NUM>, query plan cache <NUM>, and other caches. Thus, in some examples, a given hardware node with a cluster of database instances contains multiple buffer pools, query plan caches, etc., each belonging to a different database instance. Although it should be understood that other cache types are used in some examples. In some examples, buffer pool <NUM> uses 8KB pages, although other sizes (e.g., 4KB) may be used, and other cached objects may be larger or smaller.

An orchestrator <NUM> performs memory management for serverless database instances <NUM> and <NUM>, for example by managing memory reclamation processes described herein. For managing the caches (buffer pool <NUM>, large cache <NUM>, query plan cache <NUM>, and free memory <NUM>) in memory <NUM>, orchestrator <NUM> uses parameters <NUM>, thresholds <NUM> (e.g., resource utilization thresholds), and trigger data <NUM>. In some examples, a trigger condition to reclaim cache memory, is based on any or any combination) of the following inputs: timer <NUM>, measurements <NUM>, performance data <NUM>, historical data <NUM>, and thresholds <NUM>. Some examples include a "cool down period" as a time that must elapse between reclamation episodes. As with all other reclamation policy parameters, the cool down period is configurable. This "cool down period" can be classified as either a threshold <NUM> or fall under the umbrella of trigger data <NUM>, or stand on its own. In some examples, trigger data <NUM> includes time information (such as timestamps) from timer <NUM>. In operation, user node <NUM> and/or an administrator node <NUM> within tenant environment <NUM> interfaces with orchestrator <NUM> via a customization component <NUM> to customize parameters <NUM>, thresholds <NUM>, and trigger data <NUM>. For example, database node <NUM> receives user selections <NUM> via customization component <NUM> to implement user preferences. Orchestrator <NUM> uses trigger data <NUM> and/or thresholds <NUM> to determine whether to begin a memory reclamation cycle, and manages the memory reclamation cycle according to data within parameters <NUM> and thresholds <NUM>.

Measurements <NUM> holds data resulting from orchestrator <NUM> measuring a set of performance parameters <NUM> for determining whether memory is to be reclaimed. A memory unit list <NUM> identifies memory units that are in use (e.g., memory units within buffer pool <NUM>, large cache <NUM>, query plan cache <NUM>, and free memory <NUM>, etc.), at least some of which are potential reclamation targets, as indicated in further detail in the description of <FIG>. A cost calculator <NUM> determines the cost to rehydrate a cache item, which is also described in further detail in relation to <FIG>. A cache management component <NUM> manages the caches (buffer pool <NUM>, large cache <NUM>, query plan cache <NUM>, and free memory <NUM>) in memory <NUM> for orchestrator <NUM>. Policies <NUM> are used by cache management component <NUM> or orchestrator <NUM> for reclaiming identified memory (e.g., memory identified to be reclaimed during a reclamation cycle). That is, orchestrator <NUM> reclaims identified memory according to a reclamation policy identified within policies <NUM>.

An ML component <NUM> permits further improvement of the memory reclamation process, in some examples, by collecting historical data <NUM>. Historical data <NUM> provides training data, when feedback is provided on performance with certain parameters <NUM>, thresholds <NUM>, and trigger data <NUM>, so that ML component <NUM> tunes parameters <NUM> (e.g., ramp-down parameters), thresholds <NUM>, and trigger data <NUM>. ML tuning is set by user permission, in some examples. Ramp-down parameters are described in further detail in relation to <FIG>.

For some examples of environment <NUM>, database node <NUM> includes processor <NUM> and memory <NUM> that stores instructions 912b (see <FIG>) that are operative when executed by processor <NUM> to: detect a trigger event for reclaiming memory from a serverless database instance (e.g., memory within caches <NUM>-<NUM>); based at least on detecting the trigger event, determine whether memory is to be reclaimed; based at least on determining that memory is to be reclaimed; determine an amount of memory to be reclaimed; identify memory to be reclaimed; and reclaim the identified memory. See <FIG> for examples of identified memory <NUM>, <NUM> and <NUM> that are reclaimed.

In some examples, the trigger event comprises at least one event selected from the list consisting of a timer event (from timer <NUM>) and a memory usage parameter exceeding a threshold (identified within thresholds <NUM>). In some examples, orchestrator <NUM> receives a selection (from tenant environment <NUM>) defining at least a portion of a set of performance parameters (in parameters <NUM>). In some examples, determining whether memory is to be reclaimed comprises measuring the set of performance parameters, with the measurement data stored in measurements <NUM>. Determining an amount of memory to be reclaimed comprises calculating the amount of memory to be reclaimed using a ramp-down parameter. In some examples, orchestrator <NUM> receives a selection defining the ramp-down parameter, which is stored in parameters <NUM>. In some examples, orchestrator <NUM> uses ML component <NUM> to tune the ramp-down parameter based at least on historical data <NUM>. In some examples, identifying memory to be reclaimed comprises identifying a memory eviction priority. In some examples, the memory eviction priority is based at least on a cost to rehydrate a cache entry, as calculated by cost calculator <NUM>. In some examples, orchestrator <NUM> receives a selection defining a memory reclamation policy, which is stored in policies <NUM>. In some examples, reclaiming the identified memory comprises reclaiming the identified memory according to the reclamation policy. In some examples, orchestrator <NUM> scales CPU resources (e.g., usage of processor <NUM>) independently of scaling cache memory <NUM>-<NUM> resources.

<FIG> illustrates an exemplary timeline <NUM> of resource utilization for environment <NUM>. Timeline <NUM> illustrates CPU utilization (e.g., processor <NUM>), although utilization of memory <NUM> is somewhat similar. In the absence of memory reclamation, however, memory utilization is generally non-decreasing. In some examples, CPU resources scale independently of cache memory resources (e.g., buffer pool <NUM>, large cache <NUM>, free memory <NUM>, and others). A resource utilization curve <NUM> represents actual demand on percentage of CPU or memory, which increases and decreases according to workload variations over time. A minimum <NUM> represents a minimum reservation, and a maximum <NUM> is limited by the host. That is, computational resources for serverless database instances (e.g., vCore limits, memory limits, I/O limits, etc) are automatically scaled between minimum <NUM> and maximum <NUM>. In some examples, minimum memory is configurable which provides users with some control over how much cache memory can ever be reclaimed. In some scenarios, minimum memory is increased in order to reduce the performance impact from memory reclamation. An idle period <NUM> indicates a period in which the workload has diminished to effectively nothing, but the service is still active. A pause period <NUM> occurs when resources are released.

A serverless database can be used for bursty and intermittent workloads with low average usage. When there is no workload, the serverless database (e.g., serverless database instance <NUM>) enters idle period <NUM> period during which customers (users) may typically pay only for minimum resources. In some examples, after a pre-defined inactive (idle time) time, the database is paused for pause period <NUM>, during which billing may be reduced further (e.g., to costs for storage and minimal overhead). A serverless database is allowed to burst up to a usage of maximum <NUM> (e.g., a defined number of vCores for CPU and maximum memory, such as <NUM> GB). Although the service provider is able to allocate such resources dynamically, as needed, static allocation of the maximums would both reduce the total number of users for a given computing architecture, as well as raise user's costs. Aspects of the disclosure avoid overcommitting resources for serverless database relative to the maximum resources (e.g., maximum <NUM> for CPU and memory), while allowing resources needed for bursty workloads, to provide favorable performance, all while lowering costs.

<FIG> shows exemplary phases <NUM>-<NUM> of a memory management process <NUM> for serverless databases used in conjunction with environment <NUM>. A detection and triggering phase <NUM> includes detecting a triggering event for reclaiming memory, using orchestrator <NUM> (of <FIG>) and one or more of timer <NUM>, trigger data <NUM>, and thresholds <NUM>. A measuring phase <NUM> includes determining whether memory is to be reclaimed, using orchestrator <NUM> and one or more of parameters <NUM>, thresholds <NUM>, measurements <NUM>, performance data <NUM>, and memory unit list <NUM>. A selection phase <NUM> includes determining an amount of memory to be reclaimed, using orchestrator <NUM> and one or more of parameters <NUM>, memory unit list <NUM>, and cost calculator <NUM>. Selection phase <NUM> also includes identifying memory to be reclaimed, using orchestrator <NUM> and one or more of parameters <NUM>, memory unit list <NUM>, and cost calculator <NUM>, memory unit list <NUM>, and cache management component <NUM>. A reclaiming phase <NUM> includes reclaiming the identified memory (memory identified in selection phase <NUM>), using orchestrator <NUM> and one or more of cache management component <NUM> and policies <NUM>.

Phases <NUM>-<NUM> form a reclamation cycle, which is repeated according to a refresh cycle control <NUM>. A user customization operation <NUM> permits users (e.g., customers) to tailor individual portions of memory management process <NUM>, based on the flexibility offered by various examples, such as by submitting user selections <NUM> via customization component <NUM>. In some examples, with user permission, an ML tuning operation <NUM> adjusts some aspects of memory management process <NUM>, for example parameters <NUM>, thresholds <NUM>, and trigger data <NUM>. ML tuning operation <NUM> uses ML component <NUM> and historical data <NUM> to refine operations, by tuning one or more ramp-down parameters. Examples of customization and tuning include: timing for the next triggering check in detection and triggering phase <NUM>, and which performance inputs are measured in measuring phase <NUM>. Additional examples include ramp-down parameters and memory reclamation prioritization criteria used in selection phase <NUM>, and policies used in reclaiming phase <NUM>.

In some examples, on a fixed time interval (e.g., <NUM> minutes) a cache activeness ratio (e.g., the fraction of pages that were accessed during a prior interval or some other time period) is evaluated. If the activeness ratio is below a predefined threshold (e.g., <NUM>%) as set in thresholds <NUM>, the target memory size for the caches is set to a pre-calculated size to shrink external and internal caches, including buffer pool <NUM>, large cache <NUM>, free memory <NUM>, plan/object caches, and others. In some examples, various performance inputs are measured to determine whether memory should be reclaimed.

<FIG> shows a plot <NUM> with an exemplary ramp-down profile <NUM> of memory usage during memory management process <NUM>. In the illustrated example, the initial memory usage is M units. The overall approach for automatic cache reclamation modifies estimate a new memory target, MT (where MT < M) to determine an amount of memory to be reclaimed. In some examples, the database server's (e.g., database engine <NUM> of <FIG>) standard memory reclamation mechanism is leveraged with the new memory target MT. By using the standard memory reclamation mechanism, some examples leverage and modify database-specific cache eviction policies that have been developed and fine-tuned based on real-world experience.

In some examples, a buffer pool page or optionally other cache entries from any other type of SQL cache is defined to be idle if it has not been accessed in k minutes. At regular intervals of t minutes (with the constraint that t ≤ k in some examples), a background thread in the database server attempts to reclaim memory. In some examples, the default value of k is <NUM> minutes, and t is <NUM> minutes, although these are configurable as described above, in some examples.

If a small value of k is set (e.g., <NUM> minutes) by the user, this indicates that the user desires to reclaim pages soon after the page meets the criteria for being idle. Otherwise the user's purpose for setting k to a small value might not be fulfilled. In some examples, memory reclamation is triggered based on low usage by the database workload, as measured by specific usage metrics. If the active cache utilization relative to total memory usage is less than a configurable threshold (e.g., <NUM>%), or if CPU utilization relative to the maximum number of vCores configured is less than a configurable threshold (e.g., <NUM>%) over a configurable period of time (e.g., <NUM> minutes), memory is reclaimed. A serverless memory management policy can also be adjusted to reclaim memory based upon the active cache utilization being low, independently of CPU utilization. Such a determination is made during measuring phase <NUM>, in some examples. This policy flexibility allows workloads with high CPU utilization and low memory utilization to reduce memory costs and the user's costs. This policy flexibility also allows workloads with low CPU utilization to grow and maintain cache memory when memory demand is high. In both cases, this policy allows automatic scaling of CPU resources and cache memory resources to occur independently, based on differences in the actual demand for each type of resource from the database workload. Independent automatic scaling can occur both upward and downward. In the case of memory, automatic downward scaling is the memory reclamation described herein. In some examples, the scaling memory upwardly is not constrained by a timer or usage based thresholds.

At the time that a memory reclamation cycle is triggered, MIdle, represents the total amount of idle memory. The calculations below provide an exemplary determination of an amount of memory to be reclaimed. The total memory is never allowed to go below Mmin, the minimum memory set for serverless databases (e.g., serverless database instances <NUM> and <NUM>). The amount of memory reclaimed in a single cycle is limited to R1 times the current memory usage. In some examples R1 is <NUM>%; in some examples, R1 is <NUM>%; in some examples, R1 is another value. The amount of memory reclaimed in a single cycle is also limited to R2 times the idle memory (MIdle). In some examples, R2 is <NUM>%; in some examples, R2 is another value. Ramp-down parameters R1 and R2 (which are stored in parameters <NUM> of <FIG> and may be both customized by the user and tuned by ML component <NUM>) control how quickly cache memory is reclaimed. This sets a cost-performance trade-off for the workload.

With this example, the new memory target is computed as: <MAT>.

And using R1 = <NUM>% and R2 = <NUM>%, Eq. (<NUM>) becomes: <MAT>.

Ramp-down parameters R1 and R2 help ensure that the performance impact of reclaiming cache memory is minimal, because reclamation occurs in controlled steps over time, rather than in a single step of uncontrolled size.

Additionally, users can configure cache reclamation by changing the value of k, which governs when an object is considered idle. Increasing the value of k, increases the amount of data that is retained in caches, and generally improves performance; whereas reducing the value of k reduces the cost, but may incur a greater performance penalty.

For the example shown in plot <NUM>, a serverless database's memory usage is <NUM> units and consists only of cache memory, and R1 and R2 are set at <NUM>% and <NUM>%, respectively. Mmin is <NUM> units, and all of the memory is idle. Eq. (<NUM>) becomes: <MAT>.

Thus, in each subsequent iteration, the memory reduces as follows: <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. This is shown in <FIG>, as ramp-down profile <NUM> hits each of the values <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and stays at <NUM> until the workload picks up or the serverless database is paused. See <FIG>, noting that minimum <NUM> corresponds to <NUM>, in this example.

A secondary control for the policy, configurable by the user in some examples, is t. Cache memory reclamation can be made more aggressive by using a smaller value of t, or the reverse of making the value of t larger can reduce reclamation. In the above example, with t set to <NUM> minutes, the <NUM> intervals required to reach the minimum memory, Mmin, spans <NUM> minutes, whereas with t set to <NUM> minutes, Mmin, is reached in only <NUM> minutes. Some users may take monetary considerations into account when tuning parameter values. In some examples, a utilization threshold is another parameter that influences price and performance outcomes and is tunable by users. By monitoring performance characteristics, such as throughput and latency (and others), a user may ascertain whether memory reclamation is too aggressive. Conversely, by monitoring costs, a user may ascertain whether memory reclamation is not aggressive enough to control costs. In either case, the user may change the value of any of k, active cache utilization threshold, t, R1, and R2 to determine whether price and performance characteristics are more acceptable. In some examples, ML component <NUM> collects parameters k, t, R1, and R2, and performance characteristics (such as throughput, latency, and others) into historical data <NUM>. Performance characteristic differences before and after memory reclamation can thus be correlated with the various parameters. ML component <NUM> uses historical data <NUM> to tune any of k, t, R1, R2, and an active cache utilization threshold for a ramp-down profile while minimizing performance impacts.

When the new memory target is set for the reclamation iteration, the specific cache entries to evict may be based on the cache entries that incur the lowest recourse cost to rehydrate back into the cache. This is the default eviction policy in some examples. Examples of cache rehydration resource costs include I/O to fetch data pages from disk and bring data back into the buffer pool or CPU overhead to regenerate query plans. Alternatively, in some examples, the policy may be configured to evict cache entries that were accessed longest ago. In some examples, the eviction policy may be based on a combination of cache rehydration resource costs and the amount of elapsed time since the cache entry was last accessed. In the case of the buffer pool, the difference between these policies might not be significant, but in the case of other caches such as query plan cache <NUM>, the difference in customer performance impact between these policies can be significant.

In addition to caches, some examples also use query-specific working memory, such as memory grants for operations such as sorting and hashing. Some examples do reclaim working memory that is currently being used by a query. Instead, working memory is released once the query completes execution and is returned to the free list or buffer pool - after which it can be reclaimed as described herein. In some examples, the memory is released from the query perspective, but not from the server perspective. In such examples, the memory released as free memory or released to the buffer pool is the memory that is stolen from the buffer pool. Either way, the memory is reclaimed via free memory or buffer pool.

In some examples, the ramp-down step sizes can be increased by setting new lower memory targets (e.g., R1, and R2 increased) and the cooldown time period, t, between reclamation iterations can be shortened if telemetry from historical usage patterns is used to predict future usage patterns. For example, for a particular serverless database, the active cache utilization continues to remain low after several reclamation iterations until some minimum memory target is reached before workload activity returns. This pattern repeats itself each time workload activity returns and quiesces. If the prediction confidence is sufficiently high, based on the historical usage pattern, a new lower memory target MT can be set immediately to the minimum memory target. This reduces costs more quickly and, if the prediction is correct, will not impact performance.

<FIG> shows a graphical depiction of an implementation of a reclamation policy used during memory management process <NUM> (of <FIG>). A memory usage profile 500a exists prior to a memory reclamation cycle that results in a memory usage profile 500b. Memory usage profile 500a indicates memory units <NUM>-<NUM> and <NUM>-<NUM> with their respective page weights. In some examples, page weights are based at least on cost (e.g., expense) to rehydrate into memory, and are determined (e.g., calculated) by cost calculator (e.g., see <FIG>). Memory units <NUM>-<NUM> are indicated as "hot pages" (hot cache entries, e.g., any of buffer pool pages, query plans, column store segments, etc.) because they had been accessed less than some threshold <NUM> time ago, for example less than k. Memory units <NUM>-<NUM> are indicated as "cold pages" because they had not been accessed within threshold <NUM> time ago.

As indicated, hot memory unit <NUM> has a relatively low page weight, below a cache reclaim threshold <NUM>, as do cold memory units <NUM> and <NUM>. In some examples, thresholds <NUM> and <NUM> are stored within thresholds <NUM> (e.g., see <FIG>); in some examples, threshold <NUM> and/or threshold <NUM> are customizable by a user; in some examples, threshold <NUM> and/or threshold <NUM> are tunable by ML component <NUM>. In some examples, threshold <NUM> is different for hot pages than for cold pages, such as higher for hot pages, so that identifying memory to be reclaimed is weighted toward reclaiming cold pages. In some examples, eviction may be based at least on how long has elapsed since a memory until was last accessed or last read. In some examples, the policy may favor evicting cache entries that are most costly (e.g., incur the greatest performance overhead and latency) to regenerate in the cache.

In this example, memory units <NUM>, <NUM>, and <NUM> are identified as memory to be reclaimed. Thus, after memory reclamation, memory units <NUM>, <NUM>, and <NUM> are absent from memory usage profile 500b, indicating less memory after reclamation. The operation is illustrated by a memory status timeline <NUM>. An initial status <NUM> has an allocation <NUM> of hot pages that includes memory units <NUM>-<NUM> and an allocation <NUM> of cold pages that includes memory units <NUM>-<NUM>, and which corresponds to memory usage profile 500a. A shrink cache operation <NUM>, corresponding to reclaiming phase <NUM> of memory management process <NUM> (of <FIG>), reduces cache memory usage. A new status <NUM> has an allocation <NUM> of hot pages that includes only memory units <NUM>, <NUM>, and <NUM> and an allocation <NUM> of cold pages that includes only memory units <NUM> and <NUM>, and which corresponds to memory usage profile 500b.

In some examples, on a schedule (e.g., a cache reclaim interval), the size of active cache entries (e.g., hot pages) across caches, is calculated. An active cache ratio is calculated as the ratio of the size of active cache entries to the total cache size. A new (e.g., lower) target cache size is determined based on the active cache utilization. This allows reclamation of cache entries (e.g., buffer pool pages, plan cache entries, etc.) by using existing heuristics based on lowest weighted pages. After a memory reclamation cycle, a cooldown period, t, elapses before another reclamation cycle. In some examples, during an idle period, all caches are flushed if certain utilization measures like CPU usage by user queries is zero for a sufficiently long time period. Thus, <FIG> illustrates a judicious trade-off between cost and performance, which is configurable and/or customizable so that users may achieve a desired cost-performance trade-off for their workloads.

An example billing calculation is provided. For a given time interval, user's cost, CTotal, is found by: <MAT> <MAT> where Tbilling interval is the time granularity for calculating user costs, and CTotal is the total user costs for a billing period that includes all of the billing intervals. In some examples, the billing interval (Tbilling interval) is one second; in some examples, it is ten seconds; in some examples, it is <NUM> milliseconds or another time duration. The vCore and memory unit prices may be set or variable, such as based on time of day or data center region, and may be expressed as monetary costs per unit resource per unit of time (e.g., dollars per GB memory per second, or dollars per vCore per second). Other billing calculations are used in some examples.

<FIG> illustrates an exemplary timeline <NUM> of messages in environment <NUM> (of <FIG>). Timeline <NUM> begins upon an IdleMemoryStatsTimerTask <NUM> receiving a TimerFunction message <NUM>. IdleMemoryStatsTimerTask <NUM> sends a FlushAllCaches message <NUM> to an IdleMemoryCollector <NUM>. IdleMemoryCollector <NUM> performs a SetReclaimTarget process <NUM> and sends an Insert message <NUM> to a ResetReclaimTargetTimerTaskList <NUM>. ResetReclaimTargetTimerTaskList <NUM> sends a SetMaxMemory Target message <NUM> to an SOS_MemoryNode <NUM>.

Upon IdleMemoryStatsTimerTask <NUM> sending a ShrinkIfNeeded message <NUM> to IdleMemoryCollector <NUM>, IdleMemoryCollector <NUM> sends a CalculateCacheRatio message <NUM> to an IdleMemoryStats <NUM>. IdleMemoryCollector <NUM> also performs a SetReclaimTarget process <NUM> and sends an Insert message <NUM> to ResetReclaimTargetTimerTaskList <NUM>. ResetReclaimTargetTimerTaskList <NUM> sends a SetMaxMemory Target message <NUM> to SOS_MemoryNode <NUM>.

Table <NUM> illustrates an example data structure, used by some examples.

Some examples use SqlIdleMemoryStatsTimerTask::TimerFunction() as a timer function on intervals of ServerlessCacheReclaimIntervalMin minutes. An attempt is made at these intervals to shrink the cache memory I accordance with the disclosure herein. Upon intervals, of ServerlessCheckFlushCachesTimePeriodMinutes minutes, an attempt is made to flush all caches, if applicable.

Step-down sizes is a list of step down memory limits used to determine an amount of memory to reclaim (e.g., an amount by which to shrink memory). In some examples, the list is calculated as follows:.

SqlIdleMemoryStats evaluates caches memory activeness ratio and collects cost model histograms for the buffer pool and large caches. In this class, a function, SqlIdleMemoryStats::CalculateCacheActivePageRatio(), is introduced to calculate cache memory activeness ratios. A cache entry is active if the amount of elapsed time since the cache entry last used is less than ServerlessActiveCacheThresholdMin. An example algorithm is provided:.

SqlIdleMemoryCollector is the cache memory manager to collect idle cache memory. It calls SqlIdleMemoryStats::CalculateCacheActivePageRatio() to evaluate the cache active ratio. If the cache active ratio is less than ServerlessCacheReclaimThreshold, it obtains a step-down size from the list of step-down sizes such that the total number of cache pages is greater than the step-down size multiplied by (<NUM> + ServerlessMemStepDownSizeExtraBufPercent), where ServerlessMemStepDownSizeExtraBufPercent is used to prevent a ping-pong scenario. The reclaim pages is set to be the total cache pages minus step-down sizes. SqlIdleMemoryCollector::SetReclaimTarget() is called to set the reclaim target to shrink cache memory. In some examples, the shrink policy is set to a value defined by SoftMaxTarget. The first attempt is to shrink external caches, and then internal caches are attempted next, in some examples. With this scheme, the plan/object caches are generally the last to be shrunk.

In the case of an absence of user activity for more than <NUM> minutes (or some other threshold), SqlIdleMemoryCollector::FlushAllCachesIfNeededForServerless() is called. This function checks the duration of user inactivity duration and flushes all caches by calling DbccFreeSystemCacheLocal(). The SqlIdleMemoryCollector::SetReclaimTarget() is called to shrink the memory down to the minimum memory defined for the serverless instance.

ResetReclaimTargetTimerTaskList is a list of tasks identified as ResetReclaimTargetTimerTask, and prevents race conditions between multi-instance memory brokerage and memory management for a serverless instance. An example algorithm for the ResetReclaimTargetTimerTaskList is provided:.

In some examples, telemetries are handled by a Kusto table MonSqlIdleMemCollectorStats that is used to track idle memory collector related events, such as:.

<FIG> is a flow chart <NUM> illustrating exemplary operations involved in memory management for serverless databases. In some examples, operations described for flow chart <NUM> are performed by computing device <NUM> of <FIG>. Flow chart <NUM> commences with operation <NUM>, in which a user initiates a serverless database service with a service provider, such as a cloud-based provider. In some examples, the serverless database is a serverless SQL database. In operation <NUM>, the user customizes the service parameters, such as setting criteria for a memory reclamation trigger, selecting (e.g., defining) performance parameters to measure for determining whether memory is to be reclaimed, selecting (e.g., defining) one or more ramp-down parameters (e.g., time interval and step size), selecting (e.g., defining) memory reclamation policies, and/or other customizeable parameters that can balance the cost/performance trade-off according to the user's preferences.

In some examples, the trigger event is a timer event, a memory usage parameter exceeding a threshold, and/or another user-defined custom trigger condition that will be used in operation <NUM>. In some examples, operation <NUM> includes receiving a selection defining at least a portion of a set of performance parameters to measure for determining whether memory is to be reclaimed, that will be used in operation <NUM>. In some examples, operation <NUM> includes receiving a selection defining the ramp-down parameter that will be used in operation <NUM>. In some examples, operation <NUM> includes receiving a selection defining a memory reclamation policy that will be used in operation <NUM> and/or <NUM>.

The serverless database service is initialized in operation <NUM>, for example by setting CPU and memory boundaries (e.g., CPU maximum cap and memory minimum) and beginning execution of a database engine instance execution for the user. The user employs the serverless database service in operation <NUM>, for example to process data. The service provider scales resources as needed, for example, increasing or decreasing CPU utilization and growing the memory cache according to the user's workload, in operation <NUM>. In some examples, the service provider scales CPU resources independently of scaling cache memory resources.

Operation <NUM> includes detecting a trigger event for reclaiming memory from a serverless database instance. In some examples, the trigger event includes one or more of: a timer event, a memory usage parameter exceeding a threshold, and another user-defined custom trigger condition (e.g., see operation <NUM>). In some examples, a reclamation trigger condition is evaluated against an aggregation of cache entries across multiple database instances in a pool of databases. If, in decision operation <NUM>, a trigger event is detected, operation <NUM> includes, based at least on detecting the trigger event, determining whether memory is to be reclaimed. In some examples, determining whether memory is to be reclaimed comprises measuring the set of performance parameters. If, in decision operation <NUM>, a trigger event is not detected, or in decision operation <NUM>, no memory is to be reclaimed, flow chart <NUM> returns to operation <NUM> for ongoing serverless database operations.

Otherwise, operation <NUM> includes, based at least on determining that memory is to be reclaimed, determining an amount of memory to be reclaimed. Determining an amount of memory to be reclaimed comprises calculating the amount of memory to be reclaimed using a ramp-down parameter (e.g., see operation <NUM>). Operation <NUM> includes identifying memory to be reclaimed. In some examples, identifying memory to be reclaimed comprises identifying a memory eviction priority. In some examples, the memory eviction priority is based at least on a cost to rehydrate a cache entry. In some examples, the memory eviction priority is based at least on the length of time that has elapsed since the cache entry had last been accessed. In some examples, a combination is used (e.g., see operation <NUM>). In some examples, identifying memory to be reclaimed comprises identifying cache entries to evict across caches entries for the multiple database instances in the pool of databases. Operation <NUM> includes reclaiming the identified memory. In some examples, reclaiming the identified memory comprises reclaiming the identified memory according to a reclamation policy (e.g., see operation <NUM>).

The service provider continues to scale resources as needed, for example, increasing or decreasing CPU utilization and growing or shrinking the memory cache according to the user's workload and the reclamation process described herein, in operation <NUM>. In some examples, the service provider scales CPU resources independently of scaling cache memory resources. Historical data is collected in operation <NUM>, to use for tuning the memory reclamation parameters with an ML component.

Operation <NUM> includes tuning the ramp-down parameter based at least on the historical data. Operation <NUM> uses an ML component for the tuning. In some examples, operation <NUM> involves tuning other or additional aspects of memory management for serverless databases. Flow chart <NUM> then returns to operation <NUM> for ongoing serverless database operations or is paused in operation <NUM> (e.g., by the user) and resumes with operation <NUM> at a later time.

<FIG> is a flow chart <NUM> illustrating exemplary operations involved in memory management for serverless databases. In some examples, operations described for flow chart <NUM> are performed by computing device <NUM> of <FIG>. Flow chart <NUM> commences with operation <NUM>, which includes detecting a trigger event for reclaiming memory from a serverless database instance. In some examples, the trigger event comprises at least one event selected from the list consisting of a timer event and a memory usage parameter exceeding a threshold. Operation <NUM> includes, based at least on detecting the trigger event, determining whether memory is to be reclaimed. In some examples, determining whether memory is to be reclaimed comprises measuring the set of performance parameters.

Operation <NUM> includes, based at least on determining that memory is to be reclaimed, determining an amount of memory to be reclaimed. Determining an amount of memory to be reclaimed comprises calculating the amount of memory to be reclaimed using a ramp-down parameter. Operation <NUM> includes identifying memory to be reclaimed. In some examples, identifying memory to be reclaimed comprises identifying a memory eviction priority. In some examples, the memory eviction priority is based at least on a cost to rehydrate a cache entry. Operation <NUM> includes reclaiming the identified memory. In some examples, reclaiming the identified memory comprises reclaiming the identified memory according to a reclamation policy.

Some aspects and examples disclosed herein are directed to a system for memory management of serverless databases comprising: a processor; and a computer-readable medium storing instructions that are operative upon execution by the processor to: detect a trigger event for reclaiming memory from a serverless database instance; based at least on detecting the trigger event, determine whether memory is to be reclaimed; based at least on determining that memory is to be reclaimed; determine an amount of memory to be reclaimed; identify memory to be reclaimed; and reclaim the identified memory.

Additional aspects and examples disclosed herein are directed to a method of memory management for serverless databases comprising: detecting a trigger event for reclaiming memory from a serverless database instance; based at least on detecting the trigger event, determining whether memory is to be reclaimed; based at least on determining that memory is to be reclaimed, determining an amount of memory to be reclaimed; identifying memory to be reclaimed; and reclaiming the identified memory.

Additional aspects and examples disclosed herein are directed to one or more computer storage devices having computer-executable instructions stored thereon for memory management of serverless databases, which, on execution by a computer, cause the computer to perform operations comprising: detecting a trigger event for reclaiming memory from a serverless database instance, wherein the trigger event comprises at least one event selected from the list consisting of; a timer event and a memory usage parameter exceeding a threshold; receiving a selection defining at least a portion of a set of performance parameters; based at least on detecting the trigger event, determining whether memory is to be reclaimed, wherein determining whether memory is to be reclaimed comprises measuring the set of performance parameters; receiving a selection defining a ramp-down parameter; based at least on determining that memory is to be reclaimed, determining an amount of memory to be reclaimed, wherein determining an amount of memory to be reclaimed comprises calculating amount of memory to be reclaimed using the ramp-down parameter; identifying memory to be reclaimed, wherein identifying memory to be reclaimed comprises identifying a memory eviction priority; receiving a selection defining a memory reclamation policy; and reclaiming the identified memory according to the memory reclamation policy.

<FIG> is a block diagram of an example computing device <NUM> for implementing aspects disclosed herein, and is designated generally as computing device <NUM>. Computing device <NUM> is but one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the examples disclosed herein. Neither should computing device <NUM> be interpreted as having any dependency or requirement relating to any one or combination of components/modules illustrated. The examples disclosed herein may be described in the general context of computer code or machine-useable instructions, including computer-executable instructions such as program components, being executed by a computer or other machine, such as a personal data assistant or other handheld device. Generally, program components including routines, programs, objects, components, data structures, and the like, refer to code that performs particular tasks, or implement particular abstract data types. The disclosed examples may be practiced in a variety of system configurations, including personal computers, laptops, smart phones, mobile tablets, hand-held devices, consumer electronics, specialty computing devices, etc. The disclosed examples may also be practiced in distributed computing environments when tasks are performed by remote-processing devices that are linked through a communications network.

Computing device <NUM> includes a bus <NUM> that directly or indirectly couples the following devices: computer-storage memory <NUM>, one or more processors <NUM>, one or more presentation components <NUM>, I/O ports <NUM>, I/O components <NUM>, a power supply <NUM>, and a network component <NUM>. While computing device <NUM> is depicted as a seemingly single device, multiple computing devices <NUM> may work together and share the depicted device resources. For example, memory <NUM> may be distributed across multiple devices, and processor(s) <NUM> may be housed with different devices.

Bus <NUM> represents what may be one or more busses (such as an address bus, data bus, or a combination thereof). Although the various blocks of <FIG> are shown with lines for the sake of clarity, delineating various components may be accomplished with alternative representations. For example, a presentation component such as a display device is an I/O component in some examples, and some examples of processors have their own memory. Distinction is not made between such categories as "workstation," "server," "laptop," "hand-held device," etc., as all are contemplated within the scope of <FIG> and the references herein to a "computing device. " Memory <NUM> may take the form of the computer-storage media references below and operatively provide storage of computer-readable instructions, data structures, program modules and other data for the computing device <NUM>. In some examples, memory <NUM> stores one or more of an operating system, a universal application platform, or other program modules and program data. Memory <NUM> is thus able to store and access data 912a and instructions 912b that are executable by processor <NUM> and configured to carry out the various operations disclosed herein.

In some examples, memory <NUM> includes computer-storage media in the form of volatile and/or nonvolatile memory, removable or non-removable memory, data disks in virtual environments, or a combination thereof. Memory <NUM> may include any quantity of memory associated with or accessible by the computing device <NUM>. Memory <NUM> may be internal to the computing device <NUM> (as shown in <FIG>), external to the computing device <NUM> (not shown), or both (not shown). Examples of memory <NUM> in include, without limitation, random access memory (RAM); read only memory (ROM); electronically erasable programmable read only memory (EEPROM); flash memory or other memory technologies; CD-ROM, digital versatile disks (DVDs) or other optical or holographic media; magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices; memory wired into an analog computing device; or any other medium for encoding desired information and for access by the computing device <NUM>. Additionally, or alternatively, the memory <NUM> may be distributed across multiple computing devices <NUM>, for example, in a virtualized environment in which instruction processing is carried out on multiple devices <NUM>. For the purposes of this disclosure, "computer storage media," "computer-storage memory," "memory," and "memory devices" are synonymous terms for the computer-storage memory <NUM>, and none of these terms include carrier waves or propagating signaling.

Processor(s) <NUM> may include any quantity of processing units that read data from various entities, such as memory <NUM> or I/O components <NUM>. Specifically, processor(s) <NUM> are programmed to execute computer-executable instructions for implementing aspects of the disclosure. The instructions may be performed by the processor, by multiple processors within the computing device <NUM>, or by a processor external to the client computing device <NUM>. In some examples, the processor(s) <NUM> are programmed to execute instructions such as those illustrated in the flow charts discussed below and depicted in the accompanying drawings. Moreover, in some examples, the processor(s) <NUM> represent an implementation of analog techniques to perform the operations described herein. For example, the operations may be performed by an analog client computing device <NUM> and/or a digital client computing device <NUM>. Presentation component(s) <NUM> present data indications to a user or other device. Exemplary presentation components include a display device, speaker, printing component, vibrating component, etc. One skilled in the art will understand and appreciate that computer data may be presented in a number of ways, such as visually in a graphical user interface (GUI), audibly through speakers, wirelessly between computing devices <NUM>, across a wired connection, or in other ways. I/O ports <NUM> allow computing device <NUM> to be logically coupled to other devices including I/O components <NUM>, some of which may be built in. Example I/O components <NUM> include, for example but without limitation, a microphone, joystick, game pad, satellite dish, scanner, printer, wireless device, etc..

The computing device <NUM> may operate in a networked environment via the network component <NUM> using logical connections to one or more remote computers. In some examples, the network component <NUM> includes a network interface card and/or computer-executable instructions (e.g., a driver) for operating the network interface card. Communication between the computing device <NUM> and other devices may occur using any protocol or mechanism over any wired or wireless connection. In some examples, network component <NUM> is operable to communicate data over public, private, or hybrid (public and private) using a transfer protocol, between devices wirelessly using short range communication technologies (e.g., near-field communication (NFC), Bluetooth™ branded communications, or the like), or a combination thereof. Network component <NUM> communicates over wireless communication link <NUM> and/or a wired communication link 926a to a cloud resource <NUM> across network <NUM>. Various different examples of communication links <NUM> and 926a include a wireless connection, a wired connection, and/or a dedicated link, and in some examples, at least a portion is routed through the internet.

Although described in connection with an example computing device <NUM>, examples of the disclosure are capable of implementation with numerous other general-purpose or special-purpose computing system environments, configurations, or devices. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with aspects of the disclosure include, but are not limited to, smart phones, mobile tablets, mobile computing devices, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, gaming consoles, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, mobile computing and/or communication devices in wearable or accessory form factors (e.g., watches, glasses, headsets, or earphones), network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, virtual reality (VR) devices, augmented reality (AR) devices, mixed reality (MR) devices, holographic device, and the like. Such systems or devices may accept input from the user in any way, including from input devices such as a keyboard or pointing device, via gesture input, proximity input (such as by hovering), and/or via voice input.

By way of example and not limitation, computer readable media comprise computer storage media and communication media. Computer storage media include volatile and nonvolatile, removable and non-removable memory implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or the like. Computer storage media are tangible and mutually exclusive to communication media. Computer storage media are implemented in hardware and exclude carrier waves and propagated signals. Computer storage media for purposes of this disclosure are not signals per se. Exemplary computer storage media include hard disks, flash drives, solid-state memory, phase change random-access memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that may be used to store information for access by a computing device. In contrast, communication media typically embody computer readable instructions, data structures, program modules, or the like in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media.

The order of execution or performance of the operations in examples of the disclosure illustrated and described herein is not essential, and may be performed in different sequential manners in various examples.

Claim 1:
A system for memory management of serverless databases, the system comprising:
a processor (<NUM>); and
a computer-readable medium (<NUM>) storing instructions that are operative upon execution by the processor to:
detect a trigger event for reclaiming memory from a serverless database instance (<NUM>);
based at least on detecting the trigger event, determine whether memory is to be reclaimed (<NUM>);
based at least on determining that memory is to be reclaimed, determine an amount of memory to be reclaimed by calculating the amount of memory to be reclaimed using ramp-down parameters, which comprise:
R1, indicating a limit of the ratio of the amount of memory reclaimed in a single cycle to a current memory usage, and
R2, indicating a limit of the ratio of the amount of memory reclaimed in a single cycle to idle memory,
using a machine learning, ML, component (<NUM>), trained with historical data (<NUM>), to tune any of R1 and R2 for a ramp-down profile while minimizing performance impacts;
identify memory to be reclaimed; and
reclaim the identified memory.