資料

4D SERVER V12 64-BITでのクエリ

warning: file_get_contents(http://www.telize.com/geoip/54.198.55.167) [function.file-get-contents]: failed to open stream: HTTP request failed! in /var/www/www.4d.com/docs/includes/common.inc(1762) : eval()'d code on line 4.

 

4D Server v12 64-bitでのクエリ

キャッシュサイズを増やしてクエリをスピードアップ

拡張性とは通常、速度のことではありません。より多くのメモリを割り当てられることで、アプリケーションの動作が速くなるわけではありませんが、より重いロードをサポートできるようになります。しかし動作が速くなることもあります。これは4D Serverがより多くのRAMを使用できるようになるためです。典型的な例はキャッシュサイズです。32-bitバージョンではキャッシュに最大2.3GBを割り当てることができます。(残りは接続やプロセス、ユーザー、コードを処理するためにエンジンが使用します。) 64-bitバージョンにはこの制限がなく、キャッシュにすべてのレコードインデックスを格納することができます。これによりアプリケーションが速くなります。すべてのデータをキャッシュに置くことができることで、4D Serverは (空きスペースを作ってユーザーがリクエストしたレコードをロードする等のために) それをパージする必要はなくなります。レコードはすでにキャッシュにあり、ディスクとのスワップは発生しません。

 

この動作をお見せするために、同じテーブルに対するシーケンシャルクエリを2回実行して時間を比較しました。

 

方法

1テーブル1フィールドのシンプルなストラクチャーを使用しました。テーブルには7,500,000レコードが保存されています。レコードごとに、フィールドには50-100文字が格納されています。データファイルはディスク上で3.2GBです。フィールドにインデックスは設定されていません。クエリは常にシーケンシャルです。

 

両ケースで2回のクエリを実行します。最初のクエリでキャッシュにデータをいれます。そして同じクエリをもう一度行います。2回目のクエリは1回目より速くなるはずです。なぜなら最初のクエリで、少なくともいくつかのレコードはキャッシュにロードされているはずだからです。

 

32-bitバージョンではキャッシュを最大2.33GBに設定しました。64-bitバージョンでは4GBで、これはすべてのデータをキャッシュに格納できるサイズとなります。32-bitバージョンでは一部しか保持できません。 (データファイルのサイズが3.2GBだったことを思い出してください。)

 

サーバー側で、マシンはDell製のIntel Xeon、2.67GHz, 6GB RAM、Windows 7 64-bitを使用しました。4DクライアントはIntel Core 2 DuoプロセッサーのMac OS X上で実行しました。

 

結果

一回目のクエリ結果:

 


最初のシーケンシャルクエリ (キャッシュにロード)、単位は秒


この最初のクエリは想像通り遅いです。多くのレコードがありますし、4Dはディスクからデータを読み込まなければなりません。これは遅い処理です (ディスクアクセスはミリ秒単位で行われ、RAMアクセスはマイクロ秒単位で行われます)。この状態で64-bitバージョンは25%速いです。これは64-bitバージョンがすべてのレコードをキャッシュにロードできるのに対し、32-bitバージョンでは新しいデータをロードするためにどこかの時点でキャッシュの一部をパージしなければならないからです (以下の管理ウィンドウスクリーンショットをご覧ください)。


キャッシュにレコードが取られたら (64-bitバージョンでは全レコード、32-bitバージョンでは一部のレコード)、32-bitと64-bitの違いは大きなものとなります。64-bitバージョンは26倍も速くなりました:

 


2回目のシーケンシャルクエリ (秒)、データがキャッシュにある状態

 

完全に期待通りの結果です。すべてのデータがキャッシュにとられていれば、4Dは新しいデータを読み込むためにパージを行う必要はありません。メモリをディスクにスワップする必要はありません。管理ウィンドウは以下のようになります。

 

キャッシュに1.96GBを確保した32-bitバージョンでは、パージやロードが繰り返されている様子を目に見ることができます:
 

 

キャッシュに4GBを設定した64-bitバージョンでは、すべてのデータが最初のクエリでキャッシュに格納され、利用可能になります。パージやディスクとのスワップが発生しないので、アクセスがとても速くなります:

 

 

というわけで32-bitから64-bitに移行するだけでアプリケーションの速度を向上させることができます。コードを変更する必要はありません (ストアドプロシージャーのスタックサイズを除く、4D v12.1追加修正情報を参照)。キャッシュの設定を変更するだけです。これぞ拡張性です。

 

すべてのデータをキャッシュにとるために

4D Server 64-bitバージョンへの移行を検討する際は以下の点に留意してください:

  • データファイルのサイズ (.4DD)
  • インデックスファイルのサイズ (.4DIndx)
  • ストラクチャーファイルのサイズ (.4DB/.4DC と .4DIndy)
  • 使用するコンポーネントのサイズ

 

キャッシュにすべてのデータを格納するために必要な最小サイズを正確に計算する簡単な式はありません。例えばデータファイルに多くの空き空間がある場合 (つまり多くのレコードが削除された後)、少なめのキャッシュで足りるでしょう。データベースが運用され、ユーザーがデータを更新していけば、必要サイズは次第に大きくなります。

 

そこで以下の計算式を使用することができます:

  • データファイルとインデックスファイルのサイズを加算。
  • ストラクチャーファイルとコンポーネントのサイズを加算。通常ストラクチャーはそう巨大ではありません。しかしもし大きければ、考慮にいれる必要があります。
  • 結果を1.5倍します。

 

例えば無視できるほど小さなストラクチャーを持つアプリケーションで、コンポーネントを使用せず、データ+インデックスサイズが4GBの場合、キャッシュは6GBに設定します。


 

 

他の資料を見る