10g（10.1.3.1.0）
B31864-01
 目次 |
 索引 |
| Oracle Application Server mod_plsqlユーザーズ・ガイド 10g（10.1.3.1.0） B31864-01 |
|
この章では、Oracle HTTP ServerでのPL/SQLのパフォーマンスを向上させるための方法について説明します。
この章の内容は、次のとおりです。
この項では、Oracle HTTP ServerでPL/SQLベースのWebアプリケーションのパフォーマンスを向上させるためのいくつかの方法について説明します。
表4-1に、データベース・アクセス記述子（DAD）のパラメータおよび設定の推奨事項を示します。デフォルトでは、これらのDADパラメータは、dads.confファイルに指定されます。このファイルは、UNIXシステムの場合、ORACLE_HOME/Apache/modplsql/confディレクトリにあります。Windowsシステムの場合、デフォルトでは、ORACLE_HOME¥Apache¥modplsql¥confディレクトリにあります。このディレクトリのdads.READMEファイルには、DADパラメータについて詳細に説明されています。
| パラメータ | 推奨設定 |
|---|---|
|
|
デフォルト値: |
|
|
新しいDADには、 注意: データベースのHA構成では、接続文字列パラメータはLDAP検索を介して解決されるように設定することをお薦めします。 |
|
|
日本語や中国語などのマルチバイト・キャラクタ・セットの場合、
デフォルト値: |
|
|
このパラメータの値を増加すると、プールされたデータベース接続が、プール内で指定された時間、使用可能な状態を維持できます。 |
|
|
オラクル社カスタマ・サポート・センターからデバッグの目的で薦められないかぎり、
デフォルト値: |
|
|
接続プール内で停止中の接続を検出するためにmod_plsqlが使用するオプションを指定します。オプションは次のとおりです。
|
|
|
mod_plsqlにプールされた接続のテストに対するタイムアウトを（ミリ秒単位で）指定します。 関連項目: 3.11.3.2項「タイムアウト期間の指定」 |
|
|
PL/SQLベースのWebアプリケーションがリソースまたはメモリーをリークしない場合は、このパラメータをさらに高い値（5000など）に設定できます。 関連項目: 3.11.2項「プールされたデータベース・セッションのクローズ」および4.3.2項「接続プーリングのヒントおよびOracle HTTP Server構成」 |
|
|
データベースのグローバリゼーション・サポートのパラメータと一致するように設定すると、Oracle Net Servicesでのキャラクタ・セット変換におけるオーバーヘッドを削減できます。 |
|
|
データベースがリリース8.1.7.2以上の場合、このパラメータを |
表4-2に、mod_plsqlのキャッシング・オプションと、そのオプションを説明している関連項目を示します。
| オプション | 説明 |
|---|---|
|
期限方式 |
定期的に変わるコンテンツに対して、最高のパフォーマンスを提供します。 関連項目: 3.10.2項「期限方式の使用」 |
|
検証方式 |
不定期に変わるコンテンツに対して、良好なパフォーマンスを提供します。 関連項目: 3.10.1項「検証方式の使用」 |
|
システム・レベル・キャッシング |
システム上のすべてのユーザーに対して1つのコピーをキャッシュすることにより、パフォーマンスを向上させます。 関連項目: 3.10.3項「PL/SQLベースのWebアプリケーションでのシステム・レベルおよびユーザー・レベルのキャッシング」 |
|
関連資料
|
この項では、Oracle HTTP Serverがプロセス・ベースであるプラットフォームとスレッド・ベースであるプラットフォームである場合に当てはまるPL/SQLのパフォーマンス問題について説明します。プロセス・ベースのOracle HTTP Server（UNIXベースのプラットフォームで稼働するものなど）では、サーブレット、PL/SQL、静的ファイルを含め、すべてのタイプのHTTPリクエストを各プロセスで処理します。スレッド・ベースのOracle HTTP Server（Windowsベースのプラットフォームなど）では、Oracle HTTP Serverプロセスは1つしかなく、複数のスレッドがプロセス内にあり、個々のスレッドを使用してすべてのタイプのHTTPリクエストを処理できます。
mod_plsqlを使用する際、パフォーマンスおよびスケーラビリティに影響を及ぼす領域は次のとおりです。
PL/SQL Gatewayユーザーは、PL/SQLベースのWebアプリケーションを開発する際に、次の項目について考慮する必要があります。
各Oracle HTTP Serverノードで使用されるDADの数を制限してください。
PL/SQLでは表を作成できます。PL/SQL表を作成するには、表の索引およびデータ型を持つ表を作成します。表の索引は、-2147483647〜+2147483647の2進整数です。この表索引オプションは、スパースと呼ばれ、顧客番号、従業員番号あるいはその他の便利な索引キーなど、重要な索引番号を使用できます。PL/SQL表は、大量データの処理に使用します。
PL/SQLには、TABLEおよびVARRAY（可変サイズ配列）のコレクション型があります。TABLEコレクション型は、ネストした表と呼ばれます。ネストした表は、サイズに制限がなく、スパースにできます。つまり、ネストした表内の要素はDELETEプロシージャを使用して削除できます。可変サイズ配列は、サイズに制限があり、データベースに格納される際に順序および添字を保持します。ネストした表のデータは、その表に関連付けられたシステム表に格納されます。可変サイズ配列は、アプリケーションがバッチ配列スタイルでデータを処理するバッチ操作に適しています。ネストした表は、ネストした表を格納表に格納して、各要素を格納表の行にマッピングすることで、問合せを効率的に行うことができます。
PL/SQLベースのWebアプリケーションでは、プロシージャ名のオーバーロード機能の使用に注意する必要があります。複数のプロシージャに異なる名前を付けて、プロシージャ名のオーバーロードを回避することが最良の方法です。
PL/SQLベースのWebアプリケーションでは、パラメータ・タイプ（スカラーや配列など）の詳細がURLから十分に提供されないプロシージャの実行におけるオーバーヘッドに注意する必要があります。このような場合、プロシージャを実行する最初の試みに失敗すると、mod_plsqlによって実行できるようにするためには、プロシージャ・シグネチャを記述する必要があります。
プロシージャでは、4パラメータ・スタイルのパラメータの受渡しではなく、パフォーマンスの高い2パラメータ・スタイルの柔軟なパラメータの受渡しを利用します。
Oracle HTTP Serverで接続プーリングを構成する際、次の項目について考慮してください。
PlsqlMaxRequestsPerSessionの設定値の使用新しいデータベース接続の作成はコストの高い操作であるため、各リクエストが独自のデータベース接続をオープンおよびクローズしないことが最も重要です。最適な方法は、あるリクエストでオープンされたデータベース接続が、後続のリクエストで確実に再利用されるようにすることです。まれなケースですが、データベースへのアクセスが非常に少なく、パフォーマンスが重要な問題ではない場合には、接続プーリングは無効化してもかまいません。たとえば、管理者がまれにサイトにアクセスして管理タスクを行う場合、管理アプリケーションへのアクセスに使用されるDADで、接続プーリングを無効化できます。接続プーリングを無効化するには、DADパラメータPlsqlMaxRequestsPerSessionを値1に設定します。
httpdプロセスの数を、システムに対する平均の負荷を処理できるように設定する必要があります。さらに、httpd.confファイルの構成パラメータMaxClientsは、同様に、ランダムに発生する負荷の急激な上昇を処理できる必要があります。
MaxRequestsPerChild構成パラメータが高い数値に設定されていることを確認してください。PL/SQLベースのWebアプリケーションの場合は、このパラメータを0（ゼロ）に設定しないでください。
KeepAliveを無効にする必要があります。これにより、各プロセスは、現在のリクエストの処理が完了するとただちに他のクライアントからのリクエストを処理できるようになります。負荷が低く、Oracle HTTP Serverプロセスの数が常にOracle HTTP Serverリスナーに対する同時リクエストの数より多いサイトの場合、KeepAliveパラメータを有効にすると、パフォーマンスは向上します。このような場合、必ずKeepAliveTimeoutパラメータを適切にチューニングしてください。
Timeoutの値を低くすることもできます。これにより、クライアントが適時にレスポンスを返さない場合、Oracle HTTP Serverプロセスはより早く解放されます。この値を低くしすぎないでください。値が低すぎると、その値より遅いクライアントのレスポンスがタイムアウトします。
mod_expiresでタグ付けすることで、システムに対する負荷を大幅に減らすことができます。また、Oracle Application Server Web CacheでWebサイトをフロントエンドにすることも検討してください。
mod_expiresの使用が有効かどうかを確認する方法
「ページ情報を表示」（または使用しているブラウザのこれに相当するコマンド）を選択します。ページ情報ウィンドウのトップ・パネルに、様々なイメージおよび静的コンテンツが多数表示される場合、そのサイトでのmod_expiresの使用は有効です。
grepユーティリティを使用してaccess_logの304を検索し、この結果の行数をaccess_logの合計の行数で割ります。この割合が高い場合、そのサイトでのmod_expiresの使用は有効です。
Locationディレクティブを探します。ExpiresActiveおよびExpiresDefaultディレクティブを追加します。
Alias /images/ "/u01/app/oracle/myimages/" <Directory "/u01/app/oracle/myimages/"> AllowOverride None Order allow, deny Allow from all ExpiresActive On ExpiresDefault A2592000 </Directory>
/imagesパスからキャッシュします。詳細は、『Oracle HTTP Server管理者ガイド』を参照してください。
Expiresヘッダーでタグ付けされているかどうかを確認する方法
Expiresヘッダーでタグ付けされたイメージがあるWebページを開きます。ページでマウスを右クリックし、ポップアップ・メニューから「ページ情報を表示」を選択します。または、使用しているブラウザのこれに相当するコマンドを使用します。
Expiresヘッダーでタグ付けされているイメージを選択します。
Expiresヘッダーは有効な日付に設定されています。このエントリが「指定されていません」となっている場合、そのファイルはExpiresヘッダーでタグ付けされていません。
データベース・セッションの数をチューニングする際、次の項目について考慮してください。
init$SID.ora構成ファイルのprocessesおよびsessionsパラメータは、Oracleで最大数のデータベース・セッションを処理できるように設定する必要があります。この数は、DADの数にOracle HTTP Serverプロセスの最大数を掛け、さらにOracle HTTP Serverインスタンスの数を掛けた値に比例します。
Oracle HTTP Serverがプロセス・ベースであるプラットフォーム（すべてのUNIXベースのプラットフォームなど）では、サーブレット、PL/SQL、静的ファイルおよびCGIを含め、すべてのタイプのHTTPリクエストを各プロセスで処理します。1つのOracle HTTP Serverリスナー設定で、各httpdプロセスはデータベースへの独自の接続プールを保持します。データベース・セッションの最大数は、httpd.conf構成ファイルのStartServers、MinSpareServersおよびMaxSpareServersの設定およびシステムに対する負荷により決まります。このアーキテクチャでは、mod_plsqlリクエストの数に基づいてデータベース・セッションの数をチューニングできません。mod_plsqlリクエストの数に基づいてデータベース・セッションの数をチューニングするには、mod_plsqlリクエスト専用に別のHTTPリスナーをインストールします。この方法により、mod_plsqlリクエストの処理に必要なデータベース・セッションの数を大幅に減らすことができます。
たとえば、メインのOracle HTTP Serverリスナーがmylsnr1.mycompany.comのポート7777で稼働しているとします。まず、別のOracle HTTP Serverリスナーをmylsnr2.mycompany.comのポート8888にインストールします。次に、mylsnr1.mycompany.com:7777に対して行われたすべてのmod_plsqlリクエストを、mylsnr2.mycompany.com:8888の2番目のリスナーにリダイレクトします。手順は次のとおりです。
mylsnr1.mycompany.com:7777に対するすべてのPL/SQLリクエストをmylsnr2.mycompany.com:8888にリダイレクトするには、次のように構成を変更します。
ORACLE_HOME/Apache/modplsql/conf/plsql.confファイルを編集します。行の先頭に#を挿入して、次の行をコメント化します。
#LoadModule plsql_module...
mylsnr1.mycompany.comのPL/SQLリクエストの処理に使用されるDADの場所を、mylsnr2.mycompany.comのORACLE_HOME/Apache/modplsql/conf/dads.conf構成ファイルにコピーします。 行の先頭に#文字を挿入して、mylsnr1.mycompany.com上のDADの場所の構成パラメータをコメント化します。
#<Location /pls/portal> #... #</Location>
dads.confに追加して、このDADの場所に対するすべてのmod_plsqlリクエストを2番目のリスナーに転送するように、このリスナーを設定します。
ProxyPass /pls/portal http://mylsnr2.mycompany.com:8888/pls/portal
すべてのDADの場所について、この設定の手順を繰り返します。
mylsnr2.mycompany.com:8888の内部mod_plsqlリスナーを参照せずに構成されていることが重要です。PL/SQLベースのWebアプリケーションでURLがどのように生成されるかにより、次の3つのオプションがあります。
SERVER_NAMEおよびSERVER_PORTを使用する場合、mylsnr2.mycompany.comのリスナーの構成を変更することは簡単です。ファイルを編集し、2番目のリスナーのORACLE_HOME/Apache/conf/httpd.confファイルのServerNameおよびPort行を次のように変更します。
ServerName mylsnr1.mycompany.com (was mylsnr2.mycompany.com) Port 7777 (was 8888)
HTTP_HOSTを使用して生成されている場合、ポート8888で稼働しているOracle HTTP ServerリスナーのCGI環境変数をオーバーライドする必要があります。各DADのORACLE_HOME/Apache/modplsql/conf/dads.confファイルに次の行を追加して、デフォルトのCGI環境変数HOST、SERVER_NAMEおよびSERVER_PORTをオーバーライドします。
PlsqlCGIEnvironmentList SERVER_NAME mylsnr1.mycompany.com PlsqlCGIEnvironmentList SERVER_PORT 7777 PlsqlCGIEnvironmentList HOST mylsnr1.us.oracle.com:7777
いかなる場合でも、目的はアプリケーションに2番目のリスナーが存在しないかのように見せかけて、URLを生成することです。
mylsnr1.mycompany.comのメインのリスナーは、Oracle HTTP Serverリスナーに対する合計の負荷に基づいて設定できます。mylsnr2.mycompany.comの2番目のリスナーは、実行されるmod_plsqlリクエストのみに基づいて細かくチューニングできます。
一部のストアド・プロシージャの実行時、mod_plsqlにDescribeのオーバーヘッドが発生することがあり、その結果、実行を正常終了するために、データベースへのラウンドトリップが2回余分に発生します。これは、パフォーマンスと密接な関係があります。
PL/SQLプロシージャを実行するために、mod_plsqlは、渡されるパラメータのデータ型を認識する必要があります。この情報に基づいて、mod_plsqlは、各パラメータを配列またはスカラーとしてバインドします。プロシージャ・シグネチャを認識するための1つの方法は、プロシージャを実行前に記述することです。ただし、この方法は、各プロシージャを実行前に記述する必要があるため、効率的ではありません。Describeのオーバーヘッドを回避するには、mod_plsqlでパラメータ名ごとに渡されるパラメータの数を調べるようにします。この情報を使用して、各変数のデータ型を推定します。このロジックは単に、渡される値が1つの場合はそのパラメータをスカラーとし、それ以外の場合は配列とします。これは、ほとんどの場合において機能しますが、1つの値を配列パラメータに渡そうとしたり、複数の値をスカラーに渡そうとしている場合には機能しません。このような場合、プロシージャを実行する最初の試みに失敗します。mod_plsqlはDescribeコールを発行して、PL/SQLプロシージャのシグネチャを取得し、Describe操作で取得した情報に基づいて各パラメータをバインドします。プロシージャは再実行され、結果が戻されます。
このDescribeコールは、プロシージャに対して透過的に発生しますが、mod_plsqlの内部では、ラウンドトリップが2回余分に発生します。1回は実行に失敗したコールのため、もう1回はDescribeコールのためです。
次のようにして、パフォーマンスの問題を回避できます。
CREATE OR REPLACE PACKAGE testpkg AS TYPE myArrayType is TABLE of VARCHAR2(32767) INDEX BY binary_ integer; PROCEDURE arrayproc (arr myArrayType); END testpkg; /
/pls/.../testpkg.arrayproc? arr= 1のようなURLコールを作成している場合、仕様を次のように変更します。
CREATE OR REPLACE PACKAGE testpkg AS TYPE myArrayType is TABLE of VARCHAR2( 32767) INDEX BY binary_integer; PROCEDURE arrayproc (arr varchar2); PROCEDURE arrayproc (arr myArrayType); END testpkg; /
arrayprocは、次のようになります。
CREATE OR REPLACE PACKAGE BODY testpkg AS PROCEDURE arrayproc (arr varchar2) IS localArr myArrayType; BEGIN localArr( 1) := arr; arrayproc (localArr); END arrayproc;
ラウンドトリップのオーバーヘッドは、PL/SQLプロシージャが古いスタイルの4パラメータ・インタフェースを使用している場合に発生します。PL/SQL Gatewayは、最初に2パラメータ・インタフェースを使用してプロシージャの実行を試みます。これに失敗すると、PL/SQL Gatewayは4パラメータ・インタフェースを使用します。つまり、すべての4パラメータ・インタフェースのプロシージャでは、ラウンドトリップが1回余分に発生します。
このオーバーヘッドを回避するには、対応するラッパーを作成して、2パラメータ・インタフェースを使用しながら内部的に4パラメータ・インタフェースのプロシージャをコールするようにすることをお薦めします。もう1つのオプションは、元のプロシージャの仕様を変更して、渡されないパラメータをデフォルトとして2パラメータ・インタフェースに設定することです。4パラメータ・インタフェースは、下位互換性のためにのみ提供されていますが、将来的には使用されなくなります。
Oracle HTTP Serverの柔軟なパラメータの受渡しモードでは、PL/SQLプロシージャのプロシージャ名の前に感嘆符が付いていると想定しています。Oracle HTTP Serverで使用されている自動検出方法はパフォーマンスと密接に関係するため、現在、Oracle HTTP Serverでの柔軟なパラメータの受渡しには感嘆符が必須です。Oracle HTTP Serverでは、各プロシージャは実行前に完全に記述されます。プロシージャDescribeコールにより、プロシージャのシグネチャが決まり、データベースへのラウンドトリップが必要となります。Oracle HTTP ServerのPL/SQL Gatewayでは、エンド・ユーザーがプロシージャの前に感嘆符を追加して、明示的に柔軟なパラメータの受渡し規則を指定することにより、このラウンドトリップを回避します。
ファイル・システム・キャッシュを構成し、使用すると、OracleAS Portalアプリケーションおよび一般的なPL/SQLベースのWebアプリケーションのパフォーマンスを向上させることができます。
この項の内容は、次のとおりです。
この項では、mod_plsqlに関連するファイル・システム・キャッシュのチューニング・オプションについて説明します。キャッシュ・コンテンツは、オペレーティング・システム付属のファイル・システム・コールを使用してキャッシュされますが、キャッシュされたコンテンツはmod_plsqlのメモリー領域には格納されません。mod_plsqlのファイル・システム・キャッシュを使用していても、メモリー・ディスクなどの機能がオペレーティング・システムでサポートされ、それを使用するようにシステムが構成されている場合（一部のUNIXプラットフォームはメモリー・ディスク・ベースの高速格納をサポートしています）、キャッシュ・コンテンツはメモリーに存在することがあります。
この項の情報を使用すると、mod_plsqlがファイル・システム・キャッシュを使用するように構成されている場合に、PL/SQLベースのWebアプリケーションのパフォーマンスを向上させることができます。たとえば、OracleAS Portalではファイル・システム・キャッシュを使用しています。そのため、ファイル・システム・キャッシュが適切にチューニングされれば、OracleAS Portalのパフォーマンスは向上します。
表4-3に、mod_plsqlに対して設定できるキャッシュ関連のパラメータを示します。これらのパラメータをcache.confファイルに設定します。このファイルは、UNIXではORACLE_HOME/Apache/modplsql/confディレクトリに、WindowsではORACLE_HOME¥Apache¥modplsql¥confディレクトリにあります。
| パラメータ | 説明 |
|---|---|
|
|
キャッシュ・クリーン・アップ・ルーチンの実行間隔を設定します。 |
|
|
mod_plsqlのキャッシュを保持するディレクトリを定義します。
UNIXシステムでは、エラー・ログのデフォルト・ディレクトリは
Windowsシステムでは、デフォルト・ディレクトリは |
|
|
|
|
|
|
|
|
キャッシュに格納される個々のファイルの最大サイズをバイト単位で設定します。 関連項目: 4.4.4.3項「PlsqlCacheMaxSizeによるキャッシュ・ファイルの最大ファイル・サイズの設定」 |
|
|
cache.confのPlsqlCacheEnableパラメータにより、mod_plsqlキャッシングが使用できるようになります。パフォーマンスを最大化するには、PlsqlCacheEnableパラメータの値をOnに設定して有効にします。
この項では、別のディスク上にあるようにファイル・システム・キャッシュを構成する方法について説明します。ファイル・システム・キャッシュを使用し、より高速な別のディスク上にキャッシュを格納すると、OracleAS Portalや一般的なPL/SQLベースのWebアプリケーションなど、ファイル・システム・キャッシュを使用するすべてのタイプのWebアプリケーションについて、パフォーマンスは向上します。
ファイル・システム・キャッシュを構成する際、キャッシュを別の物理ディスクまたはメモリー・ディスクのいずれかに設定できます。
ファイル・システム・キャッシュを別のディスク上に設定するには、次のようにします。
UNIXの場合: /u01/cache
Windowsの場合: E:¥cache
UNIXの場合: ORACLE_HOME/Apache/modplsql/conf/cache.conf
Windowsの場合: ORACLE_HOME¥Apache¥modplsql¥conf¥cache.conf
PlsqlCacheDirectoryを次のように変更します。UNIXの場合: PlsqlCacheDirectory /u01/cache
Windowsの場合: PlsqlCacheDirectory E:¥cache
この項の内容は、次のとおりです。
デフォルトのインストールでは、mod_plsqlのファイル・システム・キャッシュ・サイズは2097152バイト（20MB）に設定されます。PL/SQLアプリケーションがOWA_CACHEパッケージを使用しない場合、またはパッケージを使用して少量のコンテンツをキャッシュする場合は、デフォルト設定で十分です。PL/SQLアプリケーションが大量のコンテンツをmod_plsqlのファイル・システム・キャッシュにキャッシュする場合、より高い値の指定を検討する必要があります。
キャッシュ・サイズを制御するには、cache.confファイルにPlsqlCacheTotalSizeパラメータを設定します。UNIXシステムでは、このファイルはORACLE_HOME/Apache/modplsql/confディレクトリにあります。Windowsシステムでは、このファイルはORACLE_HOME¥Apache¥modplsql¥confにあります。
高いキャッシュ・ヒット率を達成するのに十分なキャッシュ・サイズを設定する必要があります。頻繁にアクセスされるコンテンツがキャッシュされた状態を維持するのに十分な大きさのキャッシュ・サイズを設定するようにしてください。また、キャッシュ・サイズが大きくなりすぎないように、ディスク領域の量を制限することも重要です。キャッシュ・サイズを適切にチューニングすると、頻繁にアクセスされるコンテンツすべてを保持するために十分なキャッシュを提供する一方で、非常に大きなキャッシュの検索は非効率であることから、キャッシュ・サイズが大きくなりすぎるのを防ぐこともできます。
PlsqlCacheTotalSizeの値はバイト数で指定します。1MBは1048576バイトです。この設定は、割り当てられるキャッシュ量に対する弱い制限です。場合によっては、次のクリーン・アップ操作までに、キャッシュ・サイズがこの制限を超えて大きくなることがあります。そのため、キャッシュ・サイズに対する強い制限は、使用する物理ハード・ディスク・サイズとなります。この制限に達すると、領域が使用可能になるまで、キャッシュ・コンテンツをディスクに書き出すことができません。
適度なキャッシュ・サイズを決定するには、次のようにします。
httpd.confのLogLevelをinfoレベルに設定してmod_plsqlパフォーマンス・ロギングをオンにし、mod_plsqlロギングを使用できるようにします。
error_logを監視します。UNIXシステムでは、エラー・ログのデフォルト・ディレクトリはORACLE_HOME/Apache/Apache/logです。Windowsシステムでは、デフォルト・ディレクトリはORACLE_HOME¥Apache¥Apache¥logです。
mod_plsql error_logエントリは、次のような形式です。
[info] mod_plsql: cachecleanup deleted=2571 max_age=96,2178852b kept=1042,25585368b time=128s limit=25600000b
意味は次のとおりです。
deletedは、クリーン・アップ・プロセスで削除されたキャッシュ・ファイルの数です。
max_ageは、一定期間使用されていなかったために削除されたキャッシュ・ファイルの数および合計サイズです。
keptは、クリーン・アップ・プロセス後に保持されたキャッシュ・ファイルの数および合計サイズです。
timeは、クリーン・アップの実行にかかった時間です。
limitは、合計キャッシュ・サイズです。これは、PlsqlCacheTotalSize設定の値です。
エラー・ログのエントリは次のように解析します。
PlsqlCacheMaxAgeパラメータを使用すると、キャッシュ・コンテンツの古さを制御できます。パラメータの値は日数単位で指定します。このパラメータのデフォルト値は30（日）です。これは、キャッシュ・コンテンツが30日以内であれば、キャッシュに保存されることを意味します。30日を過ぎると、コンテンツはクリーン・アップ・プロセス時に削除対象とみなされます。
mod_plsql error_logのmax_age情報には、キャッシュ・ファイルのエージング情報が示されます。サイトが非常に動的なサイトである場合、この設定をより小さい値に構成します。古いキャッシュ・コンテンツは通常、再利用されないため、より小さい値がキャッシュ・ヒット率に影響を及ぼすことがないためです。サイトに多くの静的ページが含まれる場合、PlsqlCacheMaxAgeの値を増やし、クリーン・アップ・プロセスでキャッシュ・コンテンツが故意に削除されないようにします。
PlsqlCacheMaxSizeパラメータを使用すると、キャッシュに格納される個々のファイルの最大サイズを指定できます。このパラメータを使用することで、1つのキャッシュ・ファイルでキャッシュ全体がいっぱいになる状態を回避できます。
このパラメータのデフォルト値は1048576（バイト）です。一般に、このパラメータは、合計キャッシュ・サイズの約1〜3%の値に設定します。
キャッシュ・クリーン・アップ・パラメータにより、ファイル・システム・キャッシュを調査し、必要に応じてクリーン・アップする頻度が決まります。キャッシュ・クリーン・アップ・パラメータのPlsqlCacheCleanupTimeはcache.confファイルに指定されています。頻度は、毎日、毎週、毎月に設定できます。毎週のクリーン・アップを指定する場合、曜日と時刻を指定できます。
mod_plsqlのPlsqlCacheCleanupTimeのデフォルト設定は、現地時間の毎日午後11時です。そのため、デフォルトでは、毎晩午後11時にクリーン・アップ・ルーチンが実行されます。毎月の頻度を選択した場合、クリーン・アップは毎月第1土曜日に行われます。
クリーン・アップの頻度が高すぎるとキャッシュ・ヒット率が低くなり、クリーン・アップの頻度が低すぎるとキャッシュのディスク使用量が過多になるため、このパラメータを適切に設定することが重要です。
クリーン・アップ・アクティビティは、mod_plsql error_logのエントリを使用して監視します。エントリを分析して、クリーン・アップ・パラメータのPlsqlCacheCleanupTimeをチューニングします。
[info] mod_plsql: cachecleanup deleted=2571 max_age=96,2178852b kept=1042,25585368b time=128s limit=25600000b
次の事柄に注意してください。
Oracle HTTP ServerでのPL/SQLのパフォーマンスを向上させるには、使用している構成に対してOracle HTTP Serverのディレクティブを適切にチューニングする必要があります。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|