Sentry-javascript: ノード10.13.0で@sentry / nodeメモリリーク

@abraxxasこの問題の再現を手伝ってもらえますか？ このメモリリークをどの程度正確にトリガーしていますか？
私は運が悪かったのであなたの説明を試しました、それはただ統計イベントを生成します、決してそれを漏らしません。

@kamilogorekご回答ありがとうございます。 私がしたことは次のとおりでした。 この例https://github.com/sheerun/next.js/tree/with-sentry-fix/examples/with-sentryをチェックアウトし、server.jsにmemwatchを追加しました

if (!dev) {
  memwatch.on("leak", info => {
    console.log("memwatch::leak");
    console.error(info);
  });

  memwatch.on("stats", stats => {
    console.log("memwatch::stats");
    console.error(Util.inspect(stats, true, null));
  });
}

次に、ノード10.xを使用して例を実行し（8.xiではメモリの問題は観察されませんでした）、ガトリングテストスイートを使用して次のリソースを要求しました。

    "/",
    "/_next/static/r1zovjaZ1TujaA0hJEp91/pages/_app.js",
    "/_next/static/r1zovjaZ1TujaA0hJEp91/pages/_error.js",
    "/_next/static/r1zovjaZ1TujaA0hJEp91/pages/index.js",
    "/_next/static/runtime/main-1eaa6d1d0c8e7d048efd.js",
    "/_next/static/chunks/commons.b34d260fee0c4a698139.js",
    "/_next/static/runtime/webpack-42652fa8b82c329c0559.js"

（ハッシュが変更される可能性があることに注意してください）

しかし、このアプローチで同じ結果を非常に簡単に達成できるはずですhttps://www.simonholywell.com/post/2015/06/parallel-benchmark-many-urls-with-apachebench/

数千回のリクエストの後、メモリ使用量はほぼ1GBになり、アイドリング時でも減少することはありませんでした。 server.jsからrequestとerrorHandlerを削除するとすぐに、メモリリークが停止します。 したがって、それらの2に接続されているようです。リクエストが少なすぎるか、ノード8.xを使用した可能性がありますか？

@abraxxasが確認されました。 ノード10+各リソースの〜300reqがジョブを実行します。 さらに調査します。 ありがとう！

@kamilogorek興味深いですが、あなたがあなたの
再現すると、ハンドラーなしで約20MBに留まることがわかります
しかし、それらとともに急速に増加します。

ハンドラーなしのメモリリーク警告は、次の理由だけで発生すると思います
リクエストにより、一定のメモリ増加があります。

とのバージョン間でメモリ使用量にまだ大きな違いがあります
歩哨となし。

2018年11月29日木曜日、12：45KamilOgórek< [email protected]は次のように書いています。

@abraxxas https://github.com/abraxxas正常に再現しましたが、
ただし、サーバーはそれ自体でリクエストオブジェクトをリークしているようです。
セントリーハンドラーがなくても。

https://streamable.com/bad9j

ドメインと独自のスコープをアタッチするため、成長率は少し大きくなります
リクエストに反対しますが、GCによるリクエストと一緒に利用されます。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/getsentry/sentry-javascript/issues/1762#issuecomment-442804709 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AIbrNlgPjPd5Jra1aahR-Dthf7XvbCexks5uz8jjgaJpZM4YvOA2
。

@abraxxasは私の前のコメント（私が削除したもの）を無視します、それは完全に私たちの側にあります:)

これは、ノードのコア自体の問題のようです。 このコメントを参照してくださいhttps://github.com/getsentry/sentry-javascript/issues/1762#issuecomment-444126990

@kamilogorekこれを調べる機会は

https://github.com/getsentry/sentry-javascript/blob/c27e1e32d88cc03c8474fcb1e12d5c9a2055a150/packages/node/src/handlers.ts#L233

検査官はeventProcessorsリストに何千ものエントリを示しました

物事がどのように設計されているかについてのコンテキストはありませんが、リクエストのスコープが正しくなく、間違ったメタデータが提供されていることに気付きました（＃1773を参照）。そのため、すべてがグローバル状態で管理されており、リクエストは終了します

@ abraxxas @ tpbowdenノードのコア自体のドメインモジュールのリークに問題があります。 それを監視し続け、コアで修正される前に一時的な解決策を考え出すようにします。 関連する問題： https ：

@kamilogorekこれに対する回避策または一時的な修正について何かアイデアはありますか？ ノードの問題の進行は非常に遅いようです

現在、メモリが特定のしきい値に達したときにNode.jsプロセスを再起動するためにPM2を使用しています。 https://pm2.io/doc/en/runtime/features/memory-limit/#max -memory-threshold-auto-reload

ユニットテストにラボを使用する。 漏れはまだ存在しています。 リークはデバッグが難しい場合があることを私は知っています。 修正のためのETAはありますか？

1つのテストが完了しました
テスト期間：1832ミリ秒
次のリークが検出されました。

npm ERR！ コードELIFECYCLE
npm ERR！ errno 1
npm ERR！ [email protected]テスト： lab build/test
npm ERR！ 終了ステータス1
npm ERR！
npm ERR！ [email protected]テストスクリプトで失敗しました。
npm ERR！ これはおそらくnpmの問題ではありません。 上記の追加のログ出力がある可能性があります。

npm ERR！ この実行の完全なログは、次の場所にあります。
npm ERR！ /Users/sunknudsen/.npm/_logs/2019-02-13T14_41_28_595Z-debug.log

@sunknudsenこの問題は実際にはNodeJSで修正されています。https：//github.com/nodejs/node/issues/23862およびhttps://github.com/nodejs/node/pull/25993を参照して

@garthenwebパッケージの開発方法が原因で、これは@sentry/node影響しますか？ 私がhapiで開発している（そして他の多くの依存関係に依存している）プロジェクトの1つは、リークを生成しません（少なくとも、ラボでは検出されません）。

@sunknudsen多かれ少なかれ。 私が理解している限り、これは（非推奨の）ドメインパッケージとpromiseの組み合わせです。 https://github.com/getsentry/sentry-javascript/blob/master/packages/node/src/handlers.ts#L233を参照して

私の場合、歩哨ミドルウェアを（エクスプレス）サーバーから削除して修正しました。

これはノードでは問題ではありませんが、Sentryハンドラーを無効にすると問題が修正されるため、Sentryでは問題になります。

@MartijnHols現在、SDKのメモリフットプリントを大幅に削減するメジャーリリースに取り組んでいます。 冒険心があれば、 https：//github.com/getsentry/sentry-javascript/pull/1919を試してみて

@HazATおかげで、昨夜（グラフの23:10に）本番

@MartijnHols試していただきありがとうございます！

覚えておくべき2つのことは、ノード内のドメインのメモリリーク修正が、ノードに最近11.10着陸したことです。
また、 latestタグが誤って付けられたため、 5.0.0-beta1を非公開にする必要がありました。 5.0.0-rc.1が最新のnextバージョンになりました。
5.0.0-rc.1を試してみてください。イベントのキューに入れる方法を少し変更しました。これにより、負荷/メモリが大幅に改善されます。

ノード11.12に更新すると、メモリとCPUの使用量が安定したようです。 ハンドラーを無効にした場合と比較した場合、リソースの使用量に認識できる違いはないようです。おそらく少しだけ良いでしょう。 また、必要なすべての情報でエラーをうまくキャッチしているようです（コンソールの「ブレッドクラム」がもっとあるかもしれません。 5.0.0について他に何を確認できるかわかりません。 問題が発生した場合はお知らせしますが、おそらくそうではありません。

LGTM。 ありがとう！

これも試してみてください。 @HazAT 11.10の修正がアクティブなLTSリリース10.xすでにバックポートされているかどうか知っていますか？

@adriaanmeuris誰かが10.xにバックポートするかどうか尋ねたのを読みましたが、そうするかどうかはわかりません。
参照： https ：

エクスプレスミドルウェアでクライアントとスコープを手動で作成する問題を解決しました

関数をエクスポートするファイルservices/sentryを作成しました

import {
  NodeClient as SentryClient, Hub, Integrations, Scope,
} from '@sentry/node';
import config from 'config';

const sentryClient = new SentryClient({
  ...config.sentry,
  frameContextLines: 0,
  integrations: [new Integrations.RewriteFrames()],
});

export default () => {
  const scope = new Scope();
  const client = new Hub(sentryClient, scope);
  return Object.freeze({ client, scope });
};

ミドルウェアでは、歩哨クライアント/スコープを次のようにリクエストオブジェクトに保存します

app.use((req, res, next) => {
  req.sentry = getSentry();
  req.sentry.scope.setTag('requestId', req.requestId);
  req.sentry.scope.setExtra('More info', 'XXXXXX');
  next();
});
....
// and use the express error handler
app.use((err, req, res, next) => {
  const code = err.code || 500;
  res.status(code).json({
    code,
    error: err.message,
  });
  if (code >= 500) {
    req.sentry.client.captureException(err);
  }
  next();
});

これでメモリリークが修正されたようです

@coudsこの実装は本当に素晴らしいです、あなたが考慮しなければならないことが1つあります。

リクエストごとに新しいクライアントが取得され、グローバルエラー/自動ブレッドクラム（またはデフォルトの統合が行うその他の機能）は検出されません。

@HazATありがとう、私はそれを知っていますが、支払うべき小さな価格です。 その巨大なメモリリークを解決するために、しかしこの損失を最小限に抑えるために、私はいくつかのことをしました。

1. unCoughException / promiseイベントに依存しないように設定したすべての例外を処理しようとしています。
2. ブレッドクラムの場合、reqオブジェクトにアクセスできる限り、手動で追加します。
3. @sentry/webpack-plugin使用してソースマップを歩哨にアップロードします
4. 問題の特定に役立つすべてのリクエストにタグ/追加を追加します

もう1つ、トランザクションである追加するタグをもう1つ貼り付けるのを忘れました（デフォルトのハンドラーをシミュレートするため）

req.sentry.scope.setTag('transaction', `${req.method}|${req.route ? req.route.path : req.path}`);

これが誰かの助けになることを願っています。Sentryは本当に素晴らしいツールであり、スタックから削除されないようにできる限りのことをしました。

@HazAT @kamilogorek [email protected]と[email protected]まだメモリが大幅に増加しています-このnodejsパッチで修正されたと確信していますか？

@tpbowden再現を提供するか、少なくともコードがどのように見えるかを教えてください。
また、Sentryに関連する他のプラグインを使用していますか？

@HazAT再現しようとしましたが、多くのミドルウェアを備えたかなり複雑なサーバーが原因です（サーバー側のレンダリングReact）。 Sentryミドルウェアをインストールすると、メモリが大幅に増加します（高負荷の場合、最大10MB /秒増加する可能性があります）。 サーバーからSentry.Handlers.requestHandler()ミドルウェアを削除すると、メモリは約200MBで一定になります

プラグインは使用しておらず、 @sentry/nodeのみを使用しています。 これを再現するために私ができることは何か考えられますか？

@HazATサーバー上でwebpackを使用してSentryをバンドルすることに関連しているようです-アプリがWebpackによってビルドされている場合にのみ発生します。 @sentry/nodeをexternals追加すると、メモリの問題が修正されました。 なぜこれが起こるのか考えはありますか？

リークは、@ sentry / node5.1.0を使用してノード11.14.0で引き続き再現可能です。

私たちにとって、リークは@ sentry / nodeとi18next-express-middlewareの間の相互作用によって引き起こされます。 Expressアプリはhttps://github.com/i18next/react-i18next/blob/master/example/razzle-ssr/src/server.jsに似てい

.use(Sentry.Handlers.requestHandler()); .use(i18nextMiddleware.handle(i18n))上に置くと、メモリリークが発生します。 その下に歩哨を置いても、漏れはありません。

同じ問題があります。 node 10.15.3と11.14.0試してみました。 これは、問題を再現するための最小限のリポジトリですhttps://github.com/michalkvasnicak/sentry-memory-leak-reproduction。 yarn testまたはyarn test:watchを実行するだけで、ヒープの使用状況が報告されます。 常に増加します。

yarn test

yarn test:watch

@michalkvasnicak例を作成するために時間を

SDKに関して実際には何もテストしていません

const Sentry = require('@sentry/node');

it('works', () => {
  expect(true).toBe(true);
});

パッケージが必要ですが、それだけです。
jestでリークテストを実行した経験がないのでわかりませんが、パッケージを要求するだけで何がリークする可能性がありますか？
確かではありませんが、何かが足りないかもしれませんが、新しいパッケージをロードするとメモリが増えると思います。

リークする可能性のあるものに関しては、いくつかのグローバル変数を作成しますが、状態を追跡するためにそれらが必要です。

@HazATはい、それは奇妙ですが、テストをリークさせるのに十分です。 jestはリークが検出されて失敗します。 コードベースにも同じ問題があり、 @sentry/nodeのインポートにコメントするだけで、リークの問題が解決しました。

@michalkvasnicak私はこれを調査しましたが、Sentryが直接原因ではありません。

@sentry/nodeトランスポートはhttps-proxy-agentに依存しており、 agent-base依存しているため、 patch-core.jsファイルが必要です。これがリークの原因です：shrug：

https://github.com/TooTallNate/node-agent-base/issues/22

その内容をテストにコピーし、ヒープ統計を使用して実行することで、これを簡単に確認できます。

const url = require("url");
const https = require("https");

https.request = (function(request) {
  return function(_options, cb) {
    let options;
    if (typeof _options === "string") {
      options = url.parse(_options);
    } else {
      options = Object.assign({}, _options);
    }
    if (null == options.port) {
      options.port = 443;
    }
    options.secureEndpoint = true;
    return request.call(https, options, cb);
  };
})(https.request);

https.get = function(options, cb) {
  const req = https.request(options, cb);
  req.end();
  return req;
};

it("works", () => {
  expect(true).toBe(true);
});

おそらくそれをフォークするか、回避策を書く必要があります。

これの回避策はありますか？

https://nodejs.org/en/blog/release/v10.16.0/

いくつかのメモリリークを修正しました、誰かがそれをテストできますか？

ノード11.10でも同じ問題が発生しますが、ノード12.3.1で修正されているようです。

agent-base問題についてオープンなPRがあります： //github.com/TooTallNate/node-agent-base/pull/25

これをフォークしてYarn解像度の依存関係をオーバーライドするか、マージする方法を見つけることができます。

少しオフトピックかもしれませんが、Handlers.tsにドメインのクリーンアップがなく、domain.createのみであるというリークが発生する可能性もありますか？
中程度の記事またはSOは、removeListenersとdomain.exitが必要であることを示唆しています。 しかし、それに対する決定的な答えは見つかりませんでした。

更新：ハンドラーがdomain.exitを内部的に呼び出すdomain.runを使用していることがわかりました。 それでもリスナー/エミッターを削除すると違いが生じる可能性がありますが、正直なところわかりません。

Node 12.4.0にアップグレードしましたが、Sentryに関連しているように見える悪い動作がまだ見られます。

これは、90秒以上--autocannonオプションを使用して実行されたノードクリニックドクターの実行です。

• 歩哨の初期化なし
• init 、ただしエクスプレスリクエストハンドラーなし
• ハンドラーとinit （現在の本番セットアップ）の

リクエストハンドラーが配置されている場合にのみ、実際にリークが発生するように見えます。 ハンドラーなしの実行でGCトラフの底を見ると、それらはすべてほぼ同じレベル（65〜70 mb）にあり、ハンドラーを使用した実行では、GCサイクルごとに約5mb上昇しているように見えます。

@ tstirrat15この修正はまだリリースされていないため、おそらくこの問題がまだ発生しているのはそのためです。 それがオプションである場合、最新のマスターから試すことができますか？

@ tstirrat15修正が含まれている5.4.2がリリースされました、試してみてください:)

これは、v5.4.2を配置した別の実行です。 それはまだ少し漏れているようです...

GCは常に正しく起動し、メモリをベースラインに復元します。 メモリ使用量の増加は、イベントおよびイベントキューから収集されたブレッドクラムによって引き起こされますが、100ブレッドクラムで停止し、それ以上増加することはありません。 15〜30分のダンプのように表示され、ピークメモリがある時点で停止するかどうかを確認できれば便利です。

うーん...いいですね。 このPRを本番環境に移行し、動作が変化するかどうかを確認します。 ありがとうございました！

サーバーでwebpackを使用してSentryをバンドルすることに関連しているようです。これは、アプリがWebpackによってビルドされている場合にのみ発生します。 @ sentry / nodeを外部に追加すると、メモリの問題が修正されました。 なぜこれが起こるのか考えはありますか？

@tpbowdenあなたはこれについて

サーバーバンドル内のすべての依存関係をwebpackにバンドルしています。 このようにして、node_modulesなしでDockerイメージを出荷できますが、何かが歩哨SDKを台無しにしており、この方法でバンドルするとメモリリークが発生します。

いくつかの最適化プロセスによって作成されたバグである可能性があります。 私の大げさな推測は、それはおそらくより簡潔だということです。 いくつかの最適化はおそらくドメインモジュールの使用法を台無しにしており、 scope.addEventProcessor渡されたコールバックのクロージャはもはやガベージコレクションではないため、行われたすべての要求はかなりの量のメモリをリークしています。

また、webpack / terserバージョンより少し遅れているrazzle.jsを使用していますが、おそらくすでに修正されています。

これはもはや歩哨側のバグではないようです。 私はこれを引き続き調査し、必要に応じて問題を開き、このスレッドを最新の状態に保ちます。

これはもはや歩哨側のバグではないようです。 私はこれを引き続き調査し、必要に応じて問題を開き、このスレッドを最新の状態に保ちます。

投稿してください、ありがとうございます！

@kamilogorekコードのどこでScopeインスタンス内の_eventProcessors配列に追加されたイベントプロセッサコールバックが削除されるかを教えてください。 見つかりません。 すべてのリクエストがこの配列にイベントプロセッサコールバックを追加しているようで、削除されることはありません。 それらがどのように削除されるのかを知っていれば、バグをよりよく理解するのに役立つかもしれません。

それとも、リクエストごとに一意でガベージコレクションされるはずのスコープ全体ですか？ 各リクエストは同じスコープインスタンスを取得しているようです🤔

それとも、リクエストごとに一意でガベージコレクションされるはずのスコープ全体ですか？

それは正しいです。 ただし、 scopeは、新しいdomainインスタンスごとに複製する必要があります🤔

このコールスタックを参照してください。

https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/node/src/handlers.ts#L319 -L328

https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/hub/src/hub.ts#L442 -L457

https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/hub/src/hub.ts#L463 -L488

https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/hub/src/hub.ts#L479

ハ！ 私は何か見つけたと思う。

dynamicRequireを使用します。
https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/hub/src/hub.ts#L465-L468

しかし、dynamicRequireコードにステップインすると：
https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/utils/src/misc.ts#L28-L31

requireはmodでは未定義です🤯

したがって、 getHubFromActiveDomain関数のcatchブロックに入り、代わりにgetHubFromCarrier()ます。

私のセットアップでは、_everyting_はwebpackにバンドルされているため、おそらくwebpackによって壊れたmodオブジェクトにいくつかの仮定があります。 これをどのように修正できるかについてのアイデアはありますか？ 🤔

要約

dynamicRequireを使用します。

mod.requireは未定義です：

modオブジェクトはどのように見えますか：

最終的にgetHubFromCarrierを使用します。

node_modulesフォルダーに直接Hubモジュールにパッチを手動で適用しました。 dynamicRequireを使用して行を削除し、ファイルの先頭にimport domain from 'domain';を追加したところ、完全に機能するようになりました。 これ以上の漏れはありません！ 🎉

以前はdynamicRequireハックが必要だったかもしれませんが、新しいバージョンのwebpackでは不要になりましたか？ 🤔

私も交換しようとしました：

const domain = dynamicRequire(module, 'domain');

と：

const domain = require('domain');

そしてそれはまたうまく働きます。 これらの2つのソリューションのどちらを好むかわかりません。

この修正でPRを開きますか？