Benchmark

Environment

• EC2 and the S3 bucket are located in the same region

fio

Create a 100GB test file:

fio --name=create_100gb_file \
    --filename=/mnt/fuse/100gb \
    --ioengine=libaio \
    --direct=1 \
    --group_reporting \
    --fallocate=none \
    --create_on_open=1 \
    --end_fsync=1 \
    --size=100000M \
    --rw=write \
    --bs=10M \
    --numjobs=1

Load the test file into local cache:

$ lsblk

$ sudo mkfs.xfs /dev/nvme1n1

$ sudo mkdir /mnt/fuse /data

$ sudo chmod 0777 /mnt/fuse /data -R

$ sudo mount /dev/nvme1n1 /data

$ sudo mapfs add vol_benchmark aws <AWSAccessKey> <AWSSecretKey> <S3-BucketName> <Region> cache_dir=/data

$ mapfs load /mnt/fuse/100gb

Read Performance with cache:

Network Write Performance:

fio --name=write_benchmark \
    --directory=/mnt/fuse \
    --ioengine=libaio \
    --direct=1 \
    --group_reporting \
    --fallocate=none \
    --create_on_open=1 \
    --end_fsync=1 \
    --runtime=60 \
    --time_based \
    --size=100G \
    --rw=write \
    --bs=<1M|4M|8M> \
    --numjobs=<1|32|128>

Note:

After each fio test, delete fio generated large test file from the Cloud Storage:

$ rm -f /mnt/fuse/write_benchmark.*

c6id Series: performance overview

With 1 NVME SSD instance storage.

Benchmark Results

c6id.large

c6id.xlarge

4 vCPU, 8GB RAM
On-Demand Linux pricing: 0.231 USD per Hour
Network: baseline 1.25Gbps (156MB/s), up to 12.5Gbps; VPC credits can be exhausted within one minute
NVME SSD: 1 x 237 GiB Instance Store

c6id.2xlarge

8 vCPU, 16GB RAM
On-Demand Linux pricing: 0.4620 USD per Hour
Network: Up to 12.5Gbps
NVME SSD: 1 x 474 GiB Instance Store

c6id.4xlarge

16 vCPU, 32GB RAM
On-Demand Linux pricing: 0.9240  USD per Hour
Network: Up to 12.5Gbps
NVME SSD: 1 x 950 GiB Instance Store

c6id.8xlarge

32 vCPU, 64GB RAM
On-Demand Linux pricing: 1.8480 USD per Hour
Network: 12.5Gbps
NVME SSD: 1 x 1900 GiB Instance Store

Performance Notes

1. c6id.large/xlarge/2xlarge/4xlarge: EBS and Network have a baseline performance, and burstable upper limit.

2. "mapfs mount <VolumeName> <MountPoint>" mounts in traditional mode by default;

To enable "fuse over iouring" mode, specify "iouring" during mount:

 $ mapfs mount <VolumeName> <MountPoint> iouring

Note:

Specifying iouring does not guarantee "fuse over iouring" will be enabled. It also requires Linux kernel version >= 6.18, typically from these distributions:

• Amazon Linux 2023, kernel 6.18
• Ubuntu 26.04

3. Advantages and limitations of iouring mode

Traditional mount: When CPU number exceeds 16 and IOPS exceeds 300K, a single lock contention point can cause CPU usage to spike while I/O performance may not improve or can even degrade greatly. The more CPUs added, the worse the performance degradation becomes, due to scheduling pressure, frequent L3 cache invalidations, and the single kernel spinlock CPU usage.

iouring mode mount: breaks single lock contention and scale up better when CPU number exceeds 16 and IOPS exceed 300K.

However, its limitation is that when IOPS exceed 1M and CPU number reaches 32 or more, fuse uring threads may degrade into polling mode, causing high CPU usage without a corresponding I/O performance increase.

4. Common benchmark bottlenecks:

• EBS Throughput and IOPS limitations
• c6id instances include an instance NVME SSD. If you use other instance types such as t3.small with an attached GP3 SSD volume, you will be limited by GP3 throughput and IOPS.
• Network bandwidth
• If you use burstable EC2 instances (such as t3 series), CPU performance may fluctuate between baseline and burst limits.