IISがアプリケーションをリサイクルしないようにするにはどうすればよいですか？

IISでホストされているWCFサービスアプリがあります。起動時に、ローカルキャッシュとして使用するために非常に高価な（時間とCPUの点で）リソースを取得します。

残念ながら、IISはかなり定期的にプロセスをリサイクルしているようです。そのため、IISがアプリケーションをリサイクルしないように、アプリケーションプールの設定を変更しようとしています。これまでのところ、以下を変更しました。

• CPUの下での間隔を5から0に制限します。
• 20〜0のプロセスモデルでのアイドルタイムアウト。
• 1740から0までのリサイクル中の定期的な時間間隔。

これで十分ですか？そして、私が変更したアイテムに関する特定の質問があります：

1. CPUでの制限間隔の設定は具体的に何を意味しますか？特定のCPU使用率を超えた場合、アプリケーションプールがリサイクルされるということですか？
2. 「リサイクル」とはどういう意味ですか？アプリケーションは完全に解体され、再び起動しましたか？
3. 「ワーカープロセスのシャットダウン」と「アプリケーションプールのリサイクル」の違いは何ですか？プロセスモデルでのアイドルタイムアウトのドキュメントでは、ワーカープロセスのシャットダウンについて説明しています。一方、「リサイクル」の「定期的な時間間隔」のドキュメントでは、アプリケーションプールのリサイクルについて説明しています。私はこの2つの違いをあまり理解していません。w3wp.exeは、アプリケーションプールを実行するワーカープロセスだと思いました。誰かが2つのアプリケーションの違いを説明できますか？

IIS7およびIIS7.5タグを使用する理由は、アプリが両方で実行され、バージョン間で答えが同じであることを期待するためです。

参考画像：

リサイクル

通常、リサイクルとは、IISがアプリケーションのコンテナとして新しいプロセスを起動し、その後、古いプロセスをShutdownTimeLimitまで与えて、強制終了する前に独自の意志を取り除くことです。

*-通常：DisallowOverlappingRotation /「重複リサイクルを無効にする」設定を参照

それは破壊的な元のプロセスとそのすべての状態情報が破棄されることで、。アウトプロセスセッション状態（たとえば、状態サーバーまたはデータベース、または状態が小さい場合はCookie）を使用すると、この問題を回避できます。

ただし、デフォルトでは重複しています。つまり、古いプロセスに「[ShutdownTimeLimit]秒離れる必要があります。準拠してください。

設定

あなたの質問に：そのページのすべての設定は何らかの方法でリサイクルを制御します。「シャットダウン」は「プロアクティブなリサイクル」と呼ばれる場合があります-プロセス自体が行く時間を決定し、整然と終了します。

リアクティブリサイクルは、WASが問題を検出し、プロセスを（適切な代替W3WPを確立した後に）実行する場所です。

さて、ここにいくつかのフォームのリサイクルを引き起こす可能性のあるものがあります：

• 不健康だと判断するISAPI
• モジュールがクラッシュする
• アイドルタイムアウト
• CPU制限
• アプリプールプロパティの調整
  • お母さんはある時点で叫んだかもしれないので：「それを選ぶのをやめる、またはそれは決して良くならない！」
• 「ping」の失敗*実際にはpingを実行しません。名前付きパイプを使用しているため、より多くの「ライフ検出」
• 上記のスクリーンショットのすべての設定

何をすべきか：

一般的に：

• アイドルタイムアウトを無効にします。20分間の非アクティブ=ブーム！次の着信要求の新しいプロセス。それをゼロに設定します。

• 通常の時間間隔を無効にする-29時間のデフォルトは、さまざまな関係者によって「非常識」、「迷惑」、「賢い」と説明されています。実際には、そのうちの2つだけが真実です。

• オプションをオンにDisallowRotationOnConfigChange（、上記の構成の変更のために無効にReyclingをこれは、あなたがそれを瞬時にそれが殺される必要があるワーカープロセスにシグナルなしアプリケーションプールの設定を変更することができます-あなたはそれで遊んで止めることができない場合）。設定を有効にするには、アプリケーションプールを手動でリサイクルする必要があります。これにより、設定を事前に設定し、変更ウィンドウを使用して、リサイクルプロセスでそれらを適用できます。

• 一般的な原則として、pingを有効のままにします。それがあなたの安全策です。私は人々がそれをオフにし、その後サイトが無期限にハングし、パニックにつながるのを見てきました...そのため、設定が非常に非常に遅い応答アプリに対して攻撃的すぎる場合は、少しオフにしてくださいオフにするのではなく、何が得られるかを確認します。（独自の監視プロセスを使用して、ハングしたW3WPの自動クラッシュモードダンプを設定していない限り）

それは、行儀の良いプロセスを永遠に生き続けるのに十分です。それが死んだ場合、確かに、それは交換されます。ハングした場合、pingはそれを拾い、2分以内に新しいものを開始する必要があります（デフォルトでは、最悪の場合の計算は、最大ping頻度 + pingタイムアウト + リクエストが再び動作を開始するまでの起動時間制限です）。

CPU制限は通常はおもしろくありません。デフォルトではオフになっており、とにかく何もしないように構成されているためです。プロセスを強制終了するように構成されていた場合、それはリサイクルのトリガーになります。そのままにしておきます。IIS 8.xの場合、CPUスロットリングもオプションになります。

（IIS）AppPoolは（.Net）AppDomainではありません（ただし、1つまたは複数を含む場合があります）

しかし...その後、.Netの土地とAppDomainのリサイクルを開始します。これにより、状態が失われることもあります。（参照：https : //blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/）

ショートバージョン、あなたのコンテンツフォルダにweb.configファイルをタッチすることを行う（再びピッキング付き！）、またはそのフォルダ内にフォルダを作成することによって、またはASPXファイル、または...他のもの...それはだについてアプリプールのリサイクルと同じくらい破壊的であり、ネイティブコードの起動コストを差し引いています（これは純粋にマネージコード（.Net）の概念であるため、ここではマネージコードのみが発生します）。

アンチウイルスはweb.configファイルをスキャンするときにこれをトリガーし、変更通知を引き起こします。

確認してください、

アプリケーションプールをリサイクルする理由

Webを参照して、アプリケーションプールが定期的に自動的にリサイクルされるように構成されている理由を見つけると、メモリの問題に関係のない合理的な答えを見つけるのが難しくなります。コミュニティが一般に、Webアプリケーション（またはIISでホストされるサービスレイヤー）をメモリの問題を回避するためにリサイクルする必要があるという事実をほぼ受け入れているようです。

正しく動作し続けるためにコードを定期的に再起動する必要がある場合、何かが明らかに間違っているという意見が常にあります。どこかにコードにバグがあり、問題を「解消」するためにプロセスを時々再起動する代わりに、それを修正する必要があります。

.NET でのメモリ管理と、アプリケーションが問題なく実行し続けることができるようにすることにより重点を置く必要があります。

OPシナリオ（起動時の長い初期化/ウォームアップ）に基づいて、チェックするもう1つのことは、起動時間制限（秒）で、デフォルト値は90秒です。初期化にスタートアップの時間制限を超える時間がかかる場合、ワーカープロセスを終了できます。