共有環境でのIIS7のアプリケーションプールのリサイクルに最適な設定は何ですか?
4 に答える
ホスティング事業者として、メモリと時間、場合によってはリクエストの制限と CPU をリサイクルする必要があります。これらの制限についてかなり積極的に取り組みたいと考えていますが、必ずクライアントに公開してください。
メモリ- x86 ボックスの場合は 512、おそらく 768。x64 の場合、サーバーあたりのホスト数に応じて、これをさらに高く設定できます。注意して、メモリの問題でアプリ プールのリサイクル イベントを監視する必要があります。
時間- 通常、午前 1 時にプラスまたはマイナスでリサイクルします (最初のサイトは 1:01、2 番目のサイトは 1:11、3 番目のサイトは 1:21、すべてが同時にリサイクルされることはありません)。
リクエスト制限- IIS6 のデフォルトは 35,000 でしたが、この数は非常に恣意的であり、問題のサイトに大きく依存しています。使用量の少ないサイトの場合、夜間のリサイクルは 35,000 リクエストを受け取るずっと前にヒットします。
CPU - 95%/1 分制限/KillW3WP ですが、これは慎重に使用してください。これについての私の理解では、CPU がこのワーカー プロセスの 1 分間の制限を超えて 95% 以上に達した場合、アクションが KillW3WP に設定されている場合、ワーカー プロセスは強制終了され、制限の残りの時間は再起動できません。最初は NoAction を試して、イベント ログを注意深く観察することをお勧めします。
Recycle Event Logs - 設定した各イベントしきい値についてアプリ プールのリサイクルをログに記録していることを確認する必要があります。つまり、リクエストの制限に基づいて制限する場合は、Request Limit のログが有効になっていることを確認してください。
覚えておくべきことの 1 つは、 machine.configretail="true"
の<deployment>
要素に設定する必要があることです。
<system.web>
<!--
<deployment
retail = "false" [true|false]
/>
-->
<deployment retail="true" />
</system.web>
これを設定しないと、サイトでデバッグをオンにすることができ、リクエストのタイムアウトが無制限になります。ホスティング業者にとっては理想的ではありません...
ヒント:アプリをリサイクルすると、すべてのセッション変数が破棄されます...したがって、これには注意してください。
私見、デフォルトのままにします。
トラフィックの多いサイトの場合は、長いリサイクル スケジュールを使用してください。トラフィックの少ないサイトの場合は、短い/デフォルトのスケジュールを使用してメモリを節約してください。
Al Zabir のブログからこれを学びました。
Daniel S. の言うとおりです。セッション変数はリサイクル時に破棄されるため、セッション オブジェクトを取得するときに、これを十分にテストするか、適切なエラー保護/回復を行うようにしてください。
必要に応じて設定を調整する必要があります。使用しているメモリの量と、サイト/Web アプリケーションの使用のピーク時間を考慮してください。
また、サイト/Web アプリケーションのメモリ使用量も考慮してください。メモリ リークが発生した場合、考えているよりも頻繁にリサイクルしている可能性があります。
上記のように、状態変数が失われるため、リークとリサイクルのコストを比較検討してください。