Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory leak in long running single test #4164

Open
Konstruktour opened this issue May 8, 2019 · 25 comments
Open

Memory leak in long running single test #4164

Konstruktour opened this issue May 8, 2019 · 25 comments

Comments

@Konstruktour
Copy link

@Konstruktour Konstruktour commented May 8, 2019

Current behavior:

Currently if a test runs the same actions repetitively over a long period of time, the memory of the cypress process increases until it crashes. (headless mode, video off, numTestsKeptInMemory 0)
The sample to reproduce runs 15 minutes increasing the memory ~300MB. (the longer the run the more memory is used..)

Desired behavior:

Performance tests should be possible with cypress, without increasing memory and crashing.

Steps to reproduce: (app code and test code)

Config cypress.json

{
  "baseUrl": "http://localhost:8080/",
  "defaultCommandTimeout": 60000,
  "viewportWidth": 1280,
  "viewportHeight": 720,
  "numTestsKeptInMemory": 0,
  "video": false
}

Cypress test

describe('memory dummy test', () => {
    const endTime = Date.now() + 60000 * 15;

    before('visit', () => {
        cy.visit('/memory-test.html');
    });

    it('should test', () => {
        const test = () => {
            cy.get('#testinput').clear().type('hello world');
            cy.wait(2000);
            cy.then(() => {
                if (Date.now() < endTime) test();
            });
        };
        test();
    });
});

Simple static html site

<!DOCTYPE html>
<html lang="en">
<head>
</head>
<body>
	<input id="testinput">
</body>
</html>

Versions

Cypress 3.2.0 / 3.5.0 / 3.6.0
Windows 10

@scharf
Copy link

@scharf scharf commented Jun 16, 2019

@brian-mann
Copy link
Member

@brian-mann brian-mann commented Jun 17, 2019

I actually believe this issue will be fixed by this PR which will be merged in the next patch release: #4406

@brian-mann
Copy link
Member

@brian-mann brian-mann commented Jun 17, 2019

It was an oversight / bug that we were still taking snapshots when a single test even though numSnapshotsKeptInMemory was 0 - so it's expected that the memory would grow larger after each command runs - until the next test runs.

@brian-mann
Copy link
Member

@brian-mann brian-mann commented Jun 17, 2019

Closing this issue as duplicate because I'm very confident this is describing the same behavior as #4104

@cypress-bot
Copy link

@cypress-bot cypress-bot bot commented Jun 27, 2019

Released in 3.3.2.

@Konstruktour
Copy link
Author

@Konstruktour Konstruktour commented Nov 4, 2019

@brian-mann / @jennifer-shehane: Retested it with version 3.6.0... still the same issue! :(

@Konstruktour
Copy link
Author

@Konstruktour Konstruktour commented Nov 8, 2019

@brian-mann / @jennifer-shehane: can this issue be reopened?

@jennifer-shehane
Copy link
Member

@jennifer-shehane jennifer-shehane commented Jan 3, 2020

This issue will be closed to further comment as the exact issue here was resolved and tested.

If you're experiencing a bug similar to this in Cypress, please open a new issue with a fully reproducible example that we can run. There may be a specific edge case with the issue that we need more detail to fix.

@cypress-io cypress-io locked as resolved and limited conversation to collaborators Jan 3, 2020
@cypress-io cypress-io unlocked this conversation Feb 5, 2020
@jennifer-shehane
Copy link
Member

@jennifer-shehane jennifer-shehane commented Feb 5, 2020

I ran the provided code and was unable to reproduce the crashing described in the original issue. The spec ran for 15 minutes and finished to completion in Cypress 3.8.3 in Electron 78.

*Couldn't fit log in one screenshot

Screen Shot 2020-02-05 at 10 27 56 PM

Screen Shot 2020-02-05 at 10 27 48 PM

There will be a new PR in 4.0 that will log process usage that would be helpful to see what is going on here memory wise #6171. How did you assess this is consuming more memory over time?

@Konstruktour
Copy link
Author

@Konstruktour Konstruktour commented Feb 5, 2020

thx for getting a look again at that issue...
the crashing only occurs if the system gets out of memory.. the consumption increases over time, 15 min will be too less see the crash ...
nevertheless you can track the memory consumption in the task manager..
eg the test started with ~100mb memory usage:
image

after 45min it increased to ~360mb ... and rising...
image

@Konstruktour
Copy link
Author

@Konstruktour Konstruktour commented Feb 13, 2020

@jennifer-shehane could u recreate the issue? any new findings?

@Oliboy50
Copy link

@Oliboy50 Oliboy50 commented Jul 18, 2020

@jennifer-shehane if you want another easily reproductible example
=> I guess I'm experiencing something similar in this project on cypress 4.10.0

it runs a single test which is pretty fast at the beginning and starts to be really slow after ~50 seconds of execution

I tried to use "numTestsKeptInMemory": 0 cypress configuration but it didn't help at all 🤷

if you want to try it out, please install node v12.x and run the following commands:

git clone https://github.com/Oliboy50/coinche.git
cd coinche

cd client
npm install
cd ..

cd server
npm install
cd ..

cd e2e
npm install
npm run dev

Cypress GUI will pop up and you'll be able to run the test I'm talking about

hope it will help (I'd love to have a faster test, one which does not make my computer burn ❤️)

@jennifer-shehane
Copy link
Member

@jennifer-shehane jennifer-shehane commented Oct 8, 2020

We're investigating some performance issues related to the rendering of the Command Log such as #6783 where I think the solution to that may also solve this issue. Will have to investigate once there is a proposed PR there.

@pardamike
Copy link

@pardamike pardamike commented Oct 9, 2020

Our team has worked around this issue by simply using:

launchOptions.args.push('--max_old_space_size=1500');
launchOptions.args.push('--disable-dev-shm-usage');

inside of our plugins/index.js

Note that we are on an older version of Cypress and older image, and we are running this on Gitlab CI:
package.json: "cypress": "^4.12.1"
.gitlab-ci.yml (image): name: cypress/included:4.9.0

Hopefully this can help someone else 👍

@Oliboy50
Copy link

@Oliboy50 Oliboy50 commented Oct 10, 2020

@pardamike I've tried to put the following in my plugin.js file but it didn't help (at least not in chrome view):

module.exports = (on) => {
  on('before:browser:launch', (_, launchOptions) => {
    launchOptions.args.push('--max_old_space_size=1500');
    launchOptions.args.push('--disable-dev-shm-usage');
  });
};

🤷

@pardamike
Copy link

@pardamike pardamike commented Oct 12, 2020

@Oliboy50 - Yea that looks good to me, for reference this is what we have in our plugins/index.js:

module.exports = (on, config) => {
    on('before:browser:launch', (browser = {}, launchOptions) => {
        if (browser.name === 'chrome') {
            launchOptions.args.push('--disable-web-security');
            launchOptions.args.push('--disable-site-isolation-trials');
            launchOptions.args.push('--max_old_space_size=1500');
            launchOptions.args.push('--disable-dev-shm-usage');
            return launchOptions;
        }
    });
}

You also may need to increase or decrease the max_old_space_size setting, 1500 worked for us but maybe you need more or less memory. I would try: 500, 1000, 2000, and 10000 and see if any of those work

If that does not work, I suggest trying out this logging package so you can see the exact error you are getting in the terminal when you run your pipeline: https://github.com/flotwig/cypress-log-to-output (for us, Cypress was swallowing the console errors)

You will need to use the "chromeWebSecurity": false, setting in your cypress/environments/cypress.{env}.json files, this logging package seems to make the browser ignore that flag for some reason

Note that we are on an older version of Cypress and older image, and we are running this on Gitlab CI:
package.json: "cypress": "^4.12.1"
.gitlab-ci.yml (image): name: cypress/included:4.9.0

@kaysan13
Copy link

@kaysan13 kaysan13 commented Oct 13, 2020

Hello,

After I made this modification, cypress displayed that the configuration is deprecated

@Oliboy50
Copy link

@Oliboy50 Oliboy50 commented Oct 31, 2020

Just updated cypress from 4.12.1 to 5.5.0 and it results in a huge performance improvement for my long running test 🎉
Thank you for your work 💪
=> I think that memory leaks are gone in 5.5.0, so I guess this issue could be closed now (if @Konstruktour agrees)

4.12.1:

  • GUI cypress-4_12_1
  • CI cypress-4_12_1-ci

5.5.0:

  • GUI cypress-5_5_0
  • CI cypress-5_5_0-ci

@norvinino
Copy link

@norvinino norvinino commented Nov 18, 2020

free memory from one test case to another in cypress

@norvinino
Copy link

@norvinino norvinino commented Nov 18, 2020

@ brian-mann / @ jennifer-shehane Free memory from one test case to another in cypress

@andrei22b
Copy link

@andrei22b andrei22b commented Dec 17, 2020

@Oliboy50 not really, i still have it in 6.0.0

@andrei22b
Copy link

@andrei22b andrei22b commented Dec 17, 2020

For me the problem was that it was keeping zombie processes in memory on the docker container.

I fixed it with running dumb init on that container Note this is for who uses docker

ADD https://github.com/Yelp/dumb-init/releases/download/v1.2.2/dumb-init_1.2.2_x86_64 /usr/local/bin/dumb-init
RUN chmod +x /usr/local/bin/dumb-init
ENTRYPOINT ["dumb-init", "--"]

@ronwongsk661
Copy link

@ronwongsk661 ronwongsk661 commented Jan 29, 2021

Any update on memory leak

@cuadllop
Copy link

@cuadllop cuadllop commented Feb 12, 2021

I am still having this issue too on 6.4.0

@reuben-rodrigues
Copy link

@reuben-rodrigues reuben-rodrigues commented Sep 30, 2021

8.5.0 as well...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
13 participants