PHP on Windows ガイドライン

Transcription

1 PHP on Windows ガドラン ドラフト版 ~ 第 3 章 : ゕプリケーション配置後の問題解決 Tips 本ガドランは各章の先行ドラフト版公開を行い 全章の公開後 正式版文書としてまとめを行 い 再度公開します 第 1 版 2011/02 日本マクロソフト株式会社 免責事項 : このドキュメントの内容は情報提供のみを目的としており 明示または黙示に関わらず これらの情報についてマクロソフトはいかなる責任も負わないものとします このドキュメントに記載されている情報 (URL 等のンターネット Web サトに関する情報を含む ) は 将来予告なしに変更することがあります お客様がこのドキュメントを運用した結果の影響については お客様が負うものとします 別途記載されていない場合 このドキュメントで例として挙げられている企業 組織 製品 ドメン名 電子メールゕドレス ロゴ 人物 地名 およびベントは 架空のものです それらが いずれかの実際の企業 組織 製品 ドメン名 電子メールゕドレス ロゴ 人物 地名 あるいはベントを指していることはなく そのように解釈されるべきではありません お客様ご自身の責任において 適用されるすべての著作権関連法規に従ったご使用を願います

2 第 3 章 ゕプリケーション配置後の問題解決 Tips PHP ゕプリケーションを構築あるいは開発する方は Windows 風な管理方法や問題解決方法から しばらく離れた方も結構いらっしゃると思います でも Windows 2000 や Windows XP のユーザ ー ンターフェースには親しみがある方も多いとの考えのもと 特に Windows/IIS 上の PHP 動 作環境をよりわかりやすくするためにこの章で PHP 向けテクニックと後半のコラムで Windows で の一般論としての問題解決手法の基本的な要素を整理していきます なお この章では多くの方が試されるであろうクラ ゕント環境 Windows 7 で説明をします 基本的にサーバーでも同じ Tips が使用できます Web サーバー IIS が返すエラー処理 エラー処理と PHP という二つのキーワードを並べるとコード記述上の 例外処理 のことを思い 浮かべると思いますが ここではそうではなく IIS が返すサーバー側でのエラーについて書きます 図 1 エラーには Web サーバーが返すものとゕプリのエラーがある 一例をあげると フゔ ルが見つかりませんでした の意味である 404 エラーもその一つです PHP ゕプリケーションを利用している場合のこのような基本的なサーバーで発生したエラーの解析 が IIS の場合は表面上の現象を見て最初苦労するかもしれません IIS7 では PHP のエラー診断においてエラー状態に割り込むことで一般的な HTTP ステータスコ ードに対してエラーを表示するページへのリダ レクト処理を提供します 既定では詳細なエラーページはサーバー上で実行した場合のみ表示され リモートのクラ ゕント のブラウザーからの接続の場合にはより情報の少ないエラーページが表示されます サーバー上では 1

3 様々な補足データが表示されることで解析が容易になるので便利なのですが リモートではサーバーの設定情報などが見えるとセキュリテゖ面で問題になるため この設計になっています 開発環境においてはリモートでも詳細エラーを表示するように設定することも可能です 以前のバージョンと違い IIS7 はほとんどすべてのエラーに対してかなり詳細なエラーをページとして返します 最低でもリクエストに関する情報およびエラーの内容 これにはエラーが発生したモジュール リクエスト処理のフローのどこで発生したかなどを含みます 無論 より親切な UI を提供するためにカスタマズしたページを表示する設定も可能です ゕプリケーションやランタムではなく IIS7 そのものあるいは IIS7 の標準付属のモジュールに関しては以前に比べるとかなり改善された内容の解決策も表示されます 以下ではこのようなケースで実際にどのように対処するのかを順番に説明します サンプルゕプリケーションの作成 まずはエラー解析を行うための操作用のサンプルを用意しましょう ゕプリケーションのデゖレクトリ作成 エクスプローラーで c:\inetpub を開きます TroubleShootPHP というフォルダーを作成します サンプルサトの作成 スタートメニューの検索ボックスで inetmgr と入力し [Enter] キーを押し IIS の管理ツールである IIS マネージャーを起動します [ サト ] が表示されるところまで左のツリーを展開し クリックして選択します 右の操作ペンで [Web サトの追加 ] をクリックします 4. 以下を入力し [OK] します サト名 :TroubleShootPHP 物理パス :c:\inetpub\troubleshootphp ポート :80 を 84 に変更 [ 参照 ] ボタンから開くダゕログ内でフォルダーの新規作成ができます ゕプリケーションの権限設定 エクスプローラーで TroubleShootPHP フォルダーを右クリックし [ プロパテゖ ] を開き ます [ セキュリテゖ ] タブを開きます [ 編集 ] をクリックし [ 追加 ] をクリックします 2

4 4. テキストボックスに IIS APPPOOL\TroubleShootPHP と入力し OK をクリックします この点は後で解説しますのでここではこの通り実行してください 5. 既定で 読み取りと実行 の権限になっていますのでそのまま [OK] をクリックします 6. [プロパテゖ] ページを [OK] して終了します サンプルページの作成 ゕクセサリーから [メモ帳] を開き <?php echo("hello!");?> と入力し デスクトップに hello.php として保存します この時 hello.php.txt になっていないように注意 ｃ:\inetpub\troubleshootphp フォルダーに hello.php フゔ ルをコピーします Internet Explorer を起動し にゕクセスします 図 2 サンプル ページの実行結果 3

5 PHP エラーメッセージの表示を変更する IIS7 の機能を使って PHP ゕプリケーションで Web サーバーが出すエラーをリダ レクト処理 する動作をまずは体験しましょう 404 エラーを体験しましょう Internet Explorer を起動し にゕクセスします このページは明らかに存在しないので 404 のエラーになります 図 3 IIS7 の詳細エラーの表示 IIS7 が ンストールされているマシン上での実行なので詳細が表示されました リモートからゕク セスした場合には下記のようなエラーになります 図 4 IIS7 のカスタムエラーの表示 4

6 詳細のエラー表示の方を見ると 下記の情報の掲載があります エラー情報の詳細 エラーを発したモジュール ハンドラー PHP 内部エラーコード =File not found URL と IIS の認識した物理パス 実行したユーザーが掲載されています 可能性のある原因 今回は原因が明らかなのですが この欄には原因の可能性として以下が列記されています 指定されたデゖレクトリまたはフゔ ルは Web サーバーに存在しません 正解 URL に誤字が含まれています URLScan などのカスタム フゖルターやモジュールによってフゔ ルへのゕクセスが制限されています URLScan は以前から存在するセキュリテゖ対策ツールです 対処方法 コンテンツを作成する あるいは URL を確認するように対処方法が提示されています このように 今までの IIS で不明瞭とされていた実行ユーザーや内部処理のタ ミングなどの情報 がこの詳細エラーを見るだけでわかります メモ IIS7 の匿名ユーザーの実行について書いておきます この情報だけだと Windows のなんと いうゕカウントで実行されたのかがわからないで困る人もいると思います IIS マネージャーで認証というゕ コンをダブルクリックしましょう 注意点は サーバー名を選 択している場合はサーバー全体の既定値 TroubleShootPHP サ トを選択した状態で認証設定を開 くとこのサ トにのみ有効な設定の変更になる点です この場合はサ トを選択した状態で実行しま しょう 図 5 サ トを選択した状態の認証ゕ コン 5

7 IIS を既定の設定で ンストールした場合には以下の３つの認証方式が存在するはずです 匿名 認証 をクリックし 操作ペ ンから [編集] をクリックします 図 6 IIS マシンにセットゕップされている認証方式の一覧 そうすると 下記のダ ゕログが表示され IUSR というビルト ンゕカウント IIS7 から登場 で実行されていることがわかります ご覧のように変更することも可能です IUSR は IIS_IUSRS グループに所属しています 図 7 匿名認証の実行ゕカウント設定画面 でも実際に PHP フゔ ルを実行するのは IIS7 では実は IIS6 から登場したゕプリケーション プールの設定ユーザーになりますので IIS5 のころとはここが変わっています hello.php を動作さ せて php-cgi.exe の挙動をタスクマネージャーで見てみましょう Internet Explorer を起動し にゕクセスします タスクマネージャーを起動してプロセスタブを見てみましょう 図 8 タスクマネージャーで php-cgi.exe の実行状況を見る 6

8 ゕプリケーション プール名と同じユーザー名になっているのがわかります これが実は ApplicationPoolIdentity という設定がゕプリケーションプールで指定されている場合の動作なので す 今の IIS では匿名認証で指定されたユーザーではなく ゕプリケーション プールの指定ゕカウ ントを使うのです メモ IIS7 ではゕプリケーション間の分離性を保つためにサ トを作成した時の既定で同名のゕプ リケーション プールが作成されます したがって サ ト名 ゕプリケーション プール名です 今回のサンプルでは既定のままサ ト作成時に同名のゕプリケーション プールを作成する操作に なっています 図 9 ゕプリケーションプールの設定状況 文字通り ゕプリケーション プール名のゕカウント TroubleShootPHP という普通のゕカウント とは違うゕプリケーション実行用の内部ゕカウントが作成され 利用されます これでフォルダーの ゕクセス権設定を行ったところの手順が理解できましたでしょうか メモ ApplicationPoolIdentity 設定が存在する理由はセキュリテゖです 他の権限と比べ サ トで 利用するフォルダーのみに明示的にゕクセス権をふる必要があり 今までよりも制限が厳しくなって います IIS APPPOOL\ゕカウント名 で指定するこのゕカウントがリモート マシンにあるリソース にゕクセスする場合には Network Service ゕカウント IIS6 での既定 と同じ動きをします メモ ApplicationPoolIdentity 設定については英語ですが 以下に解説が載っています Application Pool Identities 英語 7

9 違う挙動を見てみましょう Web PI などを使用して PHP の環境を構築するとここまでのような挙動になるのですが.php の 拡張子の入った URL のリクエストを受け付けた時にハンドラー 特定拡張子のフゔ ルを処理する 紐付 が正しく行われていないと違う挙動になります IIS マネージャーを起動します TroubleShootPHP サ トをツリーで選択します ワークスペース内で [ハンドラー マッピング] のゕ コンを探し ダブル クリックします 図 10 ハンドラーマッピングの実行 4. PHPｘｘ_via_FastCGI というマッピングを探し 操作ペ ンで [編集] を実行します それまでの作業によって複数バージョンある場合もあります 詳細エラーで表示されたハン ドラーを参照し それを選択します 図 11 モジュール マップの設定画面 5. [要求の制限] をクリックし マップ タブの内容を確認します 6. 要求のマップ先が次の場合のみ~ チェックボックスを外して [OK] します この際に php-cgi.exe が Program Files の下にある場合は全体を で囲ってください これはパスに空白を含んだ場合のチェックをしているためです 8

10 7. Internet Explorer を起動し にゕクセスします 今度は全然違うページ表示になったはずです 図 12 ハンドラーマッピングが無い状態の 404 エラー さらに Internet Explorer の場合であれば [ツール] [ ンターネット オプション] から [詳細 設定] タブを開き 設定の中で HTTP エラーメッセージを簡易表示する のチェックを外すと さ らに違う画面になります 図 13 Internet Explorer の HTTP エラー簡易表示オフ このように PHP 拡張子を持ったフゔ ルをゕクセスする場合の IIS や Internet Explorer の様々 な設定によってエラー画面の出方が違うので それで戸惑うことが多いのですが 原理はここまでに 説明した通りです 9

11 ゕクセス拒否が起きている場合のエラーを体験しましょう 次に Windows のフゔ ルシステムのゕクセス権限が適切でない場合の挙動を見てみましょう エクスプローラーを開き hello.php をコピーし denied.php と名前をつけます denied.php フゔ ルを選択し 右クリックして [プロパテゖ] を開きます [セキュリテゖ] タブを開き [詳細設定] をクリックします 4. [ゕクセス許可の変更] をクリックします 5. [このオブジェクトの親からの継承可能なゕクセス許可を含める] のチェックを外します 6. Windows セキュリテゖ ダ ゕログが表示されるので [削除] をクリックします これでどのユーザーからもゕクセスできない状態になります 7. [OK] をクリックし 詳細設定 を閉じます 8. Windows セキュリテゖ ダ ゕログで [はい] をクリックします 9. [OK] をクリックし 詳細設定 を閉じます 10. [OK] をクリックし プロパテゖ を閉じます 1 Internet Explorer を起動し にゕクセスします 図 14 ゕクセス権限が無い場合に表示されるエラー メモ 現在の Windows フゔ ル システムではゕクセス権の親フォルダーから継承が行われるよう になっているため 表面上で意図しない動きを体験することが多いです ここで指定しているように 継承を切ることも可能なので icacls コマンド 下記が使用例 で当該オブジェクトがどういう権限設 定になっているかを確認した方が気持ちのいい人も結構いらっしゃるかもしれません icacls c: inetpub TroubleShootPHP 10

12 ゕプリケーションエラーを診断するための PHP エラーメッセージの有効化 ここまではフゔ ルの存在可否やゕクセス権といった OS レベルの問題があった場合のサーバー が返すエラーをみてきました これら以外のほとんどのエラー発生の条件としてはゕプリケーション の記述レベルでのエラーであり IIS7 の表示する詳細エラーではこのレベルのエラーを診断する上で 必要な情報は表示されません よくある例としてはスクリプトの記述ミスやスクリプトの解釈エラーがあります この場合には IIS7 の詳細エラーを参照するのではなく PHP が提供するエラーを参照する必要があります 既定 では PHP はサーバーの詳細な情報を表示しないようになっており レスポンスにこのような詳細な エラー情報は含めません PHP スクリプト エラーを発生させてみる ゕクセサリーから [メモ帳] を開き 以下の間違ったスクリプトを入力し デスクトップに error.php として保存します この時 error.php.txt になっていないように注意 <?php echo( script error?> ｃ:\inetpub\troubleshootphp フォルダーに error.php フゔ ルをコピーします Internet Explorer を起動し にゕクセスします 図 15 IIS7 が表示する詳細エラー IIS7 は 500 内部サーバーエラーを返します これは PHP がエラー詳細を返す設定になっていな いため IIS7 は一般的なエラーを表示することしかできないため このエラーページが表示されます 確かにハンドラーの情報から PHP を処理していてエラーが出たことはわかるのですが 内部の詳細 情報はこれではわかりません 11

13 レスポンスにエラーを返すように PHP の設定を変更する まずは PHP がどこに ンストールされているかを確認します IIS マネージャーを開きます TroubleShootPHP サ トを選択後 [ハンドラー マッピング] をダブルクリックします ハンドラー マッピングで PHP のマッピングを探します 図 16 ハンドラー マッピングの一覧 この環境には二つのバージョンの PHP が設定されていますので上記のような表示になります 4. プロパテゖを開いてパスを確認します 図 17 PHP の実行可能フゔ ルのパスを確認する 5. エクスプローラーで確認したパス 例 c:\program files\php\v5.3\php-cgi.exe を開く 6. メモ帳を管理者実行で開きます 7. 同パスにある Php.ini フゔ ルをメモ帳内から開きます 8. display_errors デゖレクテゖブを探し Off を On に変更して保存します 9. Internet Explorer を起動し にゕクセスします より詳細なエラーが表示されるようになります 12

14 図 18 PHP の詳細エラーが表示された状態 メモ PHP ではデフォルトのエラー処理の動きをカスタマ ズ あるいは完全に上書きするオプショ ンを提供しています より詳細な情報は を参照ください 13

15 リクエストの状態を調べて エラーの診断を行う Web ゕプリケーションの問題に対処する上で レスポンスのエラー内容を確認する方法ではエラー を診断することができないケースがあります 下記のようなケースです どの URL がエラーを起こしているかわからない なかなか再現しない問題 エラーが特定の操作内容や操作している条件に依存している 本番環境でしか起きない こういうケースでは問題を解決するのが本当に難しくなりますし そもそも診断をする上でも困難 であることは間違いないでしょう Web サーバーのリクエスト ログやエラー ログを確認することで いずれ URL を特定できるかもしれませんが 何故問題が起きているのかを特定するまでには相当苦 労することでしょう IIS7 は 失敗した要求トレース という新しいトレース機能があり このような問題に対処できる ようになっています 特定条件に合致したリクエストに関して自動的にトレースを取得することがで きます PHP ゕプリケーションの場合でもリクエスト データやレスポンス データを取得するのに役 に立ちます これらの情報は問題解決をもっと楽にしてくれるはずです もう一つ 解決が非常に難しいケースがあります それは処理がハングあるいはループに入ってし まっているようなリクエストの特定です 下記がよくある原因です フゔ ルの IO が排他処理で止まっている リモートの Web サーバーやデータベースの応答が非常に遅い プログラムのロジックにバグがあり 無限ループに突入している 無限ループに突入し さらに CPU 高負荷 メモリー不足を引き起こしている 特定メモリー空間など共有リソースに関してデッドロックが発生している これらのような事象が発生した場合にはリクエストが非常に長い時間滞留し ユーザー操作がタ ムゕウトする あるいはゕプリケーションのレスポンス低下 最悪のケースではサーバー全体の挙動 に影響を与えることもあります IIS7 にはリクエストの実行状態を確認する機能と API があります このことにより 長時間実行 しているリクエストを容易にとらえることが可能です 14

16 原因不明 再現困難な問題を失敗した要求トレースで診断する 失敗した要求トレース FRT Failed Request Tracing は断続的に起こる問題や再現困難な問題 を診断する上で有効な機能です リクエストやレスポンスに関する詳細情報 IIS モジュールが出力 する有用な情報がトレースに記録され 診断に利用できます それでは FRT を使用して PHP ゕプリケーションの特定ページでトレースを取得してみましょう メモ FRT は本番環境でも使えるように設計されており 従来の Windows のトレース機能に比べ ると相当軽量 リソース面で 10%程度のオーバーヘッド に取得できる上 条件指定でトレース負荷 を下げることもできます 断続的に問題が発生するようなテストページの作成 ユーザー入力が特定の入力値だった場合に失敗するようなテスト ページを作ります [ゕクセサリー] から [メモ帳] を開き 下記を入力し デスクトップに products.php とし て保存します この時 products.php.txt になっていないように注意 <?php if($_get['productid'] == "5") { header("http/0 500 Server Error"); die("incorrect product id!"); } else { echo("product page"); }?> ｃ:\inetpub\troubleshootphp フォルダーに products.php フゔ ルをコピーします Internet Explorer を起動し にゕクセス します 図 19 正常に終了した場合の表示 15

17 失敗した要求トレースを有効化する この手順を実行する前に IIS7 のコンポーネントで 追跡 が ンストールされていることを確認す る必要があります ンストールされていない場合にはゕ コンが存在しません IIS マネージャーを開きます 左のツリーから TroubleShootPHP サ トをクリックします 操作ペ ンから [失敗した要求トレース...] をクリックします 4. [有効にする] チェックボックスをクリックし [OK] をクリックして有効化します メモ FRT の出力するフゔ ル数は条件に合致したリクエスト１つに対して１つになるのでもし本番 環境で利用する場合には再現トレースをきちんと取得できる数を設定する必要があるので既定値をい つも使うべきではないことを認識しておきましょう また デゖスクの空き容量にも注意して適切な 値を設定すべきです 要求トレースの規則を設定する IIS マネージャーを開きます 左のツリーから TroubleShootPHP サ トをクリックします 失敗した要求トレースの規則 をダブル クリックします 4. 操作ペ ンから [追加] をクリックします 5. すべてのコンテンツ を選択したまま [次へ] をクリックします ｃ 図 20 FRT のルールの作成 コンテンツの条件 6. トレース条件で状態コードのチェック ボックスをチェックし と入力します HTML のエラー コードで実際にエラーなのは 404 フゔ ルが見つからない などの 400 以 上のエラー番号の場合なので 500 番台も含めてトレースを残したい場合にはこのように範囲 で指定します 実は正常な場合もトレースを取得可能なので 200 も設定できます 16

18 図 21 FRT のルールの作成 エラーの条件 7. [次へ] をクリックします 8. トレース プロバ ダーで詳細設定も可能ですが ここではそのまま [終了] をクリックします この部分では内部的な ベントの対象を絞っているので PHP の場合 ASP や ASPNET は不 要ですが このサンプルではそのままにしておきましょう 図 22 FRT のルールの作成 トレース プロバ ダー 実際にゕプリケーションをリクエストする 実際には複数のユーザーが Web サーバーにリクエストを行うのですが ここではテスト的に自分 で複数のリクエストを行いましょう Internet Explorer を起動し にゕクセスします にゕクセスします 17

19 にゕクセスします このページはエラー になるはずです 4. スタート メニューから [コマンド プロンプト] を管理者実行で開きます 5. 以下を入力します %windir% system32 inetsrv appcmd.exe list traces /site.name:"troubleshootingphp" 6. 下記のような出力が得られるはずです 図 23 AppCmd コマンドでトレース出力を確認 メモ この出力でわかることは /products.php?productid=5 のリクエストが 1 件 500 エラー を返したことがわかります 他のクエリー ストリングの場合にはエラーが発生していないことから productid=5 の入力が行われた場合にのみエラーが発生するという仮説が立てられます トレース ログの中身を見て詳細を検証する １ では実際に出力されたトレース ログを見てさらに診断を続けます スタート メニューから [コマンド プロンプト] を管理者実行で開きます 以下を入力します %windir% system32 inetsrv appcmd.exe list traces "TroubleshootingPhp/fr00000xml" /text:* 下記のような出力が得られるはずです 図 24 トレース内容の詳細をコマンドで表示 18

20 トレース ログの中身を見て詳細を検証する 2 では実際に出力されたトレース ログを開いて見ることにします トレースの実体は FRT を有効化 したダ ゕログにあったように c:\inetpub\logs\failedreqlogfiles\w3svc2 フォルダーに置か れます トレースの出力は XML 形式のフゔ ルです XSLT フゔ ルで書式を整えています なお IIS ではサ ト単位でこのサブフォルダーを管理するので この環境では既定の Web サ トに続く 2 番目のサ トとして TroubleShootPHP を作成しているため W3SVC2 フォルダーを使 用しています W3C のログに関しても同じです エクスプローラーで W3SVC2 フォルダーを開きます Fr0000xml フゔ ルをダブル クリックしてブラウザーで開きます 図 25 FRT の出力したトレース Request Summary メモ Request Summary タブではリクエストに関しての基本的な情報が得られます FastCgiModule がエラーを報告したことがまず一見してわかり ハンドラーで PHP しかセットして いない環境の場合 PHP コンテンツで問題が発生したことがわかります また実行に 20ms かかっ たことなども把握できます Compact View タブをクリックして開きます 実際に IIS がどのようにリクエストを処理したかを各 IIS モジュールが実行順でログしてく れます GENERAL_REQUEST_START ベントではリクエストに関する URL 動詞 実行サ ト 実行ゕプリケーション プール などの基礎的な情報がログされます 19

21 GENERAL_REQUEST_HEADERS ベントではリクエストに含まれる完全なヘッダー情報 が記録されます GENERAL_RESPONSE_HEADERS, GENERAL_RESPONSE_ENTITY_BUFFER ベ ントでは完全なレスポンス ヘッダー情報および レスポンスの BODY 情報が格納されていま す このケースでは実際の画面挙動を再現できていない管理者は incorrect product id! が ユーザーのブラウザーに戻されたことがわかります 図 26 FRT の出力したトレース Compact View メモ 確認しなかった Request Details タブはリクエストが実行された順番を階層的な表示で説 明してくれます また FastCgiModule などのフゖルターにより 表示件数をフゖルターすること ができます Performance View ではどのパートが最も時間を要したのかも判断できるように実行 時間に注目したビューになっています 4. すべてのウゖンドウを閉じます ハングしているリクエストを実行状態から検査して見つける 長時間実行されているリクエストは異常終了せずに エラーも何かのリソースがタ ムゕウトする まで発生しないために発見および解決が難しい問題の一つです IIS7 からはリクエストの実行状態 情報を管理者が様々な方法で利用できるようにしたため 非常に簡単に見つけることができます 無限ループするようなサンプル ページを作成します ゕクセサリーから [メモ帳] を開き 下記を入力し デスクトップに loop.php として保存し ます この時 loop.php.txt になっていないように注意 <?php 20

22 $j = 0; for($i=0; $i<10; $j = $i + 1) { $j = $j + 1; } echo("done");?> 太字の部分にタ プミスがあり 無限ループする想定です ｃ:\inetpub\troubleshootphp フォルダーに loop.php フゔ ルをコピーします Internet Explorer を起動し にゕクセスします 無限ループするコードになっているので Internet Explorer はビジー状態になり タ ムゕウ トするまで応答が無くなります 同時に CPU 負荷は非常に高くなります IIS マネージャーでリクエスト実行状態を確認する IIS マネージャーを開きます 左のツリーからサーバー名のノードをクリックします IIS グループにある [ワーカープロセス] をダブル クリックして開きます ｖ ｖ 図 27 リクエストの実行状態を IIS マネージャーで確認 4. TroubleShootPHP をダブル クリックします 5. 何も表示されない場合はもう既にタ ムゕウトした可能性があるので Internet Explorer に 戻り 最新の情報に更新 あるいは F5 キー を実行してください 21

23 6. 操作ペ ンにある [現在の要求の表示] をクリックします 図 28 実行中のリクエストを IIS マネージャーで確認 メモ 一覧中に当該ワーカー プロセス内で現在実行されているリクエストが表示されます URL 動 詞 実行クラ ゕント モジュール名 PHP であれば FastCgiModule そして経過時間が表示され ます この画面は自動的に更新されないので F5 キーで更新をする必要があります 同じ状態を維持 し 経過時間だけ大きくなるリクエストはハングしている可能性があると言えます 意外にフゖルタ ーの入力が可能な点を見逃しがちなので リクエストが多い場合には活用しましょう コマンドでリクエスト実行状態を確認する IIS マネージャーで見ることができるのは非常に便利な機能であり Windows に慣れたユーザー からは好評ですが 同じことがコマンドでもできますのでご紹介しておきます スタート メニューから [コマンド プロンプト] を管理者実行で開きます Internet Explorer を起動し にゕクセスします コマンド プロンプトに切り替え 以下を入力します %windir% system32 inetsrv appcmd.exe list requests /elapsed: 下記のような出力が得られるはずです 図 29 コマンドで実行中のリクエストを確認する IIS マネージャーで確認できる内容と全く同じ内容をこのように簡単に確認できますので時々実行 するタスクを仕掛けておくことで長時間実行しているリクエストを早い段階で捕捉することができる でしょう 22

24 Appcmd.exe の一歩進んだ使い方 フゖルターをかける点においては IIS マネージャーよりも Appcmd を使用する方が柔軟です 特定のページ URL だけ確認する 特定のページ URL だけに絞りたい場合には以下のように入力します %windir% system32 inetsrv appcmd.exe list requests /url:/loop.php /elapsed:1000 Appcmd はパ プすることが可能なので 長いリクエストが存在するゕプリケーションを検知 したい場合には下記のように実行します %windir% system32 inetsrv appcmd.exe list requests /elapsed:1000 /xml %windir% system32 inetsrv appcmd list apps /in 結果は以下のようになります APP "TroubleShootPHP/" (applicationpool:troubleshootphp) さらにはパ プ機能を生かして 問題が発生しているプールに対して再起動するようなことも 可能で たとえば下記のように実行します %windir% system32 inetsrv appcmd.exe list requests /elapsed:1000 /xml %windir% system32 inetsrv appcmd list apppools /in /xml %windir% system32 inetsrv appcmd recycle apppools /in 結果は以下のようになります "TroubleshootingPhp" successfully recycled メモ Appcmd のパ プ処理に興味がある方は 以下の英語記事が参考になります s-easily-with-appcmd-command-piping.aspx. 以上で PHP を利用する環境で IIS7 の様々な機能をトラブルシューテゖングで活用する方法を説明 してきました IIS7 には面白い診断機能がいくつも備わっているのでぜひフル活用いただけようにお 願いします 23

25 コラム Windows でよく使われる問題解析ツール しばらく Windows を離れていた人にもわかるように Windows ばかりやってきた著者が最大限 努力して書いてみます いやいやこれは必要ないと思う人は読み飛ばしてください システムのログ /var/log はどこなの いう声が今にも聞こえてきそうです Windows ではよく言われるよ うに GUI ンターフェースがほぼ存在し 場合によってコマンドでも色々なことができます 例え ばシステムのログと言えば ベント ビューゕー というツールを使用します スタートメニュー の検索ボックスに eventvwr と入力して Enter キーを押します ベント ビューゕーは OS のリリースとともに順次進化を遂げ Windows Vista や Windows 7 では下図のような画面に様変わりしています 図 30 Windows 7 の ベント ビューゕー 従来の Windows では 3 大ログとよく言われていた システム ゕプリケーション セキュリテゖ のログに集約されてしまっていたのですが 今の Windows ではフゖルターがかかるビューも存在し ゕプリケーション独自のログを出力する方法も柔軟になりました テキストではないのですが 今の Windows では各 ベントを XML 形式で保持しているため 非 常に柔軟な情報採取ができるように成長しています 24

26 図 31 Windows 7 の ベント例 またサブスクリプション機能を使用すれば 複数のマシンからあるマシンにログを集めることも簡 単にできるようになっており 今までの Windows のようにそれぞれのマシンでジョブをセットして それぞれの出力を集める必要もなくなっています システム情報 状態情報 今度は /proc は? に行ってみましょう これに近いのは msinfo3exe とタスクマネージャ ーで パフォーマンスモニターはさらに詳細を知りたい時に使用します システムに関する情報は 基本的な情報をコンピュータの右クリックすることで開くプロパテゖでも表示されますが msinfo3exe を実行することでより詳細な情報を見ることができます Msinfo3exe はスタート メニューの検索ボックスから msinfo32 と入力し Enter キーで実行できます 図 32 Windows 7 の msinfo3exe 25

27 さて CPU の利用率やメモリーの使用状況などはタスクマネージャーでおおまかにチェックするこ とができます Ctrl+Alt+Delete を押し タスクマネージャーの起動とやるか 画面下のタスクバー 上で右クリックしても起動できます もっと慣れた管理者だと検索ボックスに taskmgr と入力して実 行する人もいるでしょう 図 33 タスクマネージャーの画面 お奨めはパフォーマンスタブの右下の方にあるリソースモニターです リソースモニターではどん な確認作業でも知りたい CPU メモリー デゖスク IO ネットワークを利用している詳細な単位で 見ることができるので今までの Windows に比べると何が起きているかわかりやすくなりました 図 34 リソースモニターの起動画面 26

28 さて 記録を残したいとか もっと詳細に調査をしたい場合 Windows では歴史的にパフォーマ ンスモニターというものを使います 検索ボックスに perfmon と入力して実行しましょう 図 35 パフォーマンスモニターとカウンターの追加 初期状態では Processor Time のグラフを表示していますが Windows ではほぼすべてのプログ ラムがパフォーマンスカウンターへの状態情報提供を行っているので 様々な情報をグラフで表示す るあるいはフゔ ルに記録を残すことができます ここまでほぼコマンド起動をしてきたのですが これらのツールは [コントロール パネル] [管理ツール] の中からゕ コンをダブルクリックすることでも実行可能です 27