Closed OverseePublic closed 6 years ago
Also happens in the same repository in enzyme branch
We have the same problem in https://github.com/stylelint/stylelint/pull/3069
Tests finished:
$ npm run jest -- --logHeapUsage
$ npm run jest -- --runInBand --logHeapUsage
$ npm run jest -- --runInBand --logHeapUsage
I thought the problem could be because of our code. We run all our tests via custom testRule()
, which is included in setupFiles
configuration. But apparently, it's not our code problem. I replaced our setup file and testRule()
with a simple script:
'use strict';
global.testRule = () => {
test('test', () => {
expect(true).toBe(true);
});
};
Even with this script --runInBand
failed because of out of memory.
All of this is on Node.js 8.9.1 and npm 5.5.1. macOS 10.12.6 on MacBook Pro with 16GB memory.
Could the contributors / authors help us identify whether this is a bug or not?
Thanks.
Whenever you run with -i
, all tests are executed from the main process. This means that the memory consumption will grow as much as it can within one single process. On the other hand, when using multiple processes, the memory consumption is spread through them, thus reducing the memory per process used.
To get more accurate results, you should make sure that the GC is run after each test. Jest already does that, but it needs to be explicitly exposed. You can do that as a fast test by adding --expose-gc
to the node_modules/.bin/jest
shebang line.
Hmm, even with the --expose-gc
I get the increasing heap size. But the heap size is smaller. Maybe it's getting cleared more often?
#!/usr/bin/env node --expose-gc
> jest -i --silent --logHeapUsage
PASS __tests__/component.test.10000.js (203 MB heap size)
PASS __tests__/component.test.c.10000.js (364 MB heap size)
PASS __tests__/component.test.b.10000.js (514 MB heap size)
Test Suites: 3 passed, 3 total
Tests: 30000 passed, 30000 total
Snapshots: 0 total
Time: 12.667s
I also tested exposing and forcing global.gc()
in afterEach
hook in setupTestFrameworkScriptFile
and it hangs probably due to extra global.gc()
call I added.
Code is in branch force-clean
and the command is npm run test:i-gc
If the GC is exposed, it will automatically be ran after each test (see here). Running yourself the GC on the afterEach
should have no effect, as long as you are using --logHeapUsage
as well.
The memory growth you see from test to test is due to several reasons:
fs
or http.Server.prototype
). We are also trying to mitigate those (as in #4970), but these ones are way more complex.Hope that solves the mistery! 🙂
Gotcha! Thanks. I wondered whether I incorrectly setup the test. I will dig in and see if I can be a contribution :)
Thanks for the help / comments. Appreciated!
@hudochenkov I confirmed that the above PR fixes the leak in stylelint for Jest 22
That PR also fixes the --detectLeaks
argument. I ran your tests with this an I see a number of userland leaks you'll want to look into once this lands:
I think this can be closed:
stylelint
issue is tracked in https://github.com/facebook/jest/issues/5239@rickhanlonii thank you for your help!
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.
Reproducing project can be found:
https://github.com/OverseePublic/jest-memory-test
Without the -i
With the -i
Is this a memory bug or expected behavior?