k6 out of memory / too many VUs on the runner in CI

Each k6 virtual user costs memory, and a large script (big JSON payloads, SharedArray misuse) multiplies it. When the runner runs out of RAM the kernel kills k6 and the step exits without a summary.

What this error means

k6 stops abruptly with "signal: killed", exit code 137, or a Go runtime "out of memory" panic, often only at higher VU counts on a small runner.

runtime: out of memory: cannot allocate 1073741824-byte block (2147483648 in use)
fatal error: out of memory
signal: killed

Common causes

VU count exceeds runner memory

Thousands of VUs each hold their own JS state; the total exceeds the runner's RAM and the OOM killer terminates k6.

Per-VU data is not shared

Loading a large data file per VU instead of via SharedArray duplicates it across every VU and blows up memory.

How to fix it

Share static data across VUs

Load large datasets once with SharedArray so all VUs read from a single copy.

script.js

import { SharedArray } from 'k6/data';
const users = new SharedArray('users', () => JSON.parse(open('./users.json')));

Scale VUs to the runner or go distributed

Lower --vus to a count the runner can hold, or use a bigger runner.
Use arrival-rate executors so RPS is capped independent of VU memory.
Split very large tests across distributed load generators.

Terminal

k6 run --vus 500 --duration 2m script.js

How to prevent it

Load big datasets once via SharedArray, never per VU.
Size VU count to the runner memory available.
Prefer arrival-rate executors to decouple RPS from VU memory cost.