【体験談まとめ】Nodeのメモリリークのトラブルシューティング方法は？アイデアを共有する-jsチュートリアル-php.cn

ノードのメモリリークをトラブルシューティングするにはどうすればよいですか?次の記事は、ノードのメモリリークのトラブルシューティング体験をまとめたもので、皆様のお役に立てれば幸いです。

【体験談まとめ】Nodeのメモリリークのトラブルシューティング方法は？アイデアを共有する

Nodejs サーバーサイド開発のシナリオでは、メモリリーク が間違いなく最も厄介な問題です。しかし、プロジェクトが開発され反復され続ける限り、メモリリークの問題は絶対に避けられず、遅かれ早かれ発生するだけです。したがって、効果的な メモリリーク トラブルシューティング方法を体系的に習得することは、Nodejs エンジニアの最も基本的かつ中心的な能力です。

メモリリークに対処する際の難しさは、無数の関数や関数の中から、どの行のどの関数や関数がメモリリークの原因となっているのかを正確に特定する方法です。残念ながら、現時点ではメモリリークを簡単に特定できるツールは市場に存在しないため、この問題に初めて遭遇した多くのエンジニアは混乱し、対処方法がわからなくなるでしょう。ここでは、22 年間に Memory Leak を調査した事例に基づいて、私の対処方法を共有します。

問題の説明

2022 Q4 ある日、研究開発ユーザーグループから、当社の研究開発プラットフォームにアクセスできないことが報告され、多数のユーザーがバックグラウンドで例外が発生しました。タスクは完了していません。最初の反応は、メモリリークの可能性があるということです。幸いなことに、サービスはモニタリング (prometheus grafana) に接続されています。grafana モニタリングパネルでは、 10.00 以降、メモリが制御不能になっていることが判明しました。明らかなデータ漏洩が発生しました。 [関連チュートリアルの推奨事項: nodejs ビデオチュートリアル ]

DX 内存泄漏监控图.png

##手順 :

プロセスメモリ: rss (常駐セットサイズ)、プロセスの常駐メモリサイズ。

heapTotal: V8 ヒープの合計サイズ。

heapused: 使用される V8 ヒープのサイズ。

external: V8 オフヒープメモリの使用量。

Nodejs のグローバルメソッド process.memoryUsage() を呼び出して、heapTotal と # を含むこれらのデータを取得できます。 ##heapused は V8 ヒープの使用量であり、Node.js 内の JavaScript オブジェクトが保存される場所です。また、external は、C オブジェクトなど、非 V8 ヒープに割り当てられたメモリを表します。 rss は、プロセスの合計メモリ使用量です。一般に、監視データを確認するときは、heapused インジケーターに注目してください。

メモリリークの種類

メモリリークは主に 2 つに分類されます。 into:

グローバルリーク

ローカルリーク

実際には、グローバルメモリリークであろうとローカルメモリリークであろうと、すべてやるべきことは、除外範囲をできる限り狭めることです。

グローバルメモリリーク

グローバルコンテンツリークは通常、

ミドルウェア

および コンポーネント で発生します。このタイプのメモリリークもトラブルシューティングが最も簡単です。残念ながら、

2022 Q4

で発生したメモリリークはこのタイプに属さないため、ローカルリークの考え方に従って分析する必要があります。

二分法によるトラブルシューティング

このタイプの他の科学的分析方法については説明しませんが、この場合、二分法を使用するのが最も早いと思います。

プロセスフロー

ミドルウェア
, コンポーネント、または他の一般的なロジックの使用)

の詳細な場所。2020 年に

Nuxt## ベースの SSR アプリケーションを開発していたときのことです。 # では、オンラインにする前のストレステストでアプリケーションメモリリークが見つかり、グローバルであることが判明しました。予期せぬリークの後、二分法を使用して問題を特定するのに約 30 分かかりました。
当時のリークの原因は、サーバー側で axios を使用していたためでしたが、その後、
axios を統合し、関連するものをすべて node- に置き換えました。 fetch で解決しました。それ以来、axios PDST に切り替えました。axios を Node サービスで使用することはありません。
永続的なメモリリークの部分的なトラブルシューティング

ほとんどのメモリリークはローカルリークです。リークポイントは、特定のミドルウェア

または特定の # に存在する可能性があります。 ##interface

. 特定の 非同期タスク では、このような特性により、トラブルシューティングも困難になります。この場合、分析のために heapdump が実行されます。 <p>ここでは主にこの場合の私のアイデアについて話します。<code>heapdump の詳細な説明は次の段落

Heap Dump に記載します。 : ヒープダンプ。以下の部分はすべて heapdump で表されます。heapdump を実行するためのツールやチュートリアルは数多くあります (chrome、vscode、heapdump オープンソースライブラリなど)。私が使用するヒープダンプライブラリに関するオンラインチュートリアルは多数ありますが、ここでは説明しません。

ローカルメモリリークのトラブルシューティングには、ある程度のメモリリークのトラブルシューティングの経験が必要です。問題が発生するたびに、自分自身のテストとして扱ってください。経験を積んでから、メモリのトラブルシューティングを行うことができます。漏れの問題は後で発生しますが、それはますます速くなります。

1. メモリリークが発生する時間範囲を特定する

これは非常に重要であり、これを知っておくと、調査の範囲が大幅に狭まる可能性があります。
この状況はよく発生します。この反復には 3 つの関数 A、B、C があり、ストレステスト中またはオンラインになった後にメモリリークが発生します。その後、直接ロックできるようになり、これら 3 つの新しい関数の間で小さなメモリリークが発生します。この場合、heapdump を実行するために運用環境に移動する必要はありません。いくつかのツールを使用してローカルでメモリリークポイントを簡単に分析し、特定することができます。

2020 年の Q4 における特殊な状況により、メモリリークが見つかったとき、メモリリークが最初に発生した時期を特定することが困難でした。大まかに 1 でロックすることしかできません。数か月以内に。今月もメジャーバージョンアップを行っているのですが、これらの機能やインターフェースを一つ一つチェックしていくと、かなりのコストがかかってしまいます。したがって、さらに分析するには、より多くのデータを組み合わせる必要があります

2. ヒープダンプデータを収集します

運用開始時ノード追加--expose-gc、このパラメータは gc() メソッドをグローバルに挿入して、GC の手動トリガーを容易にし、より正確な ヒープスナップショットdata
- #印刷ヒープスナップショット
#プロジェクト開始後の初めてのスナップショットデータの印刷
- メモリがクリティカルに近づいています GC を再度トリガーして、ヒープスナップショットを出力します

ノードサービスは

heapdump
中に中断されます。この時間は、その時点のサーバーメモリのサイズに応じて約 2 ～ 30 分になります。。運用環境で
heapdump を実行するには、運用および保守と協力して合理的な戦略を策定する必要があります。ここでは、2 つのプライマリ pod とセカンダリ pod を使用します。プライマリ pod が停止すると、ビジネスリクエストは、本番稼働を確保するためにセカンダリ pod にロードバランシングされます。ビジネスの。 (このプロセスは運用保守と緊密に連携したプロセスである必要があります。結局のところ、heapdump もそれらを通じてサーバー内の heap snapshot ファイルを取得する必要があります)
クリティカルポイントでスナップショットを印刷するというのは、漠然とした説明ですが、試したことがある方ならわかると思いますが、メモリスナップショットを印刷する前にクリティカルポイントのすぐ近くで待機すると、印刷されません。したがって、この程度に近づくには自分をコントロールする必要があります。
少なくとも 3 回実行してください
heapdump(実際には、最も詳細なデータを取得するために 5 回実行しました)

3 . 分析のために監視パネルからのデータを結合します

監視にアクセスするにはアプリケーションサービスが必要です。ここでのアプリケーションは監視に

prometheus grafana を使用します。主にサービスの次の指標を監視します

(1 秒あたりのリクエスト訪問数)、リクエストのステータス、およびそのアクセスパス
(インターフェイスの平均応答時間) とそのアクセスデータ
バージョン
(ハンドル)# #イベントループラグ
サービスプロセスの再起動数
メモリ使用量:
rss
heapTotal、heapused、external、heapAvailableDetail

heapdump

データのみが含まれません。十分です、
heapdump データは非常に曖昧であり、視覚化ツールのサポートがあっても、問題を正確に特定することは困難です。今回はgrafanaのデータをいくつか組み合わせて見てみました。
私の解析・処理結果

当時のスナップショットデータが紛失してしまったので、ここでシーンをシミュレーションしてみます。

grafana

モニタリングインターフェイスを通じて、メモリが増加していて減少していないことがわかりますが、同時に

の数が減少していることにも気づきました。サービス内のハンドル も急増していますが、落ちることはありません。

2. これは、リークが発生した月の新機能を確認し、メモリリークは bull メッセージキューコンポーネントの使用によって引き起こされているのではないかと疑ったときのことです。まず、関連するアプリケーションコードを分析しましたが、メモリリークを引き起こすような問題があるとはわかりませんでした。 1.のハンドルリークの問題と合わせると、bullを使用した後に特定のリソースを手動で解放する必要があるようですが、現時点では具体的な理由はわかりません。

3. 次に、5 回分の heapdunmp データを分析し、そのデータを chrome にインポートしました。5 回分のヒープスナップショットを比較した結果、次のことがわかりました。各キューの作成後、 TCP 、 Socket 、 EventEmitter イベントは解放されません。現時点では、bull の不規則な使用が原因であることはほぼ確実です。 bull では、通常、キューは頻繁に作成されず、キューによって占有されているシステムリソースは自動的に解放されないため、必要に応じて手動で解放する必要があります。

【体験談まとめ】Nodeのメモリリークのトラブルシューティング方法は？アイデアを共有する

#4. コードを調整した後、再度ストレステストを実行したところ、問題は解決しました。

ヒント: Nodejs の handle は、基礎となるシステムリソース (ファイル、ネットワーク接続など) を指すポインターです。ハンドルを使用すると、Node.js プログラムは、基盤となるシステムと直接対話することなく、これらのリソースにアクセスして操作できるようになります。ハンドルは、Node.js ライブラリまたはモジュールで使用されるハンドルの種類に応じて、整数またはオブジェクトになります。 CommonHandle:

#fs.open() 返されるファイルハンドル

net.createServer() 返されるネットワークサーバーハンドル

dgram.createSocket() 返された UDP ソケットハンドル

child_process.spawn() 返された子プロセスハンドル
#crypto.createHash()
返されたハッシュハンドル
zlib.createGzip()
返された圧縮ハンドル

#ヒープダンプ分析の概要

通常、ヒープスナップショット

データを初めて取得するときは、多くの人が混乱します。私も同様です。インターネット上で無数の分析テクニックを読み、それを私自身の実際の実践と組み合わせた後、さらに役立つテクニックをいくつかまとめました。一部の基本的な使用方法のチュートリアルについては、ここでは説明しません。ここでは、

chrome; 概要ビュー

データをインポートした後の画像の見方について主に説明します。このビューでは、通常、まず [保持サイズ] を選択し、次にオブジェクトのサイズと数を観察します。経験豊富なエンジニアは、特定のオブジェクトの数が異常であることをすぐに判断できます。このビューでは、自分で定義したいくつかのオブジェクトを考慮することに加えて、

【体験談まとめ】Nodeのメモリリークのトラブルシューティング方法は？アイデアを共有する

TCP

##ソケット
など、メモリリークが発生しやすい一部のオブジェクトにも注意が必要です。 EventEmitter
グローバル
比較ビュー

合格した場合概要ビュー, 問題が特定できない場合は、通常、

Comparison

ビューを使用します。このビューを通じて、2 つのヒープスナップショット内のオブジェクトの数と、オブジェクトが占有するメモリの変化を比較できます。この情報を通じて、ヒープ内のオブジェクトの値を判断し、一定の操作 (特定の操作) 後のメモリの変化を判断することができ、これらの値を通じて異常なオブジェクトを見つけることができます。これらのオブジェクトの名前属性または関数によって、メモリリーク調査の範囲が狭まる可能性があります。 [比較] ビューで 2 つのヒープスナップショットを選択し、それらを比較します。 2 つのヒープスナップショット間でどのオブジェクトが追加されたか、2 つのヒープスナップショット間でどのオブジェクトが削減されたか、どのオブジェクトのサイズが変更されたかを確認できます。

比較

ビューでは、オブジェクト間の関係だけでなく、タイプ、サイズ、参照カウントなどのオブジェクトの詳細も表示できます。この情報により、どのオブジェクトがメモリリークの原因となっているかを理解できます。

#包含ビュー

【体験談まとめ】Nodeのメモリリークのトラブルシューティング方法は？アイデアを共有する

オブジェクト間の到達可能なすべての参照関係を表示します。各オブジェクトは点として表され、その親オブジェクトに線で接続されます。こうすることで、オブジェクト間の階層関係を確認し、どのオブジェクトがメモリリークの原因となっているかを把握できます。

#統計ビュー

【体験談まとめ】Nodeのメモリリークのトラブルシューティング方法は？アイデアを共有するこの図は非常に単純なので、詳細については説明しません

メモリリークのシナリオ

グローバル変数: グローバル変数はリサイクルされません
キャッシュ: 次のようなメモリ集約型のサードパーティライブラリが使用されますlru-cache 保存しすぎるとメモリ不足になります。Nodejs サービスでは lru-cache の代わりに
を使用することをお勧めします。ハンドルリーク: システムリソースは呼び出し後に解放されません
イベントモニタリング
終了
循環参照

概要

問題の種類を初めて特定しやすくするために、サービスにはアクセス監視が必要です
メモリリークがグローバルかローカルかを判断します
二分法を使用して、グローバルメモリリークのトラブルシューティングを迅速に行い、特定します。
ローカルメモリリーク
- メモリリークが発生し、問題を迅速に特定します。機能
- ヒープスナップショットデータを少なくとも 3 回収集します。
- 監視データ、ヒープスナップショットデータ、リーク発生時の新しい関数を組み合わせて、問題を特定します。メモリリークポイント

メモリリークの問題が発生しても恐れることはありません。メモリリークの問題のトラブルシューティングでより多くの経験を積んでください。処理の経験が増えるほど、メモリリークの問題は、すぐに見つけやすくなります。各解決策の後で、レビューと要約を実行し、もう一度振り返りますヒープスナップショットデータは、関連するエクスペリエンスをより速く蓄積するのに役立ちます