Docker image is consuming a lot of memory and cpu

I am running this docker image

FROM loadimpact/k6:master
COPY files files
CMD ["run", "test.js"]

The docker process grows in memory with time from 3 GBto 40 GB
Also, CPU consumption is growing from 5 CPUs to 16 CPU
If I run it without docker locally using k6 CLI it takes only 3 GB and CPU is way less
Is there a reason for that?

Hi @ibrahiem.94

Welcome to the community forum :wave:

Can you share the (sanitized) test.js script so we may have a look?

Locally, without dockers, are you running the same version of k6? Can you also share k6 version?

Do you see the same effect running the latest docker image grafana/k6:latest?

Thanks in advance for the info. With that we should be able to further dig into this.


The minimal code that I can share

import { check, group } from 'k6';
import { SharedArray } from 'k6/data';
import grpc from 'k6/net/grpc';
import {
} from './availability-api.js';
import { randomItems } from './helpers.js';

const hostname = __ENV.HOSTNAME;
const geid = __ENV.GEID;
const countryCode = geid.split('_')[1]

// customer coordinates array shared across VUs
const customerCoordinates = new SharedArray(`${countryCode} customer coordinates`, () => {
  return __ENV.CUSTOMER_COORDINATES.split(';').map(coordinate => {
    const coordinateSplit = coordinate.split(',')
    return {latitude: parseFloat(coordinateSplit[0]), longitude: parseFloat(coordinateSplit[1])};

export function setup() {
  let vendorIds = [];
  while (!vendorIds.length) {
    const customerCoordinate = randomItem(customerCoordinates);
    const response = getlistAvailableVendorsResponse(hostname, geid, customerCoordinate);
    vendorIds = => vendor.vendorId);
  return { vendorIds: vendorIds }

export function listAvailableVendors() {
  group('listAvailableVendors', () => {
    const customerCoordinate = randomItem(customerCoordinates);
    const response = getlistAvailableVendorsResponseStatus(hostname, geid, customerCoordinate);
    check(response, {
      'status is OK': (r) =>  r === grpc.StatusOK,

export const options = {
  userAgent: 'logistics-vendor-availability-k6/1.0',
  discardResponseBodies: true,
  scenarios: {
    listAvailableVendors: {
      executor: 'ramping-arrival-rate',
      exec: 'listAvailableVendors',
      preAllocatedVUs: __ENV.VUS_LIST,
      startRate: 1,
      timeUnit: '1s',
      stages: getStages('listAvailableVendors'),

function getStages(scenario) {
  const soakDuration = __ENV.SOAK_DURATION ? __ENV.SOAK_DURATION : '10s';

  if (scenario === 'listAvailableVendors') {
    return [
      { target: __ENV.WARM_UP_RPS, duration: __ENV.WARM_UP_DURATION },
      { target: __ENV.PEAK_RPS_LIST, duration: __ENV.RAMP_UP_DURATION },
      { target: __ENV.PEAK_RPS_LIST, duration: soakDuration },

function randomIntBetween(min, max) {
  return Math.floor(Math.random() * (max - min + 1) + min);

function randomItem(arrayOfItems){
  return arrayOfItems[Math.floor(Math.random() * arrayOfItems.length)];


import exec from 'k6/execution';
import grpc from 'k6/net/grpc';

const client = new grpc.Client();
client.load(['protorepo/protos/'], 'public_api.proto');

export function getlistAvailableVendorsResponse(hostname, geid, customerCoordinate) {
    if ( && === 0) {

    let data = { global_entity_id: geid, customer: { location: customerCoordinate } };
    let response = client.invoke(service_url, data, observabilityParams());
    return response;

export function getlistAvailableVendorsResponseStatus(hostname, geid, customerCoordinate) {
    let response = getlistAvailableVendorsResponse(hostname, geid, customerCoordinate);
    return response ? response.status : {};

function observabilityParams() {
    const startTime =;
    return {
        metadata: {
            'Traffic-Type': 'TESTING',
            'Accept-Encoding': 'gzip, deflate',
            'Request-Start-Instant': startTime.toString(),
            'Request-Expiry-Instant': (startTime + 1000).toString(),
        timeout: '1000',

my local version of k6 is k6 v0.43.1 ((devel), go1.20.1, darwin/arm64)
same behavior yes with both grafana/k6:latest and with alpine Linux with k6 installed in

1 Like

I shared the code above, thanks in advance.
I see the same effects yes running it on grafana/k6:latest and even with Alpine Linux with k6 installed on
my local k6 version is k6 v0.43.1 ((devel), go1.20.1, darwin/arm64)

1 Like


Thanks for sharing all the information. Initially we thought this might be related to the master image, as it includes new features not yet released. We can discard that if you are running locally with 0.43.1 and docker image grafana/k6:latest reproduces the same effect (it’s also 0.43.1).

Our thinking now goes to the scripts having different behavior, which we also need to look into. Can you also share the helpers.js one? It will help us reproduce this.

Knowing the concrete values instead of environment ones will also facilitate reproduction (__ENV.GEID, __ENV.HOSTNAME, __ENV.VUS_LIST, __ENV.SOAK_DURATION, etc.).

And finally, can you share the full outputs (including end summary) of both runs, when using grafana/k6:latest and locally? We might spot something that gives us a hint of what is causing the different behavior.


I can’t share the HOSTNAME unfortunately, but GEID is a string, VUS_LIST is 1000 and SOAK_DURATION is 30m for example.
The helper.js

import { randomItem } from '';

export function randomItems(list, size) {
  const items = new Array(size).fill(0);
  return => {
    return randomItem(list);

I will run the test and share the results with you later

but isn’t it weird that the docker image grows up so much but running through cli locally takes only 3 GB?
could be something related to the Garbage collector not freeing up space or something on the docker process?

Thanks for the additional info @ibrahiem.94

There are more variables that the script uses, HOSTNAME is not important, but __ENV.WARM_UP_RPS and __ENV.PEAK_RPS_LIST could be relevant. I also see __ENV.CUSTOMER_COORDINATES. Maybe you can share all the environment variables (sanitize the ones that you can’t share like HOSTNAME)?

We don’t know yet why the memory keeps growing, so our initial approach would be to run a similar scenario on our labs and see if we can reproduce it.

With the outputs we might be able to spot something as well that points to the root cause. And that is why we also asked for that.


1 Like

One thing to add this docker is running inside k8s pod with a limit of 16 CPU and a limit of 40 GB memory

Thanks @ibrahiem.94 , will you able to share the full outputs (including end summary) of both runs?

One thing to add this docker is running inside k8s pod with a limit of 16 CPU and a limit of 40 GB memory

Is anything else (other containers) in the pod, or just the k6 image/container?

Unrelated to this, just curiosity, have you tried the k6-operator? Or running on k8s as a regular pod?

It’s running as a normal pod and the container running alone in the pod

Good to know the pod only contains the k6 image, thanks! Will you be able to share the full outputs (including end summary) of both runs? Before creating the lab for the reproduction it’s good to have a look in case it contains clues as to what is causing the different behavior.