Oracle9i Application Server for UNIX Oracle HTTP Server powered by Apacheパフォーマンス・ガイド, リリース1.0.2

(1)

Oracle9i Application Server for UNIX

Oracle HTTP Server powered by Apache

パフォーマンス・ガイド

リリース 1.0.2

2001年 1 月部品番号 : J02988-01

(2)

Oracle9i Application Server for UNIX Oracle HTTP Server powered by Apache パフォーマンス・ガイド , リリース1.0.2

部品番号: J02988-01

原本名：Oracle9i Application Server Oracle HTTP Server powered by Apache Performance Guide Release 1.0.2 for AIX-Based Systems, Compaq Tru64 UNIX, HP 9000 Series HP-UX, Linux Intel, and Sun Solaris Intel

原本部品番号：A86828-01

原本著者：Pallavi Bhowmik, and Julia Pond

原本協力者：Corinne Arne, Rupesh Das, Danielle Higgins, Prashanth Joshi, Rajesh Konanganparambath, Saurabh Pandey, and Sriram V.R. Nagaraja Rao

Copyright © 2000 Oracle Corporation. All rights reserved. Printed in Japan. 制限付権利の説明プログラムの使用、複製または開示は、オラクル社との契約に記された制約条件に従うものとします。著作権、特許権およびその他の知的財産権に関する法律により保護されています。当ソフトウェア（プログラム）のリバース・エンジニアリングは禁止されております。このドキュメントの情報は、予告なしに変更されることがあります。オラクル社は本ドキュメントの無謬性を保証しません。 * オラクル社とは、Oracle Corporation（米国オラクル）または日本オラクル株式会社（日本オラクル）を指します。危険な用途への使用についてオラクル社製品は、原子力、航空産業、大量輸送、医療あるいはその他の危険が伴うアプリケーションを用途として開発されておりません。オラクル社製品を上述のようなアプリケーションに使用することについての安全確保は、顧客各位の責任と費用により行ってください。万一かかる用途での使用によりクレームや損害が発生いたしましても、日本オラクル株式会社と開発元であるOracle Corporation（米国オラクル）およびその関連会社は一切責任を負いかねます。当プログラムを米国国防総省の米国政府機関に提供する際には、『Restricted Rights』と共に提供してください。この場合次の Legend が適用されます。

Restricted Rights Legend

Programs delivered subject to the DOD FAR Supplement are "commercial computer software" and use, duplication and disclosure of the Programs shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement. Otherwise, Programs delivered subject to the Federal Acquisition Regulations are "restricted computer software" and use, duplication and disclosure of the Programs shall be subject to the restrictions in FAR 52.227-14, Rights in Data -- General, including Alternate III (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.

このドキュメントに記載されているその他の会社名および製品名は、あくまでその製品および会社を識別する目的にのみ使用されており、それぞれの所有者の商標または登録商標です。

(3)

i

はじめに

... v

1 パフォーマンスの概要

パフォーマンスの概要

パフォーマンスに関する用語パフォーマンスに関する用語パフォーマンスに関する用語パフォーマンスに関する用語 ... 1-2 パフォーマンスのチューニングとはパフォーマンスのチューニングとはパフォーマンスのチューニングとはパフォーマンスのチューニングとは ... 1-2 応答時間 ... 1-3 システム・スループット ... 1-4 待機時間 ... 1-4 重要なリソース ... 1-5 過度の需要による影響 ... 1-6 問題解決のための調整 ... 1-6 パフォーマンス目標の設定パフォーマンス目標の設定パフォーマンス目標の設定パフォーマンス目標の設定 ... 1-7 ユーザーの期待値の設定ユーザーの期待値の設定ユーザーの期待値の設定ユーザーの期待値の設定 ... 1-7 パフォーマンスの評価パフォーマンスの評価パフォーマンスの評価パフォーマンスの評価 ... 1-7 パフォーマンス管理の方法パフォーマンス管理の方法パフォーマンス管理の方法パフォーマンス管理の方法 ... 1-8 パフォーマンス改善の要因 ... 1-9 アーキテクチャアーキテクチャアーキテクチャアーキテクチャ ... 1-10

2 Web

サーバーのモニター

プロセッサ使用率のモニタープロセッサ使用率のモニタープロセッサ使用率のモニタープロセッサ使用率のモニター ... 2-2 sar ユーティリティの使用（AIX、HP-UX、Intel Solaris） ... 2-2 top ユーティリティの使用 ... 2-3

Web サーバーのモニターサーバーのモニターサーバーのモニターサーバーのモニター ... 2-3 mod_status ユーティリティの使用 ... 2-3

(4)

サーバー統計のファイルへのロギング ... 2-6 JServ プロセスのモニタープロセスのモニタープロセスのモニタープロセスのモニター ... 2-7

3 サイズ設定および構成

サイズ設定および構成

ハードウェアおよびリソースのサイズ設定ハードウェアおよびリソースのサイズ設定ハードウェアおよびリソースのサイズ設定ハードウェアおよびリソースのサイズ設定 ... 3-2 同時ユーザーおよびユーザー数について同時ユーザーおよびユーザー数について同時ユーザーおよびユーザー数について同時ユーザーおよびユーザー数について ... 3-2 CPU 要件の決定要件の決定要件の決定 ... 3-3要件の決定 CPU 要件に対する Secure Sockets Layer の影響 ... 3-4 メモリー要件の決定メモリー要件の決定メモリー要件の決定メモリー要件の決定 ... 3-4 HTTP サーバー以外のソフトウェアおよびオペレーティング・システムのメモリー ... 3-4 HTTP サーバーのメモリー要件 ... 3-5 JServ のメモリー要件 ... 3-5 Java のヒープ・サイズの決定 ... 3-5 サーブレットおよびOracleJSP のメモリー要件 ... 3-6 JServ プロセスの数 ... 3-6

4 HTTP

サーバーのパフォーマンスの最適化

TCP のチューニングのチューニングのチューニング ... 4-2のチューニング Linux でチューニング可能な設定 ... 4-4 MaxClients ... 4-9 SSL セッション・キャッシュセッション・キャッシュセッション・キャッシュ ... 4-9セッション・キャッシュロギングの影響ロギングの影響ロギングの影響ロギングの影響 ... 4-10 HTTP/1.1 ... 4-10 永続的な接続 ... 4-11 Apache のバージョンのバージョンのバージョンのバージョン ... 4-13

5 Apache JServ

の最適化

JServ の概要の概要の概要の概要 ... 5-2 サーブレットのパフォーマンスの最適化サーブレットのパフォーマンスの最適化サーブレットのパフォーマンスの最適化サーブレットのパフォーマンスの最適化 ... 5-3 サーブレット・クラスのロード ... 5-3 クラスの自動リロード ... 5-3 ロード・バランシング ... 5-4 シングル・スレッド・モデルのサーブレットの使用 ... 5-7 OracleJSP とはとはとはとは ... 5-8 OracleJSP のパフォーマンス・チューニングのパフォーマンス・チューニングのパフォーマンス・チューニングのパフォーマンス・チューニング ... 5-8

(5)

iii セッション管理の影響 ... 5-8 開発者モード ... 5-8 バッファリング ... 5-9 OracleJSP のパフォーマンスの向上 ... 5-9

索引

(6)

(7)

v

はじめに

対象読者

このマニュアルは、Oracle HTTP Server powered by Apache の設定およびチューニングを担当するOracle9i Application Server の開発者およびシステム管理者を対象としています。

前提

Web サーバー、特に Apache の設定およびチューニングについては、多くの参考情報が存在します。このマニュアルでは、有用な場合にはそれらの参考情報について言及し、実際的であれば、それらの情報で説明されている設定を行った結果、どれ位パフォーマンスが向上するかについても触れます。オラクル社の社内テストで検証されていない推奨事項については、参考情報をそのまま使用し、その旨が明記されています。すべての社内テストは、再現性のあるテスト結果を得られるよう、専用の100Mbps のネットワークで実行されました。ご使用の環境での結果は、ネットワーク設定や競合特性によって異なります。

マニュアルの表記規則

このマニュアルでは、次の表記規則を使用します。表記規則表記規則表記規則表記規則例例例例説明説明説明説明太字太字太字太字 tnsnames.ora runInstaller ファイル名、ユーティリティおよびプロセスを表します。イタリック体 file1 テキスト内の可変部分を表します。このプレースホルダを特定の値や文字列に置き換えます。山カッコ <filename> コード内の可変部分を表します。このプレースホルダを特定の値や文字列に置き換えます。

(8)

固定幅フォント owsctl start wrb _{表示どおりに入力するテキストを表します。関} 数にも使用します。大カッコ [-c string] [on|off] オプション項目を表します。オプション項目の選択肢がそれぞれ垂直バー（|）で区切って示され、その中のいずれか 1 つを選択できます。中カッコ {yes|no} _{必須項目の選択肢が垂直バー（|）で区切って} 示されます。省略記号 n,... その前の項目を何回でも繰り返すことができることを表します。表記規則表記規則表記規則表記規則例例例例説明説明説明説明

(9)

パフォーマンスの概要 1-1

1

パフォーマンスの概要

この章では、パフォーマンスとチューニングの概念について説明し、Oracle9i Application Server のアーキテクチャについて簡単に説明します。

内容

■ パフォーマンスに関する用語 ■ パフォーマンスのチューニングとは ■ パフォーマンス目標の設定 ■ ユーザーの期待値の設定 ■ パフォーマンスの評価 ■ パフォーマンス管理の方法 ■ アーキテクチャ

(10)

パフォーマンスに関する用語

次に、このマニュアルで使用されているパフォーマンスに関する用語を示します。

パフォーマンスのチューニングとは

パフォーマンスは、事前に設定しておく必要があります。アプリケーションの分析および設計中にパフォーマンス要件を予測し、最適なパフォーマンスのコストと利益を考慮する必要があります（1-7 ページの「パフォーマンス目標の設定」を参照してください）。この項では、次のような基本概念について説明します。 ■ 応答時間 ■ システム・スループット ■ 待機時間 ■ 重要なリソース ■ 過度の需要による影響 ■ 問題解決のための調整同時実行性同時実行性同時実行性同時実行性複数のリクエストを同時に処理する能力。同時実行性メカニズムの例には、スレッドおよびプロセスがあります。レイテンシレイテンシレイテンシレイテンシ全体のタスクを完了するために、あるシステム・コンポーネントが別のコンポーネントを待機している時間。レイテンシは、無駄な時間として定義できます。ネットワークの場合、レイテンシはパケットのソースから宛先への移動時間として定義されます。応答時間応答時間応答時間応答時間リクエストの送信から応答の完了までの時間。スケーラビリティスケーラビリティスケーラビリティスケーラビリティ使用可能なハードウェア・リソースに比例して、そして使用可能なハードウェア・リソースによってのみ制限された状態でシステムがスループットを提供できる能力。スケーラブルなシステムとは、応答時間およびスループットに悪影響を与えずに、増加したリクエストの処理が可能なシステムです。サービス時間サービス時間サービス時間サービス時間リクエストへの応答の開始から完了までの時間。思考時間思考時間思考時間思考時間ユーザーが実際にプロセッサを使用していない時間。スループットスループットスループットスループット単位時間あたりに処理されるリクエスト数。待機時間待機時間待機時間待機時間リクエストの送信から応答の開始までの時間。

(11)

パフォーマンスのチューニングとはパフォーマンスの概要 1-3

応答時間

応答時間はサービス時間と待機時間の合計であるため、次の方法でパフォーマンスを向上できます。 ■ 待機時間を削減する ■ サービス時間を削減する図1-1に、1 つのリソースに対して 10 個のタスクが競合している状態を示します。図図図 図 1-1 個別のタスクの順次処理個別のタスクの順次処理個別のタスクの順次処理個別のタスクの順次処理この例では、待機時間なしで実行されるのはタスク1 のみです。タスク 2 はタスク 1 が完了するまで待機し、タスク3 はタスク 1 と 2 が完了するまで待機する必要があります。他のタスクについても同様です。（この図では各タスクの大きさは同じですが、実際のタスクのサイズはそれぞれ異なります。）複数のリソースを使用したパラレル処理の場合、より多くのリソースをタスクに割り当てることができます。各タスクは専用のリソースを使用してすぐに実行されるため、待機時間が発生しません。 1 2 3 4 5 6 7 8 9 10

(12)

パフォーマンスのチューニングとは

システム・スループット

システム・スループットは、一定時間内に完了する処理量です。スループットは、次の方法で増加できます。 ■ サービス時間を削減する ■ 不足しているリソースを増加することにより、全体の応答時間を削減する。たとえば、システムのボトルネックがCPU である場合には、CPU を追加できます。

待機時間

1 つのタスクのサービス時間が同じ場合でも、競合が増加すると待機時間は長くなります。1 秒を要するサービスを多数のユーザーが待っている場合、10 番目のユーザーは 9 秒間待機する必要があります。図1-2に、待機時間とリソースに対する競合の関係を示します。図図図 図 1-2 リソースに対する競合の増加による待機時間の増加リソースに対する競合の増加による待機時間の増加リソースに対する競合の増加による待機時間の増加リソースに対する競合の増加による待機時間の増加

(13)

パフォーマンスのチューニングとはパフォーマンスの概要 1-5

重要なリソース

CPU、メモリー、I/O 容量およびネットワーク帯域幅などのリソースは、サービス時間短縮の鍵となります。リソースを増加すると、スループットが増加し、応答時間も短縮できます。パフォーマンスは次の要因に依存します。 ■ 使用可能なリソースの量 ■ リソースを必要とするクライアントの数 ■ リソースに対するクライアントの待機時間 ■ クライアントがリソースを保持する時間図1-3に、リクエスト単位数が増加すると、サービスの完了までに要する時間も増加することを示します。図図図 図 1-3 サービス完了までの時間と需用率サービス完了までの時間と需用率サービス完了までの時間と需用率サービス完了までの時間と需用率この状況を解消するには、2 つの方法があります。 ■ 許容範囲の応答時間を維持するために需用率を制限する ■ リソースを追加する

(14)

パフォーマンスのチューニングとは

過度の需要による影響

過度の需要により、応答時間が増加し、スループットが減少します。この様子を図1-4に示します。需用率がスループットの限度を超過する可能性がある場合、需要の制限手段（たとえば、Oracle HTTP Server の MaxClients および JServ の security.maxConnections など）が不可欠です。システムにどの程度の需要が生じるかを考慮し、これらの制限を考慮してアプリケーションの設計やシステム設定を行ってください。図図図 図 1-4 需要の増加とスループットの減少需要の増加とスループットの減少需要の増加とスループットの減少需要の増加とスループットの減少

問題解決のための調整

パフォーマンスに関する問題は、次のような調整により解決できます。単位消費リクエストあたりのリソース（CPU、メモリー）の消費の削減により、パフォーマンスを改善できます。これは、プーリングおよびキャッシングにより実現できます。機能面での需要問題によっては、処理のスケジュールを変更したり、処理を分散しなおすことによって解決できます。容量リソース（CPU など）の増加や再割当てによって問題を解決できる場合があります。

(15)

パフォーマンスの評価パフォーマンスの概要 1-7

パフォーマンス目標の設定

システムを設計する場合もメンテナンスを行う場合も、最適化の手段および対象を判断できるよう、具体的なパフォーマンス目標を設定する必要があります。特定の目標を持たずにパラメータを変更すると、目立った効果もなくシステムのチューニングに余分な時間を費やすことになります。具体的なパフォーマンス目標の例として、注文入力の応答時間を3 秒以内にする、などがあります。アプリケーションがその目標を達成できない場合、原因（たとえばI/O 競合など）を識別して対処します。開発中にアプリケーションをテストして、設計時に設定されたパフォーマンス目標を達成できるかどうかを調べます。通常、チューニングには他の面とのトレード・オフが発生します。ボトルネックを判断できたら、目標を達成するために、他の部分のパフォーマンスを変更する必要がある場合もあります。たとえば、I/O が問題である場合、メモリーまたはディスクの購入が必要な場合があります。購入できない場合は、目標のパフォーマンスを得るためにシステムの同時実行性を制限する必要があります。ただし、パフォーマンスの目標が明確に定まっていれば、何が最も重要かがわかっているため、パフォーマンス向上のために何を犠牲にするかの判断が容易になります。

ユーザーの期待値の設定

アプリケーション開発者、データベース管理者およびシステム管理者は、ユーザーが期待しているパフォーマンスを、注意しながら適切に設定する必要があります。システムが特に複雑な処理を行っている場合は、単純な処理を行っている場合よりも応答時間が長くなる可能性があります。どの処理に時間がかかるかを明確にユーザーに知らせる必要があります。

パフォーマンスの評価

パフォーマンス目標を明確に定めると、パフォーマンスのチューニングが成功したかどうか、容易に判断できます。チューニングの成功を左右するのは、ユーザー・コミュニティに対して設定した機能面での目標、基準が満たされたかどうかを判断する能力、そして例外事項を解決するための対策を講じる能力です。常にパフォーマンスをモニターすることにより、十分にチューニングされたシステムを維持できます。アプリケーションのパフォーマンスの履歴を記録することにより、有効な比較が可能となります。様々な大きさの負荷に関する実際のリソース消費データを使用して、客観的なスケーラビリティの調査を行うことにより、予期される負荷のボリュームに合わせたリソース要件を予測できます。

(16)

パフォーマンス管理の方法

システムの最適効率を実現するためには、計画、モニターおよび定期的な調整が必要です。パフォーマンス・チューニングの最初のステップは、目標を決定し、使用可能なテクノロジを効率的にアプリケーションに使用するよう設計することです。システムのインプリメント後には、システムを定期的にモニターし、調整する必要があります。たとえば、90% のユーザーの応答時間を5 秒以下にし、すべてのユーザーの最長応答時間を 20 秒にするように保証するとします。通常、これは簡単なことではありません。アプリケーションには、それぞれ特徴および許容できる応答時間が異なる様々な処理が含まれます。それぞれのアプリケーションに対し、適切な目標を設定する必要があります。図図図 図 1-5 容量と機能面での需要の調整容量と機能面での需要の調整容量と機能面での需要の調整容量と機能面での需要の調整また、負荷の変動も判別する必要があります。たとえば、ユーザーはシステムに午前9 時から10 時に集中的にアクセスし、再び午後 1 時から 2 時に集中的にアクセスする可能性があります。たとえば、毎日あるいは毎週など、定期的に負荷のピークが発生する場合、一般的には負荷のピーク時の要件に合わせてシステムを設定し、チューニングします。ピーク時以外にアプリケーションにアクセスするユーザーは、ピーク時のユーザーよりも短い応答時間を得られます。負荷のピークが頻繁に発生しない場合は、少ないハードウェア構成でコストを抑えるために、負荷のピーク時には応答時間が長くても我慢することも考えられます。

(17)

パフォーマンス管理の方法パフォーマンスの概要 1-9

パフォーマンス改善の要因

パフォーマンスは、様々な領域にまたがっています。 ■ アプリケーション設計: ハードウェア・リソースを効率的に利用し、ユーザーの増加に効率的に対処するアプリケーションの設計。 ■ サイズ設定と構成: パフォーマンス目標をサポートするために必要なハードウェアのタイプの判断。第3 章「サイズ設定および構成」を参照してください。 ■ パラメータのチューニング: アプリケーションの最高のパフォーマンスを得るための、設定可能なパラメータの設定。第5 章「Apache JServ の最適化」および第4 章「HTTP サーバーのパフォーマンスの最適化」を参照してください。 ■ パフォーマンスのモニター: アプリケーションが使用しているハードウェア・リソースおよびユーザーが費やしている応答時間の判断。第2 章「Web サーバーのモニター」を参照してください。 ■ トラブルシューティング: アプリケーションが過度にハードウェア・リソースを使用していたり、応答時間が目標よりも長い場合の理由の診断。

(18)

アーキテクチャ

図1-6に、Oracle9i Application Server のアーキテクチャを示します。

このマニュアルでは、次のコンポーネントのパフォーマンスと設定について説明します。 ■ Oracle HTTP Server powered by Apache

■ Apache JServ ■ OracleJSP

図図図

(19)

Webサーバーのモニター 2-1

2

Web

サーバーのモニター

この章では、システムに関する情報収集に使用可能なユーティリティおよびプロセスについて説明します。この情報は、リソースを最大限に活用するために役立ちます。

内容

■ プロセッサ使用率のモニター ■ Web サーバーのモニター ■ JServ プロセスのモニター

(20)

プロセッサ使用率のモニター

プロセスの使用率を判断するためには、CPU 統計を収集する必要があります。また、ユーザーを追加し、システムのワークロードを増やして、システムのスケーラビリティをモニターする必要があります。プロセスの使用率をモニターするには、sar（System Activity Reporter）および mpstat などのユーティリティを使用します。

sar

ユーティリティの使用（

ユーティリティの使用（AIX

ユーティリティの使用（

AIX

AIX、

、

、HP-UX

HP-UX、

HP-UX

、

、Intel Solaris

Intel Solaris

Intel Solaris）

）

sarを使用すると、指定した間隔でオペレーティング・システムの累積アクティビティ・カウンタのサンプルを取得できます。

CPU

使用率のレポート

プロセスの使用率を判断するには、次の sar コマンドを使用します。 $ sar -u 5 5 : このコマンドは、次に示すように、5 秒間隔で 5 回、CPU 使用率のサンプルを取得します。 $ sar -u 5 5

15:30:25 %usr %sys %wio %idle 15:30:30 49 36 0 14 15:30:35 52 41 0 7 15:30:40 46 45 0 8 15:30:45 46 44 0 10 15:30:50 50 41 0 9 Average 46 41 0 9 上の統計は、指定した期間中に、CPU が 9% だけアイドル状態であったことを示します。パフォーマンス基準でCPU 使用率を特定の割合よりも低くするよう指定している場合、sar を使用して指定した間隔で負荷のピーク時の使用率のサンプルを取得することが可能です。 sarコマンド（-u オプション）により次の統計が表示されます。表表表 表 2-1 sar ユーティリティによってレポートされるユーティリティによってレポートされるユーティリティによってレポートされるユーティリティによってレポートされる CPU 統計統計統計統計 CPU統計統計統計統計説明説明説明説明 %usr _{ユーザー・モードでプロセッサが実行される時間の割合} %sys _{システム時間で実行されるプロセッサの割合} %wio プロセッサがI/O リクエストの待機に費やす時間の割合 %idle _{プロセッサがアイドルになっている割合}

(21)

Webサーバーのモニター Webサーバーのモニター 2-3

top

ユーティリティの使用

topユーティリティを使用して、稼動中のプロセッサのアクティビティをリアル・タイムで表示できます。使用方法については、man ページを参照してください。例: $ top

4.:16pm up 15 days, 5:39 23 users, load average: 0.51, 0.38, 0.49 265 processes: 261 sleeping, 3 running, 1 zombie, 0 stopped CPU states: 7.1% user, 44.3% system, 0.0% nice, 48.4% idle

Mem: 2009664K av, 1954828K used, 54836K free, 75288K shrd, 1448352K buff Swap: 2096440K av, 10376K used, 2086064K free 250576K cached

PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 20892 oasport 6 0 13908 13M 5068 R 0 24.9 0.6 0:06 oraweb 20928 oasport 7 0 13652 13M 4896 R 0 24.9 0.6 0:05 oraweb 20936 rkonanga 5 0 1252 1252 916 R 0 1.4 0.0 0:00 top 15187 oasport 0 0 2232 2232 1372 S 0 0.4 0.1 0:02 xterm 20728 oasport 0 0 2984 2984 1604 S 0 0.1 0.1 0:00 oasoorb 1 root 0 0 156 136 92 S 0 0.0 0.0 0:04 init 2 root 0 0 0 0 0 SW 0 0.0 0.0 0:10 kflushd 3 root 0 0 0 0 0 SW 0 0.0 0.0 6.35 kupdate

Web

サーバーのモニター

パフォーマンスのチューニングには、モニターが不可欠です。Oracle HTTP Server では、 mod_statusモジュールを使用して、現在のサーバー統計を含め、サーバー側のステータス情報が提供されます。これらのサーバー・ステータス・レポートを取得するには、次に説明するようにWeb サーバーを設定する必要があります。

mod_status

ユーティリティの使用

モニターを使用可能にするには、httpd.conf ファイルを編集して、your_domain.com を、モニターするサーバーのホスト名に置き換えます。 <Location /server-status> SetHandler server-status Order deny, allow Deny from all

Allow from your_domain.com </Location>

最大限の情報が表示されるように、ExtendedStatus ディレクティブが On に設定されていることを確認します。

your_domain.comのみでなく、すべてのドメインからのアクセスを許可すると、ドメイン外のマシンからご使用のサーバーをモニターすることが可能です。ただし、ご使用のサー

(22)

Webサーバーのモニターバー・ステータスにあらゆるサイトからアクセス可能であるため、セキュリティ面で問題があることを認識する必要があります。システム・モニターに使用するドメインのみ指定することをお薦めします。 モニターを使用可能にすると、現在の統計を http://hostname:port/server-status で表示できます。これらの統計により、ご使用のシステムの混雑状況を知ることができます。次の内容が表示されます。 ■ 表示中のステータスのホスト名 ■ サーバーのバージョン ■ サーバーが構築された日付 ■ 現在の時間、再起動の時間、アップタイム ■ 現在処理中のリクエスト数 ■ リクエストを処理しているhttpd プロセス数 ■ アイドル状態のhttpd プロセス数 ■ 現在のサーバーの状態（たとえば、接続待機中、リクエストの読込み中、応答の送信中など）図2-1に、ExtendedStatus がオンになっているサーバー・ステータス・ページのスナップショットを示します。

(23)

Webサーバーのモニター Webサーバーのモニター 2-5 図図図 図 2-1 サーバー・ステータス・ページサーバー・ステータス・ページサーバー・ステータス・ページサーバー・ステータス・ページ

サーバー・ステータス情報の解析

画面（ExtendedStatus を使用可能にした状態で）には、6 つのリクエストが処理中で、4 つのサーバーがアイドル状態であることが示されています。M（モード列）の値から、サーバーが処理のどの段階にあるかを判断できます。図2-1では、6 つのサーバーが応答を送信中で、4 つのサーバーが接続待機中です。ご使用のシステムの応答時間が長い場合、またはhttpd プロセスが応答を止めたと思われる場合、Req（リクエスト）列を見ます。この列には、最後のリクエスト処理に要した時間がミリ秒で表示されます。この数値がリクエスト処理の目標値より大きいかどうかを調べます。リクエストの完了後も、そのプロセスのM（モード）列に W と表示されている場合、プロセスは応答していないと考えられます。

(24)

Webサーバーのモニターこれ以外にも、システムがCPU の限界に達していないかどうかをモニターすることが重要です。これは、CPU 使用率が 90% 前後の状態です。サーバー・ステータス・ページには、 CPU 使用率および生成されたプロセス数が表示されます。システムが httpd プロセスの限界（httpd.conf 内の MaxClients ディレクティブの設定）に近づいており、パフォーマンスが悪く、プロセスが常に使用中である場合、MaxClients 設定を変更する必要があることがあります。4-9 ページの「MaxClients」を参照してください。

サーバー・ステータス表示のカスタマイズ

図2-1に、ある瞬間のサーバーのスナップショットを示します。サーバー・ステータスURL にrefresh パラメータを含めると、任意の間隔でサーバー統計を更新して表示できます。 http://servername:port/server-status?refresh=x x は、データ更新までの秒数を示す整数です。たとえば、統計を 3 秒ごとに更新するには、 refresh=3と指定します。また、統計をデータ分析プログラムまたはスプレッドシート・プログラムで処理できるよう、統計をマシンで読込み可能な形式で表示すると便利な場合があります。これを行うには、次に示すように、URL の最後に auto を追加します。 http://servername:port/server-status?auto 図図図 図 2-2 サーバー統計表示サーバー統計表示サーバー統計表示サーバー統計表示

サーバー統計のファイルへのロギング

Apache Group により、サーバーのモニターを自動化するための Perl スクリプト

logstatus.pl が提供されています。これは、$ORACLE_HOME/Apache/Apache/bin/ ディレクトリに含まれています。

(25)

JServプロセスのモニター Webサーバーのモニター 2-7 このスクリプトは、cron（またはコマンドを一定間隔で実行するその他の同様のデーモン）によって実行されるよう設計されています。このスクリプトを使用するには、次の設定値を変更する必要があります。 httpd プロセスが応答しておらず、そのプロセスを識別する必要がある場合、サーバー・ステータスを使用可能にすると大変役に立ちます。 ps、top または pmap などのオペレーティング・システム・ユーティリティでは、応答していないプロセスは識別されません。 mod_statusの詳細は、次を参照してください。 http://www.oreillynet.com/pub/a/apache/2000/04/21/wrangler.html http://www.apache.org/docs/mod/mod_status.html

JServ

プロセスのモニター

Oracle9i Application Server の開始後、すべての JServ プロセスが正しく開始されているかど うかを確認できます。 1. jserv.conf ファイルの JServ ステータス・ハンドラ・セクションのコメントを削除してモニターを使用可能にし、JServ のステータスにアクセスするホストを指定します（デフォルトはlocalhost です）。ご使用のシステムのステータス情報にアクセス可能なホストを選択する際、必ずセキュリティ面を考慮してください。 <Location /jserv/> SetHandler jserv-status order deny, allow deny from all

allow from oracle.com </Location> 表表表 表 2-2 ログ・ステータス・スクリプト変数ログ・ステータス・スクリプト変数ログ・ステータス・スクリプト変数ログ・ステータス・スクリプト変数変数変数変数変数値値値値 $wherelog _{ログ・ファイルの場所のパス名。} 例: /private/admin/logs/ スクリプトにより、ファイル名が作成されます。たとえば、20010945 です。 $port _{モニターするサーバーのポート番号。デフォルトは}_{80 です。} $server サーバー・ホスト名。デフォルトはlocalhost です。 $request _{ブラウザに入力されるとおりの、auto パラメータを使用したサー} バー・ステータス・リクエスト。例: http://servername:port/server-status?auto

(26)

JServプロセスのモニター 2. 次のようにブラウザに入力します。 http://hostname:port/jserv/ port には、Web サーバーがリスニングを行うポートを指定する必要があります（httpd.conf ファイル内に存在します）。この URL では、必ず最後にスラッシュ（/）を入力してください。最後にスラッシュを入力しないと、"not found" エラーが発生します。「Configured Hosts」列にホストのリンクが表示されます。 3. モニターするホストをクリックします。ホストのJServ ステータス情報が、図2-3のように表示されます。注意注意注意 注意 : JServ ステータス・モニターには、jserv.conf ファイルで設定されているJServ プロセスがすべて表示されますが、すべてが開始されているとは限りません。たとえば、図2-3には4 つのプロセスが表示されていますが、ステータスがUp（そのプロセスがリクエスト処理可能であることを示す）のものは2 つのみです。

(27)

JServプロセスのモニター Webサーバーのモニター 2-9 図図図 図 2-3 JServ ステータスの表示ステータスの表示ステータスの表示ステータスの表示「Status」列には、各プロセスの現在の共有メモリー（shm）の状態が表示されます。

(28)

JServプロセスのモニター「Up」または「Down」という単語の後のカッコ内に表示される記号には、次のような意味があります。注意注意注意 注意 : 「Status」列の値は、手動モードで開始されたプロセスについての み表示されます。自動モードで開始されたシングル・プロセスについては、値は表示されません。記号記号記号記号意味意味意味意味 + プロセスは実行中です。 - プロセスは停止中です。 X プロセスは即時停止されました。 / プロセスは既存リクエストの実行を待って停止されました（プロセスの終了前に既存のリクエストは処理されました）。

(29)

サイズ設定および構成 3-1

3

サイズ設定および構成

この章では、パフォーマンス目標を達成する際に役立つ、サイズやその他の設定に関するガイドラインを示します。また、消費メモリー、I/O に関する問題、およびネットワークとソフトウェアの制約などのパフォーマンス要因についても説明します。

内容

■ ハードウェアおよびリソースのサイズ設定 ■ 同時ユーザーおよびユーザー数について ■ CPU 要件の決定 ■ メモリー要件の決定

(30)

ハードウェアおよびリソースのサイズ設定

ハードウェア・リソースは、インストールの最小推奨事項に加えて、使用するアプリケーションの要件を満たしている必要があります。ハードウェアに関連するパフォーマンスのボトルネックを避けるには、各ハードウェア・コンポーネントを容量の80% 以下で操作してください。 CPU 使用率の測定方法の詳細は、2-2 ページの「sar ユーティリティの使用（AIX、HP-UX、Intel Solaris）」を参照してください。特に、プロセッサとメモリー・リソースは、予期される最大のユーザー負荷に対して多めに割り当てる必要があります。

同時ユーザーおよびユーザー数について

必要なハードウェア・リソースの量は、アプリケーションによって異なります。ユーザーの思考時間やネットワークのレイテンシを考慮に入れずにリソースを推定するという誤りがよく見受けられます。アプリケーションのサイズを決定する際、予想ユーザー数と実際の同時ユーザー数との関係について把握している必要があります。これは、思考時間とアプリケーションの平均応答時間から判断します。必要なメモリー量を判断する際、同時実行ユーザー数（ユーザー数の合計ではない）にユーザーあたりのコストを掛けた数値も考慮する必要があります。表3-1に、思考時間とサービス時間が同時実行性に与える影響と、その結果生じるシステムのパフォーマンスの例を示します。注意注意注意 注意 : httpd.conf ファイルの MaxClients 設定により、同時実行ユーザー数が制限されます。 MaxClients ディレクティブの詳細は、4-9 ページの「MaxClients」を参照してください。

(31)

CPU要件の決定

サイズ設定および構成 3-3

CPU

要件の決定

ほとんどのアプリケーションの場合、CPU 使用率の大部分はアプリケーションのコード処理によるものです。表3-2に示すように、アプリケーションのCPU 要件は、アプリケーションの複雑さと作業負荷によって異なります。開発サイクル全体を通じて、アプリケーションのCPU 要件をモニターする必要があります。この方法は、第2 章「Web サーバーのモニター」を参照してください。表表表 表 3-1 同時実行ユーザー同時実行ユーザー同時実行ユーザー同時実行ユーザーユーザー数ユーザー数ユーザー数ユーザー数1 1 ユーザー数 - ユーザーの合計。思考時間思考時間思考時間思考時間（秒）（秒）（秒）（秒）2 2 _{思考時間 - ユーザーが実際にプロセッサを使用していない時間（リクエストとリクエストの間の時} 間）。サービス時間サービス時間サービス時間サービス時間（秒）（秒）（秒）（秒）3 3 _{サービス時間（秒）}_{- 1 ユーザーについて、操作を完了するまでの経過時間。} 同時ユーザーの同時ユーザーの同時ユーザーの同時ユーザーの範囲範囲範囲範囲4 4 同時ユーザーの範囲 - サーバー上で測定されたユーザー数。サーバー・ステータス表示（現在処理中のリクエスト）のスナップショットから取得。サーバー・ステータスの詳細は、2-3 ページの「mod_ status ユーティリティの使用」を参照してください。平均応答平均応答平均応答平均応答時間（秒）時間（秒）時間（秒）時間（秒）5 5 _{平均応答時間 - 処理中のクライアントについて測定された応答時間。} 1秒あたりの秒あたりの秒あたりの秒あたりのリクエスト数リクエスト数リクエスト数リクエスト数（スループット）（スループット）（スループット）（スループット）6 6 1 秒あたりのリクエスト数（スループット） - 処理されたリクエスト数。 CPU 使用率使用率使用率使用率（（（ （%））））7 7 _{CPU 使用率 - CPU 使用率合計の平均（パーセンテージ）。} 100 0 0.3 100 5.2 19 99 100 1 0.3 65-100 4.2 19 99 100 10 0.3 0-32 0.9 9 48 100 10 0.6 0-53 2.9 8 80 表表表 表 3-2 アプリケーションのアプリケーションのアプリケーションのアプリケーションの CPU 要件要件要件要件アプリケーションアプリケーションアプリケーションアプリケーション CPU要件要件要件要件（リクエストあたり）（リクエストあたり）（リクエストあたり）（リクエストあたり）静的ページ、20K 5ms 単純なサーブレット、JDK 1.2 20ms 単純なサーブレット、JDK 1.1.8 40ms 標準的なアプリケーション 100-200ms 複雑なアプリケーション 400-600ms

(32)

メモリー要件の決定

CPU

要件に対する

要件に対する Secure Sockets Layer

要件に対する

Secure Sockets Layer

の影響

Secure Sockets Layer（SSL）は、インターネット上でドキュメントを安全に送信するためのプロトコルです。SSL 接続を必要とする Web ページの URL は、http ではなく https で始まります。 SSL 接続の確立は、応答時間と CPU 使用率という点でコストがかかります。たとえば、SSL を使用しない場合に応答時間が0.5 秒であるリクエストでは、SSL を使用した場合、応答時間が1.7 秒でした（内部の 100Mbps ネットワーク上で測定）。SSL の使用によるパフォーマンス・コストの大部分は、接続の確立の際に発生します（336Mhz のプロセッサで 1 回の接続あたり約125ms の CPU タイム）。高い接続コストは、クライアントのSSL セッションの最初の接続の際に発生します。HTTP サーバーは、その後の接続のオーバーヘッドを削減するためにSSL のセッション情報をキャッシュに入れることができるためです。詳細は、4-9 ページの「SSL セッション・キャッシュ」を参照してください。

メモリー要件の決定

この項では、次のコンポーネントのメモリー要件について説明します。 ■ HTTP サーバー以外のソフトウェアおよびオペレーティング・システムのメモリー ■ HTTP サーバーのメモリー要件 ■ JServ のメモリー要件 ■ Java のヒープ・サイズの決定 ■ サーブレットおよびOracleJSP のメモリー要件 ■ JServ プロセスの数

HTTP

サーバー以外のソフトウェアおよびオペレーティング・システムの

メモリー

使用できるメモリー・リソースが解放されているアイドル状態のシステムでは、オペレーティング・システムの統計情報を見ると、常駐メモリーの使用量が仮想サイズに比較的近いことを示す場合があります。ユーザーがシステムにかける負荷が増加するにつれ、オペレーティング・システムはこれらのプロセスの不要なメモリーを利用するため、プロセスが消費する常駐メモリーが減少します。ご使用のシステムをモニターする際には、様々な使用レベルでプロセスのスナップショットを取得することをお薦めします。オペレーティング・システムのメモリー使用量の測定およびチューニングに関する詳細は、ご使用のオペレーティング・システムのハードウェアおよびソフトウェアのドキュメントを参照してください。メモリー使用量やプロセッサの統計は、オペレーティング・システムの標準のツールでモニターできます。詳細は、第2 章「Web サーバーのモニター」を参照してください。

(33)

メモリー要件の決定サイズ設定および構成 3-5

HTTP

サーバーのメモリー要件

リスナーのメモリー使用量の一連のテストで、各HTTP リスナーは（起動時に）約 400K の常駐メモリーを使用しました。このサイズは、リスナーがアクティブである間、1 プロセスあたり500 ∼ 600K ずつ増加しました。オペレーティング・システムが休止中のときには、リスナーのメモリー使用量が起動時のサイズに戻りました。オペレーティング・システムの標準のツールを使用して、常駐メモリー・サイズを調べることが可能です。リスナー・プロセスについて調べた場合、表示されるサイズには共有メモリーが含まれるため、前述の値より大きくなります。

JServ

のメモリー要件

JDK 1.2 を使用する JServ プロセスは、起動時に 12 ∼ 15MB 必要です。JDK 1.1.8 の場合、 10MB 必要です。

Java

のヒープ・サイズの決定

JDK 1.1.8 の場合、デフォルトの最大ヒープ・サイズは 16MB です。JDK 1.2 の場合、24MB です。パフォーマンスを最大にするには、アプリケーション要件を満たす最大ヒープ・サイズを設定します。必要なJava ヒープを判断するには、ご使用のプログラムに java.lang パッケージの Runtime.getRuntime().totalMemory() および Runtime.getRuntime().freeMemoryメソッドのコールを挿入します。合計メモリーからメモリーの空き容量を引きます。その差がアプリケーションが消費したヒープの量です。 128MB のヒープが必要だと判断したとします。ヒープ・サイズを変更するには、自動モードの場合、jserv.properties ファイルの最大 Java ヒープ・サイズを設定します。 wrapper.bin.parameters=-mx128m 手動モードの場合、複数のJServ プロセスが実行されているときは、ヒープ・サイズは各 JServ プロセスごとに、コマンドラインで設定する必要があります。 JServ プロセスが最大ヒープ・サイズを超えると、プロセスは終了します。自動モードの場合、新しいプロセスが開始されますが、パフォーマンスは著しく低下します。手動モードの場合、終了されたプロセスは再開されないため、ヒープ・サイズが十分な大きさであることを確認する必要があります。注意注意注意 注意 : top または ps などのユーティリティのレポートに表示されるプロセス・サイズは、最大ヒープ・サイズより大きくなります。これは、プライベート・メモリーが最大ヒープ・サイズに足されるためです。

(34)

サーブレットおよび

サーブレットおよび OracleJSP

OracleJSP

のメモリー要件

OracleJSP（サン・マイクロシステムズ社の JavaServer Pages の Oracle によるインプリメン

テーション）およびサーブレットは、使用するJDK のバージョンにより、必要なメモリー量が異なります。次の表に、10 ∼ 30 のアクティブ・スレッドを使用した処理における単純なサーブレットとOracle JSP のメモリー要件を比較します。サーブレットではセッションを使用しませんでした。OracleJSP ではセッションがオンでした（デフォルト）。必要なメモリー量は、セッションが使用されているかどうかによって異なります。1 つのセッションあたり約0.5MB 消費します。最大のパフォーマンスを得るためには、セッションを使用しない場合、次のようにしてOracleJSP アプリケーションでセッションをオフにします。 <%@ page session=”false” %> <html><body> HelloWorld </body></html> まず、アクティブなユーザーはそれぞれJava アプリケーションについて 150K から 200K、加えてサーバー・プロセスのサイズを消費すると考えます。Java アプリケーションの場合、基本プロセスは約12 ∼ 15MB です。アプリケーションのメモリーは、アプリケーションのサイズ、キャッシュされるデータの量、およびその他の要因によっても異なります。

OracleJSP の詳細は、『Oracle8i JavaServer Pages 開発者ガイドおよびリファレンス』を参照 してください。

JServ

プロセスの数

オラクル社では、基本的に、1 つの CPU あたり 2 つの JServ プロセスをお薦めします。また、JServ 設定ファイルのデフォルトのスレッド設定（security.maxConnections=50）から検討することもできます。（設定ファイルでパラメータを変更する方法については、5-4 ページの「ロード・バランシング」を参照してください。）ご使用のアプリケーション・コードで同期化を頻繁に行ったり、新しいJava オブジェクトを多数作成する場合、JServ プロセスの数を増やし、一方で 1 プロセスあたりのスレッド数を10 から 20 に制限することを考慮する必要があります。これにより、JVM のオブジェクトの同期化に必要なキューイングや処理の増加を回避できます。httpd プロセス（mod_jserv）が着信リクエストを分散してJServ プロセスに送信するためです。使用可能な JServ エンジ表表表 表 3-3 サーブレットとサーブレットとサーブレットとサーブレットと OracleJSP のメモリーのメモリーのメモリーのメモリーコンポーネントコンポーネントコンポーネントコンポーネント JDK 1.1.8 JDK 1.2 サーブレット 10MB 24MB OracleJSP 10MB 32MB

(35)

サイズ設定および構成 3-7 ン間でリクエストを分散する方法については、5-4 ページの「ロード・バランシング」を参照してください。（Oracle Application Server を熟知している方は、あるサーブレット・エンジンのスレッドの制限に達するまでリクエストがそのサーブレット・エンジンに送信され、

その後のリクエストは次のサーブレット・エンジンに送信されることをご存知でしょう。）

図図図

(36)

(37)

HTTPサーバーのパフォーマンスの最適化 4-1

4

HTTP

サーバーのパフォーマンスの最適化

この章では、TCP パラメータのチューニング、MaxClients パラメータの変更による効果、 SSL のキャッシュおよびロギングなど、Oracle HTTP Server のパフォーマンス改善について説明します。

内容

■ TCP のチューニング ■ MaxClients ■ SSL セッション・キャッシュ ■ ロギングの影響 ■ HTTP/1.1 ■ Apache のバージョン

(38)

TCPのチューニング

TCP

のチューニング

TCP パラメータを正しくチューニングすると、パフォーマンスが著しく改善されます。この項では、TCP チューニングの推奨事項と、各パラメータの簡単な説明を示します。次の表に、推奨するTCP パラメータ設定を示します。表表表 表 4-1 推奨する推奨する推奨する推奨する TCP パラメータ設定（パラメータ設定（パラメータ設定（パラメータ設定（Intel Solaris の場合）の場合）の場合）の場合）パラメータパラメータパラメータパラメータ設定設定設定設定コメントコメントコメントコメント tcp_conn_hash_size ₃₂₇₆₈ _{4-6 ページの}_{「TCP 接続テーブル} のアクセス速度の増加」を参照してください。 tcp_close_wait_interval 60000 Solaris 2.6 のパラメータ名。4-6 ページの「接続テーブルのエントリの保存期間の指定」を参照してください。 tcp_time_wait_interval 60000 Solaris 2.7 のパラメータ名。4-6 ページの「接続テーブルのエントリの保存期間の指定」を参照してください。 tcp_conn_req_max_q 1024 4-7 ページの「ハンドシェークのキューの長さの増加」を参照してください。 tcp_conn_req_max_q0 1024 4-7 ページの「ハンドシェークのキューの長さの増加」を参照してください。 tcp_slow_start_initial 2 4-8 ページの「データ転送率の変更」を参照してください。 tcp_xmit_hiwat 32768 4-8 ページの「データ転送ウィンドウ・サイズの変更」を参照してください。 tcp_recv_hiwat 32768 4-8 ページの「データ転送ウィンドウ・サイズの変更」を参照してください。

(39)

TCPのチューニング HTTPサーバーのパフォーマンスの最適化 4-3 表表表 表 4-2 パフォーマンス・ベンチマークのためのパフォーマンス・ベンチマークのためのパフォーマンス・ベンチマークのためのパフォーマンス・ベンチマークのための HP-UX のチューニングのチューニングのチューニングのチューニングパラメータパラメータパラメータパラメータスコープスコープスコープスコープデフォルト値デフォルト値デフォルト値デフォルト値チューニング後の値チューニング後の値チューニング後の値チューニング後の値 tcp_time_wait_interval ndd/dev/tcp 60,000 60,000 tcp_conn_req_max ndd/dev/tcp 20 1,024 tcp_ip_abort_interval ndd/dev/tcp 600,000 60,000 tcp_keepalive_interval ndd/dev/tcp 7,20,00,000 900,000 tcp_rexmit_interval_initial ndd/dev/tcp 1,500 1,500 tcp_rexmit_interval_max ndd/dev/tcp 60,000 60,000 tcp_rexmit_interval_min ndd/dev/tcp 500 500 tcp_xmit_hiwater_def ndd/dev/tcp 32,768 32,768 tcp_recv_hiwater_def ndd/dev/tcp 32,768 32,768 表表表 表 4-3 Tru64 TCP/IP でチューニング可能な値でチューニング可能な値でチューニング可能な値でチューニング可能な値パラメータパラメータパラメータパラメータモジュールモジュールモジュールモジュールデフォルト値デフォルト値チューニング後の値デフォルト値デフォルト値チューニング後の値チューニング後の値チューニング後の値 tcbhashsize sysconfig -r inet 512 16,384

tcbhashnum sysconfig -r inet 1 16（5.0 の場合） tcp_keepalive_default sysconfig -r inet 0 1

tcp_sendspace sysconfig -r inet 16,384 65,535 tcp_recvspace sysconfig -r inet 16,384 65,535 somaxconn sysconfig -r socket 1,024 65,535 sominconn sysconfig -r socket 0 65,535 sbcompress_threshold sysconfig -r socket 0 600

(40)

TCPのチューニング

Linux

でチューニング可能な設定

Linux

システム

システム 2.1.100

システム

2.1.100

2.1.100 以上でのネットワーク制約の拡張

以上でのネットワーク制約の拡張

Linux では、15 ビットの TCP ウィンドウ・フィールドのみを使用できます。このため、すべてを2 倍にするか、あるいはこの制約のないカーネルを再コンパイルする必要があります。

実行中のシステムのチューニング

カーネル値を変更するための sysctl アプリケーションは存在しません。 VI などのエディタを使用してカーネル値を変更できます。

デフォルトおよび最大サイズのチューニング

次にリストするファイルを編集してカーネル値を変更します。表表表 表 4-4 AIX TCP パラメータ（コマンドを使用しない場合）パラメータ（コマンドを使用しない場合）パラメータ（コマンドを使用しない場合）パラメータ（コマンドを使用しない場合）パラメータパラメータパラメータパラメータモデルモデルモデルモデルデフォルト値デフォルト値デフォルト値デフォルト値推奨値推奨値推奨値推奨値 rfc1323 /etc/rc.net 0 1 sb_max /etc/rc.net 65,536 131,072 tcp_mssdflt /etc/rc.net 512 1,024 ipqmaxlen /etc/rc.net 50 100 tcp_sendspace /etc/rc.net 16,384 65,536 tcp_recvspace /etc/rc.net 16,384 65,536 xmt_que_size /etc/rc.net 30 150 関連項目関連項目関連項目 関連項目 : 4-5 ページの「コンパイル時のチューニング」表表表 表 4-5 Linux TCP パラメータパラメータパラメータパラメータファイル名ファイル名ファイル名ファイル名詳細詳細詳細詳細 /proc/sys/net/core/rmem_default デフォルトの受信ウィンドウ /proc/sys/net/core/rmem_max 最大受信ウィンドウ /proc/sys/net/core/wmem_default デフォルトの送信ウィンドウ /proc/sys/net/core/wmem_max 最大送信ウィンドウ

(41)

TCPのチューニング HTTPサーバーのパフォーマンスの最適化 4-5 /proc/sys/net/ipv4/では、次に示すように、他にもTCP をチューニングできる部分があります。 ■ tcp_timestamps ■ tcp_windowscaling ■ tcp_sack /Documentation/networking/ip-sysctl.txtには、TCP パラメータの簡単な説明が記載されています。

コンパイル時のチューニング

前述のTCP パラメータ値は、Linux カーネルのソース・ディレクトリである /LINUX-SOURCE-DIR/include/linux/skbuff.h内のヘッダー・ファイルで、すべてデフォルト値が設定されています。デフォルト値は次のとおりです。これは実行時に設定可能です。 # ifdef CONFIG_SKB_LARGE #define SK_WMEM_MAX 65535 #define SK_RMEM_MAX 65535 # else #define SK_WMEM_MAX 32767 #define SK_RMEM_MAX 32767 #endif Linux カーネルのソース・ディレクトリ /LINUX-SOURCE-DIR/include/net/tcp.h の MAX_WINDOW 値は変更可能です。 #define MAX_WINDOW 32767 #define MIN_WINDOW 2048 MIN_WINDOWの定義により、TCP のパケット・ヘッダーで使用可能なウィンドウ・フィールドは15 ビットに制限されます。たとえば、40KB のウィンドウを使用する場合、rmem_default を 40KB に設定するとします。スタックは、値が 64KB 未満であることを認識し、winshift のネゴシエーションを行いません。しかし、2 番目のチェックにより、32KB しか確保されません。このため、強制的に winshift=1 となるようにするには、rmem_default 値を 64KB より大きな値に設定する必要があります。これにより、必要とする40KB を 15 ビットのみで表現できるようになります。注意注意注意 注意 : ウィンドウの拡張を行わずに、ウィンドウに32768 以上の値を割り当てないでください。

Oracle9i Application Server for UNIX Oracle HTTP Server powered by Apacheパフォーマンス・ガイド, リリース1.0.2