none
.netFrameWork 2.0と.netFrameWork4.0のガーベージコレクションの起動・挙動の違いについて RRS feed

  • 質問

  • .netFrameWork 2.0と.netFrameWork4.0のガーベージコレクションの起動・挙動の違いについて

    八木と申します。

    「ガベージ コレクションの条件
      ガベージ コレクションは、次のいずれかの条件に当てはまる場合に発生します。
        システムの物理メモリが少ない場合。
        マネージ ヒープで割り当てられたオブジェクトによって使用されているメモリが、許容されるしきい値を超える場合。
        このしきい値は、プロセスの進行に合わせて絶えず調整されます。
        GC.Collect メソッドが呼び出された場合。 ほとんどの場合、ガベージ コレクターは継続して実行されるため、

      このメソッドを呼び出す必要はありません。
        このメソッドは、主に特別な状況やテストで使用されます。 」

    上記の条件で
    .netFrameWork 2.0と.netFrameWork4.0のガーベージコレクションの起動・挙動に
    何か違いがありますでしょうか。

    もし何か情報がございましたらよろしくお願いします。

    2014年9月19日 6:02

回答

  • SurferOnWww様

    ラビットフェール保護につきましては、御回答いただいた内容から

    問題には関係ないという判断を開発者と相談の上行い

    現象の原因からは外すこととなりました。

    ご迷惑をおかけし申し訳ございませんでした。

    • 回答としてマーク 智弘八木 2014年9月19日 8:49
    2014年9月19日 8:37

すべての返信

  • 別スレッド(IIS6 と IIS8 の話)で似たような質問をされてますが、引用した文の出展、質問の背景を書けないですか?

    2014年9月19日 6:05
  • >> 「ガベージ コレクションの条件・・・
    >
    >何かを引用したのだと思いますが、出展を書けませんか?
    出典はこちらになります。
    http://msdn.microsoft.com/ja-jp/library/ee787088%28v=vs.100%29.aspx

    >> 上記の条件以外で
    >> IIS6.0と8.0のVisualC#における
    >> それぞれのガーベージコレクションの
    >> 起動条件の違いなどありますでしょうか。
    >
    >どういう意味でしょう?
    >C# で書かれた ASP.NET の Web アプリを IIS6 または IIS8 上で動作させた場合「ガベージ コレクションの条件・・・」に当てはまらないケースがあるか、
    >あるとするとそれは具体的にどういうケースかという質問ですか?
    >質問の背景を書けないでしょうか?
    背景としましては
    ある案件で
    ・WindowServer2003R2→2012R2
    ・IIS6.0→IIS8.0
    ・.net Framework2.0→4.0
    ・メモリ:12GB
    ・言語:VisualC#

    に環境をかえて、処理を実行した処
    「該当のワーカープロセスのメモリ使用率が100%近くになってしまい
      処理のフリーズが発生する。」
    現象が発生しております。

    開発者の方から、「本来は、上記のような状態になれば
    ガーベージコレクションが起動し、不要なメモリが
    解放され、処理が再起動される。(処理フリーズは起きない。)」

    上記の原因調査について
    ・.netFrameWork2.0と4.0でガーベージコレクションの挙動について
      差異があるのか調査してほしい。
    ・.netFramework4.0でガーベージコレクションによりアプリ上で
     使用したメモリを正しく解放するにはどのようにすればよいのか。
     net Framework2.0→4.0に移行時に、設定しなければならないことが
     あるのであれば調査してほしい。
    ということとなります。

    上記の事象で想定される原因のあたりがつかず
    どこから手を付けていいかわからない状態です。

    もし何か情報があればと考え質問をさせていただいた次第です。
    2014年9月19日 7:03
  • IIS 6/8 のスレッドにも書きましたが・・・

    このスレッドを含め、過去に質問者さんが立てた 8 つのスレッドは、すべて同じ問題が背景となっているのですよね。であれば、一つのスレッドにまとめられるはずです。
     
    同じ問題を、.NET のバージョンと IIS のバージョン別に、別スレッドを立てて質問するなんてのは最悪のやり方です。一つにまとめてください。スレッドの乱立は、はっきり言って迷惑です。止めてください。
     
    それから、過去に回答をもらっておきながら、中途半端に放置したスレッドがありますが、今後、最後まできちんとフォローしていただけるでしょうか?


    • 編集済み SurferOnWww 2014年9月19日 7:29 誤記訂正
    2014年9月19日 7:28
  • 「該当のワーカープロセスのメモリ使用率が100%近くになってしまい処理のフリーズが発生する。」

    以前、「どこのメモリ量を計測されたのかをまず示してください」と指摘したわけですが、再度(ワーカー)プロセスのメモリ使用率とは何でしょうか? 「リソースモニターのメモリ量を計測」したと答えられましたが具体的でありません。というのも「プロセス」にはそもそも「メモリ使用」という指標は存在ません。

    そもそも質問者さんはそれぞれの用語を理解していないように見受けられます。そのため、他者と意思疎通ができません。まずは用語を理解することからお勧めします。

    例えば「ワーカープロセスのリサイクル」とはプロセスを一旦終了し、新しいプロセスを立ち上げ直す機能のことです。終了している以上、メモリ使用量は0になっているはずです。ではなぜプロセスのメモリ使用量が減らないということになるか、質問者さんの言う「ワーカープロセス」が異なるものを指している可能性もあります。

    2014年9月19日 7:48
  • フォーラム オペレーターの星 睦美です。
    智弘八木 さん、こんにちは。

    先に投稿いただいた .net Framework4(VisualC#)のガーベージコレクションについて で、MSDN ライブラリの .NET Framework のバージョンおよび依存関係 をご紹介させていただきました。

    Windows Server 2012R2 の環境で.Net Framework 4.0 は適合しないのですが
    サーバーOS 、もしくは利用している.Net Framework が質問内容と実際の環境では相違しているのではないでしょうか?

    OSと.Net Framework のバージョンが適合している場合においても、既存の更新プログラムで解決されている問題の場合もありますので、OS を含めて最新の状態かどうか、さらに最新の更新プログラムが適用された環境で検証を行った結果と、イベント ログの情報などをお知らせいただくとフォーラム ユーザーからのアドバイスにつながるのではと思います。
    よろしくお願いします。

    追記:
    .Net Framework 4.0 以前の環境向けの説明として以下が参考になるかも知れませんのでご紹介します。

    ガベージ コレクタの基本とパフォーマンスのヒント:


    フォーラム オペレーター 星 睦美 - MSDN Community Support




    • 編集済み 星 睦美 2014年9月19日 8:16 追記
    2014年9月19日 7:56
  • 先のスレッドのラピッド フェール保護の件もこの問題に関連しての質問だと思いますが、結局どういう結論になったのですか? 問題とは関係ないことは明確になったのでしょうか?

    2014年9月19日 8:22
  • SurferOnWww様

    ラビットフェール保護につきましては、御回答いただいた内容から

    問題には関係ないという判断を開発者と相談の上行い

    現象の原因からは外すこととなりました。

    ご迷惑をおかけし申し訳ございませんでした。

    • 回答としてマーク 智弘八木 2014年9月19日 8:49
    2014年9月19日 8:37
  • ご自分のレスに回答としてマークをつけてますが、このスレッドは終わりにしてしまうのですか? 問題が解決したのならそれで結構ですが、もしそうなら、原因は何で、どのように解決したのか書いていただけませんか。

    ここは質問者さん専用の Q&A サイトではなく、技術者・開発者同士の情報交換の場所と考えていただけると幸いです。

    2014年9月19日 8:56
  • いくらなんでもこのコメントは質問文と無関係で、回答ではないでしょう。
    2014年9月19日 23:38
  • まあ一応ありそうな流れを書いておけば、

    ・プログラムにはそもそもメモリやリソースをリークしてしまうような不適切な部分がある

    ・以前は32ビットOSで32ビットプロセスでそもそもメモリ空間上限が低く、かつメモリ上限設定などですぐに再起動してたので一見正常に動いていた

    ・64OSになってアプリケーションプールもデフォルトの64モードでメモリ空間が実質無制限になり、メモリ上限設定もなしになり、おかげて際限なくリークが拡大して今の状況

    て辺りが考えられます。

    はっきり言ってGCの動作の問題ではなく、かなり高い確率でアプリケーションのバグです。

    ※このアプリケーションには、例えばサードパーティ製ライブラリといったものも、一応含みます、念のため。
    • 編集済み なちゃ 2014年9月20日 3:44
    2014年9月20日 3:38