パフォーマンス

PSQL Server の Windows 版では Windows パフォーマンスモニターで使用するパフォーマンスカウンターを提供します。パフォーマンスカウンターはデータベースエンジンの状態や動作を測定します。これによりアプリケーションのパフォーマンスを分析することができます。

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

•アプリケーションでの使用パターン（大量の書き込み、大量の読み取り、トランザクションの使用/不使用、レコードサイズの大小、複雑または単純なクエリ、ODBC、Btrieve のみ、など）

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

Monitor ユーティリティを使用すると、特定のデータベースエンジンの設定オプションに関連するパフォーマンスのボトルネックを明らかにすることができます。オペレーティングシステムの［スタート］メニューまたはアプリ画面から、あるいは PSQL Control Center の［ツール］メニューから Monitor を起動します。

表 15 Monitor で表示される、動的に管理されている設定
動的に管理される設定	リソース使用状況ウィンドウに表示される値	通信統計情報ウィンドウに表示される値
ファイル数
ハンドル数
クライアント数
ワーカスレッド数
リモートセッション総数

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

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

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

•既知の通信プロトコル。クライアントまたはサーバーが、その環境でサポートされていないプロトコルを介して接続を試行するために余計な時間を費やすことは望ましくありません。クライアント/サーバーが使用できないプロトコルを削除することにより、ネットワークコンポーネントがそれらの使用を試行することを防げます。

•既知のデータベースエンジンのロケーション。クライアントが存在しないエンジンへの接続を試行することは望ましくありません。ワークグループのみのサポート、またはサーバーのみのサポートを適切に指定することにより、クライアントが存在しない接続でタイムアウトになることを防ぐことができます。非共有および共有データベースの両方がある環境では、ゲートウェイの一貫性保守を使用して、データベースエンジンがデータベースエンジンの実行されていないマシンを常に知ることができ、これにより、これらのマシン上のエンジンへの接続を試行せず、別の方法でデータにアクセスします。

•実行準備の整ったデータベースエンジン。休止しているエンジンが新しい接続リクエストを受け取ると、リソースの再割り当ておよび実行時の状態に戻るのに時間がかかります。接続スピードがサーバー上のリソース使用量より重要な場合は、サーバーエンジンが使用されていないときにも休止しないようにすることができます。

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

5 ［サポートプロトコル］で、必要なプロトコルにはチェックマークが入って選択されており、使用されないプロトコルのチェックマークは外されているようにします。

8 リモートサーバーまたはリモートワークグループエンジンのみを使用している場合は、［ローカル MicroKernel エンジンの使用］のチェックマークを外すようにします（つまり、オフに設定します）。

ローカルワークグループエンジンのみを使用している場合は、［リモート MicroKernel エンジンの使用］のチェックマークを外すようにします（つまり、オフに設定します）。

ワークグループエンジンを使用することもあり、また、サーバーエンジンまたはリモートワークグループエンジンへ接続することもある場合には、両方の設定をオンにして（チェックを入れて）おく必要があります。

このような共有と非共有データの混合環境では、各クライアントで［ゲートウェイ一貫性保守］をオンに設定しておくことができます。この設定によって、データベースエンジンに接続することができないすべてのマシンの名前のリストを強制的にクライアントソフトウェアに保持させます。クライアントソフトウェアが、指定されたコンピューターにはエンジンが存在しないことを判定するには、すべてのネットワークプロトコルのリクエストがタイムアウトになるまで待ちます。

PSQL データベースエンジンを持たないサーバーにデータが格納されていて、［リモート MicroKernel エンジンの使用］の設定がオンの場合、クライアントはそのマシンにエンジンがないことを知るために少なくとも 1 度はタイムアウトを待たなければなりません。ゲートウェイ一貫性保守を使用すると、アプリケーションがそのデータに最初にアクセスしたときのみにこのタイムアウトが起きるようにできます。

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

4 ［サポートプロトコル］で、必要なプロトコルにはチェックマークが入って選択されており、使用されないプロトコルのチェックマークは外されているようにします。

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

このオプションは、データベースエンジンが必要なすべてのメモリを割り当てるタイミングを、最初の接続要求が入ってきたときではなく、起動時とします。この値を選択すると、より多くのメモリが必要ですが、クライアントから見ると、エンジンの処理速度が速くなります。

このオプションは、データベースエンジンが非アクティブなときにも、リソースを解放してオペレーティングシステムに戻さないことを指定します。すべてのリソースは割り当てられたままで、次のクライアント接続に備えられます。

•十分な物理メモリ。ホストシステムの RAM が少なすぎる場合、異なるユーザーおよびプロセスが限られたリソースを競い合うと、システムはその時間と CPU サイクルのほとんどをメモリとディスクのスワップに費やすことになります。

•十分なネットワーク帯域幅。ネットワークが遅かったり、高いコリジョン率によって悪影響を受けている場合、データベースエンジンはデータアクセスのリクエスト間で休止状態になり、各クライアントでは低いパフォーマンスを示します。

•最小限のディスク I/O。ディスク I/O は、メモリ I/O より著しく速度低下を招きます。十分なキャッシュを確保して、できる限りディスクにアクセスすることを避けます。

•十分なリソース割り当て。大きな物理メモリが使用可能であっても、データベースエンジンの設定プロパティが人為的に低く設定されている場合には、データベースのパフォーマンスは悪くなります。

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

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

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

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

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

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

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

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

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

今得た値は、データベースエンジンがホストするすべてのデータをキャッシュした場合に使用するメモリの最大量です。この数値を MaxCache と呼びます。

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

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

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

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

Windows 32 ビットオペレーティングシステムでは、すべてのユーザープロセスのメモリは 2GB に制限されています。MaxCache の計算値が 2 GB より大きく、データベースエンジンが 32 ビット Windows オペレーティングシステム上で実行される場合、選択する MaxCache 値によってエンジンが絶対に 2 GB の限界を超えないようにしていください。そうしないと、エンジンがメモリを割り当ることができず、その後、エラーになる可能性があります。

•L1 キャッシュはキャッシュ割当サイズに基づく固定サイズです。このサイズはデータベース操作によって拡大したり縮小したりすることはありません。アプリケーションで多数の書き込み操作を行う場合は、この L1 キャッシュをできるだけ増やしてください。

•すべてのデータを L1 キャッシュに収容することができれば、最高のパフォーマンスが得られます。すべてのデータが L1 キャッシュに収容されない場合は、キャッシュ割当サイズおよび MicroKernel の最大メモリ使用量を調整して妥当なシステムメモリ量を使用します。

•L2 キャッシュは、システムのメモリロードに基づいて拡大および縮小します。たとえば、ほかのアプリケーションでより多くのメモリが必要となった場合、L2 キャッシュは縮小します。十分なメモリが使用可能であれば、L2 キャッシュは上記の方程式に基づいて最大量に達します。L2 キャッシュの拡大や縮小はパフォーマンスに影響します。縮小した場合は、データページが L2 キャッシュから除去されるなどの事象が起こります。ディスクストレージからのデータページの読み取りは、キャッシュに保持されたデータページの読み取りと比べ、より時間がかかります。

•L2 キャッシュには圧縮データページが含まれます（少ないスペースにより多くのページが収まります）。L2 キャッシュからのページアクセスは、L1 キャッシュからのページアクセスよりも時間がかかりますが、ディスクストレージからのページアクセスに比べれば処理が速くなります。多数の読み取り操作を実行するアプリケーションで L2 キャッシュは役立ちますが、すべての読み取りデータページを L1 キャッシュに収容することはできません。

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

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

1 前のサブセクション、十分な物理メモリとデータベースキャッシュを確保するで説明したように、最も重要な考慮点の 1 つは、ディスクおよびキャッシュ間のデータページの頻繁なスワップを避けるために十分なデータベースメモリキャッシュを確保することです。詳細については、そのセクションを参照してください。

ディスク I/O を減らす最良の方法の 1 つは、動的なレベル 2 キャッシュを必ずオンにすることです。レベル 2 キャッシュはキャッシュ要求がレベル 1 固定キャッシュの容量を超えたとき、アプリケーションの使用量の変化によってサイズを動的に調整して可能な限り多くのデータをメモリに格納し、それによりディスク I/O を減らします。デフォルトで、レベル 2 キャッシュはオンになっています。データベースエンジンがレベル 2 キャッシュを使用していることを確認するには、設定プロパティの［MicroKernel の最大メモリ使用量］を調べます（MicroKernel の最大メモリ使用量を参照してください）。

2 次に、システム異常の場合に、どれだけのロギングが必要で、どれだけのデータベースオペレーションを失ってもかまわないかを考慮します。失ってもかまわない変更が多いほど、パフォーマンスの向上を追求することができます。

アーカイブログの使用、トランザクション一貫性保守およびトランザクションログは、すべてログファイルを必要とします。デフォルトで、アーカイブロギングはオフになっています。定期的なバックアップを実行し、システム異常の時点のデータに回復する能力を必要とする場合にのみこれをオンにします。ログの対象とするファイルを指定するときには、完全にログを必要とするファイルのみを指定するようにしてください。詳細については、第 9 章のログ、バックアップおよび復元を参照してください。

デフォルトで、トランザクションログはオンになっています。トランザクションログをオフにすると、パフォーマンスは若干向上しますが、複数ファイルの一貫性とトランザクションアトミシティは保証されません。トランザクションログをオフにする前に、アプリケーションがこの機能を使用しないで実行できるかどうかをベンダーに確認してください。

デフォルトで、トランザクション一貫性保守はオフになっています。アプリケーションでシステムクラッシュが起きてもトランザクション処理が完了することを必要とする場合は、この機能を有効にします。トランザクション一貫性保守を使用すると、パフォーマンスに最も高いペナルティが課されますが、引き換えに完了したトランザクションの最高の安全性を引き出します。

3 いずれかのロギング機能をオンにしている場合、エンジンがディスクに書き込む前にどれだけのデータを保存するかを指定することができます。変更データは繰り返し作成されるので、この機能は重要です。メモリに構築するログデータの許容量が多いほど、ディスク書き込みの頻度は減ります。

［ログバッファーサイズ］設定は、エンジンがデータベース操作をログファイルに書き出す前に、メモリに格納しておくバイト数を指定します（サーバーのプロパティツリーで［パフォーマンスチューニング］をクリックします）。

4 トランザクション一貫性保守をオンにしている場合、ディスク上のログセグメントの最大サイズを指定することができます。小さいログセグメントは作成と閉じることを繰り返すので、大きなログセグメントサイズを指定すると、若干パフォーマンスを向上させることができます。

［トランザクションログサイズ］設定は、ログセグメントを閉じて新しいログセグメントを開くまでにログセグメントに格納できる最大バイト数を指定します（サーバーのプロパティツリーで［パフォーマンスチューニング］をクリックします）。

5 データベースの使用率が高い場合には、データファイルが存在するのとは物理的に異なるボリュームにログが保持されるようシステムを構成する必要があります。一般的に高負荷の下では、単一ドライブで I/O 帯域幅を競う代わりに、ログファイルへの書き込みとデータファイルへの書き込みを別々のドライブに分ける方がパフォーマンスがよくなります。全体的なディスク I/O は減少しませんが、ロードはディスクコントローラー間で効率よく分散されます。

6 アプリケーションの使用方法がデータベース読み取り処理に重点を置いている場合、［インデックスバランスの実行］を調整することにより、パフォーマンスを向上させることができます（サーバーのプロパティツリーで［パフォーマンスチューニング］をクリックします）。インデックスバランスは通常のインデックスページのノード数を増やし、読み取り操作を速くします。ただし、Insert、Update、および Delete オペレーションでは、エンジンは隣接ページにまたがってインデックスノードのバランスをとるため、ディスク I/O 時間が余計に必要になることがあります。

7 MicroKernel および ODBC レベルの両方でトレースを必ずオフにしてください。トレースは、多くのディスク I/O を引き起こすため、パフォーマンスを著しく低下させます。

ODBC のトレースがオフであることを確認するには、PSQL Control Center から ODBC アドミニストレーターを起動します。ODBC アドミニストレーターで［トレース］タブをクリックします。トレースがオフの場合、［トレースの開始］と表示されたボタンがあるので、［キャンセル］をクリックします。トレースがオンの場合は、［トレースの停止］ボタンをクリックし、［OK］をクリックします。

MicroKernel のトレースがオフであることを確認するには、設定プロパティの［トレースオペレーションの実行］がオフに設定されている（チェックされていない）かを調べます（サーバーのプロパティツリーで［デバッグ］をクリックします）。

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

1 ［I/O スレッド数］設定により、ファイル操作の処理に利用できるスレッド数を指定することができます（サーバーのプロパティツリーで［パフォーマンスチューニング］をクリックします）。

ガイドラインとして、この設定の値は、アプリケーションが平均的に開くファイル数のおよそ 1/8 にします。たとえば、アプリケーションがたいてい 40 ファイルを開く場合、I/O スレッドに 5 を設定します。

Monitor を使用して、メニューから［MicroKernel］>［リソースの使用状況］を選択します。ウィンドウが開き、ファイル数に開いているファイル数の現在値とピーク値が表示されています。何度か現在値を記録して平均表示度数を出すことができます。その平均値に基づいて、I/O スレッド数に適切な設定をしてください。

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

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

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

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

•ハイパーバイザーホストには十分な数の仮想 CPU があり、同じマシン上の全仮想マシンの中で仮想 CPU の競合を最小化します。これにより、PSQL を実行する仮想マシンとの競合が避けられます。共通（アフィニティ）規則を使用する場合は、必ずすべてのコアを同じソケットで実行するようにしてください。

•PSQL データファイルは高速な物理ストレージに存在し、物理ストレージデバイスに対するスピンドルの競合およびコントローラーの競合を最小化します。

データベース 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