IISがアプリケーションをリサイクルしないことを確認するにはどうすればよいですか？
IISでホストされているWCFサービスアプリがあります。起動すると、ローカルキャッシュとして使用するために非常に高価な（時間とCPUの観点から）リソースをフェッチします。
残念ながら、IISはかなり定期的にプロセスをリサイクルしているようです。そのため、アプリケーションプールの設定を変更してIISアプリケーションをリサイクルしません。これまでのところ、私は以下を変更しました：
- CPUでの間隔を5から0に制限します。
- プロセスモデルでのアイドルタイムアウトが20から0になりました。
- 1740から0までのリサイクル時の定期的な時間間隔。
これで十分でしょうか？また、変更したアイテムについて具体的な質問があります。
- 具体的には、CPUの下の制限間隔設定はどういう意味ですか？特定のCPU使用率を超えた場合、アプリケーションプールがリサイクルされるということですか。
- 「リサイクル」とはどういう意味ですか？アプリケーションは完全に破棄され、再起動されましたか？
- 「ワーカープロセスのシャットダウン」と「アプリケーションプールのリサイクル」の違いは何ですか？プロセスモデルでのアイドルタイムアウトのドキュメントでは、ワーカープロセスのシャットダウンについて説明しています。一方、「リサイクル」の「定期的な間隔」のドキュメントでは、アプリケーションプールのリサイクルについて説明しています。この2つの違いをよく理解していません。 w3wp.exeはアプリケーションプールを実行するワーカープロセスだと思いました。誰かが2つのアプリケーションの違いを説明できますか？
IIS7とIIS7.5のタグがある理由は、アプリが両方で実行され、バージョン間で答えが同じであることを期待しているためです。
参考画像： 
リサイクル
リサイクルは通常*です。ここでIISは、アプリケーションのコンテナーとして新しいプロセスを起動し、古いプロセスをShutdownTimeLimitまで上げて、強制終了する前にそれ自体の意志を解消します。
*-通常：DisallowOverlappingRotation/"Disable Overlaped Recycle"設定を参照
元のプロセスとそのすべての状態情報が破棄されるという点でdestructiveです。プロセス外のセッション状態（例：状態サーバーまたはデータベース、または状態が小さい場合はCookie）を使用すると、これを回避できます。
ただし、デフォルトではoverlapped-新しいプロセスが開始され、リクエストキューにフックされるため、古いプロセスに「[ShutdownTimeLimit]秒以内に離れてください。遵守してください。」
設定
あなたの質問へ：そのページのすべての設定は、何らかの方法でリサイクルを制御します。 「シャットダウン」は「プロアクティブリサイクル」と呼ばれることもあります。この場合、プロセス自体が実行時間を決定し、秩序だった方法で終了します。
リアクティブリサイクルは、WASが問題を検出してプロセスを実行する場所です（適切な交換用W3WPを確立した後）。
ここで、何らかの形でリサイクルを引き起こす可能性があるものをいくつか示します。
- iSAPIが異常であると判断した
- クラッシュするモジュール
- アイドルタイムアウト
- cPU制限
- アプリプールプロパティの調整
- あなたのお母さんがmayを叫んだとき：「やめなさいpickingそれで、さもなければ、それは決して良くなることはない！」
- 「ping」の失敗*実際にはping自体ではなく、名前付きパイプを使用します-より「寿命検出」
- 上のスクリーンショットのすべての設定
対処法：
一般的に：
無効アイドルタイムアウト。非アクティブの20分=ブーム！次の着信要求の新しいプロセス。それをゼロに設定します。
無効通常の時間間隔-29時間のデフォルトは、「非常識」、「迷惑」、「巧妙」と説明されています。さまざまなパーティー。実際には、そのうちの2つだけがtrueです。
オプションでDisallowRotationOnConfigChange（上記のDisy Reycling for configuration changes）をオンにすることができます。 tそれで遊ぶのをやめる-これにより、強制終了する必要のあるワーカープロセスに即座に信号を送ることなく、アプリプールの設定を変更できます。設定を有効にするには、アプリケーションプールを手動でリサイクルする必要があります。これにより、設定を事前に設定し、変更ウィンドウを使用して、リサイクルプロセスを介して設定を適用できます。
一般的な原則として、leave pinging enabledにします。それがあなたのセーフティネットです。人々がそれをオフにしていると、サイトがときどきハングし、パニックに陥るのを見てきました...なので、設定が非常に非常に遅く、応答が遅いアプリに対してあまりにも積極的である場合は、少しオフにしてくださいオフにするのではなく、何が得られるかを確認してください。 （独自の監視プロセスを介してハングした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ファイルを作成するか、その他のことを行います。 aboutアプリケーションプールのリサイクルと同じくらい破壊的ですminusネイティブコードの起動コスト（これは純粋にマネージコード（.Net）の概念であるため、ここではマネージコードのみが発生します）。
アンチウイルスは、web.configファイルをスキャンしてこれをトリガーし、変更通知を引き起こし、...
親切に確認してください、
webを閲覧して、アプリケーションプールが定期的に自動的にリサイクルするように構成されている理由を見つけた場合、メモリの問題に関係のない合理的な答えを見つけるのは難しいでしょう。メモリの問題を回避するために、Webアプリケーション（またはIISでホストされるサービスレイヤー）をリサイクルする必要があるという事実は、コミュニティが一般に受け入れているようです。
正しく機能し続けるためにコードを定期的に再起動する必要がある場合、何かが明らかに間違っていると私はいつも考えていました。コードのどこかにバグがあり、時々プロセスを再起動して問題を「解消」するのではなく、修正する必要があります。
.NETの memory management にさらに焦点を当てる必要があり、アプリケーションが問題なく実行し続けることができることを確認する必要があります。
OPシナリオ（起動時の初期化/ウォームアップ）に基づいて、もう1つ確認することは起動時間制限（秒）であり、デフォルト値は90秒です。初期化に起動時間制限を超える時間がかかる場合、ワーカープロセスを終了できます。