| Oracle® Databaseパフォーマンス・チューニング・ガイド 11gリリース2 (11.2) B56312-06 |
|
 前 |
 次 |
この章では、Oracle Databseのパフォーマンスを最適化するためのオペレーティング・システムのチューニング方法について説明します。
この章には次の項があります。
|
関連項目:
|
オペレーティング・システムのパフォーマンスの問題は、一般にプロセス管理、メモリー管理およびスケジューリングに関係します。Oracleデータベース・インスタンスをチューニングした後で、さらにパフォーマンスを改善する必要がある場合は、作業内容の確認またはシステム時間の短縮を試みてください。I/O帯域幅、CPU能力およびスワップ・スペースが十分にあることを確認してください。ただし、オペレーティング・システムをさらにチューニングしても、それがアプリケーションのパフォーマンスに大きな効果を与えることは期待できません。オペレーティング・システムの簡単なチューニングよりも、Oracle Database構成またはアプリケーションでの変更の方が、オペレーティング・システム効率に大きな差異が生じます。
たとえば、アプリケーションでbuffer busy waitsが非常に頻繁に発生する場合は、システム・コールの回数が増加します。アプリケーションをチューニングすることでbuffer busy waitsを削減すると、システム・コールの数が減少します。
この項では、オペレーティング・システムのパフォーマンスの問題に関する次の項目について説明します。
オペレーティング・システムおよびデバイス・コントローラには、Oracle Databaseのキャッシュ管理と直接に競合しないデータ・キャッシュがあります。ただし、これらの構造はリソースを消費し、パフォーマンスにおける利点はほとんどありません。この状況は、LinuxまたはUNIXファイル・システムに格納されたデータベース・ファイルにおいて最も顕著です。デフォルトでは、データベースのすべてのI/Oはファイル・システム・キャッシュを使用します。
一部のLinuxおよびUNIXシステムでは、直接I/Oのファイルストアを使用できます。この場合、ファイル・システム・キャッシュをバイパスして、ファイル・システム内でデータベース・ファイルにアクセスできます。直接I/OによるCPUリソースの節約によって、ファイル・システム・キャッシュをプログラム・テキストやスプール・ファイルなどの非データベース・アクティビティ専用にすることができます。
|
注意: この問題はWindowsでは発生しません。データベースから要求されたファイルは、すべてファイル・システム内のキャッシュをバイパスします。 |
Oracle Databaseバッファ・キャッシュにブロックが格納されるため、多くの場合、オペレーティング・システムのキャッシュは冗長な機能ですが、場合によっては、データベース・バッファ・キャッシュが使用されない場合もあります。この場合、直接I/OまたはRAWデバイスを使用すると、オペレーティング・システム・バッファを使用する場合よりも、パフォーマンスがさらに低下することがあります。これには次のような例があります。
TEMP表領域での読取りまたは書込み
NOCACHE LOBに格納されるデータ
パラレル問合せスレーブで読み取られるデータ
|
注意: パラレル問合せのデータは、ディスクからPGAに直接読み込むかわりに、データベース・バッファ・キャッシュにキャッシュできる場合があります。この構成は、データベース・サーバーのメモリー容量が大きい場合に適しています。パラレル実行の使用の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
キャッシュを使用する場合でも、オペレーティング・システム・レベルですべてのファイルをキャッシュするのは望ましくない場合があります。
同期I/Oでは、I/Oリクエストがオペレーティング・システムに発行されても、書込みの完了が確認されないかぎり書込みプロセスによってブロックされます。処理はその後で継続できます。非同期I/Oでは、I/Oリクエストが発行されて処理されている間も処理が継続されます。ボトルネックを回避できる場合は非同期I/Oを使用します。
プラットフォームには、デフォルトで非同期I/Oをサポートしているもの、特殊な構成が必要なもの、基礎となる一定のファイル・システム・タイプでのみ非同期I/Oをサポートしているものがあります。
FILESYSTEMIO_OPTIONS初期化パラメータを使用して、ファイル・システムのファイルについて非同期I/Oあるいは直接I/Oを、有効化または無効化することができます。このパラメータは、プラットフォーム固有であり、それぞれのプラットフォームに最適なデフォルト値が設定されています。
FILESYTEMIO_OPTIONSは、次のいずれかの値に設定できます。
ASYNCH: ファイル・システム・ファイル上の非同期I/Oを有効にします。非同期I/Oでは、転送に対する時間的な要件はありません。
DIRECTIO: ファイル・システム・ファイル上の直接I/Oを有効にします。直接I/Oでは、バッファ・キャッシュがバイパスされます。
SETALL: ファイル・システム・ファイル上の非同期および直接I/Oを有効にします。
NONE: ファイル・システム・ファイル上の非同期および直接I/Oを無効にします。
|
関連項目: 詳細は使用しているプラットフォーム固有のマニュアルを参照してください。 |
一部のNFSサーバー環境では、短期間に大量の非同期I/Oリクエストが作成されると、パフォーマンスが低下する場合があります。そのような場合には、DNFS_BATCH_SIZE初期化パラメータを使用してパフォーマンスを改善し、Oracleプロセスから発行されるI/O数を制限して、システムの安定性を高めます。
DNFS_BATCH_SIZE初期化パラメータは、Direct NFSが有効化されている場合に、Oracleフォアグラウンド・プロセスによってキューに入れることが可能な非同期I/Oの数を制御します。NFSサーバーで未処理の非同期I/Oリクエストを大量に処理できない環境では、このパラメータの値を128に設定することをお薦めします。その後、NFSサーバーのパフォーマンスに応じて、この値を増減できます。
|
注意: DNFS_BATCH_SIZE初期化パラメータのデフォルト設定は4096です。推奨値の128を適用できるのは、NFSサーバーで大量の非同期I/Oリクエストを処理できず、サーバー遅延が検出されるシステムのみです。 |
|
関連項目: DNFS_BATCH_SIZE初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
メモリー使用量は、バッファ・キャッシュの制限と初期化パラメータの両方の影響を受けます。
UNIXバッファ・キャッシュはオペレーティング・システムのメモリー・リソースを消費します。あるバージョンのUNIXでは、UNIXバッファ・キャッシュに一定量のメモリーを割り当てることができますが、現在ではより複雑なメモリー管理メカニズムが使用されるのが普通です。通常これらの管理メカニズムでは、I/Oをキャッシュするために空きメモリー・ページを使用できます。そのようなシステムでは、オペレーティング・システムのレポート・ツールは空きメモリーがないことを示すのが普通で、通常は問題になりません。プロセスがより多くのメモリーを必要とする場合、通常はI/Oデータをキャッシュするメモリーが開放されて、そのプロセス・メモリーを割り当てることができます。
一部のプラットフォームではオペレーティング・システム・リソース・マネージャが提供されます。これらは、CPUリソース割当てに優先順位を付けることによってピーク負荷使用パターンの影響を少なくするように設計されています。これらは通常、ユーザーがアクセス可能なリソースと各ユーザーがこれらのリソースのどの程度を消費可能かを統括する、管理方針を実装します。
オペレーティング・システム・リソース・マネージャは、ドメインや他の類似のファシリティとは異なります。ドメインは、1つのシステム内で1つ以上のまったく別の環境を提供します。ディスク、CPU、メモリーおよびその他すべてのリソースが各ドメイン専用となっており、他のドメインからアクセスできません。他の類似のファシリティは、異なる領域、通常個別のCPUまたはメモリー領域にシステム・リソースの一部のみを完全に分離します。ドメインと同様、個別のリソース領域はその領域に割り当てられた処理専用となっています。プロセスは境界を超えて移行できません。ドメインとは異なり、その他すべてのリソース(通常はディスク)は、システムのすべてのパーティションからアクセスできます。
Oracle Databaseはドメイン内で実行される他、パーティション化されたメモリー(RAM)リソースの割当てが動的でなく、固定されている場合は、その他の不完全なパーティション構造体内で実行されます。
オペレーティング・システム・リソース・マネージャは、リソースのグローバル・プール内、通常はドメインあるいはシステム全体内でのリソース割当てに優先順位を設定します。プロセスはグループに割り当てられ、グループはリソース・プール内の任意の場所にあるリソースに割り当てられます。
|
注意: 1つのノードに複数のインスタンスがあり、それらの間でリソースを配分する場合は、各インスタンスを専用のオペレーティング・システム・リソース・マネージャ・グループまたは管理対象エンティティに割り当てる必要があります。管理対象エンティティの複数のインスタンスを実行するには、インスタンス・ケージングを使用して管理対象エンティティ内のCPUリソースをインスタンス間で配分する方法を管理します。Oracle Database Resource Managerは、CPUリソースを管理するときに、各インスタンスに対するCPUリソースが一定量であると予測します。インスタンス・ケージングを使用しない場合は、使用可能なCPUリソースは管理対象エンティティ内のCPUの数と同じであると予測します。インスタンス・ケージングを使用する場合、使用可能なCPUリソースはCPU_COUNT初期化パラメータの値と同じであると予測します。CPUリソースが予測より少ない場合、Oracle Database Resource Managerでりソース計画のリソース割当てを実行したときに適切な結果が得られません。 |
この項では、様々なシステムでのチューニングのヒントを示します。次の項目について説明します。
プラットフォーム固有の問題をよく理解し、使用しているオペレーティング・システムが提供するパフォーマンス・オプションを認識してください。
|
関連項目: 使用しているプラットフォーム固有のOracleマニュアルおよび使用しているオペレーティング・システム・ベンダーのマニュアル |
UNIXシステムで、オペレーティング・システムのシステム・コールの処理やプロセス・スケジューリングの実行にかかる時間と、アプリケーションの実行時間とで、妥当な比率の確立を試みます。システム・モードではなく、アプリケーション・モード(ユーザー・モードとも呼ばれる)での実行に大部分の時間を費やすことを目標としてください。
各モードで消費される時間の比率は、潜在する問題の徴候にすぎず、次の項目に関係している可能性があります。
ページングまたはスワッピング
実行しているオペレーティング・システム・コールが多すぎる状態
実行しているプロセスが多すぎる状態
このような条件が存在する場合は、アプリケーションの実行に使用できる時間は少なくなります。オペレーティング・システム側の時間を多く解放するほど、アプリケーションが実行できるトランザクションの量が増えます。
UNIXベースのシステムと同様に、Windowsシステムでは、アプリケーション・モードの時間とシステム・モードの時間の比率を適切に設定してください。Windows管理パフォーマンス・ツールで多数の要因を容易に監視できます。CPU、ネットワーク、I/Oおよびメモリーはすべて、これらの領域でのボトルネックを容易に回避できるように同じグラフ上に表示されます。
メインフレームのページング・パラメータを検討し、Oracle Databaseが非常に大きな作業セットを利用できる点に留意します。
HP OpenVMS環境での空きメモリーは、どのオペレーティング・システム・プロセスにも実際にマップされていないメモリーです。ビジーなシステムでは、空きメモリーに、1つ以上の現行のアクティブ・プロセスに属するページが含まれる可能性があります。これがアクセスされるとソフト・ページ・フォルトが発生し、ページはそのプロセスの作業セットに組み込まれます。プロセスが作業セットを拡張できない場合は、プロセスによって現在マップされているページの1つを空きセットに移動する必要があります。
任意の数のプロセスが、作業セット内に共有メモリーのページを持つことができます。したがって、作業セットのサイズの合計が使用可能メモリーを著しく超過することがあります。通常、Oracleサーバーを実行している場合、SGA、Oracle Databaseカーネル・コードおよびOracle Formsランタイム実行可能ファイルはすべて共有可能であり、これらはページ・アクセスのおよそ80%または90%を占めます。
CPUの問題に対処するには、最初に、システムのCPUリソースの使用量について、適切な見積りを設定します。次に、十分なCPUリソースが使用可能かどうかを判断し、システムがいつリソースを使用しすぎているかを認識します。まず、次の3つのシステム状況において、Oracleデータベース・インスタンスのCPUリソースの使用量を判断します。
システムがアイドル状態で、少数のOracle Databaseおよび非Oracleアクティビティが存在する場合
システムが平均ワークロードの場合
システムがピーク・ワークロードの場合
自動ワークロード・リポジトリ、StatspackまたはUTLBSTAT/UTLESTATユーティリティを使用して、様々なワークロードのスナップショットを取得できます。UNIXのvmstat、sarおよびiostatや、Windowsの管理パフォーマンス・モニタリング・ツールなどのオペレーティング・システム・ユーティリティは、V$OSSTATやV$SYSMETRIC_HISTORYビューとともに、自動ワークロード・リポジトリ、Statspack、UTLBSTAT/UTLESTATなどと同じ時間間隔で使用し、統計全体の補完ビューを提供することができます。
システムのCPU使用率のレベルを評価するときには、ワークロードが重要な要因となります。ピーク・ワークロード時には、CPU使用率が90%の場合アイドルは10%であり、待機時間が発生するのは受容できます。低ワークロード時に使用率が30%となるのも理解できます。しかし、システムが標準のワークロードで高い使用率を示している場合は、ピーク・ワークロードに耐える余裕がありません。次に、図9-1において、午前10:00と午後2:00にピークとなるアプリケーションのワークロードの時間に伴う変化の例を示します。
この例のアプリケーションでは、1日に8時間作業するユーザーが100人います。各ユーザーが5分ごとに1つのトランザクションを入力すると、1日のトランザクションは9,600になります。8時間にわたってシステムは1時間当たり1,200のトランザクションをサポートする必要があり、1分当たり平均20トランザクションをサポートする必要があります。需要率が一定の場合は、この平均ワークロードを満たすようにシステムを構築します。
ただし、使用率のパターンは一定ではないので、この場合、1分当たり20トランザクションというのは単なる最低条件と考えられます。達成する必要があるピークの割合が1分当たり120トランザクションの場合は、このピーク・ワークロードをサポートできるシステムを構成する必要があります。
この例では、ワークロードがピークのときにOracle DatabaseがCPUリソースの90%を使用するとします。この場合、平均的なワークロード期間にOracle Databaseが使用するのは、次の等式が示すように、使用可能なCPUリソースの約15%以下です。
20 tpm / 120 tpm * 90% = 15% of available CPU resource
ここで、tpmは1分当たりのトランザクション数を表します。
システムが20 tpmを達成するためにCPUリソースの50%を必要とする場合は、問題があります。これでは、CPUの90%を使用しても1分当たり120トランザクションを処理できません。しかし、CPUの15%のみを使用して20 tpmを達成するようにこのシステムをチューニングした場合は、(線形のスケーラビリティを前提とすると)CPUリソースの90%を使用して1分当たり120トランザクションを処理できます。
アプリケーションを使用するユーザーが増加するにつれて、ワークロードがかつてのピーク・レベルにまで上昇する可能性があります。そのときには、実際には以前よりも高くなった新しいピークの割合に対応できるCPU能力はありません。
CPU容量の問題は、次のように解決します。
CPUを過剰に消費する問題を検出し、解決します。詳細は、「CPU使用率の確認およびチューニング」を参照してください。
Oracle Database Resource Managerを使用してCPUリソースの割当てに優先順位を設定して、負荷ピーク時の使用パターンの影響を緩和します。詳細は、「Oracle Database Resource Managerを使用したCPUリソースの管理」を参照してください。
複数のCPUを搭載したシステムで複数のデータベース・インスタンスを実行する場合、インスタンス・ケージングを使用してデータベース・インスタンスが同時に使用できるCPU数を制限します。詳細は、「インスタンス・ケージングを使用したCPUリソースの管理」を参照してください。
ハードウェア・キャパシティを増加し、システム・アーキテクチャを改善します。詳細は、「システム・アーキテクチャ」を参照してください。
システムで実行されているすべてのプロセスは、使用可能なCPUリソースに影響を与えます。したがって、データベース以外の要素をチューニングすることで、データベースのパフォーマンスが向上する場合もあります。
V$OSSTATまたはV$SYSMETRIC_HISTORYビューを使用して、オペレーティング・システムからのシステム使用率統計を監視します。V$OSSTATおよびV$SYSMETRIC_HISTORYに含まれる有用な統計には、次のものがあります。
CPUの数
CPU使用率
負荷
ページング
物理メモリー
|
関連項目: V$OSSTATおよびV$SYSMETRIC_HISTORYの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
システム全体で実行されているプロセスを確認するには、オペレーティング・システム・モニタリング・ツールを使用します。システムの負荷が非常に高い場合は、この項で後述するメモリー、I/Oおよびプロセス管理の各項目をチェックしてください。
多くのUNIXベースのシステムでは、sar -uなどのツールを使用して、システムのCPU使用率のレベルを確認できます。UNIXでは、統計情報に、ユーザー時間、システム時間、アイドル時間およびI/Oの待機時間が表示されます。標準ワークロードまたは低いワークロードで、アイドル時間およびI/O待機時間が0に近い場合(5%未満)、CPUの問題が存在します。
Windowsでは、管理パフォーマンス・ツールを使用してCPU使用率を監視できます。このユーティリティは、プロセッサ時間、ユーザー時間、特権時間(privileged time)、割込み時間およびDPC時間の統計を提供します。
この項では、システムのCPU使用率のチェックに関する次の項目について説明します。
|
注意: この項では、ほとんどのUNIXベース・システムおよびWindowsシステムにおけるCPU使用率のチェック方法を説明します。その他のプラットフォームについては、使用しているオペレーティング・システムのマニュアルを参照してください。 |
次のメモリー管理項目をチェックします。
V$OSSTATビュー、UNIXのsar、vmstatなどのユーティリティ、またはWindowsの管理パフォーマンス・ツールなどを使用して、ページングとスワッピングの原因を調査します。
スラッシングはI/O管理の課題です。コンピュータのスラッシング(メモリー内外のスワッピングおよびページング処理)が発生しないように、ワークロードがメモリーに収まることを確認してください。オペレーティング・システムは固定サイズのタイム・スライスをユーザーのプロセスに割り当て、プロセスはそのタイム・スライス中にCPUリソースを使用できます。プロセスが実行可能かどうか、および必要な構成要素がすべてコンピュータにあるかどうかを確認するために時間の大半を浪費している場合、実際の処理に使用される時間は、割り当てられた時間の50%のみである可能性があります。
クライアント/サーバーのラウンドトリップをチェックします。メッセージを処理する際にはオーバーヘッドが発生します。アプリケーションで多数のメッセージを生成し、ネットワークを介して送信する必要がある場合、メッセージ送信の待機時間によってCPUのオーバーロードが発生することがあります。この問題を緩和するには、多数のラウンドトリップを実行するのではなく、複数のメッセージを1つにまとめます。たとえば、配列挿入、配列フェッチなどを使用できます。
この項で説明するいくつかのプロセス管理の項目をチェックする必要があります。
オペレーティング・システムはスケジューリングおよびスイッチング処理に大量の時間を消費することがあります。使用中のプロセスが多すぎる可能性があるため、オペレーティング・システムの使用方法を調査してください。Windowsシステムでは、データベース以外のプロセスでサーバーが過負荷にならないようにします。
オペレーティング・システム固有の特性によって、システムがコンテキストのスイッチングに大量の時間を消費することがあります。コンテキストのスイッチングは、特に超大規模SGAの場合には不経済です。インスタンス当たりのプロセスが1つのみであるWindowsでは、コンテキストのスイッチングは問題になりません。すべてのスレッドが同じページ表を共有します。
Oracle Databaseには、複数のコンテキスト・スイッチング機能があります。
ポスト・ウェイト・ドライバ
Oracleプロセスは、別のOracleプロセスをポスト(メッセージの送信)でき、さらにポストされるのを待機できる必要があります。たとえば、フォアグラウンド・プロセスがLGWRをポストして、指定の時点までのブロックをすべて書き出してコミットを承認するよう、LGWRに通知する必要があります。
このポスト・ウェイト・メカニズムは、UNIXのセマフォを使用して実装するのが普通ですが、これらのセマフォがリソース消費型である場合があります。したがって、一部のプラットフォームでは、ポスト・ウェイト・ドライバを提供しています。通常は、ポスト・ウェイト・インタフェースを軽量に実装できるカーネル・デバイス・ドライバが提供されます。
メモリーマップ済システム・タイマー
Oracle Databaseでは、システム時間を問い合せてタイミング情報を得る必要が生じる場合があります。その場合、オペレーティング・システム・コールが実行され、比較的コストのかかるコンテキストのスイッチングが発生することがあります。一部のプラットフォームでは、メモリーマップ済タイマーを実装し、プロセス仮想アドレス空間のアドレスに現在のタイミング情報を収集します。このメモリーマップ済タイマーから時間を読み取る方が、システム・コールのコンテキストのスイッチングのオーバーヘッドよりも経済的です。
1回のコールで複数の非同期I/Oを発行するリストI/Oインタフェース
リストI/Oとは、個別のシステム・コールで複数のI/Oリクエストを発行するかわりに、1回のシステム・コールで複数の非同期I/Oリクエストを発行できるApplication Program Interfaceです。この機能の主な利点は、コンテキストのスイッチングの所要回数が減少することです。
オペレーティング・システムの新規プロセスを開始する際には高いコストがかかります。開発者は、単一目的のプロセスを生成し、そのプロセスを終了後に、また新規のプロセスを生成することがよくあります。この方法ではそのつどプロセスの再生成と破壊が行われるため、特に大規模なSGAを持つアプリケーションではCPUが集中して消費されます。CPUは、そのたびにページ表を構築する必要があります。共有メモリーを確保またはロックするときは、すべてのページにアクセスする必要があるため、問題が増大します。
たとえば、1GBのSGAがある場合は、4KBごとにページ表のエントリがあり、1つのページ表のエントリは8バイトになります。エントリのサイズの合計は(1GB÷4KB)*×8バイトになります。ページ表がロードされていることを絶えず確認する必要があるので、コストが高くなります。
Oracle Database Resource Managerは、データベース・ユーザーおよびアプリケーション間のCPUリソースの割当ておよび管理を次のように行います。
CPU飽和の防止
CPU稼働率が100%の場合、Oracle Database Resource Managerを使用して、各コンシューマ・グループのセッションに最大限のCPUを割り当てることができます。この機能により、優先順位の高いセッションをすぐに実行できるように、優先順位の低いセッションのCPU消費量を削減できます。
コンシューマ・グループに対するCPU使用量の制限
リソース・マネージャのディレクティブmax_utilization_limitを使用して、コンシューマ・グループが使用できるCPU使用率を厳密に制限できます。この機能は、優先順位の低いセッションのCPU消費量を制限して、コンシューマ・グループ内のワークロードにより安定したパフォーマンスを提供できるようにします。
リソース集中型の問合せによるダメージの制限
Oracle Database 11gリリース2(11.2.0.2)から、Oracle Database Resource Managerは、コールの最大実行時間を制限することで、または長時間実行問合せを低優先順位の各コンシューマ・グループに移動することで、リソース集中型の問合せによるダメージを制限することができます。
コンシューマ・グループに対するパラレル文アクティビティの制限
Oracle Database 11gリリース2(11.2.0.2)から、リソース・マネージャのディレクティブparallel_target_percentageを使用して、1つのコンシューマ・グループがすべてのパラレル・サーバーを占有するのを回避できます。データベースは、この制限を超える原因となるパラレル文をキューに入れます。
たとえば、パラレル・サーバーのターゲット数が64で、コンシューマ・グループETLがこのディレクティブを50%に設定しているとします。コンシューマ・グループETLが30個のパラレル・サーバーを使用しており、新しいパラレル文が4個のパラレル・サーバーを必要とする場合、データベースはこの文をキューに入れます。
|
関連項目:
|
1つのシステムで複数のデータベース・インスタンスが実行されている場合、インスタンスはCPUリソースを競い合います。1つのリソース集中型のデータベース・インスタンスが、他のインスタンスのパフォーマンスを大きく低下させる場合があります。この問題を回避するには、インスタンス・ケージングを使用して、各インスタンスが使用できるCPU数を制限します。このとき、Oracle Database Resource Managerは、インスタンスに設定されたリソース計画に基づいて様々なデータベース・セッション間にCPUを割り当て、インスタンスがCPUバインドになる可能性を最小限に抑えます。
|
関連項目: インスタンス・ケージングの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
