4GB限界とサーバプログラムの対応

皆さん、こんにちは。Dr.テトランです。今年もあとわずかですね。少し間が空いてしまいましたが、今回は4GB限界とサーバプログラムと題して述べてみたいと思います。

セグメントを固定したi386が提供できるアドレス空間は、32ビットオフセットだけなので、4GBが限度です。これを先に述べたようにOSと分け合うので、実際にアプリケーションが使用するのは2GB迄です。(3GB迄拡張できるツールもある) 一般のアプリケーションならばこれで十分な広さでしょうが、メモリーマップドファイルを使うDBMSにとっては、問題になってくる場合があります。Tetra21サーバでも、レコードパラメータに制約が出てきます。(これは、管理しているデータ全体のことではありません。全体の制限はメディアサイズやPCの能力で決まります。)

勿論、仮想メモリへのマップはスレッド共通で、しかも動的に行っており、仮想とはいえ無駄にメモリ空間を占拠しないような構成になっています。(通常は、スレッド単位に仮想アドレスを取得するので、益々2GB限界に当たり易い)しかし、それでもインデックスサイズの増大と共に32ビット限界が見えつつあります。この問題をプログラムで解決する方法は二つ考えられます。
 

一つは、インデックスを項目別に分けてレコード長を短くするか、インデックス全体をビューにマップせずに、特定のサイズに分けてマップしながら使う方法です

全て既知の方法で対処可能ですが、実空間の拡張が望めないので、パフォーマンスが犠牲になります。特に、「一部をビューにマップする」場合は、本来のマップオフセット(64ビット)を、i386のセグメントアーキテクチャのようにして、小分けして32ビットオフセットで操作することになり、管理が複雑になってしまいます。
Tetra21サーバの場合、レコード数が大きくレコード長も長くなりそうなテーブルに、「物件概要」があります。リビジョン77以降のサーバであれば、現在の最大レコード長を知らせる能力(DB情報UIを参照)があるので、その値を基に再構成すると良いでしょう。

 

もう一つは、DBMSの64ビット化です

既に2GB以上の実メモリが当たり前になった現状では、こちらの方が高いパフォーマンスを実現できます。但し、64ビットの開発環境とソースプログラムの手直し(RPCIF部及びデータ構造を32ビット型で残しつつ、スタブや内部ポインタ関連の64ビット化)を行う必要があり、かなりの工数が見込まれます。勿論複数のプロジェクトにするつもりは無いので、32ビット環境でビルトする場合はこれまでと同じ実行コードが得られなければなりません。(当分32ビット版も必要)

(このモデルケースとして、弊社で無償提供しているプレイヤーアプリ(WFP4Exp.exe)を、上記の基準を満足するように64ビット化してみました。結果的には、想定以上の工数と困難さが伴いそうです。)

また、動作環境もそれに見合ったものが必要です。(CPU処理速度&物理メモリサイズ)残念ながら、どちらも現在のところ開発計画には至っていないので、DBパラメータの設定で問題を回避してください。実メモリが2GBあるとして、マスタファイルの4つのTDB合計サイズが1GB程度なら、実用的なパフォーマンスを持てると思います。(レコード長の無駄を切り詰めることが重要です)

Comments are closed.