Node.jsでのメモリリークのハンティング（12のMozilla Identity Team Node.js記事の1つ）

翻訳者から：これは、 ペルソナプロジェクトに関与するMozilla IdentityチームによるNode.jsシリーズの最初の記事です。 ペルソナのクライアント側とサーバー側の両方がJavaScriptで記述されています。 作業の過程で、プロジェクトチームは、ローカライズからデバッグ、依存関係管理など、あらゆる場面でいくつかのツールを作成しました。 この一連の記事では、Mozilla開発者がコミュニティやNode.jsで負荷の高いサービスを作成する人にとって役立つこれらのツールと経験を共有しています。

シリーズの最初の記事は、Node.jsの一般的な問題-メモリリーク、高負荷プロジェクトのリーク機能、およびNodeでそのようなリークを見つけて修正するのに役立つnode-memwatchライブラリに焦点を当てています。

---

なぜわざわざ？

なぜメモリリークを監視するのでしょうか？ もっと重要なことはありますか？ プロセスを時々再起動したり、サーバーにメモリを追加したりしないのはなぜですか？ 漏れをなくすことが依然として重要である理由は3つあります。

1. メモリリークについてあまり心配することはないかもしれませんが、V8（Nodeが実行されるJavaScriptエンジン）については言えません。 使用するメモリが多いほど、ガベージコレクターの動作が活発になり、アプリケーションの速度が低下します。 そのため、ノードでは、リークはパフォーマンスに直接影響します。
2. リークは他の問題につながる可能性があります。 コードが漏れると、限られたリソースがブロックされる可能性があります。 ファイル記述子が不足するか、データベースへの別の接続を開くことができない場合があります。 このような問題は、メモリが不足するずっと前に発生する可能性がありますが、アプリケーションがクラッシュすることはありません。
3. 遅かれ早かれ、アプリケーションはクラッシュします。 そして、これは訪問者の流入中に発生する可能性があります。 誰もがあなたを笑い、ハッカーニュースであなたについての嫌なことを書きます。

落下する音はどこから来るのですか？

複雑なアプリケーションには、リークが発生する可能性のある場所がたくさんあります。 おそらく最も有名で痛い場所-閉鎖。 クロージャは、スコープからの変数参照を長期間保存できるため、最も頻繁にリークするポイントになります。

一部のリークは、コードでそれらを探すだけで遅かれ早かれ検出できますが、Nodeの非同期の世界では、コールバックの形で多くのクロージャーを常に作成します。 そして、作成よりもゆっくりと動作する場合、各コールバックのメモリフラグメントが積み上げられるため、現在はまったく見えないコードが現在のものと同じように動作します。 そのような漏れを追跡することははるかに困難です。

アプリケーションは、依存している他の誰かのコードのエラーが原因でリークすることもあります。 プログラム内でリークの原因となる場所を見つけることができる場合もありますが、完全にデバッグされたコードを見て、困惑して、どのようにリークするのか疑問に思っているだけです。

node-memwatchの必要性を生み出したのは、追跡が困難なこれらのリークです。 伝説によれば、数か月前、私たちのプログラマーのロイド・ヒラエルは2日間クローゼットに身を固め、非常に重い負荷のもとでのみ発生したリークを追跡しようとしました（ところで、彼はこのシリーズの次の記事の著者であり、単に負荷テストに専念しています）

2日間の検索の後、彼は目的のエラーがNodeカーネルにあることを発見しました： http.ClientRequestイベントハンドラーはメモリを適切に解放しませんでした（このエラーを修正するためのパッチはNode.jsコードに2つだけの非常に重要な文字を追加しました）。 拷問は、ロイドにそのような漏洩を捜すのに役立つツールを書くことを余儀なくされました。

リーク検出ツール

Node.jsアプリケーションでリークを検出するためのツールの選択肢は、すでに増え続けています。 それらのいくつかを次に示します。

• node-mtrace JimbEsser。GCCmtraceユーティリティを使用してヒープ使用量をプロファイルします。
• Dave Pachecoのnode-heap-dump。V8ヒープのスナップショットを取得し、それを巨大なJSONファイルに書き込みます。 JavaScriptを使用してこのスナップショットを調査および解析するためのツールが含まれています。
• V8プロファイラーとWebKit Webインスペクターデバッガーに基づいたDanny Coatesのv8プロファイラーとノードインスペクター。
• Felix GeisendorferのNode メモリリークガイド 。v8プロファイラーとノードインスペクターを使用する基本について簡潔かつ明確に説明しています。
• Joyent SmartOSプラットフォーム。Node.jsのリークをトラブルシューティングするための豊富なツールを提供します。

私たちはこれらのツールや他の多くのツールが好きですが、どれも私たちの環境に理想的なものではありませんでした。 Web Inspectorは開発中のアプリケーションには最適ですが、特に多くのサーバーとプロセスが使用されている場合、戦闘中の実行中のアプリケーションでの使用は困難です。 したがって、その助けを借りて、すぐに表示されず、高負荷の状態でのみ発生するエラーをキャッチすることは困難です。 dtraceやlibumemなどのツールも優れていますが、すべてのオペレーティングシステムで動作するわけではありません。

会う：node-memwatch

追加ツールを必要としないクロスプラットフォームデバッグライブラリが必要でした。このライブラリを使用して、メモリリークの場所と原因を見つけることができました。 そして、 node-memwatchを書きました 。

次の3つのことを提供します。

• リークイベント
  

   memwatch.on('leak', function(info) { //   info,  ,    }); 

  
  
• イベント'stats'
  

   var memwatch = require('memwatch'); memwatch.on('stats', function(stats) { //        }); 

  
  
• クラス追跡ヒープの差分：
  

   var hd = new memwatch.HeapDiff(); //   ... var diff = hd.end(); 

  
  

さらに、ガベージコレクターを強制的に呼び出す機能があります。これはテストに役立つ場合があります。 つまり、結局のところ、3つではなく4つのことです。

 var stats = memwatch.gc(); 

memwatch.on（ 'stats'、...）：ガベージコレクション後のヒープ統計

node-memwatchは、ガベージコレクターの動作が終了した直後、メモリが新しいオブジェクトに割り当てられる前に、ヒープ使用量の統計を表示できます。 これを行うには、 V8::AddGCEpilogueCallback使用します。

統計には次のフィールドが含まれます。

• usage_trend
• current_base
• 推定ベース
• num_full_gc
• num_inc_gc
• heap_compactions
• 分
• 最大

これは、リークしているアプリケーションのメモリ使用統計がどのように見えるかを示す例です。 ジグザグの緑色の線は、 process.memoryUsage()によるメモリ使用量を示し、赤色の線は、ノードmemwatch統計からのcurrent_base値を示します。 左下は追加データです。



増分ガベージコレクションが発生する頻度に注意してください。 これは、V8が記憶を消去しながら汗をかかなければならないことを示す警告サインです。

memwatch.on（ 'leak'、...）：メモリ使用量のダイナミクス

単純なヒューリスティックを使用して、潜在的なリークを警告します。 5回連続してガベージコレクションを行った後、メモリ使用量が増加すると、「リーク」イベントがトリガーされます。 リークの可能性に関する情報は、読みやすい便利な形式で表示されます。

 { start: Fri, 29 Jun 2012 14:12:13 GMT, end: Fri, 29 Jun 2012 14:12:33 GMT, growth: 67984, reason: 'heap growth over 5 consecutive GCs (20s) - 11.67 mb/hr' } 

memwatch.HeapDiff（）：リークを見つける

最後に、node-memwatchは、メモリを占有するオブジェクトの数の名前を含むヒープスナップショットを比較できます。 Diffは侵入者を見つけるのに役立ちます。

 var hd = new memwatch.HeapDiff(); //   ... var diff = hd.end(); 

diffオブジェクトの内容は次のようになります。

 { "before": { "nodes": 11625, "size_bytes": 1869904, "size": "1.78 mb" }, "after": { "nodes": 21435, "size_bytes": 2119136, "size": "2.02 mb" }, "change": { "size_bytes": 249232, "size": "243.39 kb", "freed_nodes": 197, "allocated_nodes": 10007, "details": [ { "what": "Array", "size_bytes": 66688, "size": "65.13 kb", "+": 4, "-": 78 }, { "what": "Code", "size_bytes": -55296, "size": "-54 kb", "+": 1, "-": 57 }, { "what": "LeakingClass", "size_bytes": 239952, "size": "234.33 kb", "+": 9998, "-": 0 }, { "what": "String", "size_bytes": -2120, "size": "-2.07 kb", "+": 3, "-": 62 } ] } } 

HeapDiffは、統計情報を収集する前にガベージコレクターを呼び出して、データに不要なナンセンスが多く含まれないようにします。 'stats'イベントは発生しないため、 'stats'ハンドラー内でHeapDiffを安全に呼び出すことができます。

以下は、ヒープ上の最もスペースを占有するオブジェクトのリストを追加した統計の例です。

次は？

node-memwatchの機能：

• メモリ使用量の正確な追跡。
• 漏れの可能性の通知。
• 差分ヒープを取得するためのツール。
• クロスプラットフォーム;
• 他のツールへの依存関係の欠如。

もっと欲しい。 特に、node-memwatchが流れるオブジェクトの特定のデータ（変数の名前、配列インデックス、クロージャーコードの断片）を提供できるようにしたいと考えています。

リークしているNode.jsアプリケーションをデバッグするときにnode-memwatchが役に立つことを願っています。それをフォークして、改善に参加してください。

---