パフォーマンス
 
このページをシェアする                  
パフォーマンス
データベース パフォーマンスの分析およびチューニング
以下のセクションでは、データベースのパフォーマンスについて説明します。
パフォーマンスの分析
パフォーマンス チューニング
ハイパーバイザー製品でのパフォーマンス
パフォーマンスの分析
PSQL Server の Windows 版では Windows パフォーマンス モニターで使用するパフォーマンス カウンターを提供します。パフォーマンス カウンターはデータベース エンジンの状態や動作を測定します。これによりアプリケーションのパフォーマンスを分析することができます。
パフォーマンス カウンターの監視を参照してください。
パフォーマンス チューニング
このセクションでは、データベース初期接続および実行時オペレーションでパフォーマンスを最大にするための一般的なヒントをいくつか提供します。一般的なガイドラインをいくつか示しますが、特定のアプリケーションのパフォーマンスは、以下に挙げる要因だけに限らず、非常に多くの要因によって変わります。
ネットワークの帯域幅および使用率
アプリケーションでのコーディング技法
使用可能な物理記憶域
使用可能なメモリ
プロセッサの速度
アプリケーションでの使用パターン(大量の書き込み、大量の読み取り、トランザクションの使用/不使用、レコード サイズの大小、複雑または単純なクエリ、ODBC、Btrieve のみ、など)
CPU サイクルで競合する無関係なアプリケーション
データベース エンジン設定
ご覧のように、エンジンの設定は一定のアプリケーションの全体のパフォーマンスの中では比較的限定的な役割を果たします。さらに、データベース エンジンは使用パターンに基づいてさまざまなリソースを動的に管理します。データベース エンジン自体が、必要に応じ環境に合わせてチューニングします。以下のセクションで提供するのは、有用なガイドラインにすぎず、特定のレベルのパフォーマンスを保証するものではありません。
パフォーマンスのボトルネックを見極める
Monitor ユーティリティを使用すると、特定のデータベース エンジンの設定オプションに関連するパフォーマンスのボトルネックを明らかにすることができます。オペレーティング システムの[スタート]メニューまたはアプリ画面から、あるいは PSQL Control Center の[ツール]メニューから Monitor を起動します。
Monitor の表示と設定オプション
Monitor のメニューにある 2 つの選択肢によって、設定オプションに関連するパフォーマンスの値が表示されます。
MicroKernel > リソース使用状況
MicroKernel > 通信
次の表に示すように、データベース エンジンは複数のサーバー設定オプションを動的に管理します。
表 15 Monitor で表示される、動的に管理されている設定
動的に管理される設定
リソース使用状況ウィンドウに表示される値
通信統計情報ウィンドウに表示される値
ファイル数
* 
 
ハンドル数
* 
 
クライアント数
* 
 
ワーカ スレッド数
* 
 
リモート セッション総数
 
* 
表示および動作の解釈
Monitor に表示される情報を活用することができます。Monitor はリソースのタイプごとに 3 つの情報を表示します。たとえば、リモート セッション総数には次のように表示されます。
現在値。実際に動作しているリモート セッションの現在の数。
ピーク値。エンジンが開始されてから実際に使用されたリモート セッションの最大数。
最大値。リモート セッションの使用可能な最大数。
リソースのピーク値と最大値が同じ場合には、そのリソースの最大値を増やすように設定プロパティを設定すれば、データベース エンジンは、必要な場合に特定のリソースの追加のインスタンスを割り当てることができます。
設定プロパティを変更する前に
以下のセクションでは、次のことを前提とします。
1 PSQL Control Center (PCC)が既に開いていること。
このタスクについての説明が必要な場合は、『PSQL User's Guide』の Windows での PCC の起動を参照してください。
2 構成しようとするエンジンが既に登録済みであること(可能な場合)。
このタスクについての説明が必要な場合は、『PSQL User's Guide』のリモート サーバー エンジンを登録するにはを参照してください。
3 所定のエンジンを構成するには、オペレーティング システムの適切な権限が必要です。
このタスクについての説明が必要な場合は、『PSQL User's Guide』のデータベース エンジンの管理者権限の許可を参照してください。
4 一部のエンジン設定については、設定を変更した後にデータベース エンジンの再起動が必要になります。
初期接続時間を最小限にする
最短接続時間の基礎を成す理論は、3 つの必要条件を中心に展開します。これらの必要条件についての要約は次のようになり、詳細についてはその後で説明します。
既知の通信プロトコル。クライアントまたはサーバーが、その環境でサポートされていないプロトコルを介して接続を試行するために余計な時間を費やすことは望ましくありません。クライアント/サーバーが使用できないプロトコルを削除することにより、ネットワーク コンポーネントがそれらの使用を試行することを防げます。
既知のデータベース エンジンのロケーション。クライアントが存在しないエンジンへの接続を試行することは望ましくありません。ワークグループのみのサポート、またはサーバーのみのサポートを適切に指定することにより、クライアントが存在しない接続でタイムアウトになることを防ぐことができます。非共有および共有データベースの両方がある環境では、ゲートウェイの一貫性保守を使用して、データベース エンジンがデータベース エンジンの実行されていないマシンを常に知ることができ、これにより、これらのマシン上のエンジンへの接続を試行せず、別の方法でデータにアクセスします。
実行準備の整ったデータベース エンジン。休止しているエンジンが新しい接続リクエストを受け取ると、リソースの再割り当ておよび実行時の状態に戻るのに時間がかかります。接続スピードがサーバー上のリソース使用量より重要な場合は、サーバー エンジンが使用されていないときにも休止しないようにすることができます。
クライアントのプロパティ
クライアントのプロパティの変更は、そのクライアント マシンで行う必要があります。設定を変更したい各ワークステーションでプロパティを変更する必要があります。
クライアント側の接続待ち時間を最小限にするには
1 PSQL エクスプローラーで、ツリーのローカル クライアント ノードを展開します(ノードの左の展開アイコンをクリックします)。
2 MicroKernel ルーター]を右クリックします。
3 プロパティー]をクリックします。
4 プロパティ ツリーで[通信プロトコル]をクリックします。
5 サポート プロトコル]で、必要なプロトコルにはチェック マークが入って選択されており、使用されないプロトコルのチェック マークは外されているようにします。
6 適用]をクリックします。
これで、クライアントが、使用されていないプロトコルと通信しようとするのを妨ぐことができるようになりました。
7 プロパティ ツリーで[アクセス]をクリックします。
8 リモート サーバーまたはリモート ワークグループ エンジンのみを使用している場合は、[ローカル MicroKernel エンジンの使用]のチェック マークを外すようにします(つまり、オフに設定します)。
ローカル ワークグループ エンジンのみを使用している場合は、[リモート MicroKernel エンジンの使用]のチェック マークを外すようにします(つまり、オフに設定します)。
ワークグループ エンジンを使用することもあり、また、サーバー エンジンまたはリモート ワークグループ エンジンへ接続することもある場合には、両方の設定をオンにして(チェックを入れて)おく必要があります。
このような共有と非共有データの混合環境では、各クライアントで[ゲートウェイ一貫性保守]をオンに設定しておくことができます。この設定によって、データベース エンジンに接続することができないすべてのマシンの名前のリストを強制的にクライアント ソフトウェアに保持させます。クライアント ソフトウェアが、指定されたコンピューターにはエンジンが存在しないことを判定するには、すべてのネットワーク プロトコルのリクエストがタイムアウトになるまで待ちます。
PSQL データベース エンジンを持たないサーバーにデータが格納されていて、[リモート MicroKernel エンジンの使用]の設定がオンの場合、クライアントはそのマシンにエンジンがないことを知るために少なくとも 1 度はタイムアウトを待たなければなりません。ゲートウェイ一貫性保守を使用すると、アプリケーションがそのデータに最初にアクセスしたときのみにこのタイムアウトが起きるようにできます。
メモ: ゲートウェイ一貫性保守を使用すると、ネットワーク トポロジを固定します。後に、リモート コンピューターにサーバーまたはワークグループ エンジンをインストールする場合、各クライアントで[ゲートウェイ一貫性保守]をオフにして、データベース エンジンを持たないコンピューターのリストが削除されるようにする必要があります(これにより新しいデータベース エンジンに接続できるようになります)。[ゲートウェイ一貫性保守]に戻ると、リストは空になっています。
9 OK]をクリックします。
これで、クライアントが、使用されていないデータベース エンジンに接続しようとするのを防ぐことができます。
サーバーのプロパティ
サーバー側の接続待ち時間を最小限にするには
1 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 のパフォーマンスを最大にします。
さらに、アプリケーションがリレーショナル エンジンを使用していて一時ファイルを頻繁に作成する場合、これらのファイルが作成されるディレクトリが速いディスク ドライブであることを望むでしょう。このディレクトリの場所および一時ファイルを作成するクエリのタイプの詳細については、『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 次に、システム異常の場合に、どれだけのロギングが必要で、どれだけのデータベース オペレーションを失ってもかまわないかを考慮します。失ってもかまわない変更が多いほど、パフォーマンスの向上を追求することができます。
アーカイブ ログの使用トランザクション一貫性保守およびトランザクション ログは、すべてログ ファイルを必要とします。デフォルトで、アーカイブ ロギングはオフになっています。定期的なバックアップを実行し、システム異常の時点のデータに回復する能力を必要とする場合にのみこれをオンにします。ログの対象とするファイルを指定するときには、完全にログを必要とするファイルのみを指定するようにしてください。詳細については、第 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]をクリックして開いているダイアログを閉じ、設定を反映させるためにオペレーティング システムを再起動します。
ハイパーバイザー製品でのパフォーマンス
PSQL で最高のパフォーマンスを実現するには、以下の事項を順守してください。
ハイパーバイザー ベンダーからのパフォーマンス最良実施例に従うこと。
PSQL をホストする仮想マシンに十分なメモリ(RAM)が確保されていること。
ハイパーバイザー ホストには十分な数の仮想 CPU があり、同じマシン上の全仮想マシンの中で仮想 CPU の競合を最小化します。これにより、PSQL を実行する仮想マシンとの競合が避けられます。共通(アフィニティ)規則を使用する場合は、必ずすべてのコアを同じソケットで実行するようにしてください。
PSQL データ ファイルは高速な物理ストレージに存在し、物理ストレージ デバイスに対するスピンドルの競合およびコントローラーの競合を最小化します。