1. 『Oracle WebLogic Serverのパフォーマンスのチューニング』
  2. WebLogic永続ストアのチューニング

6 WebLogic永続ストアのチューニング

永続ストアは、永続性を必要とするOracle WebLogic Serverのサブシステムおよびサービス用の組込みの高性能ストレージ・ソリューションを提供します。JDBCストア、ファイル・ストアをチューニングし、永続ストアを使用する際のベスト・プラクティスに従って、永続ストアをチューニングします。

永続ストアの概要

管理サーバーを含め、すべてのサーバー・インスタンスには、構成が不要なデフォルトの永続ストアがあります。デフォルトのファイル・ストアの使用に加えて、ファイルベースのストアやJDBCにアクセスできるストア、JDBC TLOGストア、およびファイルベースのページング・ストアを構成することもできます。

親トピック: WebLogic永続ストアのチューニング

デフォルト永続ストアの使用方法

管理サーバーを含め、すべてのサーバー・インスタンスには、構成が不要なデフォルトの永続ストアがあります。デフォルト・ストアはファイルベースのストアで、サーバー・インスタンスのdata\store\defaultディレクトリに格納された一連のファイルにデータを保持します。デフォルト・ストア用のディレクトリは、存在しない場合には自動的に作成されます。このデフォルト・ストアは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ・メカニズムを使用することで最適に動作するサブシステムから使用することができます。たとえば、永続ストアが構成されていないJMSサーバーは、管理対象サーバー用のデフォルトのストアを使用して永続メッセージングをサポートします。高可用性のため、ベスト・プラクティスとしては、デフォルトのストアではなく、カスタム・ファイルまたはJDBCストアを構成します。次を参照してください:

親トピック: 永続ストアの概要

カスタム・ファイル・ストアとJDBCストアの使用方法

デフォルトのファイル・ストアを使用するだけでなく、特定のニーズに合わせてファイル・ストアやJDBCストアを構成することもできます。デフォルト・ファイル・ストアと同様、カスタム・ファイル・ストアもディレクトリに格納された一連のファイルにデータを保持します。一方、特定のストレージ・デバイスにデータを保持するカスタム・ファイル・ストアを作成することもできます。ファイル・ストアのディレクトリを構成する場合は、そのファイル・ストアが配置されているサーバー・インスタンスにアクセスできるディレクトリを設定する必要があります。

JDBCストアは、リレーショナル・データベースをストレージとして使用している場合に構成できます。JDBCストアを使用することで、指定のJDBCデータ・ストアを介してアクセスできる標準のJDBC対応データベースに永続メッセージを格納できます。JDBCストアのデータベース表に格納されたデータには、WLStoreという論理名が付けられます。データベースの高可用性とパフォーマンスを構成するかどうかは、データベース管理者の判断です。次を参照してください:

親トピック: 永続ストアの概要

JDBC TLOGストアの使用

JDBC TLOGストアを構成してトランザクション・ログがデータベースに永続化されるようにできます。これによって、ベースとなるデータベースのレプリケーションとHA特性を利用したり、障害時リカバリを簡易化したり、トランザクション・リカバリ・サービスの移行を改善できます。『WebLogic永続ストアの管理』のJDBC TLogストアの使用に関する項を参照してください。

親トピック: 永続ストアの概要

JMSページング・ストアの使用方法

各JMSサーバーではファイルベースのページング・ストアが暗黙的に作成されます。このストアは、WebLogic Server JVMが低メモリー状態で動作しているときに、非永続性メッセージおよび永続メッセージのページングに使用されます。ページング・ストアを使用すると、アプリケーションによってはディスク・アクティビティが増大することがあります。

オプションで、ページングが開始するしきい値設定およびディレクトリの場所を変更できます。可能な場合、一時ディレクトリなどローカルなファイル・システムにページング・ストア・ディレクトリの場所を指定すると、パフォーマンスを向上できます。ページング・ストア・ファイルはJMSサーバーを再起動するたびに自動的に再読込みされるので、どこからでもアクセスできる場所にバックアップ、レプリケートまたは配置する必要はありません。『Oracle WebLogic Server JMSリソースの管理』のWebLogic Server 9.x以上でのJMSサーバー動作に関する項を参照してください。

ノート:

ページングされた永続メッセージは、次の2つの場所に格納される可能性があります。

  • 通常は、デフォルト・ストアまたはカスタム・ストア。

  • 場合によっては、ページング・ディレクトリ。

親トピック: 永続ストアの概要

フラッシュ・ストレージを使用したJMSメッセージのページング

ローカルでマウントされたエンタープライズクラスのフラッシュ・ストレージ・デバイス上のディレクトリを参照するようJMSサーバーのページング・ディレクトリを構成すると、多くの場合、JMSメッセージ(永続または非永続)のページングのパフォーマンスを向上させることができます。これは、他のテクノロジよりも大幅に速い可能性があります。

ノート:

ほとんどのフラッシュ・ストレージ・デバイスは単一障害点で、通常、ローカル・デバイスとしてのみアクセス可能です。障害の後にデータをリカバリしたり、必要に応じて自動的に再構築したりしないJMSサーバーのページング・ディレクトリとしては適しています。

安全にリカバリできる必要のあるデータが通常含まれるカスタム・ストアやデフォルト・ストアとしては、ほとんどの場合、フラッシュ・ストレージ・デバイスは適していません。デフォルト・ストアまたはカスタム・ストアのDirectory属性の構成で、通常は単一障害点のデバイス上のディレクトリを参照しないようにします。

フラッシュ・ストレージ・デバイスを使用してJMSメッセージをページングするには、次のステップを使用します。

  1. JMSサーバーのメッセージ・ページング・ディレクトリ属性をフラッシュ・ストレージ・デバイスのパスに設定します。「メッセージ・ページング・ディレクトリの指定」を参照してください
  2. 「メッセージ・バッファ・サイズ」属性(ページングのアクティブ化を制御)をチューニングします。高速のI/O処理によって負荷を吸収できる場合、より低いしきい値を使用できます。「「メッセージ・バッファ・サイズ」オプションのチューニング」を参照してください
  3. JMSサーバーの割当てをチューニングし、フラッシュ・ストレージの領域の制限に対応します。これによって、JMSサーバーで、デバイスに格納できる以上のメッセージをページングしなくなります。場合によっては、実行時エラーや自動停止が発生することがあります。控えめな目安として、ページ・ファイルの使用量は、最低1.5 * ((アクティブなメッセージの最大数) * (512 + メッセージ本文の最大サイズ)) (16MB単位で切上げ)と想定します。「割当ての定義」を参照してください。

診断ストアの使用方法

診断ストアは、ファイル・ストアで、暗黙的に「無効化された」同期書込みポリシーを使用します。診断ストアは、WebLogicサーバーの診断情報を格納します。WebLogicサーバーのインスタンスごとに1つの診断ストアが構成されています。『Oracle WebLogic Server診断フレームワークの構成と使用』の診断アーカイブの構成を参照してください。

親トピック: 永続ストアの概要

永続ストア使用時のベスト・プラクティス

WebLogic永続ストアの使用におけるベスト・プラクティスを学習します。

  • 同じサーバー・インスタンスを共有するサブシステムでは、サブシステムごとにストアを使用するのではなく複数のサブシステムで1つのストアを共有します。ストアを共有すると、次の理由から効率性が高まります。

    • 同時発生する複数のリクエストを1つのストアで1つのI/Oにまとめることで、全体のディスク使用率が減少します。

    • 参加するリソースが1つだけのトランザクションは軽量の1フェーズ・トランザクションです。逆に、複数のストアが関与するトランザクションは、より重い2フェーズ・トランザクションになります。

    たとえば、同じサーバー・インスタンスで動作するすべてのSAFエージェントやJMSサーバーは、同じストアを共有するように構成します。

  • 古いストア(群)を拡張しなくなった場合にのみ、新しいストアを追加します。

親トピック: WebLogic永続ストアのチューニング

JDBCストアのチューニング

JDBCストアのチューニングに関する情報を確認します。

  • デフォルトで、WebLogic JDBCストア・インスタンスは、データ・ソースから2つのJDBC接続を取得し、その存続期間中はこれらの接続をキャッシュします。JDBCストアは、接続が失敗した場合により頻繁に再試行するようにチューニングすることができます。また、データ・ソースはテスト接続でチューニングする必要があります。WebLogic永続ストアの管理のJDBCストアの使用を参照してください。

  • JDBCストアのI/O負荷が高い場合、複数のJDBC接続を使用してI/O操作を同時に処理するようJDBCストアを構成すると、パフォーマンスが向上します。『WebLogic永続ストアの管理』のJDBCストアのI/Oマルチスレッドの有効化に関する項を参照してください。

  • Oracle BLOBを使用する場合、ThreeStepThreshold値をチューニングすると、パフォーマンスが向上することがあります。『WebLogic永続ストアの管理』のOracle BLOBレコード列の有効化に関する項を参照してください。

  • 空のストアを初期化するために使用されるJDBCストアDDLの場所は、構成できるようになっています。これにより、データベース表を作成するためのカスタムDDLを簡単に使用できるようになっています。このDDLはデータベースの特定のパフォーマンス・チューニングに使用されることもあります。『Oracle WebLogic Server Administration Consoleオンラインヘルプ』のJDBCストアの作成に関する項と、『WebLogic永続ストアの管理』のWebLogic永続ストアの使用に関する項を参照してください。

親トピック: WebLogic永続ストアのチューニング

ファイル・ストアのチューニング

ファイル・ストアのチューニングについて学習します。

親トピック: WebLogic永続ストアのチューニング

基本的チューニング情報

次の項では、ファイル・ストアのチューニングに関する一般的な情報を提供します。

  • ファイル・ストアのディレクトリの場所を構成する際は注意してください。

    • 最適なパフォーマンスを得るため、ページング・ストアはローカル・ディスク上の場所を参照するようにする必要があります(ページング・ストアは失敗後に再ロードされないため、高可用性のストレージ上に配置する必要はありません)。

    • 別のマシンやJVMに移行する可能性があるカスタムまたはデフォルトのファイル・ストアは、共有される場所にアクセス可能なディレクトリを参照するように構成する必要があります。

    • 『Oracle WebLogic Server JMSリソースの管理』の高可用性のベスト・プラクティスに関する項を参照してください。

    • 『WebLogic永続ストアの管理』のファイルの場所に関する項を参照してください。

  • 基本的な(非RAIDの)ディスク・ハードウェアの場合、ファイル・ストアごとに1つの専用のディスクを使用することを検討します。ディスク上の別のストアと競合しなくてよい場合、ストアの処理速度は4 - 5倍上昇します。構成された各ストアや各JMSサーバー用のJMSページング・ストアの他に、デフォルト・ファイル・ストアがあることに留意してください。

  • カスタムとデフォルトのファイル・ストアの場合は、同期書込みポリシーをチューニングします。

    • 「直接書込み - キャッシュあり」、「直接書込み」および「キャッシュ・フラッシュ」の3つのトランザクションの安全な同期書込みポリシーがあります。「直接書込み - キャッシュあり」は、これらのポリシーのうち最もパフォーマンスがよく、「キャッシュ・フラッシュ」は、最もパフォーマンスの悪いポリシーです。「直接書込み」は、デフォルトです。他のポリシーとは異なり、「直接書込み - キャッシュあり」は、プライマリ・ファイルに加えてキャッシュ・ファイルを作成します。

    • 「無効化された」同期書込みポリシーは、トランザクションで安全ではありません。「無効化された」書込みポリシーを使用すると、特にクライアント負荷が低いときに、パフォーマンスを大幅に向上します。ただし、書込みポリシーは、システムの開始時および停電のときに非同期になって、データが失われる可能性があるので、安全ではありません。

    • 『WebLogic永続ストアの管理』の同期書込みポリシーの構成のガイドラインに関する項を参照してください。

    ノート:

    以前のバージョンのMicrosoft Windowsでは、WindowsのデフォルトのWrite Cache Enabled設定を使用すると、ストレージ・デバイスの同期書込みの完了は正しく報告されません。システム・クラッシュや停電が発生したときは、レコードやメッセージが失われたり、重複されたりするからです。これにより、直接書込み(デフォルト)または直接書込み - キャッシュありポリシーで構成されたファイル・ストアを含む、トランザクション製品(Oracleに固有でない)のトランザクション・セマンティクスが違反されます。ストレージ・デバイスの物理的な機能を超える高い永続メッセージ/トランザクション・スループットの場合、この問題が現れます。この問題を対処するには、Microsoftが提供するパッチを適用するか、WindowsのWrite Cache Enabled設定を無効にするか、または電源保護のあるストレージ・デバイスを使用します。

  • ベンダーを直接的に比較する場合、永続ストアの書込みポリシーをすべて同等のポリシーにします。WebLogic以外の一部のベンダーには、デフォルトで「無効」に相当する動作をするものがあります。

  • 同期書込みポリシーに応じて、カスタム・ストアとデフォルト・ストアには、複数の追加のチューニング可能な属性があります。これにより、パフォーマンスが向上する可能性があります。これには、CacheDirectory、MaxWindowBufferSize、IOBufferSize、BlockSize、InitialSizeおよびMaxFileSizeなどがあります。Oracle WebLogic Server MBeanリファレンスのJMSFileStoreMBeanに関する項を参照してください。

    ノート:

    JMSFileStoreMBeanは非推奨ですが、個別のbean属性が、カスタムとデフォルト・ファイル・ストアの非推奨ではないbeansに適用されます。

  • ディスク・パフォーマンスがボトルネックの状況が続く場合、組込みのライトバック・キャッシュを備えたディスク・コントローラ・ハードウェアまたはRAIDコントローラ・ハードウェアの購入を検討します。これらのキャッシュで一時的に永続データを揮発性のメモリーへ保存すると、大幅にパフォーマンスが向上します。ライトバック・キャッシュでのトランザクションを確実に安全なものにするには、ライトバック・キャッシュを停電、ホスト・マシン障害、およびオペレーティング・システム障害から保護する必要があります。このような保護機能は通常、バッテリ・バックアップのあるライトバック・キャッシュで提供されます。

親トピック: ファイル・ストアのチューニング

ファイル・ストアの直接書込み - キャッシュありポリシーのチューニング

「直接書込み - キャッシュあり」同期書込みポリシーは、通常最もパフォーマンスのよいオプションで、トランザクション上安全なディスク書込みが行われます。通常は、「無効」同期書込みポリシーほどパフォーマンスはよくありませんが、「無効」ポリシーは、システム障害の発生時にバッファされた書込みが失われないようにする方法がない場合、本番システムに対して安全なオプションではありません。

直接書込み - キャッシュありファイル・ストアは、ファイル・ストアの構成のDirectory属性で定義された場所に格納される一連のプライマリ・ファイルに同期して書込みます。また、ファイル・ストアは、ファイル・ストアの構成のCacheDirectory属性で定義された場所にある、対応するキャッシュ・ファイルにも非同期に書込みます。キャッシュ・ディレクトリとプライマリ・ファイルは、別々の目的に使用され、異なる場所に存在する必要があります。多くの場合は、プライマリ・ファイルは、高可用性のためにリモート記憶域に格納されている必要があります。キャッシュ・ファイルは、高可用性ではなく、厳密にパフォーマンスのために使用されるので、ローカルな場所に格納できます。

「直接書込み - キャッシュあり」同期書込みポリシーを選択すると、次の複数の追加のチューニング・オプションを考慮する必要があります。

  • CacheDirectoryの設定。パフォーマンスのためにキャッシュ・ディレクトリがローカルなファイル・システムに存在する必要があります。デフォルトでは、オペレーティング・システムのtempディレクトリに存在しています。

  • MaxWindowBufferSizeおよびIOBufferSize属性の増加。これらの属性は、ファイル・ストアのネイティブなメモリー使用量をチューニングします。

  • InitialSizeおよびMaxFileSize属性の増加。これらの属性は、それぞれストアの初期サイズとストア内の特定のファイルの最大サイズをチューニングします。

  • BlockSize属性のチューニング。「ファイル・ストアのブロック・サイズのチューニング」を参照してください

個別のチューニング・パラメータの詳細は、Oracle WebLogic Server MBeanリファレンスのJMSFileStoreMBeanに関する項を参照してください。

親トピック: ファイル・ストアのチューニング

フラッシュ・ストレージの使用によるパフォーマンスの向上

エンタープライズクラスのフラッシュ・ドライブを使用すると、リアルタイム・アプリケーションでのデータのアクセスが回転式ディスクより大幅に速くなり、他のタスクの処理にメモリーを使用できるため、I/Oのパフォーマンスを向上させることができます。

単に、フラッシュ・ストレージ・デバイスのパスを使用してCacheDirectory属性を更新するのみです。ストアのプライマリ・ファイルの完全なコピーを格納するのに十分な空き領域が、デバイスにあることを確認します。Oracle WebLogic Server MBeanリファレンスのCacheDirectory属性に関する項を参照してください。

追加の考慮事項

直接書込み - キャッシュありポリシーをチューニングする際には、次の項目を考慮する必要があります。

  • 直接書込み - キャッシュあり同期書込みポリシーを使用する場合は、さらにセキュリティおよびファイル・ロッキングの考慮事項がある場合があります。『Oracle WebLogic Server本番環境の保護』、およびOracle WebLogic Server MBeanリファレンスのJMSFileStoreMBeanに関する項のCacheDirectory属性とLockingEnabled属性を参照してください。

    • JMSFileStoreMBeanは非推奨ですが、個別のbean属性が、カスタムとデフォルト・ファイル・ストアの非推奨ではないbeansに適用されます。

  • ストアが実行されていないときにキャッシュ・ディレクトリを削除すると安全ですが、次回ストアを起動するときに時間がかかる場合があります。ストアのホストWebLogicサーバーが(kill -9の後でもOS/JVMのクラッシュの後でもなく)現在の起動の前に正常にシャットダウンされた場合かつプライマリ・ファイル(たとえば、ストアの管理圧縮ファイル)にオフライン変更がなかった場合は、キャッシュ・ファイルを再利用して、ファイル・ストアの起動とリカバリ・プロセスを迅速化することができます。既存のキャッシュ・ファイルを起動するときに安全に使用できない場合、それらは自動的に破棄されて新しいファイルが作成されます。また、「ログ280102」という警告が作成されます。移行またはフェイルオーバーのイベント後、同じ警告メッセージが作成されますが、無視できます。

  • 直接書込み - キャッシュありファイル・ストアを使用して、wlfileioのネイティブ・ドライバのロードに失敗した場合、同期書込みポリシーは自動的に同等の直接書込みに変更され、AvoidDirectIO=trueになります。実行中のカスタムまたはデフォルトのファイル・ストアの構成済および実際の同期書込みポリシーとドライバを表示する場合は、サーバーのログでWL-280008およびWL-280009のメッセージを参照してください。

  • 未使用のキャッシュ・ファイルがディスク領域を消費しないようにする場合、一時的に作成されたドメインに残されたキャッシュ・ファイルを定期的に削除するようにテスト環境と開発環境を変更する必要がある場合があります。本番環境では、ファイル・ストアによってキャッシュ・ファイルが自動的に管理されます。

ファイル・ストアの直接書込みポリシーのチューニング

ノート:

この項に記載されているAvoidDirectIOのプロパティは、このリリースでもサポートされていますが、11gR1PS2以降は非推奨になります。「直接書込み」ポリシーの代替として、構成可能な「直接書込み - キャッシュあり」同期書込みポリシーを使用してください。

直接書込みの同期書込みポリシーによるファイル・ストアの場合は、Oracleサポートまたはリリース・ノートにおいて、weblogic.Serverのオプションをコマンド行設定するか、またはストアを実行するJVMのスクリプトを起動するように指示されます。

  • JVMで実行しているすべてのストアをグローバルに変更します。

    -Dweblogic.store.AvoidDirectIO=true

  • シングル・ストアの場合に使用します。ここでは、store-nameは、ストアの名前を示します。 

    -Dweblogic.store.store-name.AvoidDirectIO=true

  • デフォルトのストアの場合に使用します。ここでは、server-nameは、ストアをホストするサーバーの名前を示します。 

    -Dweblogic.store._WLS_server-name.AvoidDirectIO=true

AvoidDirectIOを個別のストアに設定すると、グローバルなオプションの-Dweblogic.store.AvoidDirectIOの設定がオーバーライドされます。たとえば、AおよびBという2つのストアがあり、次のオプションを設定しているとします: 

-Dweblogic.store.AvoidDirectIO=true
-Dweblogic.store.A.AvoidDirectIO=false

この場合、ストアBの場合のみAvoidDirectIO=trueの設定があります。

ノート:

AvoidDirectIOオプションを設定すると、パフォーマンスに影響を及ぼします。これは、「ファイル・ストアのブロック・サイズのチューニング」に記載されているように、通常、ブロックのサイズを設定すると軽減されます

親トピック: ファイル・ストアのチューニング

ファイル・ストア・ブロック・サイズのチューニング

特にファイル・ストアの直接書込みポリシーのチューニングに記載されているように、直接書込みをAvoidDirectIO=trueで使用する場合、または物理記憶域待機時間によりパフォーマンスが限定されているハードライブ・ベースのライト・バック・キャッシュを持つシステムの場合は、同期書込みポリシーの直接書込み(デフォルト)、直接書込み - キャッシュありまたはキャッシュ・フラッシュを使用して構成されたファイル・ストアのファイル・ストア・ブロック・サイズをチューニングしてください。

次のケースについて検討します。

  • 単一のWebLogic JMSプロデューサは永続メッセージを1つずつ送信します。

  • ネットワークのオーバーヘッドは、ごくわずかであることが分かっています。

  • ファイル・ストアのディスク・ドライブの回転速度は10,000 rpmです。

  • ディスク・ドライブはバッテリ・バックアップのあるライトバック・キャッシュを備えています。

また、メッセージ・レートは1秒間に166メッセージと測定されています。

このケースでは、バッテリ・バックアップのあるライトバック・キャッシュによって高いメッセージ・レートが可能なように思われますが、実際のレートは低く、ディスク・ドライブの待機時間(10,000 rpm/60秒、つまり166 rps)と同じ数値になります。ストアのブロック・サイズをファイル・システムのブロック・サイズと一致するようチューニングすることで、大幅な改善が可能です。

以下のようなケースでは、ブロック・サイズをチューニングしても全く改善が見られなかったり、改善したとしても不十分であったりする可能性があります。

  • キャッシュによって待機時間が小さくなっています(つまり、I/Oサブシステムは重大なボトルネックではありません)。

  • ライトバック・キャッシングが使用されておらず、ディスク・ドライブの待機時間が大きいため、パフォーマンスが制限されています。

使用しているブロック・サイズが大きい場合は、パフォーマンスとファイル・スペースの間にトレード・オフが存在する可能性があります。複数のアプリケーション・レコードは、同時に書き込まれた場合にのみ、単一のブロックにまとめられます。そのためブロック・サイズを大きくすると、サーバー・アクティビティが同時に実行されることがほとんどなく、小さいレコードしか生成されないアプリケーションの場合、ストア・ファイルのサイズが大幅に増大することになります。この場合、小さいレコードがブロックごとに1つずつ格納され、各ブロックの残りのスペースは使用されません。例として、100バイト長の小さなメッセージを送信する単一のプロデューサを含む、Web Service Reliable Messaging (WS-RM)アプリケーションが挙げられます。ここでは、ストアを使用するのはアプリケーションだけです。

パフォーマンスを向上するために、ストアのブロック・サイズをファイル・ストアをホストするファイル・システムのブロック・サイズと一致するように、チューニングすることをお薦めします(一般的に、多くのファイル・システムの場合、4096)。または、ブロック・サイズをその他の値にチューニングしても(ページングおよびキャッシュ・ユニット)パフォーマンスを向上する場合があります。ブロック・サイズをチューニングして、パフォーマンスが向上されない場合、ブロック・サイズをデフォルトのままに設定しておくことをお薦めします。これにより、ファイル・システム・リソースの使用を最小化することができます。

親トピック: ファイル・ストアのチューニング

ファイル・ストアのブロック・サイズの設定

ノート:

この項に記載されているBlockSizeコマンド行プロパティは、11gR1PS2でもサポートされていますが、非推奨です。かわりに、カスタムおよびデフォルトのファイル・ストアに構成可能なBlockSizeを使用することをお薦めします。

ストアのブロック・サイズを設定するには、次のいずれかのプロパティをコマンド行で使用するか、または、ストアを実行するJVMのスクリプトを起動してください。

  • 既存するファイルを持たないすべてのファイル・ストアのブロック・サイズをグローバルに設定します。

    -Dweblogic.store.BlockSize=block-size

  • 既存のファイルを持たない特定のファイル・ストアのブロック・サイズを設定します。

    -Dweblogic.store.store-name.BlockSize=block-size

  • ファイル・ストアに既存のファイルがない場合、デフォルトのファイル・ストアのブロック・サイズを設定します。

    -Dweblogic.store._WLS_server-name. BlockSize=block-size

ブロック・サイズは、512から8192の間の整数を設定します。最も近い2の倍数に自動的に切り捨てられます。

BlockSizeを個別のストアに設定すると、グローバルなオプションの-Dweblogic.store.BlockSizeの設定がオーバーライドされます。たとえば、AおよびBという2つのストアがあり、次のオプションを設定しているとします: 

-Dweblogic.store.BlockSize=8192
-Dweblogic.store.A.BlockSize=512

この場合、ストアBのブロック・サイズは、8192になり、ストアAのブロック・サイズが512になります。

ノート:

コマンド行プロパティを使用したブロック・サイズの設定は、既存のファイルを持たないファイル・ストアでのみ可能です。ストアに既存のファイルが存在する場合は、ストアの最初の作成時に設定されたブロック・サイズがそのまま使用されます。

ファイル・ストア・ブロック・サイズの確認

ファイル・ストアの現在のブロック・サイズおよび同期書込みポリシーは、ストアをホストするサーバーのサーバー・ログで確認することができます。「280009」のストアがオープンされたというメッセージを検索してください。

ファイル・システム・ブロック・サイズの確認

ファイル・システムの現在のブロック・サイズを確認するには、使用しているオペレーティング・システムのドキュメントを参照してください。たとえば:

  • Linux ext2およびext3ファイル・システムの場合: /sbin/dumpe2fs /dev/ボリューム名を実行し、「Block size」を検索します。

  • Windows NTFSの場合: fsutil fsinfo ntfsinfo ボリューム名:を実行し、「Bytes Per Cluster」を検索します。

既存のファイルが存在するストアの変換

ストアの既存のファイルのデータを保持する必要がない場合は、ホストのWebLogic Serverインスタンスを停止してファイルを削除すれば、ストアを再起動した際にブロック・サイズを変更できます。データを保持する必要がある場合は、新しいブロック・サイズを指定したファイル・ストアを作成して、既存のファイルが存在するストアのブロック・サイズを変換します。その際は、コマンド行ストア管理ユーティリティのcompactコマンドを使用します。

  1. java -Dweblogic.store.BlockSize=block-size weblogic.store.Admin
  2. helpと入力して、使用可能なコマンドを確認します。
  3. Storeadmin->compact -dir file-store-directory

『WebLogic永続ストアの管理』のJavaコマンドラインを使用したストア管理に関する項を参照してください。

ネットワーク・ファイル・システムの使用

ネットワーク・ファイル・システム(NFS)でのWebLogic永続ストアの使用方法について学習します。

親トピック: WebLogic永続ストアのチューニング

同期書込みポリシーの構成

NFS記憶域は、同期書込みリクエストが揮発性メモリーに警告なしでバッファされるように構成されているので、トランザクション・データを完全に保護しない場合があります。ファイル・ストアのディレクトリがNFSマウントに存在して、ファイル・ストアの同期書込みポリシーが「無効化された」以外である場合、NFS実装と構成をチェックして、同期の書込みがサポートされるように構成されていることを確認します。「無効化された」の同期書込みポリシーを使用すると、同期書込みが行われていないので、一般的にはトランザクションで安全ではありません。記憶域デバイスの物理機能を超える最大数の永続メッセージまたはトランザクション・スループットを表示すると、同期書込みリクエストの不要なバッファリングが発生する可能性があります。NFSサーバーで、ファイル・ストアをホストするエクスポート済のNFSディレクトリの同期書込み設定をチェックします。SANベースのファイル・ストアまたはJDBCストアでは、安全な集中型の記憶域を提供する簡単な方法が用意されている場合があります。

親トピック: ネットワーク・ファイル・システムの使用

サーバーの再起動の動作のテスト

NFS搭載のディレクトリにJMSメッセージとトランザクション・ログが格納されている場合、マシンが不意に障害したら、サーバーの再起動の動作を検証することをお薦めします。NFS実装に応じて、フェイルオーバーまたは再起動後、様々な問題が発生する可能性があります。Web Logicサーバーの実行中に、Web Logicサーバーをホストするノードを突然にシャットダウンして、動作を検証できます。サーバーの移行のためにサーバーが構成されている場合、対応するフェイルオーバー期間後、フェイルオーバー・ノード上でサーバーが自動的に起動する必要があります。起動しない場合は、同じホスト(ノードが完全に起動した後)上のWebLogicサーバーを手動で再起動します。

親トピック: ネットワーク・ファイル・システムの使用

NFSのロック・エラーの処理

WebLogic Serverは、JMSデータおよびトランザクション・ログの格納に使用されるファイルのロックを保持します。これらのロックは、同じWebLogic Serverまたはファイル・ストアの2つのインスタンスが誤って起動した場合に発生する可能性のあるデータ破損に対する保護を提供します。同じ名前とディレクトリを持つ2つのWebLogicファイル・ストアが誤って起動された場合、または致命的な障害後にOracle WebLogic Serverが再起動しない場合、次のエラーがサーバー・ログ・ファイルに表示されることがあります。

例6-1 ストアの再起動の失敗エラー・メッセージ

<Error> <Store> <BEA-280061> <The persistent store "_WLS_server_soa1" could not be deployed: 
weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file "_WLS_SERVER_SOA1000000.DAT"
at weblogic.store.io.file.Heap.open(Heap.java:168)
at weblogic.store.io.file.FileStoreIO.open(FileStoreIO.java:88)
...
java.io.IOException: Error from fcntl() for file locking, Resource temporarily unavailable, errno=11
同じファイルを使用する2つのファイル・ストアが同時に開始されると、ファイル・ロック・エラーが発生します。次の情報を使用して、エラーを防止または修正できます。
  • 同じ名前の2つの異なるドメインの2つのファイル・ストアが同じディレクトリを使用するように構成されている場合は、WebLogic Serverを停止し、異なるディレクトリを使用するように競合するストアの構成を変更します。WebLogic Serverでは2つのファイル・ストアが同じドメイン内で同じ名前で構成されないようにするため、これは同じドメイン内の2つの異なるファイル・ストアでは発生しません。
  • WebLogicでは、共有永続ストレージの場所を使用している場合、異なるサイトから同じドメインの複数のデプロイメントを開始することはできません。
  • WebLogicでは、共有永続ストレージの場所を使用している場合、異なるサイトから同じ名前の複数の WebLogic Serverを開始することはできません。

ファイル・ロック・エラーは、マシン障害、オペレーティング・システムのクラッシュおよび仮想マシンの破棄後に所有するファイル・ストアが実行されなくなったときに発生する「破棄されたロック」が原因でも発生します。NFSストレージ・デバイスは、問題をすぐには認識しません。結果として、WebLogic Serverによる、以前にロックされたファイルに対するロックの取得の試行が失敗する可能性があります。次の方法で説明するタスクを実行して、ログおよびデータ・ファイルをロック解除できます。

ストレージ・デバイスでNFSにマウントされたディレクトリに格納されているファイルのロックの詳細は、ストレージ・ベンダーのドキュメントを参照してください。

親トピック: ネットワーク・ファイル・システムの使用

方法1 - NFS v3のかわりにNFS v4を使用

破棄されるロックのほとんどは、ハードウェア障害、オペレーティング・システムのクラッシュ、正常に停止できるようにしない仮想マシンの削除などの致命的な障害が発生した場合にファイルをロックしたままにしておくことができるNFS v3ベースのネットワーク接続ストレージ(NAS)を使用することによるものです。

この問題を軽減するために、OracleではNFS v4 NASサーバーを使用することを強くお薦めします。これは、サーバーの再起動または移行の完了に要するおおよその時間内に破棄されたロックを自動的に解放するようにチューニングする必要があり、最も推奨される方法です。

ストレージ・デバイスでNFSにマウントされたディレクトリに格納されているファイルのロックの詳細は、ストレージ・ベンダーのドキュメントを参照してください。

方法2 - データ・ファイルをコピーしてNFSロックを削除

ノート:

このオプションを使用する場合は、十分に注意する必要があります。ファイル・ストアのファイルをコピーする前に、ファイル・ストアを停止することが重要です。そうしないと、ファイルが破損する可能性があります。人為的なエラーが発生しないようにし、コピー中のある時点でファイル・ストアのインスタンスが手動で起動されていないことを確認するために、さらに手続き型の予防措置を実施する必要があります。同じように、同じディレクトリを参照する同じ名前のストアを持つ2つのドメインが存在しないことを確認するためにも、さらに注意を払う必要があります。

デフォルトのストア、ページング・ストアおよびJMSストア・データ・ファイルを手動でロック解除し、最初にファイルを使用している実行中のファイル・ストアがないことを確認してから、ロックされた永続ストア・ファイルのコピーを作成し、そのコピーを後続の操作に使用することでサーバーを開始します。

ロック済の永続ストア・ファイルのコピーを作成するには、ファイルの名前を変更し、再度元の名前にコピーします。次のサンプル・ステップでは、トランザクション・ログが/shared/tlogsディレクトリおよびJMSデータが/shared/jmsディレクトリに格納されると仮定します。

例6-2 NFSロックを削除するためのサンプル・ステップ

cd /shared/tlogs
mv _WLS_SOA_SERVER1000000.DAT _WLS_SOA_SERVER1000000.DAT.old
cp _WLS_SOA_SERVER1000000.DAT.old _WLS_SOA_SERVER1000000.DAT
cd /shared/jms
mv SOAJMSFILESTORE_AUTO_1000000.DAT SOAJMSFILESTORE_AUTO_1000000.DAT.old
cp SOAJMSFILESTORE_AUTO_1000000.DAT.old SOAJMSFILESTORE_AUTO_1000000.DAT

mv UMSJMSFILESTORE_AUTO_1000000.DAT UMSJMSFILESTORE_AUTO_1000000.DAT.old
cp UMSJMSFILESTORE_AUTO_1000000.DAT.old UMSJMSFILESTORE_AUTO_1000000.DAT

この方法では、WebLogicのファイル・ロック・メカニズムは、同じサーバーの複数のインスタンスが誤って起動されたときにデータが障害されないように、データの保護を続行します。ただし、マシンが突然の障害で停止したときは、サーバーを手動で再起動する必要があります。また、ファイル・ストアでは、ファイル・ストアを使用して大量のデータを格納する場合、複数のnumbered.DATファイルが作成されます。この場合は、すべてのファイルをコピーし、名前を変更する必要があります。

方法3 - WebLogic Serverのファイル・ストア内のファイル・ロックの無効化

ノート:

この方法を使用すると、WebLogic Serverのロックが無効になっているので、自動サーバーを再起動して、フェイルオーバーに成功することが予想されます。ただし、このオプションを使用する場合は、十分に注意する必要があります。WebLogicのファイル・ロック機能は、並行性シナリオで発生するサーバー・ファイルの破損を避けるように設計されています。
次の前提条件により、ファイル・ロックを無効にするリスクが軽減されます。
  • ファイル・ストアを使用するサーバーは、サーバーの移行のために構成されている場合、データベースに基づくリース・オプションを構成します。これにより、データベース表を使用して追加のロック・メカニズムが実行され、同じWebLogic Serverの複数のインスタンスが自動的に再起動するのを防ぎます。
  • 自動サービス移行(ASM)を使用しているファイル・ストアでは、ファイル・ロックを無効にしないでください。
    • ASMは、安全に機能するためにファイル・ストア・ロックを必要とし、次のシナリオでアクティブ化されます。
      1. カスタム・ファイル・ストア・ターゲットが移行可能ターゲットに設定され、移行可能ターゲットが手動(デフォルト)以外の移行ポリシーを使用して構成されます。
      2. ストアが「オフ」(デフォルト)以外の移行ポリシーで構成されている場合、カスタム・ファイル・ストア・ターゲットはWebLogicクラスタに設定されます。
      3. WebLogic Serverは、手動(デフォルト)以外の移行ポリシー値を持つJTA移行可能ターゲットで構成されます。これは、デフォルトのファイル・ストアの移行につながる可能性があるためです。
    • ASMとファイル・ロックの無効化の両方が必要な場合は、ファイル・ストアではなくデータベース・ストアに重要なデータを格納して、ファイルの破損のリスクを回避します。たとえば、ファイル・ストアのかわりにカスタムJDBCストアを使用し、各WebLogic Serverのデフォルト・ファイル・ストアのかわりにJDBC TLOGストアを使用するようにJTAを構成します。
  • 人為的なエラーが発生しないようにし、ある時点でサーバーのインスタンスが1つのみ手動で起動されたことを確認するために、さらに手続き型の予防措置を実施する必要があります。同じように、同じディレクトリを参照する同じ名前のストアを持つ2つのドメインが存在しないことを確認するためにも、注意を払う必要があります。

次の各項に記載されているように、システム・プロパティまたはWebLogic Server構成を使用して、デフォルトのファイル・ストア、カスタム・ファイル・ストア、JMSページング・ファイル・ストアおよび診断ファイル・ストアのWebLogicファイル・ロック・メカニズムを無効化できます。

システム・プロパティを使用したすべてのストアのファイル・ロックの無効化

WebLogic Server 14.1.2リリース以降では、次に示すように、weblogic.Serverコマンド・ラインでJavaシステム・プロパティを指定するか、JVMの起動スクリプトを指定して、デフォルト、ページング、診断およびカスタム・ファイル・ストアを含むすべてのファイル・ストアのロックを無効にできます。

"-Dweblogic.store.file.LockEnabled=false"

デフォルトのファイル・ストアのファイル・ロックの無効化

WebLogic Server管理コンソールを使用してデフォルトのファイル・ストアのファイル・ロックを無効にするには、次のステップに従います。

  1. 必要に応じて、WebLogic Server管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。
  2. 「ドメイン構造」ツリーで、「環境」ノードを開いて「サーバー」を選択します。
  3. 「サーバーのサマリー」リストで、変更するサーバーを選択します。
  4. 「構成」>「サービス」タブを選択します。
  5. 「デフォルト・ストア」のセクションへスクロール・ダウンし、「詳細」をクリックします。
  6. スクロール・ダウンし、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。
  7. 「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
  8. 変更したサーバーを再起動して、変更を反映します。
結果のconfig.xmlエントリは、次のようになります。

例6-3 デフォルトのファイル・ストアのファイル・ロックを無効化するconfig.xmlのエントリの例

<server>
<name>examplesServer</name>
...
<default-file-store>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
</default-file-store>
</server>
カスタム・ファイル・ストアのファイル・ロックの無効化

WebLogic Server管理コンソールを使用してカスタム・ファイル・ストアのファイル・ロックを無効にするには、次のステップに従います。

  1. 必要に応じて、WebLogic Server管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。
  2. 「ドメイン構造」ツリーで、「サービス」ノードを拡張し、「永続ストア」を選択します。
  3. 「永続ストアのサマリー」リストで、変更するカスタム・ファイル・ストアを選択します。
  4. カスタム・ファイル・ストアの「構成」タブで、「詳細」をクリックすると、ストアの詳細設定が表示されます。
  5. ページの下部にスクロール・ダウンし、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。
  6. 「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
  7. カスタム・ファイル・ストアが使用中であった場合、変更を反映するには、サーバーを再起動する必要があります。
結果のconfig.xmlエントリは、次のようになります。

例6-4 カスタム・ファイル・ストアのファイル・ロックを無効化するconfig.xmlのエントリの例

<file-store>
<name>CustomFileStore-0</name>
<directory>C:\custom-file-store</directory>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
<target>examplesServer</target>
</file-store>
JMSページング・ファイル・ストアのファイル・ロックの無効化

WebLogic Server管理コンソールを使用してJMSページング・ファイル・ストアのファイル・ロックを無効にするには、次のステップに従います。

  1. 必要に応じて、WebLogic Server管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。
  2. 「ドメイン構造」ツリーで、「サービス」ノードを拡張し、「メッセージング」ノードを拡張して、「JMSサーバー」を選択します。
  3. 「JMSサーバーのサマリー」リストで、変更するJMSサーバーを選択します。
  4. JMSサーバーの「構成」>「一般」タブで、スクロール・ダウンして、「ページング・ファイル・ロックの有効化」チェック・ボックスを選択解除します。
  5. 「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
  6. 変更したサーバーを再起動して、変更を反映します。
結果のconfig.xmlエントリは、次のようになります。

例6-5 JMSページング・ファイル・ストアのファイル・ロックを無効化するconfig.xmlのエントリの例

<jms-server>
<name>examplesJMSServer</name>
<target>examplesServer</target>
<persistent-store>exampleJDBCStore</persistent-store>
...
<paging-file-locking-enabled>false</paging-file-locking-enabled>
...
</jms-server>
診断ファイル・ストアのファイル・ロックの無効化

WebLogic Server管理コンソールを使用して診断ファイル・ストアのファイル・ロックを無効にするには、次のステップに従います。

  1. 必要に応じて、WebLogic Server管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。
  2. 「ドメイン構造」ツリーで、「診断」ノードを拡張し、「アーカイブ」を選択します。
  3. 「診断アーカイブのサマリー」リストで、変更するアーカイブのサーバー名を選択します。
  4. [server_name]の設定ページで、「診断ストアのファイル・ロックを有効化」チェック・ボックスを選択解除します。
  5. 「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
  6. 変更したサーバーを再起動して、変更を反映します。
結果のconfig.xmlエントリは、次のようになります。

例6-6 診断ファイル・ストアのファイル・ロックを無効化するconfig.xmlのエントリの例

<server>
<name>examplesServer</name>
...
<server-diagnostic-config>
<diagnostic-store-dir>data/store/diagnostics</diagnostic-store-dir>
<diagnostic-store-file-locking-enabled>false</diagnostic-store-file-lockingenabled>
<diagnostic-data-archive-type>FileStoreArchive</diagnostic-data-archive-type>
<data-retirement-enabled>true</data-retirement-enabled>
<preferred-store-size-limit>100</preferred-store-size-limit>
<store-size-check-period>1</store-size-check-period>
</server-diagnostic-config>
</server>