パフォーマンス

このページをシェアする

パフォーマンス

データベースパフォーマンスの分析およびチューニング

この章では、以下の項目について説明します。

パフォーマンスの分析

Pervasive PSQL Server の Windows 版では Windows パフォーマンスモニターで使用するパフォーマンスカウンターを提供します。Pervasive PSQL のパフォーマンスカウンターがサポートされるのは、Windows Vista 以上の Windows オペレーティングシステムのみです。パフォーマンスカウンターはデータベースエンジンの状態や動作を測定します。これによりアプリケーションのパフォーマンスを分析することができます。Windows パフォーマンスモニターは、指定の時間間隔でパフォーマンスカウンターの現在の値を要求します。

Pervasive PSQL は、パフォーマンスモニターで表示するためだけにデータを提供しており、カウンターのプロパティは変更できません。パフォーマンスモニターは以下のアイテムを制御します。

•データの表示形式。折れ線グラフ（デフォルト）、ヒストグラムおよびテキストレポートの 3 種類の形式で表示されます。

•表示フィールド。［最新］、［平均］、［最小］および［最大］というラベルが付けられています。

•値の表示用のスケール。 Pervasive PSQL は各カウンターに対してデフォルトのスケールを提供します。パフォーマンスモニターを使用すれば、個々のカウンターのスケールを変更することができます。カウンターのスケールを変更するにはを参照してください。

カウンターの値は、呼び出し元を問わず、データベースエンジンへのすべての呼び出しを反映します。つまり、トランザクショナルインターフェイス、リレーショナルインターフェイス、ネイティブな Btrieve アプリケーション、ユーティリティなど、すべてがカウンターの値の一因となります。カウンターの値はすべてのファイルを対象に収集されます。ファイルごとのカウンターは現在サポートされていません。

パフォーマンスカウンターの使用は、主にアプリケーション開発者およびその他の技術スタッフ向けの高度な機能です。Windows パフォーマンスモニターおよび一般的なカウンターの使用の詳細については、Microsoft の関連ドキュメントを参照してください。

インストール時の登録

デフォルトで、Pervasive PSQL のインストールでは Pervasive PSQL パフォーマンスカウンターをパフォーマンスモニターに登録します。このカウンターはインストール完了後に使用できるようになります。

お客様のニーズへの対応のため、本章で説明されていない Pervasive PSQL コレクターセットまたはカウンターを追加インストールすることになる可能性もあります。そのような場合は、Windows パフォーマンスモニターで提供されるコレクターセットまたはカウンターの説明を参照してください。カウンターセットまたは個別のカウンターをモニターへ追加するを参照してください。

データコレクターセット

データコレクターセットは、複数のカウンターを 1 つのコンポーネントにまとめています。このコンポーネントを使用してパフォーマンスを再確認したり記録したりすることができます。 Pervasive PSQL では以下のデータコレクターセットを提供します。

•Pervasive PSQL MicroKernel Btrieve Operations

•Pervasive PSQL MicroKernel Cache

•Pervasive PSQL MicroKernel I/O

•Pervasive PSQL MicroKernel Locks and Waits

•Pervasive PSQL MicroKernel Transactions

Pervasive PSQL MicroKernel Btrieve Operations

これらのカウンターは、トランザクショナル（Btrieve）インターフェイスに関するクライアントアプリケーションの動作の特徴を示すために役立ちます。カウンターは、指定した時点にデータベースエンジンで処理されたオペレーションの種類を報告します。

『Btrieve API Guide』のBtrieve API オペレーションも参照してください。

表 15 MicroKernel Btrieve オペレーション用のカウンター
カウンター	説明	典型的な使用法
Btrieve Close Operations/sec	1 秒あたりの Btrieve Close オペレーション数。	クライアントアプリケーションの動作を調査します。問題を解決する最初のステップとして、Btrieve オペレーションに関するアプリケーション動作の分析に役立つ可能性があります。
Btrieve Get/Step Operations/sec	1 秒あたりの Btrieve Get および Step オペレーション数。各種 Get および Step オペレーションについては、『Btrieve API Guide』の Btrieve API オペレーションを参照してください。
Btrieve Open Operations/sec	1 秒あたりの Btrieve Open オペレーション数。
Btrieve Records Deleted/sec	1 秒あたりの Btrieve レコード削除数。
Btrieve Records Inserted/sec	1 秒あたりの Btrieve レコード挿入数。
Btrieve Records Updated/sec	1 秒あたりの Btrieve レコードアップデート数。
Change Operations/sec	1 秒あたりのデータファイルを変更する Btrieve オペレーション数。
Operations/sec	1 秒あたりのオペレーション数。
Page Server Requests/sec	1 秒あたりのリモートキャッシュエンジンからのページリクエスト数。

Pervasive PSQL MicroKernel Cache

データベースエンジンは 2 つのレベルのメモリキャッシュシステムを使用してデータ操作のパフォーマンスを向上させます。2 つのキャッシュは「L1（レベル 1）キャッシュ」と「L2（レベル 2）キャッシュ」と呼ばれます。

ユーザーの要求に応じエンジンがディスクからページを読み取る頻度が高くなるほど、パフォーマンスは低下します。これらのカウンターを使用すると、データベースエンジンによるディスク読み込みの回避状況をまとめて表示し、キャッシュサイズの設定に対してなんらかの変更が必要かどうかを判断することができます。

すべてのデータが L1 キャッシュに格納された場合は最高のパフォーマンスが得られます。ただし、データファイルのサイズによっては、L1 キャッシュにすべてのデータページを保持できないこともあります。このため、データベースエンジンは第 2 レベルのキャッシュ（L2 キャッシュ）も使用します。L2 キャッシュのページは圧縮形式で格納されるため、より多くのページをメモリに入れることができます。そのため、L1 キャッシュよりもパフォーマンスは低下しますが、データベースエンジンがディスクからページを読み込む状況と比べればパフォーマンスは高くなります。

データベースのメモリキャッシュの理想的なサイズを計算するにはも参照してください。

表 16 MicroKernel キャッシュ用のカウンター
カウンター	説明	典型的な使用法
Level 1 Cache Dirty Percentage	ダーティページを含む使用中の L1 キャッシュの割合 (%)。	頻繁にアクセスされるページが継続的にキャッシュの外へ出されるかどうかを判断するのに役立ちます。そのようなページが継続的にキャッシュの外へ出されるとパフォーマンスが低下する可能性があります。ディスクへ書き込まれていない変更を含むダーティページは、L1 キャッシュに存在しているだけかもしれません。大量に書き込みが行われる状況下では、L1 キャッシュにダーティページが含まれる可能性が高くなります。これによってページが強制的に L1 キャッシュから出され、L2 キャッシュを設定していれば L2 キャッシュへ入れられます。L2 キャッシュを設定していなければ L1 キャッシュの外へ完全に出されてしまいます。データベースエンジンは、指定した間隔で、または L1 キャッシュがほぼいっぱいになったときにダーティページをディスクへ書き込みます。ページが頻繁にディスクへ書き込まれると、パフォーマンスに悪影響を及ぼす可能性があります。 L1 キャッシュのサイズを調整してダーティページの割合が高くならないようにすれば、パフォーマンスを向上させることができます。キャッシュ割当サイズも参照してください。
Level 1 Cache Hits/sec	1 秒あたりの L1 キャッシュヒット数。	データベースエンジンが、要求されたページを L1 キャッシュで見つけることができたかどうかを判断するのに役立ちます。ヒット率が高くなると、データベースエンジンが L2 キャッシュまたは物理記憶域へアクセスすることなく L1 キャッシュでページを見つけていることを示します。
Level 1 Cache Hit Ratio	L1 キャッシュアクセスのヒット率 (%) 。 MicroKernel が有効である間だけ割合が表示されます。
Level 1 Cache Misses/sec	1 秒あたりの L1 キャッシュ失敗数。
Level 1 Cache Usage	現在使用中の L1 キャッシュの割合 (%)。	L1 キャッシュのサイズをアプリケーションに応じて調整する場合に役立ちます。たとえば、サイズが小さなデータファイルまたは主に読み取り専用のデータファイルを使用するアプリケーションの場合、デフォルトで設定された L1 キャッシュはそのデータファイルだけではいっぱいにならないかもしれません。L1 でメモリが使用されなくても、オペレーティングシステムまたはその他のアプリケーションがその未使用分のメモリを使用することはできません。 L1 キャッシュサイズを適宜変更すれば、メモリをオペレーティングシステムへ解放することができます。逆に、データベース全体をメモリに入れておきたい場合は、L1 キャッシュサイズの設定が妥当かどうかを知るためにこの値を監視することができます。
Level 2 Cache Hits/sec	2 秒あたりの L1 キャッシュヒット数。	データベースエンジンが、要求されたページを L2 キャッシュで見つけることができたかどうかを判断するのに役立ちます。ヒット率が高くなると、データベースエンジンが物理記憶域へアクセスすることなく L2 キャッシュでページを見つけていることを示します。
Level 2 Cache Hit Ratio	L2 キャッシュアクセスのヒット率 (%) 。 MicroKernel が有効である間だけ割合が表示されます。
Level 2 Cache Misses/sec	1 秒あたりの L2 キャッシュ失敗数。
Level 2 Cache Raw Size	L2 キャッシュの現在のサイズ (バイト)。	任意指定の L2 キャッシュサイズを決定するために役立ちます。 L2 キャッシュは MicroKernel の最大メモリ使用量用に設定される要素の 1 つです。その設定は、総物理メモリに対してデータベースエンジンが消費できるメモリの割合を指定します。これには、データベースエンジンによる、L1 キャッシュ、L2 キャッシュおよびその他すべてのメモリの使用量が含まれます MicroKernel の最大メモリ使用量の設定が 0 以外の場合、L2 キャッシュのサイズはその設定によるメモリ制限内に収まります。L2 キャッシュはシステムのメモリ消費を監視し、必要に応じて自身のサイズを変更します。L2 キャッシュによって使用されるメモリは、オペレーティングシステムによってスワップアウトされることもあります。
Level 2 Cache Raw Usage	現在使用中の L2 キャッシュの量 (バイト)。
Level 2 Cache Size Relative to Memory	物理メモリに対する L2 キャッシュサイズの割合 (%)。	システムメモリに対する L2 キャッシュの使用割合を示します。
Level 2 Cache Usage	現在使用中の L2 キャッシュの割合 (%)。	現時点における L2 キャッシュの使用割合を示します。

Pervasive PSQL MicroKernel I/O

このセットのカウンターは、データベースエンジンによる、物理記憶域へのデータの読み取りおよび書き込み状況を把握するのに役立ちます。カウンターによって報告されるページとはデータファイルページです。これらのカウンターでは、アーカイブログまたはトランザクションログ向けに使用されるファイルのページ用のデータは報告しません。

『Pervasive PSQL Programmer's Guide』のページも参照してください。

表 17 MicroKernel 入力/出力用のカウンター
カウンター	説明	典型的な使用法
Pages Read/sec	1 秒あたりのディスクからの読み取りページ数。	データベースエンジンによる、物理記憶域へのデータの読み取りおよび書き込み状況を測定します。
Pages Written/sec	1 秒あたりのディスクへの書き込みページ数。	データベースエンジンによる、物理記憶域へのデータの読み取りおよび書き込み状況を測定します。

Pervasive PSQL MicroKernel Locks and Waits

クライアントの要求は、リソースが使用可能になるのを待つため遅延することがあります。これらのカウンターを使用すれば、リソースが使用可能になるまでクライアント要求を待つ必要があるデータベースリソースのタイプを特定することができます。同様に、これらのカウンターでは複数のクライアントがリソースへアクセスしたときのデータベースエンジンの動作を観察することができます。値がクライアント数に近いまたは等しい場合は、同じリソースに対して競合している可能性があることを示しています。これらの競合を低減するための是正措置を行えば、反応性を改善することができます。

Waits on Page Buffers および Waits on Page Reads カウンターはグローバルリソースを待機します。その他のカウンターはすべて複数のクライアントに適用しますが、各クライアントはそれぞれ異なるリソースを待機している場合があります。

『Pervasive PSQL Programmer's Guide』のデータの整合性および複数のクライアントのサポートを参照してください。

表 18 MicroKernel ロックおよび待機用のカウンター
カウンター	説明	典型的な使用法
Client Record Locks	クライアントによって明示的にロックされたレコード数。	クライアントアプリケーションの作業負荷を調査します。
Waits on Active Reader Lock	アクティブなリーダーロックを待機中のクライアント数。複数のクライアントが同時にアクティブなリーダーロックを保持できます。ただし、アクティブなリーダーロックとアクティブなライタロックは排他的に使用されます。そのため、1 つのクライアントがアクティブなリーダーロックを保持すると、どのクライアントもアクティブなライタロックを取得することはできません。1 つのクライアントがアクティブなライタロックを保持すると、複数のクライアントがアクティブなリーダーロックを取得することはできません。各ファイルがそれ自身のリーダー（およびライタ）ロックを持っています。 Waits on Active Writer Lock カウンターも参照してください。
Waits on Active Writer Lock	アクティブなライタロックを待機中のクライアント数。一度に 1 つのクライアントだけがアクティブなライタロックを保持できます。各ファイルがそれ自身のライタ（およびリーダー）ロックを保持します。 Waits on Active Reader Lock カウンターも参照してください。
Waits on File Locks	現在ファイルロックで待機中のクライアント数。
Waits on Page Buffers	ページバッファーが利用可能になるのを待機中のクライアント数。もしページがリクエストに応じるためにアクセス可能でない場合は、リクエストは MicroKernel が 1 ページを提供することが可能になるまでブロックします。	データベースエンジンが、キャッシュのページバッファーを使用できるかどうかを示します。この値をメモリキャッシ関連のカウンターと一緒に使用して、キャッシュのサイズが作業負荷に対して適切かどうかを確認します。キャッシュサイズを大きくすると使用可能な総ページ数も増えます。これにより、ページバッファーへの待機を減らすことができます。キャッシュにページがない場合は、以下の 3 つ状況によってこの値が急増する可能性があります。 •データファイルが最近開かれた •データページへ初めてアクセスする、またはそのデータページへアクセスすることがほとんどない •メモリキャッシュが、頻繁にアクセスおよび変更されるすべてのページを含めることができないほど小さい可能性がある 1 番目と 2 番目の項目によって値が急増するのは、ファイルへのアクセスが初めてであるため回避することはできません。3 番目の状況はキャッシュサイズを大きくすることで回避できます。キャッシュがいっぱいでキャッシュ失敗数が多くなると、メモリキャッシュが小さすぎて、頻繁にアクセスおよび変更されるすべてのページを含めることができない可能性があります。 MicroKernel キャッシュ用のカウンターも参照してください。
Waits on Page Locks	現在ページロックで待機中のクライアント数。	クライアントアプリケーションの作業負荷を調査します。
Waits on Page Reads	ディスクからページ読み取りを待機中のクライアント数。1 つのクライアントが既にページの読み取り処理を行なっている場合、ほかのクライアントは処理中の読み取りが完了するまで待機しなければなりません。	同時に同じファイルの同じページへの読み取りを試みるクライアント数を測定します。
Waits on Record Locks	現在レコードロックで待機中のクライアント数。	クライアントアプリケーションの作業負荷を調査します。

Pervasive PSQL MicroKernel Transactions

これらのカウンターは、トランザクションに関するクライアントアプリケーションの動作を理解するために役立ちます。たとえば、変更が多く処理に長時間かかる少数のトランザクションと、短時間で処理が完了する多くのトランザクションとでは動作が異なります。

『Btrieve API Guide』の Begin Transaction（19 または 1019）、End Transaction（20）および Abort Transaction（21）、また『Pervasive PSQL Programmer's Guide』のトランザクショナルインターフェイスの基礎も参照してください。

表 19 MicroKernel トランザクション用のカウンター
カウンター	説明	典型的な使用法
System Transactions in Progress	進行中のシステムトランザクション数。システムトランザクションはデータファイルの変更を準備し、その変更をファイルに保持し続ける特殊なタイプのトランザクションです。	システムトランザクションの発生頻度が高すぎるまたは低すぎるかどうかを判断するために役立ちます。データベースエンジンは、システムトランザクション中に変更をデータファイルへ書き込みます。システムトランザクションが発生する頻度は、起動時間制限およびオペレーションバンドル制限という 2 つのサーバー設定パラメーターによって決められるか、あるいは L1 キャッシュの空き領域が少ないことが影響します。通常、システムトランザクションの実行頻度が高すぎたり低すぎたりするとパフォーマンスに悪影響を及ぼします。一般的には、1 秒あたりのページ書き込み数が増加し、レコードを変更する Btrieve オペレーション数は減少し、またアクティブなライタロックを待機するクライアント数は増加する可能性があります。これは特定の作業負荷に対する理想的な間隔を測定するための実験が必要となることもあります。
Transaction Commits/sec	1 秒あたりに実行されたコミット数。	アプリケーショントランザクションのコミット数を測定します。『Btrieve API Guide』のEnd Transaction（20）も参照してください。

Windows パフォーマンスモニターの使用

このセクションでは、Windows パフォーマンスモニターの基本的な使用手順について説明し、Pervasive PSQL パフォーマンスカウンターを使用できるようにします。Windows パフォーマンスモニターの使用に関する詳細については、Microsoft のドキュメントを参照してください。

以下に示す手順は、Pervasive PSQL のインストールによって Pervasive PSQL パフォーマンスカウンターが Windows パフォーマンスモニターに登録されていることを前提としています。

►Pervasive PSQL データコレクターセットを表示する

1 Windows パフォーマンスモニターを起動します。このユーティリティの起動手順はオペレーティングシステムによって異なりますが、一般的には［コントロールパネル］の［管理ツール］から起動することができます。また、［ファイル名を指定して実行］ウィンドウ（［スタート］メニューから［ファイル名を指定して実行］を選択）で、「perfmon」と入力し［OK］をクリックして起動することもできます。

2 左ペインのツリーから［パフォーマンスモニター］をクリックし、右ペイン上部のツールバーにあるプラス記号（＋）をクリックします。

3 ［使用可能なカウンター］セクションのカウンターリスト内で、Pervasive PSQL データコレクターセットへスクロールします。

►カウンターセットまたは個別のカウンターをモニターへ追加する

1 以下の手順のいずれかを実行します。

a. カウンターセットとしてまとめて追加するには、［使用可能なカウンター］リストから希望のカウンターセット項目をクリックします。

b. カウンターを個別に追加するには、そのカウンターが属するカウンターセットを展開し（カウンターセットの項目をダブルクリック、または右端の下矢印をクリック）、その中から対象のカウンターをクリック（複数クリック）します。

カウンターの説明を見るには、［説明を表示する］オプションを選択してください。

2 ［追加］をクリックしてから［OK］をクリックします。

►カウンターのスケールを変更するには

1 作業対象のカウンターを右クリックし、［プロパティ］をクリックします。

2 ［データ］タブで、［スケール］ドロップダウンリストから希望の値をクリックします。

同じグラフ上に 2 つ以上のカウンターを表示する場合に、それらカウンターの出力数値の差が非常に大きい場合は、適切に表示されるようスケールを調整する必要があるかもしれません。データがグラフ化される前に、カウンターの出力値にスケール値を掛けます。たとえば、1 番目のカウンターの出力値が 53 と 99、2 番目のカウンターの出力値が 578 と 784 であるとします。 1 番目のカウンターのスケールに 10 を設定することで、530 および 990 と出力されるようにするこができます。これにより、両カウンターのデータをより同等（530、990、578 および 784）に見ることができます。

3 ［OK］をクリックします。

［スケール］フィールドの値は、元の値（この例では 1）から新しい値（この例では 10）に変更されています。

4 ［グラフ］タブで、［垂直スケール］セクションの［最大］および［最小］フィールドに必要な値を設定します。

グラフ化される対象が非常に小さい（または非常に大きい）場合は垂直スケールを変更することができるので、グラフが見やすくなります。たとえば、カウンターの出力値が常に 20 未満の場合は、垂直スケールの最大を 20、最小を 0 に変更することができます。

5 ［OK］をクリックします。

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

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

•ネットワークの帯域幅および使用率

•アプリケーションでのコーディング技法

•使用可能な物理記憶域

•使用可能なメモリ

•プロセッサの速度

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

•CPU サイクルで競合する無関係なアプリケーション

•データベースエンジン設定

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

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

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

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

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

•MicroKernel｜リソース使用状況

•MicroKernel｜通信

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

表 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 これらの変更を有効にするために、［はい］をクリックしてエンジンを再起動します。

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

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

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

•十分な CPU 能力。CPU が、データ処理リクエストの流入量について行けなくなると、アプリケーションのパフォーマンスが悪影響を受けます。

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

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

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

結局、最適化されたパフォーマンスは、ネットワークのボトルネック、ディスク 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 キャッシュサイズ：システムのメモリロードに基づいて拡大および縮小するメモリ容量

以下の点に注意してください。

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

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

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

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

ディスク 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 ドライバーについては、システム要件も参照してください。

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

Pervasive PSQL Vx Server は、ハイパーバイザー製品や仮想マシン環境用のデータベース製品です。Pervasive PSQL Vx Server で最高のパフォーマンスを実現するには、以下の事項を順守してください。

•ハイパーバイザーベンダーからのパフォーマンス最良実施例に従うこと。

•Pervasive PSQL Vx Server をホストする仮想マシンに十分なメモリ（RAM）が確保されていること。

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

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

Xtreme I/O ドライバー

Pervasive PSQL 32 ビットサーバー製品（Windows 版）には、Xtreme I/O（XIO）と呼ばれるデータベースアクセラレータがオプションで含まれています。 XIO の使用するための最低限のシステム要件を満たしていれば、カスタムインストールを使用してこのオプションをインストールできます。 XIO は Pervasive PSQL データファイルのディスクアクセスを加速させることによってデータベースのパフォーマンスを向上させます。

XIO とデータベースエンジンは共同してパフォーマンスを高めます。データファイルが開かれると、エンジンは XIO に通知します。その時点から、XIO はそのデータファイルへのディスクアクセスを加速させます。 XIO は透過的に動作し、ユーザーやアプリケーションの介入は必要ありません。

XIO では、アクセスを加速したくないデータファイルを除外することができます。除外を指定するのは簡単で、テキストファイルを更新してデータベースエンジンを再起動するだけです。

以下のトピックでは、XIO の追加情報を提供します。

•留意点

Pervasive の Web サイトの Pervasive PSQL 技術白書で XIO の技術白書も参照してください。この白書では、技術的な説明をこのセクションより詳細に行っています。

留意点

一般的に、XIO は、サイズの大きなデータセットを使用するほとんどのアプリケーションのパフォーマンスを向上させます。XIO の使用上の留意点を次の表に示します。

表 21 XIO 使用上の留意点
条件	説明
アプリケーションはデータに対してランダムアクセスを使用する（データアクセスの傾向はシーケンシャルではない）	このようなパターンは、データベース管理システムを使用するアプリケーションの特徴です。
データセットは Windows システムキャッシュに完全に収まらないほど大きい	Windows システムキャッシュのサイズと比べてデータセットサイズが大きければ大きいほど、ディスクの読み取りと書き込みはより頻繁に行われます。 XIO は、このようなときに読み取りと書き込みをキャッシュすることができます。データが Windows システムキャッシュに完全に収まっている場合、XIO は読み取りや書き込み要求を処理しません。
アプリケーションは頻繁にディスクアクセス操作（読み取りおよび書き込み）を実行する	ディスクアクセスは、多くの場合アプリケーションの最も速度の遅い局面です。
既にサードパーティ製のディスク入出力を加速するプログラムを使用している	ディスク I/O を加速するプログラムを複数使用することは、お勧めできません。このようなプログラムは互いに干渉し、予測不能な結果を生みます。この理由により、XIO のみをディスク I/O プログラムとして実行してください。

システム要件

XIO は、以下の要件を満たすプラットフォームにのみインストールすることができます。

•Windows サーバークラス 32 ビットオペレーティングシステム（XIO は 64 ビットプラットフォームではサポートされません）。

•Windows Server 2008 RTM（6.0.6001）または Service Pack 2（SP2, 6.0.6002）、またはそれ以上

•Windows Server 2003（最新の Service Pack を適用）

•CPU は Pentium III 以上である必要があります。

•最低 4 GB 利用可能なシステム RAM。XIO は実行時のメモリ要件もチェックするので注意してください。実行時でメモリが 4 GB に満たない場合、XIO は実行しません。

•Pervasive PSQL データファイルは、NTFS ファイルシステムに存在する必要があります。FAT32 ファイルシステムのデータファイルはサポートされません。ファイルシステムの詳細についてはオペレーティングシステムのマニュアルを参照してください。

XIO をインストールしたら、システムの設定を以下のようにする必要があります。

•オペレーティングシステムのラージシステムキャッシュはオフにする必要があります。つまり、Windows レジストリのラージシステムキャッシュ設定にゼロを設定してください。XIO がインストールされている場合は、Pervasive PSQL インストールプログラムがラージシステムキャッシュをオフに設定します。

•Pervasive PSQL の L2 キャッシュはオフにする必要があります。つまり、［MicroKernel の最大メモリ使用量］にゼロを設定してください。MicroKernel の最大メモリ使用量を参照してください。XIO がインストールされている場合は、Pervasive PSQL インストールプログラムが L2 キャッシュをオフに設定します。

XIO メモリキャッシュ

XIO はブロックレベルのキャッシングを使用しますが、これはデータベースエンジンが速度向上を必要とする特定のファイルに対してのみです。XIO のメモリキャッシュは、Pervasive PSQL データファイル専用です。たとえば、XIO を非 Pervasive ファイルの汎用ディスクアクセラレータとして使用することはできません。

XIO は、高度な追跡およびキャッシュアルゴリズムを使用してキャッシュを管理します。このアルゴリズムについては、このセクションで説明する範囲を超えていますので、解説しません。ただし、XIO のメモリの使用方法を知ることにより、このドライバーがどのように機能するかをよりよく理解することができます。

メモリの使用

XIO は拡張メモリ、標準メモリ、またはその両方を使用します。

拡張メモリ

XIO は、拡張メモリが使用可能な場合、まず拡張メモリをキャッシュに使用します。拡張メモリは、物理アドレス拡張（PAE）メモリとも呼ばれます。拡張メモリは、4 GB を超えた RAM です。

XIO は、最大 MaxPAEMemMB レジストリに指定された値まで、オペレーティングシステムが許す限り大きな拡張メモリを予約します。レジストリ設定を参照してください。XIO は拡張メモリをシステムがシャットダウンするまで保持します。つまり、キャッシュ全体が拡張メモリに保持されれば、キャッシュサイズは変化せず、縮小または拡張します。

標準メモリ

拡張メモリが存在しない場合、XIO は標準メモリからキャッシュを取得します。標準メモリは、4 GB までの RAM です。標準メモリでは、XIO はデータベースエンジンのメモリ要求とシステム全体のメモリ要求のバランスをとります。XIO のキャッシュは、ほかのシステムリソースがメモリを取得および開放するように、縮小および拡張します。

MaxCacheSizeMB のレジストリ値が -1（デフォルト）の場合、XIO は現在のシステムの状態に基づいてキャッシュサイズを増加または減少させて調整を行います。この場合の最大キャッシュサイズは、物理メモリのおよそ 80% です。

MaxCacheSizeMB が数メガバイトに設定されている場合、XIO はオペレーティングシステムが許可するその値までしか拡張しません。

MaxCacheSizeMB にインストールされているメモリを超えた値を設定すると、Windows イベントログにエラーが書き出され、ドライバーは読み込まれません。イベントログメッセージを参照してください。

MaxCacheSizeMB は、標準メモリと PAE メモリ（存在する場合）との組み合わせに基づいたキャッシュの最大サイズです。キャッシュは、メモリがどこにあろうと MaxCacheSizeMB の値を超えて大きくなることはできません。レジストリ設定を参照してください。

メモリの組み合わせ

拡張メモリが存在してもオペレーティングシステムが MaxPAEMemMB に指定された値のメモリを割り当てられない場合、XIO は拡張メモリと標準メモリを組み合わせて使用します。XIO は、4 GB に満たない標準メモリを使用する前に、オペレーティングシステムから利用可能な 4 GB を超える拡張メモリを使用して MaxCacheSizeMB 設定を実現します。標準メモリに存在する XIO キャッシュは必要に応じて縮小および拡大します。

レジストリ設定

Windows のレジストリには XIO の設定パラメーターが含まれています。パラメーターの大多数は予約されていて変更できません。

ただし、MaxCacheSizeMB および MaxPAEMemMB レジストリエントリは設定可能です。

レジストリキー1	用途	有効な値	説明
MaxCacheSizeMB	XIO が使用する物理メモリの最大量をメガバイト（MB）で指定します。	-1 または使用する値を MB 単位で指定します。デフォルト： -1	この設定は、PAE メモリが存在する場合には、標準メモリと PAE メモリを組み合わせた最大値です。 -1 を指定すると、XIO は必要に応じ標準メモリ内でキャッシュを動的に増大または縮小します。 Pervasive では MaxCacheSizeMB に -1 を設定して XIO がキャッシュを動的に調整できるようにすることを推奨します。
MaxPAEMemMB	XIO がキャッシュに使用する物理アドレス拡張（PAE）メモリの最大値をメガバイト単位で指定します。	0 または使用する値を MB 単位で指定します。デフォルト： 8192	PAE メモリは、4 GB を超えた RAM です。
1HKEY_LOCAL_MACHINE\SOFTWARE\PERVASIVE SOFTWARE\XIO

注意：上の表に挙げられている以外の XIO レジストリエントリは変更しないでください。予測不能な結果を招きます。

レジストリの編集は高度な操作です。誤って編集すると、オペレーティングシステムが起動しなくなる恐れがあります。必要であれば、経験豊富な技術者に依頼して編集を行ってもらってください。

よく寄せられる質問

このセクションでは、XIO に関する一般的な質問について説明します。

質問	回答
XIO をクラスター環境で使用できますか？	いいえ。Pervasive PSQL をクラスター環境で使用する場合は、Xtreme I/O をインストールしてはいけません。マシンがフェールオーバーによってオンラインになり、共有記憶域をアクセスできないままにしておくと、ノードに XIO がインストールされている場合、そのノードがハングすることがあります。そのため、Pervasive PSQL インストールの［セットアップタイプ］ダイアログでは、［カスタム］を選択してください。使用可能なインストールオプションとして［Pervasive Xtreme I/O］が表示される場合は、そのオプションをクリックして、［この機能は使用できなくなります。］を選択します。 Pervasive PSQL インストールの残りを完了します。これ以上のカスタマイズは必要ありません。
XIO を仮想マシンで使用できますか？	いいえ。Pervasive PSQL を仮想マシンで使用する場合は、Xtreme I/O をインストールしてはいけません。
Pervasive PSQL Vx Server には XIO が含まれていますか？	いいえ。 Pervasive PSQL Vx Server は物理マシンにインストールすることはできますが、これは主に仮想環境向けに用いられるものです。XIO は仮想環境で使用できないので、Pervasive PSQL Vx Server には含まれていません。
XIO がインストールされているかどうかは、どうしたらわかりますか？	pvsw.log ファイルの XIO メッセージをチェックしてください。Pvsw.log のメッセージを参照してください。あるいは、コマンドプロンプトで xiomgr というコマンドを実行します。オペレーティングシステムが xiomgr のヘルプ情報を表示すれば、XIO ドライバーがインストールされています。
XIO が有効かどうかは、どうしたらわかりますか？	xiomgr -query のように、xiomgr ユーティリティに "query" オプションを付けて実行します。このユーティリティは XIO の現在の状態（有効または無効）および実行中かどうかを表示します。Xiomgrを参照してください。さらに、pvsw.log ファイルの XIO メッセージをチェックすることができます。Pvsw.log のメッセージを参照してください。
XIO が実行中かどうかは、どうしたらわかりますか？
XIO キャッシュがメモリをどれだけ使用しているかは、どうしたらわかりますか？	Xiostats ユーティリティを実行します。 "キャッシュサイズ" 統計情報に XIO キャッシュのサイズがメガバイト（MB）単位で示されます。Xiostats 統計情報も参照してください。
XIO キャッシュがどれくらい有効かは、どうしたらわかりますか？	一般的に、"読み取りヒット率" 統計情報のパーセンテージをチェックします。パーセンテージが大きいほど XIO はキャッシュを多く使用しており、XIO はより効果的にパフォーマンスを向上させています。より範囲を狭めるには、"キャッシュ可能な IO %" 統計情報を調べることもできます。これは、Pervasive PSQL データのみに関連するすべての I/O リクエストのパーセンテージを示します。高いパーセンテージは、ディスクアクセスリクエストの大多数が Pervasive PSQL データに関連していることを示します。 Xiostats 統計情報も参照してください。
XIO キャッシュにどのファイルがキャッシュされているかは、どうしたらわかりますか？	Xiostats ユーティリティを実行します。［表示｜開いているファイル］をクリックします。機能の全容も参照してください。
"開いているキャッシュファイル" 統計情報の値は、自分で開いたと思っているファイル数より多かったり少なかったりするのはなぜですか？	データベースエンジンはファイルを開いて閉じることがあります。このような場合は "開いているキャッシュファイル" にはカウントされません。4 つにセグメント化された Pervasive PSQL ファイルを開くと、1 つだけではなく 4 つのファイルが開いていると表示されます。データベースエンジンはセグメントごとに Open オペレーションを実行します。システムファイルおよびデータ辞書ファイルも開かれ、これらも合計に含まれます。 Xiostats 統計情報も参照してください。

各種ユーティリティ

XIO は、ドライバーに関する 2 種類のユーティリティ xiomgr と xiostats を提供します。

Xiomgr

適用

Windows（32 ビット）	Linux	クライアント	サーバーデータベースエンジン
Yes	No	No	Yes

説明

Xiomgr は XIO ドライバーを管理します。

概要

オプション

-query	XIO ドライバーの現在の状態を報告します。たとえば、実行中であるとか、有効であるなどです。
-start	XIO ドライバーを起動します。 xiomgr -stop コマンドの後で実行する場合は、まず、データベースエンジンが開始していることを確認してください。XIO のトラブルシューティングも参照してください。
-stop	XIO ドライバーを停止します。まず、データベースエンジンサービスを停止する必要があります。XIO のトラブルシューティングも参照してください。
-enable	オペレーティングシステムが起動したときに XIO ドライバーを起動します。 enable オプションは、次にオペレーティングシステムを起動したときに有効になります。
-disable	オペレーティングシステムが起動したときに XIO ドライバーが起動しないようにします。 disable オプションは、次にオペレーティングシステムを起動したときに有効になります。
-help	ユーティリティの使用法に関する情報を表示します。

Xiostats

このユーティリティは XIO キャッシュに関する統計情報を表示します。

Xiostats は、本来、統計情報とグラフ化データの調査を十分に理解しているユーザー向けの高度なユーティリティです。そうであっても、このユーティリティではいくつかの基本的な統計情報を提供します。Xiostats に関する一般的なヒントについては、よく寄せられる質問を参照してください。

統計情報

Xiostats の主な目的は、XIO および XIO キャッシュに関する統計情報を提供することです。この情報は、このユーティリティのメインウィンドウにマトリックスとして表示されます。次の表では統計情報について説明します。

表 22 Xiostats 統計情報
統計情報	説明
時間	システム日付および時刻。
経過秒数	Xiostats が起動されてから経過した秒数。つまり、どれだけの時間実行されたかを秒数で示します。
物理メモリ MB	そのマシンの拡張メモリを含む物理メモリの合計の概算。
キャッシュサイズ	XIO キャッシュのサイズ（メガバイト単位）。この値は、キャッシュがどのメモリを使用するかによって異なります。メモリの使用を参照してください。
開いているキャッシュファイル	開いていて、実際にキャッシュされている（ファイルが読み取られているかまたは書き込まれている）Pervasive PSQL ファイルの数。開いているキャッシュファイルの合計数は、自分で開いていると思っている数と異なることがあります。1 つのファイルを開くことによって、複数の物理ファイルが開かれることがあります。たとえば、4 つにセグメント化された Pervasive PSQL ファイルでは、1 つだけではなく 4 つのファイルが開いていると表示されます。データベースエンジンはセグメントごとに Open オペレーションを実行します。
圧縮率	キャッシュによって実行されるデータ圧縮の量。たとえば、圧縮率が 8（8 が 1 になることを意味します）であると仮定します。キャッシュのサイズが 1 GB で圧縮率が 8 の場合、キャッシュには 8 GB のデータが格納されます。この比率は、データの特性によって異なります。データによっては圧縮可能ですが、圧縮できないものもあります。
読み取りヒット率	"ヒット" は、XIO が物理ディスクではなくキャッシュから読み取るデータを対象とします。一般的に、このパーセンテージが高いほど XIO が効率的に実行されています。メモ：データが全部 Windows システムキャッシュに収まっている場合、XIO は読み取り要求を処理しません。
ダーティバッファー %	キャッシュに既に書き込まれて、まだディスクには書き込まれていないキャッシュ内のデータ量。
キャッシュ可能な IO %	Pervasive PSQL データのみに関連するすべての I/O リクエストのパーセンテージ（XIO は、すべてのディスクアクセス要求を認識しますが、Pervasive PSQL データに関連するもののみに動作します）。サーバーが Pervasive PSQL 専用である場合、キャッシュ可能な IO % は高いパーセンテージを示します。これは、ディスクアクセス要求の大多数が Pervasive PSQL データに関連するためです。
キャッシュ読み取りバイト数	キャッシュから読み込まれたバイト数。
キャッシュ書き込みバイト数	キャッシュに書き込まれたバイト数。

機能の全容

次の表は、統計情報のレポートをサポートする本ユーティリティの機能の簡単な説明です。

機能	説明
オプション	オプションダイアログを使用すると、Xiostats がキャッシュをポーリングする間隔など、ユーティリティの機能の一定の部分をカスタマイズすることができます。［オプション］コマンドは、［ファイル］メニューから使用できます。
パラメーター	パラメーター一覧は、Xiostats のさまざまなレジストリ設定を示します。これらの設定の 2 つだけがカスタマイズできます。レジストリ設定を参照してください。レジストリ設定に挙げられている 2 つ以外の XIO レジストリエントリは変更しないでください。予測不能な結果を招きます。［パラメーター］コマンドは、［表示］メニューから使用できます。
開いているファイル数	開いているファイルの一覧は、現在どのファイルが開かれ、キャッシュされているかを表示するのに便利です。［開いているファイル］コマンドは、［表示］メニューから使用できます。
パフォーマンス	［パフォーマンス］コマンドを使用すると、PerfMon ユーティリティのカウンターに簡単にアクセスできます。PerfMon ユーティリティは、Windows オペレーティングシステムの一部として含まれています。このカウンターの使用については、そのマニュアルを参照してください。
グラフ	［グラフ］コマンドを使用すると、統計情報をグラフ化してさまざまな方法で表示することができます。データは、変数、微分、積分のグラフとして表示することができます。 Xiostats ログに保存された統計情報データもグラフ化することができます。Xiostats のログは、スプレッドシートプログラムで表示可能なカンマ区切り（CSV）形式で保存されたテキストファイルです。［ファイル］メニューのコマンドを使用して、ログファイル（CSV ファイル）を開いたり閉じたりします。
ログファイル	ログファイルコマンドを使用すると、統計情報のログへの記録を開始および停止したり、ログのスケジュールを設定することができます。 Xiostats のログは、スプレッドシートプログラムで表示可能なカンマ区切り（CSV）形式で保存されたテキストファイルです。［ファイル］メニューのコマンドを使用して、ログファイル（CSV ファイル）を開いたり閉じたりします。メモ：ログ間隔が非常に短い場合、ログファイルのサイズは短期間で非常に大きくなります。

除外ファイル

XIO には xioexclude.lst というテキストファイルが含まれており、これを使用してアクセスを加速したくないデータファイルを指定することができます。一般的には、除外ファイルを追加する必要はありません。除外ファイルを選択する場合には、以下の手順に従います。

1 このファイルをテキストエディターで開きます。

デフォルトで、このファイルは %allusersprofile% の下の Pervasive Software\PSQL にあります。デフォルトで、オペレーティングシステムは %allusersprofile% の下のいくつかのフォルダーを隠しフォルダーにするため、隠しファイルを検索するようにしてください。

2 xioexclude.lst の指示に従ってファイル名を追加します。

3 オペレーティングシステムを再起動します。

Pvsw.log のメッセージ

データベースエンジンのインストール時に、XIO がインストールされ、データベースエンジンが XIO キャッシュにファイルをキャッシュすることができれば pvsw.log ファイルにメッセージが書き込まれます。このログファイルには次のようなメッセージが書き込まれます。

MicroKernel は XIO キャッシュドライバーへのアクティブなリンケージを確保しました。

メモ： XIO がインストールされているが、pvsw.log にこのメッセージが含まれていない場合は、データベースエンジンが XIO と通信することができず、ファイルはキャッシュされません。これを修正するための処置は、トランザクショナルサービスをいったん停止して再開することです。『Pervasive PSQL User's Guide』の Windows サーバー上でのサーバーエンジンの起動と停止を参照してください。サービスを再開したことによって、データベースエンジンが XIO と通信できるようになると、このメッセージが pvsw.log に書き込まれます。

イベントログメッセージ

XIO は、次の表に示すようにエラーメッセージを Windows イベントログに書き込みます。

表 23 Xiostats イベントログメッセージ
メッセージ	対処方法
XIO started.	不要。
XIO did not shut down properly.	このエラーが連続して発生する場合は、Pervasive のテクニカルサポートにお問い合わせください。
XIO failed to load because a memory allocation of %2 bytes for %3 failed.	インストールされているシステムメモリ量と、MaxCacheSizeMB および MaxPAEMemMB の設定を確認してください。
XIO detected insufficient RAM (%2MB).It requires %3MB to operate.	システム RAM を最低限必要な 2 ギガバイト（GB）に増やしてください。
XIO encountered an unrecoverable system error. %2.	Pervasive のテクニカルサポートにお問い合わせください。
XIO detected the parameter %2 has an invalid value %3. The legal range is %4 to %5. The current setting has been coerced to the default value %6.	パラメーターを正しい範囲内の値に設定してください。
NT OS Version %2.%3 is not a Server Build. XIO detected the parameter %2 has an invalid value %3. The legal range is %4 to %5. The current setting has been coerced to the minimum value %6.	パラメーターを正しい範囲内の値に設定してください。
XIO detected that the installed memory size changed from %2MB to %3MB.	インストールされているメモリを調べ、最低量の 2GB が使用可能であることを確認してください。
The maximum cache size parameter (%4MB) may need adjustment.	MaxCacheSizeMB の設定を調べ、システムメモリとデータセットの量に基づいて必要な量に調整してください。

XIO のトラブルシューティング

このセクションでは、XIO の使用中に問題が発生した場合の対処方法について提案します。

表 24 XIOトラブルシューティング
状況	説明
XIO が有効であるのに、システム起動時にロードされない。	1. オペレーティングシステムをセーフモード（一般的にシステム起動時に F8 キーを押す）で起動します。 2. XIO ドライバーが読み込まれないように、コマンドプロンプトで xiomgr -disable というコマンドを実行します。デフォルトで、xiomgr は、Program Files ディレクトリの下の Pervasive ツリーの PSQL\bin\ ディレクトリにあります。『Getting Started with Pervasive PSQL』の Pervasive PSQL ファイルはどこにインストールされますか？も参照してください。 3. オペレーティングシステムを再起動すると、XIO を開始せずにロードされます。
XIO キャッシュがデータベースエンジンの読み書きに応答しない。	この状況は、データベースエンジンおよび XIO キャッシュ間の通信がリンクされなくなった場合に起こります。以下の手順を使用して、データベースエンジンと XIO キャッシュ間の通信を再確立してください。 1. Pervasive PSQL サービスを停止します。 2. Xiomgr -stop コマンドを実行します。 3. Xiomgr -start コマンドを実行します。 4. Pervasive PSQL サービスを開始します。リンクの切断は、以下のように間違った順序で動作を行った場合に発生します。 A. Pervasive PSQL サービスを停止する。 B. Xiomgr -stop コマンドを実行する。 C. Pervasive PSQL サービスを開始する。 D. Xiomgr -start コマンドを実行する。問題は、手順 C と D の順序が逆であることです。Xiomgr -stop コマンドに続いて、まず Xiomgr -start コマンドを実行し、次に Pervasive PSQL サービスを開始する必要があります。