Es ist unmöglich, dies ohne Reproduktion aufzuspüren.

Ja ich weiß. Bevor ich einen Speicherhaufen um die Generierung der Quellkarten bekam, entfernte ich ihn. Und ich habe diese Fehlermeldung um die native Array-Datei erhalten.

Gibt es eine Möglichkeit, eine ausführlichere Stapelverfolgung zu erhalten?

Zu Ihrer Information, es wird jetzt erstellt, aber nur, weil ich dem Knotenprozess mehr Speicher hinzugefügt habe:

NODE_OPTIONS="--max_old_space_size=4096"

Es werden bis zu 28 Routen erstellt, aber wenn ich 30 Routen gebe (wir haben 31 Routen), wird der Speicher des Prozesses auf 3 GB Speicher (und noch mehr) erweitert. Ich führe den Erstellungsprozess auf einem durchschnittlichen Laptop mit 8 GB Speicher aus, von denen einige bereits verwendet wurden. Aber es ist gelungen.

Ich weiß nicht, ob ich dieses Thema offen halten soll oder nicht.
Wenn es hilft, hier die Statistiken der erstellten Seiten:

Der Prozess stürzt ab, wenn versucht wird, die Quellzuordnungen zu erstellen (meistens).

Der einzige Weg, den wir jemals erfahren werden, ist, ob eine vollständige Reproduktion bereitgestellt wird. Ich werde das jetzt schließen.

Auch wir haben festgestellt, dass nach dem Upgrade auf Next 9 Speicherfehler auftreten, während dies bei Next 8 kein Problem war.

In unserem Fall erstellen wir unsere App in CircleCi als Teil unseres CI-Flusses und stellen Folgendes fest:

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 ist das Speicherlimit für einen CircleCI-Container, daher der Fehler. Es scheint, als würden wir mit Next 9 diese Grenze erreichen.

Ich habe im Moment keinen reproduzierbaren Fall zum Teilen.

Dieses Problem trat auch bei der Bereitstellung meiner Anwendung mit NextJs 9 auf.

Von den drei Projekten, die wir auf NextJs 9 aktualisiert haben, haben zwei Probleme mit der RAM-Nutzung, wenn sie auf Elastic Beanstalk bereitgestellt werden. Am Ende müssen wir es zurücksetzen. Leider habe ich kein Repo zum Teilen, um das Problem zu replizieren.

Ich habe das gleiche Problem mit dem Speicher, aber mein Problem tritt auf, nachdem alle Lambdas gebaut wurden. Ich kann den Build auf meinem Laptop beenden, er stürzt jedoch bei der Bereitstellung ab. Bei der lokalen Entwicklung sind jedoch regelmäßig einige Speicherprobleme aufgetreten. Das einzige, was (für mich) erkennbar ist, ist diese Zeile:

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

Hier ist das Protokoll ...

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

Hier ist meine Webpack-Konfiguration:

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 Mit Next.js 9
https://github.com/stramel/styled-icons/tree/ms/add-material-variants

Hier ist der fehlerhafte Build: https://travis-ci.org/jacobwgillespie/styled-icons/builds/582987078

Travis hat NODE_OPTIONS=--max-old-space-size=4096 gesetzt

@timneutkens könnte das Problem bitte wieder öffnen, sobald Sie ein Repo haben?

Ich habe das gleiche Problem mit [email protected].

Ich vermute, diese Anwendungen haben einfach ihre Größengrenzen überschritten, um nicht mehr genügend Speicher zu haben. Sie müssen Ihren Build mit mehr über NODE_OPTIONS=--max-old-space-size=4096 ausführen.

Alternativ können Sie unsere neue Chunking-Funktion aktivieren:

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

Danke @Timer , ich werde die granularChunks -Funktion ausprobieren.

Außerdem hatte ich 8192 für den Wert auf meinem lokalen Computer ausprobiert und es schlug immer noch fehl. Ich habe ein bisschen Angst, mir vorzustellen, wie viel Speicher ich tatsächlich benötigen würde, um ihn aufzubauen.

Ich habe mir ein altes Problem angesehen und festgestellt, dass manchmal, wenn es eine neue Hauptversion gab, einige Leute mit diesem Speicherproblem konfrontiert waren. Ich frage mich, machst du einen Gedächtnistest für ein großes Projekt?

Diese neue Hauptversion erreicht die Speicherkapazität des Knotens. Was ist die Ursache für diesen großen Speicher, der vorher nicht da war?

@Timer Ich habe versucht, die Funktion granularChunks und bin trotzdem auf dasselbe Problem gestoßen . Auch vor Ort mit 8192 eingestellt.

Dies hat die Konfigurationsfunktion für granulare Chunks https://github.com/stramel/styled-icons/tree/ms/granular-chunks

Umgestellt auf dynamisches Einziehen von Komponenten, https://github.com/stramel/styled-icons/tree/ms/dynamic-import-granular-chunks

Dieses Problem tritt bei einem unserer Repos auf, wenn wir den Build ändern, um eine Minimierung durchzuführen, die jetzt standardmäßig deaktiviert ist.

Update: Ich habe festgestellt, dass in unserer Codebasis das Problem das Plugin withSourceMaps :

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

Dies ist sinnvoll, da wir es auf hidden-source-map was sehr langsam ist. Ich weiß jedoch nicht, warum es exponentiell langsamer als NextJS 8 ist.

Wir haben auch massive Leistungsprobleme nach dem Upgrade auf Version 9 festgestellt ... Ich verwende ein 2015er MacBook Pro, es ist noch nie zurückgeblieben und ich habe einige ziemlich schwere Programme darauf ausgeführt, aber jetzt jedes Mal, wenn ich meine nächste App lokal ausführe es bleibt völlig hängen und alles verlangsamt sich massiv.

Normalerweise muss ich die App alle 10 Minuten neu starten. Heute war der erste Tag, an dem ich versuchte, durchzuhalten und sie durchzuarbeiten, und nach ein paar Stunden Laufen in Dev Move bekam ich die gleichen JavaScript heap out of memory die Leute habe vom nächsten Build berichtet. Hier muss irgendwo ein Speicherverlust auftreten

Das denke ich auch. Ein Kollege von mir hat ein neueres MacBook und seit dem Upgrade auf die nächsten 9 ist die Neukompilierung des Entwicklungsservers langsamer geworden. Manchmal dauert es 20 Sekunden.

Ich bekomme das gleiche Problem, habe sogar versucht, NODE_OPTIONS = 16384 auf meinem 32 GB physischen Speicher MacBook Pro zu setzen, aber keine Auswirkung.

Protokolle werden aufgelistet:

==== 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 Bitte öffnen Sie diese Ausgabe erneut oder öffnen Sie eine neue. Dieser Speicherverlust sowie einige seltsame unendliche HMR-Anforderungen machen unsere App im Entwicklungsmodus unbrauchbar und verbrauchen einen großen Teil unserer Zeit.

Einen weiteren Zeugen hinzufügen.
Ich habe eine App mit Next Version 4.2.3 geerbt.

• Aktualisiert auf die nächste Version 9.1.3
• Alle anderen Paketversionen in package.json wurden aktualisiert.
• Löschte den Ordner node_modules und package.lock.json
• lief npm install

Wenn ich einen lokalen Serve des Projekts durchgeführt habe, ist dieser mit dem folgenden Fehler fehlgeschlagen:
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
Der Fehler trat normalerweise innerhalb von weniger als zehn Minuten nach dem Start der App auf und konnte durch Auslösen einer weiteren Navigation in der App beschleunigt werden.

Ich bin auf Version 8.1.0 zurückgekehrt und kann nicht denselben Fehler reproduzieren - selbst bei einer ernsthafteren Navigation (und damit bei der Erstellung von Seiten).

Ja, wir sehen das auch ...

Zeit, wieder zu öffnen, denke ich, @timneutkens

Ich habe dieses Problem auch auf [email protected] mit dem benutzerdefinierten

beides, wenn ich die bootstrap.min.css mit require / import via js oder @import via css / scss direkt importiere. Der Speicher meines Knotens wurde nach wenigen Konformitäten während der Entwicklung erhöht.

aber wenn ich den bootstrap von cdn importiere, via im

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

Ich denke, das Problem lag in der CSS-Minimierung in Next-CSS. Denn als ich mein Projekt auf 8.1.0 herunterstufte, bekam ich dieses Minimierungsproblem. https://github.com/zeit/next-plugins/issues/541. Deshalb habe ich diese Problemumgehung versucht (https://github.com/zeit/next-plugins/issues/392#issuecomment-475845330). und noch nicht das Speicherproblem wieder bekommen.

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

Ich habe das gleiche Problem nach dem Upgrade auf Next 9.1.3. Ich benutze auch next-css, vielleicht ist es tatsächlich das, was es zum Absturz bringt?

Sie sind sich nicht ganz sicher, ob dies für alle gleich ist, stellen Sie jedoch sicher, dass alle von Ihnen angeforderten Ressourcen tatsächlich gefunden werden können. Ich hatte ein Bild, das meine App nicht finden konnte, und es suchte weiter danach, bis es mir den Heap-Fehler gab. Ich habe die Erwähnung dieses Bildes entfernt und es hat mir den Fehler nicht mehr gegeben.

Ich habe es auch geschafft, dieses Problem zu beheben. @lloan half beim Debuggen des Problems.

In meinem Fall habe ich /public/manifest.json als meta -Tag in <head/> , aber diese Ressource war in meinem Projekt nicht vorhanden und dies verursachte den Speicherverlust.

Ich hatte diesen Code, den icon.png nicht existiert

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

Durch das Korrigieren des Imports des Favicons wird der Speicherverlustfehler nicht mehr angezeigt

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

Wie bereits erwähnt, https://github.com/zeit/now/issues/3307, glaube ich, dass mit dem Ordner static / public stimmt.

Ich hatte auch dieses Problem. Wie Bukinoshita es erwähnte, schaute ich in den statischen Ordner. Ich habe einen Ordner mit 674 JSON-Dateien (zu Testzwecken) aus dem Ordner public/static/ . Ich hatte das Problem seitdem nicht mehr.

Dieses Problem tritt bei einem unserer Repos auf, wenn wir den Build ändern, um eine Minimierung durchzuführen, die jetzt standardmäßig deaktiviert ist.

Update: Ich habe festgestellt, dass in unserer Codebasis das Problem das Plugin withSourceMaps :

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

Dies ist sinnvoll, da wir es auf hidden-source-map was sehr langsam ist. Ich weiß jedoch nicht, warum es exponentiell langsamer als NextJS 8 ist.

Ich hatte dieses Problem auch, nachdem ich auf "@zeit/next-source-maps": "^0.0.4-canary.1" aktualisiert hatte. Irgendeine Lösung oder muss ich die Quellkarten loswerden?

@focux Ich musste

Habe auch hier das gleiche Problem. Es scheint abzustürzen, wenn die Dateigröße im Build zu groß ist. Zum Beispiel habe ich etwas aus Typescript importiert und die Dateigröße im Build stieg auf 2,41 MB. Dann stürzte mein CI mit 2 GB RAM ab. Nachdem ich den Typescript-Import entfernt hatte, ging die Dateigröße auf 100 KB zurück und es funktionierte wieder.

Nextjs 9 war in CI von Anfang an sehr langsam. Der Bau dauert sehr lange und ich habe keine besonderen Bedürfnisse ... reagiere einfach auf Sachen, Material-UI, einige Pakete hier und da. Ich habe CI: s im selben Cluster mit Node / Express, etwas Dotnet Core, PHP usw. Alle diese haben 1 GB Speicher in CI und bauen ziemlich schnell. Ich weiß nicht mehr als mein Gefühl über den Erstellungsprozess hat vielleicht ein Problem?

Selbes Problem hier. Mac OS / Github-Aktionen. Keine der hier genannten Aktionen hilft, es können keine Dateien gefunden werden, die verknüpft, aber nicht vorhanden sind.

Das Projekt wird jedoch in Zeit Now erstellt (und befindet sich in Produktion).

Würde gerne helfen, wenn ich wüsste wie.

Gleiches Problem hier (MacOS). Was ich gefunden habe ist:

• Beginnt mit Next 9.1.5 und 9.1.6. Durch ein Downgrade auf 9.1.4 verschwindet der Fehler.
• Ich habe meinen eigenen _ckeditor_ Build innerhalb des Projekts und seine Größe beträgt 606 KB. Wenn ich es entferne, verschwindet das Problem.

Lassen Sie mich wissen, ob ich helfen kann. Hier haben Sie das Fehlerprotokoll ...

<--- 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 Ich denke, das ist der Schuldige. Im Dev-Modus gibt es eine Generation von Quellkarten. Ich denke, dass Überstunden, dieses Quell-Map-Plugin zu viel Speicher behalten.

Ich habe immer noch das gleiche Problem, auch wenn ich die Generierung der Quellkarte deaktiviere

Сергей.

Am 24. Dezember 2019 um 10:01 GMT schrieb Emanuele [email protected] :

SourceMapConsumer_allGeneratedPositionsFür ich denke, das ist der Schuldige. Im Dev-Modus gibt es eine Generation von Quellkarten. Ich denke, dass Überstunden, diese Quell-Map-Plugin zu viel Speicher behalten.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder melden Sie sich ab .

Denken Sie daran, dass das Problem durch das Posten "Ich erlebe das immer noch" nicht behoben werden kann. Stellen Sie eine vollständige Reproduktion zur Verfügung, die von Personen untersucht werden kann. Andernfalls entspricht Ihr Kommentar einem 👍 für die ursprüngliche Ausgabe, pingt jedoch alle in der Ausgabe ohne Grund an.

Stellen Sie immer sicher, dass Ihre Kommentare umsetzbar oder nützlich sind. Zum Beispiel ist es nützlich, Dinge wie ematipico zu teilen, die auf der Untersuchung des Problems basieren. "Ich habe immer noch dieses Problem" zu sagen, ist nicht sinnvoll.

Gibt es eine Problemumgehung? Meine CI / CD-Pipeline schlägt bei 1 GB RAM fehl.

@timneutkens Repro-Schritte sind wie in dieser geschlossenen Ausgabe erwähnt:

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

Die @ Vista1nik-Problemumgehung , die für mich funktioniert hat, bestand darin, das veraltete statische Verzeichnis neu zu erstellen.

Die verwandte jetzt Ausgabe:

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

Nur um die Diskussion zu ergänzen, falls es jemandem hilft.
Ich hatte ein Gedächtnismangel und fand dann heraus, worum es in meinem Fall ging:

Wenn im folgenden Code-Snippet const Icon zufällig undefined der Code einfach in eine Endlosschleife eingegeben und überprüft, ob die Komponente gültig ist.

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

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

  return <Icon />;
}

Wenn ich eine Prüfung hinzufüge, wenn const Icon nicht definiert ist, wird das Problem mit dem Speichermangel behoben.

...
  const Icon = iconMapping[name];

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

Das gleiche passierte mir, dann wurde mir klar, dass es ein Tippfehler war, der es verursachte:

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

Bitte versuchen Sie, ein Upgrade auf die neueste Version von Next.js durchzuführen. Wir haben kürzlich eine Reihe von Optimierungen für die Speichernutzung vorgenommen.

@ Timneutkens , ich habe die neueste Version (9.3.5). Ich habe das Projekt heute Morgen erstellt und bin einige Minuten später auf diesen Fehler gestoßen.

Hatte ein ähnliches Problem mit CricleCI beim Erstellen der App mit Quellkarten unter Verwendung von next-source-maps

NODE_OPTIONS="--max_old_space_size=4096" hat lokal geholfen, aber auf CircleCI müssen Sie auch die Ressourcenklasse https://circleci.com/docs/2.0/configuration-reference/#resource_class auf large erhöhen, damit es funktioniert richtig.

Ich habe diesen Fehler nach dem heutigen Update auf 9.3.6 erhalten:

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

Es wurde behoben, indem paths in tsconfig.json geändert wurde, wie in # 12280 vorgeschlagen

Wahrscheinlich andere Ursache

Das gleiche Problem tritt hier nach dem Upgrade von 9.0.5 auf 9.3.6 auf.

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

Irgendeine Idee?

@szaza können Sie versuchen, next@canary , der wahrscheinlichste Fall ist, dass Sie das hier beschriebene Problem haben: https://github.com/zeit/next.js/issues/12280

Ok, nach dem Löschen von node_modules und dem erneuten Installieren von Abhängigkeiten scheint es, dass es mit der kanarischen Version funktioniert, aber ich habe jetzt einen weiteren Fehler: Cannot find module 'next-server/dist/server/next-server'. . Kommt es Ihnen bekannt vor?

Oh, ich habe es verstanden, es wurde auf import Server from "next/dist/next-server/server/next-server"; verschoben.
Jetzt funktioniert es gut. Danke für Ihre Hilfe!

@szaza Wie bist du dazu gekommen, dieses Modul in dein Projekt zu importieren? Es ist ein internes Modul? Ich denke, Sie wollten stattdessen 'next' importieren?

Ich arbeite an einem großen Projekt, das in TypeScript geschrieben wurde. Es ist eine Middleware für die Passauthentifizierung konfiguriert, die die nicht autorisierten Benutzer zurück zur Anmeldeseite leitet. Es wird folgendermaßen implementiert:

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

Nach dem Update der nächsten Version von 9.0.5 auf 9.3.7-canary.0 konnte der Typ Server nicht mehr aus next-server/dist/... importiert werden, sondern aus dem oben genannten Pfad.

Ich hatte den gleichen Fehler, als ich alle Bibliotheken in meiner package.json aktualisiert habe. Derzeit verwende ich NextJS 9.2.2 mit @ zeit / next-css ohne Probleme . Es scheint, als würde eine Version von Bibliotheken nicht genügend Speicherplatz haben oder sie stehen in Konflikt mit NextJS.

Meine aktuelle Paketkonfiguration ist -

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

Ich habe mein spezielles Problem auf die Verwendung der Bibliothek https://github.com/google/schema-dts eingegrenzt. Als Typdefinitionen aus dieser Bibliothek in meiner Next-App verwendet wurden, wurde der Build nie abgeschlossen. Macbook-Fans schalten die volle Leistung ein und spucken schließlich eine OOM-Report-JSON-Datei im Stammverzeichnis des Projekts aus.

Ich habe das Problem behoben, indem ich alle Seiten bis auf eine von pages/ und Code entfernt habe, bis das Projekt erstellt wurde, und dann schrittweise wieder Code eingefügt habe.

Vielleicht hilft das jemandem, der auf diesen Thread stößt 🤷‍♂️

Hatte ein ähnliches Problem mit CricleCI beim Erstellen der App mit Quellkarten unter Verwendung von next-source-maps

NODE_OPTIONS="--max_old_space_size=4096" hat lokal geholfen, aber auf CircleCI müssen Sie auch die Ressourcenklasse https://circleci.com/docs/2.0/configuration-reference/#resource_class auf large erhöhen, damit es funktioniert richtig.

Dies ist das einzige, was für uns funktioniert hat 👍

In einer ziemlich großen Next.js-App (v9.3.6) hatten einige von uns beim Start der App (Dev-Modus) Probleme mit dem Heapspeicher, für die die Einstellung NODE_OPTIONS="--max_old_space_size=4096" für Node 10 oder alternativ für Node 10 hilfreich war Knoten 12 und darüber hinaus wird dies für Sie mit diesem Commit und einem anderen erledigt, der die einem Container zugewiesene Speichermenge berücksichtigt (nur Linux afaik).

Nur um die Diskussion zu ergänzen, falls es jemandem hilft.
Ich hatte ein Gedächtnismangel und fand dann heraus, worum es in meinem Fall ging:

Wenn im folgenden Code-Snippet const Icon zufällig undefined der Code einfach in eine Endlosschleife eingegeben und überprüft, ob die Komponente gültig ist.

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

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

  return <Icon />;
}

Wenn ich eine Prüfung hinzufüge, wenn const Icon nicht definiert ist, wird das Problem mit dem Speichermangel behoben.

...
  const Icon = iconMapping[name];

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

Wie haben Sie herausgefunden, dass dies der Code ist, der dieses Problem verursacht hat?

Interessanterweise sehe ich beim erneuten Betrachten dieses Codes tatsächlich einen anderen
Problem. Das Symbol ist eine Komponente und innerhalb des Symbols habe ich auf das Symbol verwiesen
selbst.

Ich habe es hauptsächlich herausgefunden, indem ich Komponente für Komponente und isoliert habe
Versuchen Sie, das Problem zu reproduzieren, bis ich herausgefunden habe, welche Komponente provoziert hat
Das.

Am 21. Mai 2020 um 18:20 Uhr schrieb Vivek_Neel [email protected] :

Nur um die Diskussion zu ergänzen, falls es jemandem hilft.
Ich hatte ein Gedächtnismangel und fand dann heraus, was das war
Problem in meinem Fall:

Im folgenden Codeausschnitt, wenn das const-Symbol zufällig undefiniert ist
Der Code wird nur in eine Endlosschleife eingegeben und überprüft, ob die Komponente gültig ist.

const iconMapping = {
"Flash-Gliederung": FlashOutline,
};
export const Icon = ({name}) => {
const Icon = iconMapping [Name];

Rückkehr ;;
}}

Wenn ich eine Prüfung hinzufüge, wenn das const-Symbol nicht definiert ist, werde ich das out of los
Speicherproblem.

...
const Icon = iconMapping [Name];

if (! Icon) gibt null zurück;
Rückkehr ;;
}}

Wie haben Sie herausgefunden, dass dies der Code ist, der dies verursacht hat?
Problem?

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/zeit/next.js/issues/7929#issuecomment-632187103 oder
Abmelden
https://github.com/notifications/unsubscribe-auth/ABA2CL7ZJQY5YPYJVCJMCODRSVIE7ANCNFSM4ICM4RAA
.

>

Von meinem Telefon gesendet

Soweit ich verstanden habe, kann Next.js (seit Version 9.0.0) den Speicher großer Webanwendungen nicht optimieren. Unser Erstellungsprozess stößt an die Speichergrenze, wenn mit dem Kompilieren des serverseitigen Teils des Projekts begonnen wird.

Während des Entwicklungsmodus ist der lokale Server anfangs in Ordnung, aber nach einiger Zeit explodiert der zugewiesene Speicher und der Speicherheap-Fehler wird angezeigt.

Könnte jemand aus dem Kernteam dieses Problem bitte anerkennen und uns helfen, das Problem zu lösen?

Selbst mit leistungsstarken Laptops können ich und mein Team die Anwendung manchmal nicht lokal erstellen. Dieses Problem ist fast 1 Jahr alt, aber es gab kein klares Update zu diesem Problem. Persönlich besteht die einzige Problemumgehung darin, die Anwendung in zwei Sub-Next.js-Projekte aufzuteilen, da ich befürchte, dass wir eines Tages nicht einmal in der Lage sein werden, die Anwendung selbst auf dem CI zu erstellen (und wir verwenden bereits leistungsstarke VMs dafür).

Es tut mir so leid, der Böse hier zu sein, ich suche nur um Hilfe.

BEARBEITEN: Wir haben auf Next.js 9.3.3 aktualisiert, aber es wurden keine Verbesserungen vorgenommen

Könnte jemand aus dem Kernteam dieses Problem bitte anerkennen und uns helfen, das Problem zu lösen?

Ich habe Sie in diesem Thread mehrmals gebeten, eine vollständige Reproduktion bereitzustellen oder Ihre Anwendung bereitzustellen. Wir können in Ihrer speziellen Anwendung nichts analysieren, um das Problem in Ihrer Anwendung aufzuspüren.
Wir haben die Sourcemap-Generierung in 9.4 btw geändert, daher sollten Sie auf jeden Fall auf die neueste Version aktualisieren.

FWIW-Fälle wie https://github.com/zeit/next.js/issues/7929#issuecomment -618297553 sind Endlosschleifen, die in Ihrer Anwendung erstellt wurden, und wir können diese nicht sehr gut erkennen (da sie das React-Rendering durchlaufen) ).

Soweit ich verstanden habe, kann Next.js (seit Version 9.0.0) den Speicher großer Webanwendungen nicht optimieren. Unser Erstellungsprozess stößt an die Speichergrenze, wenn mit dem Kompilieren des serverseitigen Teils des Projekts begonnen wird.

Da Sie keine Reproduktion zur Verfügung gestellt haben, kann ich nur auf unsere eigenen Anwendungen verweisen.

Wir führen Millionen von Anfragen auf Next.js aus und die von uns ausgeführten Anwendungen haben mehr als 300 Seiten. Wir haben keine Speicherprobleme von unseren Teams gemeldet und sie arbeiten den ganzen Tag über auf vielen Seiten.

Beachten Sie, dass ich nicht leugne, dass es ein Problem geben könnte. Ich sage nur, dass es unmöglich ist, ein Problem aufzuspüren, wenn Sie keine eindeutige Reproduktion oder Anwendung bereitstellen, die wir profilieren können.
Beachten Sie auch, dass ich nicht einmal darum bitte, dass die Beratung bezahlt wird. Wir werden uns die Anwendung kostenlos ansehen.

Ich habe Sie in diesem Thread mehrmals gebeten, eine vollständige Reproduktion bereitzustellen oder Ihre Anwendung bereitzustellen. Wir können in Ihrer speziellen Anwendung nichts analysieren, um das Problem in Ihrer Anwendung aufzuspüren.

Andere Leute haben hier Repositories bereitgestellt, seit ich die Ausgabe geöffnet habe. Aus diesem Grund wurde das Problem erneut geöffnet und verfügt nicht über das Etikett, das besagt, dass ein Repository erforderlich ist, um das Problem zu reproduzieren.

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

Seitdem wurde es offen gelassen

Ich kann kein Repository bereitstellen, da die Webanwendung meinem Client gehört und der Quellcode geschlossen ist.

Wir haben die Sourcemap-Generierung in 9.4 btw geändert, daher sollten Sie auf jeden Fall auf die neueste Version aktualisieren.

Ist diese Funktion Opt-In / Opt-Out? Ich habe die Generierung von Quellkarten entfernt (dies wurde über das Plugin durchgeführt), nachdem ich das Problem geöffnet hatte (vor so langer Zeit), aber es hat nicht viel geholfen.

Wenn Sie der Meinung sind, dass dieses Problem nicht gültig ist, schließen Sie es bitte. Das Repo wurde vor langer Zeit geteilt und ist möglicherweise nicht mehr gültig.

Ich kann beim Triaging helfen, aber ich brauche Anleitung.

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

Die Reproduktion kann nicht ausgeführt werden, weshalb ich jede einzelne Person, die hier berichtet hat, gebeten habe, auch eine Reproduktion bereitzustellen, um solche Fälle zu vermeiden. Auch das Potenzial, dass diese Probleme zu 100% gleich sind, ist recht gering.

Ist diese Funktion Opt-In / Opt-Out? Ich habe die Generierung von Quellkarten entfernt (dies wurde über das Plugin durchgeführt), nachdem ich das Problem geöffnet hatte (vor so langer Zeit), aber es hat nicht viel geholfen.

Sourcemaps sind in der Entwicklung immer aktiviert, wir haben jedoch auf Eval Source Maps umgestellt.

Aus diesem Grund wurde das Problem erneut geöffnet und verfügt nicht über das Etikett, das besagt, dass ein Repository erforderlich ist, um das Problem zu reproduzieren.

Ich habe es erneut geöffnet, weil immer mehr Berichte eingingen und ich nach Reproduktionen fragte: https://github.com/zeit/next.js/issues/7929#issuecomment -568760542

In diesem Thread sind nur 2 Reproduktionen enthalten. Einer ist völlig unabhängig von Next.js ( now dev Speicherverbrauch) und der andere kann nicht ausgeführt / erstellt werden.

Deshalb bitte ich noch einmal um eine vollständige Reproduktion, sonst ist dies weiterhin unmöglich zu untersuchen.

Ich kann kein Repository bereitstellen, da die Webanwendung meinem Client gehört und der Quellcode geschlossen ist.

Wenden Sie sich an [email protected], und wir können eine NDA einrichten. Dies bedeutet möglicherweise, dass wir eine Beratung für Sie durchführen müssen, da die Einrichtung all dessen nur erheblich dauert helfen Ihnen bei Ihrer speziellen Anwendung und Sie erstellen die Anwendung auch für einen Client.

Ich vermute, diese Anwendungen haben einfach ihre Größengrenzen überschritten, um nicht mehr genügend Speicher zu haben. Sie müssen Ihren Build mit mehr über NODE_OPTIONS=--max-old-space-size=4096 ausführen.

Alternativ können Sie unsere neue Chunking-Funktion aktivieren:

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

Dies hat unser Problem nicht gelöst, FYI.

Weiß jemand, ob dieses Problem beim eingebauten nächsten Serverstart auftritt?
dh: Next start statt NODE_ENV=production node server.js" ?

Mein Problem tritt nach dem Generieren des Builds auf. Auf meinem benutzerdefinierten Server, auf dem "node server.js" ausgeführt wird, wird Speicher aufgebaut, bis ich diesen Fehler erhalte und der Prozess neu gestartet wird. Dies bedeutet, dass alle zwischengespeicherten Routen und Inhalte verloren gehen, sodass der erste Benutzer, der die Seiten danach als betritt, sehr langsam ist Die ganze SSR passiert.

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]

Das ist meine 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"
  }
}

Versuchen Sie für alle, die es mit einem außer Kontrolle geratenen next build zu tun haben, Ihr .babelrc oder babel.config.js löschen. Ich habe ein .babelrc für einen separaten Teil meines Projekts, der nicht mit Next.js zusammenhängt, und es stimmt nicht mit next build überein. In meiner Situation trat das Problem nur in Docker auf. Ich habe es behoben, indem ich meine Docker-Datei geändert habe

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

dazu

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

Wenn Sie gemeinsam genutzte Läufer in GitLab CI verwenden, beenden diese Läufer Ihren Erstellungsprozess mit SIGABRT und lösen diesen Fehler aus. Wir sind zurück zu unserem Gruppenläufer gewechselt und es hat funktioniert.

Für den Fall, dass einer von Ihnen next-transpile-modules , bestand meine Lösung darin, die Einstellung resolveSymlinks (seit v4.1.0) wie folgt zu aktivieren:

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

Ich bin zum ersten Mal auf das hier beschriebene Problem gestoßen, als somepackage "zu groß" wurde (von 500 KB auf 700 KB). Jetzt war plötzlich mein gesamter Speicher (auch mit der 8-GB-Option ausprobiert) nicht mehr ausreichend, um damit umzugehen .

Ich glaube, dass es einige durch Symlinks verursachte Schleifen gibt, die dazu führen, dass der Speicher exponentiell aufgebläht wird.