ホームページ > 記事 > ウェブフロントエンド > なぜパフォーマンス監視が必要なのでしょうか? Node.js のパフォーマンス監視について話しましょう
なぜパフォーマンス監視が必要なのでしょうか?この記事では、Node.js のパフォーマンス監視について説明します。お役に立てば幸いです。
ノードサーバー上の Javascript のランタイム (Runtime) として側面としては、JavaScript のアプリケーション シナリオが大幅に強化されます。
しかし、Node.js ランタイム自体はブラック ボックスであり、私たちは ランタイムの状態を 認識することができず、 オンラインの問題を再現することは 困難です。
したがって、パフォーマンス監視は、Node.js アプリケーションの「通常の操作」の基礎となります。さまざまな実行時インジケーターをいつでも監視できるだけでなく、異常なシナリオの問題のトラブルシューティングにも役立ちます。
パフォーマンス監視は 2 つの部分に分けることができます:
パフォーマンス指標の収集と表示
上の図から、現在主流の 3 つの Node.js パフォーマンス監視ソリューションの長所と短所がわかります。これら 3 つのソリューションの構成を簡単に紹介します。
commdx を統合する便利なツールです。
Memory
heap Used: v8 によって使用されたヒープ メモリ サイズ
arrayBuffers: ArrayBuffer に割り当てられたメモリ サイズ
上の図からわかるように、rss
にはコード セグメント (コード セグメント
)、スタック メモリ (Stack
)、およびヒープ メモリ (ヒープ
)
は、v8.getHeapStatistics()
および v8.getHeapSpaceStatistics(() を通じて v8 から取得できます。 )
ヒープ メモリとヒープ スペースの分析データ。次の図は、v8 のヒープ メモリ構成の分布を示しています。
ヒープ メモリ スペースは、まずスペースに分割されます。 、スペースはページに分割され、メモリは 1MB の位置合わせに従ってページングされます。
新しいスペース: 新しい世代のスペース。ライフサイクルが比較的短いオブジェクト データを保存するために使用され、2 つのスペースに分割されます (スペース タイプは セミ スペース
)。 from space
、to space
##Old Space: 古い世代のスペース、New Space
プロモートされたオブジェクトの格納に使用されます
Code Space: v8 JIT コンパイルされた実行可能コードの格納
マップ スペース: Object が指す隠しクラスのポインタ オブジェクトを格納します。隠しクラス ポインタは、実行時に v8 によって記録されるオブジェクト レイアウト構造であり、オブジェクト メンバーにすばやくアクセスするために使用されます
アルゴリズムを使用します。
アルゴリズム
New space は 2 つのオブジェクト スペースに分割されます:
from と
to
New space space Full# のとき
##ステップ:
は一度生存し (スカバンジを経験)、
オールド スペースに昇格しました。他のオブジェクトは
スペース ## にコピーされます。
はクリアされます。 ##from space
Scavenge
頻繁にリサイクルされ、メモリが少ないオブジェクトに適しています。これは典型的な時間対時間戦略です。欠点は、2 倍のスペースが無駄になることです。
マーク- スイープ - コンパクト
トリガー時間: 古いスペース
黒 :リサイクル不可能なオブジェクトを表し、それによって生成された参照はすべてスキャンされています。
pop その後、オブジェクト参照の下にあるすべての白いオブジェクトが灰色でマークされます##push
マーキング キュー
に移動し、スタック上のすべてのオブジェクトがポップされるまで
PS: オブジェクトが大きすぎてスペースが限られているスタックにプッシュできない場合、v8 はオブジェクトを灰色のままにしてスキップし、スタック全体を次のようにマークします。スタックがクリアされた後、再度プッシュされ、マークをトラバースします。これには、ヒープの追加スキャンが必要になります。 #白いオブジェクトを消去すると、メモリ容量が不足します。 Continuous
Old オブジェクトの一端に移動します。スペース
、空にできるようにします スペースは連続した完全なスペースです 増分マーキング: マーキング フェーズでは、ヒープが特定のサイズに達すると、増分 GC が開始され、一定量のメモリが割り当てられた後、各割り当てが開始されます。メモリが確保され、プログラムが一時停止され、マーキングが数ミリ秒から数十ミリ秒行われてから、プログラムが再開されます。
スペース調整
デフォルトの制限: 64 ビット システムは 1400M、32 ビット システムは 700M
node
には調整用の 2 つのパラメーターが用意されています。新世代と旧世代のスペースの上限
--max-semi-space-size の最大値を設定します
node
も提供されています。 GC ログを表示する 3 つの方法: --trace_gc_verbose
: 各 GC 後の各 V8 ヒープ スペースの詳細なステータスを表示します
実行中のプログラムの ヒープ メモリ
のスナップショット サンプリングを実行します。メモリ消費と変更の分析に使用できます。
# を使用します。
##使用
分析方法
ファイルを Chrome devtools ツールバーのメモリにアップロードして選択すると、表示結果は次のようになります:
デフォルトのビューは、サマリー
ビューです。ここでは、一番右の 2 つの列、Shallow Size
と Retained Size
: v8 ヒープ メモリに割り当てられたオブジェクト自体のサイズを示します。
: すべてのオブジェクトの
Shallow Size# を示しますオブジェクト ##sum
が特に大きいことが判明した場合、オブジェクト内でメモリ リークが発生している可能性があり、さらに拡張して特定することができます。問題と
ビューは、2 つの異なる期間のヒープ スナップショットを比較および分析するために使用されます。Delta
列を使用して、オブジェクトをフィルターで除外できます。最大のメモリ変更
のスナップショット サンプリングを使用して、 CPU 時間の消費量と割合を分析します。
生成方法 ファイルを生成するには、いくつかの方法があります。
ファイルは、Chrome devtools ツールバーの Javascript Profiler
に表示できます (デフォルトのタブではなく、必要に応じて)ツールバーの右側にある [その他] で開きます)。アップロード ファイルを選択すると、結果が表示されます。以下に示すように:
デフォルトのビューは
ビュー。ここには、Self Time
と Total Time
と Self Time
の間の偏差が大きいことが判明した場合、この関数は時間がかかり、CPU を集中的に使用する計算になる可能性があります。さらにトラブルシューティングを実行することもできます
ファイルの 3 つのメソッド:
ファイルを使用すると、mdb、gdb、lldb、およびその他のツールを使用して、実際のプロセス クラッシュの原因を分析および診断できます
監視すると、ヒープ メモリが増加し続けていることがわかります。そのため、トラブルシューティングにはヒープ スナップショットが必要です。
##分析
#heapsnapshot によると、分析すると、常に比較的大きなメモリを維持する
オブジェクトが存在することがわかりますトラブルシューティング
unused メソッドは呼び出されませんが、
オブジェクトは theThing
から参照されているため、常に replaceThing
の実行コンテキストに存在し、解放されていません。これは、クロージャ # によって引き起こされるメモリ リークの典型的なケースです。
##概要
So in上記の状況では、オブジェクトがメモリ内で自動的にリサイクルされるかどうかを慎重に検討する必要があります。自動的にリサイクルされない場合は、オブジェクトを手動で null
に設定し、
nodejs チュートリアル を参照してください。
以上がなぜパフォーマンス監視が必要なのでしょうか? Node.js のパフォーマンス監視について話しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。