ヘッダーをスキップ
Oracle Application Serverリリース・ノート
10gリリース2（10.1.2）for HP-UX PA-RISC (64-bit)
B25637-05
  目次
目次
戻る
戻る 		 次へ
次へ		  

21 Oracle COREid Federation

この章では、Oracle COREid Federationに関する問題について説明します。この章の内容は次のとおりです。

21.1 一般的な問題と対処方法

この項では、一般的な問題とその対処方法について説明します。この項の内容は次のとおりです。

21.1.1 Oracle COREid FederationのWebプロキシのチューニング

ここでは、Oracle COREid FederationのWebプロキシをチューニングする方法を説明します。この項の内容は次のとおりです。

21.1.1.1 背景

Oracle COREid Federation製品は、主に次の2つのコンポーネントで構成されています。

  1. フェデレーション・サーバー（Apache Tomcatサーブレット・コンテナとともにパッケージされているJ2EEアプリケーション）

    および

  2. Webプロキシ（Apache 2.0 HTTPサーバーに基づき、クライアント証明書認証についてフェデレーション・サーバーと通信する機能を含む）

Oracle COREid Federationのパイロットおよびテスト段階から本番デプロイにサイトを移動する際は、パフォーマンスに留意することが重要です。特に次の点に注意してください。

  • スケーラビリティ

  • 信頼性と障害処理

これらの領域では、リクエスト処理タスクを実行するApache 2.0 HTTPサーバーのチューニングが不可欠です。このドキュメントでは、Apacheプロセス・モデル、チューニング・パラメータ、およびOracle COREid Federationのデプロイにおけるパフォーマンス上の考慮事項について説明します。


注意:

Apache 2.0 HTTPサーバーはサード・パーティ製品であり、Oracle COREid Federationのデプロイ、およびそのサポートの文脈でのみ紹介されます。Apache 2.0 HTTPサーバーの詳細な製品情報は、Apache Software Foundationに問い合せてください。

21.1.1.2 Apache MPMモデル

Apache MPMには様々なモデルが用意されています。

21.1.1.2.1 Microsoft WindowsのApache MPM

Windowsでは、Apache 2.0 HTTPサーバーによってWindows MPMというMPMアーキテクチャがサポートされます。Windows MPMは、1つのマルチスレッド・プロセスを使用してすべてのリクエストを処理します。

21.1.1.2.2 UNIXのApache MPM

UNIX/Linuxプラットフォームでは、Apache 2.0 HTTPサーバーに対して、次の2つのマルチプロセッシング・モジュール（MPM）アーキテクチャが用意されています。

  • Apache MPM prefork

    Apache MPM preforkモジュールは、スレッドを使用せず、先行してforkを実行するWebサーバーを実装します。これにより、Apache 1.3モデルに対応するプロセス・モデルが提供されます。このモデルでは、1つの制御プロセスが、それぞれにシングル・スレッドである複数の子プロセスを起動します。各子プロセスは接続リクエストをリスニングして、リクエストが着信したら応答します。つまり、各リクエストは1つのシングルスレッド・プロセスによって処理されます。

    MPM preforkは、Apache 2.0 HTTPサーバーのデフォルトのMPMです。Oracle COREid FederationのWebプロキシは、このMPMモデルを利用しています。

  • Apache MPM worker

    Apache MPM workerモジュールは、マルチプロセスでマルチスレッドのWebサーバーを実装します。このモデルでは、1つの制御プロセスが複数の子プロセスを起動します。各子プロセスは、一定数のサーバー・スレッドとリスナー・スレッドを1つ起動します。これにより接続リクエストをリスニングし、着信したリクエストをサーバー・スレッドに渡して処理します。


注意:

COREid FederationのWebプロキシでは、Linuxでのみprefork MPMが提供されます。MPMはApacheのコンパイル時設定であるため、worker MPMを使用するようにプロキシを再構成することはできません。したがって、worker MPMの構成オプションはCOREid FederationのWebプロキシに適用されません。

21.1.1.3 Apache MPMモデルの比較

同時リクエスト数が比較的少なく、マシンのリソースに制約がない場合は、worker MPMおよびprefork MPMにパフォーマンス上の大きな違いはありません。

worker MPMを使用する利点は、そのスケーラビリティにあります。worker MPMを使用すると、（より大きいけれども）より少ないプロセスでより多くのリクエストを処理できます。しかし、このスケーラビリティには次の欠点があります。

  • スレッド処理の複雑さが増加する

  • 障害の処理能力が低下する

シングルスレッドを使用するprefork MPMでは、ロードしたモジュールが失敗した場合、コア・ダンプは1つのリクエスト（つまり、そのプロセスによって処理されていたリクエスト）にのみ影響します。workerモデルでは、そのようなコア・ダンプによって、特定のプロセスのすべてのスレッドで処理されているすべてのリクエストが停止します。

スケーラビリティを向上させるために（workerモデルで）スレッド数を増やすことにより、プロセス障害の影響を受けるリクエスト数も増加します。

21.1.1.4 Apache MPM preforkのチューニングに関する考慮事項

Oracle COREid FederationのWebプロキシで利用する、prefork MPMモデルをチューニングする際に考慮するいくつかのパラメータを次に示します。

MaxClients: サーバーで処理可能な同時リクエストの最大数を設定します。

StartServers: リスナーの起動時に生成される子プロセスの数を設定します。このパラメータは、サーバーで処理する同時ユーザーのおおよその平均値に設定します。

MinSpareServersおよびMaxSpareServers: それぞれに、アイドル状態にある子プロセスの最小数と最大数を定義します。メモリーによほどの制約がないかぎり、比較的大きな値を設定できます。

MaxRequestsPerChild: （サーバーが古いプロセスを停止して新しいプロセスを起動することによって）子プロセスがリサイクルされるまでに、個々の子プロセスが処理するリクエスト数を設定します。このパラメータは、メモリーまたは他のリソースをリークする可能性のある、信頼性の低いモジュールで使用します。通常は、この値を0に設定します。これにより、子プロセスはリサイクルされなくなります。

これらのパラメータの例を次に示します。たとえば、サーバーでの同時リクエスト処理数が平均75、リクエスト数が150となるピークが散発的に発生すると予測する場合は、次のように設定することをお薦めします。

MaxClients  200
StartServers 75
MinSpareServers 20
MaxSpareServers 50

21.1.1.5 Apache MPM workerのチューニングに関する考慮事項

worker MPMモデルをチューニングする際に考慮するいくつかのパラメータを次に示します。

ThreadsPerChild: それぞれの子プロセスで生成されるスレッド数を設定します。

MaxClients: 起動可能なスレッドの最大総数を設定します。

StartServers: 最初に起動されるプロセス数を指定します。

MinSpareThreadsおよびMaxSpareThreads: Apacheでは、すべてのプロセスのアイドル・スレッドの総数を追跡し、プロセスをforkおよび停止することによって、その総数をMinSpareThreadsおよびMaxSpareThreadsで指定した範囲内に維持します。

MaxRequestsPerChild: 古いプロセスを停止して新しいプロセスを起動することによりサーバーが子プロセスをリサイクルする頻度を設定します。

ServerLimit: アクティブな子プロセスの絶対的な上限値を設定します。

推奨される構成値および関連情報は、http://httpd.apache.org/docs/2.0/mod/worker.htmlを参照してください。

21.1.1.6 分析のために収集する情報

次の情報を収集しておくと、Oracle COREid FederationのWebプロキシのパフォーマンスを分析する際に役立ちます。

  • 重要なチューニング・パラメータの設定

    Apache MPM preforkでは、次の情報を収集します。

    • MaxClients

    • StartServers

    • MinSpareServers

    • MaxSpareServers

    • MaxRequestsPerChild

    Apache MPM workerでは、次の情報を収集します。

    • MaxClients

    • StartServers

    • ThreadsPerChild

    • MinSpareThreads

    • MaxSpareThreads

    • MaxRequestsPerChild

  • mod_statusの出力

    この出力は、処理が行われているURLやリクエストの状態（クライアントから読取り中、リクエスト処理中、レスポンスへの書込み中）など、Apacheの各処理単位（スレッド/プロセス）で何が行われているかを確認する際に役立ちます。

    ハングしているリクエストがある場合、mod_statusからのダンプには、それらのリクエストを処理しているプロセスやダンプ発生時のプロセスの状態が記録されます。

    mod_status出力の解析の詳細は、次のWebサイトを参照してください。

    http://httpd.apache.org/docs/2.0/mod/mod_status.html

  • プロセスのスタック・トレース

    mod_statusのダンプを調べてハングしているプロセスのpidを取得し、このpidを使用してプロセスのスタック・トレースを取得します。これは、リクエストがスタックしている場所を判断する際に役立ちます。

    スタック・トレースの取得に使用するツールについては、該当するプラットフォームのドキュメントを参照してください。たとえば、次のLinuxのmanページには、pstackの詳細が記載されています。

    http://linuxcommand.org/man_pages/pstack1.html

21.1.1.7 まとめ

ユーザー数を拡大するにしたがって、Oracle COREid FederationのWebプロキシのパフォーマンスを監視することが非常に重要になります。パフォーマンスは、Apacheの重要なMPM構成パラメータを管理し、mod_status出力およびハングしているプロセスのスタック・ダンプを収集して分析することによりチューニングします。

Apache MPMモジュールの詳細は、次のWebサイトを参照してください。

  戻る
戻る 		 次へ
次へ
  目次
目次