É impossível rastrear isso sem uma reprodução.

Sim, eu sei. Antes eu estava obtendo um heap de memória em torno da geração dos mapas de origem, então eu o removi. E recebi esta mensagem de erro sobre o arquivo de array nativo.

Existe alguma maneira de obter um rastreamento de pilha mais detalhado?

Para sua informação, agora está crescendo, mas apenas porque adicionei mais memória ao processo do nó:

NODE_OPTIONS="--max_old_space_size=4096"

Ele acumula até 28 rotas, mas quando dou 30 rotas (temos 31 rotas) a memória do processo sobe para 3 GB de memória (e até mais). Estou executando o processo de compilação em um laptop médio com 8 GB de memória, parte dela já usada. Mas conseguiu.

Não sei se devo manter esse assunto em aberto ou não.
Se ajudar, aqui estão as estatísticas das páginas construídas:

O processo falha ao tentar criar os mapas de origem (na maioria das vezes).

Realmente, a única maneira de sabermos é se uma reprodução completa é fornecida. Vou fechar isso por enquanto.

Nós também notamos que, após a atualização para o Next 9, estamos recebendo erros de memória insuficiente, enquanto com o Next 8 isso não foi um problema.

Em nosso caso, estamos construindo nosso aplicativo em CircleCi como parte de nosso fluxo de CI e encontrando o seguinte:

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

4 GB é o limite de memória para um contêiner CircleCI, daí o erro. Parece que com o Next 9 estamos atingindo esse limite.

Não tenho um caso reproduzível para compartilhar no momento.

Também enfrentamos esse problema ao implantar meu aplicativo com NextJs 9.

Dos 3 projetos que atualizamos para o NextJs 9, dois deles enfrentam problemas de uso de ram ao implantar no Elastic Beanstalk. No final, temos que reverter. Infelizmente, não tenho um repositório para compartilhar para replicar o problema.

Estou recebendo o mesmo problema de falta de memória, mas o meu ocorre depois que todos os lambdas são construídos. Posso terminar a compilação no meu laptop, mas ele trava durante a implantação, no entanto, tenho visto alguns problemas de falta de memória periodicamente durante o desenvolvimento local. A única coisa reconhecível (para mim) é esta linha:

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

Aqui está o log ...

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

Aqui está minha configuração do webpack:

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 Estou ficando sem memória usando Next.js 9 também. Pode ser devido ao número de componentes que estamos compilando. Você mencionou que precisava de uma reprodução completa dele. Você pode dar uma olhada no meu ramo.
https://github.com/stramel/styled-icons/tree/ms/add-material-variants

Aqui está a compilação com falha: https://travis-ci.org/jacobwgillespie/styled-icons/builds/582987078

Travis tem NODE_OPTIONS=--max-old-space-size=4096 definido

@timneutkens poderia reabrir o problema agora que você tem um repositório?

Estou enfrentando o mesmo problema com [email protected].

Estou supondo que esses aplicativos simplesmente atingiram seus limites de tamanho para começar a ficar sem memória. Você precisará executar sua construção com mais via NODE_OPTIONS=--max-old-space-size=4096 .

Como alternativa, você pode ativar nosso novo recurso de fragmentação:

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

Obrigado @Timer , vou dar uma chance ao recurso granularChunks .

Além disso, apenas para observar, eu tentei 8192 para o valor em minha máquina local e ainda falhou. Estou com um pouco de medo de imaginar quanta memória eu precisaria para realmente construir.

Eu dei uma olhada em algum problema antigo e percebi que às vezes, quando havia um novo lançamento importante, algumas pessoas enfrentavam esse problema de memória. Eu me pergunto, você faz algum teste de memória em algum grande projeto?

Esta nova versão principal está atingindo o limite de memória do nó. Qual é a causa dessa grande quantidade de memória que não existia antes?

@Timer Tentei usar o recurso granularChunks e ainda tive o mesmo problema. Mesmo localmente com 8192 definido.

Isso tem o conjunto de recursos de configuração de blocos granulares https://github.com/stramel/styled-icons/tree/ms/granular-chunks

Alternado para extrair componentes dinamicamente, https://github.com/stramel/styled-icons/tree/ms/dynamic-import-granular-chunks

Esse problema ocorre em um de nossos repositórios quando alteramos a construção para realizar a minificação, que agora está desativada por padrão.

Atualização: determinei que em nossa base de código o problema estava usando o plug-in withSourceMaps :

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

Isso faz sentido, uma vez que definimos como hidden-source-map que é muito lento. Porém, não sei por que ele é exponencialmente mais lento do que o NextJS 8.

Também notamos enormes problemas de desempenho após a atualização para a v9 ... Estou usando um macbook pro 2015, ele nunca sofreu atrasos e executei alguns programas muito pesados ​​nele, mas agora toda vez que executo meu próximo aplicativo localmente ele fica completamente atrasado e tudo fica mais lento.

Normalmente tenho que reiniciar o aplicativo a cada 10 minutos mais ou menos, hoje foi o primeiro dia em que tentei perseverar e trabalhar com ele e, após algumas horas de execução no movimento dev, obtive o mesmo JavaScript heap out of memory que as pessoas relataram a execução da próxima construção. Deve haver um vazamento de memória aqui em algum lugar

Eu também acho. Um colega meu tem um MacBook mais recente e, desde que atualizamos para o próximo 9, o servidor de desenvolvimento ficou mais lento para recompilar. Às vezes, leva cerca de 20 segundos.

Estou tendo o mesmo problema, até tentei definir NODE_OPTIONS = 16384 no meu MacBook Pro de memória física de 32 GB, mas sem efeito.

Os registros são listados:

==== 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 reabra este problema ou abra um novo. Esse vazamento de memória, bem como algumas solicitações HMR infinitas estranhas, está tornando nosso aplicativo inutilizável no modo de desenvolvimento e consumindo muito do nosso tempo.

Adicionando outra testemunha.
Eu herdei um aplicativo com Next versão 4.2.3.

• Atualizado para a próxima versão 9.1.3
• Atualizado todas as outras versões de pacotes em package.json;
• Excluiu a pasta node_modules e package.lock.json
• rodou npm install

Quando fiz um serviço local do projeto, ele falhou com o seguinte erro:
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
A falha geralmente acontecia em menos de dez minutos após a inicialização do aplicativo e poderia ser acelerada acionando mais navegação no aplicativo.

Eu reverti para a versão 8.1.0 e não consigo reproduzir a mesma falha - mesmo com uma navegação mais séria (e, portanto, construção de páginas).

Sim, estamos vendo isso também ...

É hora de reabrir, acho @timneutkens

Estou enfrentando esse problema também em [email protected] com o servidor personalizado

tanto quando eu importo diretamente o bootstrap.min.css com require / import via js ou @import via css / scss. minha memória nodejs usada foi aumentada depois de alguns ajustes durante o desenvolvimento.

mas quando eu importo o bootstrap do cdn, via dentro

<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>

então acho que o problema estava na minificação do CSS no next-css. porque ao fazer o downgrade do meu projeto para 8.1.0, tive esse problema de minificação. https://github.com/zeit/next-plugins/issues/541. então tentei esta solução alternativa (https://github.com/zeit/next-plugins/issues/392#issuecomment-475845330). e ainda não tendo o problema de memória novamente.

// 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;
  },
});

Estou tendo o mesmo problema depois de atualizar para o Next 9.1.3. Estou usando o next-css também, talvez seja isso que está travando?

Não tenho certeza se isso será o mesmo para todos, mas certifique-se de verificar se qualquer recurso que você está solicitando pode realmente ser encontrado. Eu tinha uma imagem que meu aplicativo não conseguiu encontrar e continuou procurando até me dar o erro de heap. Removi a menção a essa imagem e não me deu o erro novamente.

Eu também consegui consertar isso, o comentário @lloan ajudou a depurar o problema.

No meu caso, eu estava me referindo a /public/manifest.json como uma tag meta em <head/> , no entanto, esse recurso não estava presente em meu projeto e isso estava causando o vazamento de memória.

Eu tinha esse código, que icon.png não existe

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

Ao corrigir a importação do favicon, não recebo mais o erro de vazamento de memória

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

Conforme mencionado https://github.com/zeit/now/issues/3307 Eu acredito que algo está acontecendo com a pasta static / public .

Eu tive esse problema também. Como bukinoshita mencionou, olhei para a pasta estática. Removi uma pasta de 674 arquivos json (para fins de teste) da pasta public/static/ . Eu não tive o problema desde então.

Esse problema ocorre em um de nossos repositórios quando alteramos a construção para realizar a minificação, que agora está desativada por padrão.

Atualização: determinei que em nossa base de código o problema estava usando o plug-in withSourceMaps :

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

Isso faz sentido, uma vez que definimos como hidden-source-map que é muito lento. Porém, não sei por que ele é exponencialmente mais lento do que o NextJS 8.

Comecei a ter esse problema também depois de fazer upgrade para "@zeit/next-source-maps": "^0.0.4-canary.1" . Alguma solução ou terei que me livrar dos mapas de origem?

@focux Eu tive que desabilitar os mapas de origem em tudo. Depois disso, o uso de memória caiu substancialmente

Tenho o mesmo problema aqui também. Parece travar quando o tamanho do arquivo na construção é muito grande. Por exemplo, importei algo do Typescript e o tamanho do arquivo no build subiu para 2,41 MB. Então meu CI com 2 GB de RAM começou a falhar. Depois que eu removi a importação do Typescript, o tamanho do arquivo caiu para 100kb e funcionou novamente.

Nextjs 9 tem sido muito lento em CI desde o início. Demora muito para construir e eu não tenho nenhuma necessidade especial ... apenas reajo coisas, material de interface do usuário, alguns pacotes aqui e ali. Eu tenho CI: s no mesmo cluster com node / express, algum core dotnet, php etc, todos estes têm 1GB de memória em CI e constroem muito rápido. Eu não sei mais do que meu sentimento sobre o processo de construção tem algum problema, talvez?

Mesmo problema aqui. Ações do Mac OS / Github. Nenhuma ação mencionada aqui ajuda, não consigo encontrar nenhum arquivo que esteja vinculado, mas não existente.

No entanto, o projeto é construído (e está em produção) no Zeit Now.

Adoraria ajudar se soubesse como.

Mesmo problema aqui (MacOS). O que eu encontrei é:

• Começa a acontecer com Next 9.1.5 e 9.1.6. O downgrade para 9.1.4 faz com que o erro desapareça.
• Eu tenho meu próprio _ckeditor_ build dentro do projeto e seu tamanho é 606 KB. Se eu removê-lo, o problema desaparece.

Me diga se posso ajudar. Aqui você tem o log de erros ...

<--- 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 Acho que esse é o culpado. No modo dev, há uma geração de mapas de origem. Eu acho que com o tempo, este plugin de mapa de origem retém muita memória.

Ainda tenho o mesmo problema, mesmo se desligar a geração do mapa de origem

Сергей.

Em 24 de dezembro de 2019 às 10:01 GMT, Emanuele [email protected] escreveu:

SourceMapConsumer_allGeneratedPositionsFor Acho que esse é o culpado. No modo dev, há uma geração de mapas de origem. Acho que com o tempo, esses plugins de mapa de origem retêm muita memória.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub ou cancele a inscrição .

Lembre-se de que postar "Ainda sinto isso" não resolverá o problema. Forneça uma reprodução completa para que as pessoas examinem, caso contrário, seu comentário é o mesmo que fazer um 👍 no problema inicial, mas enviar um ping para todos os envolvidos sem motivo.

Sempre certifique-se de que seus comentários sejam acionáveis ​​ou úteis. Por exemplo, como ematipico, compartilhar coisas com base na investigação do problema é útil. Dizer "Ainda tenho esse problema" não é útil.

Existe alguma solução alternativa? Meu pipeline de CI / CD falha em 1 GB de RAM.

As etapas

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

A solução alternativa do

O problema agora relacionado:

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

Só para aumentar a discussão, caso ajude alguém.
Eu estava experimentando uma falta de memória e então descobri qual era o problema no meu caso:

No trecho de código a seguir, se const Icon for undefined o código apenas entra em um loop infinito, verificando se o componente é válido.

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

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

  return <Icon />;
}

Se eu adicionar um cheque se const Icon não estiver definido, eu me livro do problema de falta de memória.

...
  const Icon = iconMapping[name];

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

A mesma coisa aconteceu comigo, então percebi que foi um erro de digitação que causou isso:

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

Tente atualizar para a versão mais recente do Next.js, fizemos várias otimizações no uso de memória recentemente.

@timneutkens , tenho a versão mais recente (9.3.5). Criei o projeto esta manhã e enfrentei esse erro alguns minutos depois.

Teve um problema semelhante no CricleCI ao construir o aplicativo com mapas de origem usando next-source-maps

NODE_OPTIONS="--max_old_space_size=4096" ajudou localmente, mas no CircleCI você também precisa aumentar a classe de recursos https://circleci.com/docs/2.0/configuration-reference/#resource_class para large pelo menos para fazê-lo funcionar devidamente.

Comecei a receber este erro depois de atualizar para o próximo 9.3.6 hoje:

<--- 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
...

Foi corrigido modificando paths em tsconfig.json conforme sugerido em # 12280

Provavelmente causa diferente

O mesmo problema está presente aqui após a atualização de 9.0.5 para 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

Qualquer ideia?

@szaza, você pode tentar next@canary , o caso mais provável é que você tenha o problema descrito aqui: https://github.com/zeit/next.js/issues/12280

Ok, depois de deletar o node_modules e reinstalar as dependências parece que funciona com a versão canário, porém agora tenho outro erro: Cannot find module 'next-server/dist/server/next-server'. . Parece familiar para você?

Ah, entendi, foi movido para import Server from "next/dist/next-server/server/next-server"; .
Agora funciona bem. Obrigado pela ajuda!

@szaza como você acabou importando aquele módulo em seu projeto? É um módulo interno? Eu acho que você pretendia importar 'next' vez disso?

Estou trabalhando em um grande projeto escrito em TypeScript. Há um middleware de autenticação de passaporte configurado, que redireciona os usuários não autorizados de volta à página de login. É implementado da seguinte forma:

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);
...
}

Após atualizar a próxima versão de 9.0.5 para 9.3.7-canary.0, Server type não pôde mais ser importado de next-server/dist/... , mas sim do caminho mencionado acima.

Eu tive o mesmo erro quando atualizei todas as bibliotecas em meu package.json. Atualmente estou usando NextJS 9.2.2 com @ zeit / next-css sem nenhum problema. Parece que alguma versão das bibliotecas gera um problema de falta de memória ou elas estão de alguma forma em conflito com o NextJS.

Minha configuração de pacote atual é -

{
"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"
  }
}

Limitei meu problema específico ao uso da biblioteca https://github.com/google/schema-dts. Quando as definições de tipo desta biblioteca estavam sendo usadas em meu Next app, a compilação nunca foi concluída, os fãs do Macbook vão com força total e, eventualmente, cuspem algum arquivo json de relatório OOM na raiz do projeto.

Eu depurei o problema removendo todas as páginas de pages/ exceto uma, e removendo o código até que o projeto fosse construído e, em seguida, gradualmente colocando o código de volta.

Talvez isso ajude alguém que se depara com este tópico 🤷‍♂️

Teve um problema semelhante no CricleCI ao construir o aplicativo com mapas de origem usando next-source-maps

NODE_OPTIONS="--max_old_space_size=4096" ajudou localmente, mas no CircleCI você também precisa aumentar a classe de recursos https://circleci.com/docs/2.0/configuration-reference/#resource_class para large pelo menos para fazê-lo funcionar devidamente.

Esta é a única coisa que funcionou para nós 👍

Em um aplicativo Next.js bastante grande (v9.3.6), vários de nós estávamos enfrentando problemas de falta de memória heap na inicialização do aplicativo (modo de desenvolvimento) para os quais a configuração NODE_OPTIONS="--max_old_space_size=4096" ajudou no Nó 10 ou, alternativamente, Nó 12 e além, isso é feito para você com este commit e outro que leva em conta a quantidade de memória alocada para um contêiner (apenas Linux afaik).

Só para aumentar a discussão, caso ajude alguém.
Eu estava experimentando uma falta de memória e então descobri qual era o problema no meu caso:

No trecho de código a seguir, se const Icon for undefined o código apenas entra em um loop infinito, verificando se o componente é válido.

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

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

  return <Icon />;
}

Se eu adicionar um cheque se const Icon não estiver definido, eu me livro do problema de falta de memória.

...
  const Icon = iconMapping[name];

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

Como você descobriu que essa é a parte do código que causou o problema?

Interessante, olhando para este código novamente, eu realmente vejo outro
problema. O ícone é um componente e dentro do ícone eu estava fazendo referência ao ícone
em si.

A maneira como descobri foi isolando componente por componente e
tente reproduzir o problema até descobrir qual componente estava provocando
este.

Na quinta-feira, 21 de maio de 2020 às 18:20, Vivek_Neel [email protected] escreveu:

Só para aumentar a discussão, caso ajude alguém.
Eu estava passando por uma falta de memória e então descobri o que era
problema no meu caso:

No seguinte snippet de código, se o ícone const for indefinido
o código apenas entra em um loop infinito verificando se o componente é válido.

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

Retorna ;
}

Se eu adicionar uma verificação se o ícone const não estiver definido, eu me livro de fora do
problema de memória.

...
ícone const = iconMapping [nome];

if (! Ícone) retorna nulo;
Retorna ;
}

Como você descobriu que essa é a parte do código que causou isso
questão?

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/zeit/next.js/issues/7929#issuecomment-632187103 , ou
Cancelar subscrição
https://github.com/notifications/unsubscribe-auth/ABA2CL7ZJQY5YPYJVCJMCODRSVIE7ANCNFSM4ICM4RAA
.

>

Enviado do meu telefone

Tanto quanto eu entendi, Next.js (desde a v9.0.0) não é capaz de otimizar a memória de grandes aplicativos da web. Nosso processo de construção atinge o limite de memória quando começa a compilar a parte do lado do servidor do projeto.

Durante o modo de desenvolvimento, o servidor local está bem inicialmente, mas depois de algum tempo a memória alocada explode e o erro de heap de memória aparece.

Alguém da equipe principal poderia reconhecer esse problema e nos ajudar a fazer a triagem do problema?

Eu e minha equipe, mesmo com laptops poderosos, às vezes não somos capazes de construir o aplicativo localmente. Este problema tem quase 1 ano, mas não houve uma atualização clara em torno do problema. Pessoalmente, a única solução alternativa que posso pensar é dividir o aplicativo em dois subprojetos Next.js porque estou preocupado que um dia não seremos capazes de construir o aplicativo nem mesmo no CI (e já estamos usando VMs para fazer isso).

Lamento ser o bandido aqui, estou apenas procurando ajuda.

EDIT: atualizamos para Next.js 9.3.3, mas não houve melhorias

Alguém da equipe principal poderia reconhecer esse problema e nos ajudar a fazer a triagem do problema?

Pedi várias vezes neste tópico para fornecer uma reprodução completa ou fornecer seu aplicativo. Não podemos analisar nada em seu aplicativo específico para rastrear o problema em seu aplicativo.
Mudamos a geração do mapa de origem em 9,4 btw, então você definitivamente deve atualizar para a versão mais recente.

Casos FWIW como https://github.com/zeit/next.js/issues/7929#issuecomment -618297553 são loops infinitos criados dentro de seu aplicativo e não podemos detectá-los muito bem (pois eles acabam passando pela renderização React )

Tanto quanto eu entendi, Next.js (desde a v9.0.0) não é capaz de otimizar a memória de grandes aplicativos da web. Nosso processo de construção atinge o limite de memória quando começa a compilar a parte do lado do servidor do projeto.

Visto que você não forneceu uma reprodução, posso apenas citar nossos próprios aplicativos.

Executamos milhões de solicitações no Next.js e os aplicativos que executamos têm mais de 300 páginas. Não tivemos problemas de memória relatados por nossas equipes e elas trabalham em muitas páginas ao longo do dia.

Observe que não sou eu que estou negando que pode haver um problema, estou apenas dizendo que é impossível rastrear se há um problema se você não fornecer uma reprodução ou aplicativo claro que possamos identificar.
Observe também que eu nem estou pedindo que seja paga consultoria, vamos dar uma olhada no aplicativo gratuitamente.

Pedi várias vezes neste tópico para fornecer uma reprodução completa ou fornecer seu aplicativo. Não podemos analisar nada em seu aplicativo específico para rastrear o problema em seu aplicativo.

Outras pessoas forneceram repositórios aqui desde que abri a edição. É por isso que a edição foi reaberta e por isso não tem o rótulo que diz que é necessário um repositório para reproduzir a edição.

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

Desde que foi deixado aberto

Não posso fornecer um repositório porque o aplicativo da web pertence ao meu cliente e o código-fonte está fechado.

Mudamos a geração do mapa de origem em 9,4 btw, então você definitivamente deve atualizar para a versão mais recente.

Este recurso é opt-in / opt-out? Removi a geração de mapas de origem (isso era feito via plug-in) depois de abrir o problema (há muito tempo), mas não ajudou muito.

Se você acha que este problema não é válido, feche-o. O repo foi compartilhado há muito tempo e pode não ser mais válido.

Posso ajudar na triagem, mas preciso de orientação.

▲  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.

A reprodução não pode ser executada, por isso pedi a cada pessoa que relatou aqui para fornecer também uma reprodução para evitar casos como este. Além disso, o potencial para que esses problemas sejam 100% iguais é bastante baixo.

Este recurso é opt-in / opt-out? Removi a geração de mapas de origem (isso era feito via plug-in) depois de abrir o problema (há muito tempo), mas não ajudou muito.

Os mapas de origem estão sempre ativados no desenvolvimento, mas mudamos para mapas de origem de avaliação.

É por isso que a edição foi reaberta e por isso não tem o rótulo que diz que é necessário um repositório para reproduzir a edição.

Eu o reabri porque mais relatórios continuavam chegando e eu continuei pedindo reproduções: https://github.com/zeit/next.js/issues/7929#issuecomment -568760542

Existem apenas 2 reproduções fornecidas neste tópico. Um não está totalmente relacionado com Next.js ( now dev consumo de memória) e o outro não pode ser executado / construído.

É por isso que mais uma vez estou pedindo uma reprodução completa, caso contrário, isso continuará a ser impossível de investigar.

Não posso fornecer um repositório porque o aplicativo da web pertence ao meu cliente e o código-fonte está fechado.

Sinta-se à vontade para entrar em contato com [email protected] e podemos configurar um NDA, potencialmente isso significa que teremos que fazer consultoria para você, embora levará um tempo significativo para configurar tudo isso apenas para ajudá-lo com seu aplicativo específico e você também está construindo o aplicativo para um cliente.

Estou supondo que esses aplicativos simplesmente atingiram seus limites de tamanho para começar a ficar sem memória. Você precisará executar sua construção com mais via NODE_OPTIONS=--max-old-space-size=4096 .

Como alternativa, você pode ativar nosso novo recurso de fragmentação:

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

Isso não resolveu nosso problema, para sua informação.

Alguém sabe se esse problema ocorre no próximo início do servidor embutido?
ou seja: Next start vez de NODE_ENV=production node server.js" ?

Meu problema surge depois de gerar a compilação. No meu servidor personalizado executando "node server.js", ele acumula memória até que eu receba esse erro e o processo seja reiniciado, o que significa que ele perde todas as rotas em cache e outras coisas, então é muito lento para o primeiro usuário que entrar nas páginas depois disso, como todo o SSR está acontecendo.

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 é o meu 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 qualquer um que esteja lidando com um fugitivo next build sem memória, tente deletar .babelrc ou babel.config.js . Eu tenho um .babelrc para uma parte separada do meu projeto não relacionada ao Next.js e não concorda com next build . Na minha situação, o problema estava acontecendo apenas no Docker. Corrigi-o mudando meu Dockerfile deste

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"]

para isso

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 aqueles que usam runners compartilhados no GitLab CI, esses runners irão encerrar seu processo de construção com SIGABRT e, por sua vez, acionar esse erro. Voltamos ao nosso corredor de grupo e funcionou.

Caso algum de vocês esteja usando next-transpile-modules , minha solução foi habilitar a configuração resolveSymlinks (desde a v4.1.0) assim:

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

Eu encontrei pela primeira vez o problema descrito aqui quando somepackage se tornou "muito grande" (de 500kb para 700kb), agora, de repente, toda a minha memória (também tentei com a opção de 8 GB) não era suficiente para lidar com isso .

Acredito que existam alguns loops causados ​​por links simbólicos que fazem com que a memória inche exponencialmente.