Pervasive PSQL パフォーマンス

Pervasive PSQL パフォーマンス
Pervasive PSQL の主要なパフォーマンス機能
Pervasive Software ホワイトペーパー
2009 年 12 月
目次
はじめに ……………………………………………………………………………………………………… 1
パフォーマンスの基本事項－メモリの追加、ディスク I/O およびネットワーク I/O の削減 ……………
1
64 ビットのサポート ………………………………………………………………………………………… 1
データベース管理システム（DBMS） ……………………………………………………………………… 2
より効果的なメモリの使用 ………………………………………………………………………………… 3
より優れた読み取りと書き込み ……………………………………………………………………………
6
ネットワーク I/O の削減 …………………………………………………………………………………
8
まとめ …………………………………………………………………………………………………………
9
付録 A －パフォーマンスの構成 ………………………………………………………………………… 10
付録 B －静的キャッシュと動的キャッシュの比較 ………………………………………………………
12
問い合わせ先/商標情報 …………………………………………………………………………………… 13
はじめに
Pervasive® PSQL は、とりわけ中小規模の業務における要件（非常に尐ないメンテナンス、自動最適化、自動調整、簡単
なインストールと組み込み、柔軟な配置オプション）に適したデータベースとして名声を得ています。それは、今に始まっ
たことではありません。25 年もの間、新しいリリースのたびにパフォーマンスの向上に取り組んできたため、 Pervasive
PSQL で実行するアプリケーションによって、ユーザーはその優れたパフォーマンスを体感することができます。このホワ
イトペーパーでは、Pervasive PSQL へのパフォーマンスに関するいくつかの重要な改善点に焦点を当てています。また、
データベースを最適化するために役立つチューニングの提案事項も挙げています。PSQL パフォーマンスチューニング
の詳細については、Pervasive PSQL Summit™ v10 の『Advanced Operations Guide』の第 5 章「パフォーマンス」をお
読みください。
パフォーマンスの向上に対する Pervasive の理念は、恣意的な一連のベンチマークの結果に集中することではなく、アプ
リケーションのパフォーマンスの全般的な向上にあります。このホワイトペーパーは、Pervasive PSQL のパフォーマンスに
関する改善点について説明することを目的としています。また、開発者、独立系ソフトウェアベンダおよびエンドユーザ
ーが、その改善点を理解し、パフォーマンスのテストや実際の現場でのアプリケーション配置において、どのような利点が
あるかを予測するガイドとしての役割も果たします。
パフォーマンスの基本事項－メモリの追加、ディスク I/O およびネットワー
ク I/O の削減
データベースに関する要素の中で、アプリケーションのパフォーマンスに影響する可能性があるものが主に 3 つあります。こ
れらの要素とは、ディスク I/O の待ち時間、ネットワーク I/O およびプロセッサとメモリの使用です。RAM のアクセスはディスク
アクセスよりも 100,000 倍以上も速いので、メモリを追加し、そのメモリをより効率的に使用すれば、アプリケーションのパフォー
マンスは一般的に向上します。Pervasive PSQL にはこの両方をいずれも可能にする改善策がいくつかあります。
64 ビットのサポート－メモリの追加
アプリケーションのディスク I/O を減らす極めて簡単な方法は、使用可能な RAM のサイズを極限まで増やすことです。
当然のことながら、ディスクからデータを取り出すよりも、メモリにデータを保持する方がアプリケーションのパフォーマンスが
向上します。何と言っても、ディスクアクセスは処理に不可欠の（電子的とは対照的に）機械的な機能の 1 つであるため、
可動部分によるアクセス速度の遅さに悩まされます。ソフトウェア側では、ディスクアクセスにはパフォーマンスの点から見
てコストのかかる "システムの呼び出し" も伴います。
ディスクと RAM アクセスの対比
Pervasive PSQL パフォーマンス ----------------------------------------------------------------------------------------------------------------------------1
データベース管理システム（DBMS）－キャッシュとファイルシステムキャッシュの方法
理論上、32 ビット Intel および AMD マシンは最大 4GB の RAM へアクセスできます。Windows ベースのマシンで
は、その 4GB をオペレーティングシステムとアプリケーションで分配しています。つまり、これはアプリケーションがアクセ
スできる最大メモリが 2GB であることを意味します。このため、32 ビット Windows マシンに 4GB の RAM がある場合、
メモリを追加してもパフォーマンスには何も効果がありません。Windows 2000 Server や Windows Server 2003 で使用す
る API である Microsoft の Address Windowing Extension（AWE）を使用すると、32 ビットアプリケーションでアクセス
するアドレス可能なメモリを増やすことができます。ただし、AWE の利用はアプリケーションに組み込む必要があります。ま
た、この方法は Windows やドライバが使用できるメモリ量を減らすことになるのでオペレーティングシステムのほかの部
分に影響します。
Pervasive PSQL Summit v10 は Windows Vista™ および 64 ビットアーキテクチャもサポートします。大きなデータセ
ットを扱うアプリケーションは、64 ビットサーバーやオペレーティングシステムの恩恵を受けることができます。なぜなら
多くの場合、データベース全体を RAM にロードできるようになるからです。64 ビット Windows Vista では 8GB から
128GB（エディションによって異なる）をサポートするので、アプリケーションはより多くのデータを仮想メモリへ実質的に事
前ロードできます。これにより、高速アクセスが可能になり、アプリケーションのパフォーマンスが大きく改善されます。次の
表では、32 ビットおよび 64 ビットの Windows アプリケーションで使用可能なアドレス空間についてまとめています。
64 ビットアーキテクチャと 32 ビットアーキテクチャ
アドレス空間
64 ビットWindows
32 ビットWindows
仮想メモリ
16 テラバイト
4 ギガバイト
ページファイル
512 テラバイト
16 テラバイト
システムキャッシュ
1 テラバイト
1 ギガバイト
64 ビットプラットフォームへの移行による恩恵を受けようとする開発者にとって、Pervasive PSQL Summit v10 は正しい選
択と言えます。64 ビットプラットフォームオペレーティングシステムを購入されたアプリケーションユーザーは、追加さ
れた処理およびメモリ機能を 32 ビットアプリケーションでも利用することができます。Pervasive PSQL は最良のパフォー
マンスが得られるよう以下の 3 種類の構成をサポートします。
良い 64 ビットプラットフォーム上で実行している 32 ビット PSQL データベースとデータをやり取りする 32 ビットアプリケー
ション。オペレーティングシステムが内部構成やネイティブのプロセッサ能力を利用できます。
より良い 64 ビットプラットフォーム上で実行している 64 ビット PSQL データベースにアクセスする 32 ビットアプリケーション。
そのアプリケーション用にデータベースメモリを拡張します。
最良 64 ビットオペレーティングシステム上で実行している 64 ビット PSQL データベースにアクセスする 64 ビットアプリ
ケーション。これは最適なパフォーマンスが得られるよう、すべてのコンポーネントがネイティブな構成で実行することがで
きます。
より効果的なメモリの使用 – XIO と動的キャッシュ
Xtreme I/O
Xtreme I/O（XIO）は Pervasive PSQL Summit v10 の機能で、Pervasive PSQL データファイルのディスクアクセス速度を
上げることによってパフォーマンスを向上させます。XIO は、32 ビット Windows プラットフォームで Pervasive PSQL サ
Pervasive PSQL パフォーマンス ----------------------------------------------------------------------------------------------------------------------------2
ーバーアプリケーション用のデバイスドライバとして実装されます。システム要件として、Pervasive PSQL をインストール
する前に最低 4GB の RAM が搭載されていることを確認してください。詳細については、『 Advanced Operations
Guide』を参照してください。
XIO とデータベースエンジンは共同してパフォーマンスを高めます。データファイルが開かれると、エンジンは XIO に
通知します。その時点から、XIO はそのデータファイルへのディスクアクセスを加速させます。例として、多数のレコード
をテーブルに挿入する Pervasive PSQL アプリケーションを考えてみましょう。多数のレコード挿入は、データベースファ
イルのさまざまな領域へのランダム I/O 要求を招きます。XIO はこの挿入を体系化および合理化することによって、書き
込みや記憶域に対する I/O 要求の総数を減らします。これによって、記憶域コントローラおよび PCI バスにかかる負荷
が減り、さらにプロセッサの負荷の減尐のため、ほかのトラフィック用の帯域幅が大きくなります。
XIO は、完全に管理できるデータベースキャッシュを確保する（または割り当てる）ために使用可能な RAM で直接作
業することができます。XIO は書き込み操作を合理化し、またインテリジェント圧縮アルゴリズムを用いることでメモリに格納
できるデータ量を増やします。XIO は透過的に動作し、ユーザーやアプリケーションの介入は必要ありません。
XIO キャッシュ
ほとんどのキャッシュサブシステムはシステムにあるすべてのアプリケーションをサポートし、キャッシュの動作を全体的に
最適化しようとします。XIO のキャッシュは、Pervasive PSQL データベース経由でアクセスされるアプリケーションファイ
ルを格納することのみを目的に設計されています。また、データベースは Windows で利用できるどのような物理メモリへ
もエンジンのキャッシュを拡張することができます。つまり、ほとんどの 32 ビットアプリケーションで実質的な限界サイズ
である 2GB を超えるということです。XIO は、物理アドレス拡張（PAE）が使用可能であればそれを使って 4GB を超え
る拡張メモリを使用します。XIO はシステムがシャットダウンするまで拡張メモリを保持します。キャッシュサイズは変化せ
ず、縮小または拡張することはありません。拡張メモリが存在しない場合、XIO は標準メモリ（最大 4GB の RAM）からキ
ャッシュを取得します。
たとえば、Windows 2000 Advanced Server で物理アドレス拡張（PAE）機能を使用すれば、最高 8 GB まで物理メモリを
利用できます。XIO があれば、データベースエンジンのキャッシュは、Windows 2000 が利用できるすべての物理メモリ
によって拡張されます。XIO がない場合、データベースキャッシュのサイズは 1.5GB（つまり、32 ビット Windows の
2GB の制限から実行ファイルの使用量を除いた残り）を超えることはありません。
標準メモリでは、XIO はデータベースエンジンのメモリ要求と、オペレーティングシステム全体用のメモリ要求やその他
の非データベースアプリケーション用のメモリ要求とのバランスをとります。XIO のキャッシュは、ほかのシステムリソース
がメモリを確保および解放するに応じて、動的に縮小および拡張することができます。多数のユーザーから同時にアクセ
スされ、複数のアプリケーションを実行するデータベースサーバーに高いパフォーマンスを提供します。
XIO 圧縮
XIO には、異なるデータ型それぞれに適した多数の圧縮アルゴリズムが含まれています。XIO は受信データすべてに対
して単一の圧縮を適用するのではなく、前方参照アルゴリズムをデータに適用して適切な圧縮アルゴリズムを選択します。
XIO はキャッシュ処理の一部としてデータを圧縮することによって、キャッシュリソースをより有効に利用します。たとえば、
2：1 の圧縮率を使用すれば、XIO がキャッシュに格納できるデータ量は 2 倍になります。
XIO の合理化された書き込み
XIO は、データをディスクに書き込むときに、書き込みの集約と書き込みの順序付けという 2 つの技術を使用して効率を
高めています。XIO は、いくつもの書き込み要求を 1 つの大きな要求にまとめることによって、ディスクコントローラや
PCI バスにおける負荷を低減します。XIO は、書き込み要求を順序付けすることによって、書き込みを達成するためにハ
ードドライブのヘッドが行う必要があるシーク数を低減します。書き込み回数を減らし、書き込みが発生する順序を整理す
れば、書き込み時間が大いに改善されます。
XIO の使用に適した状況
次に表では、XIO の使用した場合にパフォーマンスが向上する可能性があるアプリケーションの特性について確認しま
Pervasive PSQL パフォーマンス ----------------------------------------------------------------------------------------------------------------------------3
す。
要因
詳細
XIO の使用
アプリケーションはランダムデー
タアクセスを使用する（データア
クセスの傾向はシーケンシャルで
はない）
これは、データベース管理システムを使用するアプリ
ケーションの特徴です。
可
データセットは Windows システ
ムキャッシュに完全に収まらない
ほど大きい
Windows システムキャッシュに収まらないデータ
セットが多ければ多いほど、ディスクの読み取りと書
き込みはより頻繁に行われます。XIO は、このような
ときに読み取りと書き込みをキャッシュすることができ
ます。データが Windows システムキャッシュに完
全に収まっている場合、XIO は読み取りや書き込み
要求を処理しません。
可
アプリケーションは頻繁にディスク
の読み取りおよび書き込みを実行
する
ディスクアクセスによってアプリケーションのパフォ
ーマンスが大幅に制限されます。
可
既にサードパーティ製のディスク
I/O を加速するプログラムを使用
している
ディスク I/O を加速するプログラムを複数使用する
ことはお勧めできません。このようなプログラムは互
いに干渉し、予測不能な結果が生じるためです。
不可
Xtreme I/O の詳細については、Pervasive PSQL Summit v10 の『Advanced Operations Guide』で第 5 章『パフォーマン
ス』を参照してください。
Pervasive PSQL パフォーマンス ----------------------------------------------------------------------------------------------------------------------------4
動的キャッシュ
コンピュータ処理では、最近要求されたデータが再度要求される可能性が高いということは、よく知られている原則です。
Pervasive PSQL および Btrieve には、ディスクにも格納されているデータのページを保持する統合キャッシュ機能が常
に含まれています。Pervasive.SQL V8 では第 2 レベルのキャッシュが導入されました。これはメモリ状態を交換して未使
用メモリを有効利用するように設計された動的キャッシュです。
静的に割り当てられたキャッシュ（構成設定中に定義された連続的なメモリブロック）は、メモリ使用が厳密に監視および
予測されている専用サーバーでは無難に使用できますが、多くの状況で制限が設けられています。その理由は、a）システ
ムの未使用メモリを利用するように拡大できないこと、および、b）メモリの断片化またはオペレーティングシステムによって
連続ブロックが制限されていることです。複数のアプリケーションが動作するワークステーションやサーバーなど、メモリの利
用できる度合いが頻繁に変わるシステムでは、ユーザーがほかのプロセスを開始および終了するのに伴うメモリ要求の変
化に動的に適応することが重要です。
マシン上でメモリを集中的に使用するプロセスがほとんど実行されていない場合は、一般的にデータのキャッシュに利用可
能な未使用メモリが大量にあり、データベースパフォーマンスが全面的に向上します。PSQL Server の初期のバージョン
では、デフォルトで物理メモリの 20% を使用する設定になっていました。専用のデータベースサーバーでは、デフォルト
で相当な量の RAM が未使用となっていました。キャッシュの固定的な量を設定するのに加え、Pervasive PSQL ではオ
ペレーティングシステムのキャッシュも使用します（ディスクではなく OS キャッシュから読み書きをします）。Pervasive
PSQL キャッシュとオペレーティングシステムキャッシュの間では情報が共有されず、両方のキャッシュが LRU アルゴリ
ズム（キャッシュからページを削除するとき、最近使用されていないメモリが最初に削除される）を使用して保持するものと上
書きするものを決定するため、キャッシュされたデータの多くが重複していました。言い換えると、Pervasive PSQL のキャッ
シュが利用可能メモリの 20% を使用している場合、システムキャッシュは最大 80% になります。しかし、最大で 1/4（全
体の 20%）は Pervasive PSQL キャッシュに既にある重複キャッシュページとなります。
動的キャッシュ－メモリの有効利用とわかりやすい最適化
Pervasive PSQL が動的キャッシュを実装する別の理由は、エンドユーザーがキャッシュ設定を最適化する必要性をなく
すことです。静的設定では、特定の環境でシステムリソースを最大限効率的に使用するためにユーザーがチューニング
を行い、環境が変わるたびに再度チューニングを行う必要があります。
決定的なことに、静的データベースキャッシュはオペレーティングシステムから単一の連続メモリブロックを必要としまし
た。動的キャッシュは連続ブロックを必要としないので、システムの使用可能メモリを非常に有効に利用することができま
す。
動的キャッシュの設計
Pervasive PSQL は L1 と L2 という 2 階層のキャッシュを使用します。L1 は、このデータベースの以前のバージョンで
使用されていた静的キャッシュに類似していますが、L2 は完全に動的な新しいキャッシュです。ページは、必要に応じて
L1 と L2 の間を移動します。L1 にはアクセス中または変更中のすべてのページが含まれ、L2 には現在は使用中では
ないが最近アクセスされたページが含まれます。アクティブなキャッシュ L1 と非アクティブなキャッシュ L2 の分離は、
バックグラウンドで動的キャッシュ管理が行われ、特定のカーネルの動作から独立していることを意味します。
動的キャッシュを使用すると、データベースはシステムキャッシュからの割り当てを必要としません。これにより、読み取りア
クセスのパフォーマンスは次のように向上します。まず第一に、使用されるメモリ量が Pervasive PSQL のデータ要求に基
づいて制御されます。第二に、システム呼び出しが行われず、L2 キャッシュはその内容に関与するのが、ただ 1 つのプ
ロセスであるという前提で機能することができます。システムキャッシュは、リソースを複数のプロセスが同時に使用すること
を前提にする必要があります。
動的キャッシュのパフォーマンス上の利点
動的キャッシュのパフォーマンス上の利点は、サーバーの使用可能メモリ、データベースサイズ、使用パターンなどの要
因によってさまざまです。しかし、これらの情報によって、関連するメモリ使用に基づいたパフォーマンス改善の測定基準
を考案することができます。
Pervasive PSQL パフォーマンス ----------------------------------------------------------------------------------------------------------------------------5
静的キャッシュを使用するシステムと動的キャッシュを使用するシステムの 2 つのシステムの例から始めましょう。（動的キ
ャッシュの例にあるように）静的キャッシュと L1 キャッシュの使用可能メモリが共に 20% と設定されているとします。（同
じタイプの LRU アルゴリズムのために）システムキャッシュが、静的キャッシュおよび L1 キャッシュとほとんど重複すること
になります。
静的キャッシュ：4GB のメモリを持つサーバーでは、データベースが使用するメモリ量は 20%、つまり 800 MB になりま
す（システムキャッシュが別の 800MB をデータベースのために使用中であったとしても、システムと静的キャッシュが同
じデータを格納しているため、実際にはパフォーマンスの助けにはなりません）。
動的キャッシュ：4GB のメモリを持つサーバーで、20% の L1 キャッシュは 800MB を使用し、残りの 3.2GB が使用可
能です。L2 キャッシュサイズの上限は、別の構成設定である "最大メモリ使用量" によって決定されます。"最大メモリ使
用量" は L1 + L2 キャッシュが使用する利用可能メモリをパーセンテージで定義します。この例で最大メモリを 50% ま
たは 2GB に設定したとすると、L2 が使用できるメモリ量は 2GB（最大メモリ）－ 800MB（L1）、つまり 1.2GB です。
このシンプルな例では、データベースのキャッシュに使用できるメモリを 800MB から 2GB に、つまり、2.5 倍に増やしま
した。動的キャッシュのパフォーマンス上の効果を詳しく計算するには、「付録 B」を参照してください。
場合によっては、データベースサーバーを注意深くチューニングすることにより、システムキャッシュを除去して L1 を最
大化し、同様の結果を実現できる可能性もあります。ただし、これには、システムが総じて原則的に静的で、データベース
サーバー専用であり、メモリ断片化がないという条件が必要です。このような状況はほとんどありません。専用サーバーや、
継続的なデータベースチューニングを提供するデータベース管理者（DBA）を持たないユーザーは、Pervasive PSQL が
キャッシュの自動チューニングを実行してサーバーおよびワークステーションデプロイメントでメモリ稼働率を改善できるこ
とを高く評価されるでしょう。中小企業のユーザーにとっては、最適な構成設定およびアプリケーションパフォーマンスを
達成する際に、これは大きな利点となります。
より優れた読み取りと書き込み－レコード圧縮およびページ圧縮、 Turbo Write
Accelerator
圧縮
Pervasive PSQL ではレコードおよびページによる 2 種類のデータ圧縮を提供します。これらのデータ圧縮は、別々に使
われることもあれば、一緒に使われることもあります。圧縮を行うと、データファイルのサイズを縮小してキャッシュ内の読み
書きを速くすることにより、パフォーマンスを改善します。
レコード圧縮
Pervasive PSQL v10 には 5 文字以上の連続した文字を 3 バイトに圧縮する機能が含まれています。その結果、データ
内のレコードのタイプによってはストレージで必要とする空間を大幅に減らすことができます。レコード圧縮は、以下の状況
で最良の結果が得られます。
・圧縮するレコードは、データ圧縮を使用することの利点が最大になるように構造化されている。
・ディスク利用度を高める必要性が、処理量の増大や圧縮されたファイルに必要なディスクアクセス時間よりも重要である。
・データベースを実行するコンピュータには（読み取り中にレコードを展開する）圧縮バッファとして十分なメモリがある。
レコード圧縮は、各レコードが文字の繰り返しを多数含む可能性がある場合に最も効果的です。たとえば、レコードにいく
つかのフィールドが含まれていて、ファイルに挿入するときに、それらのフィールドをすべて空白に初期化する場合です。
圧縮は、これらのフィールドがほかの値を含むフィールドによって分離される場合でなく、レコード内で 1 つにグループ化
される場合に有効です。
ページ圧縮
内部的には、Pervasive PSQL データファイルはさまざまな種類のページの連続です。ページ圧縮は、ファイル内のデー
タページの圧縮と復元を制御します。
ファイルがディスクから読み取られると、データページは復元されてキャッシュに保持されます。レコードの読み取りと更
Pervasive PSQL パフォーマンス ----------------------------------------------------------------------------------------------------------------------------6
新は、キャッシュ内の圧縮されていないデータに対して行われます。書き込み操作が行われると、データページは圧縮さ
れてディスクに書き込まれます。圧縮されたページが、次回アクセスされるまで保持されるかどうかは、キャッシュ管理によ
って異なります。ページ圧縮は、以下の条件の場合に最も効果的です。
・データは ZIP 形式の圧縮アルゴリズムを使用して圧縮できる可能性が極めて高い。ファイルサイズが 1/4 以上減
尐したとき、ファイルのパフォーマンスは著しく向上します。
・アプリケーションでは、（挿入、更新、削除に比べて）読み取りが高いパーセンテージを占める。
レコード圧縮とページ圧縮の使用に関する情報については、『Programmer's Guide』の第 5 章「データベースの設計」お
よび『Advanced Operations Guide』の第 13 章「Maintenance を使用した Btrieve データファイルの操作」を参照してく
ださい。
Turbo Write Accelerator
ディスクへの書き込みの特性の１つは、いったん開始したら、停止してヘッドを新しい物理トラックに移動して再度書き込
みを開始するより、書き込み続ける方が消費時間がより尐ないということです。言い換えると、連続的な書き込みは不連続
な書き込みより極めて速いということです。さらに、書き込みの呼び出しには OS との相互作用も必要です。複数の書き込
みを減らして単一の大きな書き込みを行うようにすれば、書き込みの実行時間は著しく減尐します。 Turbo Write
Accelerator（TWA）は物理ファイル内に開いたスロットをあらかじめ割り当て、複数のページが 1 つの一体化したページと
して書き込まれるようにします。このことが、頻繁に更新されるファイルで断片化を減尐させて I/O パフォーマンス（その結
果アクセス時間）を改善します。
Turbo Write Accelerator のパフォーマンスにおける便益は、書き込みが発生する量、データのページサイズ、およびシス
テムトランザクションの設定によって異なります。小さなページを持つファイルでは、一般的に大きなページサイズのファ
イルより高い便益が得られます。これは、大きなページが既により一体化したものになっているからです。
Turbo Write Accelerator を使用するディスク書き込みのパフォーマンスは、ファイル内の空きページ数が増加するにつれ
て向上すると見込まれています。これは、複数の連続したファイルページをディスク上に書き込むことができるからです。
空きページ数のパーセンテージを調整する設定を「ファイルの拡張係数」と呼びます。ファイルの拡張係数設定の詳細に
ついては、『Advanced Operations Guide』の第 4 章「設定リファレンス」を参照してください。
ネットワーク I/O の削減 – クライアントキャッシュ
クライアントキャッシュ
Pervasive PSQL は、ネットワーク I/O を削減するために（クライアント/サーバー構成の）クライアントにあるデータをキャッ
シュします。Pervasive PSQL サーバーにはレコードごとのクライアントリクエストに応えることに加え、ページサーバーの
概念も持っています。これはディスク I/O 呼び出しをローカルエンジンからリモートサーバーへ移動します。Pervasive
PSQL クライアントは、ローカルキャッシュページを操作できるエンジンを保持します。ただし、ロックを使用した読み込み、
書き込み、およびユーザートランザクション内の操作は、ページベースではなくレコードベースとしてサーバーに渡され
Pervasive PSQL パフォーマンス ----------------------------------------------------------------------------------------------------------------------------7
ます。クライアントキャッシュおよびページサーバーはキャッシュの並行性を管理し、クライアントキャッシュとレコードリ
クエスタ読み込みや、クライアントキャッシュヒット率とシステム全体のトラフィックを動的に検出して切り替えます。
アプリケーション側から見れば、頻繁に使用されるデータは常に手元にあり、クライアントキャッシュに保持しています。す
べての更新、挿入、削除、ロックおよびトランザクションはサーバーに渡されるので、クライアントキャッシュが書き込みパフ
ォーマンスに直接影響を与えるわけではありません。クライアントキャッシュエンジンは、ページサーバー/クライアント
キャッシュとレコードベースのクライアント/サーバーモードを動的に切り替えることもできます。これは、クライアントキャッ
シュのパフォーマンスコストが、そのファイルに対する便益を上回り始めた場合に行われます。
クライアントキャッシュが役立つ状況
クライアントキャッシュの主な利点はアプリケーションへのキャッシュデータをローカルに保持している点です。これによっ
て同じデータが再度読み込まれた場合のネットワークトラフィックやディスク I/O がなくなります。レポート作成などの大量
の読み込みの操作時に最大の利点を発揮します。比較的小さく変化の尐ないデータが繰り返し参照されたり（たとえば、
会計報告の図表）、同じページを何度も読み込む可能性が高い場合、そのデータは既にクライアントキャッシュに存在し、
ネットワーク I/O もディスクI/O も必要とせず、アプリケーションに非常に速く送り返されます。
Pervasive PSQL パフォーマンス ----------------------------------------------------------------------------------------------------------------------------8
まとめ
このホワイトペーパーでは、Pervasive がこれまでの 25 年間にデータベース製品に行ってきた、重要なパフォーマンス
の改善に焦点を当ててきました。これらのいくつかは Pervasive PSQL データベースに固有のものです（特許を受けていま
す）が、その他は Pervasive PSQL がプラットフォームレベルの技術進歩（64 ビットへの転換）に対してどのように最適化
を行えるかの例です。ここで説明している内容は、決してすべてを網羅したものではありません。SQL の最適化、改善され
たユーティリティ、優れた開発ツールおよびその他の諸々は、すべての開発者やアプリケーションがより快適に実行するた
めに適用される部分です。Pervasive の典型的な中小企業顧客は、伝統的な企業 IT のやり方、つまりハードウェアを投
入することでパフォーマンス課題に対処する傾向にありません。中小企業の限定された予算ではハードウェアを継続的に
導入していくことはできないため、Pervasive はデータベースおよびアプリケーションのパフォーマンスを改善する別の方法
を見つけることに創意工夫をこらすようになりました。そのすべての変更で共通する特徴は、中小企業顧客が使用するハ
ードウェアおよび OS プラットフォームを超越して最良のパフォーマンスを得る方法を Pervasive PSQL が常に進歩させ
発見してきたことです。また、同じ顧客が新しい高パフォーマンスプラットフォームをできる限り簡単に導入できることを確
実にしてきました。
Pervasive PSQL パフォーマンス ----------------------------------------------------------------------------------------------------------------------------9
付録 A －パフォーマンスの構成
使用可能な RAM に基づいた一般的な構成のガイドラインを次の表に示します。
設定
デフォルト
32 ビット OS
< 4GB RAM
32 ビット OS
>= 4GB RAM
64 ビット OS
2 - 4GB RAM
64 ビット OS
> 4GB RAM
キャッシュ割り当て
非専用サーバー
RAM の
20%
20%
20%
20%
20%
キャッシュ割り当て
専用データベースサーバー
RAM の
20%
最大約 500
MB までの
40%
約 500 MB
40%
データセット
サイズ1
XIO2
オフ
適用外
オン
適用外
適用外
MicroKernel の最大メモリ
使用量
RAM の
60%
60%
0%3
0%
0%1
I/O スレッド4
32
32
32
64
64
起動時のリソース割当
オフ
オン
オン
オン
オン
最小の状態に戻す
オフ
オフ
オフ
オフ
オフ
インデックスバランス
オフ
オフ
オフ
オフ
オフ
セグメントサイズを 2GB に
制限
オン
オフ
オフ
オフ
オフ
ログバッファサイズ
1MB
1MB
1MB
1MB
1MB
トランザクションログサイズ
2MB
2MB
2MB
2MB
2MB
トレース
オフ
オフ
オフ
オフ
オフ
システムキャッシュ
オフ
オフ
オフ5
オフ
オフ
1) 64 ビットシステムでは使用中の全部のデータセットをキャッシュするのに十分な RAM を持つことができます。OS のために十分な
RAM を残すようにしてください。16GB 以上のキャッシュ割り当てには v10 Service Pack 1 以上が必要です。もし使用中の全部の
データセットのために十分な RAM がない場合は、キャッシュ割り当てを RAM の 20%、そして MicroKernel の最大メモリ使用量
を 60% に設定することをお勧めします。
2） XIO を使用するには、最低 4GB の RAM がインストールされている必要があります。XIO のデフォルトはオフです。32 ビットシ
ステム専用です。
3） XIO を使用すると、L2 キャッシュは自動的にオフになります。
4） Windows OS はスレッドごとに 1 MB のメモリを割り当てます。最良の結果を生むためには、8 個のファイルを開くごとに 1 つのス
レッドを使用します。
5） XIO がインストールされていない場合や無効の場合は、システムキャッシュをオンにしてください。
パフォーマンスチューニングをチェックするもう 1 つの設定は、合計データベースサイズに基づくファイルの拡張係数で
す。次の表はファイルの拡張係数を設定するためのよい出発点です。
Pervasive PSQL パフォーマンス ------------------------------------------------------------------------------------------------------------------------- 10
DB サイズ
ファイルの拡張係数
1GB 未満
5%
1 GB 以上 5 GB 未満
2%
10 GB 以上
1%
Pervasive PSQL パフォーマンスチューニングの詳細については、『Advanced Operations Guide』の第 5 章「パフォーマン
ス」をお読みください。
Pervasive PSQL パフォーマンス --------------------------------------------------------------------------------------------------------------------------11
付録 B －静的キャッシュと動的キャッシュの比較
一連のパフォーマンスの時間計測に基づいて、L1 キャッシュから 1 ページを読み取る平均消費時間は約 110 マイクロ
秒と判断されました。これとは別に L2 でのキャッシュ管理タスクは平均 210 マイクロ秒かかり、ページごとの合計は 320
マイクロ秒となります。同じページをディスクから読み取る消費時間は 1900 マイクロ秒で、つまり、キャッシュからページを
読み取るよりおよそ 18 倍長くかかります。これらの時間計測は、もちろん特定のハードウェア構成とオペレーティングシ
ステム固有のもので一般化することはできませんが、Pervasive PSQL の以前のバージョンの動的キャッシュと静的キャッシ
ュの違いを明らかにするのに役立つでしょう。
静的キャッシュを使用し、読み取りの 20% が Pervasive PSQL キャッシュ（L1）にヒットし、理論上 20% がシステムキャ
ッシュにヒットし、60% がディスク I/O を必要とすると仮定します。L1 およびシステムキャッシュに重複するデータが含
まれておらず、システムキャッシュへのアクセスに何の不利益もない理想的なケースでは、1000 件の読み取りは、キャッ
シュアクセス時間（400 × 110 マイクロ秒） = 0.044 秒と、ディスクアクセス時間（600 × 1900 マイクロ秒） = 1.14 秒の
合計、つまり、1.1840 秒を要します。実際には、L1 およびシステムキャッシュの大部分は重複している可能性が高く、キ
ャッシュ内のデータは 20% に留まり、アクセス時間は（200 × 110 マイクロ秒）+（800 × 1900 マイクロ秒） = 1.542 秒とな
ります。
動的キャッシュを使用すると、読み取りが L1 にヒットする可能性が 20%、L2 にヒットする可能性が 50%、ディスク I/O
を必要とする可能性が 30% になります。したがって、1000 件の読み取りに必要な時間は（200 × 110 マイクロ秒）+（500
× 320 マイクロ秒）+（300 × 1900 マイクロ秒）= 0.022 秒 + 0.16 秒 + 0.57 秒 = 0.7522 秒で、静的キャッシュの 1.5
倍から 2 倍のパフォーマンスとなります。
Pervasive PSQL パフォーマンス ------------------------------------------------------------------------------------------------------------------------- 12
問い合わせ先
株式会社エージーテック
東京都千代田区神田錦町1-21-1
昭栄神田橋ビル3F
TEL：03-3293-5300
FAX：03-3293-5270
カスタマーセンター
TEL：03-3293-5283
[email protected]
2009 Pervasive Software Inc. All rights reserved. Pervasive の社名および製品名はすべて、米国およびその他
の国における Pervasive Software Inc. の商標または登録商標です。その他の商標は、各所有者が保有するものです。
Pervasive PSQL パフォーマンス ------------------------------------------------------------------------------------------------------------------------- 13

Download Report