最近、一連のWindows Server 2008 R2/IIS 7.5サーバーをWindows Server 2012を実行する新しいサーバーに移行しました/ IIS 8。
IISからの奇妙な動作が発生しています。 2つの同一のサーバーがあり、各サーバーは2つのWebサイトを実行しており、それぞれが独自のアプリプールで実行しています。各Webサイトのコードは同じです。 (文字通り...同じdllとすべて、わずかに異なる構成)。
アプリプールは24時間ごとのスケジュールでリサイクルするように設定されていますが、その24時間の間、w3wpワーカープロセスのCPU使用率は12.5%ずつ増加します(サーバーには8つのプロセッサがあるため、そうではないと思います)偶然)。
CPU使用率が上昇すると、アプリがリサイクルするまで、CPU使用率は下がりません。私が知る限り、現時点ではアプリは何もせず、リクエストを処理していません。サーバーへのすべてのトラフィックをブロックでき、CPU使用率はそのままです。 Webサイトを再起動することもできますが、CPU使用率は変わりません。 CPU使用率をリセットする唯一の方法は、実行されているアプリプールをリサイクルまたは再起動することです。
この問題が私のコードとは何の関係もないと私は多少確信していますが、何らかの貧弱なIIS構成またはIIS 8の変更が機能しているハードウェア構成か何かで不十分ですか?
それが重要かどうかはわかりませんが、これらはRackspace Performance Cloudサーバーです。
次のスクリーンショットは、これらのサーバーのCPU負荷の経時変化を示しています(緑色の矢印は、アプリプールがリサイクルする時間を示しています。各プラトーが12.5%の整数倍であることがわかります。
誰かがこの動作を観察しましたか?私は2009年にこの質問を見つけました。IIS 6:
どんな助けでも大歓迎です
この本当には、無限ループでスタックしているコードのように見えます。
リクエストが届くと、IISがサービスを開始し、何か(おそらくバグ)がこの動作をトリガーします。ワーカースレッドが無限ループに入り、CPUを100%に固定します。アプリプールがリサイクルされるまでの道。
スタックスレッドが実際に終了することはないため、新しい要求が入らなくても、CPUは使用中のままです。
時々、新しいリクエストがこの振る舞い再びを引き起こし、それからtwoスタックしたCPU(または3つまたは4つ...)を取得します。
もちろん、アプリプールをリサイクルすると、すべてのワーカースレッドが終了するため、問題が解決されます...再び発生するまで。
Debug Diagnostic tool から track down を使用して問題の原因を試すことができます。これは通常、クラッシュとメモリリークのトラブルシューティングを目的としていますが、問題の原因となっているコンポーネントを見つけるのに役立ちます。
Sharepoint 2013とまったく同じ問題があり、IIS 8 on 2012 ...トラブルシューティングは行っていませんが、代わりに2008 R2でSP2013にダウングレードし、すべてが順調でした。
私には無限ループのように見えます。 IIS未処理のリクエストはないと言っているにもかかわらず、これを何度か見たことがあります。それがどのようになるかはわかりませんが、これはまさにあなたが見るものです。難しい部分はIISは要求が完了するまで要求をログに記録しないため、この動作をトリガーする要求を見つけるのは困難です。
CPUプロファイラーをw3wpプロセスに接続して、そこで何が行われているのかを確認できます。 CPUサイクルを消費しているものを確認できるはずです。