Cache eviction limits how much metadata each persistent connection can accumulate, preventing out of memory (OOM) errors in Software as a Service (SaaS) workloads with large numbers of persistent connections. The feature uses the Least Recently Used (LRU) policy to release infrequently used caches, reducing per-connection memory usage and improving instance stability.
Prerequisites
Before you begin, ensure that:
Your RDS instance runs PostgreSQL 11 or later
If the feature is not yet available, update the minor engine version of your instance. For more information, see Update the minor engine version.
Background
Each time a PostgreSQL backend process accesses a table, it caches the table's metadata in process-local memory. This cache is never proactively released—it accumulates for the lifetime of the connection. In workloads with many persistent connections, this can exhaust available memory and trigger OOM errors.
Use cases
SaaS applications that maintain large numbers of persistent database connections
Usage notes
Some caches cannot be evicted to ensure the instance runs correctly. In extreme cases, the configured cache limit may not be fully enforced.
Modifying the parameters described in this topic does not trigger an instance restart.
Key concepts
ApsaraDB RDS for PostgreSQL maintains three types of connection caches:
| Cache type | What it stores | Configurable limit |
|---|---|---|
relcache | Metadata of user tables | Yes — rds_relcache_max_cached_relations |
syscache | Tuples of system tables | Yes — rds_syscache_max_cached_tuples |
plancache | User-defined execution plans | No |
Configure cache eviction
For the current connection
Run the following SQL statements to set limits for the current session only.
-- Limit relcache to 1,000 user tables for the current connection
SET rds_relcache_max_cached_relations = 1000;
-- Remove the relcache limit for the current connection
SET rds_relcache_max_cached_relations = -1;
-- Limit syscache to 10,000 system table tuples for the current connection
SET rds_syscache_max_cached_tuples = 10000;
-- Remove the syscache limit for the current connection
SET rds_syscache_max_cached_tuples = -1;For all connections
Set rds_relcache_max_cached_relations and rds_syscache_max_cached_tuples in the ApsaraDB RDS console to apply limits instance-wide. For more information, see Modify the parameters of an ApsaraDB RDS for PostgreSQL instance.
Monitor cache usage per process
To monitor cache usage for each connection, install the rdsutils extension and enable the cache monitor parameter.
Install the extension:
CREATE EXTENSION rdsutils;In the ApsaraDB RDS console, set
rds_enable_cache_monitortoon. You can modify therds_enable_cache_monitorparameter only in the ApsaraDB RDS console. For more information, see Modify the parameters of an ApsaraDB RDS for PostgreSQL instance.
Enabling rds_enable_cache_monitor adds approximately 2 ms of overhead per SQL statement.Parameters
| Parameter | Description | Valid values | Default | Minimum recommended value |
|---|---|---|---|---|
rds_enable_cache_monitor | Monitors cache usage per connection. | on, off | off | — |
rds_relcache_max_cached_relations | Maximum number of user tables cached per connection. Set to -1 to disable the limit. If you use partitioned tables or the timescaledb extension, set this to -1 or a large value. | -1 to INT_MAX | -1 (unlimited) | 1000 |
rds_syscache_max_cached_tuples | Maximum number of system table tuples cached per connection. Set to -1 to disable the limit. If you use partitioned tables or the timescaledb extension, set this to -1 or a large value. | -1 to INT_MAX | -1 (unlimited) | 5000 |
Settingrds_relcache_max_cached_relationsorrds_syscache_max_cached_tuplestoo low can degrade query performance. Size the limits based on the number of tables and fields your workload accesses. If your workload accesses many tables, use a larger value.