ApsaraDB for MongoDB:Reclaim disk space

After bulk data deletion

When you delete large amounts of data, disk space remains reserved for future writes. This creates unused fragmented space.

Long-running high-write workloads

Frequent insert, update, and delete operations cause fragmented space to accumulate over time.

Disk space constraints with >20% fragmentation

When disk utilization reaches 85-90% and fragmentation exceeds 20%, running compact reduces disk usage.

Step 1: Connect to your instance

Connect using Mongo Shell:

• Standalone Instance

• Replica Set Instance (connect to Secondary node to minimize impact)

• Sharded Cluster Instance

Step 2: Switch to the target database

use <database_name>

Run show dbs to view databases.

Step 3: Run the compact command

Before and after you run compact, you can run db.runCommand({collStats: "<collection_name>"}) in the target database to validate compact effect.

db.runCommand({compact:"<collection_name>"})

db.runCommand({compact:"<collection_name>",force:true})

{ "ok" : 1 }

db.runCommand({runCommandOnShard:"<Shard ID>","command":{compact:"<collection_name>"},$queryOptions: {$readPreference: {mode: 'secondary'}}})

{ "ok" : 1 }

Check storage size and fragmentation rate

To evaluate whether you need compact and to verify its effect, run the following command before and after compact in the database that contains the collection:

db.runCommand({collStats: <collection_name>})

Key fields:

• size: Total size of uncompressed data in the collection.

• storageSize: Total disk space allocated to the collection.

• freeStorageSize: The amount of storage space that can be reclaimed (available in MongoDB 4.4+).

Fragmentation rate = freeStorageSize / storageSize

A high ratio indicates high fragmentation.

Estimate reclaimable space

Switch to the database containing the collection, then run:

db.<collection_name>.stats().wiredTiger["block-manager"]["file bytes available for reuse"]

Example:

db.test_collection.stats().wiredTiger["block-manager"]["file bytes available for reuse"]

Sample output:

207806464

This indicates approximately 207,806,464 bytes (~198 MB) can be reclaimed.

Performance impact

Node rebuild risk

The following versions may trigger automatic node rebuilds:

Later versions: Nodes remain in SECONDARY state and do not trigger rebuilds.

For version details, see MongoDB minor version release notes.

When compact is ineffective

The compact command has no effect when:

• Physical collection size < 1 MB.

• Fragmentation rate < 20%.

• First 80% of file: available space < 20%.

• First 90% of file: available space < 10%.

Reference: WiredTiger block_compact.c#L140.

Other considerations

• Execution time: Depends on data volume and system workload.

• Space release: Released space may be less than available space. Ensure the previous compact completes before running the next.

• Disk full scenarios: compact can execute even when the disk is full and the instance is locked.

Error: "Compaction interrupted due to cache eviction pressure"

Cause: Small-specification instances on older versions may abort compact due to cache pressure.

Solution: Run the operation during off-peak hours when system load is lower.

How fragmentation occurs

When you delete data from an ApsaraDB for MongoDB instance, the storage space used by that data is marked as available for reuse. New data may be:

• Stored directly in the available space

• Stored at the end of the file after expanding file size

This results in unused available space scattered throughout the file—this is disk fragmentation.

Fragmentation impact

Higher fragmentation reduces effective disk utilization.

Example:

• Disk size: 100 GB

• Fragmented space: 20 GB

• Business data: 60 GB

• Reported disk utilization: 80% (60 GB + 20 GB)

• Effective disk utilization: 60% (only business data)

The 20 GB of fragmented space is counted as "used" but contains no data.

Command reference

For complete compact command documentation, see:

• MongoDB compact Command Reference

• collStats Output Fields