| Oracle Databaseパフォーマンス・チューニング・ガイド 11gリリース1（11.1） E05743-02 |
|
 戻る |
 次へ |
この章では、Oracleデータベース・サーバーのパフォーマンスを最適化するためにオペレーティング・システムをチューニングする方法を説明します。
この章には次の項があります。
|
関連項目:
|
オペレーティング・システムのパフォーマンスの問題は、一般にプロセス管理、メモリー管理およびスケジューリングに関係します。Oracleインスタンスをチューニングした後で、さらにパフォーマンスを改善する必要がある場合は、作業方法を検証するか、システム時間の短縮を試行してください。I/O帯域幅、CPU能力およびスワップ・スペースが十分にあることを確認してください。ただし、オペレーティング・システムをさらにチューニングしても、それがアプリケーションのパフォーマンスに大きな効果を与えることは期待できません。単にオペレーティング・システムをチューニングするよりも、Oracleの構成またはアプリケーションを変更する方が、結果的にオペレーティング・システムの効率が大きく変わります。
たとえば、アプリケーションでbuffer busy waitsが非常に頻繁に発生する場合は、システム・コールの回数が増加します。アプリケーションをチューニングすることでbuffer busy waitsを削減すると、システム・コールの数が減少します。
この項では、オペレーティング・システムのパフォーマンスの問題に関する次の項目について説明します。
オペレーティング・システムとデバイス・コントローラが提供するデータ・キャッシュは、Oracleのキャッシュ管理と直接は衝突しません。ただし、パフォーマンスにほとんど利益にならないですし、これらの構造ではリソースが消費されます。このことは、UNIXファイル・システムにデータベース・ファイルがあるUNIXシステムで最も顕著です。デフォルトでは、すべてのデータベースI/Oはファイル・システム・キャッシュ内を通過します。一部のUNIXシステムでは、ファイル・システムへの直接I/Oが使用可能です。これによって、データベース・ファイルは、ファイル・システム・キャッシュをバイパスしてUNIXファイル・システム内でアクセスできます。これによってCPUリソースを節約でき、ファイル・システム・キャッシュを、プログラム・テキストやスプール・ファイルなどのデータベース以外のアクティビティ専用にできます。
この問題はWindowsでは発生しません。データベースから要求されたファイルは、すべてファイル・システム内のキャッシュをバイパスします。
Oracleバッファ・キャッシュのバッファ・ブロックの存在により、オペレーティング・システムのキャッシュは冗長になる場合がありますが、OracleがOracleバッファ・キャッシュを使用しないこともよくあります。このような場合に、UNIXまたはオペレーティング・システムのキャッシュがバイパスされる直接I/O、またはオペレーティング・システムのキャッシュが使用されないRAWデバイスを使用すると、オペレーティング・システムのバッファリングを使用したときより、パフォーマンスが劣化することがあります。これには次のような例があります。
一時表領域での読取りまたは書込み
NOCACHE LOBに格納されるデータ
パラレル問合せスレーブで読み取られるデータ
オペレーティング・システム・レベルでキャッシュするファイルと、キャッシュしないファイルを混在させる必要がある場合があります。
同期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を無効にします。
|
関連項目: 詳細は使用しているプラットフォーム固有のマニュアルを参照してください。 |
メモリー使用量は、バッファ・キャッシュの制限と初期化パラメータの両方の影響を受けます。
UNIXバッファ・キャッシュはオペレーティング・システムのメモリー・リソースを消費します。あるバージョンのUNIXでは、UNIXバッファ・キャッシュに一定量のメモリーを割り当てることができますが、現在ではより複雑なメモリー管理メカニズムが使用されるのが普通です。通常これらの管理メカニズムでは、I/Oをキャッシュするために空きメモリー・ページを使用できます。そのようなシステムでは、オペレーティング・システムのレポート・ツールは空きメモリーがないことを示すのが普通で、通常は問題になりません。プロセスがより多くのメモリーを必要とする場合、通常はI/Oデータをキャッシュするメモリーが開放されて、そのプロセス・メモリーを割り当てることができます。
一部のプラットフォームではオペレーティング・システム・リソース・マネージャが提供されます。これらは、CPUリソース割当てに優先順位を付けることによってピーク負荷使用パターンの影響を少なくするように設計されています。これらは通常、ユーザーがアクセス可能なリソースと各ユーザーがこれらのリソースのどの程度を消費可能かを統括する、管理方針を実装します。
オペレーティング・システム・リソース・マネージャは、ドメインや類似のファシリティとは異なります。ドメインは、1つのシステム内で1つ、あるいは複数のまったく別の環境を提供します。ディスク、CPU、メモリーおよびその他すべてのリソースがドメイン専用となっており、他のドメインからアクセスできません。他の類似のファシリティは、異なる領域、通常個別のCPUまたはメモリー領域へのシステム・リソースの一部として完全に分離されています。ドメインと同様、個別のリソース領域はその領域に割り当てられた処理専用となっています。プロセスは境界を超えて移行できません。ドメインとは異なり、その他すべてのリソース（通常はディスク）は、システムのすべてのパーティションからアクセスできます。
Oracle Databaseはドメイン内で実行される他、パーティション化されたメモリー（RAM）リソースの割当てが動的でなく、固定されている場合は、その他の不完全なパーティション構造体内で実行されます。
オペレーティング・システム・リソース・マネージャは、リソースのグローバル・プール内、通常はドメインあるいはシステム全体内でのリソース割当てに優先順位を設定します。プロセスはグループに割り当てられ、グループはリソース・プール内の任意の場所にあるリソースに割り当てられます。
|
注意: オペレーティング・システム・リソース・マネージャで実行されている場合、Oracleは各インスタンスが専用オペレーティング・システム・リソース・マネージャ・グループあるいは管理エンティティに割り当てられている場合にのみサポートされます。また、すべてのインスタンスのプロセスを実行している専用エンティティは、1つの優先順位（またはリソース使用）レベルで実行される必要があります。異なる優先順位レベルの個別のOracleプロセスの管理は、サポートされません。インスタンスの破壊などの重大な結果が発生します。 |
この項では、様々なシステムでのチューニングのヒントを示します。次の項目について説明します。
プラットフォーム固有の問題をよく理解し、使用しているオペレーティング・システムが提供するパフォーマンス・オプションを認識してください。
|
関連項目: 使用しているプラットフォーム固有のOracleマニュアルおよび使用しているオペレーティング・システム・ベンダーのマニュアル |
UNIXシステムでは、オペレーティング・システムが費やす時間量（システム・コールの処理およびプロセス・スケジューリングの実行）とアプリケーションが実行する時間量の妥当な比率を確立するようにしてください。システム・モードではなく、アプリケーション・モード（ユーザー・モードとも呼ばれる）での実行に大部分の時間を費やすことを目標としてください。
各モードで消費される時間の比率は、潜在する問題の徴候にすぎず、次の項目に関係している可能性があります。
ページングまたはスワッピング
実行しているオペレーティング・システム・コールが多すぎる状態
実行しているプロセスが多すぎる状態
このような条件が存在する場合は、アプリケーションの実行に使用できる時間は少なくなります。オペレーティング・システム側の時間を多く解放するほど、アプリケーションが実行できるトランザクションの量が増えます。
UNIXベースのシステムと同様に、Windowsシステムでは、アプリケーション・モードの時間とシステム・モードの時間の比率を適切に設定してください。Windows管理パフォーマンス・ツールで多数の要因を容易に監視できます。CPU、ネットワーク、I/Oおよびメモリーはすべて、これらの領域でのボトルネックを容易に回避できるように同じグラフ上に表示されます。
メインフレームのページング・パラメータを検討し、Oracleがパラメータの非常に大きな作業セットを利用できることを覚えておいてください。
HP OpenVMS環境での空きメモリーは、どのオペレーティング・システム・プロセスにも実際にマップされていないメモリーです。ビジーなシステムでは、1つ以上の現行のアクティブ・プロセスに属するページを空きメモリーが含むことがよくあります。これがアクセスされるとソフト・ページ・フォルトが発生し、ページにはそのプロセスの作業セットが組み込まれます。プロセスが作業セットを拡張できない場合は、プロセスによって現在マップされているページの1つを空きセットに移動する必要があります。
任意の数のプロセスが、作業セット内に共有メモリーのページを持つことができます。したがって、作業セットのサイズの合計が使用可能メモリーを著しく超過することがあります。Oracleサーバーの実行中は、SGA、Oracleカーネル・コードおよびOracle Formsランタイム実行可能ファイルは一般にすべて共有可能であり、アクセスされるページのおよそ80%または90%に相当します。
CPUの問題を扱うには、まずシステムが使用するCPUリソースの量について、適切な見積りを設定します。次に、十分なCPUリソースが使用可能かどうかを判断し、システムがいつリソースを使用しすぎているかを認識します。最初に、次の3つのシステムの状況についてOracleインスタンスが利用するCPUリソースの量を判断します。
システムがアイドル状態（Oracleのアクティビティがほとんど存在しないか、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がCPUリソースの90%を使用するとします。その場合、ワークロードが平均の期間では、次の等式が示すように、Oracleは使用可能な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使用率の調査」を参照してください。
システム・アーキテクチャの変更など、ハードウェア容量を増加する場合。
CPUのリソース割当てに優先順位を付けることにより、ピーク負荷使用パターンの影響を少なくする場合。Oracle Database Resource Managerは、データベース・ユーザーとアプリケーション間でCPUリソースを割り当て、管理することによって、次の方法でこれを実行します。
各コンシューマ・グループのアクティブ・セッション数の制限
この機能は、各コンシューマ・グループに多数のパラレル問合せがあり、パラレル問合せの総数を制限する場合に特に重要です。
CPU飽和
CPUが100%の使用率で稼働している場合に、Oracle Database Resource Managerを使用して各コンシューマ・グループのセッションに対するCPUの割当てを最小限にできます。この機能により、優先順位の低いセッションのCPU消費を削減できます。
リソース集中型の問合せ
Oracle Database Resource Managerは、コールの最大実行時間を制限することで、または長時間実行問合せを低優先順位の各コンシューマ・グループに移動することで、リソース集中型の問合せによるダメージを制限することができます。
|
関連項目: Oracle Database Resource Managerの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
使用しているシステムで実行するすべてのプロセスが、使用可能なCPUリソースに影響を与えます。このため、Oracle以外の要因をチューニングするとパフォーマンスが向上することがあります。
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でのCPU使用率は、ユーザー時間、システム時間、アイドル時間およびI/Oの待機時間を示す統計で説明されます。ワークロードが標準または低いときに、アイドル時間とI/Oの待機時間が両方とも0に近い（5%未満である）場合は、CPUの問題が存在します。
Windowsでは、管理パフォーマンス・ツールを使用してCPU使用率を監視します。このユーティリティは、プロセッサ時間、ユーザー時間、特権時間（privileged time）、割込み時間およびDPC時間の統計を提供します。
この項では、システムのCPU使用率のチェックに関する次の項目について説明します。
|
注意: この項では、ほとんどのUNIXベース・システムおよびWindowsシステムにおけるCPU使用率のチェック方法を説明します。その他のプラットフォームについては、使用しているオペレーティング・システムのマニュアルを参照してください。 |
次のメモリー管理項目をチェックします。
スラッシングはI/O管理の課題です。マシンのスラッシング（メモリー内外のスワッピングおよびページング処理）が発生しないように、ワークロードをメモリーに適合させてください。オペレーティング・システムは固定サイズのタイム・スライスをユーザーのプロセスに割り当て、プロセスはそのタイム・スライス中にCPUリソースを使用できます。プロセスが実行可能かどうか、および必要な構成要素がすべてマシンにあるかどうかを確認するときに、プロセスが大半の時間を浪費すると、実際の作業の実行に割り当てられる時間はわずか50%となることがあります。
クライアント/サーバーのラウンドトリップをチェックします。メッセージを処理する際にはオーバーヘッドが発生します。アプリケーションで多数のメッセージを生成し、ネットワークを介して送信する必要がある場合、メッセージ送信の待機時間によってCPUのオーバーロードが発生することがあります。この問題を軽減するには、多数のラウンドトリップを実行せずに、複数のメッセージをまとめます。たとえば、配列挿入、配列フェッチなどを使用できます。
この項で説明するいくつかのプロセス管理の項目をチェックする必要があります。
オペレーティング・システムはスケジューリングおよびスイッチング処理に大量の時間を消費することがあります。使用しているプロセスが多すぎる可能性があるので、オペレーティング・システムの使用方法を検証してください。Windowsシステムでは、Oracleプロセス以外の大量のプロセスによってサーバーが過負荷にならないようにしてください。
オペレーティング・システム固有の特性によって、システムがコンテキストのスイッチングに大量の時間を消費することがあります。コンテキストのスイッチングは、特に超大規模SGAの場合には不経済です。インスタンス当たりのプロセスが1つのみであるWindowsでは、コンテキストのスイッチングは問題になりません。すべてのスレッドが同じページ表を共有します。
Oracleでは、この項で説明する複数のコンテキストのスイッチング機能があります。
Oracleプロセスは、別のOracleプロセスをポスト（メッセージの送信）でき、さらにポストされるのを待機できる必要があります。
たとえば、フォアグラウンド・プロセスがLGWRをポストして、指定の時点までのブロックをすべて書き出してコミットを承認するよう、LGWRに通知する必要があります。
このポスト・ウェイト・メカニズムは、UNIXのセマフォを使用して実装するのが普通ですが、これらのセマフォがリソース集中型である場合があります。したがって、一部のプラットフォームでは、ポスト・ウェイト・ドライバを提供しています。通常は、ポスト・ウェイト・インタフェースを簡単に実装できるカーネル・デバイス・ドライバが提供されます。
オペレーティング・システムの新規プロセスを開始する際には高いコストがかかります。プログラマは、単一目的のプロセスを生成し、そのプロセスを終了後に、また新規のプロセスを生成することがよくあります。この場合、そのつどプロセスの再生成と破壊が行われます。この方法では、特に大規模なSGAを持つアプリケーションでCPUが集中して使用されます。これは、そのたびにページ表を構築する必要があるからです。共有メモリーを確保またはロックするときは、すべてのページにアクセスする必要があるため、問題が増大します。
たとえば、1GBのSGAがある場合は、4KBごとにページ表のエントリがあり、1つのページ表のエントリは8バイトになります。エントリのサイズの合計は（1G÷4KB）×8バイトになります。ページ表がロードされていることを絶えず確認する必要があるので、これは不経済になります。
