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 パフォーマンス ---------------------------------------------------------------------------------------------------------------------------- 1

はじめに

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 パフォーマンス ---------------------------------------------------------------------------------------------------------------------------- 2

データベース管理システム（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 パフォーマンス ---------------------------------------------------------------------------------------------------------------------------- 3

ーバー アプリケーション用のデバイス ドライバとして実装されます。システム要件として、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 パフォーマンス ---------------------------------------------------------------------------------------------------------------------------- 4

す。

要因 詳細 XIO の使用

アプリケーションはランダム デー

タ アクセスを使用する（データ ア

クセスの傾向はシーケンシャルで

はない）

これは、データベース管理システムを使用するアプリ

ケーションの特徴です。

可

データ セットは Windows システ

ム キャッシュに完全に収まらない

ほど大きい

Windows システム キャッシュに収まらないデータ

セットが多ければ多いほど、ディスクの読み取りと書

き込みはより頻繁に行われます。XIO は、このような

ときに読み取りと書き込みをキャッシュすることができ

ます。データが Windows システム キャッシュに完

全に収まっている場合、XIO は読み取りや書き込み

要求を処理しません。

可

アプリケーションは頻繁にディスク

の読み取りおよび書き込みを実行

する

ディスク アクセスによってアプリケーションのパフォ

ーマンスが大幅に制限されます。

可

既にサード パーティ製のディスク

I/O を加速するプログラムを使用

している

ディスク I/O を加速するプログラムを複数使用する

ことはお勧めできません。このようなプログラムは互

いに干渉し、予測不能な結果が生じるためです。

不可

Xtreme I/O の詳細については、Pervasive PSQL Summit v10 の『Advanced Operations Guide』で第 5 章『パフォーマン

ス』を参照してください。

Pervasive PSQL パフォーマンス ---------------------------------------------------------------------------------------------------------------------------- 5

動的キャッシュ

コンピュータ処理では、最近要求されたデータが再度要求される可能性が高いということは、よく知られている原則です。

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 パフォーマンス ---------------------------------------------------------------------------------------------------------------------------- 6

静的キャッシュを使用するシステムと動的キャッシュを使用するシステムの 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 パフォーマンス ---------------------------------------------------------------------------------------------------------------------------- 7

新は、キャッシュ内の圧縮されていないデータに対して行われます。書き込み操作が行われると、データ ページは圧縮さ

れてディスクに書き込まれます。圧縮されたページが、次回アクセスされるまで保持されるかどうかは、キャッシュ管理によ

って異なります。ページ圧縮は、以下の条件の場合に最も効果的です。

・ データは 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 パフォーマンス ---------------------------------------------------------------------------------------------------------------------------- 8

ます。クライアント キャッシュおよびページ サーバーはキャッシュの並行性を管理し、クライアント キャッシュとレコード リ

クエスタ読み込みや、クライアント キャッシュ ヒット率とシステム全体のトラフィックを動的に検出して切り替えます。

アプリケーション側から見れば、頻繁に使用されるデータは常に手元にあり、クライアント キャッシュに保持しています。す

べての更新、挿入、削除、ロックおよびトランザクションはサーバーに渡されるので、クライアント キャッシュが書き込みパフ

ォーマンスに直接影響を与えるわけではありません。クライアント キャッシュ エンジンは、ページ サーバー/クライアント

キャッシュとレコード ベースのクライアント/サーバー モードを動的に切り替えることもできます。これは、クライアント キャッ

シュのパフォーマンス コストが、そのファイルに対する便益を上回り始めた場合に行われます。

クライアント キャッシュが役立つ状況

クライアント キャッシュの主な利点はアプリケーションへのキャッシュ データをローカルに保持している点です。これによっ

て同じデータが再度読み込まれた場合のネットワーク トラフィックやディスク I/O がなくなります。レポート作成などの大量

の読み込みの操作時に最大の利点を発揮します。比較的小さく変化の尐ないデータが繰り返し参照されたり（たとえば、

会計報告の図表）、同じページを何度も読み込む可能性が高い場合、そのデータは既にクライアント キャッシュに存在し、

ネットワーク I/O もディスクI/O も必要とせず、アプリケーションに非常に速く送り返されます。

Pervasive PSQL パフォーマンス ---------------------------------------------------------------------------------------------------------------------------- 9

まとめ

このホワイト ペーパーでは、Pervasive がこれまでの 25 年間にデータベース製品に行ってきた、重要なパフォーマンス

の改善に焦点を当ててきました。これらのいくつかは Pervasive PSQL データベースに固有のものです（特許を受けていま

す）が、その他は Pervasive PSQL がプラットフォーム レベルの技術進歩（64 ビットへの転換）に対してどのように最適化

を行えるかの例です。ここで説明している内容は、決してすべてを網羅したものではありません。SQL の最適化、改善され

たユーティリティ、優れた開発ツールおよびその他の諸々は、すべての開発者やアプリケーションがより快適に実行するた

めに適用される部分です。Pervasive の典型的な中小企業顧客は、伝統的な企業 IT のやり方、つまりハードウェアを投

入することでパフォーマンス課題に対処する傾向にありません。中小企業の限定された予算ではハードウェアを継続的に

導入していくことはできないため、Pervasive はデータベースおよびアプリケーションのパフォーマンスを改善する別の方法

を見つけることに創意工夫をこらすようになりました。そのすべての変更で共通する特徴は、中小企業顧客が使用するハ

ードウェアおよび OS プラットフォームを超越して最良のパフォーマンスを得る方法を Pervasive PSQL が常に進歩させ

発見してきたことです。また、同じ顧客が新しい高パフォーマンス プラットフォームをできる限り簡単に導入できることを確

実にしてきました。

Pervasive PSQL パフォーマンス ------------------------------------------------------------------------------------------------------------------------- 10

付録 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 パフォーマンス -------------------------------------------------------------------------------------------------------------------------- 11

DB サイズ ファイルの拡張係数

1GB 未満 5%

1 GB 以上 5 GB 未満 2%

10 GB 以上 1%

Pervasive PSQL パフォーマンス チューニングの詳細については、『Advanced Operations Guide』の第 5 章 「パフォーマン

ス」をお読みください。

Pervasive PSQL パフォーマンス ------------------------------------------------------------------------------------------------------------------------- 12

付録 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 パフォーマンス ------------------------------------------------------------------------------------------------------------------------- 13

問い合わせ先

株式会社エージーテック

東京都千代田区神田錦町1-21-1

昭栄神田橋ビル3F

TEL：03-3293-5300

FAX：03-3293-5270

カスタマーセンター

TEL：03-3293-5283

info@agtech.co.jp

2009 Pervasive Software Inc. All rights reserved. Pervasive の社名および製品名はすべて、米国およびその他

の国における Pervasive Software Inc. の商標または登録商標です。その他の商標は、各所有者が保有するものです。