By default, every Sprinters-powered runner comes with 10
GiB of temp storage (just like GitHub-hosted runners).
The type, the size and the performance of this temp storage are all fully configurable via the runs-on: label in your workflow yml.
There are 3 types of temp storage available: gp3, zram and ephemeral:
Type | Description | Availability | Size | Performance | EBS costs |
---|---|---|---|---|---|
gp3 |
gp3 EBS volume | all instance types | 1 to 65536 GiB(configurable, default: 10 GiB) |
3000 to 80000 IOPS(configurable, default: 3000 IOPS)150 to 2000 MiB/s throughput(configurable, default: 150 MiB/s) |
size, IOPS above 3000 and throughput above 150 MiB/s |
zram |
zstd-compressed RAM disk | all instance types | 1 GiB to 2x or 3x RAM size(default: 10 GiB) |
several million IOPS | None |
ephemeral |
instance store NVMe volume | instances with ephemeral NVMe storage only | 55 to 1770 GiB(depending on instance type) |
16771 to 3,219,996 IOPS(depending on instance type) |
None |
By default, the storage type is auto-selected based on the following criteria, in this order:
You can set the size of the auto-selected temp storage via the label:
runs-on: sprinters:aws:ubuntu-latest:m7i.large:temp=64
This will auto-select the optimal storage for the specified instance type using the formula above for 64
GiB of temp storage.
For the m7i.large
instance in this example, this will result in a 64
GiB gp3
EBS volume with 3000
IOPS and 150
MiB/s throughput.
The auto-selection can be overridden by explicitly specifying one of the available storage types below.
When all the temp storage fits in RAM, you can forego EBS entirely and use an ultra-fast zstd-compressed RAM disk instead:
runs-on: sprinters:aws:ubuntu-latest:temp=zram/16
This gives you the highest possible I/O performance and completely eliminates your EBS costs!
RAM is not pre-allocated and an empty zram temp disk does not use any memory. The size in the label merely serves as an upper bound for the size of the uncompressed data. Data you add to the zram disk is first zstd-compressed, and will, depending on how compressible it is, only consume about half or a third of its size in RAM. And when the runner terminates, the entire zram disk is automatically discarded.
A runner with 16
GiB RAM with compressible temp data can therefore easily accommodate a 16
GiB (or larger!) zram disk.
But remember that the RAM the zram disk occupies isn’t available to other processes. So, keep a close eye on usage
and consider moving to a larger or memory-optimzed instance if needed.
When using gp3
EBS volumes, by default a 10
GiB gp3
EBS volume with 3000
IOPS and 150
MiB/s throughput is attached to your instance as temp storage.
The volume is reformatted on every boot and destroyed after the job completes.
Unlike GitHub-hosted runners, Sprinters-powered runners are not restricted by a fixed amount of temp space. If your job needs more temp space, you do not need to resort to brittle hacks like deleting the preinstalled software using actions like jlumbroso/free-disk-space.
Instead, you can freely pick the exact amount of temp space you need, between 1
and 65536
GiB by specifying it in the label:
runs-on: sprinters:aws:ubuntu-latest:temp=gp3/256
EBS charges you by the allocated GiB. This makes it financially sound to right-size. Unfortunately, guessing the necessary capacity isn’t always easy. To guide you, Sprinters shows the actual temp usage at the end of every job run in the Complete runner section of the job output:
If your temp volume was say 100
GiB and utilization was 38%,
you can safely slash your EBS costs in half by adjusting its size to 50
GiB for future runs with enough room to spare:
runs-on: sprinters:aws:ubuntu-latest:temp=gp3/50
By default gp3
volumes are provisioned with 3000
IOPS and 150
MiB/s throughput.
For I/O-intensive jobs, Sprinters gives you full control over the performance (and EBS costs!) of your temp volume.
You can freely scale it from 3000
to 80000
IOPS and 150
to 2000
MiB/s throughput.
To do so, specify the desired IOPS (4000
in this example) and throughput (750
MiB/s in this example) in the label:
runs-on: sprinters:aws:ubuntu-latest:temp=gp3/100/4000/750
The exact EBS performance upper limits depend on the size and IOPS of the gp3
volume. The IOPS:GiB ratio is limited at 500:1
and throughput:IOPS ratio at 0.250:1. As this can be annoying to calculate, Sprinters lets you specify the convenience value max
for both IOPS and throughput to automatically calculate the maximum supported performance for the given volume size and IOPS.
To use the maximum supported number of IOPS for this size, you can therefore specify:
runs-on: sprinters:aws:ubuntu-latest:temp=gp3/100/max/750
Or the maximum supported throughput for these IOPS:
runs-on: sprinters:aws:ubuntu-latest:temp=gp3/100/4000/max
Or both:
runs-on: sprinters:aws:ubuntu-latest:temp=gp3/100/max/max
Instances that have ephemeral NVMe storage can make use of their much faster internal store volumes instead:
runs-on: sprinters:aws:ubuntu-latest:c6id.8xlarge:temp=ephemeral
The first ephemeral
volume of the instance is then fully used for temp storage.
In this case, with a c6id.large
instance,
this gives you 1900
GB of ephemeral storage with 536,666
IOPS and zero EBS costs!