-
Notifications
You must be signed in to change notification settings - Fork 254
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 issue in regards to SSR #891
Comments
Does it keep growing after ~430mb? |
Sorry that was a little unclear - yes, it'll just keep growing until running out of memory; Of course the example with siege is a bit of an extreme one, because it makes ~1000 requests over the course of 30 seconds, but our staging environment crashes over the course of about an hour, with just the healthcheck calling the homepage every few minute or so. (I don't know if I can share our clients's theme here, but I think the same leak applies to the default themes). |
I can confirm I am having the same issue. This causes my local server to crash approx every 15-60 minutes. |
Ok. Would you mind trying packages one by one to see which one has the leak (or if it's the core)? Then we can trace back to see the exact point in time when that problem was introduced. |
I'm sorry, how would I go about that? Is there a theme which only uses the core, so I can add the others step by step and see when it starts leaking? |
Oh, I guess you can create a minimal theme then. Something like: const Root = () => (
<div>Empty theme</div>
);
const EmptyTheme = {
name: "empty-theme",
roots: {
theme: Root,
},
};
export default EmptyTheme; |
I've got the minimum theme I could observe the leak on here: I only managed to remove |
So the memory leak only happens if both are present? |
I can't really tell, since I didn't manage to get it to run without the router - at least not yet. |
Okay, I got it to run with @frontity/wp-source and @frontity/tiny-router individually, and I can only really reproduce it when both are present. |
It'd be great if we can narrow it down to the code. Is it only the package presence? Only by using connect? Or when accessing a specific part of the state? |
Hello @luisherranz, it's been a while, but I've got some more specific news this time: I've put together a small example in the test repo https://github.com/Bananicorn/frontity-memory-leaking-theme, just taking the minimal code from the official examples to fetch a menu from wordpress and display it. Steps to reproduce:
|
Under what circumstances will the connected Comp component change over time? Can you trace that down to a specific component to understand what's going on? |
Just wanted to confirm that for me the memory leak issue as become worse as well. My local server constantly crashes due to it. I have no idea what i have to do to provide some more info about the problem to help find the cause. LEt me know if I can contribute somehow. |
Even though I don't fully understand the problem, if those flags indeed cause a memory leak, these should fix it: @erdigokce, @DonKoko: would you mind testing it out? You can just replace this file in your |
Upon installing frontity locally with:
npx frontity create my-first-frontity-project
,npm run build && npm run serve
It seems as if the node application can't garbage collect all the memory allocated during requests.
It happens naturally when the site is called, but can be seen a bit more clearly when testing with siege, with the following command:
timeout 30s siege http://localhost:3000/
The memory spikes up, as expected for a stress test, but then settles on the following values: 279mb -> 330mb -> 381mb -> 430mb, and refuses to go down any further.
I thought it was only the case with my theme, since the docker instance it's running in would periodically run out of memory - but upon removing all prefetching for SSR, it stopped, and it also seems to be happening with the default themes.
For better local testing, I've also tried it with this (added to the package.json)
"inspect": "frontity build && node --inspect ./node_modules/frontity/dist/src/cli/index.js serve"
, which enables me to use the nodejs debugger in chromium, but I can't really make sense of the memory dumps there, except that they steadily increase in size.Locally, I'm running:
System:
Binaries:
Browsers:
npmPackages:
npmGlobalPackages:
I've tried searching the forums, but the closest thing I've found was this:
https://community.frontity.org/t/npx-frontity-dev-aborted-core-dumped-javascript-heap-out-of-memory/1321/9
But that seems like a slightly different problem.
Thank you for your time - and thank you for Frontity, it's been a joy to develop on so far!
The text was updated successfully, but these errors were encountered: