Serverless out of memory

[romainquellec]

I'm trying to test and deploy serverless version of nextjs, with serverless framework.
At the build phase, this error below occurs :

<--- Last few GCs --->

[29376:0000025DFBC3CCB0]    63127 ms: Mark-sweep 1381.4 (1405.6) -> 1381.4 (1405.6) MB, 278.3 / 0.0 ms  (average mu = 0.114, current mu = 0.000) last resort GC in old space requested
[29376:0000025DFBC3CCB0]    63367 ms: Mark-sweep 1381.4 (1405.6) -> 1381.4 (1405.6) MB, 239.8 / 0.0 ms  (average mu = 0.061, current mu = 0.000) last resort GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 00000364E0CD0461]
    1: StubFrame [pc: 00000364E0CC69CB]
Security context: 0x012951a1d949 <JSObject>
    2: replace [0000012951A0F4E9](this=0x03813c38af09 <Very long string[4785407]>,0x018ac81410f9 <JSRegExp <String[18]: [<>\/\u2028\u2029]>>,0x018ac8141171 <JSFunction escapeUnsafeChars (sfi = 00000294E35792D9)>)
    3: default(aka serialize) [00000294E35797F1] [C:\Users\Romain\Documents\GitHub\front\node_modules\nex...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: 00007FF78C2FD50A v8::internal::GCIdleTimeHandler::GCIdleTimeHandler+4618
 2: 00007FF78C2A4F86 uv_loop_fork+79446
 3: 00007FF78C2A5C21 uv_loop_fork+82673
 4: 00007FF78C7ACAEE v8::internal::FatalProcessOutOfMemory+798
 5: 00007FF78C7ACA27 v8::internal::FatalProcessOutOfMemory+599
 6: 00007FF78CA85844 v8::internal::Heap::RootIsImmortalImmovable+14788
 7: 00007FF78CA83608 v8::internal::Heap::RootIsImmortalImmovable+6024
 8: 00007FF78C6440DB v8::internal::Factory::AllocateRawWithImmortalMap+59
 9: 00007FF78C646B5D v8::internal::Factory::NewRawTwoByteString+77
10: 00007FF78CA344A3 v8::internal::Smi::SmiPrint+483
11: 00007FF78C6414A3 v8::internal::CompilationJob::operator=+1155
12: 00007FF78CC62AAA v8::internal::VectorSlotPair::index+263610
13: 00000364E0CD0461

To Reproduce

My repo is pretty complex, but should be stable : https://github.com/CuistotduCoin/front
(yarn build)
I will try with a simpler version

System information

• OS: Windows,
• Version of Next.js: 8.0.1

[timneutkens]

Probably because you're adding components and other things to the pages directory 😅 It should only hold actual pages.

[romainquellec]

Are you talking about getPageContext, initApollo, theme & withData ?
If so, I will try after moving them elsewhere and give feedback tomorrow.

PS : For storybook, I store the stories close to the page, it this also a problem ?

[timneutkens]

I meant the storybook files and other components. they all becomes pages.

[romainquellec]

I followed your requirements but this issue is still one.

I tried with another repo, its working fine (https://github.com/romainquellec/boilerplate). I wil try to add parts to see whats going on.

[romainquellec]

This error comes from one broken page.
I knew this adding pages one by one. Maybe, I'm unlucky, but I guess there is no way to "compile" pages after pages to know the broken one ?
(I can close this issue and add this as a request)

[timneutkens]

@romainquellec could you expand on what solved it?

[romainquellec]

I dont really know now. Its seems related to "node-fetch" making a 'CriticalDependencyWarning' with a dynamic import.
I was not really using the page (was just a test), so I removed it.
I will close this, as my issue is resolved.

[zvictor]

EDIT: I was wrong! Only item * 3 below is right, 1 and 2 can be ignored.

---

I was also experiencing very similar memory leaks in the build process, even though I am not going for the serverless target yet.

Both cases seem to be a problem with serialize-javascript, so I forced mine to be updated to the latest version (1.6.1 instead of 1.4.0) and the error disappeared.

For future readers, I would recommend trying these:

1. Append to your package.json:

  ... 
  "resolutions": {
    "serialize-javascript": "1.6.1"
  },

2. try Terser

---

3. disable uglification:

// next.config.js
module.exports = {
  webpack(config) {
     config.optimization.minimize = false
  }
}

[timneutkens]

1. Append to your package.json:

Latest stable has "serialize-javascript": "1.4.0",

As you can see in the commits here nothing significant was changed:

https://github.com/yahoo/serialize-javascript/commits/v1.6.1

2. try Terser

This sounds like a weird recommendation, Next.js already uses Terser.

3. disable minification

The would probably work, downside being non-optimized JS.

[zvictor]

you are right!
I ran the build process a couple of times more and both 1 and 2 proved to be not enough.
only 3 saved me from the memory leak =/

[timneutkens]

I don't think it's a leak btw, it's just using a massive amount of resources to minify your pages 😄 Though I'm very willing to investigate this further, I have some plans for that already 👍

[MohammedFaragallah]

@timneutkens any news or ideas on this i can't go production without minification 😢
can i do the minification step before deployment to avoid host limited memory

[emplums]

I'm having this same issue, does anyone have tips for finding the culprit file?

[zvictor]

I managed to go around this problem by reviewing my project's structure. In my case, I had too many "supporting files" inside the /pages subfolders and I hadn't noticed that every single file there was being compiled as an independent page.

If you are running out of memory or it's just taking too long to build your app, I recommend double checking that it's not building more pages than needed.

In my case, as I wanted to keep my files structure, I had to find a way to flag which files should be compiled as pages and the only way I found to achieve that was using a different extension for them.

If you want to achieve the same, these are the steps:

1. Start with all files in your project as .js
2. The files you want compiled inside /pages you change to .jsx. (Don't forget the special pages, e.g. _app.jsx and _document.jsx)
3. In the configs add pageExtensions: ['jsx']

[timneutkens]

Note that it's generally better to move the components out of pages, especially on larger projects.

Does the next@canary build output help in showing you that all your components were compiled as pages too?

[stevez86]

Note that it's generally better to move the components out of pages, especially on larger projects.

@timneutkens Could you clarify? Do you mean importing a single component and exporting it in the page file?

[timneutkens]

@stevez86 basically every file in the pages directory becomes a page, meaning it will be bundled separately and affect chunking behavior, it makes builds slower if you have components turned into pages etc.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.