Advanced Operations Guide (v11)

パフォーマンス チューニング

このセクションでは、データベース初期接続および実行時オペレーションでパフォーマンスを最大にするための一般的なヒントをいくつか提供します。一般的なガイドラインをいくつか示しますが、特定のアプリケーションのパフォーマンスは、以下に挙げる要因だけに限らず、非常に多くの要因によって変わります。

ご覧のように、エンジンの設定は一定のアプリケーションの全体のパフォーマンスの中では比較的限定的な役割を果たします。さらに、データベース エンジンは使用パターンに基づいてさまざまなリソースを動的に管理します。データベース エンジン自体が、必要に応じ環境に合わせてチューニングします。以下のセクションで提供するのは、有用なガイドラインにすぎず、特定のレベルのパフォーマンスを保証するものではありません。

パフォーマンスのボトルネックを見極める

Monitor ユーティリティを使用すると、特定のデータベース エンジンの設定オプションに関連するパフォーマンスのボトルネックを明らかにすることができます。Monitor は[スタート]メニューからアクセスできる[Pervasive]グループから起動することができます。

Monitor の表示と設定オプション

Monitor のメニューにある 2 つの選択肢によって、設定オプションに関連するパフォーマンスの値が表示されます。

次の表に示すように、データベース エンジンは複数のサーバー設定オプションを動的に管理します。

表 20 Monitor で表示される、動的に管理されている設定
動的に管理される設定
リソース使用状況ウィンドウに表示される値
通信統計情報ウィンドウに表示される値
ファイル数

 
ハンドル数

 
クライアント

 
ワーカ スレッド数

 
リモート セッション総数
 

表示および動作の解釈

Monitor に表示される情報を活用することができます。Monitor はリソースのタイプごとに 3 つの情報を表示します。たとえば、リモート セッション総数には次のように表示されます。

リソースのピーク値と最大値が同じ場合には、そのリソースの最大値を増やすように設定プロパティを設定すれば、データベース エンジンは、必要な場合に特定のリソースの追加のインスタンスを割り当てることができます。

設定プロパティを変更する前に

以下のセクションでは、次のことを前提とします。

  1. Pervasive PSQL Control Center (PCC)が既に開いていること。
    このタスクについての説明が必要な場合は、『Pervasive PSQL User's Guide』の Windows での PCC の起動を参照してください。
  2. 構成しようとするエンジンが既に登録済みであること(可能な場合)。
    このタスクについての説明が必要な場合は、『Pervasive PSQL User's Guide』のリモート サーバー エンジンを登録するにはを参照してください。
  3. 所定のエンジンを構成するには、オペレーティング システムの適切な権限が必要です。
    このタスクについての説明が必要な場合は、『Pervasive PSQL User's Guide』のデータベース エンジンの管理者権限の許可を参照してください。
  4. 一部のエンジン設定については、設定を変更した後にデータベース エンジンの再起動が必要になります。

初期接続時間を最小限にする

最短接続時間の基礎を成す理論は、3 つの必要条件を中心に展開します。これらの必要条件についての要約は次のようになり、詳細についてはその後で説明します。

クライアントのプロパティ

クライアントのプロパティの変更は、そのクライアント マシンで行う必要があります。設定を変更したい各ワークステーションでプロパティを変更する必要があります。

クライアント側の接続待ち時間を最小限にするには

  1. Pervasive PSQL エクスプローラーで、ツリーのローカル クライアント ノードを展開します(ノードの左の展開アイコンをクリックします)。
  2. MicroKernel ルーター]を右クリックします。
  3. プロパティー]をクリックします。
  4. プロパティ ツリーで[通信プロトコル]をクリックします。
  5. サポート プロトコル]で、必要なプロトコルにはチェック マークが入って選択されており、使用されないプロトコルのチェック マークは外されているようにします。
  6. 適用]をクリックします。
    これで、クライアントが、使用されていないプロトコルと通信しようとするのを妨ぐことができるようになりました。
  7. プロパティ ツリーで[アクセス]をクリックします。
  8. リモート サーバーまたはリモート ワークグループ エンジンのみを使用している場合は、[ローカル MicroKernel エンジンの使用]のチェック マークを外すようにします(つまり、オフに設定します)。
    ローカル ワークグループ エンジンのみを使用している場合は、[リモート MicroKernel エンジンの使用]のチェック マークを外すようにします(つまり、オフに設定します)。
    ワークグループ エンジンを使用することもあり、また、サーバー エンジンまたはリモート ワークグループ エンジンへ接続することもある場合には、両方の設定をオンにして(チェックを入れて)おく必要があります。
    このような共有と非共有データの混合環境では、各クライアントで[ゲートウェイ一貫性保守]をオンに設定しておくことができます。この設定によって、データベース エンジンに接続することができないすべてのマシンの名前のリストを強制的にクライアント ソフトウェアに保持させます。クライアント ソフトウェアが、指定されたコンピューターにはエンジンが存在しないことを判定するには、すべてのネットワーク プロトコルのリクエストがタイムアウトになるまで待ちます。
    Pervasive データベース エンジンを持たないサーバーにデータが格納されていて、[リモート MicroKernel エンジンの使用]の設定がオンの場合、クライアントはそのマシンにエンジンがないことを知るために少なくとも 1 度はタイムアウトを待たなければなりません。ゲートウェイ一貫性保守を使用すると、アプリケーションがそのデータに最初にアクセスしたときのみにこのタイムアウトが起きるようにできます。

    メモ

    ゲートウェイ一貫性保守を使用すると、ネットワーク トポロジを固定します。後に、リモート コンピューターにサーバーまたはワークグループ エンジンをインストールする場合、各クライアントで[ゲートウェイ一貫性保守]をオフにして、データベース エンジンを持たないコンピューターのリストが削除されるようにする必要があります(これにより新しいデータベース エンジンに接続できるようになります)。[ゲートウェイ一貫性保守]に戻ると、リストは空になっています。


  9. OK]をクリックします。
    これで、クライアントが、使用されていないデータベース エンジンに接続しようとするのを防ぐことができます。

サーバーのプロパティ

サーバー側の接続待ち時間を最小限にするには

  1. Pervasive PSQL エクスプローラーで、ツリーのエンジン ノードを展開します(ノードの左の展開アイコンをクリックします)。
  2. 設定を指定するデータベース エンジンを右クリックします。
  3. プロパティー]をクリックします。
  4. サポート プロトコル]で、必要なプロトコルにはチェック マークが入って選択されており、使用されないプロトコルのチェック マークは外されているようにします。
  5. 適用]をクリックします。
    これで、サーバーが、使用されていないプロトコルと通信しようとするのを防ぐことができます。

    メモ

    サーバーの設定で選択したプロトコルの少なくとも 1 つが、クライアントの設定で選択されたものと同一であることを確認してください。サーバーとクライアントは同じプロトコルを使用しなければ通信できません。


  6. プロパティ ツリーで[メモリの使用]をクリックします。
  7. 起動時のリソース割当]をクリックして、値をオンに設定します(チェック ボックスを選択)。
    このオプションは、データベース エンジンが必要なすべてのメモリを割り当てるタイミングを、最初の接続要求が入ってきたときではなく、起動時とします。この値を選択すると、より多くのメモリが必要ですが、クライアントから見ると、エンジンの処理速度が速くなります。
  8. 非アクティブ時、最小の状態に戻す]をオフに設定します(チェック ボックスをクリア)。
    このオプションは、データベース エンジンが非アクティブなときにも、リソースを解放してオペレーティング システムに戻さないことを指定します。すべてのリソースは割り当てられたままで、次のクライアント接続に備えられます。
  9. OK]をクリックします。
  10. これらの変更を有効にするために、[はい]をクリックしてエンジンを再起動します。

ランタイムのスループットを最大にする

最大スループットを得るための原理は、ここに挙げる非常に多くの要因に依存します。最も重要な要因のいくつかを挙げます。

結局、最適化されたパフォーマンスは、ネットワークのボトルネック、ディスク I/O のボトルネック、メモリのボトルネック、および CPU のボトルネックの間を綱渡りすることで実現しています。このセクションでは、メモリおよびディスク I/O のボトルネックを減少させる方法のガイドラインをいくつか示します。

速いディスクと速い CPU

ハードウェアへの投入費用に対しパフォーマンス向上の効果を最大にしたければ、既存のパフォーマンスの制約を理解する必要があります。データベースが非常に大きくて、データベースの主要な部分をキャッシュに入れるための十分なメモリを購入してインストールするのが妥当でない場合、パフォーマンスはディスク I/O によって制約を受けがちです。これらの状況では、速い RAID ディスク配列に費用をかけてディスク I/O のパフォーマンスを最大にします。

さらに、アプリケーションが SRDE を使用していて一時ファイルを頻繁に作成する場合、これらのファイルが作成されるディレクトリが速いディスク ドライブであることを望むでしょう。このディレクトリの場所および一時ファイルを作成するクエリのタイプの詳細については、『SQL Engine Reference』のテンポラリ ファイルを参照してください。

データベースが小さくてメモリに全部またはほとんどがキャッシュできる場合、速いディスク配列の追加では著しいパフォーマンス向上を得る可能性はありません。このような状況下では、CPU をアップグレードするか CPU を追加することにより最高のパフォーマンス改善値が得られます。

十分な物理メモリとデータベース キャッシュを確保する

Pervasive.SQL バージョン 8 以降を使用する場合、データベース エンジンは設定プロパティで設定したキャッシュ割当サイズのレベル 1 キャッシュに加え、レベル 2 動的キャッシュを提供します。MicroKernel の最大メモリ使用量にゼロを設定してレベル 2 動的キャッシュを無効にしないとすれば、レベル 1 キャッシュ サイズを手動で調整するのは、以前のリリースよりずっと楽です。これを念頭において、このセクションでは、データベース エンジンの最適なパフォーマンスのための十分なメモリを確実に利用できるようにする方法を説明します。

理想的には、データベース エンジンが十分なメモリを割り当てることができ、管理する各データベースの完全なコピーをキャッシュできれば、ディスク I/O を最大限避けることができます。1 つまたは複数のデータベース全体をキャッシュするのは状況によって、特にデータベースサイズが非常に大きい場合には、明らかに実用的ではありません。さらに、既存のシステム リソースが通常の使用でも大きな負荷がかかっている場合、パフォーマンスを向上させる対策はマシンに RAM を追加することだけです。

データベース エンジンは最初に起動されたときに動的にレベル 1 キャッシュ値を選択します。ただし、この値は使用可能なメモリに基づいていて、その環境で理想的なキャッシュ量になるとは限りません。

データベースのメモリ キャッシュの理想的なサイズを計算するには

  1. まず、データベース エンジンがサービスするすべてのデータベース ファイルのサイズを合計します。

    メモ

    エンジンがサービスするデータベースが 2 つ以上あっても、同時に使用されない場合は、大きい方のサイズだけを加算します。


    たとえば、サーバー上に 2 つのデータベースがあり、それらのサイズは以下のとおりで、ユーザーが同時に両方のデータベースにアクセスするとします。

    データベース A
    データベース B
    file1.mkd
    223 MB
    Afile.mkd
    675 MB
    file2.mkd
    54 MB
    Bfile.mkd
    54 MB
    file3.mkd
    92 MB
    Cfile.mkd
    318 MB
    file4.mkd
    14 MB
     
     

    これらすべてのファイルの合計は 1,430 MB です。
    今得た値は、データベース エンジンがホストするすべてのデータをキャッシュした場合に使用するメモリの最大量です。この数値を MaxCache と呼びます。
    キャッシュ割当サイズに、これより大きい値を指定しようとは考えないでしょう。そうすることは、データベース エンジンにまったく使用しないと思われるメモリを割り当てることになるからです。実際の運用に妥当なのは、キャッシュ割当サイズMaxCache の 20% から 70% を設定することです。この範囲中で低い値は読み取り処理の多いアプリケーションに最適で、高い値は書き込み処理の多いアプリケーションに最適です。それは、すべての書き込み/更新操作はレベル 1 キャッシュで行われるからです。

    メモ

    ファイル ページは、アクセスされたときにのみデータベース キャッシュに書き込まれます。したがって、データベース エンジンはデータベースのすべてのページがアクセスされるたびに MaxCache を必要とします。この評価方式により、長期間安定した状態でデータベース処理を行うことができます。データベース エンジンを毎晩または毎週停止する場合、一定の稼働時間内にデータベース エンジンが、データベースのすべてのページにアクセスすることはあまりありません。

    このような状況の場合、一定の稼動期間にアプリケーションが別個のページに平均何回アクセスするかを見積もり、ページ サイズを掛けて、特定の稼動期間のより現実的な MaxCache の値を求めたいでしょう。

    MicroKernel キャッシュ用のカウンターも参照してください。


Windows 32 ビット オペレーティング システムでは、すべてのユーザー プロセスのメモリは 2GB に制限されています。MaxCache の計算値が 2 GB より大きく、データベース エンジンが 32 ビット Windows オペレーティング システム上で実行される場合、MaxCache に 2 GB の値を使用します。

必要な物理メモリ総量を決定するには

次の方程式を使用して、データベース エンジンで必要とされる総物理メモリ量の近似値を割り出します。
データベースの最大メモリ使用量 = L1 キャッシュサイズ + 内部割り当て + L2 キャッシュサイズ
各項目の説明は次のとおりです。
L1 キャッシュ サイズキャッシュ割当サイズ
内部割り当て:L1 キャッシュの約 25% のサイズ
L2 キャッシュ サイズ:システムのメモリ ロードに基づいて拡大および縮小するメモリ容量
以下の点に注意してください。

ディスク I/O を最小限にする

ディスクからの読み込みおよびディスクへの書き込みは、メモリに対するそれよりずっと時間がかかります。したがって、パフォーマンスを最適化する 1 つの方法はディスクの動作を最小限にすることです。

ディスク I/O を最小化する上での重要な考慮点はデータの回復の可能性です。ディスク I/O は、トランザクション一貫性および回復可能性に対する直接的な交換条件です。変更のログをディスクに書き込むための停止なしでデータをメモリに保持するほど、データベースのパフォーマンスは速くなります。一方、変更のログをディスクに書き込むための停止を行わずにデータをメモリに保持するほど、システムに異常をきたした場合に失うデータが増えます。

ディスク I/O を減少させるには

  1. 前のサブセクション、十分な物理メモリとデータベース キャッシュを確保するで説明したように、最も重要な考慮点の 1 つは、ディスクおよびキャッシュ間のデータ ページの頻繁なスワップを避けるために十分なデータベース メモリ キャッシュを確保することです。詳細については、そのセクションを参照してください。
    ディスク I/O を減らす最良の方法の 1 つは、動的なレベル 2 キャッシュを必ずオンにすることです。レベル 2 キャッシュはキャッシュ要求がレベル 1 固定キャッシュの容量を超えたとき、アプリケーションの使用量の変化によってサイズを動的に調整して可能な限り多くのデータをメモリに格納し、それによりディスク I/O を減らします。デフォルトで、レベル 2 キャッシュはオンになっています。データベース エンジンがレベル 2 キャッシュを使用していることを確認するには、設定プロパティの[MicroKernel の最大メモリ使用量]を調べます(MicroKernel の最大メモリ使用量を参照してください)。
  2. 次に、システム異常の場合に、どれだけのロギングが必要で、どれだけのデータベース オペレーションを失ってもかまわないかを考慮します。失ってもかまわない変更が多いほど、パフォーマンスの向上を追求することができます。
    アーカイブ ログの使用 トランザクション一貫性保守 およびトランザクション ログはすべてログ ファイルを必要とします。デフォルトで、アーカイブ ロギングはオフになっています。定期的なバックアップを実行し、システム異常の時点のデータに回復する能力を必要とする場合にのみこれをオンにします。ログの対象とするファイルを指定するときには、完全にログを必要とするファイルのみを指定するようにしてください。詳細については、第 8 章のログ、バックアップおよび復元を参照してください。
    デフォルトで、トランザクション ログはオンになっています。トランザクション ログをオフにすると、パフォーマンスは若干向上しますが、複数ファイルの一貫性とトランザクション アトミシティは保証されません。トランザクション ログをオフにする前に、アプリケーションがこの機能を使用しないで実行できるかどうかをベンダーに確認してください。

    注意

    トランザクション ログが無効な場合、複数ファイルのデータベースの整合性は保証されません。


    デフォルトで、トランザクション一貫性保守はオフになっています。アプリケーションでシステム クラッシュが起きてもトランザクション処理が完了することを必要とする場合は、この機能を有効にします。トランザクション一貫性保守を使用すると、パフォーマンスに最も高いペナルティが課されますが、引き換えに完了したトランザクションの最高の安全性を引き出します。
  3. いずれかのロギング機能をオンにしている場合、エンジンがディスクに書き込む前にどれだけのデータを保存するかを指定することができます。変更データは繰り返し作成されるので、この機能は重要です。メモリに構築するログ データの許容量が多いほど、ディスク書き込みの頻度は減ります。
    ログ バッファー サイズ]設定は、エンジンがデータベース操作をログ ファイルに書き出す前に、メモリに格納しておくバイト数を指定します(サーバーのプロパティ ツリーで[パフォーマンス チューニング]をクリックします)。
    システム異常の場合、ログ バッファー内のデータは失われます。
  4. トランザクション一貫性保守をオンにしている場合、ディスク上のログセグメントの最大サイズを指定することができます。小さいログ セグメントは作成と閉じることを繰り返すので、大きなログ セグメント サイズを指定すると、若干パフォーマンスを向上させることができます。
    トランザクション ログ サイズ]設定は、ログ セグメントを閉じて新しいログ セグメントを開くまでにログ セグメントに格納できる最大バイト数を指定します(サーバーのプロパティ ツリーで[パフォーマンス チューニング]をクリックします)。
  5. データベースの使用率が高い場合には、データ ファイルが存在するのとは物理的に異なるボリュームにログが保持されるようシステムを構成する必要があります。一般的に高負荷の下では、単一ドライブで I/O 帯域幅を競う代わりに、ログ ファイルへの書き込みとデータ ファイルへの書き込みを別々のドライブに分ける方がパフォーマンスがよくなります。全体的なディスク I/O は減少しませんが、ロードはディスク コントローラー間で効率よく分散されます。
  6. アプリケーションの使用方法がデータベース読み取り処理に重点を置いている場合、[インデックス バランスの実行]を調整することにより、パフォーマンスを向上させることができます(サーバーのプロパティ ツリーで[パフォーマンス チューニング]をクリックします)。インデックス バランスは通常のインデックス ページのノード数を増やし、読み込みオペレーションを速くします。ただし、Insert、Update、および Delete オペレーションでは、エンジンは隣接ページにまたがってインデックス ノードのバランスをとるため、ディスク I/O 時間が余計に必要になることがあります。
  7. MicroKernel および ODBC レベルの両方でトレースを必ずオフにしてください。トレースは、多くのディスク I/O を引き起こすため、パフォーマンスを著しく低下させます。
    ODBC のトレースがオフであることを確認するには、Pervasive PSQL Control Center から ODBC アドミニストレーターを起動します。ODBC アドミニストレーターで[トレース]タブをクリックします。トレースがオフの場合、[トレースの開始]と表示されたボタンがあるので、[キャンセル]をクリックします。トレースがオンの場合は、[トレースの停止]ボタンをクリックし、[OK]をクリックします。
    MicroKernel のトレースがオフであることを確認するには、設定プロパティの[トレース オペレーションの実行]がオフに設定されている(チェックされていない)かを調べます(サーバーのプロパティ ツリーで[デバッグ]をクリックします)。

十分なリソース割り当てを確保する

データベース サーバー プラットフォームに十分なメモリおよび CPU パワーがある場合は、データベース エンジンが複数クライアントおよび複数データ ファイルを最も効果的にサービスできるよう、ハードウェア リソースを最大限利用できるようにしてください。

複数クライアントおよび複数ファイルを扱えるように設定するには

  1. I/O スレッド数]設定により、ファイル操作の処理に利用できるスレッド数を指定することができます(サーバーのプロパティ ツリーで[パフォーマンス チューニング]をクリックします)。
    ガイドラインとして、この設定の値は、アプリケーションが平均的に開くファイル数のおよそ 1/8 にします。たとえば、アプリケーションがたいてい 40 ファイルを開く場合、
    I/O スレッドに 5 を設定します。
    Monitor を使用して、メニューから[MicroKernelリソースの使用状況]を選択します。ウィンドウが開き、ファイル数に開いているファイル数の現在値とピーク値が表示されています。何度か現在値を記録して平均表示度数を出すことができます。その平均値に基づいて、I/O スレッド数に適切な設定をしてください。

大きいシステム キャッシュ

Windows オペレーティング システムによっては "大きいシステム キャッシュ" 設定を提供しています。これを使用すれば、システムが空きメモリを利用して最近アクセスしたデータをキャッスすることができます。一部の Windows サーバーではデフォルトでこの設定がオンになっています。これは、単純なファイル共有には都合がよく、積極的にシステム キャッシュを増加させます。

ファイル キャッシュ用のメモリを積極的に使用すると、Pervasive PSQL をスワップ アウトすることがあります。これによってデータベースに伴う多くのパフォーマンス問題が発生する可能性があります。"大きなシステム キャッシュ" をオンにし、Pervasive PSQL の設定であるシステム キャッシュの設定もオン(明示的、または MicroKernel の最大メモリ使用量 をゼロに設定)にすると、パフォーマンスが低下する可能性があります。データベースのパフォーマンスを向上させるために考えられる解決策は、この "大きなシステム キャッシュ" をオフにすることです。

この設定をオフにするには、(コントロール パネルまたはマイ コンピューターのプロパティから)システム プロパティにアクセスします。[詳細設定]タブをクリックし、[パフォーマンス]セクションの[設定]ボタンをクリックします。[パフォーマンス オプション]ダイアログで[詳細設定]タブをクリックします。

[メモリの使用量]セクションで、[システム キャッシュ]オプションが選択されている場合は、大きなシステム キャッシュがオンになっています。これをオフにするには、[メモリの使用量]のもう 1 つのオプションである " プログラム" を選択します。[OK]をクリックし、開いていた一連のダイアログを閉じ、オペレーティング システムを再起動します。このオペレーティング システムの設定を反映させるには再起動する必要があります。

Xtreme I/O ドライバーについては、システム要件も参照してください。


パフォーマンスの分析

ハイパーバイザー製品でのパフォーマンス