من المستحيل تعقب ذلك بدون إعادة إنتاج.

نعم اعرف. قبل أن أحصل على كومة ذاكرة حول إنشاء خرائط المصادر ، لذا قمت بإزالتها. وقد تلقيت رسالة الخطأ هذه حول ملف المصفوفة الأصلي.

هل هناك طريقة ما للحصول على تتبع مكدس أكثر تفصيلاً؟

لمعلوماتك ، يتم البناء الآن ولكن فقط لأنني أضفت المزيد من الذاكرة إلى عملية العقدة:

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 ، ومن هنا الخطأ. يبدو أننا نبني مع التالي 9 نحن نصل إلى هذا الحد.

ليس لدي حالة قابلة للتكرار لمشاركتها في الوقت الحالي.

لقد واجهنا هذه المشكلة أيضًا أثناء نشر تطبيقي مع NextJs 9.

من بين المشاريع الثلاثة التي قمنا بالترقية إلى 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

تم التبديل لسحب المكونات ديناميكيًا ، https://github.com/stramel/styled-icons/tree/ms/dynamic-import-granular-chunks

تحدث هذه المشكلة لأحد مستودعاتنا عندما نغير البنية لأداء التصغير ، والذي تم تعطيله افتراضيًا الآن.

تحديث: لقد قررت أن المشكلة في قاعدة التعليمات البرمجية الخاصة بنا كانت تستخدم المكون الإضافي withSourceMaps :

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

هذا منطقي نظرًا لأننا قمنا بتعيينه على hidden-source-map وهو بطيء جدًا. رغم ذلك ، لا أعرف لماذا هو أبطأ بشكل كبير من NextJS 8.

لقد لاحظنا أيضًا مشكلات كبيرة في الأداء بعد الترقية إلى الإصدار 9 ... أنا أستخدم جهاز macbook pro لعام 2015 ، ولم يتأخر أبدًا من قبل وقمت بتشغيل بعض البرامج الثقيلة عليه ، ولكن الآن في كل مرة أقوم بتشغيل تطبيقي التالي محليًا إنه متأخر تمامًا وكل شيء يتباطأ بشكل كبير.

عادةً ما أضطر إلى إعادة تشغيل التطبيق كل 10 دقائق أو نحو ذلك ، كان اليوم أول يوم حاولت فيه المثابرة والعمل من خلاله ، وبعد ساعتين من الجري في خطوة التطوير ، حصلت على نفس JavaScript heap out of memory هذا الأشخاص أبلغت من تشغيل الإصدار التالي. يجب أن يكون هناك تسرب للذاكرة هنا في مكان ما

أظن ذلك أيضا. لدى زميل لي جهاز MacBook أحدث ومنذ أن قمنا بالترقية إلى 9 التالي ، أصبح خادم dev أبطأ في إعادة الترجمة. أحيانًا يستغرق الأمر 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 الغريبة اللانهائية إلى جعل تطبيقنا غير قابل للاستخدام في وضع التطوير ويستهلك قدرًا كبيرًا من وقتنا.

إضافة شاهد آخر.
لقد ورثت تطبيقًا بالإصدار التالي 4.2.3.

• تم تحديثه إلى الإصدار التالي 9.1.3
• تم تحديث جميع إصدارات الحزم الأخرى في package.json ؛
• تم حذف المجلد node_modules و package.lock.json
• ركض تثبيت npm

عندما قدمت خدمة محلية للمشروع ، فشلت بسبب الخطأ التالي:
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
عادة ما يحدث الفشل في غضون أقل من عشر دقائق من بدء التطبيق ويمكن تسريع ذلك من خلال تشغيل المزيد من التنقل في التطبيق.

لقد عدت إلى الإصدار 8.1.0 ولا يمكنني إعادة إنتاج نفس الفشل - حتى مع التنقل الأكثر جدية (وبالتالي إنشاء الصفحات).

نعم ، نحن نشهد هذا أيضًا ...

حان الوقت لإعادة الفتح على ما أعتقد Timneutkens

أواجه هذه المشكلة أيضًا على [email protected] مع خادم مخصص التفاعلي منذ أمس منذ أن بدأت في استيراد bootstrap.min.css في وضع التطوير الخاص بي.

كلاهما عند استيراد ملف bootstrap.min.css مباشرةً مع طلب / استيراد عبر 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 .

كان لي هذه المشكلة أيضا. كما ذكرها bukinoshita ، نظرت في المجلد الثابت. لقد قمت بإزالة مجلد مكون من 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 جيجابايت في الانهيار. بعد أن قمت بإزالة ملف استيراد الأنواع ، انخفض حجم الملف إلى 100 كيلو بايت وعمل مرة أخرى.

كان Nextjs 9 بطيئًا جدًا في CI منذ البداية. يستغرق البناء وقتًا طويلاً وليس لدي أي احتياجات خاصة ... فقط قم برد فعل الأشياء ، ومواد واجهة المستخدم ، وبعض الحزم هنا وهناك. لدي CI: s في نفس المجموعة مع node / express ، بعض نواة dotnet ، php وغيرها ، كل هذه تحتوي على ذاكرة 1 جيجا بايت في CI وتبني بسرعة كبيرة. أنا لا أعرف أكثر من شعوري حول عملية البناء لديها بعض المشاكل ربما؟

نفس المشكلة هنا. إجراءات Mac OS / Github. لا توجد إجراءات مذكورة هنا تساعد ، لا يمكن العثور على أي ملفات مرتبطة ولكنها غير موجودة.

ومع ذلك ، فإن المشروع يبني (وهو قيد الإنتاج) في تسايت ناو.

أحب المساعدة إذا عرفت كيف.

نفس المشكلة هنا (MacOS). ما وجدته هو:

• يبدأ في الحدوث مع التالي 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 أعتقد أن هذا هو الجاني. في وضع dev ، يوجد جيل من خرائط المصدر. أعتقد أن هذا المكون الإضافي لخريطة المصدر يحتفظ بذاكرة كبيرة جدًا.

ما زلت أواجه نفس المشكلة حتى إذا أوقفت إنشاء خريطة المصدر

Сергей.

في 24 كانون الأول (ديسمبر) 2019 ، الساعة 10:01 بتوقيت جرينتش ، كتب Emanuele [email protected] :

SourceMapConsumer_allGeneratedPositions لأعتقد أن هذا هو الجاني. في وضع dev ، يوجد جيل من خرائط المصدر. أعتقد أن هذا المكون الإضافي لخريطة المصدر يحتفظ بذاكرة كبيرة جدًا.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بإلغاء الاشتراك .

ضع في اعتبارك أن نشر "ما زلت أعاني من ذلك" لن يحل المشكلة. قدم نسخة كاملة للناس للنظر فيها ، وإلا فإن تعليقك سيكون مثل القيام بـ 👍 بشأن المشكلة الأولية ولكن مع إجراء اختبار ping على كل شخص في المشكلة بدون سبب.

تأكد دائمًا من أن تعليقاتك قابلة للتنفيذ أو مفيدة. على سبيل المثال ، مثل مشاركة ematipico للأشياء بناءً على التحقيق في المشكلة أمر مفيد. إن قول "ما زلت أعاني من هذه المشكلة" ليس مفيدًا.

هل هناك أي عمل في الأرجاء؟ فشل خط أنابيب CI / CD الخاص بي على 1 غيغابايت من ذاكرة الوصول العشوائي.

خطوات reprotimneutkens كما هو مذكور في هذه المسألة المغلقة:

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

@ Vista1nik كان الحل البديل الذي

القضية ذات الصلة الآن:

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 وإعادة تثبيت التبعيات ، يبدو أنه يعمل مع إصدار canary ، ولكن لدي الآن خطأ آخر: 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/ وإزالة الرمز حتى تم إنشاء المشروع ثم إعادة إدخال الكود تدريجيًا.

ربما يساعد هذا الشخص الذي يأتي عبر هذا الموضوع 🤷‍♂️

واجهت مشكلة مماثلة على 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 الكبير نسبيًا (الإصدار 9.3.6) ، واجه عدد منا مشكلات ذاكرة الكومة عند بدء تشغيل التطبيق (وضع dev) حيث ساعد إعداد NODE_OPTIONS="--max_old_space_size=4096" لـ Node 10 ، أو بالتناوب على Node 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 = {
"مخطط فلاش": FlashOutline ،
} ؛
تصدير رمز const = ({name}) => {
رمز const = iconMapping [الاسم] ؛

إرجاع ؛
}

إذا أضفت فحصًا إذا لم يتم تعريف رمز const ، فأنا أتخلص من
قضية الذاكرة.

...
رمز const = iconMapping [الاسم] ؛

إذا (! Icon) إرجاع فارغ ؛
إرجاع ؛
}

كيف استنتجت أن هذا هو جزء الكود الذي تسبب في ذلك
القضية؟

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/zeit/next.js/issues/7929#issuecomment-632187103 ، أو
إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ABA2CL7ZJQY5YPYJVCJMCODRSVIE7ANCNFSM4ICM4RAA
.

>

أرسلت من هاتفي

بقدر ما فهمت ، Next.js (منذ الإصدار 9.0.0) غير قادر على تحسين ذاكرة تطبيقات الويب الكبيرة. تصل عملية البناء الخاصة بنا إلى الحد الأقصى للذاكرة عندما تبدأ في تجميع الجزء الجانبي من الخادم من المشروع.

أثناء وضع التطوير ، يكون الخادم المحلي جيدًا في البداية ولكن بعد مرور بعض الوقت تنفجر الذاكرة المخصصة ويظهر خطأ كومة الذاكرة.

هل يمكن لشخص من الفريق الأساسي الاعتراف بهذه المشكلة ومساعدتنا في فرز المشكلة؟

أنا وفريقي ، حتى مع أجهزة الكمبيوتر المحمولة القوية ، غير قادرين على إنشاء التطبيق محليًا في بعض الأحيان. هذه المشكلة عمرها عام واحد تقريبًا ولكن لم يكن هناك تحديث واضح حول هذه المشكلة. شخصيًا ، الحل الوحيد الذي يمكنني التفكير فيه هو تقسيم التطبيق إلى مشروعين فرعيين من Next.js لأنني قلق من أنه في يوم من الأيام لن نتمكن حتى من إنشاء التطبيق حتى على CI (ونحن بالفعل نستخدم أجهزة افتراضية للقيام بذلك).

أنا آسف جدًا لكوني الرجل السيئ هنا ، أنا فقط أسعى للحصول على المساعدة.

تحرير: قمنا بالتحديث إلى Next.js 9.3.3 ولكن لم تكن هناك تحسينات

هل يمكن لشخص من الفريق الأساسي الاعتراف بهذه المشكلة ومساعدتنا في فرز المشكلة؟

لقد طلبت منك عدة مرات في هذا الموضوع تقديم نسخة كاملة أو تقديم طلبك. لا يمكننا تحليل أي شيء في التطبيق الخاص بك لتعقب المشكلة في التطبيق الخاص بك.
لقد غيّرنا إنشاء خرائط المصادر في 9.4 راجع للشغل ، لذا يجب عليك بالتأكيد الترقية إلى أحدث إصدار.

حالات FWIW مثل https://github.com/zeit/next.js/issues/7929#issuecomment -618297553 هي حلقات لا نهائية تم إنشاؤها داخل تطبيقك ولا يمكننا اكتشافها جيدًا (حيث ينتهي بها الأمر من خلال عرض React ).

بقدر ما فهمت ، Next.js (منذ الإصدار 9.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٪ هي نفسها منخفضة جدًا.

هل هذه الميزة قابلة للاشتراك / إلغاء الاشتراك؟ لقد قمت بإزالة إنشاء خرائط المصدر (تم ذلك عبر البرنامج المساعد) بعد أن فتحت المشكلة (منذ وقت طويل) لكنها لم تساعد كثيرًا.

يتم تمكين خرائط المصادر دائمًا في التطوير ، ولكننا انتقلنا إلى تقييم خرائط المصدر.

لهذا السبب تم إعادة فتح المشكلة وهذا هو السبب في عدم وجود التسمية التي تقول إنها تتطلب مستودعًا لإعادة إنتاج المشكلة.

أعدت فتحه نظرًا لاستمرار ورود المزيد من التقارير وواصلت طلب النسخ: https://github.com/zeit/next.js/issues/7929#issuecomment -568760542

هناك نسختان فقط متوفرة في هذا الموضوع. أحدهما غير مرتبط تمامًا بـ 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" ، فإنه يبني ذاكرة حتى أتلقى هذا الخطأ وإعادة تشغيل العملية مما يعني أنه يفقد جميع المسارات والأشياء المخزنة مؤقتًا ، لذا فهو بطيء حقًا بالنسبة للمستخدم الأول الذي يدخل الصفحات بعد ذلك كل 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]

هذه هي مجموعتي. 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 (منذ الإصدار 4.1.0) مثل:

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

واجهت المشكلة الموضحة هنا لأول مرة عندما أصبح somepackage "كبيرًا جدًا" (من 500 كيلو بايت إلى 700 كيلو بايت) ، والآن فجأة ، لم تكن كل ذاكرتي (التي جربت أيضًا مع خيار 8 جيجابايت) كافية للتعامل مع هذا .

أعتقد أن هناك بعض الحلقات التي يسببها الارتباط الرمزي والتي تتسبب في تضخم الذاكرة بشكل كبير.