Отследить это без репродукции невозможно.

Да, я знаю. Раньше у меня была куча памяти вокруг генерации исходных карт, поэтому я удалил ее. И я получил это сообщение об ошибке вокруг файла собственного массива.

Есть ли способ получить более подробную трассировку стека?

К вашему сведению, он сейчас создается, но только потому, что я добавил больше памяти в процесс узла:

NODE_OPTIONS="--max_old_space_size=4096"

Он создает до 28 маршрутов, но когда я даю 30 маршрутов (у нас есть 31 маршрут), объем памяти процесса достигает 3 ГБ (и даже больше). Я запускаю процесс сборки на среднем ноутбуке с 8 ГБ памяти, некоторые из которых уже используются. Но это удалось.

Я не знаю, следует ли держать этот вопрос открытым или нет.
Если поможет, вот статистика построенных страниц:

Процесс вылетает при попытке создать исходные карты (в большинстве случаев).

На самом деле, единственный способ узнать, будет ли предоставлено полное воспроизведение. Я пока закрою это.

Мы тоже заметили, что после обновления до Next 9 мы получаем ошибки нехватки памяти, тогда как с Next 8 это не было проблемой.

В нашем случае мы создаем наше приложение в CircleCi как часть нашего потока CI и сталкиваемся со следующим:

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 ГБ - это ограничение памяти для контейнера CircleCI, отсюда и ошибка. Похоже, что с Next 9 мы достигли этого предела.

На данный момент у меня нет воспроизводимого случая.

Мы также столкнулись с этой проблемой при развертывании моего приложения с NextJs 9.

Из 3 проектов, которые мы обновили до NextJs 9, два из них сталкиваются с проблемой использования оперативной памяти при развертывании на Elastic Beanstalk. В конце концов, мы должны это вернуть. К сожалению, у меня нет репо, которым можно было бы поделиться, чтобы воспроизвести проблему.

У меня такая же проблема с памятью, но моя возникает после создания всех лямбда-выражений. Я могу завершить сборку на своем ноутбуке, но он дает сбой при развертывании, однако я периодически замечал несколько проблем с нехваткой памяти при локальной разработке. Единственное, что узнаваемо (для меня) - это строка:

 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

Вот моя конфигурация веб-пакета:

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 У меня заканчивается память и при использовании Next.js 9. Это могло быть из-за количества компилируемых компонентов. Вы упомянули, что вам нужно его полное воспроизведение. Можете посмотреть мою ветку.
https://github.com/stramel/styled-icons/tree/ms/add-material-variants

Вот неудачная сборка: https://travis-ci.org/jacobwgillespie/styled-icons/builds/582987078

У Трэвиса есть набор NODE_OPTIONS=--max-old-space-size=4096

@timneutkens может, пожалуйста, снова открыть проблему, когда у вас есть репо?

У меня такая же проблема с [email protected].

Я предполагаю, что эти приложения просто достигли своих пределов размера, чтобы начать исчерпывать память. Вам нужно будет запустить сборку с другими через NODE_OPTIONS=--max-old-space-size=4096 .

Кроме того, вы можете включить нашу новую функцию фрагментации:

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

Спасибо @Timer , я granularChunks .

Также, чтобы отметить, я попробовал 8192 для значения на моем локальном компьютере, но все равно не удалось. Я немного боюсь представить, сколько памяти мне понадобится, чтобы собрать его.

Я посмотрел на какую-то старую проблему и заметил, что иногда, когда выходил новый основной выпуск, некоторые люди сталкивались с этой проблемой памяти. Интересно, вы проводите тест памяти на каком-нибудь большом проекте?

Этот новый основной выпуск достигает предела памяти узла. В чем причина такого большого объема памяти, которого раньше не было?

@Timer Я пробовал использовать granularChunks но все равно столкнулся с той же проблемой. Даже локально с набором 8192.

У этого есть набор функций конфигурации гранулярных блоков https://github.com/stramel/styled-icons/tree/ms/granular-chunks

Переключен на динамическое извлечение компонентов,

Эта проблема возникает для одного из наших репозиториев, когда мы изменяем сборку для выполнения минификации, которая сейчас отключена по умолчанию.

Обновление: я определил, что в нашей кодовой базе проблема заключалась в использовании плагина withSourceMaps :

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

Это имеет смысл, поскольку у нас установлено значение hidden-source-map что очень медленно. Хотя я не знаю, почему он экспоненциально медленнее, чем NextJS 8.

Мы также заметили серьезные проблемы с производительностью после обновления до v9 ... Я использую macbook pro 2015 года, он никогда не отставал, и я запускал на нем довольно тяжелые программы, но теперь каждый раз, когда я запускаю свое следующее приложение локально полностью тормозит и все массово тормозит.

Обычно я должен перезапустить приложение каждые 10 минут или около того , сегодня был первый день я пытался упорствовать и работать через него, и через пару часов работы в Dev ходу я получил тот же JavaScript heap out of memory , что люди сообщили о запуске следующей сборки. Где-то здесь должна быть утечка памяти

Я тоже так думаю. У моего коллеги более свежий MacBook, и с тех пор, как мы обновились до следующих 9, сервер разработки стал медленнее перекомпилировать. Иногда это занимает до 20 секунд.

У меня такая же проблема, даже попытался установить NODE_OPTIONS = 16384 на моем MacBook Pro с физической памятью 32 ГБ, но никакого эффекта.

Журналы перечислены:

==== 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, пожалуйста, откройте этот выпуск повторно или откройте новый. Эта утечка памяти, а также некоторые странные бесконечные запросы HMR делают наше приложение непригодным для использования в режиме разработки и отнимают у нас огромное количество времени.

Добавление еще одного свидетеля.
Я унаследовал приложение с версией 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 и не могу воспроизвести ту же ошибку - даже при более серьезной навигации (и, следовательно, при построении страниц).

Да, мы тоже это видим ...

Пора открыться, думаю, @timneutkens

Я столкнулся с этой проблемой также на [email protected] с настраиваемым сервером

и когда я напрямую импортирую bootstrap.min.css с помощью require / import через js или @import через css / scss. моя используемая память nodejs была увеличена после нескольких выполнений во время разработки.

но когда я импортирую начальную загрузку с cdn через в

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

поэтому я думаю, что проблема была в минификации css в next-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;
  },
});

У меня такая же проблема после обновления до Next 9.1.3. Я тоже использую next-css, может быть, это действительно его сбой?

Не совсем уверен, будет ли это одинаково для всех, но убедитесь, что любой запрашиваемый вами ресурс действительно может быть найден. У меня было изображение, которое мое приложение не могло найти, и оно продолжало его искать, пока не выдало ошибку кучи. Я удалил упоминание об этом изображении, и ошибка больше не возникала.

Мне тоже удалось это исправить, комментарий @lloan помог отладить проблему.

В моем случае я ссылался на /public/manifest.json как на тег meta в <head/> , однако этот ресурс отсутствовал в моем проекте, и это вызывало утечку памяти.

У меня был этот код, которого 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 .

У меня тоже была эта пробема. Как сказал Букиносита, я заглянул в статическую папку. Я удалил папку с 674 файлами json (для целей тестирования) из папки public/static/ . С тех пор у меня не было проблемы.

Эта проблема возникает для одного из наших репозиториев, когда мы изменяем сборку для выполнения минификации, которая сейчас отключена по умолчанию.

Обновление: я определил, что в нашей кодовой базе проблема заключалась в использовании плагина 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 Мне пришлось вообще отключить исходные карты. После этого использование памяти существенно упало.

И здесь такая же проблема. Кажется, вылетает, когда размер файла в сборке слишком велик. Например, я импортировал что-то из Typescript, и размер файла в сборке увеличился до 2,41 мб. Затем мой CI с оперативной памятью 2 ГБ начал вылетать. После того, как я удалил импорт Typescript, размер файла уменьшился до 100 КБ, и он снова заработал.

Nextjs 9 с самого начала был очень медленным в CI. Сборка занимает очень много времени, и у меня нет никаких особых потребностей ... просто реагируйте на вещи, материал пользовательского интерфейса, некоторые пакеты здесь и там. У меня есть CI: s в одном кластере с node / express, некоторым ядром dotnet, php и т. Д., Все они имеют 1 ГБ памяти в CI и собираются довольно быстро. Я не знаю больше, чем мое мнение о процессе сборки, может быть, есть какие-то проблемы?

Здесь та же проблема. Mac OS / Действия Github. Никакие упомянутые здесь действия не помогают, не удается найти файлы, которые связаны, но не существуют.

Однако проект строится (и находится в разработке) в Zeit Now.

Хотел бы помочь, если бы знал, как.

Такая же проблема здесь (MacOS). Я обнаружил:

• Начинает происходить с Next 9.1.5 и 9.1.6. При переходе на 9.1.4 ошибка исчезнет.
• У меня внутри проекта есть собственная сборка _ckeditor_ размером 606 КБ. Если я его удалю, проблема исчезнет.

Сообщите мне, если я могу помочь. Вот журнал ошибок ...

<--- 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 Думаю, это виноват. В режиме разработки есть генерация исходных карт. Я думаю, что со временем этот плагин карты исходного кода сохраняет слишком много памяти.

У меня все еще возникает та же проблема, даже если я отключу создание исходной карты

Сергей.

24 декабря 2019 года в 10:01 по Гринвичу Emanuele [email protected] написал:

SourceMapConsumer_allGeneratedPositionsFor я думаю, что это виноват. В режиме разработки есть генерация исходных карт. Я думаю, что со временем этот плагин карты источников сохраняет слишком много памяти.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub или откажитесь от подписки .

Помните, что сообщение «Я все еще испытываю это» не решит проблему. Предоставьте людям возможность ознакомиться с полным воспроизведением, иначе ваш комментарий будет таким же, как и по первоначальной проблеме, но без всякой причины пинговать всех, кто ее затронул.

Убедитесь, что ваши комментарии актуальны или полезны. Например, как ematipico, делиться вещами, основанными на исследовании проблемы, полезно. Сказать «У меня все еще есть эта проблема» бесполезно.

Есть ли обходной путь? Мой конвейер CI / CD не работает на 1 ГБ ОЗУ.

Шаги воспроизведения @timneutkens указаны в этом закрытом выпуске:

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

Обходной путь

Связанная с этим проблема:

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

Просто чтобы добавить к обсуждению, если это кому-то поможет.
У меня была нехватка памяти, а затем я узнал, в чем проблема в моем случае:

В следующем фрагменте кода, если 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 />;
}

То же самое произошло и со мной, но потом я понял, что причиной этого была опечатка:

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

Пожалуйста, попробуйте обновить Next.js до последней версии, мы недавно сделали несколько оптимизаций использования памяти.

@timneutkens , у меня последняя версия (9.3.5). Я создал проект сегодня утром и через несколько минут столкнулся с этой ошибкой.

Была аналогичная проблема с CricleCI при создании приложения с исходными картами с использованием next-source-maps

NODE_OPTIONS="--max_old_space_size=4096" помогло локально, но на CircleCI вам также необходимо увеличить класс ресурсов https://circleci.com/docs/2.0/configuration-reference/#resource_class до large по крайней мере, чтобы заставить его работать должным образом.

Я начал получать эту ошибку после обновления до следующей версии 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
...

Исправлено путем изменения paths в tsconfig.json как предложено в # 12280

Наверное другая причина

Та же проблема присутствует и после обновления с 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, можешь попробовать next@canary , наиболее вероятный случай - проблема, описанная здесь: https://github.com/zeit/next.js/issues/12280

Хорошо, после удаления node_modules и переустановки зависимостей кажется, что он работает с канареечной версией, однако теперь у меня другая ошибка: Cannot find module 'next-server/dist/server/next-server'. . Вам это кажется знакомым?

О, я понял, он перемещен в import Server from "next/dist/next-server/server/next-server"; .
Теперь работает нормально. Спасибо за вашу помощь!

@szaza, как вы в итоге импортировали этот модуль в свой проект? Это внутренний модуль? Полагаю, вы хотели вместо этого импортировать 'next' ?

Я работаю над большим проектом, написанным на 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 тип Server больше не может быть импортирован из next-server/dist/... , но из пути, указанного выше.

У меня была такая же ошибка, когда я обновил все библиотеки в своем package.json. В настоящее время я использую NextJS 9.2.2 с @ zeit / next-css без каких-либо проблем. Похоже, что в какой-то версии библиотек возникает проблема нехватки памяти или они каким-то образом конфликтуют с 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"
  }
}

Я сузил свою конкретную проблему до использования библиотеки https://github.com/google/schema-dts. Когда определения типов из этой библиотеки использовались в моем приложении Next, сборка так и не была завершена, фанаты Macbook выходили на полную мощность и в конечном итоге выплюнули какой-то json-файл отчета OOM в корне проекта.

Я отладил проблему, удалив все страницы, кроме одной, из pages/ и удалив код до тех пор, пока проект не будет построен, а затем постепенно вернул код обратно.

Может быть, это поможет тому, кто попадется на эту тему thread

Была аналогичная проблема с CricleCI при создании приложения с исходными картами с использованием next-source-maps

NODE_OPTIONS="--max_old_space_size=4096" помогло локально, но на CircleCI вам также необходимо увеличить класс ресурсов https://circleci.com/docs/2.0/configuration-reference/#resource_class до large по крайней мере, чтобы заставить его работать должным образом.

Это единственное, что у нас сработало 👍

В довольно большом приложении Next.js (v9.3.6) многие из нас сталкивались с проблемами нехватки памяти кучи при запуске приложения (режим разработчика), для которых установка NODE_OPTIONS="--max_old_space_size=4096" помогала для Node 10 или, альтернативно, на Узел 12 и выше, вы позаботитесь об этом с помощью другого, который учитывает объем памяти, выделенной контейнеру (только для Linux afaik).

Просто чтобы добавить к обсуждению, если это кому-то поможет.
У меня была нехватка памяти, а затем я узнал, в чем проблема в моем случае:

В следующем фрагменте кода, если 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 />;
}

Как вы выяснили, что именно этот фрагмент кода вызвал проблему?

Достаточно интересно, глядя на этот код еще раз, я действительно вижу еще один
проблема. Значок - это компонент, и внутри значка я ссылался на значок
сам.

Я понял это в основном путем изоляции компонента за компонентом и
попытайтесь воспроизвести проблему, пока не выясню, какой компонент вызывал
тот.

21 мая 2020 года в 18:20 Vivek_Neel [email protected] написал:

Просто чтобы добавить к обсуждению, если это кому-то поможет.
У меня не хватало памяти, а потом я узнал, что это за
проблема в моем случае:

В следующем фрагменте кода, если значок const не определен
код просто входит в бесконечный цикл, проверяя, действителен ли компонент.

const iconMapping = {
"flash-outline": FlashOutline,
};
экспорт const Icon = ({name}) => {
const Icon = iconMapping [имя];

возвращение ;
}

Если я добавлю проверку, если значок const не определен, я избавлюсь от
проблема с памятью.

...
const Icon = iconMapping [имя];

если (! Значок) вернет ноль;
возвращение ;
}

Как вы поняли, что именно этот фрагмент кода вызвал это
проблема?

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/zeit/next.js/issues/7929#issuecomment-632187103 или
отказаться от подписки
https://github.com/notifications/unsubscribe-auth/ABA2CL7ZJQY5YPYJVCJMCODRSVIE7ANCNFSM4ICM4RAA
.

>

Отправлено с моего телефона

Насколько я понял, Next.js (начиная с v9.0.0) не умеет оптимизировать память больших веб-приложений. Наш процесс сборки достигает предела памяти, когда начинает компилировать серверную часть проекта.

В режиме разработки локальный сервер изначально в порядке, но через некоторое время выделенная память взрывается, и появляется ошибка кучи памяти.

Может ли кто-нибудь из основной команды признать эту проблему и помочь нам в ее сортировке?

Я и моя команда, даже имея мощные ноутбуки, иногда не можем создать приложение локально. Этой проблеме почти 1 год, но четких обновлений по ней не было. Лично я могу придумать единственный обходной путь - разделить приложение на два дочерних проекта Next.js, потому что я обеспокоен тем, что однажды мы даже не сможем построить приложение даже на CI (а мы уже используем мощные ВМ для этого).

Мне так жаль, что я здесь плохой парень, я просто ищу помощи.

РЕДАКТИРОВАТЬ: мы обновились до Next.js 9.3.3, но улучшений не было

Может ли кто-нибудь из основной команды признать эту проблему и помочь нам в ее сортировке?

Я несколько раз просил вас в этой ветке предоставить полное воспроизведение или предоставить ваше приложение. Мы не можем ничего анализировать в вашем конкретном приложении, чтобы отследить проблему в вашем приложении.
Мы изменили генерацию исходной карты в 9.4, кстати, так что вам обязательно стоит перейти на последнюю версию.

Случаи FWIW, такие как https://github.com/zeit/next.js/issues/7929#issuecomment -618297553, представляют собой бесконечные циклы, созданные внутри вашего приложения, и мы не можем их очень хорошо обнаружить (поскольку они в конечном итоге проходят через рендеринг React ).

Насколько я понял, Next.js (начиная с v9.0.0) не умеет оптимизировать память больших веб-приложений. Наш процесс сборки достигает предела памяти, когда начинает компилировать серверную часть проекта.

Учитывая, что вы не предоставили репродукцию, я могу ссылаться только на наши собственные приложения.

Мы выполняем миллионы запросов на Next.js, а приложения, которые мы запускаем, содержат более 300 страниц. Наши команды не сообщали о проблемах с памятью, и они работают над множеством страниц в течение дня.

Обратите внимание: я не отрицаю, что может быть проблема, я просто говорю, что невозможно отследить, есть ли проблема, если вы не собираетесь предоставить четкое воспроизведение или приложение, которое мы можем профилировать.
Также обратите внимание, что я даже не прошу, чтобы это была платная консультация, мы бесплатно посмотрим на приложение.

Я несколько раз просил вас в этой ветке предоставить полное воспроизведение или предоставить ваше приложение. Мы не можем ничего анализировать в вашем конкретном приложении, чтобы отследить проблему в вашем приложении.

Другие люди предоставили здесь репозитории с тех пор, как я открыл проблему. Вот почему проблема была повторно открыта, и поэтому на ней нет ярлыка, в котором говорится, что для воспроизведения проблемы требуется репозиторий.

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

С тех пор, как он был оставлен открытым

Я не могу предоставить репозиторий, потому что веб-приложение принадлежит моему клиенту, а исходный код закрыт.

Мы изменили генерацию исходной карты в 9.4, кстати, так что вам обязательно стоит перейти на последнюю версию.

Включена / отключена эта функция? Я удалил генерацию исходных карт (это было сделано через плагин) после того, как открыл проблему (очень давно), но это не сильно помогло.

Если вы считаете, что эта проблема не актуальна, закройте ее. Репо было опубликовано давно, и, возможно, оно больше не действует.

Я могу помочь с сортировкой, но мне нужен совет.

▲  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% одинаковыми, довольно низка.

Включена / отключена эта функция? Я удалил генерацию исходных карт (это было сделано через плагин) после того, как открыл проблему (очень давно), но это не сильно помогло.

Исходные карты всегда включены в разработке, хотя мы перешли на исходные карты eval.

Вот почему проблема была повторно открыта, и поэтому на ней нет ярлыка, в котором говорится, что для воспроизведения проблемы требуется репозиторий.

Я снова открыл его, потому что продолжали поступать новые отчеты, и я продолжал просить репродукции: https://github.com/zeit/next.js/issues/7929#issuecomment -568760542

В этой ветке представлены только 2 репродукции. Один полностью не связан с Next.js (потребление памяти now dev ), а другой не может быть выполнен / построен.

Поэтому я еще раз прошу о полном воспроизведении, иначе это будет по-прежнему невозможно исследовать.

Я не могу предоставить репозиторий, потому что веб-приложение принадлежит моему клиенту, а исходный код закрыт.

Не стесняйтесь обращаться по адресу [email protected], и мы можем создать соглашение о неразглашении, потенциально это означает, что нам придется проконсультировать вас, хотя, учитывая, что настройка всего этого займет значительное количество времени, просто чтобы помочь вам с вашим конкретным приложением, и вы также создаете приложение для клиента.

Я предполагаю, что эти приложения просто достигли своих пределов размера, чтобы начать исчерпывать память. Вам нужно будет запустить сборку с другими через NODE_OPTIONS=--max-old-space-size=4096 .

Кроме того, вы можете включить нашу новую функцию фрагментации:

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

Это не решило нашу проблему, к вашему сведению.

Кто-нибудь знает, возникает ли эта проблема при следующем запуске встроенного сервера?
то есть: Next start а не NODE_ENV=production node server.js" ?

Моя проблема возникает после создания сборки. На моем настраиваемом сервере, на котором запущен "node server.js", он накапливает память до тех пор, пока я не получу эту ошибку, и процесс не будет перезапущен, что означает, что он теряет все кэшированные маршруты и прочее, поэтому это действительно медленно для первого пользователя, который входит на страницы после этого, поскольку все сср происходит.

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

Для тех, кто может иметь дело с беглым next build заканчивается память, попробуйте удалить .babelrc или babel.config.js . У меня есть .babelrc для отдельной части моего проекта, не связанной с Next.js, и она не соответствует next build . В моей ситуации проблема возникала только в Docker. Я исправил это, изменив свой Dockerfile с этого

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

Для тех, кто использует общие бегуны в GitLab CI, эти бегуны завершат ваш процесс сборки с помощью SIGABRT и, в свою очередь, вызовут эту ошибку. Мы вернулись к нашему групповому бегу, и это сработало.

В случае, если кто-то из вас использует next-transpile-modules , моим решением было включить resolveSymlinks -setting (начиная с v4.1.0) следующим образом:

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

Я впервые столкнулся с проблемой, описанной здесь, когда somepackage стал "слишком большим" (от 500 до 700 КБ), теперь внезапно всей моей памяти (также пробовал с опцией 8 ГБ) было недостаточно, чтобы справиться с этим. .

Я считаю, что есть некоторые петли, вызванные символическими ссылками, которые приводят к экспоненциальному раздутию памяти.