3

MVC3WebアプリケーションとWCFデータレイヤーサービス間のメモリリークに問題があります。

問題はWCF側にあると思いますが、追跡することはできません。私はウェブとこれらのフォーラムを検索しましたが、原因を見つけることができませんでした。どんな助けでも大歓迎です！

つまり、最初の症状は、バックエンドが絶えず成長することに関連するw3wpプロセスのサイズでした。サービスを呼び出すWebアプリから単純な呼び出しが行われるたびに、可変量（100kbのオーダー）で増加することがわかります。

アプリに対してJetbrainsメモリプロファイルを実行すると、

System.ServiceModel.Channels.TransmissionStrategy.SlidingWindow

はるかに犯人です。アプリの起動時に、少量のメモリ（全体の6.4％）でインスタンス化された4つのオブジェクトがありますが、穏やかに使用すると、200を超えるオブジェクト、全体の約50％に上昇します。継続して使用すると、これが100％になります。これについては今まで聞いたことがありませんが、グーグルによって、WCFレイヤーとの間のデータの送信に（とりわけ）使用されていることが示されています。

私の現在の考え方は、プロセスは作成されていますが、正しくリリースされることはないということです。私たちのサービスはCastleから作成され、Webエンドから次のように登録されます。

public static IWindsorContainer RegisterWcfService<TS, TI>(this IWindsorContainer container)
 where TI : TS
 where TS : class
{
 container.Register(Component.For<TS>().ImplementedBy<TI>().Named(typeof(TI).Name)
     .Interceptors<LoggingInterceptor>()
     .Interceptors<ExceptionHandlerInterceptor>()
     .LifeStyle.Transient
     .AsWcfService(
        GetServiceModel<TS, TI>()
        ));

 return container;
}

他のスレッドで提案されているように、私たちは使用しています

container.Kernel.ReleasePolicy = new NoTrackingReleasePolicy();

コンポーネントが正しくリリースされていることを確認します。上記で十分だと思いますが、サービス参照を明示的に破棄することはありません。リークがどこから来ているのかについて、誰かが推奨事項や提案を持っていますか？

4

1 に答える 1

4

残念ながら、WCFプロキシの破棄を手動で管理することは、ガベージコレクション用のメモリの解放とネットワークリソースの解放を確実にするための最も信頼できる方法です。この簡単なブログ投稿では、WCFプロキシがメモリとネットワークリソースをリークする原因となるいくつかの問題について説明しています。一時プロキシインスタンスを作成するようにコンテナをすでに構成しているため、サービス呼び出しロジックを記事に示されているパターンと同様のパターンでラップする必要があります。

これで問題が解決しない場合は、WinDbgを使用してメモリダンプを調べ、SlidingWindowインスタンスへの参照チェーンを保持している実際のGCルートを見つける必要があります。

PS：この問題を解決するために、より長寿命のスコープ（思考を要求または消滅させる、シングルトン）を使用するように誘惑されないでください。解決策は、プロキシインスタンスを適切に破棄することです。私はこれを難しい方法で見つけました...;-)

于 2012-04-23T13:29:54.757 に答える