jest: Memory Leak when running multiple test. Especially with --runInBand

To run the global.gc() on each test, you just need to put afterEach (or afterAll) inside a setupFilesAfterEnv. This way, the function be called inside each test and after Jest module is initiated.

Inside jest.config.js:

{ 
  setupFilesAfterEnv: [
    '<rootDir>/force-gc'
  ]
}

Inside force-gc.js:

afterEach(() => {
  if (global.gc) global.gc()
})

No need to create a particular function on Jest.

I can’t provide example code which repeats this issue easily, as the code isn’t licensed such that I can share it, but my team sees an issue similar to this. jest consumes tons of memory and keeps eating memory until it runs into swap space. We’ve been able to fix this by manually running global.gc() in afterAll blocks.

It looks like something is stopping the garbage collector from running. It might be nice to have a setting in Jest to force the garbage collector to run when there’s only a specified percentage of available memory remaining, or something like that.

Our team is experiencing issues as well. I also can’t post the repo due to proprietary tech. It appears to be related to setup/teardown of internal jasmine. I’m seeing the same objects populate memory over and over again.

https://share.getcloudapp.com/4guxKGwn https://share.getcloudapp.com/kpumJvLL

Steps to reproduce:

1. Run the node inspector with Jest and log the usage: node --inspect-brk --expose-gc ./node_modules/jest/bin/jest.js --runInBand --logHeapUsage
2. Open chrome://inspect
3. Click the link to inspect the node instance
4. From the Sources tab, click the Play icon in the top right to Resume script execution. You will now see the Jest console begin running the tests. You can also pause the script execution with the Pause icon to stop Jest
5. Take heap snapshots
6. Profit

--expose-gc

We were struggling with java heapsize problems for the last month, with karma/jasmine and jest respectively. After several negative attempts we found one major problem in our test suites - we imported a module in almost all tests, which itself imported lots of google material modules. That caused all tests to run slow (compared to now) and lead to the heap size problems. We restructured our test suites (do not import large modules, mock everything that is not part of the current class under test, use TestBed only if necessary, do not compile the components, add NO_ERROR_SCHEMA etc). Now, we do not have heap space problems under karma/jasmine, and the tests run, as they should, very fast.

Unfortunately, we still get heap space disconnects in jest. Don’t know why.

Our team was able to stabilize heap size using this particular approach: https://github.com/integrations/slack/pull/895

We definitely have a memory leak but the leaks are not as significant as the ones we were previously experiencing. I hope this helps until we get a long term approach 👍

Turns out this issue is not because of our test suite. There’s something odd going on with Jest retaining multiple instances of files: https://github.com/facebook/jest/issues/7874

If it doesn’t affect performance negatively, then I’m in

While the leak is in user code and not jest’s code, I wonder if we should run the gc automatically after a run is complete? We already have code for it: https://github.com/facebook/jest/blob/084508290f4a90b28c3190021d3358ab1f753c3f/packages/jest-leak-detector/src/index.ts#L57-L68

Thoughts @jeysal @thymikee?

Yeah sorry should have mentioned it’s a Node option, not a Jest option

@jeysal well, this is not so obvious actually, because you can run jest like that "test": "jest

but in order to use this option, it should be run in this way "test": "node --expose-gc ./node_modules/.bin/jest