Es imposible rastrear esto sin una reproducción.

Si lo se. Antes de obtener un montón de memoria sobre la generación de los mapas de origen, lo eliminé. Y recibí este mensaje de error alrededor del archivo de matriz nativo.

¿Hay alguna forma de obtener un seguimiento de pila más detallado?

Para su información, ahora se está construyendo, pero solo porque agregué más memoria al proceso del nodo:

NODE_OPTIONS="--max_old_space_size=4096"

Construye hasta 28 rutas pero cuando doy 30 rutas (tenemos 31 rutas) la memoria del proceso sube a 3GB de memoria (e incluso más). Estoy ejecutando el proceso de compilación en una computadora portátil promedio que tiene 8 GB de memoria, parte de la cual ya se usa. Pero se las arregló.

No sé si debería mantener este problema abierto o no.
Si ayuda, aquí las estadísticas de las páginas creadas:

El proceso se bloquea cuando intenta crear los mapas de origen (la mayoría de las veces).

Realmente, la única forma en que lo sabremos es si se proporciona una reproducción completa. Cerraré esto por ahora.

Nosotros también hemos notado que después de actualizar a Next 9 nos estamos quedando sin errores de memoria, mientras que con Next 8 esto no fue un problema.

En nuestro caso, estamos construyendo nuestra aplicación en CircleCi como parte de nuestro flujo de CI y encontramos lo siguiente:

Exited with code 137
Hint: Exit code 137 typically means the process is killed because it was running out of memory
Hint: Check if you can optimize the memory usage in your app
Hint: Max memory usage of this container is 4284268544
 according to /sys/fs/cgroup/memory/memory.max_usage_in_bytes

4GB es el límite de memoria para un contenedor CircleCI, de ahí el error. Parece que construyendo con Next 9 estamos alcanzando ese límite.

No tengo un caso reproducible para compartir en este momento.

También enfrentamos este problema al implementar mi aplicación con NextJs 9.

De los 3 proyectos que actualizamos a NextJs 9, dos de ellos enfrentan problemas de uso de RAM cuando se implementan en Elastic Beanstalk. Al final tenemos que revertirlo. Desafortunadamente, no tengo un repositorio para compartir para replicar el problema.

Estoy obteniendo el mismo problema de memoria, pero el mío ocurre después de que se construyen todas las lambdas. Puedo terminar la compilación en mi computadora portátil, pero se bloquea durante la implementación, sin embargo, he visto algunos problemas de memoria insuficiente periódicamente durante el desarrollo local. Lo único reconocible (para mí) es esta línea:

 readFile [/tmp/b0cc21aa63cece4e/.build-utils/.builder/node_modules/@now/next/dist/index.js:9555]

Aquí está el registro ...

Aug 22 2019 01:26:51:346 | λ  (Lambda)       page was emitted as a lambda (i.e. getInitialProps)
-- | --
Aug 22 2019 01:26:51:346 | ⚡  (Static File)  page was prerendered as static HTML
Aug 22 2019 01:26:51:434 | Done in 146.48s.
Aug 22 2019 01:26:51:444 | preparing lambda files...
Aug 22 2019 01:34:22:983 | <--- Last few GCs --->
Aug 22 2019 01:34:22:983 | [430:0x23f5310]   666594 ms: Mark-sweep 4089.3 (4262.1) -> 4089.3 (4261.1) MB, 3898.4 / 0.0 ms  allocation failure GC in old space requested
Aug 22 2019 01:34:22:983 | [430:0x23f5310]   671097 ms: Mark-sweep 4089.3 (4261.1) -> 4089.3 (4225.6) MB, 4502.8 / 0.0 ms  last resort GC in old space requested
Aug 22 2019 01:34:22:983 | [430:0x23f5310]   674990 ms: Mark-sweep 4089.3 (4225.6) -> 4089.3 (4223.1) MB, 3892.4 / 0.0 ms  last resort GC in old space requested
Aug 22 2019 01:34:22:983 | <--- JS stacktrace --->
Aug 22 2019 01:34:22:983 | ==== JS stack trace =========================================
Aug 22 2019 01:34:22:983 | Security context: 0x70e9f6257c1 <JSObject>
Aug 22 2019 01:34:22:983 | 1: toString [buffer.js:611] [bytecode=0x2833662c6061 offset=31](this=0xce2ca70dbc1 <Uint8Array map = 0x6cc06836709>,encoding=0x2fb750b822d1 <undefined>,start=0x2fb750b822d1 <undefined>,end=0x2fb750b822d1 <undefined>)
Aug 22 2019 01:34:22:983 | 2: arguments adaptor frame: 0->3
Aug 22 2019 01:34:22:983 | 3: readFile [/tmp/b0cc21aa63cece4e/.build-utils/.builder/node_modules/@now/next/dist/index.js:9555] [bytecode=0x1814135ff3e1 offset=53](t...
Aug 22 2019 01:34:22:983 | FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Aug 22 2019 01:34:22:983 | 1:
Aug 22 2019 01:34:22:984 | node::Abort() [/node8/bin/node]
Aug 22 2019 01:34:22:984 | 2:
Aug 22 2019 01:34:22:986 | 0x11e73ec [/node8/bin/node]
Aug 22 2019 01:34:22:986 | 3:
Aug 22 2019 01:34:22:986 | v8::Utils::ReportOOMFailure(char const*, bool) [/node8/bin/node]
Aug 22 2019 01:34:22:986 | 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/node8/bin/node]
Aug 22 2019 01:34:22:986 | 5: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/node8/bin/node]
Aug 22 2019 01:34:22:986 | 6:
Aug 22 2019 01:34:22:986 | v8::internal::Factory::NewStringFromUtf8(v8::internal::Vector<char const>, v8::internal::PretenureFlag) [/node8/bin/node]
Aug 22 2019 01:34:22:986 | 7:
Aug 22 2019 01:34:22:987 | v8::String::NewFromUtf8(v8::Isolate*, char const*, v8::NewStringType, int) [/node8/bin/node]
Aug 22 2019 01:34:22:987 | 8:
Aug 22 2019 01:34:22:987 | node::StringBytes::Encode(v8::Isolate*, char const*, unsigned long, node::encoding, v8::Local<v8::Value>*) [/node8/bin/node]
Aug 22 2019 01:34:22:987 | 9:
Aug 22 2019 01:34:22:988 | 0x12070d6 [/node8/bin/node]
Aug 22 2019 01:34:22:988 | 10:
Aug 22 2019 01:34:22:988 | v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) [/node8/bin/node]
Aug 22 2019 01:34:22:988 | 11:
Aug 22 2019 01:34:22:989 | 0xb79dac [/node8/bin/node]
Aug 22 2019 01:34:22:989 | 12:
Aug 22 2019 01:34:22:989 | v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) [/node8/bin/node]
Aug 22 2019 01:34:22:989 | 13: 0x47a70c842fd
Aug 22 2019 01:35:32:549 | done

Aquí está mi configuración de paquete web:

const loadConfig = require('./loadConfig');

const reNodeModules = /node_modules/;
const reScript = /\.(js|jsx|mjs)$/;
const reImage = /\.(bmp|gif|jpg|jpeg|png|svg)$/;
const reGraphql = /\.graphql?$/;
const reStyle = /\.(css|less|styl|scss|sass|sss)$/;

module.exports = (nextConfig = {}) => {
  return {
    ...nextConfig,
    webpack(config, options) {
      const { webpack, isServer, dev } = options;

      const staticAssetName = dev ? '[path][name].[ext]?[hash:8]' : '[name]-[hash:8].[ext]';
      const publicPath = '/_next/static/';
      const outputPath = `${isServer ? '../' : ''}static/`;

      // eslint-disable-next-line no-param-reassign
      config.resolve = {
        ...config.resolve,
        modules: [...config.resolve.modules, './src'],
      };

      config.module.rules.push(
        {
          test: reImage,
          exclude: reNodeModules,
          oneOf: [
            // Inline lightweight into CSS
            {
              issuer: reStyle,
              oneOf: [
                // Inline lightweight SVGs as UTF-8 encoded DataUrl string
                {
                  test: /\.svg$/,
                  loader: 'svg-url-loader',
                  options: {
                    name: staticAssetName,
                    limit: 4096, // 4kb
                    publicPath,
                    outputPath,
                  },
                },

                // Inline lightweight as Base64 encoded DataUrl string
                {
                  loader: 'url-loader',
                  options: {
                    name: staticAssetName,
                    limit: 4096, // 4kb
                    publicPath,
                    outputPath,
                  },
                },
              ],
            },

            // Or return public URL to image resource
            {
              loader: 'file-loader',
              options: {
                name: staticAssetName,
                publicPath,
                outputPath,
              },
            },
          ],
        }, // Rules for GraphQL
        {
          test: reGraphql,
          exclude: reNodeModules,
          use: [
            {
              loader: 'webpack-graphql-loader',
              options: {
                removeUnusedFragments: true,
                output: 'document',
              },
            },
          ],
        },
        {
          exclude: [reNodeModules, reScript, reImage, reGraphql, /\.json$/, /\.txt$/, /\.md$/],
          loader: 'file-loader',
          options: {
            name: staticAssetName,
            publicPath,
            outputPath,
          },
        },
      );

      const appConfig = loadConfig();
      if (isServer && dev) {
        console.info(appConfig);
      }
      config.plugins.push(
        new webpack.DefinePlugin({
          __DEV__: dev,
          __SERVER__: isServer,
          __BROWSER__: !isServer,
          __CONFIG__: JSON.stringify(appConfig),
        }),
      );

      if (typeof nextConfig.webpack === 'function') {
        return nextConfig.webpack(config, options);
      }

      return config;
    },
  };
};

@timneutkens Me estoy quedando sin memoria usando Next.js 9 también. Podría deberse a la cantidad de componentes que estamos compilando. Mencionaste que necesitabas una reproducción completa. Puedes echar un vistazo a mi rama.
https://github.com/stramel/styled-icons/tree/ms/add-material-variants

Aquí está la compilación fallida: https://travis-ci.org/jacobwgillespie/styled-icons/builds/582987078

Travis tiene NODE_OPTIONS=--max-old-space-size=4096 establecido

@timneutkens ¿ podría reabrir el problema ahora que tiene un repositorio?

Estoy enfrentando el mismo problema con [email protected].

Supongo que estas aplicaciones simplemente han alcanzado sus límites de tamaño para comenzar a quedarse sin memoria. Deberá ejecutar su compilación con más a través de NODE_OPTIONS=--max-old-space-size=4096 .

Alternativamente, puede habilitar nuestra nueva función de fragmentación:

// next.config.js
module.exports = {
  experimental: { granularChunks: true }
}

Gracias @Timer , granularChunks .

Además, solo para tener en cuenta, había intentado 8192 para el valor en mi máquina local y aún fallaba. Estoy un poco asustado de imaginar cuánta memoria necesitaría para construirlo.

Eché un vistazo a un problema antiguo y me di cuenta de que a veces, cuando había una nueva versión importante, algunas personas se enfrentaban a este problema de memoria. Me pregunto, ¿haces alguna prueba de memoria en algún gran proyecto?

Esta nueva versión importante está llegando al límite de la memoria del nodo. ¿Cuál es la causa de esta gran cantidad de memoria que no existía antes?

@Timer Intenté usar la función granularChunks y todavía encontré el mismo problema. Incluso localmente con el conjunto 8192.

Esto tiene el conjunto de características de configuración de fragmentos granulares https://github.com/stramel/styled-icons/tree/ms/granular-chunks

Cambiado a extraer componentes de forma dinámica, https://github.com/stramel/styled-icons/tree/ms/dynamic-import-granular-chunks

Este problema ocurre con uno de nuestros repositorios cuando cambiamos la compilación para realizar la minificación, que ahora está deshabilitada de forma predeterminada.

Actualización: determiné que en nuestra base de código el problema estaba usando el complemento withSourceMaps :

"@zeit/next-source-maps": "^0.0.4-canary.1"

Esto tiene sentido ya que lo tenemos configurado en hidden-source-map que es muy lento. Sin embargo, no sé por qué es exponencialmente más lento que NextJS 8.

También hemos notado problemas de rendimiento masivos después de actualizar a v9 ... Estoy usando una macbook pro 2015, nunca se ha retrasado antes y he ejecutado algunos programas bastante pesados ​​en ella, pero ahora cada vez que ejecuto mi próxima aplicación localmente se retrasa por completo y todo se ralentiza enormemente.

Por lo general, tengo que reiniciar la aplicación cada 10 minutos aproximadamente, hoy fue el primer día que intenté perseverar y trabajar en ella, y después de un par de horas de ejecución en movimiento de desarrollo obtuve el mismo JavaScript heap out of memory que la gente han informado de la ejecución de la siguiente compilación. Debe haber una fuga de memoria aquí en alguna parte

Yo también lo creo. Un colega mío tiene una MacBook más reciente y, desde que actualizamos a la próxima 9, el servidor de desarrollo se ha vuelto más lento para recompilar. A veces toma 20 segundos.

Tengo el mismo problema, incluso intenté establecer NODE_OPTIONS = 16384 en mi MacBook Pro de memoria física de 32 GB, pero sin efecto.

Los registros se enumeran:

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

    0: ExitFrame [pc: 0x335bafb5be3d]
Security context: 0x0fe28be1e6e9 <JSObject>
    1: createPrinter [0xfe25fe2c0b9] [/Users/my-name/my-project/node_modules/typescript/lib/typescript.js:~86713] [pc=0x335bb12e86f3](this=0x0fe280c03329 <Object map = 0xfe2df152cc9>,printerOptions=0x0fe2f39e8ae1 <Object map = 0xfe20ac205a9>,handlers=0x0fe28e1026f1 <undefined>)
    2: arguments adaptor frame: 1->2
    3: reportImplicitAny(aka reportImpli...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d035 node::Abort() [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 2: 0x10003d23f node::OnFatalError(char const*, char const*) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 3: 0x1001b8e15 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 4: 0x100586d72 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 5: 0x100589845 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 6: 0x1005856ef v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 7: 0x1005838c4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 8: 0x10059015c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 9: 0x1005901df v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
10: 0x10055fb24 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
11: 0x1007e7e04 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
12: 0x335bafb5be3d
13: 0x335bb12e86f3
14: 0x335bafb0a5c3

@timneutkens , vuelva a abrir este problema o abra uno nuevo. Esta pérdida de memoria, así como algunas solicitudes de HMR infinitas y extrañas, hacen que nuestra aplicación sea inutilizable en el modo de desarrollo y consumen una gran cantidad de nuestro tiempo.

Añadiendo otro testigo.
Heredé una aplicación con Next versión 4.2.3.

• Se actualizó a la próxima versión 9.1.3
• Se actualizó la versión de todos los demás paquetes en package.json;
• Eliminó la carpeta node_modules y package.lock.json
• ejecutó npm install

Cuando hice un servicio local del proyecto, falló con el siguiente error:
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
Por lo general, el error se produjo en menos de diez minutos después de iniciar la aplicación y podría acelerarse activando más navegación en la aplicación.

He vuelto a la versión 8.1.0 y no puedo reproducir el mismo error, incluso con una navegación más seria (y por lo tanto, creaciones de páginas).

Sí, también estamos viendo esto ...

Es hora de reabrir, creo que @timneutkens

También estoy enfrentando este problema en [email protected] con el servidor personalizado react-router desde ayer desde que comencé a importar bootstrap.min.css en mi modo de desarrollo.

tanto cuando importo directamente el bootstrap.min.css con require / import via js o @import via css / scss. mi memoria de nodejs utilizada se ha incrementado después de algunos cumplimientos durante el desarrollo.

pero cuando importo el bootstrap de cdn, vía en

<Head>
<meta key="viewport" name="viewport" content="initial-scale=1.0, width=device-width" />
<link key="bootstrapcdn" rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" ...  />
...
</Head>

así que creo que el problema estaba en la minificación css en next-css. porque cuando degrado mi proyecto a 8.1.0, tengo este problema de minificación. https://github.com/zeit/next-plugins/issues/541. así que probé esta solución alternativa (https://github.com/zeit/next-plugins/issues/392#issuecomment-475845330). y aún no volver a tener el problema de la memoria.

// next.config.js
const withCSS = require('@zeit/next-css');

function HACK_removeMinimizeOptionFromCssLoaders(config) {
  console.warn(
    'HACK: Removing 'minimize' option from 'css-loader' entries in Webpack config',
  );
  config.module.rules.forEach(rule => {
    if (Array.isArray(rule.use)) {
      rule.use.forEach(u => {
        if (u.loader === 'css-loader' && u.options) {
          delete u.options.minimize;
        }
      });
    }
  });
}

module.exports = withCSS({
  webpack(config) {
    HACK_removeMinimizeOptionFromCssLoaders(config);
    return config;
  },
});

Tengo el mismo problema después de actualizar a Next 9.1.3. También estoy usando next-css, ¿tal vez eso es lo que lo falla?

No estoy del todo seguro de si esto será igual para todos, pero asegúrese de verificar que se pueda encontrar cualquier recurso que esté solicitando. Tenía una imagen que mi aplicación no podía encontrar y siguió buscándola hasta que me dio el error de montón. Eliminé la mención de esa imagen y no me ha vuelto a dar el error.

También logré solucionar este problema, el comentario de @lloan ayudó a depurar el problema.

En mi caso, estaba haciendo referencia a /public/manifest.json como una etiqueta meta en <head/> , sin embargo, ese recurso no estaba presente en mi proyecto y esto estaba causando la pérdida de memoria.

Tenía este código, que el icon.png no existe

<Head>
  <link rel="icon" href="/static/icon.png" type="image/png" />
</Head>

Al arreglar la importación del favicon, ya no obtengo el error de fuga de memoria

<Head>
  <link rel="icon" href="/icon.png" type="image/png" />
</Head>

Como se mencionó https://github.com/zeit/now/issues/3307 , creo que algo está pasando con la carpeta static / public .

Yo tuve este problema también. Como lo mencionó bukinoshita, miré en la carpeta estática. Eliminé una carpeta de 674 archivos json (con fines de prueba) de la carpeta public/static/ . No tuve el problema desde entonces.

Este problema ocurre con uno de nuestros repositorios cuando cambiamos la compilación para realizar la minificación, que ahora está deshabilitada de forma predeterminada.

Actualización: determiné que en nuestra base de código el problema estaba usando el complemento withSourceMaps :

"@zeit/next-source-maps": "^0.0.4-canary.1"

Esto tiene sentido ya que lo tenemos configurado en hidden-source-map que es muy lento. Sin embargo, no sé por qué es exponencialmente más lento que NextJS 8.

Empecé a tener este problema también después de actualizar a "@zeit/next-source-maps": "^0.0.4-canary.1" . ¿Alguna solución o tendré que deshacerme de los mapas de origen?

@focux Tuve que deshabilitar los mapas de origen. Después de eso, el uso de memoria se redujo sustancialmente

Tengo el mismo problema aquí también. Parece fallar cuando el tamaño del archivo en la compilación es demasiado grande. Por ejemplo, importé algo de Typecript y el tamaño del archivo en la compilación subió a 2,41 mb. Entonces mi CI con 2GB de RAM comenzó a fallar. Después de eliminar la importación de TypeScript, el tamaño del archivo bajó a 100kb y funcionó nuevamente.

Nextjs 9 ha sido muy lento en CI desde el principio. Se necesita mucho tiempo para construir y no tengo ninguna necesidad especial ... solo reaccionar, material ui, algunos paquetes aquí y allá. Tengo CI: s en el mismo clúster con node / express, algunos dotnet core, php, etc., todos estos tienen 1 GB de memoria en CI y se compilan bastante rápido. No sé más de lo que mi sentimiento sobre el proceso de construcción tiene algún problema, ¿tal vez?

El mismo problema aqui. Acciones de Mac OS / Github. Ninguna acción mencionada aquí ayuda, no puedo encontrar ningún archivo que esté vinculado pero que no exista.

Sin embargo, el proyecto se construye (y está en producción) en Zeit Now.

Me encantaría ayudar si supiera cómo.

El mismo problema aquí (MacOS). Lo que encontré es:

• Empieza a suceder con Next 9.1.5 y 9.1.6. La degradación a 9.1.4 hace que el error desaparezca.
• Tengo mi propia compilación de _ckeditor_ dentro del proyecto, y su tamaño es de 606 KB. Si lo elimino, el problema desaparece.

Avíseme si puedo ayudar. Aquí tienes el registro de errores ...

<--- Last few GCs --->

[83442:0x102804000]   123060 ms: Scavenge 1371.3 (1422.4) -> 1370.7 (1422.9) MB, 8.3 / 0.0 ms  (average mu = 0.120, current mu = 0.058) allocation failure 
[83442:0x102804000]   123066 ms: Scavenge 1371.7 (1422.9) -> 1370.9 (1423.9) MB, 4.1 / 0.0 ms  (average mu = 0.120, current mu = 0.058) allocation failure 
[83442:0x102804000]   123071 ms: Scavenge 1371.7 (1423.9) -> 1371.0 (1424.4) MB, 3.9 / 0.0 ms  (average mu = 0.120, current mu = 0.058) allocation failure 


<--- JS stacktrace --->

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

    0: ExitFrame [pc: 0x3b944125be3d]
Security context: 0x164494d1e6e9 <JSObject>
    1: SourceMapConsumer_allGeneratedPositionsFor [0x16448b97d331] [/Users/alberto.iglesias/Coding/iteisa/projects/ceoe-gis/node_modules/@babel/core/node_modules/source-map/lib/source-map-consumer.js:~178] [pc=0x3b944240968c](this=0x1644193fb679 <BasicSourceMapConsumer map = 0x16448ea8a239>,aArgs=0x16447d082249 <Object map = 0x16448ea98939>)
    2: /* anonym...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d035 node::Abort() [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 2: 0x10003d23f node::OnFatalError(char const*, char const*) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 3: 0x1001b8e15 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 4: 0x100586d72 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 5: 0x100589845 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 6: 0x1005856ef v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 7: 0x1005838c4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 8: 0x10059015c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 9: 0x1005901df v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
10: 0x10055fb24 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
11: 0x1007e7e04 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
12: 0x3b944125be3d 
13: 0x3b944240968c 
Abort trap: 6

SourceMapConsumer_allGeneratedPositionsFor Creo que este es el culpable. En el modo de desarrollo hay una generación de mapas fuente. Creo que con el tiempo, este complemento de mapa de origen retiene demasiada memoria.

Sigo experimentando el mismo problema incluso si desactivo la generación de mapas de origen

Сергей.

El 24 de diciembre de 2019 a las 10:01 GMT, Emanuele [email protected] escribió:

SourceMapConsumer_allGeneratedPositionsFor creo que este es el culpable. En el modo de desarrollo hay una generación de mapas fuente. Creo que con el tiempo, estos complementos de mapas de origen retienen demasiada memoria.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub o cancele la suscripción .

Tenga en cuenta que publicar "Sigo experimentando esto" no resolverá el problema. Proporcione una reproducción completa para que la gente la vea; de lo contrario, su comentario es lo mismo que hacer un 👍 sobre el problema inicial pero hacer ping a todos en el problema sin ningún motivo.

Siempre asegúrese de que sus comentarios sean útiles o procesables. Por ejemplo, como ematipico, compartir cosas en función de la investigación del problema es útil. Decir "todavía tengo este problema" no es útil.

¿Hay algún trabajo alrededor? Mi canalización CI / CD falla en 1 GB de RAM.

Los pasos de reproducción de

https://github.com/zeit/next.js/issues/9442#issuecomment -554839437

La solución de

El problema relacionado ahora:

https://github.com/zeit/now/issues/3307

Solo para agregar a la discusión en caso de que ayude a alguien.
Estaba experimentando una falta de memoria y luego descubrí cuál era el problema en mi caso:

En el siguiente fragmento de código, si const Icon resulta ser undefined el código simplemente ingresa en un bucle infinito comprobando si el componente es válido.

const iconMapping = {
  "flash-outline": FlashOutline,
};

export const Icon = ({ name }) => {
  const Icon = iconMapping[name];

  return <Icon />;
}

Si agrego un cheque si const Icon no está definido, elimino el problema de falta de memoria.

...
  const Icon = iconMapping[name];

  if (!Icon) return null;
  return <Icon />;
}

A mí me pasó lo mismo, luego me di cuenta de que había un error tipográfico que lo había causado:

const Button = ({ children }) => {
  // BUG: the button should be lower case (the HTML input)
  //      instead of CamelCase (an undefined component)
  return <Button>{children}</Button>
}

Intente actualizar a la última versión de Next.js, recientemente hicimos un montón de optimizaciones en el uso de memoria.

@timneutkens , tengo la última versión (9.3.5). Creé el proyecto esta mañana y enfrenté ese error unos minutos después.

Tuve un problema similar en CricleCI al crear la aplicación con mapas de origen usando next-source-maps

NODE_OPTIONS="--max_old_space_size=4096" ayudó localmente, pero en CircleCI también necesita aumentar la clase de recurso https://circleci.com/docs/2.0/configuration-reference/#resource_class a large al menos para que funcione correctamente.

Comencé a recibir este error después de actualizar a la próxima 9.3.6 hoy:

<--- Last few GCs --->

[66325:0x108008000]    17639 ms: Mark-sweep 1936.2 (2071.4) -> 1923.6 (2073.4) MB, 283.4 / 0.0 ms  (average mu = 0.157, current mu = 0.048) allocation failure scavenge might not succeed
[66325:0x108008000]    17937 ms: Mark-sweep 1938.1 (2073.4) -> 1925.4 (2075.4) MB, 285.8 / 0.0 ms  (average mu = 0.108, current mu = 0.042) allocation failure scavenge might not succeed


<--- JS stacktrace --->

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

Security context: 0x0fb9ac667d09 <JSObject>
    0: builtin exit frame: stringify(this=0x0fb9ac6598a9 <Object map = 0xfb921b01449>,0x0fb958e804d1 <undefined>,0x0fb958e804d1 <undefined>,0x0fb910180ec1 <Object map = 0xfb9d8491399>,0x0fb9ac6598a9 <Object map = 0xfb921b01449>)

    1: arguments adaptor frame: 1->3
    2: callAsync [0xfb9320a6cf9] [0x0fb958e804d1 <undefined>:~1] [pc=0x1aa09fe84627](this=0x0fb9320a6909 <Hook map = 0xfb9d8495179>...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
...

Se corrigió modificando paths en tsconfig.json como se sugiere en # 12280

Probablemente una causa diferente

El mismo problema está presente aquí después de actualizar de 9.0.5 a 9.3.6.

Creating an optimized production build ..
<--- Last few GCs --->

[1600:0000020DB9FFEBE0]    26245 ms: Mark-sweep 1958.0 (2080.3) -> 1945.0 (2081.5) MB, 266.4 / 0.0 ms  (average mu = 0.179, current mu = 0.077) allocation failure scavenge might not succeed
[1600:0000020DB9FFEBE0]    26530 ms: Mark-sweep 1959.9 (2082.0) -> 1947.2 (2083.8) MB, 265.9 / 0.0 ms  (average mu = 0.127, current mu = 0.068) allocation failure scavenge might not succeed


<--- JS stacktrace --->

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

    0: ExitFrame [pc: 00007FF77B4D4DDD]
Security context: 0x00e7d00c08d1 <JSObject>
    1: /* anonymous */(aka /* anonymous */) [000002BB3E5CAA29] [C:\Users\...\node_modules\enhanced-resolve\lib\UnsafeCachePlugin.js:~27] [pc=00000147695447FC](this=0x00d9404004b1 <undefined>,0x001a9e083681 <Object map = 000003D51551D3A9>,0x001a9e0838d9 <Object map = 000003D515521AE9>,0x001a9e083979 ...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 00007FF77A8D363F napi_wrap+128063
 2: 00007FF77A872836 v8::base::CPU::has_sse+35142
 3: 00007FF77A8734F6 v8::base::CPU::has_sse+38406
 4: 00007FF77B089F4E v8::Isolate::ReportExternalAllocationLimitReached+94
 5: 00007FF77B072021 v8::SharedArrayBuffer::Externalize+833
 6: 00007FF77AF3E57C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1436
 7: 00007FF77AF497D0 v8::internal::Heap::ProtectUnprotectedMemoryChunks+1312
 8: 00007FF77AF462F4 v8::internal::Heap::PageFlagsAreConsistent+3204
 9: 00007FF77AF3BB13 v8::internal::Heap::CollectGarbage+1283
10: 00007FF77AF3A184 v8::internal::Heap::AddRetainedMap+2452
11: 00007FF77AF5C734 v8::internal::Factory::NewInternalizedStringImpl+132
12: 00007FF77AD9C7FD v8::internal::DescriptorArray::Allocate+4941
13: 00007FF77ADAD0C5 v8::internal::StringTable::LookupString+373
14: 00007FF77AAAF356 v8::internal::Factory::InternalizeName+54
15: 00007FF77ACAB0BE v8::internal::Runtime::GetObjectProperty+9662
16: 00007FF77B4D4DDD v8::internal::SetupIsolateDelegate::SetupHeap+546637
17: 00000147695447FC

¿Alguna idea?

@szaza, ¿puedes probar next@canary caso más probable es que tengas el problema que se describe aquí: https://github.com/zeit/next.js/issues/12280

Ok, después de eliminar node_modules y reinstalar las dependencias, parece que funciona con la versión canary, sin embargo, ahora tengo otro error: Cannot find module 'next-server/dist/server/next-server'. . ¿Te parece familiar?

Oh, lo tengo, se ha movido a import Server from "next/dist/next-server/server/next-server"; .
Ahora funciona bien. ¡Gracias por tu ayuda!

@szaza ¿cómo terminaste importando ese módulo en tu proyecto? ¿Es un módulo interno? ¿Supongo que pretendías importar 'next' lugar?

Estoy trabajando en un gran proyecto escrito en TypeScript. Hay un middleware de autenticación de pasaportes configurado, que redirige a los usuarios no autorizados a la página de inicio de sesión. Se implementa de la siguiente manera:

import Server from "next-server/dist/server/next-server";
...
export const initPassport = (
    server: Express,
    app: Server,
    authStrategies: string[]
) => {
...
return app.render(req, res, AuthRoutes.LOGIN_PAGE);
...
}

Después de actualizar la próxima versión de 9.0.5 a 9.3.7-canary.0, Server type ya no se pudo importar desde next-server/dist/... , sino desde la ruta mencionada anteriormente.

Tuve el mismo error cuando actualicé todas las bibliotecas en mi package.json. Actualmente estoy usando NextJS 9.2.2 con @ zeit / next-css sin ningún problema. Parece que alguna versión de las bibliotecas surge de un problema de memoria o de alguna manera entran en conflicto con NextJS.

Mi configuración de paquete actual es -

{
"dependencies": {
    "@zeit/next-css": "^1.0.1",
    "axios": "^0.19.2",
    "body-parser": "^1.19.0",
    "compression": "^1.7.4",
    "cookie-parser": "^1.4.4",
    "cookie-session": "^1.4.0",
    "express": "^4.17.1",
    "helmet": "^3.21.3",
    "json-server": "^0.16.1",
    "morgan": "^1.9.1",
    "next": "^9.2.2",
    "passport": "^0.4.1",
    "passport-local": "^1.0.0",
    "passport-strategy": "^1.0.0",
    "prop-types": "^15.7.2",
    "react": "^16.13.0",
    "react-dom": "^16.13.0",
    "react-mathjax2": "0.0.2",
    "shaka-player": "^2.5.10",
    "styled-components": "^5.0.1"
  },
  "devDependencies": {
    "@babel/cli": "^7.8.4",
    "@babel/core": "^7.9.0",
    "@babel/preset-env": "^7.8.6",
    "@babel/preset-react": "^7.8.3",
    "babel-jest": "^25.1.0",
    "babel-plugin-module-resolver": "^4.0.0",
    "babel-plugin-styled-components": "^1.10.7",
    "enzyme": "^3.11.0",
    "enzyme-adapter-react-16": "^1.15.2",
    "jest": "^25.1.0",
    "react-test-renderer": "^16.13.0"
  }
}

Reduje mi problema particular al uso de la biblioteca https://github.com/google/schema-dts. Cuando las definiciones de tipo de esta biblioteca se estaban utilizando en mi aplicación Next, la compilación nunca se completó, los fanáticos de Macbook alcanzan la máxima potencia y, finalmente, escupieron un archivo json de informe OOM en la raíz del proyecto.

Depurado el problema eliminando todas las páginas menos una de pages/ y eliminando el código hasta que se compiló el proyecto y luego volviendo a colocar el código gradualmente.

Tal vez esto ayude a alguien que se encuentre con este hilo 🤷‍♂️

Tuve un problema similar en CricleCI al crear la aplicación con mapas de origen usando next-source-maps

NODE_OPTIONS="--max_old_space_size=4096" ayudó localmente, pero en CircleCI también necesita aumentar la clase de recurso https://circleci.com/docs/2.0/configuration-reference/#resource_class a large al menos para que funcione correctamente.

Esto es lo único que funcionó para nosotros 👍

En una aplicación Next.js bastante grande (v9.3.6), varios de nosotros nos encontrábamos con problemas de falta de memoria en el montón al iniciar la aplicación (modo dev), para lo cual la configuración NODE_OPTIONS="--max_old_space_size=4096" ayudó para el nodo 10, o alternativamente Nodo 12 y posteriores, esto se soluciona con esta confirmación y otra que tiene en cuenta la cantidad de memoria asignada a un contenedor (Linux solo afaik).

Solo para agregar a la discusión en caso de que ayude a alguien.
Estaba experimentando una falta de memoria y luego descubrí cuál era el problema en mi caso:

En el siguiente fragmento de código, si const Icon resulta ser undefined el código simplemente ingresa en un bucle infinito comprobando si el componente es válido.

const iconMapping = {
  "flash-outline": FlashOutline,
};

export const Icon = ({ name }) => {
  const Icon = iconMapping[name];

  return <Icon />;
}

Si agrego un cheque si const Icon no está definido, elimino el problema de falta de memoria.

...
  const Icon = iconMapping[name];

  if (!Icon) return null;
  return <Icon />;
}

¿Cómo averiguaste que este es el fragmento de código que causó este problema?

Lo suficientemente interesante, mirando este código de nuevo, en realidad veo otro
problema. El icono es un componente y dentro del icono estaba haciendo referencia al icono.
sí mismo.

La forma en que lo averiguo fue principalmente aislando componente por componente y
Intento reproducir el problema hasta que descubra qué componente estaba provocando
ese.

El jueves 21 de mayo de 2020 a las 18:20, Vivek_Neel [email protected] escribió:

Solo para agregar a la discusión en caso de que ayude a alguien.
Estaba experimentando una falta de memoria y luego descubrí cuál era la
problema en mi caso:

En el siguiente fragmento de código, si el icono const no está definido
el código simplemente entra en un bucle infinito comprobando si el componente es válido.

const iconMapping = {
"flash-outline": FlashOutline,
};
export const Icon = ({nombre}) => {
const Icon = iconMapping [nombre];

regreso ;
}

Si agrego una marca de verificación si el ícono const no está definido, me deshago del
problema de memoria.

...
const Icon = iconMapping [nombre];

si (! Icono) devuelve nulo;
regreso ;
}

¿Cómo averiguaste que este es el fragmento de código que causó esto?
¿problema?

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/zeit/next.js/issues/7929#issuecomment-632187103 , o
darse de baja
https://github.com/notifications/unsubscribe-auth/ABA2CL7ZJQY5YPYJVCJMCODRSVIE7ANCNFSM4ICM4RAA
.

>

Enviado desde mi teléfono

Por lo que tengo entendido, Next.js (desde v9.0.0) no puede optimizar la memoria de grandes aplicaciones web. Nuestro proceso de compilación alcanza el límite de memoria cuando comienza a compilar la parte del lado del servidor del proyecto.

Durante el modo de desarrollo, el servidor local está bien inicialmente, pero después de un tiempo, la memoria asignada explota y aparece el error del montón de memoria.

¿Podría alguien del equipo central reconocer este problema y ayudarnos a clasificar el problema?

Mi equipo y yo, incluso con portátiles potentes, a veces no podemos crear la aplicación localmente. Este problema tiene casi 1 año, pero no ha habido una actualización clara sobre el problema. Personalmente, la única solución que se me ocurre es dividir la aplicación en dos proyectos secundarios Next.js porque me preocupa que algún día ni siquiera podamos construir la aplicación incluso en el CI (y ya estamos usando potentes VM para hacerlo).

Siento mucho ser el malo aquí, solo estoy buscando ayuda.

EDITAR: actualizamos a Next.js 9.3.3 pero no ha habido mejoras

¿Podría alguien del equipo central reconocer este problema y ayudarnos a clasificar el problema?

Le he pedido varias veces en este hilo que proporcione una reproducción completa o que proporcione su solicitud. No podemos analizar nada en su aplicación particular para rastrear el problema en su aplicación.
Hemos cambiado la generación de mapas de origen en 9.4 por cierto, por lo que definitivamente debería actualizar a la última versión.

Los casos de FWIW como https://github.com/zeit/next.js/issues/7929#issuecomment -618297553 son bucles infinitos creados dentro de su aplicación y no podemos detectarlos muy bien (ya que terminan pasando por el renderizado React ).

Por lo que tengo entendido, Next.js (desde v9.0.0) no puede optimizar la memoria de grandes aplicaciones web. Nuestro proceso de compilación alcanza el límite de memoria cuando comienza a compilar la parte del lado del servidor del proyecto.

Dado que no proporcionó una reproducción, solo puedo hacer referencia a nuestras propias aplicaciones.

Ejecutamos millones de solicitudes en Next.js y las aplicaciones que ejecutamos tienen más de 300 páginas. Nuestros equipos no han informado problemas de memoria y trabajan en muchas páginas a lo largo del día.

Tenga en cuenta que no estoy negando que pueda haber un problema, solo digo que es imposible rastrear si hay un problema si no va a proporcionar una reproducción clara o una aplicación que podamos perfilar.
También tenga en cuenta que ni siquiera estoy pidiendo que eso sea una consultoría pagada, echaremos un vistazo a la aplicación de forma gratuita.

Le he pedido varias veces en este hilo que proporcione una reproducción completa o que proporcione su solicitud. No podemos analizar nada en su aplicación particular para rastrear el problema en su aplicación.

Otras personas han proporcionado repositorios aquí desde que abrí el problema. Es por eso que se reabrió el problema y por eso no tiene la etiqueta que dice que se requiere un repositorio para reproducir el problema.

• https://github.com/zeit/next.js/issues/7929#issuecomment -529756317

Desde que se dejó abierto

No puedo proporcionar un repositorio porque la aplicación web pertenece a mi cliente y el código fuente está cerrado.

Hemos cambiado la generación de mapas de origen en 9.4 por cierto, por lo que definitivamente debería actualizar a la última versión.

¿Esta función se habilita o se excluye? Eliminé la generación de mapas de origen (se hizo a través de un complemento) después de abrir el problema (hace tanto tiempo) pero no ayudó mucho.

Si cree que este problema no es válido, ciérrelo. El repositorio se compartió hace mucho tiempo y es posible que ya no sea válido.

Puedo ayudar con la clasificación, pero necesito orientación.

▲  styled-icons (master) ✗ yarn build:ci
yarn run v1.22.4
$ lerna run build
lerna notice cli v3.21.0
lerna info Executing command in 25 packages: "yarn run build"
lerna info run Ran npm script 'build' in '@styled-icons/styled-icon' in 6.6s:
$ tsc --project tsconfig.esm.json && mv dist/index.js dist/index.esm.js && tsc --project tsconfig.json
lerna ERR! yarn run build exited 1 in '@styled-icons/boxicons-logos'
lerna ERR! yarn run build stdout:
$ build-pack
Reading icon packs...
Error reading icons from pack
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

lerna ERR! yarn run build stderr:
error Command failed with exit code 1.

lerna ERR! yarn run build exited 1 in '@styled-icons/boxicons-logos'
lerna WARN complete Waiting for 4 child processes to exit. CTRL-C to exit immediately.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

La reproducción no se puede ejecutar, por eso le pedí a todas las personas que informaron aquí que también proporcionaran una reproducción para evitar casos como este. Además, la posibilidad de que estos problemas sean 100% iguales es bastante baja.

¿Esta función se habilita o se excluye? Eliminé la generación de mapas de origen (se hizo a través de un complemento) después de abrir el problema (hace tanto tiempo) pero no ayudó mucho.

Los mapas de origen siempre están habilitados en desarrollo, sin embargo, cambiamos a mapas de origen de evaluación.

Es por eso que se reabrió el problema y por eso no tiene la etiqueta que dice que se requiere un repositorio para reproducir el problema.

Lo volví a abrir porque seguían llegando más informes y seguía pidiendo reproducciones: https://github.com/zeit/next.js/issues/7929#issuecomment -568760542

Solo se proporcionan 2 reproducciones en este hilo. Uno no está relacionado en absoluto con Next.js ( now dev consumo de memoria) y el otro no se puede ejecutar / construir.

Por eso, una vez más, pido una reproducción completa, de lo contrario, esto seguirá siendo imposible de investigar.

No puedo proporcionar un repositorio porque la aplicación web pertenece a mi cliente y el código fuente está cerrado.

No dude en comunicarse con [email protected] y podemos configurar un NDA, potencialmente esto significa que tendremos que asesorarlo por usted, dado que tomará una cantidad significativa de tiempo configurar todo esto solo para ayudarlo con su aplicación particular y también está creando la aplicación para un cliente.

Supongo que estas aplicaciones simplemente han alcanzado sus límites de tamaño para comenzar a quedarse sin memoria. Deberá ejecutar su compilación con más a través de NODE_OPTIONS=--max-old-space-size=4096 .

Alternativamente, puede habilitar nuestra nueva función de fragmentación:

// next.config.js
module.exports = {
  experimental: { granularChunks: true }
}

Esto no resolvió nuestro problema, FYI.

¿Alguien sabe si este problema ocurre en el próximo inicio del servidor incorporado?
es decir: Next start lugar de NODE_ENV=production node server.js" ?

Mi problema surge después de generar la compilación. En mi servidor personalizado que ejecuta "node server.js", acumula memoria hasta que recibo ese error y el proceso se reinicia, lo que significa que pierde todas las rutas en caché y todo eso, por lo que es realmente lento para el primer usuario que ingresa a las páginas después de eso todo el SSR está sucediendo.

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
0|profiles |  1: 0xa093f0 node::Abort() [node /home/projects/profiles/server.js]
0|profiles |  2: 0xa097fc node::OnFatalError(char const*, char const*) [node /home/projects/profiles/server.js]
0|profiles |  3: 0xb842ae v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node /home/projects/profiles/server.js]
0|profiles |  4: 0xb84629 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node /home/projects/profiles/server.js]
0|profiles |  5: 0xd30fe5  [node /home/projects/profiles/server.js]
0|profiles |  6: 0xd31676 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node /home/projects/profiles/server.js]
0|profiles |  7: 0xd3def5 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node /home/projects/profiles/server.js]
0|profiles |  8: 0xd3eda5 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node /home/projects/profiles/server.js]
0|profiles |  9: 0xd4185c v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node /home/projects/profiles/server.js]
0|profiles | 10: 0xd0830b v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node /home/projects/profiles/server.js]
0|profiles | 11: 0x1049f4e v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node /home/projects/profiles/server.js]
0|profiles | 12: 0x13cf019  [node /home/projects/profiles/server.js]

Este es mi package.json

{
  "name": "profiles",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "node server.js",
    "build": "yarn relay && next build",
    "start": "NODE_ENV=production node server.js",
    "relay": "relay-compiler --src ./ --exclude '**/.next/**' '**/node_modules/**' '**/test/**'  '**/__generated__/**' --exclude '**/schema/**' --schema ./var/schema.graphql --artifactDirectory __generated__",
    "relay-get-schema-stage": "graphql get-schema --project sourcr --endpoint stage && yarn run relay",
    "relay-get-schema-prod": "graphql get-schema --project sourcr --endpoint prod && yarn run relay",
    "relay-get-schema-dev": "graphql get-schema --project sourcr --endpoint dev && yarn run relay",
    "pm2": "pm2"
  },
  "dependencies": {
    "@babel/plugin-proposal-class-properties": "^7.10.4",
    "@babel/plugin-proposal-decorators": "^7.10.5",
    "@babel/plugin-proposal-export-default-from": "^7.10.4",
    "@babel/plugin-proposal-optional-chaining": "^7.11.0",
    "@babel/plugin-syntax-dynamic-import": "^7.8.3",
    "@babel/plugin-transform-runtime": "^7.11.0",
    "@fortawesome/fontawesome": "^1.1.8",
    "@fortawesome/fontawesome-free-regular": "^5.0.13",
    "@fortawesome/fontawesome-free-solid": "^5.0.13",
    "@fortawesome/react-fontawesome": "^0.1.11",
    "@sentry/browser": "^5.21.0",
    "@svgr/webpack": "^5.4.0",
    "babel-loader": "^8.1.0",
    "babel-plugin-styled-components": "^1.11.1",
    "babel-plugin-transform-export-extensions": "^6.22.0",
    "bootstrap": "^4.5.2",
    "classnames": "^2.2.6",
    "file-loader": "^6.0.0",
    "formsy-react": "^1.1.5",
    "graphql": "^15.3.0",
    "jwt-decode": "^2.2.0",
    "mobx": "^5.15.5",
    "moment": "^2.28.0",
    "next": "9.5.1",
    "path": "^0.12.7",
    "pm2": "^4.5.0",
    "query-string": "^6.13.1",
    "react": "16.13.1",
    "react-dom": "16.13.1",
    "react-helmet": "^6.1.0",
    "react-player": "^2.6.0",
    "react-relay": "^10.0.1",
    "react-relay-network-modern": "^4.7.4",
    "react-relay-network-modern-ssr": "^1.4.0",
    "react-toastify": "^6.0.8",
    "relay-compiler": "^10.0.1",
    "relay-devtools": "^1.4.0",
    "relay-devtools-core": "^0.0.8",
    "relay-runtime": "^10.0.1",
    "sass": "^1.26.10",
    "sass-resources-loader": "^2.0.3",
    "siema": "^1.5.1",
    "transform-class-properties": "^0.1.0"
  },
  "devDependencies": {
    "babel-plugin-relay": "^10.0.1"
  }
}

Para cualquiera que pueda estar lidiando con un next build quedando sin memoria, intente eliminar su .babelrc o babel.config.js . Tengo un .babelrc para una parte separada de mi proyecto no relacionada con Next.js, y no está de acuerdo con next build . En mi situación, el problema solo sucedía en Docker. Lo arreglé cambiando mi Dockerfile de este

FROM node:12
WORKDIR /app
COPY package.json package-lock.json /app/
ENV NODE_ENV production
RUN npm install
COPY . /app
RUN npm run build
RUN npm run next-build
EXPOSE 8081
CMD ["npm", "start"]

a esto

FROM node:12
WORKDIR /app
COPY package.json package-lock.json /app/
ENV NODE_ENV production
RUN npm install
COPY . /app
RUN npm run build
# Let Next.js use its own Babel config
RUN rm .babelrc
RUN npm run next-build
EXPOSE 8081
CMD ["npm", "start"]

Para aquellos que usan corredores compartidos en GitLab CI, esos corredores matarán su proceso de compilación con SIGABRT y, a su vez, desencadenarán este error. Cambiamos de nuevo a nuestro corredor de grupo y funcionó.

En caso de que alguno de ustedes esté usando next-transpile-modules , mi solución fue habilitar resolveSymlinks -setting (desde v4.1.0) así:

// next.config.js
const withTM = require("next-transpile-modules")([
    "somepackage"
], {
    resolveSymlinks: true
})
module.exports = {
    ...withTM()
}

Encontré por primera vez el problema descrito aquí cuando somepackage volvió "demasiado grande" (de 500kb a 700kb), ahora, de repente, toda mi memoria (también probé con la opción de 8gb) no era suficiente para manejar esto .

Creo que hay algunos bucles causados ​​por enlaces simbólicos que hacen que la memoria se hinche exponencialmente.