| |
ファイル・ストア: 構成
このページでは、永続的なJMSメッセージやストア・アンド・フォワード・メッセージなどのサブシステム・データを格納するためのディスクベースのファイル・ストアを構成します。
構成オプション
名前 説明 名前 このファイル・ストアの名前。この名前は、WebLogicドメイン内で一意である必要があります。
MBean属性:
WebLogicMBean.Name同期書込みポリシー ファイル・ストアがデータをディスクに書き込む方法を決定するディスク書込みポリシー。
このポリシーは、JMSファイル・ストアのパフォーマンス、スケーラビリティおよび信頼性にも影響します。通常最大のパフォーマンスを提供する
「直接書込み - キャッシュあり」の使用をお薦めします。デフォルト値は「直接書込み」です。有効なポリシー・オプションは次のとおりです。
直接書込みすべてのプラットフォームで直接I/Oがサポートされます。使用可能な場合、直接I/Oモードのファイル・ストアは自動的にネイティブI/O
wlfileioドライバをロードします。このオプションは、通常「キャッシュ・フラッシュ」を上回り、「直接書込み - キャッシュあり」よりも遅くなります。このモードはネイティブ・ストアのwlfileioドライバを必要としませんが、使用すると処理が速くなります。直接書込み - キャッシュありストア記録は
Directory属性で指定されたディレクトリ内のプライマリ・ファイルに同期的に書き込まれ、「キャッシュ・ディレクトリ」内の対応するキャッシュ・ファイルに非同期的に書き込まれます。「キャッシュ・ディレクトリ」はディスク領域、ロック、セキュリティおよびパフォーマンスの実装に関する情報を提供します。このモードは、ネイティブ・ストアのwlfileiocodeドライバを必要とします。ネイティブ・ドライバをロードできない場合、書き込みモードは自動的に「直接書込み」に切り替わります。キャッシュ・ディレクトリを参照してください。キャッシュ・フラッシュすべての書込みがディスクにフラッシュされるまでトランザクションが完了しません。このポリシーは信頼性があり、同時実行ユーザーが増えるとそれに合わせて拡大します。トランザクションは安全ですが、直接書込みポリシーよりパフォーマンスが低下します。
無効書込みがメモリーにキャッシュされると、ディスクに正常に格納されるまで待機せずに、すぐにトランザクションが完了します。書込みリクエストがディスクとの同期の待機をブロックしないため、これは最速のポリシーです。ただし、他のポリシーと異なり、オペレーティング・システムまたはハードウェアで障害が発生した場合、トランザクションは安全ではありません。このような障害が発生すると、データやメッセージの重複または消失につながる可能性があります。このオプションはネイティブ・ストアの
wlfileioドライバを必要としませんが、使用すると処理が速くなります。WebLogic以外のJMSベンダーでは、「無効」に相当するポリシーをデフォルトとするものもあります。ノート:
使用可能な場合、ファイル・ストアはパフォーマンスを向上するWebLogic
wlfileioネイティブ・ドライバをロードします。これらのドライバは、Windows、Solaris、LinuxおよびAIX WebLogicのインストールに含まれています。古いバージョンのMicrosoft Windowsでは、Windowsでデフォルトの
書き込みキャッシュを有効にする設定が使用されている場合、ストレージ・デバイスの同期書込みが完了したことを間違って報告する可能性があります。システムのクラッシュや電源の故障はレコードまたはメッセージの損失や重複につながる可能性があるため、これにより、「直接書込み」(デフォルト)または「直接書込み - キャッシュあり」ポリシーで構成されたファイル・ストアを含む、トランザクション製品(Oracleに限られません)のトランザクション・セマンティクスが無視されます。認識できる症状の1つは、ストレージ・デバイスの物理許容量を超える高い永続性メッセージまたはトランザクションのスループットが発生したときに表れます。この問題は、Microsoft提供のパッチを適用してWindowsの書き込みキャッシュを有効にする設定を無効にするか、電源を保護されたストレージ・デバイスを使用することで対処できます。http://support.microsoft.com/kb//281672およびhttp://support.microsoft.com/kb//332023を参照してください。NFSストレージ・ノート: 一部のオペレーティング・システムで、ファイルがロックされているとき、ネイティブ・ドライバのノート・リーマッピングはNFSと互換性がありません。同期書込みポリシー
「直接書込み - キャッシュあり」または「無効」のストアおよびWebLogic JMSページング・ストアでは、ネイティブwlfileioドライバを使用してパフォーマンスを向上し、メモリーマップのオペレーティング・システムの呼出しを実行します。NFS、ファイル・ロック、メモリー・マッピング間に互換性がないことをストアが検出すると、メモリー・マッピングのかわりに、従来の読取りまたは書込みのシステム・コールに自動的にダウングレードされます。最適なパフォーマンスのため、代替NFSクライアント・ドライバの調査、NFS以外のストレージの場所の構成、制御下の環境および自己責任でファイル・ロックの無効化をお薦めします(ファイル・ロックの有効化を参照)。詳細は、Oracle WebLogic ServerのパフォーマンスのチューニングのWebLogic永続ストアのチューニングを参照してください。ターゲット ファイル・ストア、JDBCストアまたはレプリケートされたストアをホストするための候補となる、現在のドメインに定義済のサーバー・インスタンス、クラスタまたは移行可能ターゲット。リソース・グループまたはリソース・グループ・テンプレートにスコープ指定する場合は、仮想ターゲットからターゲットを継承します。
クラスタを選択する場合、JMSサーバーと同じクラスタを指定する必要があります。移行可能なターゲットを選択する場合、移行可能なJMSサーバーまたはSAFエージェントと同じ移行可能なターゲットを指定する必要があります。ベスト・プラクティスは、パス・サービスが独自のカスタム・ストアを使用し、ストアとして同じターゲットを共有することです。
MBean属性:
PersistentStoreMBean.Targetsスコープ このファイル・ストアに、ドメイン、パーティションまたはリソース・グループ・テンプレート内からアクセス可能にするかどうかを指定します。
ディレクトリ ファイル・ストアがデータ・ファイルを保持するファイル・システム・ディレクトリのパス名。
ファイル・ストアに移行可能なターゲットを指定する場合、ストア・ディレクトリは、移行可能なターゲットのすべての候補サーバー・メンバーからアクセスできる必要があります。
最高レベルの可用性を実現するには、SAN(ストレージ領域ネットワーク)またはその他の信頼性のある共有ストレージを使用してください。
NFSマウントの使用は推奨されませんが、サポートされています。デフォルトでは、ほとんどのNFSマウントによるトランザクションは安全ではありません。トランザクションの正確性を確保するには、NFSベンダーのドキュメントを使用して同期書き込みリクエストを受け付けるように構成する必要があります。
「直接書込み - キャッシュあり」のSynchronousWritePolicyは、キャッシュ・ディレクトリを参照してください。ディレクトリがMicrosoft Windowsによってホストされている場合、追加のO/Sのチューニングが必要な場合があります。詳細は、同期書込みポリシーを参照してください。
MBean属性:
FileStoreMBean.Directory論理名 同一の名前を使用する別々のサーバー上にある別々のストアを参照するための、サブシステムで使用する名前。
たとえば、タイマー・サービスを使用するEJBが、論理名を使用してストアを参照するとします。この論理名は、各サーバーに物理名の異なるストアがあったとしても、同じクラスタの複数のサーバーにおいて有効であると考えられます。
同じドメインまたは同じクラスタ内の複数のストアが、同じ論理名を共有できます。ただし、ある特定の論理名を、同じサーバー上の複数のストアに割り当てることはできません。
MBean属性:
FileStoreMBean.LogicalNameキャッシュ・ディレクトリ
「直接書込み - キャッシュあり」のキャッシュ・ディレクトリの場所。他のポリシーでは無視されます。
「直接書込み - キャッシュあり」がSynchronousWritePolicyとして指定されると、プライマリ・ファイルに加えてキャッシュ・ファイルが作成されます(プライマリ・ファイルの場所はディレクトリを参照してください)。キャッシュ・ディレクトリの場所が指定されると、キャッシュ・ファイルのパスはCacheDirectory/WLStoreCache/StoreNameFileNum.DAT.cacheになります。絶対パスを使用することをお薦めしますが、ディレクトリの場所が相対パスの場合、WebLogic Serverインスタンスのホーム・ディレクトリを基準とした相対的な場所にCacheDirectoryが作成されます。またはNullが指定されると、CacheDirectoryはjava.io.tmpdirJavaシステム・プロパティ(JDKのデフォルト: UNIXの場合は/tmp、Windowsの場合は%TEMP%)によって現在のオペレーティング・システムのtempディレクトリに配置され、TempDirectory/WLStoreCache/DomainName/unique-id/StoreNameFileNum.DAT.cacheになります。java.io.tmpdirの値はオペレーティング・システムおよび構成によって異なり、-Djava.io.tmpdir=My_pathをJVMコマンド・ラインに渡すことでオーバーライドできます。考慮事項:
セキュリティ: 特にプライマリ・ディレクトリにカスタム構成されたユーザー・アクセス制限がある場合、キャッシュ・ディレクトリへのアクセスを制限するために、特定のディレクトリの許可を設定する場合があります。WebLogicのセキュリティの完全なガイドは、Oracle WebLogic Serverのプロダクション環境の保護を参照してください。
追加のディスク領域の使用: キャッシュ・ファイルは、ミラー化するプライマリ・ストア・ファイルと同じ量のディスク領域を消費します。プライマリ・ストア・ファイルの場所は、ディレクトリを参照してください。
パフォーマンス: 最適なパフォーマンスのためには、キャッシュ・ディレクトリをNAS/SAN (リモート)ストレージよりも、オペレーティング・システムの
tempディレクトリなどのローカル・ストレージに配置する必要があります。相対パスはドメインのインストールを基準として配置されるため、通常はリモート・ストレージに配置されます。ストアが停止している間にキャッシュ・ディレクトリを削除すると安全ですが、次のストアの起動速度を低下させる可能性があります。破損の防止とファイル・ロック: 2つの同じ名前のストアが同じプライマリ・ディレクトリまたはキャッシュ・ディレクトリを共有しないようにしてください。このような競合を検出し、ストアの起動を失敗させて破損を防止するように設計されたストアのファイル・ロック・チェック機能がありますが、正確性を確認するためにファイル・ロック機能に依存することはお薦めしません。ファイル・ロックの有効化を参照してください。
起動の回復: キャッシュ・ファイルはファイル・ストアの起動と回復プロセスの速度を上げるために再利用されます。ただし、現在の起動の前にストアのホストWebLogic Serverインスタンスが正常に停止した場合のみです。たとえば、
kill -9の後、OSまたはJVMのクラッシュの後、またはストア管理の圧縮処理など、プライマリ・ファイルがオフラインで変更された後は、キャッシュ・ファイルは再利用されず、完全に再作成されます。キャッシュ・ファイルが再作成されると、警告ログ・メッセージ280102が生成されます。フェイルオーバーと移行の回復: ファイル・ストアはキャッシュ・ディレクトリを使用しないで安全にデータを回復します。このため、キャッシュ・ディレクトリをコピーしたり、フェイルオーバーまたは移行後にアクセス可能にしたり、同様にNAS/SANストレージに配置したりする必要もありません。新しいホスト・システムにキャッシュを再作成する必要があることを示す
警告ログ・メッセージ280102は無視できます。キャッシュ・ファイルのクリーン・アップ: 使用していないキャッシュ・ファイルがディスク領域を消費することを防ぐため、テスト環境および開発者環境では定期的にキャッシュ・ファイルを削除する必要があります。
MBean属性:
FileStoreMBean.CacheDirectory最小ウィンドウ・バッファ・サイズ JVMのアドレス空間にマップされるプライマリ・ストア・ファイルごとのデータの最小容量(バイト単位)。最も近い2のべき乗に切り捨てられます。同期書込みポリシーが
「直接書込み - キャッシュあり」および「無効」で、ネイティブwlfileioライブラリがロードされているときのみ適用されます。最大ウィンドウ・バッファ・サイズを参照してください。MBean属性:
FileStoreMBean.MinWindowBufferSize最小値:
-1最大値:
1073741824最大ウィンドウ・バッファ・サイズ JVMのアドレス空間にマップされるプライマリ・ストア・ファイルごとのデータの最大容量(バイト単位)。最も近い2のべき乗に切り捨てられます。同期書込みポリシーの
「直接書込み - キャッシュあり」および「無効」に適用されますが、ネイティブのwlfileioライブラリがロードされたときのみです。ウィンドウ・バッファはJavaヒープ・メモリーを消費しませんが、off-heap (ネイティブ)メモリーを消費します。ストアがリクエストされたバッファ・サイズを割り当てられない場合は、
MinWindowBufferSizeに到達するまでより小さいバッファを割り当て、MinWindowBufferSizeに到達すると失敗します。最大ウィンドウ・バッファのサイズを、その他の制約がないかぎり、最大書込みの2倍(同時に更新される複数の記録が1つの書込みとして組み合される可能性があります)およびファイル・サイズ以上に設定することをお薦めします。32ビットのJVMでは、Javaヒープとoff-heap (ネイティブ)のメモリー使用量の合計の制限を2から4 GBに設定します。
実際に割り当てられているウィンドウ・バッファ・サイズを調べるには、ストア属性
AllocatedWindowBufferBytesを参照してください。最大ファイル・サイズおよび最小ウィンドウ・バッファ・サイズを参照してください。
MBean属性:
FileStoreMBean.MaxWindowBufferSize最小値:
-1最大値:
1073741824IOバッファ・サイズ I/Oバッファのサイズ(バイト単位)で、自動的に最も近い2のべき乗に切り捨てられます。
「直接書込み - キャッシュあり」ポリシーでネイティブwlfileioドライバが使用できるときは、IOBufferSizeはシステム・コールに渡されるキャッシュ・ビューの最大容量を表します。この部分は、off-heap (ネイティブ)メモリーまたはJavaヒープ・メモリーを消費しません。
「直接書込み」ポリシーおよび「キャッシュ・フラッシュ」ポリシーでは、IOBufferSizeはoff-heap (ネイティブ)メモリーを消費するストア・バッファごとのサイズを表します。実行時に1つのバッファが割り当てられますが、起動の回復時に複数のバッファが一時的に作成される場合があります。ネイティブ
wlfileioドライバを使用できない場合、この設定は(「無効」を含む)すべてのポリシーのoff-heap (ネイティブ)メモリーに適用されます。最適な実行時パフォーマンスのために、
IOBufferSizeを最大書込み(同時に更新される複数のリクエストが1つの書込みとして組み合される可能性があります)よりも大きな値に設定することをお薦めします大きなストアでの起動回復時間の最適なパフォーマンスのために、
IOBufferSizeを2 MB以上に設定することをお薦めします。実際に割り当てられているoff-heap(ネイティブ)メモリーを調べるには、AllocatedIOBufferBytesを参照してください。これは、
「直接書込み」ポリシーおよび「キャッシュ・フラッシュ」ポリシーのIOBufferSizeの倍数か、ゼロになります。MBean属性:
FileStoreMBean.IoBufferSize最小値:
-1最大値:
67108864最大ファイル・サイズ 各データ・ファイルの最大ファイル・サイズ(バイト)。
MaxFileSize値は特定のサイズのストアを格納するために必要なファイルの数に影響します(ファイルの数=ストアのサイズ/切り上げられたMaxFileSize)。新しい記録のための領域が十分にない場合、ファイル・ストアは自動的に記録の削除によって開放された領域を再利用し、自動的に個々のファイルを
MaxFileSizeまで拡張します。既存のファイルに新しい記録のための領域が残っていない場合、ストアは追加ファイルを作成します。各ファイルにウィンドウ・バッファおよびファイル・ハンドルが割り当てられるため、通常少数の大きなファイルのほうが多数の小さなファイルより推奨されます。
MaxFileSizeが2^24 *BlockSizeより大きい場合、MaxFileSizeは無視され、値は2^24 *BlockSizeになります。デフォルトのBlockSizeは512で、2^24 * 512は8 GBです。ストアによって複数のデータ・ファイルが使用されている場合、
MaxFileSizeの最小サイズは10 MBです。InitialSizeがMaxFileSizeより小さい場合は、InitialSizeバイトの単一ファイルが作成されます。InitialSizeがMaxFileSizeより大きい場合は、MaxFileSizeバイトの(InitialSize/MaxFileSize)ファイルが作成され、必要に応じて残りを含む追加のファイルが作成されます。初期サイズを参照してください。
MBean属性:
FileStoreMBean.MaxFileSize最小値:
1048576最大値:
2139095040ファイル・ロックの有効化 OSのファイル・ロックが使用されているかどうかを判断します。
ファイル・ロック保護が有効なとき、別のストア・インスタンスがすでにストア・ファイルを開いていると、ストアの起動に失敗します。複数のストア・インスタンスが同じファイルを開くことを防ぐ手順が揃っていないかぎり、この設定を無効にしないでください。ファイル・ロックは必須ではありませんが、同じディレクトリで2つの同名のファイル・ストア・インスタンスが動作したときに発生する破損を防ぐのに役立ちます。この設定は、プライマリ・ファイルおよびキャッシュ・ファイルの両方に適用されます。
MBean属性:
FileStoreMBean.FileLockingEnabledブロック・サイズ ファイルのアドレス指定可能な最小ブロック(バイト)。ネイティブ
wlfileioドライバが使用でき、ブロック・サイズがユーザーによって構成されていないとき、ストアはバッファされていない(直接) I/OとしてOS指定の最小値(範囲[512, 8192]内にある場合)を選択します。一度ファイル・ストアがファイルを作成すると、そのファイル・ストアのブロック・サイズは変更されません。ブロック・サイズの変更は新しいファイル・ストアまたは現在のファイルが削除されたときにのみ有効です。Oracle WebLogic Serverのパフォーマンスのチューニングの永続ストアのチューニングを参照してください。
MBean属性:
FileStoreMBean.BlockSize最小値:
-1最大値:
8192初期サイズ ファイルの初期サイズ(バイト)。
ファイル・ストアの起動時に、
InitialSizeを事前割当て済のファイル領域に設定します。InitialSizeがMaxFileSizeを超える場合、ストアは複数のファイルを作成します(ファイルの数 =InitialSize/切り上げられたMaxFileSize)。新しい書込みリクエストのための領域が十分にない場合、ファイル・ストアは自動的に削除された記録の領域を再利用し、自動的にファイルを拡張します。
ファイルの拡張は、まれな状況で一時的な待機時間が長く続く可能性があるため、
InitialSizeを使用して実行時のファイルの拡張を制限または防止します。初期サイズの変更は、新しいファイル・ストアに対してのみ、または現在のファイルが削除された後に再起動した場合のみ有効です。
最大ファイル・サイズを参照してください。
MBean属性:
FileStoreMBean.InitialSize最小値:
0
|