スロットル・メカニズムを通じたRational Build Forgeのリソース使用率の制御

IBM Rational Build Forgeには、一時点における処理量を制御するための複数の方法があります。管理コンソールがシステム全体に及ぼす影響を制限するため、あるいはシステムがより多くの処理を許容できるのであれば処理量を増やすために、これらのメカニズムを使用します。グローバル・レベル、プロジェクト・レベル、およびサーバー・レベル、の3つのレベルでスロットルを適用できます。

Kristofer Duer, IBM Software Group, Rational BuildForge Level 3 Developer Software Developer : Rational Software Configuration Management, IBM

DUER, KRISTOFER A. (KRIS)
IBM Software Group, Rational BuildForge Level 3 Developer Software Developer : Rational Software Configuration Management



2011年 6月 17日

IBM Rational Build Forgeには、一時点における処理量を制御するための複数の方法があります。管理コンソールがシステム全体に及ぼす影響を制限するため、あるいはシステムがより多くの処理を許容できるのであれば処理量を増やすために、これらのメカニズムを使用します。グローバル・レベル、プロジェクト・レベル、およびサーバー・レベル、の3つのレベルでスロットルを適用できます。

当記事は以下のトピックをカバーします。

グローバル・レベル・スロットル

  • AutoCleanログ設定
  • データベース・サイズしきい値 および データベース・サイズしきい値の通知
  • コンソール・プロセスの最大数
  • 実行キュー・サイズ
  • 最大同時パージ数
  • 最大同時サーバー・テスト数

プロジェクト・レベル・スロットル

  • 実行上限数
  • 最大スレッド

サーバー・レベル・スロットル

  • 最大ジョブ数
  • command_output_cache

内部スロットル・メカニズム

  • purge_log_count
  • Perlロギング内部制御
  • db_pool

グローバル・レベル・スロットル

グローバル・レベル・スロットルは、Rational Build Forgeシステム全体に作用します。これらのスロットルに高すぎる値を設定すると、ホスト・システムに適切でない負荷を与えてしまいます。これらのスロットルに低すぎる値を設定するとRational Build Forgeが同時処理可能なアクションの数が減ってしまいます。

グローバル・レベル・スロットルにアクセスするには管理コンソールの「管理」>「システム」に遷移します。いくつかのスロットルはデータベースを直接操作する必要があります。

注:内部スロットルの変更は、原則IBMラショナル・カスタマー・サポートの指示により実施してください。万が一ユーザー組織の判断で実施する場合は細心の注意を払ってください。

AutoCleanログ設定

AutoCleanログ設定はデフォルトで非常に高い価に設定されています。その結果、Rational Build Forgeは大量のシステム・メッセージをデータベースに格納します。ユーザー組織のユースケースに合うようにこれらの値を変更してください。AutoCleanログ設定に関するパラメーターは4つあります:

AutoClean監査ログ日数
監査メッセージは、Build Forge成果物への変更と管理メッセージを出力します。典型的なシステムでは、監査メッセージはすべてのメッセージ数の20%を占めます。デフォルトの設定は365日です。

AutoCleanエラー・ログ日数
エラー・メッセージは、例えばエンジンがメール通知を送信できなかった場合など、エンジンがあるタスクを完了できない場合に出力されます。これらのメッセージは一般的にすべてのメッセージ数の1%未満を占めます。デフォルトの値は0で、システムが永久にメッセージを削除しないことを意味します。このメッセージのインパクトは非常に少ないことから、この値は0のままにしておくことをお勧めします。

AutoClean情報ログ日数
情報メッセージは、すべてのメッセージ数のおよそ70%を占めます。この設定が環境へのインパクトが最も高いです。デフォルトの値は120日であり、ほとんどのユーザー組織にとって長すぎます。一般的には、この値を7日から14日に設定するべきです。

AutoClean警告ログ日数
警告メッセージは、すべてのメッセージ数のおよそ10%を占めます。デフォルトでは、これらのメッセージも、AutoClean情報ログ日数同様、デフォルトで120日保存されます。しかしそのインパクトは情報メッセージに比べて非常に少ないです。

データベース・サイズしきい値およびデータベース・サイズしきい値の通知

これらの設定は早期の警告システムとして機能します。Rational Build Forgeはデータベースがデータベース・サイズしきい値に設定したディスク・サイズを超えると、データベース・サイズしきい値の通知に指定されたアドレスへ通知を送信します。

データベース・サイズしきい値のデフォルト値は2GBで、ほとんどのRational Build Forge環境において小さすぎる値です。この値をデータベースのデータ・ファイルが使用可能なディスク・スペースの最大値の80%に設定してください。この値を使用することにより、ディスク・スペース不足になる前に是正処置を講じる時間を確保できます。

コンソール・プロセスの最大数

この設定はコンソールが一時点で実行するプロセスの最大数を制御します。バージョン7.1.2では、buildforge.exeとbfproject.exeのみがコンソールによって起動されるプロセスであると認識されます。 最適な稼動には、次に説明する実行キュー・サイズより少なくとも1大きい値を使用します。この設定のデフォルト値は25です。

実行キュー・サイズ

この設定は同時にいくつの個別のビルドを実行できるかを制御します。この値が低すぎるとコンソールがプロジェクトを並列に処理する能力を活かしきれません。この値が高すぎるとシステムの性能に望ましくない影響が及ぶ可能性があります。デフォルト値の3はどのような環境においても小さすぎる可能性が高いです。Build Forgeシステムで必要な作業を実行できるところまで、もしくはBuild Forgeシステムに過大な負荷をかけてしまうところまで、この値を少しずつ増加します。今までにこの値が設定された範囲は10から200の間でした。選択する値は環境と生成されるビルドの種類に大きく依存します。例えば、100の並列ステップがあるプロジェクトを1つ実行するのは、 10の並列ステップがあるプロジェクトを10実行するのと同様のCPUとメモリーを必要とします。前者の場合、実行キュー・サイズの値が10では高すぎる可能性があります。なぜなら、2例目の場合で実行キュー・サイズの値が100に相当するからです。いずれの場合も、この値を適切に設定するためには環境を理解することが求められます。 値を少しずつ増加させていくアプローチが過去の成功パターンです。5から始め5ずつ増分させていきながら最適な値を決定すると良いでしょう。

最大同時パージ数

この設定はBuild Forge 7.1.2から導入されています。この設定により、いくつのパージ処理のスレッドを同時に実行するかを制御することができます。この数値を高くすればより多くのパージ処理を同時に実行できるようになりますが、ビルドの性能も落ちます。デフォルト値は20です。パージ処理をより厳格に制御するためにより低い値が必要な場合にのみこの設定を変更してください。この設定の代替手段としては、クラスのパージのスケジューリングを検討してください。クラスのパージのスケジューリングの方がパージの環境への影響を大きく削減でき、パージの制御方法としてより望ましいと言えます。

最大同時サーバー・テスト数

Rational Build Forge バージョン7.1.2から、サーバー・テストはJavaのサービス・レイヤーで実行されています。そのため、サーバー・テストはシステム・リソースに対して以前よりはるかに少ないフットプリントで実行されます。結果的に、デフォルト値の6よりも大きな数値を使えるようになりました。一般的には、もし頻繁に再起動するコンピューターが環境に多数ある場合は、より高い値が同時サーバー・テストに必要になります。この場合、持続的にサーバー・テストを実行しRational Build Forgeにサーバーが再びオンラインになったことを伝える必要があります。


プロジェクト・レベル・スロットル

プロジェクトを定義もしくは変更する際に、これらのプロパティーを設定します。

実行上限数

この設定はあるプロジェクトのインスタンスを同時にいくつ実行できるかを決定します。もしプロジェクトを起動して実行中のジョブの数が実行上限数に達していた場合、新たに投入したジョブは少なくともひとつのジョブが完了するまで待ちます。

最大スレッド

プロジェクトの最大スレッド設定はステップの並列実行の制限として作用します。この設定はプロジェクトの中の並列ステップが同時にいくつ実行可能かを制限します。


サーバー・レベル・スロットル

最大ジョブ数

個々のビルド・サーバーは同時にいくつのステップを実行できるかの制限があります。ステップはサーバーにおいてジョブ・スロットに置き換えられます。最大ジョブ数のデフォルト値は3です。しかし、場合によっては、コンピューターが追加の処理を実行できるだけのリソースがあるのであれば、この値を増やすことができます。

ひとつのステップが1/最大ジョブ数よりも多くシステム・リソースを消費する状況においてこの設定は危険性をはらみます。CPUの80%を消費するコンパイル・ステップがあって、最大ジョブ数が3に設定されているケースを考えてみてください。ステップはシステム・リソースの1/3よりもはるかに多く消費しています。このシナリオで最大ジョブ数を増加すればすぐにサーバーを過負荷な状態にしてしまいます。一方、 小さな、あるいはコストの低いコマンドを実行するサーバーであれば、通常3よりもいくつか多い同時実行ステップを扱うことができます。

サーバーを定義もしくは変更する際に、このプロパティーを設定します。

command_output_cache

エージェントが稼動する各サーバーのbfagent.confファイルの中のcommand_output_cache設定は、サーバーのエージェントがデータを管理コンソールに送る前にどの程度データを格納するかを決定します。設定可能な最小の値でもあるデフォルト値は2048(バイト)です。この値をより高く設定することでエージェントの性能を大幅に改善しネットワーク負荷を削減することができます。最適な性能を実現するために、この値を16384もしくは32768に設定してください。


内部スロットル・メカニズム

いくつかの内部パラメーターはBuild Forgeシステムの性能全体に影響を及ぼすことができます。これらのパラメーターの変更に際しては細心の注意を払ってください。これらの値の変更により好ましくない副作用が発生する可能性があります。

purge_log_count

purge_log_countオプションはbf_sysconfig表に存在します。しかし、Build Forgeユーザー・インターフェースの「管理」>「システム」のメニューから見ることや変更することができません。パージのメカニズムは現在、前述のとおり、Javaのサービス・レイヤーで実行されています。変更点のひとつは、何行のログをバッチで削除するかです。デフォルト値は100です。この値を100行の単位で増加して、同時により多くを削除することができます。このスキームの主なゴールはログ行数の多いパージのBuild Forge環境全体とホスト・システムへの影響のサイズを制御することです。一般的には、大量のビルドのステップ・ログがない限りこの値はそのままにしておくことをお勧めします。

Perlロギング内部制御

バージョン7.1.2から、ステップ・ログはサービス・レイヤーで書かれています。このアプローチは現代のRDBMSのトランザクショナルな性質を活かします。サービス・レイヤーを経由した結果、ログの書き出しプロセスを制御するためにbf_sysconfig表を通して2つのスロットル・オプションが追加されました。これらは隠されたbf_sysconfigオプションであり、デフォルトではBFデータベースに入っていません。この制御を導入するには手動でレコードを挿入する必要があります。

use_sl_logs
エンジン: 0以上の値の設定でこのオプションが有効になります。-1以下の値の設定でサービス・レイヤーのロギングを無効にし、レガシーなPerlロギングを使用します。

サービス・レイヤー:
値は強制的なフラッシュの前に受け取る行数を決定します。この数字は最低でも300である必要があります。より高い値に設定することにより、より多くのログを同時にフラッシュできるようになります。

この設定をデータベースに追加するには、下記のステートメントを使用します。

insert into bf_sysconfig values 
('1','N','use_sl_logs','300','','','',NULL,'integer','',
(SELECT MAX(bf_modified) from bf_users))

use_sl_bulk_logs
このパラメーターはBuild Forgeエンジンにのみ作用します。このパラメーターはエンジンからサービス・レイヤーへの大量ログ転送を有効にします。値は、処理のためにバッチでサービス・レイヤーに送られるステップ部分あたりの行数です。この設定はuse_sl_logs設定が有効化されている場合にのみ作用します。

設定可能な最も低い値でもあるデフォルト値は100です。

この制御をデータベースに追加するには、下記のステートメントを使用します。

insert into bf_sysconfig values 
('2','N','use_sl_bulk_logs','100','','','',NULL,'integer','',
(SELECT MAX(bf_modified) from bf_users))

注: Oracleデータベースの場合、NULL値と空のストリングで異なる解釈をするため、シングル・クォーテーション2つ('')をスペースで区切る(' ')必要があるかもしれません。

これらの設定の使用について
これらの設定は生産者-消費者モデルに基づいています。生産者であるbfprojectが消費者であるサービス・レイヤーにどれだけのデータを送るかを制御します。データ・フローを制御することで、個別のプロセスでどの程度CPUを使うかを制御します。さらに、同時にいくつのステップ・ログをコミットするかを制御しなければなりません。最も注意が必要な数字はuse_sl_logs設定です。大きすぎる値を使用すれば大量のステップ・ログを出力するbfprojectのCPU消費量とステップ・ログのデータベースへの挿入時間を人工的に膨張させることになります。

use_sl_bulk_logs設定の値を増やしても性能の改善は僅かです。しかし、異なる環境において必要に応じて変更することができます。

これらの設定の安全な範囲:
use_sl_logs: 300-2000
use_sl_bulk_logs:100-1000

より高い値を設定する際は十分な注意を払い、必ず環境の設定を注意して評価してください。

設定は次のビルド実行時に有効となります。Rational Build Forgeを再起動する必要はありません。

db_pool

サービス・レイヤーはデータベース接続のプールをオープンし保持します。このプールはユーザー・インターフェースとエンジンから受け取ったすべてのAPIコマンドから取り出されます。50以上のユーザーもしくは50以上のビルドが同時実行されるような高負荷な環境においては、このプールが過負荷になる可能性があります。buildforge.confファイルのdb_poolエントリーで、サービス・レイヤーからデータベースに対してオープンな接続をいくつ保持するかを調整することができます。フォーマットはdb_pool <数字>です。例えば、db_pool 150。

この設定はこれらの接続をRational Build Forgeのリクエストで使用するためにオープンで使用可能な状態に保ち続けるため、この設定の値を決定する際は細心の注意を払ってください。高すぎる値を設定すれば、データベースで許されているオープンな接続を使い尽くしてしまう可能性があります。データベースを構成する必要もあるかもしれません。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational
ArticleID=680974
ArticleTitle=スロットル・メカニズムを通じたRational Build Forgeのリソース使用率の制御
publish-date=06172011