メモリー管理のベスト・プラクティス

正常なランタイム環境を維持し、メモリー不足エラーを回避するための、メモリー管理のベスト・プラクティスの概要を説明します。

統合アプライアンスでは、オーケストレーション・ジョブを実行するためのメモリーのプールを確保しておきます。このメモリー・プールの管理は、正常なランタイム環境を維持するために重要です。

使用されるメモリーの量と、ガーベッジ・コレクション・サイクルの間には直接の関係があります。ガーベッジ・コレクションは、完了したジョブおよび変数データによって確保されているメモリーを、すべてのオーケストレーション・ジョブによって使用されるメモリーのプールに戻すプロセスです。このガーベッジ・コレクション・プロセスにより、統合アプライアンスで、新規オーケストレーション・ジョブが使用できる空きメモリーが継続的に提供されるようになります。

ガーベッジ・コレクション (GC) は、オーケストレーション・ジョブのパフォーマンスに影響せずに、バックグラウンドで実行される継続的なプロセスです。しかし、メモリーがクリティカルしきい値に達すると、フル・ガーベッジ・コレクションとして知られる、さらに徹底した処理が行われます。フル・ガーベッジ・コレクション・プロセスは、すべての実行中のジョブをスリープ状態にして、使用されていないメモリーをプールに戻します。フル・ガーベッジ・コレクションの間は、すべてのオーケストレーション・ジョブが停止するため、頻繁にフル・ガーベッジ・コレクションが行われると、オーケストレーションのパフォーマンスに影響する可能性があります。

「リソース使用状況 (Resource Utilization)」グラフ上の「GC アクティビティー (GC Activity)」値が定期的に急増する場合は、メモリーの需要が大きいために、統合アプライアンスが、フル・ガーベッジ・コレクション・サイクルを開始する頻度を上げることによって、その需要に対応しようとしていると考えられます。ただし、メモリー使用量が多い場合に、必ずフル・ガーベッジ・コレクション・サイクルが増加するわけではありません。例えば、実行時間の短いオーケストレーションが多量に行われる場合、使用中のメモリーの割合は大きくなります。しかし、バックグラウンドで常に実行されているガーベッジ・コレクション・サイクルが、メモリーをメモリー・プールに戻す処理を十分に短時間で行い、全体のメモリー使用量がフル・ガーベッジ・コレクションをトリガーするほど多くならない可能性が高くなります。フル・ガーベッジ・コレクションはすべてのオーケストレーションを停止するため、頻繁にフル・ガーベッジ・コレクションが行われると、オーケストレーションのパフォーマンスに影響する可能性があります。

メモリー使用量が多いためにフル・ガーベッジ・コレクション・サイクルが頻繁に発生する可能性の高いシナリオとして、複数のオーケストレーション・タイプの混用が挙げられます。例えば、多数の変数が大規模なオブジェクトを処理する、実行時間が長く永続しない複数のオーケストレーションがある場合などです。このようなタイプのオーケストレーションが、多量のメモリーを消費して拘束すると、そのメモリーが迅速にメモリー・プールに戻されない可能性があります。
注: このようなタイプのオーケストレーションは、Cast Iron® では推奨されません。

次の表に、メモリー使用量を管理し、正常なランタイム環境を維持するために役立つベスト・プラクティスのリストを示します。

表 1. メモリー管理のベスト・プラクティス
ベスト・プラクティスの原則 説明
ロギング・レベルを低くする。 ロギングが詳細になるほど、データの処理と保管に必要なメモリーの量は増え、統合アプライアンス・ディスクでの入出力の負荷も増えるため、パフォーマンスが低下する可能性があります。詳細ロギング・レベルは、デバッグの目的のみに推奨され、大量のデータが処理される実稼働環境では推奨されません。

統合アプライアンスは、システム・ログおよびオーケストレーション・ジョブ・ログを生成します。

Cast Iron では、システム・ログで追跡されるすべてのコンポーネントについて、システム・ログ・レベルを「警告」に設定することを推奨しています。
  • ハードウェア
  • リソース
  • ネットワーク
  • セキュリティー
  • オーケストレーション
  • デプロイメント
各種システム・コンポーネントによって生成された警告の数が多い場合は、メモリー使用量が問題となる可能性があります。警告が生成される原因となっている問題を解決するか、システム・ロギング・レベルを「エラー」に引き上げてください。システム・ログ・レベルの設定について詳しくは、システム・ログ設定の指定を参照してください。

オーケストレーション・ロギング・レベルは、プロジェクト内のオーケストレーションごとに指定されます。Cast Iron では、統合アプライアンス上のすべてのプロジェクトの下にあるすべてのオーケストレーションに対して、ロギング・レベルを「エラー値 (Error Values)」に設定することを推奨しています。オーケストレーション・ログ・レベルの設定について詳しくは、オーケストレーション設定の編集を参照してください。

すべてのオーケストレーションでパーシスタンスが使用可能であることを確認する。 デフォルトでは、オーケストレーションのパーシスタンスが有効になっており、変数データはメモリーではなくディスクに書き込まれます。パーシスタンスを有効にすることで、実行時に障害が発生した場合にポイント・イン・タイム・データ・リカバリーを行うことができるというメリットが得られます。

オーケストレーションのパーシスタンスを無効にした場合、データはメモリーに格納されます。パーシスタンスを無効にすると、パフォーマンスを向上させることができますが、実行中のジョブの数が増えるにつれて、メモリーが不足する可能性も高くなります。メモリー不足になるリスクが大きいため、パーシスタンスを無効にすることを選択した場合は、特別な注意を払って処理を進めてください。

注: パーシスタンスをオフにすると、統合アプライアンスが同時に実行可能なオーケストレーション・ジョブの数が少なくなります。統合アプライアンスで使用可能なメモリーの量によって、制限が設定されます。
Web 管理コンソール (WMC) および Studio で使用可能なスケジューリング機能を使用して、オーケストレーション・ジョブが重ならないように調整する。 メモリーを多く使用するジョブを、異なるタイミングで開始するか、オフピーク時間に実行するようにスケジュールすることによって、メモリーの負荷をある程度軽減し、フル・ガーベッジ・コレクションの回数を減らします。これによりパフォーマンスが向上する可能性があります。

Studio では、「ジョブのスケジュール」アクティビティーを使用するか、オーケストレーションでのアクティビティーのポーリング間隔を構成することで、オーケストレーション・ジョブが重ならないように調整し、リソースの使用率を最大にすることができます。WMC でスケジュールを作成して、統合アプライアンスがいつオーケストレーション・ジョブを実行するかを制御することもできます。ジョブのスケジュールを最適化することができるように、所定のオーケストレーション・ジョブの平均実行時間を測定してください。

オーケストレーションで使用される変数の数を最小限にする。 オーケストレーションで使用する変数の数が多くなるほど、データを格納するために必要なメモリーの量が増えます。すると、それにより、ガーベッジ・コレクション・サイクルの数が増え、パフォーマンスに影響する可能性があります。オーケストレーションを見直し、使用される変数の数を減らすことができるかどうかを調べてください。
同時に実行されるジョブの数を減らす。 WMC では、オーケストレーションの、同時に実行されるジョブの最大数を指定することができます。同時に実行されているオーケストレーションの数が増えると、メモリーの使用率も増加します。メモリーが過負荷になりつつあることに気付いたら、同時に実行されているジョブの数を減らしてください。

同時に実行されるジョブの数を減らすと、多数の変数を含む実行時間の長い非永続オーケストレーション・ジョブの場合に、顕著な効果があります。

注: このようなタイプのオーケストレーションは、Cast Iron では推奨されません。
メモリーの負荷が 75% を超えないようにする。 WMC の「リソース使用状況 (Resource Utilization)」グラフで、使用されているメモリーの割合を追跡することができます。使用中のメモリーの割合がおよそ 75% 以下である場合、統合アプライアンスには、さらにオーケストレーションを処理できるだけの容量があります。使用中のメモリーの割合がおよそ 75% を超えた場合、フル・ガーベッジ・コレクションの回数が増えるため、パフォーマンス上の問題が認められる可能性が高くなります。
フル・ガーベッジ・コレクション・サイクルを制限する。 WMC の「リソース使用状況 (Resource Utilization)」グラフで、「GC アクティビティー (GC Activity)」の値を使用して、フル・ガーベッジ・コレクションの割合を追跡することができます。この割合が 50% を超えた場合、オーケストレーション・ジョブのスループットの減少が見られる可能性があります。メモリー管理のベスト・プラクティスを実施して、メモリー使用量を削減し、それによってフル・ガーベッジ・コレクション・サイクルが発生する可能性を低くします。
ご使用の環境に統合アプライアンスをさらに追加する。 ベスト・プラクティスの原則を実施した後も、依然としてメモリー使用量が多い場合は、ご使用の環境に統合アプライアンスをもう 1 つ追加することが選択肢として考えられます。



フィードバック | 特記事項


タイム・スタンプ・アイコン 最終更新: 2013年11月7日 (木曜日)


http://pic.dhe.ibm.com/infocenter/wci/v7r0m0/topic/com.ibm.wci.appliance.doc/Best_Practices/best_practices.html