IIS でホストされている WCF サービス アプリがあります。起動時に、ローカル キャッシュとして使用するために、非常にコストのかかる (時間と CPU の点で) リソースを取得します。
残念ながら、IIS はプロセスをかなり定期的にリサイクルしているようです。そのため、IIS がアプリケーションをリサイクルしないように、アプリケーション プールの設定を変更しようとしています。これまでに、次の変更を行いました。
- CPU の制限間隔を 5 から 0 まで。
- プロセス モデルのアイドル タイムアウトが 20 から 0 に変更されました。
- 1740 から 0 までのリサイクル中の定期的な時間間隔。
これで十分でしょうか? 変更した項目について具体的な質問があります:
- CPU の制限間隔設定は具体的に何を意味しますか? 特定の CPU 使用率を超えると、アプリケーション プールがリサイクルされることを意味しますか?
- 「リサイクル」とは具体的にどういう意味ですか? アプリケーションは完全に破棄され、再起動されるのですか?
- 「ワーカー プロセスのシャットダウン」と「アプリケーション プールのリサイクル」の違いは何ですか? プロセス モデルのアイドル タイムアウトのドキュメントでは、ワーカー プロセスのシャットダウンについて説明しています。一方、リサイクルの定期的な時間間隔のドキュメントでは、アプリケーション プールのリサイクルについて説明しています。この 2 つの違いがよくわかりません。w3wp.exe は、アプリケーション プールを実行するワーカー プロセスだと思っていました。アプリケーションにとって、この 2 つの違いを説明していただけますか?
IIS7 および IIS7.5 タグがある理由は、アプリが両方のバージョンで実行され、バージョン間で回答が同じになることを期待しているためです。
参考画像:
答え1
リサイクル
リサイクルとは通常、IIS がアプリケーションのコンテナーとして新しいプロセスを起動し、古いプロセスがShutdownTimeLimit強制終了される前に自動的に消滅するようにすることです。
*- 通常: DisallowOverlappingRotation/「重複リサイクルを無効にする」設定を参照
それは破壊的元のプロセスとそのすべての状態情報が破棄されるという点です。プロセス外のセッション状態 (状態サーバーやデータベース、または状態が小さい場合は Cookie など) を使用すると、この問題を回避できます。
しかし、それはデフォルトです重なった- つまり、古いプロセスに「[ ] 秒以内に終了してください。従ってください」と通知される前に、新しいプロセスが開始され、リクエスト キューに接続されるため、停止期間が最小限に抑えられShutdownTimeLimitます。
設定
ご質問への回答: そのページのすべての設定は、何らかの方法でリサイクルを制御します。「シャットダウン」は「プロアクティブなリサイクル」と説明できます。つまり、プロセス自体が終了のタイミングを判断し、規則的に終了します。
リアクティブリサイクルでは、WAS が問題を検出し、適切な代替 W3WP を確立した後でプロセスを実行します。
さて、ここに、何らかの形でリサイクルを引き起こす可能性のあるものをいくつか挙げます。
- ISAPIが不健全だと判断する
- モジュールがクラッシュする
- アイドルタイムアウト
- CPU制限
- アプリケーションプールのプロパティを調整する
- あなたのお母さんとして5月ある時点で叫んだ。「止めろピッキング頑張らないと、決して良くなりませんよ！」
- 「ping」の失敗 * 名前付きパイプを使用しているため、実際には ping を実行していない - より「生存検出」
- 上記のスクリーンショットのすべての設定
何をするか：
一般的に：
無効にするアイドルタイムアウト20 分間の非アクティブ = 爆発! 古いプロセスは消えます! 次の着信要求で新しいプロセスが開始されます。これをゼロに設定します。
無効にする定期的な時間間隔- 29 時間のデフォルトは、さまざまな関係者から「非常識」、「迷惑」、「巧妙」と評されています。実際には、そのうちの 2 つだけが真実です。
オプションオンにする回転時の設定変更を許可しない（その上、設定変更のリサイクルを無効にする) を使用すると、ワーカー プロセスに強制終了の通知を即座に送信することなく、アプリ プールの設定を変更できます。設定を有効にするには、アプリ プールを手動でリサイクルする必要があります。これにより、設定を事前に設定してから、変更ウィンドウを使用してリサイクル プロセスで設定を適用できます。
一般的な原則として、離れるピンピング有効. これはセーフティ ネットです。これをオフにすると、サイトが永久にハングアップしてパニックに陥る人が時々いるのを見たことがあります... そのため、明らかに応答が非常に遅いアプリに対して設定が強すぎる場合は、オフにするのではなく、少し下げて、どうなるか見てみましょう。(独自の監視プロセスを通じて、ハングした W3WP に対して自動クラッシュ モード ダンプを設定している場合を除く)
これは、行儀のよいプロセスが永遠に生き続けるのに十分なものです。プロセスが停止した場合、もちろん、置き換えられます。プロセスがハングした場合、ping でそれを検出し、2 分以内に新しいプロセスが起動します (デフォルトでは、最悪の場合の計算は次のようになります。ピング頻度+pingタイムアウト+起動時間制限リクエストが再び機能し始める前に)。
CPU制限は通常は興味深いことに、デフォルトではオフになっており、何もしないように設定されています。プロセスを強制終了するように設定されていたら、確かにリサイクル トリガーになります。オフのままにしておいてください。IIS 8.x の場合、CPU スロットリングもオプションになります。
(IIS) AppPool は (.Net) AppDomain ではありません (ただし、1 つまたは複数を含む場合があります)
しかし....その後、.Netの世界に入り、Appドメインリサイクルにより状態が失われる可能性もあります。(参照:https://blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/）
簡単に言うと、コンテンツフォルダ内のweb.configファイルを変更することでこれを実現できます（再び摘み取りです！）、またはそのフォルダ内にフォルダを作成したり、ASPXファイルを作成したり、その他の方法で...そしてそれはについてApp Poolのリサイクルと同じくらい破壊的マイナスネイティブ コードの起動コスト (これは純粋にマネージ コード (.Net) の概念なので、ここではマネージ コードの初期化処理のみが行われます)。
ウイルス対策ソフトウェアは、web.config ファイルをスキャンして変更通知を発生させ、次のような結果を引き起こすこともあります。
答え2
ご確認ください。
アプリケーションプールが定期的に自動的にリサイクルされるように構成されている理由をWebで調べると、メモリの問題に関係のない合理的な答えを見つけるのは難しいでしょう。コミュニティ全体が、Webアプリケーションが(または IIS でホストされているサービス レイヤー) は、メモリの問題を回避するためにリサイクルする必要があります。
私はいつもこう思っていますコードが正しく動作し続けるために定期的な再起動が必要な場合は、明らかに何かが間違っています。バグがあります。コードのどこかに問題があり、それを修正する必要があるため、問題を「解消」するために時々プロセスを再起動する必要はありません。
もっと集中する必要があるメモリ管理.NET でアプリケーションが問題なく実行し続けることができるようにすることに重点を置いています。
答え3
OPのシナリオ（起動/ウォームアップ時の長い初期化）に基づいて、確認すべきもう1つのことは起動時間制限(秒) デフォルト値は 90 秒です。初期化にスタートアップ時間制限を超えると、ワーカー プロセスが終了することがあります。
答え4
答えは、あなたできるAppPoolがリサイクルされるのを防ぐことができますが、いけない。
その理由は、メモリ リークが発生すると、最終的にはサーバーのメモリがすべて消費され、Windows がブルー スクリーンを表示したり、メモリ不足の例外をスローしたりして、同じ IIS サーバー上の他のサイトがダウンしてしまうからです。
したがって、そのサイトで使用できるメモリの量を決定し、その制限に達したときに上記の設定をリサイクルするように設定します。
通常、リサイクルは適切に行われるため、エンド ユーザーはそれを意識しません。ただし、Blazor Server を使用している場合は、すべてのセッションがサーバー上で実行され、すべての状態が失われます。実際には、リサイクルが行われている間、Blazor アプリに「接続中...」というメッセージが約 5 秒間表示されます。つまり、サーバー サイド Blazor アプリでは適切に行われません。
この話の教訓は、前に述べたとおり、サイトがメモリ リークを起こさないことを確認することです。開発プロセスの早い段階でメモリをテストし、ライブになるまで待たないでください。Blazor Server はメモリを大量に消費するため、私の経験ではメモリの問題のデバッグにかなりの時間を費やす必要がありました。これは Blazor のせいではなく、Blazor Server アプリの性質上、非常にタイトなコードが求められるだけです。以前の .net では、GC がすべてを処理していたため、メモリについて心配することはありませんでしたが、IIS 内で実行すると話は別です。