Fastest GitHub Actions runners: disk I/O.

How this shows up in real builds →

What the numbers say

Extremes on x64, and RAM against disk.

• On x64, one small read at a time (4k, QD1) comes back 84,854 times a second on Blacksmith 4 vCPU and 1,559 on RunsOn m8i.2xlarge · EBS gp3, 54× apart; p99 latency is 14 µs against 1,036 µs.
• Synced 4k writes on x64 run from 470 per second on RunsOn m8i.2xlarge · EBS gp3 (workspace mounted nobarrier) to 18,160 on Namespace 8x32.
• r8a.xlarge with tmpfs ($0.0021/min at spot) answers 1,054,041 QD1 reads and 912,188 synced writes per second: 87× and 77× the best local NVMe at 4 vCPU (i7i.xlarge, $0.0019) and 577× and 1,692× default EBS gp3 (m8a.xlarge, $0.0015); its workspace is 31 GiB, from RAM. (EC2 storage suite)

More findings20: EBS, arm64, NVMe vs EBS, provisioned gp3, tmpfs, storage classes

• Every EBS-backed workspace (3 AWS CodeBuild x64 runners, 25 RunsOn configurations and 3 Warpbuild configurations) answers between 1,559 and 1,842 QD1 reads and 470 to 562 synced writes per second, whoever runs it and whatever throughput it is provisioned for: each request is a round trip to network storage.
• On arm64, one small read at a time (4k, QD1) comes back 27,054 times a second on Warpbuild xfast (Apple M4 Pro) 6 vCPU and 1,660 on RunsOn m9g.large · EBS gp3, 16× apart; p99 latency is 39 µs against 963 µs.
• Synced 4k writes on arm64 run from 538 per second on Warpbuild 2 vCPU (workspace mounted nobarrier) to 16,257 on RunsOn m9gd.2xlarge · local NVMe.
• Same Xeon 6975P-C CPU, different disk: m8id.2xlarge on local NVMe answers 11,168 QD1 reads and 7,657 synced writes per second, m8i.2xlarge on EBS gp3 1,559 and 470.
• Same Xeon 6975P-C CPU, different disk: m8id.large on local NVMe answers 10,850 QD1 reads and 5,551 synced writes per second, m8i-flex.large on EBS gp3 1,745 and 527.
• Same Xeon 6975P-C CPU, different disk: m8id.xlarge on local NVMe answers 11,056 QD1 reads and 7,841 synced writes per second, m8i-flex.xlarge on EBS gp3 1,576 and 527.
• Same Neoverse-V3 CPU, different disk: m9gd.2xlarge on local NVMe answers 14,947 QD1 reads and 16,257 synced writes per second, m9g.2xlarge on EBS gp3 1,720 and 543.
• Same Neoverse-V3 CPU, different disk: m9gd.xlarge on local NVMe answers 12,610 QD1 reads and 11,264 synced writes per second, m9g.xlarge on EBS gp3 1,818 and 543.
• Same Neoverse-V3 CPU, different disk: m9gd.large on local NVMe answers 13,526 QD1 reads and 7,159 synced writes per second, m9g.large on EBS gp3 1,660 and 543.
• Provisioning gp3 at 1000 MiB/s on m8a.2xlarge takes sequential reads from 402 MiB/s to 1,002 MiB/s (2.5×); QD1 reads barely move (1,791 → 1,792 IOPS): it buys bandwidth, not latency.
• Provisioning gp3 at 1000 MiB/s on m8azn.xlarge takes sequential reads from 401 MiB/s to 1,002 MiB/s (2.5×); QD1 reads barely move (1,775 → 1,775 IOPS): it buys bandwidth, not latency.
• tmpfs on m8a.2xlarge is not a disk at all: 1,127,245 QD1 reads and 664,801 synced writes per second, from RAM. The workspace is 31 GiB, sized by memory.
• tmpfs on m9g.2xlarge is not a disk at all: 625,966 QD1 reads and 470,633 synced writes per second, from RAM. The workspace is 31 GiB, sized by memory.
• tmpfs on m9g.xlarge is not a disk at all: 674,926 QD1 reads and 634,741 synced writes per second, from RAM. The workspace is 15 GiB, sized by memory.
• tmpfs on r8a.2xlarge is not a disk at all: 1,098,003 QD1 reads and 877,674 synced writes per second, from RAM. The workspace is 62 GiB, sized by memory.
• tmpfs: 626k–1.1M QD1 reads and 471k–912k synced writes per second across 5 runners (5 RunsOn configurations).
• VM disk: 3.8k–85k QD1 reads and 578–18k synced writes per second across 42 runners from 7 providers (6 Avrea runners, 6 Blacksmith runners, 3 GitHub runners, 11 Namespace runners, 2 StarSling x64 runners, 9 Ubicloud runners and 5 Warpbuild runners).
• local NVMe: 11k–15k QD1 reads and 5.6k–16k synced writes per second across 9 runners (9 RunsOn configurations).
• network disk: 6.8k–8.6k QD1 reads and 3.3k–4.7k synced writes per second across 2 runners (2 GitHub runners).
• EBS: 1.6k–1.8k QD1 reads and 470–562 synced writes per second across 31 runners from 3 providers (3 AWS CodeBuild x64 runners, 25 RunsOn configurations and 3 Warpbuild configurations).

Reading these numbers

Most of a build is small, dependent I/O, not one big stream.

Why latency before throughput

• git checkout, npm install, cargo build and test runners read thousands of small files, each waiting for the last: the QD1 column. QD32 and sequential show what a parallel compiler, a big docker build or a cache archive can pull; read them after.
• Package managers, databases and SQLite-backed tests flush their writes. Each flush waits for the storage: network disks pay a round trip every time. That is sync write.

Every runner

Each provider's best disk first; its other machines sit behind +N more. Bars are log scale.

Pick the disk per job on RunsOn

• The instance type sets the storage under the workspace: EBS gp3 by default, provisioned gp3 for bandwidth, local NVMe on the d and i families, or tmpfs when the job fits in RAM. Pick it with the family label; each one, measured: EC2 storage benchmark.

How it's measured

Methodology →

fio runs inside the job, in GITHUB_WORKSPACE: the disk a build writes to, on the filesystem the provider mounted there. Every runner is compared, whatever its shape.

fio settingsblock sizes, queue depths, mounts

• QD1 random read: 4k blocks, one request in flight; IOPS and p99 latency.
• Sync write: 4k writes, each followed by fdatasync.
• Random read and write: 4k blocks, 4 jobs with 32 requests in flight each.
• Sequential read and write: 1M blocks, 32 requests in flight.
• The workspace filesystem, its size and its mount options come from the job's own mount table.
• Earlier versions of this page used a different harness and other fio settings on 2 vCPU runners; those numbers are gone rather than mixed in.