2012-04-23 36 views
3

MVC3 WebアプリケーションとWCFデータレイヤサービスの間でメモリリークが発生しています。WCF/Castleでのメモリリーク

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

最初の症状は、バックエンドに関連付けられたw3wpプロセスのサイズが絶え間なく増えていたことです。サービスを呼び出すWebアプリケーションから単純な呼び出しが行われるたびに、変化する量(100kbの大きさのオーダー)で拡大することがわかります。アプリに対する

実行JetBrainsのメモリプロファイルは、我々は

System.ServiceModel.Channels.TransmissionStrategy.SlidingWindow 

は遠く離れて犯人であることがわかります。アプリケーションの起動時には、わずかな量のメモリ(全体の6.4%)でインスタンス化された4つのオブジェクトがあり、軽度の使用が> 200個のオブジェクト、つまり合計の50%まで上昇した後にインスタンス化されます。継続的に使用すると、これが100%に向かいます。私は以前これについて聞いたことはありませんが、グーグルでは、WCFレイヤーとの間でデータを送受信する際に(他のものの中で)使用されていることを示しています。

私の現在の考え方は、プロセスが作成されていても正しくリリースされないということです。当社のサービスは、城から作成された、としてウェブ端から登録されています。他のスレッドで示唆したように

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(); 

を使用しています。上記の内容で十分であるとは考えていますが、私たちはサービス参照を明示的に破棄していません。誰かが、私たちの漏れがどこから来ているのかに関する推奨事項や提案はありますか?

+0

あなたはメモリを再利用できないと確信していますか?機械全体のメモリは圧迫されていますか?たくさんの記憶があるので、それを取り戻すことはできませんか? –

+0

完全に確かめて、それは再利用されていません – Chris

答えて

4

残念ながら、WCFプロキシの手動処理を管理することは、ガベージコレクションのメモリ解放とネットワークリソースの解放を確実にする最も信頼できる方法です。このbrief blog postは、WCFプロキシがメモリ&ネットワークリソースをリークする原因となる問題の一部を説明しています。一時的なプロキシインスタンスを作成するようにコンテナを設定しているので、この記事で示したようなパターンでサービスコールロジックをラップする必要があります。

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

PS:この問題の解決を試みるために、より長生きしたスコープ(思考を要求するか、シングルトン)を使用するように誘惑しないでください。解決策は、プロキシインスタンスの適切な処分です。私はこれを難しい方法で見つけました... ;-)

+0

ありがとう、私はこれが事実かもしれないと恐れていました。 – Chris

関連する問題