Il est impossible de retracer cela sans une reproduction.

Ouais je sais. Avant d'avoir un tas de mémoire autour de la génération des sourcemaps, je l'ai donc supprimé. Et j'ai reçu ce message d'erreur autour du fichier de tableau natif.

Existe-t-il un moyen d'obtenir une trace de pile plus détaillée?

Pour info, il est en cours de construction mais uniquement parce que j'ai ajouté plus de mémoire au processus de nœud:

NODE_OPTIONS="--max_old_space_size=4096"

Il construit jusqu'à 28 routes mais quand je donne 30 routes (nous avons 31 routes) la mémoire du processus monte jusqu'à 3 Go de mémoire (et même plus). J'exécute le processus de construction sur un ordinateur portable moyen doté de 8 Go de mémoire, dont une partie est déjà utilisée. Mais ça a réussi.

Je ne sais pas si je dois garder cette question ouverte ou non.
Si cela aide, voici les statistiques des pages construites:

Le processus se bloque lorsqu'il tente de créer les cartes source (la plupart du temps).

Vraiment, la seule façon dont nous saurons jamais est si une reproduction complète est fournie. Je vais fermer ça pour l'instant.

Nous aussi, nous avons remarqué qu'après la mise à niveau vers Next 9, nous perdons des erreurs de mémoire alors qu'avec Next 8 ce n'était pas un problème.

Dans notre cas, nous construisons notre application dans CircleCi dans le cadre de notre flux CI et rencontrons les éléments suivants:

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 Go est la limite de mémoire pour un conteneur CircleCI, d'où l'erreur. Il semble qu'en construisant avec Next 9, nous atteignons cette limite.

Je n'ai pas de cas reproductible à partager pour le moment.

Nous avons également rencontré ce problème lors du déploiement de mon application avec NextJs 9.

Sur les 3 projets que nous avons mis à niveau vers NextJs 9, deux d'entre eux font face à un problème d'utilisation de la RAM lors du déploiement sur Elastic Beanstalk. Finalement, nous devons le renverser. Malheureusement, je n'ai pas de dépôt à partager pour reproduire le problème.

J'obtiens le même problème de mémoire, mais le mien se produit après la construction de tous les lambdas. Je peux terminer la construction sur mon ordinateur portable, mais il se bloque lors du déploiement, mais j'ai vu périodiquement quelques problèmes de mémoire insuffisante lors du développement local. La seule chose reconnaissable (pour moi) est cette ligne:

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

Voici le journal ...

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

Voici ma configuration 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 Je suis également à court de mémoire avec Next.js 9. Cela pourrait être dû au nombre de composants que nous compilons. Vous avez mentionné que vous aviez besoin d'un repro complet. Vous pouvez jeter un œil à ma succursale.
https://github.com/stramel/styled-icons/tree/ms/add-material-variants

Voici la version défaillante: https://travis-ci.org/jacobwgillespie/styled-icons/builds/582987078

Travis a NODE_OPTIONS=--max-old-space-size=4096 ensemble

@timneutkens pourrait s'il vous plaît rouvrir le problème maintenant que vous avez un dépôt?

Je suis confronté au même problème avec [email protected].

J'imagine que ces applications ont simplement atteint leurs limites de taille pour commencer à manquer de mémoire. Vous devrez exécuter votre build avec plus via NODE_OPTIONS=--max-old-space-size=4096 .

Vous pouvez également activer notre nouvelle fonctionnalité de segmentation:

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

Merci @Timer , je vais granularChunks .

Aussi, juste pour noter, j'avais essayé 8192 pour la valeur sur ma machine locale et cela a toujours échoué. J'ai un peu peur d'imaginer la quantité de mémoire dont j'aurais besoin pour la construire.

J'ai jeté un œil à un vieux problème et j'ai remarqué que parfois, quand il y avait une nouvelle version majeure, certaines personnes étaient confrontées à ce problème de mémoire. Je me demande, faites-vous un test de mémoire sur un gros projet?

Cette nouvelle version majeure atteint le plafond de mémoire des nœuds. Quelle est la cause de cette grande quantité de mémoire qui n'existait pas auparavant?

@Timer J'ai essayé d'utiliser la fonctionnalité granularChunks et j'ai toujours rencontré le même problème. Même localement avec l'ensemble 8192.

Cela a le jeu de fonctionnalités de configuration des blocs granulaires https://github.com/stramel/styled-icons/tree/ms/granular-chunks

Passé à l'extraction dynamique des composants, https://github.com/stramel/styled-icons/tree/ms/dynamic-import-granular-chunks

Ce problème se produit pour l'un de nos dépôts lorsque nous modifions la version pour effectuer une minification, qui est maintenant désactivée par défaut.

Mise à jour: j'ai déterminé que dans notre base de code, le problème utilisait le plugin withSourceMaps :

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

Cela a du sens puisque nous l'avons défini sur hidden-source-map ce qui est très lent. Cependant, je ne sais pas pourquoi il est exponentiellement plus lent que NextJS 8.

Nous avons également remarqué d'énormes problèmes de performances après la mise à niveau vers la v9 ... J'utilise un macbook pro 2015, il n'a jamais été en retard et j'ai exécuté des programmes assez lourds dessus, mais maintenant, chaque fois que je lance ma prochaine application localement il traîne complètement et tout ralentit massivement.

Je dois généralement redémarrer l'application toutes les 10 minutes environ, c'est aujourd'hui le premier jour où j'ai essayé de persévérer et de travailler dessus, et après quelques heures de course en développement, j'ai eu le même JavaScript heap out of memory que les gens ont signalé l'exécution de la prochaine version. Il doit y avoir une fuite de mémoire quelque part ici

Je le pense aussi. Un de mes collègues a un MacBook plus récent et depuis que nous sommes passés à la version 9, le serveur de développement est devenu plus lent à recompiler. Parfois, cela prend 20 secondes.

Je reçois le même problème, j'ai même essayé de définir NODE_OPTIONS = 16384 sur ma mémoire physique de 32 Go MacBook Pro mais sans effet.

Les journaux sont répertoriés:

==== 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 veuillez rouvrir ce numéro ou en ouvrir un nouveau. Cette fuite de mémoire ainsi que certaines requêtes HMR infinies étranges rendent notre application inutilisable en mode de développement et nous prennent énormément de temps.

Ajout d'un autre témoin.
J'ai hérité d'une application avec la version 4.2.3 suivante.

• Mise à jour vers la version 9.1.3 suivante
• Mise à jour de toutes les autres versions de packages dans package.json;
• Suppression du dossier node_modules et package.lock.json
• a exécuté l'installation de npm

Lorsque j'ai fait une diffusion locale du projet, cela a échoué avec l'erreur suivante:
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
L'échec se produisait généralement moins de dix minutes après le démarrage de l'application et pouvait être accéléré en déclenchant plus de navigation dans l'application.

Je suis revenu à la version 8.1.0 et je ne peux pas reproduire le même échec - même avec une navigation plus sérieuse (et donc des constructions de pages).

Oui, nous voyons cela aussi ...

Il est temps de rouvrir je pense @timneutkens

Je suis également confronté à ce problème sur [email protected] avec le serveur personnalisé

les deux lorsque j'importe directement le bootstrap.min.css avec require / import via js ou

mais quand j'importe le bootstrap depuis cdn, via dans

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

donc je pense que le problème était sur la minification css dans next-css. parce que lorsque je rétrograde mon projet à 8.1.0, j'ai eu ce problème de minification. https://github.com/zeit/next-plugins/issues/541. j'ai donc essayé cette solution de contournement (https://github.com/zeit/next-plugins/issues/392#issuecomment-475845330). et ne pas encore avoir le problème de mémoire.

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

J'ai le même problème après la mise à niveau vers Next 9.1.3. J'utilise aussi next-css, c'est peut-être ce qui le bloque?

Vous ne savez pas si ce sera la même chose pour tout le monde, mais assurez-vous de vérifier que toutes les ressources que vous demandez peuvent réellement être trouvées. J'avais une image que mon application ne pouvait pas trouver et elle a continué à la chercher jusqu'à ce qu'elle me donne l'erreur de tas. J'ai supprimé la mention de cette image et cela ne m'a plus donné l'erreur.

J'ai également réussi à résoudre ce problème, le commentaire @lloan a aidé à déboguer le problème.

Dans mon cas, je référençais /public/manifest.json comme une balise meta dans <head/> , mais cette ressource n'était pas présente dans mon projet et cela provoquait une fuite de mémoire.

J'ai eu ce code, dont le icon.png n'existe pas

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

En corrigeant l'importation du favicon, je n'obtiens plus l'erreur de fuite de mémoire

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

Comme mentionné https://github.com/zeit/now/issues/3307, je crois que quelque chose se passe avec le dossier static / public .

J'ai eu ce problème également. Comme bukinoshita l'a mentionné, j'ai regardé dans le dossier statique. J'ai supprimé un dossier de 674 fichiers json (à des fins de test) du dossier public/static/ . Je n'ai pas eu de problème depuis.

Ce problème se produit pour l'un de nos dépôts lorsque nous modifions la version pour effectuer une minification, qui est maintenant désactivée par défaut.

Mise à jour: j'ai déterminé que dans notre base de code, le problème utilisait le plugin withSourceMaps :

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

Cela a du sens puisque nous l'avons défini sur hidden-source-map ce qui est très lent. Cependant, je ne sais pas pourquoi il est exponentiellement plus lent que NextJS 8.

J'ai également commencé à avoir ce problème après être passé à "@zeit/next-source-maps": "^0.0.4-canary.1" . Une solution ou je devrai me débarrasser des cartes sources?

@focux J'ai dû désactiver du tout les cartes sources. Après cela, l'utilisation de la mémoire a considérablement diminué

J'ai le même problème ici aussi. Il semble se bloquer lorsque la taille du fichier dans la construction est trop grande. Par exemple, j'ai importé quelque chose de Typescript et la taille du fichier dans la construction est passée à 2,41 Mo. Ensuite, mon CI avec 2 Go de RAM a commencé à planter. Après avoir supprimé l'importation Typescript, la taille du fichier est descendue à 100 Ko et cela a fonctionné à nouveau.

Nextjs 9 a été très lent dans CI depuis le début. Cela prend beaucoup de temps à construire et je n'ai pas de besoins particuliers ... il suffit de réagir à des trucs, des ui matériels, des paquets ici et là. J'ai CI: s dans le même cluster avec node / express, certains dotnet core, php, etc. tout cela a 1 Go de mémoire en CI et se construit assez rapidement. Je ne sais pas plus que mon sentiment sur le processus de construction a peut-être un problème?

Même problème ici. Actions Mac OS / Github. Aucune action mentionnée ici n'aide, ne peut trouver aucun fichier lié mais inexistant.

Cependant, le projet se construit (et est en production) dans Zeit Now.

J'adorerais aider si je savais comment.

Même problème ici (MacOS). Ce que j'ai trouvé est:

• Commence avec Next 9.1.5 et 9.1.6. La mise à niveau vers la version 9.1.4 fait disparaître l'erreur.
• J'ai ma propre compilation _ckeditor_ dans le projet, et sa taille est de 606 Ko. Si je le supprime, le problème disparaît.

Faites-moi savoir si je peux vous aider. Ici vous avez le journal des erreurs ...

<--- 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 Je pense que c'est le coupable. En mode développement, il existe une génération de cartes sources. Je pense qu'au fil du temps, ce plugin de carte source conserve trop de mémoire.

Je rencontre toujours le même problème même si je désactive la génération de carte source

Сергей.

Le 24 décembre 2019 à 10h01 GMT, Emanuele [email protected] a écrit:

SourceMapConsumer_allGeneratedPositionsFor je pense que c'est le coupable. En mode développement, il existe une génération de cartes sources. Je pense qu'au fil du temps, ces plugins de source map conservent trop de mémoire.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désabonnez-vous .

Gardez à l'esprit que la publication de "Je rencontre toujours ce problème" ne résoudra pas le problème. Fournissez une reproduction complète pour que les gens puissent l'examiner, sinon votre commentaire équivaut à faire un 👍 sur le problème initial, mais à envoyer un ping à tout le monde sans raison.

Assurez-vous toujours que vos commentaires sont exploitables ou utiles. Par exemple, comme ematipico, partager des choses sur la base d'une enquête sur le problème est utile. Dire "J'ai toujours ce problème" n'est pas utile.

Y a-t-il une solution de contournement? Mon pipeline CI / CD échoue sur 1 Go de RAM.

Les étapes de repro

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

@ La solution de contournement

Le problème maintenant lié:

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

Juste pour ajouter à la discussion au cas où cela aiderait quelqu'un.
J'éprouvais un manque de mémoire, puis j'ai découvert quel était le problème dans mon cas:

Dans l'extrait de code suivant, si const Icon se trouve être undefined le code entre simplement dans une boucle infinie vérifiant si le composant est valide.

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

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

  return <Icon />;
}

Si j'ajoute une vérification si const Icon n'est pas défini, je me débarrasse du problème de mémoire insuffisante.

...
  const Icon = iconMapping[name];

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

La même chose m'est arrivée, puis j'ai réalisé qu'une faute de frappe en était la cause:

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

Veuillez essayer de mettre à niveau vers la dernière version de Next.js, nous avons récemment fait un tas d'optimisations de l'utilisation de la mémoire.

@timneutkens , j'ai la dernière version (9.3.5). J'ai créé le projet ce matin et j'ai rencontré cette erreur quelques minutes plus tard.

Problème similaire sur CricleCI lors de la création de l'application avec des cartes sources en utilisant next-source-maps

NODE_OPTIONS="--max_old_space_size=4096" aidé localement mais sur CircleCI, vous devez également augmenter la classe de ressources https://circleci.com/docs/2.0/configuration-reference/#resource_class à large au moins pour le faire fonctionner correctement.

J'ai commencé à avoir cette erreur après la mise à jour vers la prochaine 9.3.6 aujourd'hui:

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

Correction du problème en modifiant paths dans tsconfig.json comme suggéré dans # 12280

Cause probablement différente

Le même problème est présent ici après la mise à niveau de 9.0.5 vers 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

Une idée?

@szaza pouvez-vous essayer next@canary , le cas le plus probable est que vous rencontrez le problème décrit ici: https://github.com/zeit/next.js/issues/12280

Ok, après avoir supprimé le node_modules et réinstallé les dépendances, il semble que cela fonctionne avec la version Canary, mais j'ai maintenant une autre erreur: Cannot find module 'next-server/dist/server/next-server'. . Cela vous semble familier?

Oh je l'ai, il a été déplacé vers import Server from "next/dist/next-server/server/next-server"; .
Maintenant ça marche bien. Merci de votre aide!

@szaza comment avez-vous fini par importer ce module dans votre projet? C'est un module interne? Je suppose que vous vouliez importer 'next' place?

Je travaille sur un grand projet écrit en TypeScript. Un middleware d'authentification de passeport est configuré, qui redirige les utilisateurs non autorisés vers la page de connexion. Il est implémenté de la manière suivante:

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

Après la mise à jour de la prochaine version de 9.0.5 à 9.3.7-canary.0, le type Server ne pouvait plus être importé depuis next-server/dist/... , mais depuis le chemin mentionné ci-dessus.

J'ai eu la même erreur lorsque j'ai mis à niveau toutes les bibliothèques de mon package.json. Actuellement, j'utilise NextJS 9.2.2 avec @ zeit / next-css sans aucun problème. On dirait que certaines versions de bibliothèques soulèvent un problème de mémoire insuffisante ou qu'elles sont en conflit avec NextJS.

La configuration actuelle de mon package est -

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

J'ai réduit mon problème particulier à l'utilisation de la bibliothèque https://github.com/google/schema-dts. Lorsque les définitions de type de cette bibliothèque étaient utilisées dans mon application Next, la construction ne s'est jamais terminée, les fans de Macbook sont à pleine puissance et ont finalement craché un fichier json de rapport OOM à la racine du projet.

J'ai débogué le problème en supprimant toutes les pages sauf une de pages/ et en supprimant le code jusqu'à ce que le projet soit construit, puis en réinsérant progressivement le code.

Peut-être que cela aide quelqu'un qui rencontre ce fil ️

Problème similaire sur CricleCI lors de la création de l'application avec des cartes sources en utilisant next-source-maps

NODE_OPTIONS="--max_old_space_size=4096" aidé localement mais sur CircleCI, vous devez également augmenter la classe de ressources https://circleci.com/docs/2.0/configuration-reference/#resource_class à large au moins pour le faire fonctionner correctement.

C'est la seule chose qui a fonctionné pour nous 👍

Sur une application Next.js assez volumineuse (v9.3.6), un certain nombre d'entre nous rencontraient des problèmes de mémoire insuffisante au démarrage de l'application (mode de développement) pour lesquels le réglage NODE_OPTIONS="--max_old_space_size=4096" aidé pour Node 10, ou alternativement, sur Node 12 et au-delà, cela est pris en charge pour vous avec ce commit et un autre qui prend en compte la quantité de mémoire allouée à un conteneur (Linux uniquement afaik).

Juste pour ajouter à la discussion au cas où cela aiderait quelqu'un.
J'éprouvais un manque de mémoire, puis j'ai découvert quel était le problème dans mon cas:

Dans l'extrait de code suivant, si const Icon se trouve être undefined le code entre simplement dans une boucle infinie vérifiant si le composant est valide.

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

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

  return <Icon />;
}

Si j'ajoute une vérification si const Icon n'est pas défini, je me débarrasse du problème de mémoire insuffisante.

...
  const Icon = iconMapping[name];

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

Comment avez-vous compris que c'est le morceau de code qui a causé ce problème?

Assez intéressant, en regardant à nouveau ce code, j'en vois un autre
problème. L'icône est un composant et à l'intérieur de l'icône, je faisais référence à l'icône
lui-même.

La façon dont je le comprends était principalement en isolant composant par composant et
essayez de reproduire le problème jusqu'à ce que je sache quel composant provoquait
cette.

Le jeudi 21 mai 2020 à 18:20, Vivek_Neel [email protected] a écrit:

Juste pour ajouter à la discussion au cas où cela aiderait quelqu'un.
J'éprouvais un manque de mémoire, puis j'ai découvert quel était le
problème dans mon cas:

Dans l'extrait de code suivant, si l'icône const n'est pas définie
le code entre juste dans une boucle infinie vérifiant si le composant est valide.

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

revenir ;
}

Si j'ajoute une vérification si l'icône const n'est pas définie, je me débarrasse du hors de
problème de mémoire.

...
const Icon = iconMapping [nom];

if (! Icône) renvoie null;
revenir ;
}

Comment avez-vous compris que c'est le morceau de code qui a causé cela
problème?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/zeit/next.js/issues/7929#issuecomment-632187103 , ou
Se désabonner
https://github.com/notifications/unsubscribe-auth/ABA2CL7ZJQY5YPYJVCJMCODRSVIE7ANCNFSM4ICM4RAA
.

>

Envoyé depuis mon téléphone

D'après ce que j'ai compris, Next.js (depuis la v9.0.0) n'est pas en mesure d'optimiser la mémoire des grandes applications Web. Notre processus de construction atteint la limite de mémoire lorsqu'il commence à compiler la partie côté serveur du projet.

En mode de développement, le serveur local fonctionne bien au départ, mais après un certain temps, la mémoire allouée explose et l'erreur de tas de mémoire apparaît.

Un membre de l'équipe principale pourrait-il reconnaître ce problème et nous aider à le trier?

Mon équipe et moi, même avec des ordinateurs portables puissants, ne sommes parfois pas en mesure de créer localement l'application. Ce problème date de presque 1 an, mais il n'y a pas eu de mise à jour claire sur le problème. Personnellement, la seule solution de contournement à laquelle je puisse penser est de diviser l'application en deux projets sous Next.js car je crains qu'un jour nous ne pourrons même pas créer l'application même sur le CI (et nous utilisons déjà de puissants VM pour le faire).

Je suis vraiment désolé d'être le méchant ici, je cherche juste de l'aide.

EDIT: nous avons mis à jour vers Next.js 9.3.3 mais il n'y a pas eu d'améliorations

Un membre de l'équipe principale pourrait-il reconnaître ce problème et nous aider à le trier?

Je vous ai demandé à plusieurs reprises sur ce fil de fournir une reproduction complète ou de fournir votre candidature. Nous ne pouvons rien analyser dans votre application particulière pour localiser le problème dans votre application.
Nous avons modifié la génération de sourcemap en 9.4 btw, vous devez donc absolument passer à la dernière version.

Les cas FWIW comme https://github.com/zeit/next.js/issues/7929#issuecomment -618297553 sont des boucles infinies créées à l'intérieur de votre application et nous ne pouvons pas les détecter très bien (car elles finissent par passer par le rendu React ).

D'après ce que j'ai compris, Next.js (depuis la v9.0.0) n'est pas en mesure d'optimiser la mémoire des grandes applications Web. Notre processus de construction atteint la limite de mémoire lorsqu'il commence à compiler la partie côté serveur du projet.

Étant donné que vous n'avez pas fourni de reproduction, je ne peux que référencer nos propres applications.

Nous exécutons des millions de demandes sur Next.js et les applications que nous exécutons ont plus de 300 pages. Aucun problème de mémoire n'a été signalé par nos équipes et elles travaillent sur de nombreuses pages tout au long de leur journée.

Notez que ce n'est pas moi qui nie qu'il pourrait y avoir un problème, je dis simplement qu'il est impossible de savoir s'il y a un problème si vous n'allez pas fournir une reproduction claire ou une application que nous pouvons profiler.
Notez également que je ne demande même pas que ce soit du conseil payant, nous allons jeter un coup d'œil à l'application gratuitement.

Je vous ai demandé à plusieurs reprises sur ce fil de fournir une reproduction complète ou de fournir votre candidature. Nous ne pouvons rien analyser dans votre application particulière pour localiser le problème dans votre application.

D'autres personnes ont fourni des référentiels ici depuis que j'ai ouvert le numéro. C'est pourquoi le problème a été rouvert et c'est pourquoi il n'a pas l'étiquette indiquant qu'il faut un référentiel pour reproduire le problème.

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

Depuis qu'il a été laissé ouvert

Je ne peux pas fournir de référentiel car l'application Web appartient à mon client et le code source est fermé.

Nous avons modifié la génération de sourcemap en 9.4 btw, vous devez donc absolument passer à la dernière version.

Cette fonctionnalité est-elle opt-in / opt-out? J'ai supprimé la génération des cartes sources (cela a été fait via un plugin) après avoir ouvert le problème (il y a si longtemps) mais cela n'a pas beaucoup aidé.

Si vous pensez que ce problème n'est pas valide, veuillez le fermer. Le dépôt a été partagé il y a longtemps et il se peut qu'il ne soit plus valide.

Je peux aider avec le tri mais j'ai besoin de conseils.

▲  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 reproduction ne peut pas être exécutée, c'est pourquoi j'ai demandé à chaque personne qui a signalé ici de fournir également une reproduction pour éviter des cas comme celui-ci. De plus, le potentiel que ces problèmes soient identiques à 100% est assez faible.

Cette fonctionnalité est-elle opt-in / opt-out? J'ai supprimé la génération des cartes sources (cela a été fait via un plugin) après avoir ouvert le problème (il y a si longtemps) mais cela n'a pas beaucoup aidé.

Les sourcemaps sont toujours activés dans le développement, nous sommes cependant passés à eval source maps.

C'est pourquoi le problème a été rouvert et c'est pourquoi il n'a pas l'étiquette indiquant qu'il faut un référentiel pour reproduire le problème.

Je l'ai rouvert car de plus en plus de rapports arrivaient et je demandais des reproductions: https://github.com/zeit/next.js/issues/7929#issuecomment -568760542

Il n'y a que 2 reproductions fournies dans ce fil. L'un n'a aucun rapport avec Next.js ( now dev consommation de mémoire) et l'autre ne peut pas être exécuté / construit.

D'où la raison pour laquelle je demande à nouveau une reproduction complète, sinon cela continuera à être impossible à étudier.

Je ne peux pas fournir de référentiel car l'application Web appartient à mon client et le code source est fermé.

N'hésitez pas à contacter [email protected] et nous pourrons mettre en place un NDA, cela signifie potentiellement que nous devrons faire des conseils pour vous, car cela prendra beaucoup de temps pour configurer tout cela juste pour vous aider avec votre application particulière et vous construisez également l'application pour un client.

J'imagine que ces applications ont simplement atteint leurs limites de taille pour commencer à manquer de mémoire. Vous devrez exécuter votre build avec plus via NODE_OPTIONS=--max-old-space-size=4096 .

Vous pouvez également activer notre nouvelle fonctionnalité de segmentation:

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

Cela n'a pas résolu notre problème, FYI.

Quelqu'un sait si ce problème se produit dans le prochain démarrage du serveur intégré?
ie: Next start plutôt que NODE_ENV=production node server.js" ?

Mon problème survient après la génération de la compilation. Sur mon serveur personnalisé exécutant "node server.js", il crée de la mémoire jusqu'à ce que je reçoive cette erreur et le processus redémarre, ce qui signifie qu'il perd toutes les routes et tout le reste en cache, il est donc vraiment lent pour le premier utilisateur qui entre dans les pages après cela. tout le SSR se produit.

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]

Ceci est mon 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"
  }
}

Pour tous ceux qui pourraient avoir affaire à un fugitif next build court de mémoire, essayez de supprimer votre .babelrc ou babel.config.js . J'ai un .babelrc pour une partie distincte de mon projet non liée à Next.js, et il n'est pas d'accord avec next build . Dans ma situation, le problème ne se produisait que dans Docker. Je l'ai corrigé en changeant mon Dockerfile de ceci

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

pour ça

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

Pour ceux qui utilisent des coureurs partagés dans GitLab CI, ces coureurs tueront votre processus de construction avec SIGABRT et à leur tour déclencheront cette erreur. Nous sommes revenus à notre coureur de groupe et cela a fonctionné.

Dans le cas où l'un d'entre vous utilise next-transpile-modules , ma solution était d'activer resolveSymlinks -setting (depuis la v4.1.0) comme ceci:

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

J'ai rencontré le problème décrit ici pour la première fois lorsque somepackage est devenu "trop ​​gros" (de 500 ko à 700 ko), maintenant tout d'un coup, toute ma mémoire (également essayée avec l'option 8 Go) n'était pas suffisante pour gérer cela .

Je crois qu'il y a des boucles provoquées par des liens symboliques qui provoquent un gonflement exponentiel de la mémoire.