Not enough memory while testing a Node.js appplication


I’m facing this error while testing my Node.js application with Jest@0.20.3 on CircleCI 2.0 in a custom Docker image:

    ENOMEM: not enough memory, read
    at Error (native)
  at Object.fs.readSync (fs.js:732:19)
  at tryReadSync (fs.js:487:20)
  at Object.fs.readFileSync (fs.js:527:19)
  at Object.<anonymous> (modules/service-jobs/node_modules/aws-sdk/clients/all.js:38:20)

I’m not really sure what’s going as our tests are passing locally.

Any lead?


How much RAM do your tests use locally?
Were you testing on 1.0? Did you need extra resources there?

Just tested locally, they use ~1GB tops.

We are new customers and directly jumped in CircleCI 2.0.

Here is a link to a failing build: (not all the builds are failing).

1 Like

Seems like your _JAVA_OPTIONS aren’t being respected. Maybe you need a different key, like JAVA_OPTS?

Java should not be an issue here, I included this env var to limit the amount of memory allocated by (seen it here

I tried this solution after the first memory errors occurred on CircleCI.

Let me remove it :thumbsup:

I do think Java is part of the issue here. You’re running it in the background at the same time you’re trying to run JS tests, so you run out of memory.

Actually LocalStack will spawn several processes, I do agree this might cause an issue.

I will try to spawn LocalStack as a separate Docker container :ok_hand:

Do you confirm it will be automatically linked with the main container and that it will not share the same memory limit?

What do you mean by “linked”?

Correct, though; a separate container wouldn’t share the same 4GB RAM.

1/ I meant: any port exposed by the container will be available in the main container?

2/ Ok great for the ram :ok_hand:

That won’t be the case when it’s in the remote environment. That’s currently a limitation of the base docker executor.

Maybe you need to further limit the memory and keep it in the same container.

I was thinking of the Multiple images features, the ports should be available on localhost right?

Oh, sorry! Yes, those images share localhost. Any ports defined with EXPOSE will be automatically exposed.

Ok, so I managed to reduce the quantity of ram used by LocalStack by specifying the services I want to use. This seemed to have solve the issue :ok_hand:


Follow up: The errors kept popping, I had to split LocalStack to a separate container (leveraging the multiple images feature).

Now I would like to run containers from a non-primary image (ideally setup_remote_docker), is this something I can do? If not do you have any solution to offer?

1 Like

The only viable solution to that problem is more RAM, which you can contact to enquire about. As a fair warning, it’s only available to paid accounts.


Thanks @rohara!

I fixed jest memory issues by running it single threaded with -w 1. The container does have only 1 thread anyway.


This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.