locked
IIS アプリケーション プールの初回起動が遅い RRS feed

  • 質問

  • VS2008 にてASP.NETのシステムを構築しております。

    社内では、初回起動時、もしくはアイドル状態からの復帰時の時間は、数秒で起動するのですが、

    お客様のサーバーでは、5分以上掛かって起動します。

    現在、いろいろ調査を行っているのですが、明確な原因が特定できない状態です。

    モジュールの記載がないプログラムでも、現象が変わらない状況です。

    環境

    サーバーOS:Windows Server 2008 + SP2

    .Net Framework :3.5 SP1

    IIS7

    承認:ASP.NET偽装、Windows 認証、基本認証は有効

    アプリケーションプールのプロセスモデルのID: NetworkService

    リサイクルの設定は、多少変更しております。

    後の設定は、初期状態です。

    開発言語:C# 2008

    一時回避策は、分かっていますが、セキュリティ上問題なので、解決したいと思っております。

    お知恵を拝借できないでしょうか。

    よろしくお願いします。

     

    2011年12月16日 3:02

回答

  • aspnet.configに<generatePublisherEvidence enabled="false"/>を
    追加することにより解決?に至りました。

    現在、様子をみている状態です。

     

    • 回答としてマーク 碧流 2012年1月4日 0:47
    2011年12月22日 10:03

すべての返信

  • 碧流 さん、こんにちは
    フォーラム オペレーターの星 睦美です。

    碧流 さんが調査された点と一時的に回避する方法、
    サーバーに関する詳しい情報が分かると回答が集まりやすいのではないかと思います。
    よろしければお知らせください。


    日本マイクロソフト株式会社 フォーラム オペレーター 星 睦美
    2011年12月16日 4:22
  • ■サーバーの構成

    OS:Windows Server 2008 + SP2

    IIS:7.0

    CPU:Xeon 5640 2.66GHz(4コア)

    メモリ:4GB

    HDD:300GB×3(Raid 1 + 1ホットスペア)

    database:SQL Server 2008 R2(32bit)

    .Net Framework :3.5 SP1

    ADサーバーは、別に立てております。

    ■IISとアプリケーションプールの設定

    承認:ASP.NET偽装、Windows 認証、基本認証は有効

    アプリケーションプールのプロセスモデルのID: NetworkService

    マネージ パイプラインモード:統合

    リサイクル設定:

     定期的な間隔:1740分

     特定の時間:5:00,12:30

     プライベートメモリ:800MB

     仮想メモリ制限:1.2GB

     構成可能なリサイクルイベント

      定期的な間隔:ON

      プライベートメモリ:ON

      仮想メモリ制限:ON

     ランタイム リサイクルイベント

      オンデマンド:ON

    ■調査

    ①IISの設定が社内と同様かの確認

    ②セキュリティーポリシの確認

    ③モジュールの記載がないプログラムを作成

    ④Windows 認証を匿名認証に変更

    ⑤サーバーの再インストール

    ■一時的な回避方法

    サーバーでIEを起動し、5分毎にリフレッシュをかけて、アプリケーションプールを停止しないように行っています。

    よろしくお願いします。

    2011年12月16日 5:12
  • ASP.NETは初回起動時にコンパイルを実施し、IISプロセスの起動、プログラムからDB接続時にコネクション取得を実施しています。
    社内では問題なく、客先で遅い理由は提示いただいた情報からでは判断できませんが、
    おそらく初回起動時にプリコンパイルが走っていると思われます。

    http://msdn.microsoft.com/ja-jp/library/399f057w(VS.80).aspx
    http://msdn.microsoft.com/ja-jp/library/cc671425.aspx
    あたりの情報を参考にプリコンパイルを実施しておくと多少改善すると思われます。

    あとは、ADがらみで次のような情報を書かれているBlogもあります。
    http://d.hatena.ne.jp/YokoKen/20081114/1226630162

    また、現在対応されているようなIEリフレッシュに近いものとして
    http://natchan-develop.seesaa.net/article/13322326.html
    http://ino1970.blog119.fc2.com/blog-entry-94.html
    といった対応をされている方もいます。

    私の過去の対応では、空起動用の軽いページを設けて、キックするような対応をしたこともあります。
    検索エンジンで「ASP.NET 初回起動」というキーワードを含めて検索をすると
    情報がいろいろ出てきますので、プロジェクトの特徴のワードを含めて検索すると
    該当する情報が手に入るかもしれません。

    2011年12月17日 1:21
  • ymtyさん、返信ありがとうございます。

    プリコンパイルに関しては、情報は集めております。

    自分が担当していないシステムで同様の現象が出ており、

    プリコンパイルを行って納品を行っております。

    プリコンパイルにしても社内みたく数秒で起動せず、数分掛かったみたいです。

    そのシステムもお客様と相談し、空起動用のページを起動するようにして、一時回避を行っています。

    今現在、分かっている事は、w3wp.exeの起動が異様に遅いということです。

    IISプロセスの起動の前にコンパイルを行っているのであれば、

    .Net Frameworkの起動が遅いということになるような気がします。

    .Net Frameworkまわりも調査したいと思います。

    後、サーバーのイベントログをみておりますが、ASPと.Net Frameworkまわりのエラーは発生していない状況です。

     

    2011年12月19日 0:58
  • こんにちは。

    「一時回避策は、分かっていますが、セキュリティ上問題なので、解決したいと思っております」

    ということですが、回避する対象の処理等にww3wpの起動(もしくは初回のリクエスト処理)を遅くするような何かがあるということが判明している?
    と考えてよいのでしょうか?

    とすれば、その処理等にかかる時間分を、事前コンパイルなどで稼げるかという事になる気がします。
    これで結果が期待できるのかな?っと疑問が浮かんでききました。

    やっぱり、問題のプロセス起因で何かを考えていく必要があるんじゃないかなぁと思います。

     

    後は、

    イベントログで、ASP.NET , .Net Framework 以外もチェックしてみる。

    .NET CLR Jit (かな)あたりのカウンタを見て、社内とお客様先との違いを見てみるとかでも何かつかめるかもしれませんね。一応GCなども見てみるとよいかもしれません。

    長時間リサイクルせずに使っていてコネクションプールがうまく使われていないとかがあるかもしれません。(コード調査)
    machine.configなどのprocessModelやhttpRuntimeの設定も比較してみるとよいかもしれません。
    ネットワークをモニタリングして、応答時間を見てみる手も有効かもしれません。
    メモリやCPUの圧迫が無いかも見ておく必要はあると思います。
    (もし、仮想環境であれば、ホストのメモリCPUも含めて監視する必要があると思います)

     

    もし、事前コンパイル済みであるのに、アイドル状態からの起動が遅いとすれば、環境(マシンリソース含む)かコード(やクエリー)に問題があるような気がします。

    2011年12月19日 2:11
  • Keiichi Oumiさん、返信ありがとうございます。

    > 「一時回避策は、分かっていますが、セキュリティ上問題なので、解決したいと思っております」

    > ということですが、回避する対象の処理等にww3wpの起動(もしくは初回のリクエスト処理)を遅くするような何かがあるということが判明している?
    > と考えてよいのでしょうか?

    はい。

    なので、w3wpの起動を疑っているのですが、何が悪さをしているのか分からない状況になっております。

    メモリとCPUの使用率は確認しており、特に問題ないと思っております。

    > .NET CLR Jit (かな)あたりのカウンタを見て、社内とお客様先との違いを見てみるとかでも何かつかめるかもしれませんね。

    確認してみます。

    当方でも調べてみたのですが、aspnet.configに<generatePublisherEvidence enabled="false"/>を

    追加してみて状況をみてみたいと思います。

    2011年12月20日 0:55
  • こんにちは。

    えっと、「回避する対象の処理」が判明しているのであれば、疑うのは、w3wpではなくて、その「回避する対象の処理」じゃないかと思うのですが。

    たとえば、

    ・DBの操作
    ・ログインや証明書の操作
    ・オブジェクトの過度な生成
    ・外部サ-ビスへの接続
    ・なにがしかのIO
    ・etc

    などなどの処理があって、これらが無いか、もしくは自社ではさくっと動作する。
    ということだとすれば、環境や各種外部リソースのキャパシティなどに問題があるっていう事(もしくは問題を引き起こす要因がある)じゃないかなぁと思うのですが。

    メモリやCPUに問題がないっていうことであれば、jit コンパイルそのものに問題がある感じでもなさそうですし・・・(これは言い切れないですが)

    確認用のデータのINDEXが違うとか量が半端ないとか、初期データのロードをしているとか、通信を伴う何かで問題(遅い)とか・・・ないかなぁ。
    AppDomain をいじくりまわす何かが実は仕込んであるとかだと、話は全然かわっちゃいますし・・・
    動的コンパイルだとしても、全コードがコンパイルされたりしないわけですし(ちょっと記憶が薄い)・・・
    Global.asax で何か重い処理とかやってないのかなぁ。

    実際に何をやっているか、謎が多いので、てよくわかりませんね・・・頭もないですが(TT)

    2011年12月20日 6:04
  • Keiichi Oumiさん返信ありがとうございます。

    > 「回避する対象の処理」が判明しているのであれば、疑うのは、w3wpではなくて、その「回避する対象の処理」じゃないかと思うのですが。

    > ・DBの操作
    > ・ログインや証明書の操作
    > ・オブジェクトの過度な生成
    > ・外部サ-ビスへの接続
    > ・なにがしかのIO
    > ・etc

    >> ③モジュールの記載がないプログラムを作成

    現象が、改善されない状況です。

    なので、w3wp疑っているのです。

    間違っているのかな・・・。

     

    2011年12月21日 0:22
  • aspnet.configに<generatePublisherEvidence enabled="false"/>を
    追加することにより解決?に至りました。

    現在、様子をみている状態です。

     

    • 回答としてマーク 碧流 2012年1月4日 0:47
    2011年12月22日 10:03