一番下の緑色の線がデータベース呼び出しで始まり、そこにとどまっていることに気付きました。これは、db 呼び出しが開いたままになっていることを意味しますか?

Hangfireでバックグラウンド ジョブをエンキューおよび処理するときに、再現可能なメモリ不足の例外が発生する可能性があります。

ジョブは単純なConsole.WriteLine呼び出しであるため、ヒープメモリがそのように増加するとは思いません。

構成が間違っていましたか、それとも問題を報告することを検討する必要がありますか?

結果 ( VMMap )

ジョブのバッキング ストレージとして Redis を使用する:

• 開始時の総ヒープ = 29,088K。
• 5,000 ジョブの後、938,672K。
• 6,000 ジョブ、1,056,004K。
• 7,000 ジョブ、1,219,296K。
• 8,000 ジョブ、ヒープ値は存在しません。
• さらに 100 ジョブ以内に、iisexpress.exeインスタンスがクラッシュします。

SQL ストレージを使用すると、制限はさらに高くなります ~= 15,000 ジョブ。

設定

• 空の ASP.NET プロジェクト。
• IIS ホスティングと Hangfire 用の Owin パッケージをインストールします。
• スタートアップ クラスとコントローラー。

パッケージ

コントローラ

起動

いくつかの Azure Web ジョブが設定されているアプリケーションがあり、これらの Web ジョブの開始と終了を報告するように NLog が設定されています。NLog を Stackify にフックして、Stackify ロガーを使用して WebJob から WebJob への移動を監視できるようにします。ロギングは機能します (したがって、構成に問題がないことがわかります)。私たちが直面している問題は、ログが断続的であることです。いくつかの WebJob に沿って移動するメッセージを個別に確認できますが、部分的なログしか取得できません。たとえば、最初のログにはメッセージが読み取られたことが記録されますが、終了メッセージは表示されません。次のログには、入口と出口が表示されます。問題は、それらがすべてまったく同じコードを利用しているため、同じログメッセージが毎回表示されるはずです。他の誰かが以前にこの問題に遭遇したことがありますか? 回答する前に、次の診断手順を実行しました。

(1) すべての webjob 構成ファイルで構成設定が適切であることを確認しました。

(2) すべての webjob 構成ファイルが Azure に適切に投稿されていることを確認しました。

(3) 私たちは、メッセージがさまざまな Web ジョブに到達し、処理され、次の Web ジョブに移動していることを (Azure の Web ジョブ コンソールを介して) 独自に検証しました。つまり、ログ コードを呼び出していることを意味します。

(4) Stackify のログ データが調整されていないことを確認しました (ログが単に停止した場合、これは理にかなっているかもしれませんが、単一のメッセージ送信中に、場合によっては部分的なログが取得され、他の場合には完全なログが取得されるという事実があります)。これはありそうもありません）。

(5) Stackify のドキュメントを詳しく調べたところ、ログを取得できるように構成が適切に設定されていることが保証されているようです。全か無かのシナリオはカバーしていますが、いくつかのシナリオはカバーしていません。

必要に応じて、より明確な説明を提供させていただきます。

Stackify Prefixをインストールしましたが、うまく機能しています。唯一の問題は、IIS に CRM サイトがあることです。私は本当にこれを無視する必要があります。