ビルド プランが長時間キューに入れられ、Bamboo のビルド アクティビティ ダッシュボードに「キューに登録済み (queued)」と表示されない

関連コンテンツ

  • 関連コンテンツがありません

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

問題

ビルドプランがビルドのために長時間キューに入れられ、ビルド アクティビティ ダッシュボードに「キューに登録済み (Queued)」として表示されない。ビルドを処理できるエージェントはあるが、長時間キューに入れられたままになる。

原因

キューに入れられてからビルド キューに表示されるまでに大きな遅延があるということは、サーバー側の変更検出プロセスに時間がかかっていることを示唆しています (ビルド ワークフローの詳細は、下を参照してください)。症状が現れたときに問題がどこにあるのかを理解するには、Bamboo のビルド プラン ワークフローの基本を理解しておくと役に立ちます。

  1. ビルド プランが開始される。
  2. プランのステータスが「キューに登録済み」に変わる。
  3. サーバー側で変更を検出する。ビルドに必要な変更があるかどうかを判断するためにリポジトリにアクセスするのがここであり、ビルド キューにまだ入っていないキュー内のビルドを観察するときに最もエラー発生の可能性が高いポイント。
  4. プランがビルド キューに追加される。これがビルド アクティビティ ダッシュボードに表示されるタイミング。
  5. サーバーはそれにエージェントを割り当て、そのエージェントにイベントを送る。
  6. エージェントはイベントを受け取り、ビルドを開始する。

この動作は正常ですが、サーバー側の変更検出が異常に長い原因がいくつか確認されていることに注意が必要です。

原因 1: PlanExec スレッドの競合

Bamboo には、初期の実行フェーズを通じてビルドを移動する役割を担う 4 つのスレッドがあります。VCS 操作が遅い場合、または Bamboo インスタンスで高頻度で発生するリポジトリ ポーリングの数が多い場合、これらのスレッドは変更検出操作の処理に拘束される可能性があります。

原因 2: Git for Windows のバージョンが古い

最近のバージョンでは、Git for Windows のパフォーマンスが大幅に向上し、変更の検出を大幅に高速化できます。

原因 3: Quiet repository

リポジトリの [Enable Quiet repository] 設定は、単一のコミットが検出されてからビルドを開始するまでの遅延を設定できます。これにより、複数のコミットを単一のビルドに集約できます。ビルドに Quiet 期間の待機時間が適用されている間は、そのビルドはビルド キューにまだ入っていないため、ビルド アクティビティ ダッシュボードには表示されません。しかし、ビルドのステータスは「キューに登録済み」と表示され、混乱を招く可能性があります。

Large Quiet period durations are also known to cause issues on busy Bamboo Servers in delaying plans by consuming plan execution threads for the duration of the sleep as well as blocking manual builds and deployment plans. See the following Bug Report:  BAM-7320 - Getting issue details... STATUS

原因 4: Git Credential Manager for Windows

ユーザー名を指定し、パスワードを指定せずに公開 GitHub リポジトリで認証しようとすると、Git Credential Manager　for Windows がインストールされている場合、バックグラウンドで対話型の子プロセスが起動され、GitHub 資格情報を求めて待機します。Bamboo は、変更検出のために、git コマンドを自動化された非対話型の方法で実行しているため、このプロセスは認証情報を受け取って終了することはなく、リポジトリ上で構成されたコマンドがタイムアウトに達するまで、Bamboo はビルドを「キューに登録済み」状態のままとします。次のようなログ エントリーが表示されます。

2017-02-15 01:47:54,686 INFO [9-BAM::PlanExec:pool-16-thread-1] [GitCommandProcessor] Command was canceled: command 'C:\Program Files\Git\cmd\git.exe' ls-remote https://user@github.com/repository-owner/repo.git failed with code -1. Working directory was [.].
原因 5: SSH タイムアウト

Bamboo には、アイドル状態の SSH 接続を維持するための 2 分というハードコードされた制限があります。リポジトリがかなり大きい場合、この制限に達してしまい、変更の検出に失敗し、その結果、ビルド前のアクションが終了しない可能性があります。このような状況になると、ビルドがキューに入れられなくなります。この場合、ログに次のメッセージが表示されます。

BAMBOO-SSH-PROXY: [User session has timed out idling after 120000 ms.]

このタイムアウト値の上限を設定可能にするるよう、改善リクエストが起票されています。以下のチケットで、この改善要望の実装状況を追跡できます。  

BAM-19670 - Getting issue details... STATUS

回避策

原因 3: Quiet repository

負荷の高いサーバーに対する Quiet Repository 設定の影響を最小限に抑えるには、次の点を考慮してください。

  1. Quiet 期間の間スリープしている複数のビルドがすべてのプラン実行スレッドを消費しないように、[Enable Quiet repository] を使用するプランの量を減らします。
  2. Quiet 期間の期間を短縮します。

  3. Bamboo Server の CPU コア数が 8 以上であれば、以下の起動引数を追加してプラン実行スレッド数を増やします。

    8 を超える値の使用はお勧めしません。

原因 4: Git Credential Manager for Windows

  1. まず、Windows の [コントロール パネル] > [資格情報マネージャー] > [汎用資格情報] で、リポジトリに資格情報が保存されているかどうかを確認します。以前の認証試行によっては、資格情報マネージャーがここにユーザー名のみを保存し、その後のすべての試行で GitHub ログイン プロンプト UI を使用して対話型の git-credential-manager.exe が起動される場合があります。そのため、最初にこのエントリをクリアすることをお勧めします。

  2. コマンドラインから、リポジトリに gitコマンドを実行します。つまり、次を実施します。git ls-remote https://user@github.com/repository-owner/repo.git

  3. パスワードの入力を求められたら入力します。これにより、ユーザー名/パスワードが認証情報保管庫に保存され、Bamboo から同じコマンドが実行されても、再度入力を求められることはありません。

  4. または、Bamboo リポジトリ設定にパスワードを追加して、認証情報マネージャーのプロンプトを回避することもできます。

もうひとつの回避策は、Bamboo で GitHub 型リポジトリを使って公開リポジトリにアクセスする代わりに、「Git」型のリポジトリを使って GitHub の公開 URL を指定することです。違いは、Bamboo の GitHub リポジトリではユーザー名(Username) が必須フィールドであるため、Git リポジトリのように匿名で公開リポジトリを認証できないことです。

ソリューション

原因 1: PlanExec スレッドの競合

競合を減らすために検討できることが複数あります。原因 2、3、および 4 は、最終的にこれらのスレッドを拘束する可能性のある根本原因ですが、他にも検討すべき点がいくつかあります。

  1. インスタンスで発生するリポジトリのポーリング操作の量を減らすことで、これらのスレッドの競合を減らします。以下のナレッジベース記事で、過剰なポーリングの分析と特定について説明しています。最終的には、リポジトリのポーリングが発生する頻度を減らすことで解決します。
    1. How do I work with triggering builds

  2. ネットワークの要因が原因で、基本的な VCS 操作に必要以上に時間がかかっていないかを把握し、外部要因を調査してください。たとえば、Gitでは、<bamboo-home>/logs/atlassian-bamboo.log で Bamboo Application のログを確認し、Git の操作が遅いというエラーメッセージや警告メッセージがあるか確認してください。次の例をご確認ください。

    2017-11-20 22:02:04,861 ERROR [12-BranchDetectionBackgroundThread:pool-20-thread-1] [GitCommandProcessor] ls-remote http://bitbucket:7990/bitbucket/scm/res/stored-spec.git took 40.11 s
2017-11-20 22:02:04,862 WARN [12-BranchDetectionBackgroundThread:pool-20-thread-2] [GitCommandProcessor] ls-remote http://bitbucket:7990/bitbucket/scm/res/stored-spec2.git took 15.12 s
2017-11-20 22:02:04,867 ERROR [12-BranchDetectionBackgroundThread:pool-20-thread-3] [GitCommandProcessor] ls-remote http://bitbucket:7990/bitbucket/scm/sim/simple-npm-bamboo.git took 40.13 s
    1. これらのエラーおよび警告を識別するための簡単な grep コマンド：  grep -E "(ERROR|WARN).*GitCommandProcessor.*took"
  3. Bamboo が Bitbucket Server と頻繁にやり取りしている場合は、Bitbucket 側で ref アドバタイズのキャッシュを有効にして操作を高速化することを検討してください。Scaling Bitbucket for Continuous Integration Performance

  4. Bamboo Server の CPU コア数が 8 以上であれば、以下の起動引数を追加してプラン実行スレッド数を増やします。

    8 を超える値の使用はお勧めしません。


原因 2: Git for Windows のバージョンが古い

お使いの Git for Windows のバージョンを、サポートされている最新のバージョンにアップグレードしてください。 

この記事を書いている時点において、2.8 より古いバージョンで問題が発生していることがわかっています。詳細は「サポート対象プラットフォーム」をご参照ください。

最終更新日 2019 年 8 月 2 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する

関連コンテンツ

  • 関連コンテンツがありません
Powered by Confluence and Scroll Viewport.