以下は、Caché5.0.xに関する記述です。
●データベースキャッシュ用メモリ 単位:MB データベースキャッシュの総サイズをMB単位で指定します。
データベースキャッシュは2KB用と8KB用とが存在します。
コンフィグレーション内に2KB/8KBのデータベースが共存している場合は、それぞれにキャッシュを割り当ててください。
(詳細ボタンを押下すると2KB用の値設定が行える画面に切り替わります)
Caché5以降は、デフォルトで8KBのデータベースが作成されますが、旧バージョンからcache.datをコピーして使用している場合等は、ご注意ください。
2KB=0(デフォルト)の場合、2KBデータベースは8KBバッファを使用してキャッシュされます。
(6KB無駄になります)
理論上、グローバルバッファ値をアプリケーションで使用するすべてのグローバルのトータルのサイズに合わせておけば、全てのデータをキャッシュに乗せることが可能です。
これによりグローバル参照に伴う物理DISK I/O数を最小限に抑えることができます。
この値の適正値の決定には、アプリケーションの実行/GLOSTAT統計データの参照を 繰り返す必要があります。(注1)
(注1) GLOSTAT等でCache Efficiencyをモニタしてください。この値はDISKへの物理I/Oと論理I/O(キャッシュから取得)の比で、ここの数値が大きいほどキャッシュヒット率が高い状態です。
この値が常時40を下回るようなら本値を増加させることを検討してください。
●ルーチンキャッシュ用メモリ 単位:MB ルーチンキャッシュの総サイズをMB単位で指定します。
個々のルーチンキャッシュのサイズは32KBです。
例えばアプリケーションで使用するルーチンが100ルーチン存在する場合、理論上、[ルーチンキャッシュ用メモリ]に100*32KB=32MB~を設定すれば全てのルーチンをキャッシュに乗せることが可能です。
これにより、ルーチンの実行に伴う物理DISK I/O数を最小限に抑えることができます。
また、クラスを使用している場合は、クラスがコンパイルされた結果生成されるルーチンも この領域を使用します。
よって、ルーチンキャッシュサイズは [ルーチンの総数+クラスがコンパイルされた結果のルーチンの総数]*32KB
(注1) が開始値としては適当な値といえます。
また、動的クエリ(xDBCや%ResultSetのDynamicSQL)を使用している場合、キャッシュドクエリとして生成されるルーチンの個数も考慮に入れる必要があります。
(注2) この値の適正値の決定には、アプリケーションの実行/GLOSTAT統計データの参照を 繰り返す必要があります。
(注3) (注1) アプリケーションが存在するネームスペース上で*.OBJの個数を調べてください。
エクスプローラでフィルタに[*.OBJ]を指定する方法が最も簡単です。
(注2) クエリ実行後に、テーブルが存在するネームスペース上でCacheSql*.OBJの個数を調べてください。
エクスプローラでフィルタに[CacheSql*.OBJ]を指定する方法が最も簡単です。
(注3) GLOSTAT等でRoutine buffer loads and saves:をモニタしてください。
この値はルーチンの読み出しが物理DISK I/Oを伴う場合にカウントされます。
通常、起動直後しばらくはこの値が増加し続けますがルーチンキャッシュが十分に確保されている環境では、この値はいずれ収束します。
詳細=>メモリセクション関連の設定内容 ●ルーチンオブジェクトバッファ 単位:個 クラスの情報(クラスデスクリプタ)を保持するための領域を個数で指定します。
アプリケーションで使用するクラスが100個存在する場合、理論上、[ルーチンオブジェクトバッファ]に100~を設定すれば、全てのクラス情報をオンメモリに保持することが可能です。
この項目は個数指定です。実際に確保されるメモリ量はこの値に32KBを掛けた量になります。
実装上、ルーチンキャッシュと同じ構造を使用しますが、ルーチンキャッシュで指定した領域とは別に確保される領域です。
[ルーチンキャッシュ用メモリ]で指定した領域の一部をリザーブするものではありませんのでご注意ください。
●一般メモリヒープ 単位:KB 管理メモリ領域をKBで指定します。本領域には下記の情報が含まれます。
よって、これらの領域を増加する場合には、合わせてこちらの領域も増加する必要があります。
- プロセスIDテーブル (動的に拡張)128スロット~、不足時は+128スロット単位で増加、約900B/スロット - ロックテーブル (*構成マネージャで変更可能)
- SLMテーブル (*構成マネージャで変更可能)
- NLSテーブル - ネームスペーステーブル ([SLMテーブル]で変更可能)
- クラスコントロールブロック (動的に拡張)
●ロックテーブル 単位:バイト インスタンス全体で使用出来るロックの総量をバイトで指定します。
アプリケーションがLockコマンドを実行するたびにこの領域が消費されます。
個々の消費量は可変長です。
下記の処理により空き容量を知ることができます。
ロック実行前と実行後で下記の処理を実施することにより、おおよその消費量を推定することが可能です。
ロックテーブルの空きが不足すると、新たなLockコマンドは空きができるまで待たされます。
この場合、タイムアウト付きのLockはタイムアウトします。
●IJCバッファ 単位:バイト ジョブ間通信で使用できる個々のバッファのサイズをバイトで指定します。
アプリケーションでOpen 224...等の機能を使用していなければデフォルトのままで問題ありません。
●IJCバッファ 単位:個 ジョブ間通信で使用できるバッファの個数を指定します。
アプリケーションでOpen 224...等の機能を使用していなければデフォルトのままで問題ありません。
●ネームスペーステーブル 単位:バイト 現在使用されておりません(無視されます)。
●SLMテーブル 単位:バイト SLM(Subscripts Level Mapping)
テーブルは、各ネームスペースの情報(使用するデータベースの名前、データベースのディレクトリ、さらにグローバルトランスレーション、グローバルのサブスクリプトレベルでのトランスレーションの情報等)を保持する領域です。
このため、ネームスペースの個数を増やすとSMLテーブルのサイズを増やす必要があります。
ネームスペース1個が使用するSMLテーブルのサイズは、約 800 bytes になります。
(ただし、データベース名の長さ、ディレクトリ名の長さ、グローバルのトランスレーションの個数等により変わります。)
SLMテーブルのデフォルトの値は 65535 bytes なので約80個程度のネームスペースが定義できます。
このSLMテーブルは最大 2097152 bytes まで設定可能です。
●共有メモリアドレス 単位:アドレス(16進数) 共有メモリ開始位置を指定します。
通常デフォルト値で問題ありません。
●照合テーブル最大数 単位:個 インスタンスが保持可能な照合(collation)テーブルの最大数を指定します。
通常デフォルト値で十分です。
本項目は、照合テーブルへのポインタを保持するだけで実際に照合テーブルがロードされるかどうかは、NLSのロケール設定に従います。
日本語環境ではデフォルトで照合テーブルは最大1つ(Japanese1)しかロードされません。