ApsaraDB RDS:Buffer Pool Extension (BPE) feature

Use cases

BPE delivers the most benefit when the working dataset exceeds available memory, forcing repeated disk reads. Consider enabling it for:

• Read-heavy workloads with large datasets — queries that frequently access data pages not resident in memory benefit most from the additional cache layer.

• Mixed read/write workloads — the extra cache reduces I/O pressure on high-performance disks, cutting SQL execution time and write latency.

• Larger instance types — the performance gain scales with instance size. An 8-core, 16 GB instance sees up to 103% improvement in mixed QPS, while a 4-core, 8 GB instance sees up to 30% improvement in write QPS.

How it works

Disk I/O is the most common performance bottleneck in database systems. When the buffer pool (an in-memory cache of data pages) is full, every cache miss triggers a read from disk — the slowest operation in the stack.

BPE inserts a high-speed disk cache between memory and the high-performance data disk. When a data page is not found in the buffer pool, the system checks BPE before falling back to the data disk. This three-tier read path significantly reduces requests that reach the slowest storage layer.

Three-tier storage architecture:

Data page read path:

1. The client requests a data page.

2. The system checks the in-memory buffer pool.

   • Found: return to the client.

   • Not found: proceed to step 3.

3. The system checks BPE on the high-speed disk.

   • Found: load into the buffer pool, then return to the client.

   • Not found: proceed to step 4.

4. The system reads the data page from the high-performance disk, loads it into the buffer pool, and returns it to the client.

BPE stores only clean pages — data pages that are consistent with the data files on the high-performance disk. Data files, binlog files, and redo log files are always stored on the high-performance disk, not in BPE. If BPE data is lost, service data is unaffected.

Prerequisites

Before you begin, make sure that your instance meets all of the following requirements:

• Database engine: MySQL 8.0, minor engine version 20230914 or later

• Edition: RDS High-availability Edition or Cluster Edition

• Product type: standard

• Instance type: general-purpose

• Region and zone: one of the following

Check the ApsaraDB RDS console to confirm supported regions and zones.

Billing

BPE is free for RDS MySQL general-purpose instances with high-performance disks.

Enable BPE

1. Go to the ApsaraDB RDS instance list, select a region at the top, and click the target instance ID.

2. In the Basic Information section, click Storage Type next to Configure Premium ESSD.

3. In the dialog box, turn on the Buffer Pool Extension (BPE) switch.

Disable BPE

1. Go to the ApsaraDB RDS instance list, select a region at the top, and click the target instance ID.

2. In the Basic Information section, click Storage Type next to Configure Premium ESSD.

3. In the dialog box, turn off the Buffer Pool Extension (BPE) switch.

Usage notes

• Enabling or disabling BPE causes approximately 30 seconds of downtime. Perform this operation during off-peak hours.

• BPE consumes memory equal to 4% of buffer_pool_size. When you enable BPE, the buffer_pool_size value is automatically reduced by 4%. Adjust buffer_pool_size based on your memory usage metrics if needed.

• Performance improvement scales with instance size. Larger instances see more significant gains.

• BPE loss does not affect service data. Service data is persistently stored on the high-performance disk.

Performance testing

The following test results compare QPS before and after enabling BPE on two instance types.

git clone https://github.com/akopytov/sysbench.git
cd sysbench
git checkout 0.5

yum -y install make automake libtool pkgconfig libaio-devel
yum -y install mariadb-devel

./autogen.sh
./configure
make -j
make install

# Prepare data
sysbench oltp_read_only --tables=30 --table_size=40000000 --rand-type=special --rand-spec-pct=15 --threads=64 --time=100 prepare

# Run test
sysbench oltp_read_only --tables=30 --table_size=40000000 --rand-type=special --rand-spec-pct=15 --threads=64 --time=100 run

# Prepare data
sysbench oltp_write_only --tables=30 --table_size=40000000 --rand-type=special --rand-spec-pct=15 --threads=64 --time=100 prepare

# Run test
sysbench oltp_write_only --tables=30 --table_size=40000000 --rand-type=special --rand-spec-pct=15 --threads=64 --time=100 run

# Prepare data
sysbench oltp_read_write --tables=30 --table_size=40000000 --rand-type=special --rand-spec-pct=15 --threads=64 --time=100 prepare

# Run test
sysbench oltp_read_write --tables=30 --table_size=40000000 --rand-type=special --rand-spec-pct=15 --threads=64 --time=100 run

Test results

4 cores, 8 GB (`mysql.n2.large.xc`):

• Read: no significant change

• Write: +30% QPS

• Mixed read/write: +26% QPS

8 cores, 16 GB (`mysql.n2.xlarge.xc`):

• Read: +80% QPS

• Write: +33% QPS

• Mixed read/write: +103% QPS

To observe real-time BPE performance on live RDS resources at no cost, see RDS high-performance disk I/O acceleration (BPE) performance observation.

See also

• Change ESSD to high-performance disk

• What is high-performance disk

• I/O burst feature

• Data archiving feature