Troubleshooting out-of-memory issues for Aurora MySQL databases

When an Aurora MySQL DB instance runs critically low on memory, the operating system can terminate the database process, causing an unplanned restart. To help prevent these restarts, Aurora MySQL includes memory management capabilities that monitor system memory and take automatic recovery actions when memory is low. These actions help prevent database unavailability due to memory exhaustion.

The following parameters control this behavior:

OOM response actions

The following actions can be included in aurora_oom_response, listed from least to most aggressive.

kill_connect version-specific behavior

On Serverless v2, Aurora responds to memory pressure by first scaling up ACUs to provide additional memory. If memory pressure persists while scaling is in progress, Aurora may terminate existing connections to recover memory. Termination of connections that try to allocate memory only occurs when the instance has reached its configured maximum ACU limit and can no longer scale further.

Default values by version

Aurora MySQL automatically configures aurora_oom_response based on engine version, instance type, and available memory.

In Aurora MySQL 8.4, when aurora_enable_memory_management is ON (the default), Aurora automatically manages memory recovery actions, and the aurora_oom_response value is not used. When set to OFF, Aurora uses the aurora_oom_response value directly, which is empty by default – meaning no recovery actions are taken unless you explicitly configure them. The following defaults table applies to Aurora MySQL version 3 only.

Small instance threshold: ≤2 GiB for versions 3.04 and 3.05. ≤4 GiB for version 3.06 and higher.

Large instance threshold: >2 GiB for versions 3.04 and 3.05. >4 GiB for version 3.06 and higher.

Aurora Serverless v2

The tune and tune_buffer_pool actions are not supported on Aurora Serverless v2. All other actions work the same as on provisioned instances.

Memory thresholds adjust dynamically as the instance scales its ACUs. The Serverless v2 column in the defaults table above shows the effective defaults for each version.

Monitoring

You can monitor OOM avoidance activity through the following methods.

Error log

When memory recovery actions are taken, Aurora MySQL writes messages to the database error log. The message prefix varies by version and may change in future releases:

These messages include:

To view the error log, see Aurora MySQL error logs.

Amazon CloudWatch metrics

The following CloudWatch metrics track OOM avoidance activity at the instance level.

The following general CloudWatch metrics are also useful for monitoring memory pressure:

For the full list of Aurora MySQL instance-level metrics, see Instance-level metrics for Amazon Aurora.

Global status variables

The following status variables provide information about OOM state. Available in Aurora MySQL version 3.06.0 and higher.

To query: SHOW GLOBAL STATUS LIKE 'aurora_oom%';

For the full list of Aurora MySQL global status variables, see Aurora MySQL global status variables.

Performance Insights

If Performance Insights is enabled, you can use OS-level memory metrics to monitor memory pressure and detect OOM events. The following metrics are available under the os.memory and os.swap counters:

You can monitor os.memory.outOfMemoryKillCount to detect when the OS killed the database process due to out of memory. For the full list of OS counters, see Performance Insights OS metrics.

Performance Schema

If performance_schema is enabled, you can use memory summary tables to identify which components and connections are consuming the most memory. For more information, see Troubleshooting memory usage issues for Aurora MySQL databases.