62

ええと...私は振り出しに戻りました。私は私の人生のためにこれを理解することはできません。

次のエラーが表示されます。

FATAL ERROR: JS Allocation failed - process out of memory

この問題の根源を突き止めようと試みたものを数十 (はい、数十) 列挙することはできますが、実際には多すぎるでしょう。重要なポイントは次のとおりです。

  • 実稼働サーバーでのみ発生させることができ、アプリは大きくて複雑であるため、分離するのが非常に難しいことがわかっています
  • ヒープ サイズと RSS サイズが両方とも 200 Mb 未満であっても発生しますが、マシン (Amazon Cloud、CentOS、m1.large) の RAM が 8Gb であることを考えると問題にはなりません。

私の推測では、 (2 番目の点のため) リークはおそらく原因ではありません。むしろ、おそらく非常に大きな SINGLE オブジェクトがあるようです。次のスレッドは、この理論を裏付けています:: Node.js で JSON.stringify を使用すると、'process out of memory' エラーが発生します。

私が本当に必要としているのは、アプリケーションがクラッシュした瞬間のメモリの状態を調べる方法、または致命的なエラーに至るまでのスタック トレースです。

上記の仮定に基づくと、10 分間経過したヒープ ダンプでは不十分です (オブジェクトがメモリに常駐していないため)。

4

15 に答える 15

49

これが現時点でGoogleのトップアンサーであるという理由だけで、私はちょうど遭遇したケースの解決策を追加すると思いました：

ejsテンプレートでexpressを使用してこの問題が発生しました-問題は、ejsブロックを閉じることができず、ファイルがjsコードであるということでした-次のようなものです：

var url = '<%=getUrl("/some/url")'
/* lots more javascript that ejs tries to parse in memory apparently */

これは明らかに非常に特殊なケースであり、OPのソリューションをほとんどの時間使用する必要があります。ただし、OPのソリューションはこれには機能しません（ejsスタックトレースはによって表示されませんofe）。

于 2013-01-30T05:39:56.090 に答える
21

このエラーが発生したときにヒープ ダンプを自動的に生成するようにnode.js 自体を変更するために、Trevor Norris に多大な支援を与える必要があります。

しかし、最終的に私にとってこの問題を解決したのは、はるかにありふれたものでした。各着信 API 要求のエンドポイントをログ ファイルに追加する簡単なコードをいくつか書きました。約 10 個のデータ ポイント (クラッシュ) を収集するのを待ち、クラッシュの 60 秒前に実行されたエンドポイントを比較しました。9/10 のケースでは、クラッシュの直前に 1 つのエンドポイントがヒットしていたことがわかりました。

そこからは、コードをさらに深く掘り下げるだけでした。mongoDB クエリから返されるデータを減らし、オブジェクトから必要なデータのみをコールバックに渡すなど、すべてを削減しました。現在、どのサーバーでも 1 回もクラッシュすることなく、平均よりも 6 倍長くなりました。それが解決されることを願っています...今のところ。

于 2012-12-03T18:26:47.360 に答える
12

この問題に対する唯一の解決策はありません。
私はさまざまなケースを読みましたが、そのほとんどは JS に関連していましたが、たとえば、私の場合は、コードのバグが原因で無限に続く壊れた jade テンプレート ループでした。

ノードがうまく管理できない構文エラーだと思います。
コードを確認するか、投稿して問題を見つけてください。

于 2014-06-05T08:15:33.853 に答える
7

私の場合、cap production deploy (capistrano) を介して Rails 4.2.1 をデプロイし、アセットのプリコンパイル中に以下を受け取りました。

rake stdout: rake が中止されました! ExecJS::RuntimeError: FATAL ERROR: Evacuation Allocation failed - プロセスのメモリ不足 (execjs):1

以前にactive_adminを介して多数のデータインポートを実行しましたが、すべてのRAMを使い果たしたようです

解決策: サーバーの再起動とデプロイが初めて実行されました....

于 2015-07-14T09:09:52.707 に答える
4

シリアル化するオブジェクトの再帰の問題である可能性があります。これは、そもそも大きく、再帰が問題になる前にメモリが不足しているためです。

このため、 safe-clone- deepnpmモジュールを作成しました...基本的には次のようにします。

var clone = require('safe-clone-deep');
...
   return JSON.stringify(clone(originalObject));

これにより、安全にシリアル化されるほとんどすべてのオブジェクトのクローンを作成できます。また、オブジェクトの1つが継承する場合、Error継承されたプロパティとプロパティはシリアル化されます。これらは通常、シリアル化されないためです。namemessagestack

于 2012-11-29T19:15:25.707 に答える
1

多くのケースを分析すると、最も一般的な問題は無限ループの問題です。これは、複雑なアプリで解決するのが難しいため、テスト駆動開発が便利です!!

于 2015-09-07T03:00:19.060 に答える
1

私たちの場合、util.format を爆破させる巨大な (まばらな) 配列を誤って割り当ててしまいました。

http://grahamrhay.wordpress.com/2014/02/24/fatal-error-js-allocation-failed-process-out-of-memory/

于 2014-02-25T19:59:52.653 に答える
1

私の場合、[] を使用して連想配列 (オブジェクト) を初期化しました。{} として初期化するとすぐに、問題はなくなりました。

于 2015-02-12T11:11:12.423 に答える
0

ここで何が起こるかを共有する:

この問題で数日を失いましたが、あるファイルで 1 つの静的ファイル (ビルド済みファイル) からクラスをインポートしていることがわかりました。ビルドプロセスが決して終わらないようにします。何かのようなもの：

import PropTypes from "../static/build/prop-types";

実際のソースに修正することで、すべての問題が解決しました。

于 2016-09-19T11:03:48.803 に答える
0

ノードのバージョンに問題がある可能性があります。反応アプリケーションの実行中に同じ問題が頻繁に発生しました。ノード バージョン 14.7.2 でこの問題に直面していました。ヒープ メモリの増加、キャッシュのクリア、ノード モジュールの再インストールなど、多くの解決策を試しました。どれも問題を解決しませんでした。最後に、ノードのバージョンを 10.24.1 にダウングレードすると、エラー メッセージが表示されなくなりました。

于 2021-07-02T09:57:02.873 に答える