What's New in Pervasive PSQL (v11)

マルチコア サポート

Pervasive PSQL v11 は、特にマルチコア マシンにおけるスケーラビリティとパフォーマンスを向上させることを目的に設計されています。マルチコア マシンに Pervasive PSQL v11 をインストールすると、マルチユーザー環境ですぐにその効果が得られます。

どれほどの効果があるのか知りたいと思われるでしょう。ハードウェア テクノロジの進歩によってスケーラビリティとパフォーマンスは明らかに向上しており、それらを利用できると考えられます。これまでは、ハードウェア テクノロジの進歩といえば速度の高速化を指していました。つまり、アプリケーションの実行速度が速くなるということです。近年、コンピューター テクノロジにおける進歩は、クロック速度の高速化ではなく並列処理効率の向上を指すようになってきました。これにより、アプリケーションに対し、おそらく今まで取り組むことがなかった課題が出てきました。

この進歩は、マルチコア環境のためにだけに変わったのではなく、劇的に変わっています。たとえば、複数のユーザーでデータを共有し、トランザクションの整合性を維持する必要があるデータベースを使用するアプリケーションの場合は、マルチコア プロセッサ上では実行速度が低下する可能性があります。

Pervasive PSQL v11 を使用する大多数のアプリケーションがこの状況に当てはまるので、マルチコアのサポートが Pervasive PSQL における主要な機能となっています。これはマルチユーザー アプリケーションをマルチコア環境に移行する場合に最も重要です。

マルチコアをサポートする理由

ほとんどのソフトウェア アプリケーションは変更することなくマルチコア マシンで実行できます。しかし、次のような状況では変更を検討する必要があります。これは実在のフィードバックに基づいています。

旧式の製品サーバーを最新のものにリプレースすることになりました。新しいマルチコア マシン(互換性のあるオペレーティング システム搭載)にマルチユーザー アプリケーションをインストールしました。これで、今までより動作が快適になると思われました。しかし、応答時間が遅くなってしまい、パフォーマンスはハードウェアのアップグレード前よりも低下してしまいました。

どうしてでしょう?これは、ビジネス ソリューションの重要な各要素が、マルチコアの新しい世界では互いに最適化されていないからです。

これを次のように考えてみましょう。 "アプリケーション" は、作成したコード(一般的な定義では "アプリケーション")、データベースオペレーティング システムおよびハードウェアという 4 つの主要な要素で構成されています。ハードウェアの変更は大きな影響があります。ただし、これはそのハードウェアが変更前のものと根本的に異なっていた場合です。

しかし、適切な調整を行うことで処理速度が上がるアプリケーションであれば、ハードウェアの変更の利点を活用し、パフォーマンスを大幅に向上させることができます。多くの場合、データベースなどアプリケーション スタックの一部をスワップ アウトすればマルチコアの問題を解決することができます。アプリケーションをすぐに変更する必要はありません。この手段は、アプリケーション開発の長期的な方策を講じる間、時間を稼ぐためのリスクの低い方法として用いることができます。

Pervasive PSQL v11 をデータベースとして使用すれば、マルチコア マシン上でパフォーマンスとスケーラビリティが向上することを実感することができます。

パフォーマンス

Pervasive PSQL v11 は、複数の類似動作を実行する並列スレッドを提供するよう設計されています。並列処理が増加したことで、マルチ プロセッサに関わる地点までのスループットが改善します。この結果、複数のクライアントがセントラル サーバーにアクセスするマルチコア環境で、データベース エンジンのパフォーマンスが向上します。マルチクライアント アプリケーションは、コードを再コンパイルしたり再設計することなく、このパフォーマンスの向上による利点を得ることができます。

また、Pervasive PSQL v11 はトランザクショナル インターフェイスにおける低レベルの同期メカニズムについても機能強化しています。複数のユーザーが、キャッシュされた同じファイル ページを同時に読み込むことができ、またそれらの操作はそれぞれ別々のサーバー CPU で処理することができます。チェックポイントやログ管理などの非ユーザー操作には、さらに別のサーバー CPU を使用することもできます。

スケーラビリティ

Pervasive PSQL v11 は、特にマルチコア ハードウェア向けに行ったアーキテクチャ設計によってスケーラビリティも強化されました。たとえば、複数のユーザーがそれぞれ別々のファイルにアクセスする場合、それらの操作を別々のサーバー CPU で処理することができます。また、データベース エンジンは、以前に比べ少ないオーバーヘッドで多くのユーザー ロードを処理することもできるので、より安定したスループットが実現します。

パフォーマンスの向上と同様に、コードを再コンパイルしたり再設計することなく、このスケーラビリティの向上によるすべての利点を得ることができます。

各種設定

Pervasive PSQL v11 におけるマルチコアに関する改善点の大部分は透過的です。その最適化をより高めるために調整する必要がある設定は特にありません。なお、[通信スレッド数]設定は変更されています。この設定を使用すると、パフォーマンスを微調整することができます。設定を参照してください。

マルチコアのジレンマ

マルチコア環境におけるハードウェアとソフトウェアの相互作用によっていくつかの問題が出てきました。それによりアプリケーションでパフォーマンスが低下する可能性もあります。その問題の中には、マルチスレッドとメモリの競合などがあります。これらの問題およびその他の問題の詳細については、CITO Research の CTO(最高技術責任者)Dan Woods 氏によるホワイト ペーパー「マルチコアのジレンマ」(The Multi-core Dilemma)を参照してください。このホワイト ペーパーは Pervasive Web サイトから入手可能です。

本ドキュメントではマルチ スレッドとメモリの競合について簡単に説明します。これによりマルチコアのサポートが Pervasive PSQL v11 の主要な機能となっている理由を明らかにします。

マルチ スレッド

マルチスレッド化されたアプリケーションは、必ずしもマルチコア マシンで実行速度が速くなるわけではありません。事実、マルチスレッド化されたアプリケーションの実行速度は低下する場合があります。

スレッドが正しく並列に動作するためには、それらのスレッドを同期させる必要があります。アプリケーションがマルチスレッド化できても、スレッド自体が同期するわけではありません。実際、この状況はごく一般的なことで、古いアプリケーションは必要に応じて追加のスレッドを分離独立させています。これは、効率性を確保する設計に基づくよりも便利なためです。そのようなアプリケーションはスレッドが互いに競合するため、マルチコア マシンで効率よく実行されません。スレッドの競合により、マルチコアが関わっていない地点までのスループットが阻害されるので、マルチコアが提供されてもメリットがありません。

また、マルチコア アーキテクチャは、マルチ スレッドを一連のシングル スレッドとして分離独立させるサブタスクを認識することがあります。そうすると、シングルスレッド化されたプログラムと同じように、そのスレッドは単独のキューに強制的に入れられ、1 つずつ処理されます。キャッシュではこの問題を改善できません。より悪化してしまいます(メモリの競合を参照してください)。

可能であれば、コアごとに個別のデータを処理するようにします。そうでなければ、同期に伴うオーバーヘッドによってパフォーマンスが著しく低下する恐れがあります。Pervasive PSQL v11 は、同期される並列スレッドを提供するよう設計されていることを思い出してください。

メモリの競合

開発者はアプリケーションの作成時に、並列処理または非並列処理のどちらにするか決定する必要はありませんでした。アプリケーションの大半はシーケンシャルに作成されます。つまり、これらは逐次的または連続的に情報へアクセスするということです。メモリの競合に伴う問題は、マルチコア システムで非並列(一般的)アプリケーションを実行したときに発生します。

人々が一群となって一斉に 1 つの出入り口を通り抜けようとする様子を描く(喜劇的)寸劇を思い浮かべてください。 出入り口は人々でいっぱいになり、ぎゅうぎゅう詰めに押し込められている様子は面白いと思われるでしょう。 では次に、これを複数のスレッド(人々)を同時に処理(出入り口)しようとする状況に置き換えてみてください。4 個から 16個(またはそれ以上)のスレッドが一度に同じプロセッサを通り抜けようとする場合は混雑が生じ、オペレーティング システムがそれらを整理する必要があります。

複数のコアまたはプロセッサに同じデータを指すキャッシュがある場合、1 つのコアがそのデータを変更すると、別のコアにキャッシュされたデータは無効になります。このため、キャッシュを同期させる必要があります。また、あるプロセッサのタスクが、別のプロセッサのタスクによって作成された古いデータに対して実行されないようにするために、各プロセッサがキャッシュを繰り返しチェックする場合にも競合が発生します。このチェックでは、各プロセッサがメモリ キャッシュを個別かつ順次にチェックするので、処理速度が低下します。

メモリの競合を減らす方法として、Pervasive PSQL v11 では複数のユーザーによる操作を別々のサーバー CPU 上で処理することを思い出してください。複数のユーザーが、キャッシュされた同じファイル ページを同時に読み込むことができ、また別々のファイルにアクセスすることができます。

オペレーティング システムの役割

オペレーティング システム(OS)はマルチ コアの問題をどのように支援するのか、知りたいと思われるでしょう。最新の 64 ビット OS にもかかわらず、期待するほどの効果はありません。

リソースの競合が発生した場合、OS がその問題の解決にあたります。大多数のアプリケーションで、マルチコア システム上の OS がスレッドの競合を処理するときには速度が低下します。つまり、マルチコア システム上の OS では、競合ポイントの解決に時間がかかります。

これには次のような理由があります。アプリケーションがオペレーティング システムに対し、単一ファイルで複数のタスクを実行する方法を今もなお要求している場合、マルチコア用に最適化されたオペレーティング システムであっても問題を解決することはできません。

マルチコア処理用の命令が組み込まれていないアプリケーションからのリクエストを OS が受ける場合、その OS にとってリクエストを処理する順序の並び替えは大きな負荷となります。これは車の交通渋滞に似ています。概念的に言えば、OS はそれぞれの車を通す前に、待機している車の各運転手に対し、進行する準備ができているかどうか尋ねます。そのような処理渋滞が OS レベルで起こっていたとしても、ユーザーは、その処理速度の低下をアプリケーションのパフォーマンスの問題としてとらえます。

マルチコア用に最適化されたアプリケーションは、共有リソースの管理方法およびリソースへのアクセス優先度について、OS へ指示を与えることができます。情報の要求は、キャッシュ ラインの競合を行わない、または中央メモリにアクセスしないよう整理されます。

Pervasive PSQL v11 には、特にマルチコア ハードウェア向けのアーキテクチャ設計が含まれていることを思い出してください。低レベル ロックは、マルチコア マシン向けに最適化されました。

現時点で得られる利点と将来的な計画

マルチコア マシンは今や標準仕様となっているので、現行または将来のハードウェア アップグレードには複数のコアが含まれます。一方、オペレーティング システムは最良のパフォーマンスを支援するためのマルチコア マシンに対応できていません。これらの状況に対処するにはどのような方法が一番よいでしょうか。

最終的には、マルチコア マシンで最適に実行されるようアプリケーションを再設計する必要があります。そうすれば、アプリケーションはマルチ プロセッサにおける並列スレッドを利用し、さらに同期の問題を回避することができます。

再設計には周到な計画と実装するための時間を要します。場合によっては数年かかるかもしれません。それまでの間は従来の状況が続くことになるでしょう。このセクションの冒頭でも述べたように、アプリケーションをマルチコア環境に移行する上で、マルチコアのサポートは最も重要です。

"アプリケーション" はコードデータベースオペレーティング システムおよびハードウェアで構成されています。ハードウェア システムは既にマルチコア サポートに対応しています。アプリケーションがマルチコアを活用することによって、オペレーティング システムからなんらかの支援が得られます。それはデータベースにゆだねられます。

Pervasive PSQL v11 のマルチコア機能は、マルチコア環境向けに最適化されていないアプリケーションでユーザーやエンド ユーサーが経験するパフォーマンスの低下を補うのに役立ちます。ほとんどの場合、アプリケーション コードの再コンパイルや変更を行わなくても、アプリケーションのパフォーマンスを向上させることができます。


以前の Pervasive PSQL v11 の新機能

IPv6 のサポート