2

この特定の問題は私を狂わせています。誰かが同じような問題を経験したのだろうか。ワークフローをロードしてからアンロードしてメモリスナップショットを実行すると、結果は予測可能になります。ワークフローはメモリに存在しなくなります。ただし、ワークフローをロードしてPersistableIdleアクションをPersistableIdleAction.Unloadに設定し、ワークフローをアイドル状態にすると、Unloadアクションが実行されてもワークフローはメモリに残ります。

この問題をデバッグするためにANTSメモリプロファイラーを使用しました。これは、内部オブジェクトがワークフローインスタンスにぶら下がっていることを示す、出力されたオブジェクト保持グラフです。

代替テキスト
（出典：rohland.co.za）

他の誰かがこの問題を確認できますか？私のコードは次のようになります。

  1. SqlWorkflowInstanceStoreを作成し、ロック所有者ハンドルを設定します
    -この時点で、メモリスナップショットを取得します
  2. Workflow1のインスタンスを作成します
  3. PersistableIdleアクションを設定します
  4. インスタンスストアをWorkflow1に適用します
  5. Idle、Unload、UnhandledExceptionなどのアクションイベントハンドラーを設定します。
  6. ワークフローインスタンスを永続化する
  7. ワークフローインスタンスを実行します
  8. インスタンスがアイドル状態になるのを待ちます（遅延アクティビティが原因）
  9. アンロードアクションが実行されていることを確認します
    -この時点で、2番目のメモリスナップショットを作成します

上の画像から、Workflow1を参照している唯一のオブジェクトは、処理できない内部イベントハンドラーの結果であることが明らかです。

手がかりはありますか？

4

1 に答える 1

0

興味深いバグのように見えますか？あなたが言及したプロファイラーを持っていないので、いくつか質問します。

  • あなたの調査は、いくつかの重大なメモリ使用の問題によって引き起こされていますか?

  • プロファイリングの時点でアンロード アクションが実際に完了したことをどの程度確信していますか (非同期で実行しようとしている場合など)?

  • 非同期チェーンは問題ないように見えますが、TdsParserStateObject がリークされている実際のオブジェクトである可能性があります。クラスには Dispose() メソッドがありますが、IDisposable を実装していません。したがって、別のアイデアは、 Dispose() を使用して、特定の時点でオブジェクトを手動で「リセット」または「リサイクル」することですが、その時点は「まだ（アンロード時間）ではなく後で」、たとえば怠惰であることが判明しますリサイクル。TdsParserStateObjects の数が経時的に増加しているかどうかをプロファイラーで確認して、そこに実際のリークがあるかどうかを確認できますか? 「オブジェクトの数が限られているため、実際のリークではない」リークとは対照的です。

于 2010-04-29T21:26:24.767 に答える