Pervasive PSQL パフォーマンス

Transcription

1 Pervasive PSQL パフォーマンス Pervasive PSQL の主要なパフォーマンス機能 Pervasive Software ホワイトペーパー 2009 年 12 月

2 目次 はじめに 1 パフォーマンスの基本事項 -メモリの追加 ディスク I/O およびネットワーク I/O の削減 1 64 ビットのサポート 1 データベース管理システム (DBMS) 2 より効果的なメモリの使用 3 より優れた読み取りと書き込み 6 ネットワーク I/O の削減 8 まとめ 9 付録 A - パフォーマンスの構成 10 付録 B - 静的キャッシュと動的キャッシュの比較 12 問い合わせ先 / 商標情報 13

3 はじめに 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 パフォーマンス

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

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

6 す 要因詳細 XIO の使用 アプリケーションはランダムデータアクセスを使用する ( データアクセスの傾向はシーケンシャルではない ) データセットは Windows システムキャッシュに完全に収まらないほど大きい アプリケーションは頻繁にディスクの読み取りおよび書き込みを実行する 既にサードパーティ製のディスク I/O を加速するプログラムを使用している これは データベース管理システムを使用するアプリケーションの特徴です Windows システムキャッシュに収まらないデータセットが多ければ多いほど ディスクの読み取りと書き込みはより頻繁に行われます XIO は このようなときに読み取りと書き込みをキャッシュすることができます データが Windows システムキャッシュに完全に収まっている場合 XIO は読み取りや書き込み要求を処理しません ディスクアクセスによってアプリケーションのパフォーマンスが大幅に制限されます ディスク I/O を加速するプログラムを複数使用することはお勧めできません このようなプログラムは互いに干渉し 予測不能な結果が生じるためです 可可可不可 Xtreme I/O の詳細については Pervasive PSQL Summit v10 の Advanced Operations Guide で第 5 章 パフォーマンス を参照してください Pervasive PSQL パフォーマンス

7 動的キャッシュ コンピュータ処理では 最近要求されたデータが再度要求される可能性が高いということは よく知られている原則です 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 パフォーマンス

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

9 新は キャッシュ内の圧縮されていないデータに対して行われます 書き込み操作が行われると データページは圧縮されてディスクに書き込まれます 圧縮されたページが 次回アクセスされるまで保持されるかどうかは キャッシュ管理によって異なります ページ圧縮は 以下の条件の場合に最も効果的です データは ZIP 形式の圧縮アルゴリズムを使用して圧縮できる可能性が極めて高い ファイルサイズが 1/4 以上減尐したとき ファイルのパフォーマンスは著しく向上します アプリケーションでは ( 挿入 更新 削除に比べて ) 読み取りが高いパーセンテージを占める レコード圧縮とページ圧縮の使用に関する情報については Programmer's Guide の第 5 章 データベースの設計 および Advanced Operations Guide の第 13 章 Maintenance を使用した Btrieve データファイルの操作 を参照してください Turbo Write Accelerator ディスクへの書き込みの特性の 1 つは いったん開始したら 停止してヘッドを新しい物理トラックに移動して再度書き込 みを開始するより 書き込み続ける方が消費時間がより尐ないということです 言い換えると 連続的な書き込みは不連続な書き込みより極めて速いということです さらに 書き込みの呼び出しには 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 パフォーマンス

10 ます クライアントキャッシュおよびページサーバーはキャッシュの並行性を管理し クライアントキャッシュとレコードリクエスタ読み込みや クライアントキャッシュヒット率とシステム全体のトラフィックを動的に検出して切り替えます アプリケーション側から見れば 頻繁に使用されるデータは常に手元にあり クライアントキャッシュに保持しています すべての更新 挿入 削除 ロックおよびトランザクションはサーバーに渡されるので クライアントキャッシュが書き込みパフォーマンスに直接影響を与えるわけではありません クライアントキャッシュエンジンは ページサーバー / クライアントキャッシュとレコードベースのクライアント / サーバーモードを動的に切り替えることもできます これは クライアントキャッシュのパフォーマンスコストが そのファイルに対する便益を上回り始めた場合に行われます クライアントキャッシュが役立つ状況 クライアントキャッシュの主な利点はアプリケーションへのキャッシュデータをローカルに保持している点です これによって同じデータが再度読み込まれた場合のネットワークトラフィックやディスク I/O がなくなります レポート作成などの大量の読み込みの操作時に最大の利点を発揮します 比較的小さく変化の尐ないデータが繰り返し参照されたり ( たとえば 会計報告の図表 ) 同じページを何度も読み込む可能性が高い場合 そのデータは既にクライアントキャッシュに存在し ネットワーク I/O もディスク I/O も必要とせず アプリケーションに非常に速く送り返されます Pervasive PSQL パフォーマンス

11 まとめ このホワイトペーパーでは Pervasive がこれまでの 25 年間にデータベース製品に行ってきた 重要なパフォーマンスの改善に焦点を当ててきました これらのいくつかは Pervasive PSQL データベースに固有のものです ( 特許を受けています ) が その他は Pervasive PSQL がプラットフォームレベルの技術進歩 (64 ビットへの転換 ) に対してどのように最適化を行えるかの例です ここで説明している内容は 決してすべてを網羅したものではありません SQL の最適化 改善されたユーティリティ 優れた開発ツールおよびその他の諸々は すべての開発者やアプリケーションがより快適に実行するために適用される部分です Pervasive の典型的な中小企業顧客は 伝統的な企業 IT のやり方 つまりハードウェアを投入することでパフォーマンス課題に対処する傾向にありません 中小企業の限定された予算ではハードウェアを継続的に導入していくことはできないため Pervasive はデータベースおよびアプリケーションのパフォーマンスを改善する別の方法を見つけることに創意工夫をこらすようになりました そのすべての変更で共通する特徴は 中小企業顧客が使用するハードウェアおよび OS プラットフォームを超越して最良のパフォーマンスを得る方法を Pervasive PSQL が常に進歩させ発見してきたことです また 同じ顧客が新しい高パフォーマンスプラットフォームをできる限り簡単に導入できることを確実にしてきました Pervasive PSQL パフォーマンス

12 付録 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 XIO 2 オフ適用外オン適用外適用外 MicroKernel の最大メモリ使用量 RAM の 60% 60% 0% 3 0% 0% 1 I/O スレッド 起動時のリソース割当 オフ オン オン オン オン 最小の状態に戻す オフ オフ オフ オフ オフ インデックスバランス オフ オフ オフ オフ オフ セグメントサイズを 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 パフォーマンス

13 DB サイズ ファイルの拡張係数 1GB 未満 5% 1 GB 以上 5 GB 未満 2% 10 GB 以上 1% Pervasive PSQL パフォーマンスチューニングの詳細については Advanced Operations Guide の第 5 章 パフォーマンス をお読みください Pervasive PSQL パフォーマンス

14 付録 B - 静的キャッシュと動的キャッシュの比較 一連のパフォーマンスの時間計測に基づいて L1 キャッシュから 1 ページを読み取る平均消費時間は約 110 マイクロ秒と判断されました これとは別に L2 でのキャッシュ管理タスクは平均 210 マイクロ秒かかり ページごとの合計は 320 マイクロ秒となります 同じページをディスクから読み取る消費時間は 1900 マイクロ秒で つまり キャッシュからページを読み取るよりおよそ 18 倍長くかかります これらの時間計測は もちろん特定のハードウェア構成とオペレーティングシステム固有のもので一般化することはできませんが Pervasive PSQL の以前のバージョンの動的キャッシュと静的キャッシュの違いを明らかにするのに役立つでしょう 静的キャッシュを使用し 読み取りの 20% が Pervasive PSQL キャッシュ (L1) にヒットし 理論上 20% がシステムキャッシュにヒットし 60% がディスク I/O を必要とすると仮定します L1 およびシステムキャッシュに重複するデータが含まれておらず システムキャッシュへのアクセスに何の不利益もない理想的なケースでは 1000 件の読み取りは キャッシュアクセス時間 ( マイクロ秒 ) = 秒と ディスクアクセス時間 ( マイクロ秒 ) = 1.14 秒の合計 つまり 秒を要します 実際には L1 およびシステムキャッシュの大部分は重複している可能性が高く キャッシュ内のデータは 20% に留まり アクセス時間は ( マイクロ秒 )+( マイクロ秒 ) = 秒となります 動的キャッシュを使用すると 読み取りが L1 にヒットする可能性が 20% L2 にヒットする可能性が 50% ディスク I/O を必要とする可能性が 30% になります したがって 1000 件の読み取りに必要な時間は ( マイクロ秒 )+( マイクロ秒 )+( マイクロ秒 )= 秒 秒 秒 = 秒で 静的キャッシュの 1.5 倍から 2 倍のパフォーマンスとなります Pervasive PSQL パフォーマンス

15 問い合わせ先 株式会社エージーテック東京都千代田区神田錦町 昭栄神田橋ビル3F TEL: FAX: カスタマーセンター TEL: Pervasive Software Inc. All rights reserved. Pervasive の社名および製品名はすべて 米国およびその他の国における Pervasive Software Inc. の商標または登録商標です その他の商標は 各所有者が保有するものです Pervasive PSQL パフォーマンス