4

--trace_gcフラグを指定してアプリを実行し、パフォーマンスの問題を見つけようとしました。まあ、私はそれを見つけたかもしれないように見えます...

 1288678 ms: Mark-sweep 498.8 (549.0) -> 488.8 (548.0) MB, 4085 ms [idle notification: finalize idle round] [GC in old space requested].

Gadzooks！GCを実行するのに4秒以上。私が問題を抱えているのも不思議ではありません。

さて、本当の質問：どのオブジェクトがGCされているか、そしてさらに重要なことに、それらがどこに割り当てられているかをどのように見つけることができますか？ノードタイムですでにヒープスナップショットを使用しましたが、これらのオブジェクトがどこから来ているのかを見つけるのに役立つ十分な情報が表示されていません。おそらく、どこかに循環参照があると信じさせるヒントがいくつかあります（たとえば、1人のユーザーがAPIを数回呼び出しただけで、ヒープスナップショットに数百の「ユーザー」プロパティが表示されます）。

これらの大量のガベージコレクション時間の原因を追跡する方法について、優れたチュートリアルやその他の優れた情報はありますか？または、循環参照を見つけるために、割り当てられたオブジェクトを何らかの方法で印刷することもできます...？

4

1 に答える 1

3

このためのツールは実際にはありませんが、循環参照は問題ではないことを保証できます。

使用しているV8のバージョンはどれかしら。

長い一時停止を引き起こす可能性のあるものの1つは、非常に大きなオブジェクトです。V8は、数百万の要素配列または数十万のオブジェクトを含むオブジェクトのスキャンを段階的に増やすことはまだあまり得意ではありません。

ノード内または--nouse-idle-notificationを使用してアイドル通知をオフにすることをお勧めします。通知が常に適切なタイミングで発生するかどうかはわかりません。彼らはV8に、VMには何の関係もないことを伝えることができ、今は非インクリメンタルなストップザワールドGCを実行する良い機会になるでしょう。

于 2012-10-15T11:55:23.343 に答える