Next.js: 构建应用程序时，[下9个]内存不足

创建于 2019-07-12 · 66评论 · 资料来源: vercel/next.js

错误报告

描述错误

将应用程序从Next 8移至Next 9。
当我运行next build ，进程内存不足，无法构建应用程序。

仅供参考，这是一个包含20条路线的应用程序。

重现

很难重现，因为我不知道出了什么问题。 Next 8编译没有问题，但Next9没有。

这是堆栈跟踪。如果您知道如何获得更具描述性的输出，请告诉我，我将提供：



<--- Last few GCs --->

[28143:0x102634000]   231190 ms: Mark-sweep 1278.7 (1441.0) -> 1263.4 (1438.5) MB, 838.4 / 0.0 ms  (average mu = 0.290, current mu = 0.268) allocation failure scavenge might not succeed
[28143:0x102634000]   231308 ms: Scavenge 1278.1 (1438.5) -> 1266.6 (1440.0) MB, 8.2 / 0.0 ms  (average mu = 0.290, current mu = 0.268) allocation failure 
[28143:0x102634000]   231365 ms: Scavenge 1279.3 (1440.0) -> 1271.6 (1443.0) MB, 21.6 / 0.0 ms  (average mu = 0.290, current mu = 0.268) allocation failure 


<--- JS stacktrace --->

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

    0: ExitFrame [pc: 0x3547db9dbe3d]
Security context: 0x3a36ebf9e6e1 <JSObject>
    1: DoJoin(aka DoJoin) [0x3a36ebf85e89] [native array.js:~87] [pc=0x3547dcd9a7d0](this=0x3a366f3826f1 <undefined>,l=0x3a368f6eb2b9 <JSArray[10]>,m=10,A=0x3a366f3828c9 <true>,w=0x3a36c3aafc69 <String[1]: />,v=0x3a366f3829a1 <false>)
    2: Join(aka Join) [0x3a36ebf85ed9] [native array.js:~112] [pc=0x3547dd85bb38](this=0x3a366f3826f1 <undefined>,l=0x3a368f6...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003ae75 node::Abort() [/usr/local/bin/node]
 2: 0x10003b07f node::OnFatalError(char const*, char const*) [/usr/local/bin/node]
 3: 0x1001a7ae5 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 4: 0x100572ef2 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/bin/node]
 5: 0x1005759c5 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/usr/local/bin/node]
 6: 0x10057186f v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/bin/node]
 7: 0x10056fa44 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
 8: 0x10057c2dc v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/bin/node]
 9: 0x10057c35f v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/bin/node]
10: 0x10054e1e4 v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/usr/local/bin/node]
11: 0x10082784d v8::internal::Runtime_StringBuilderJoin(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/bin/node]
12: 0x3547db9dbe3d 
[1]    28142 abort      npm run build:next

预期行为

它应该建立

屏幕截图

如果适用，请添加屏幕截图以帮助解释您的问题。

系统信息

作业系统：macOS
节点：10.13.0（它也必须与节点8.X一起使用）
Next.js版本：9.0.1

其他背景

在此处添加有关该问题的任何其他上下文。

needs investigation

资料来源

ematipico

👍38 👀18

最有用的评论

@timneutkens可以在您有回购协议的情况下重新打开该问题？

ematipico 于 2019-09-10

👍21

所有66条评论

没有复制就不可能追踪到这一点。

timneutkens 于 2019-07-12

是的，我知道。在获得围绕源映射的生成的内存堆之前，我将其删除。我在本地数组文件中收到了此错误消息。

有什么方法可以获取更详细的堆栈跟踪信息？

ematipico 于 2019-07-12

仅供参考，它正在构建中，但这仅是因为我向节点进程添加了更多内存：

NODE_OPTIONS="--max_old_space_size=4096"

它最多可建立28条路由，但是当我给出30条路由（我们有31条路由）时，该进程的内存将增加到3GB内存（甚至更多）。我在具有8GB内存的普通笔记本电脑上运行构建过程，其中一些已经使用过。但是成功了。

我不知道是否应该保持此问题开放。
如果有帮助，请查看以下已构建页面的统计信息：

尝试创建源映射时，该过程崩溃（大多数情况下）。

ematipico 于 2019-07-15

我们真正知道的唯一方法是是否提供完整的复制品。我现在将其关闭。

timneutkens 于 2019-07-17

我们也已经注意到，在升级到Next 9之后，我们已经摆脱了内存不足的错误，而对于Next 8，这并不是问题。

在我们的案例中，作为CI流的一部分，我们正在CircleCi中构建应用程序，并且遇到以下情况：

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

CircleCI容器的内存限制为4GB，因此会出现错误。看来我们将要达到该极限的是Next 9。

我目前没有可复制的案例。

danb235 于 2019-07-19

在使用NextJs 9部署应用程序时，我们也遇到了这个问题。

在我们升级到NextJs 9的3个项目中，其中两个在部署到Elastic Beanstalk时面临ram使用问题。最后，我们必须还原它。不幸的是，我没有可共享的仓库来复制问题。

ZhengYuTay 于 2019-07-25

我遇到了同样的内存不足问题，但是在构建所有lambda之后，我的问题就会发生。我可以在笔记本电脑上完成构建，但是在部署时会崩溃，但是在本地开发时我会定期看到一些内存不足的问题。（对我而言）唯一可识别的是此行：

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

这是日志...


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

这是我的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;
    },
  };
};

stevez86 于 2019-08-22

@timneutkens我也正在使用Next.js 9耗尽内存。这可能是由于我们正在编译的组件数量所致。您提到您需要对其进行全面复制。你可以看看我的分支。
https://github.com/stramel/styled-icons/tree/ms/add-material-variants

这是失败的构建： https :

特拉维斯（Travis）已设置NODE_OPTIONS=--max-old-space-size=4096

stramel 于 2019-09-10

@timneutkens可以在您有回购协议的情况下重新打开该问题？

ematipico 于 2019-09-10

👍21

我在[email protected]中面临着同样的问题

Clement-Bresson 于 2019-09-20

👍5

我猜这些应用程序已经达到了它们的大小界限，开始耗尽内存。您需要通过NODE_OPTIONS=--max-old-space-size=4096来运行更多构建。

另外，您可以启用我们的新分块功能：

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

Timer 于 2019-09-20

👍1

感谢@Timer ，我将尝试granularChunks功能。

另外，请注意，我在本地计算机上尝试使用8192作为该值，但仍然失败。我有点不敢想象要实际构建它需要多少内存。

stramel 于 2019-09-20

我查看了一些旧问题，并且发现有时在发布新的主要版本时，有些人会遇到此内存问题。我想知道，您是否对某个大型项目进行了内存测试？

这个新的主要版本即将达到节点内存上限。以前没有的大量内存的原因是什么？

ematipico 于 2019-09-20

@Timer我尝试使用granularChunks功能，但仍然遇到相同的问题。即使在本地也有8192套。

这具有粒度块配置功能集https://github.com/stramel/styled-icons/tree/ms/granular-chunks

切换到动态引入组件， https：//github.com/stramel/styled-icons/tree/ms/dynamic-import-granular-chunks

stramel 于 2019-09-20

当我们更改内部版本以执行压缩时，对于我们的某个存储库而言，会发生此问题，默认情况下该功能已禁用。

更新：我确定在我们的代码库中，问题出在使用withSourceMaps插件：

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

这是有道理的，因为我们将其设置为hidden-source-map ，这非常慢。虽然，我不知道为什么它比NextJS 8慢得多。

jrosspaperless 于 2019-09-30

👍2

升级到v9后，我们还注意到了巨大的性能问题...我使用的是2015年的macbook pro，它从不落后，并且我在上面运行了一些非常繁琐的程序，但是现在每次我在本地运行我的下一个应用程序时它完全落后，一切都大大减慢了速度。

我通常必须每隔10分钟左右重新启动一次应用程序，今天是我努力坚持并完成应用程序的第一天，在开发人员移动中运行了几个小时后，我得到了与人们相同的JavaScript heap out of memory从运行下一个版本报告。这里一定有内存泄漏

mattwills8 于 2019-10-07

我也这么认为。我的一位同事使用的是较新的MacBook，并且自从我们升级到下一个9以来，开发服务器的编译速度越来越慢。有时需要20秒钟。

ematipico 于 2019-10-07

我遇到了同样的问题，甚至尝试在32GB物理内存MacBook Pro上设置NODE_OPTIONS = 16384，但没有任何效果。

日志列出：

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

xxvvii 于 2019-10-10

👍10

@timneutkens请重新打开此问题，或打开一个新的问题。这种内存泄漏以及一些奇怪的无限HMR请求正在使我们的应用在开发模式下无法使用，并占用了大量时间。

mattwills8 于 2019-10-14

👍5

添加另一个见证人。
我继承了Next版本4.2.3的应用程序。

将其更新为下一版本9.1.3
更新了package.json中所有其他软件包的版本；
删除了node_modules文件夹和package.lock.json
运行npm install

当我对项目进行本地服务时，它失败并显示以下错误：
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
故障通常在启动应用程序后不到十分钟内发生，可以通过触发应用程序中的更多导航来加速。

我已还原到8.1.0版，无法重现相同的失败-即使导航更加认真（因此页面构建也是如此）。

mtngoatgit 于 2019-11-10

👍5

是的，我们也看到了...

是时候重新打开了，我想@timneutkens

dan-turner 于 2019-11-13

👍9

自从昨天开始在我的开发模式下导入bootstrap.min.css以来，我也就在下一个@@ 9.1.3上使用react-router定制服务器

当我直接通过js导入带有require / import的bootstrap.min.css或通过CSS / scss导入@import时。在开发过程中经过几次遵从后，我使用的nodejs内存增加了。

但是当我从CDN导入引导程序时，通过在

使用next / head时，即使在长时间的开发过程中遵循了许多标准，内存似乎仍然可以正常运行。

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

所以我认为问题出在next-css中的CSS缩小上。因为当我将项目降级到8.1.0时，我遇到了缩小问题。 https://github.com/zeit/next-plugins/issues/541。所以我尝试了这种解决方法（https://github.com/zeit/next-plugins/issues/392#issuecomment-475845330）。并且尚未再次遇到内存问题。

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

rebotak 于 2019-11-15

升级到Next 9.1.3后遇到同样的问题。我也在使用next-css，也许确实是崩溃的原因？

rcmenezes 于 2019-11-15

不完全确定这是否对每个人都一样，但是请确保检查是否可以找到您所请求的任何资源。我有一个我的应用程序找不到的图像，并且一直在寻找它，直到它给我堆错误。我删除了对该图像的提及，并且它再也没有给我错误。

lloan 于 2019-11-16

👍3

我也设法解决了这个问题， @ lloan评论有助于调试问题。

就我而言，我引用/public/manifest.json为meta的标签<head/> ，但该资源不存在在我的项目，这是造成内存泄漏。

mpsq 于 2019-11-16

我有这段代码，其中icon.png不存在

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

通过修复图标图标的导入，我不再遇到内存泄漏错误

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

正如提到的https://github.com/zeit/now/issues/3307，我相信static / public文件夹有问题。

bukinoshita 于 2019-11-18

我也有这个问题。正如bukinoshita提到的那样，我查看了静态文件夹。我从public/static/文件夹中删除了674个json文件文件夹（出于测试目的）。从那以后我就没有问题了。

JiDai 于 2019-11-18

👍2

当我们更改内部版本以执行压缩时，对于我们的某个存储库而言，会发生此问题，默认情况下该功能已禁用。
更新：我确定在我们的代码库中，问题出在使用withSourceMaps插件：
"@zeit/next-source-maps": "^0.0.4-canary.1"
这是有道理的，因为我们将其设置为hidden-source-map ，这非常慢。虽然，我不知道为什么它比NextJS 8慢得多。

升级到"@zeit/next-source-maps": "^0.0.4-canary.1"之后，我也开始遇到此问题。任何解决方案还是我必须摆脱源映射？

focux 于 2019-11-25

@focux我必须完全禁用源地图。此后，内存使用量大幅下降

ematipico 于 2019-11-25

这里也有同样的问题。当构建中的文件大小太大时，似乎崩溃了。例如，我从Typescript导入了一些内容，构建中的文件大小达到2.41 mb。然后我的2GB内存CI开始崩溃。在删除Typescript导入后，文件大小降到了100kb，并且再次正常工作。

从一开始，Nextjs 9的CI速度就非常慢。构建需要很长时间，而且我没有任何特殊需求...只是在这里和那里反应东西，材料ui，一些软件包。我的CI：与节点/表达式，一些dotnet核心，php等位于同一群集中，所有这些在CI中都有1GB内存，并且构建速度非常快。除了对构建过程的感觉之外，我不了解更多问题吗？

webartistse 于 2019-11-25

👍2

这里同样的问题。 Mac OS / Github操作。此处提到的操作无济于事，找不到链接但不存在的任何文件。

但是，在Zeit Now中进行项目构建（并且正在生产中）。

如果知道如何将很乐意提供帮助。

neoromantic 于 2019-12-09

👍1

同样的问题在这里（MacOS）。我发现的是：

从Next 9.1.5和9.1.6开始。降级到9.1.4会使错误消失。
我在项目内部有自己的_ckeditor_构建，其大小为606KB。如果我删除它，问题就会消失。

让我知道是否可以帮忙。这里有错误日志...

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

rigobauer 于 2019-12-24

SourceMapConsumer_allGeneratedPositionsFor我认为这是罪魁祸首。在开发人员模式下，有一代的源地图。我认为超时，此源地图插件保留了太多的内存。

ematipico 于 2019-12-24

即使关闭源地图生成，我仍然遇到相同的问题

Сергей。

在格林尼治标准时间2019年12月24日10：01，Emanuele [email protected]写道：

SourceMapConsumer_allGeneratedPositions对于我来说，这是罪魁祸首。在开发人员模式下，有一代的源地图。我认为，随着时间的流逝，这些源地图插件会保留过多的内存。

-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看，或取消订阅。

neoromantic 于 2019-12-24

请记住，发布“我仍然会遇到这种情况”将无法解决问题。提供完整的副本供人们研究，否则您的评论与对初始问题的评论相同，但无缘无故地对问题中的每个人进行查验。

始终确保您的评论可行或有用。例如，像ematipico一样，基于调查问题来共享事物很有用。说“我仍然有这个问题”没有用。

timneutkens 于 2019-12-24

❤1 👍1

有什么解决方法吗？我的CI / CD管道在1GB RAM上失败。

Vista1nik 于 2020-01-13

@timneutkens复制步骤如以下已解决的问题所述：

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

对我有用的@ Vista1nik解决方法是重新创建已弃用的静态目录。

现在相关的问题：

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

dan-turner 于 2020-01-14

只是增加讨论以防万一。
我遇到了内存不足的问题，然后发现了我的问题所在：

在以下代码段中，如果const Icon恰好是undefined该代码仅进入无限循环，以检查组件是否有效。

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

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

  return <Icon />;
}

如果我添加了一个未定义const Icon的检查，则摆脱了内存不足的问题。

...
  const Icon = iconMapping[name];

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

tomasfrancisco 于 2020-04-14

同样的事情发生在我身上，然后我意识到是造成它的错字：

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

sandrina-p 于 2020-04-23

请尝试升级到最新版本的Next.js，我们最近对内存使用做了很多优化。

timneutkens 于 2020-04-23

@timneutkens ，我拥有最新版本（9.3.5）。我今天早上创建了这个项目，几分钟后就遇到了这个错误。

sandrina-p 于 2020-04-23

👍3

在使用next-source-maps使用源地图构建应用程序时，在CricleCI上发生了类似的问题

NODE_OPTIONS="--max_old_space_size=4096"在本地得到https://circleci.com/docs/2.0/configuration-reference/#resource_class至少增加到large ，以使其正常工作正确地。

adam187 于 2020-04-23

今天更新到下一个9.3.6后，我开始收到此错误：

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

通过modifiying固定它paths的tsconfig.json为＃12280建议

laurensnl 于 2020-04-28

👍1

原因可能不同

ematipico 于 2020-04-29

从9.0.5升级到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

任何想法？

szaza 于 2020-04-30

@szaza您可以尝试next@canary ，最可能的情况是您遇到了此处描述的问题： https :

timneutkens 于 2020-04-30

👍1

好的，删除node_modules并重新安装依赖项后，它似乎可以使用canary版本，但是现在又出现了另一个错误： Cannot find module 'next-server/dist/server/next-server'. 。您似乎熟悉吗？

szaza 于 2020-04-30

哦，我知道了，它已经移到import Server from "next/dist/next-server/server/next-server"; 。
现在工作正常。谢谢你的帮助！

szaza 于 2020-04-30

@szaza您最终是如何在项目中导入该模块的？这是内部模块吗？我猜您是要导入'next'吗？

timneutkens 于 2020-04-30

我正在用TypeScript编写一个大型项目。配置了一个护照认证中间件，它将未经授权的用户重定向回登录页面。它是通过以下方式实现的：

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

在将下一个版本从9.0.5更新到9.3.7-canary.0之后，无法再从next-server/dist/...导入Server类型，而是从上述路径导入。

szaza 于 2020-04-30

升级package.json中的所有库时，我遇到了相同的错误。目前，我正在使用带有@ zeit / next-css的NextJS 9.2.2 ，没有任何问题。似乎某些版本的库引起了内存不足的问题，或者它们在某种程度上与NextJS冲突。

我当前的软件包配置是-

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

amit08255 于 2020-05-04

我将特定问题的范围缩小到https://github.com/google/schema-dts库的用法

我通过从pages/删除除一页以外的所有页面并删除代码直到项目建立，然后逐步放回代码来调试了该问题。

也许这可以帮助遇到这个问题的人🤷️

wilsonpage 于 2020-05-04

在使用next-source-maps使用源地图构建应用程序时，在CricleCI上发生了类似的问题
NODE_OPTIONS="--max_old_space_size=4096"在本地得到https://circleci.com/docs/2.0/configuration-reference/#resource_class至少增加到large ，以使其正常工作正确地。

这是唯一对我们有用的东西👍

craigcartmell 于 2020-05-13

在相当大的Next.js应用（v9.3.6）上，我们中的许多人在应用启动（开发模式）时遇到堆内存不足的问题，为此设置NODE_OPTIONS="--max_old_space_size=4096"有助于节点10或替代地，节点12及以后，此提交和另一个考虑到分配给容器的内存量（仅Linux afaik）都会为您解决。

davidtrogers 于 2020-05-15

只是增加讨论以防万一。
我遇到了内存不足的问题，然后发现了我的问题所在：
在以下代码段中，如果const Icon恰好是undefined该代码仅进入无限循环，以检查组件是否有效。
const iconMapping = {
  "flash-outline": FlashOutline,
};

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

  return <Icon />;
}
如果我添加了一个未定义const Icon的检查，则摆脱了内存不足的问题。
...
  const Icon = iconMapping[name];

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

您如何确定这是导致此问题的代码段？

VivekNeel 于 2020-05-21

有趣的是，再次查看此代码，我实际上看到了另一个
问题。 Icon是一个组件，在Icon内部，我引用了Icon
本身。

我发现的方法主要是通过逐个组件隔离
尝试重现问题，直到我找出引起问题的原因
那。

2020年5月21日星期四18：20，Vivek_Neel [email protected]写道：

只是增加讨论以防万一。
我遇到了内存不足的情况，然后才知道是什么
我的问题：
在以下代码段中，如果const Icon碰巧未定义
代码只是进入无限循环，检查组件是否有效。
const iconMapping = {
“ flash-outline”：FlashOutline，
};
导出常量图标=（{名称}} => {
const Icon = iconMapping [name];
返回 ;
}
如果我添加了一个检查，如果没有定义const Icon，我摆脱了
内存问题。
...
const Icon = iconMapping [name];
如果（！Icon）返回null;
返回 ;
}
您如何确定这是导致此问题的代码段
问题？
-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/zeit/next.js/issues/7929#issuecomment-632187103 ，或
退订
https://github.com/notifications/unsubscribe-auth/ABA2CL7ZJQY5YPYJVCJMCODRSVIE7ANCNFSM4ICM4RAA
。
>

从我的手机发送

tomasfrancisco 于 2020-05-21

据我了解，Next.js（自v9.0.0起）无法优化大型Web应用程序的内存。当我们的构建过程开始编译项目的服务器端部分时，它达到了内存限制。

在开发模式期间，本地服务器最初运行良好，但是一段时间后，分配的内存耗尽，并且出现内存堆错误。

核心团队中的某人能否请您承认此问题并帮助我们对问题进行分类？

我和我的团队即使拥有强大的笔记本电脑，有时也无法在本地构建应用程序。该问题已存在将近1年，但该问题尚未有明确的更新。就我个人而言，我唯一能想到的解决方法是将应用程序分为两个子Next.js项目，因为我担心有一天我们甚至都无法在CI上构建应用程序（而且我们已经在使用强大的执行此操作的VM）。

很抱歉成为这里的坏人，我只是在寻求帮助。

编辑：我们更新到了Next.js 9.3.3，但是还没有改进

ematipico 于 2020-05-22

👍4

核心团队中的某人能否请您承认此问题并帮助我们对问题进行分类？

我已多次要求您在此线程上提供完整的复制或提供您的应用程序。我们无法分析您特定应用程序中的任何内容来跟踪您应用程序中的问题。
我们已经在9.4 btw中更改了源地图的生成，因此您绝对应该升级到最新版本。

像https://github.com/zeit/next.js/issues/7929#issuecomment -618297553这样的FWIW案例是在应用程序内部创建的无限循环，我们无法很好地检测到它们（因为它们最终会通过React渲染）。

据我了解，Next.js（自v9.0.0起）无法优化大型Web应用程序的内存。当我们的构建过程开始编译项目的服务器端部分时，它达到了内存限制。

鉴于您没有提供复制品，我只能引用我们自己的应用程序。

我们在Next.js上运行数百万个请求，我们运行的应用程序有300多个页面。我们的团队没有报告内存问题，他们一整天都在许多页面上工作。

请注意，这并不是我否认可能存在问题，我只是说如果您不打算提供清晰的复制品或我们可以描述的应用程序，则不可能追踪是否存在问题。
另请注意，我什至不要求提供付费咨询，我们将免费提供该应用程序的外观。

timneutkens 于 2020-05-22

我已多次要求您在此线程上提供完整的复制或提供您的应用程序。我们无法分析您特定应用程序中的任何内容来跟踪您应用程序中的问题。

自从我打开问题以来，其他人都在这里提供了存储库。这就是为什么重新打开该问题的原因，也就是为什么它没有标签说明需要一个存储库才能重现该问题。

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

自从它被打开以来

我无法提供存储库，因为Web应用程序属于我的客户端，并且源代码已关闭。

我们已经在9.4 btw中更改了源地图的生成，因此您绝对应该升级到最新版本。

该功能是选择加入还是选择退出？在我打开问题（很久以前）之后，我删除了源地图的生成（这是通过插件完成的），但是并没有太大帮助。

如果您认为此问题无效，请关闭它。该回购是很久以前共享的，可能不再有效。

我可以帮助您进行分类，但需要指导。

ematipico 于 2020-05-22

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

复制无法执行，因此为什么我要求在这里举报的每个人也提供复制，以避免出现此类情况。同样，这些问题100％相同的可能性非常低。

该功能是选择加入还是选择退出？在我打开问题（很久以前）之后，我删除了源地图的生成（这是通过插件完成的），但是并没有太大帮助。

在开发过程中始终启用源地图，但是我们切换到了评估源地图。

这就是为什么重新打开该问题的原因，也就是为什么它没有标签说明需要一个存储库才能重现该问题。

我重新打开它是因为不断有更多报告出现，并且我不断要求复制： https :

此线程中仅提供2个复制品。一个与Next.js完全无关（ now dev内存消耗），而另一个则无法执行/构建。

因此，为什么我再次要求完整复制，否则将继续无法进行调查。

我无法提供存储库，因为Web应用程序属于我的客户端，并且源代码已关闭。

请随时与[email protected]联系，我们可以设置一个NDA，这可能意味着我们必须为您提供咨询，尽管要花费大量的时间来设置所有这些信息，帮助您处理特定的应用程序，并且还在为客户端构建应用程序。

timneutkens 于 2020-05-22

👍2

我猜这些应用程序已经达到了它们的大小界限，开始耗尽内存。您需要通过NODE_OPTIONS=--max-old-space-size=4096来运行更多构建。
另外，您可以启用我们的新分块功能：
// next.config.js
module.exports = {
  experimental: { granularChunks: true }
}

仅供参考，这并不能解决我们的问题。

ydax 于 2020-09-10

有人知道内置的下一个服务器启动中是否会发生此问题？
即： Next start而不是NODE_ENV=production node server.js" ？

fr-nevin 于 2020-09-15

生成构建后出现了我的问题。在运行“ node server.js”的自定义服务器上，它会建立内存，直到收到该错误，然后重新启动进程，这意味着它将释放所有缓存的路由和内容，因此对于第一个在此之后进入页面的用户来说确实很慢所有的SSR都在发生。

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]

这是我的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"
  }
}

murilozilli 于 2020-10-12

对于可能正在处理失控next build内存不足的任何人，请尝试删除.babelrc或babel.config.js 。我的项目的一部分有.babelrc与Next.js不相关，并且与next build 。就我而言，该问题仅在Docker中发生。我通过更改此文件来修复它

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

对此

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

markplindsay 于 2020-10-12

对于在GitLab CI中使用共享运行程序的人，这些运行程序将使用SIGABRT终止您的构建过程，并依次触发此错误。我们改回了小组赛跑者，并且成功了。

vicary 于 2020-10-22

如果你们中有人使用next-transpile-modules ，我的解决方案是启用resolveSymlinks -setting（自v4.1.0起），如下所示：

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

当somepackage变得“太大”（从500kb到700kb）时，我首先遇到这里描述的问题，突然之间，我所有的内存（也尝试使用8gb选项）不足以解决此问题。

我相信，有一些由符号链接引起的循环会导致内存呈指数级膨胀。

InsOpDe 于 2020-10-30

此页面是否有帮助？

0 / 5 - 0 等级

Next.js: 构建应用程序时，[下9个]内存不足

错误报告

描述错误

重现

预期行为

屏幕截图

系统信息

其他背景

最有用的评论

所有66条评论

>

相关问题