Bitbucket Server の拡張

Bitbucket Server を管理する

このページの内容

お困りですか?

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

コミュニティに質問

このページでは、Bitbucket Server を使用するときのパフォーマンスおよびハードウェアの考慮事項について説明します。

このページでは取り上げませんが、Bitbucket Data Center は、Bitbucket Server ノードのクラスタを使用してアクティブ / アクティブ フェイルオーバーを提供する、大規模環境での高可用性とパフォーマンスが必要なエンタープライズ企業向けのデプロイメント オプションです。

ハードウェア要件

Bitbucket Server を実行するために必要なハードウェア タイプは、さまざまな要因によって異なります。

  • クローン操作の数と頻度。リポジトリのクローンは、もっともリソースを消費する操作の 1 つです。クローン操作の主な背景として、継続的インテグレーションが挙げられます。CI ビルドに複数の並行ステージがある場合、Bitbucket Server で多数のクローンを同時に実行する必要があり、システムで多大な負荷が発生します。
  • リポジトリの数。Bitbucket Server では、リポジトリの規模が非常に大きい場合に大量のメモリと CPU を消費する、多数の操作があります。また、大規模な Git リポジトリ (数 GB 以上) は Git クライアントのパフォーマンスにも影響を与える可能性があります。
  • ユーザーの数。

ハードウェアを選定するにあたっての大まかなガイドラインは次のとおりです。

  • 標準的に発生することが予測される同時クローンの数を見積ります (継続的インテグレーションをご確認ください)。同時クローン操作 2 つにつき、1 つの CPU を追加します。SCM Cache Plugin (Bitbucket Server 2.5.0 以降に同梱) を有効化すると、Bitbucket Server インスタンスでの CI ポーリングによるクローン負荷を減らすことができます。「継続的インテグレーションのために Bitbucket Server を拡張する」をご参照ください。
  • リポジトリ サイズの平均値を見積もるか計算し、1.5 * 同時クローン操作の数 *
  • If you’re running Bitbucket Data Center, check your size using the Bitbucket Data Center load profiles. If your instance is Large or XLarge, take a look at our infrastructure recommendations for Bitbucket Data Center AWS deployments.



アダプティブ スロットリング

Bitbucket Server 4.11 までのバージョンでは、リソース スロットルは固定数のチケットを割り当てることで実現されており、各ホスティング処理はチケットを取得してから続行する必要がありました。ホスティング処理に利用可能なチケットが見つからない場合、チケットが利用可能になるまでキューで待機する必要があり、待機時間が長すぎる場合にはタイムアウトが発生していました。既定は CPU コアあたり 1.5 チケットですが、アプリのプロパティ内でこれを増やすことができました。この設定に適切な値を見つけることは簡単ではありませんでした。

Bitbucket Server 4.11 では、マシンの負荷に対応可能な、SCM ホスティング処理のための新しいスロットル アプローチを採用しました。これは「アダプティブ スロットリング」と呼ばれます。Bitbucket はアダプティブ スロットリングにより、マシンの物理メモリの合計量を評価し、ホスティング処理が消費するメモリ量、BBS で必要とするメモリ量、および検索で必要とするメモリ量の見積もりを元に、マシンで安全にサポート可能な最大チケット数を決定します。チケット範囲の既定の最小値 (CPU コアあたり 1 チケット) と最大値 (CPU コアあたり 12 チケット) は変更できます。

アダプティブ リソース スロットリングの他の特長には次のようなものがあります。

  • 現在の CPU 使用率とターゲット CPU 使用率 (既定では 75 % の CPU 使用率) との間の差異に基づいて幅広いチケット値を許可。これは変更できます。
  • 5 秒ごとに CPU 使用率の再サンプリングを行い、範囲内でサポート可能なチケット数を再計算。
  • CPU 使用率の読み取りはスムージングされるため、最適なチケット数が CPU スパイクによって必要以上に素早く変更されることはない。 

アダプティブ スロットリングは Bitbucket Server 4.11 以降では既定で有効化されますが、次のような状況の場合は固定スロットリングに戻すことができます。

  • You previously set a non-default fixed number of tickets, for instance 
    throttle.resource.scm-hosting=25
  • You previously configured this strategy explicitly, for instance 
    throttle.resource.scm-hosting.strategy=fixed
    throttle.resource.scm-hosting.fixed.limit=25
  • アダプティブ スロットリングが同様の方法で無効である場合
  • メモリの合計メモリ量が制限されていて、チケット範囲全体が安全な値ではない場合


Bitbucket Server のリソースの使用状況を理解する

Bitbucket Server で行うほとんどの操作は、Bitbucket Server インスタンスと、Bitbucket Server が作成した 1 つ以上の Git プロセスの両方を含みます。たとえば、Bitbucket Server の web アプリケーションでファイルを表示した場合、Bitbucket Server が受信リクエストを処理し、権限チェックを行い、ファイル コンテンツを取得するための Git プロセスを作成して、結果となる web ページのフォーマッティングを行います。ほとんどのページの提供に、Bitbucket Server インスタンスと Git プロセスの両方が含まれます。これは、Bitbucket Server へのコミットのプッシュ、Bitbucket Server からのリポジトリのクローン、および Bitbucket Server からの最新の変更の取得などの "ホスティング" 処理でも同様です。 

つまり、Bitbucket Server をパフォーマンスの観点で構成する場合、Bitbucket Server Git の両方の CPU およびメモリ使用率を考慮に入れる必要があります。

メモリ

Bitbucket Server に割り当てるメモリの量を決定する際に考慮すべき最も重要な要素は、Git 操作に必要なメモリの量です。一部の Git 操作はメモリを大量に使用します。もっともわかりやすい例として、大規模なリポジトリの Bitbucket Server への初回プッシュや、Bitbucket Server からの大規模なリポジトリのクローンがあります。大規模なリポジトリの場合、クローン処理中に Git が 500 MB のメモリを使用することも珍しくありません。このような数字はリポジトリごとに変わりますが、400 MB までのリポジトリでの 1 回のクローン処理に必要なメモリ量の概算として、ディスクでのリポジトリ サイズ (/git/objects ディレクトリのコンテンツ) の 1.5 倍と見なすことができます。より大きなリポジトリの場合、メモリ使用量は約 700 MBで一定になります。

クローン操作は、もっともメモリ量を消費する Git 操作です。ファイル履歴、ファイル コンテンツ、およびコミット一覧などの表示などの他の Git 操作のほとんどは、相対的に軽量です。

Bitbucket Server has been designed to have fairly constant memory usage. Any pages that could show large amounts of data (e.g. viewing the source of a multi-megabyte file) perform incremental loading or have hard limits in place to prevent Bitbucket Server from holding on to large amounts of memory at any time. In general, the default memory settings (max. 768 MB) should be sufficient to run Bitbucket Server. The maximum amount of memory available to Bitbucket Server can be configured in _start-webapp.sh or _start-webapp.bat.

The memory consumption of Git is not managed by the memory settings in _start-webapp.sh or _start-webapp.bat. The Git processes are executed outside of the Java virtual machine, and as a result the JVM memory settings do not apply to Git.

CPU

Bitbucket Server では、負荷の高い処理の多くが Git に委任されます。したがって、Bitbucket Server を実行するために必要なハードウェアを判断する際に考慮すべきもっとも重要な事項は、Git プロセスの CPU 使用量です。また、メモリ使用量の場合と同様に、もっとも CPU を使用する Git 操作は、大規模なリポジトリのクローンです。リポジトリをクローンすると、サーバー側の Git はクライアントに送信するパック ファイル (リポジトリのすべてのコミットとファイル バージョンを含む圧縮ファイル) を作成します。パック ファイルの準備中、1 つの CPU で CPU 使用率が 100 % まで上がります。

暗号化 (SSH または HTTPS) を有効化している場合、CPU に顕著なオーバーヘッドが見られます。次の表に示すように、SSH と HTTPS にはそれぞれのメリットとデメリットがあるため、これらのどちらかが明確に優れているようなことはありません。


httpHTTPSssh
暗号化

暗号化の CPU オーバーヘッドはないが、プレーンテキストでの転送やベーシック認証はセキュリティ上許可されない可能性がある。

暗号化の CPU オーバーヘッドがあるが、これは別のプロキシ サーバーにオフロードできる (セキュアな接続がそこで終了している場合)。

暗号化の CPU オーバーヘッドがある。

認証

認証は低速。LDAP または Crowd サーバーとのリモート認証が必要。

認証は高速。単純なルックアップのみが必要。

クローン

リポジトリのクローンはわずかに高速。最少 2 リクエスト (場合によってはそれ以上) で、それぞれに認証と権限チェックが必要。ただし、追加のオーバーヘッドは 10-100 ミリ秒の範囲に収まる小さな量。

リポジトリのクローンは単一のリクエスト。

クローンの検証

リポジトリのクローンは CPU およびメモリの観点でもっとも高価な操作であるため、ここではクローン処理を詳細に分析します。次のグラフは 220 MB のリポジトリの CPU およびメモリ使用率を表します。


Git プロセス (青色の線)

  • サーバー側でパック ファイルが作成される間、CPU 使用率は 100 % まで上昇します。
  • パック ファイルを圧縮する間、CPU 使用率はピークの 120 % に達します (複数の CPU を使用)。
  • パック ファイルをクライアントに送信する際、CPU 使用率は 0.5 % まで低下します。

Bitbucket Server (赤色の線)

  • クローン リクエストの処理中、CPU 使用率は素早く 30 % のピークに達します。
  • Gir がパック ファイルを用意する間、CPU 使用率は 0 % に戻ります。
  • パック ファイルがクライアントに送信される間、CPU 使用率は 1 % 前後になります。


Git プロセス (青色の線)

  • パック ファイルの準備中、メモリ使用量は 270 MB まで徐々に上昇します。
  • パック ファイルがクライアントに転送される間、メモリ使用量は 270 MB にとどまります。
  • パック ファイルの転送が完了すると、メモリ使用量は 0 に戻ります。

Bitbucket Server (赤色の線)

  • メモリ使用量は 800 MB 前後を維持し、クローン操作の影響を受けません。


このグラフは、同時実行によるクローンの平均レスポンス時間への影響を示します。

  • 垂直軸: 平均レスポンス時間。
  • 水平軸: 同時クローン操作の数。
このグラフの測定は、4 つの CPU と 12 GB のメモリを持つサーバーで行われました。
同時クローン操作が CPU の数を超えるにつれて、
レスポンス時間は飛躍的に低下しています。


Bitbucket Server のスケーリング オプションとシステム プロパティの構成

Bitbucket Server では、すべてのクライアントのパフォーマンスが許容レベルを下回ることを防止するために、同時に実行できる Git 操作の数を制限しています。これらの制限は調整できます。「Bitbucket Server の構成プロパティ」を参照してください。 

これらのプロパティは、一度に実行可能な特定のタイプの Git 操作を制限することで、ThrottleService の同時タスクの制限を定義します。これは、Bitbucket Server が実行中のプロセスによってサーバー マシンに負荷をかけるのを防ぐことを意図しています。Bitbucket Server には、同時に処理できる Git プロセスを制御するための 2 つの設定があります。1 つは web UI 用、1 つは "ホスティング" 処理 (コミットのプッシュおよびプル、リポジトリのクローン) 用です。

対象のリソースの上限に到達すると、リクエストは現在実行中のリクエストが完了するのを待機します。構成されたタイムアウト時間中にリクエストが完了されない場合、リクエストは却下されます。Bitbucket Server の UI にアクセスするときのリクエストが却下されると、ユーザーには、サーバーが負荷状態にあることを示す 501 エラーのページか、現在のページの一部が失敗したことを示すポップアップが表示されます。Git クライアントの "ホスティング" コマンド (プル/プッシュ/クローン) が却下されると、Bitbucket Server はさまざまなことを実行します。

  • Bitbucket Server はクライアントにエラー メッセージを返します。ユーザーはこれをコマンド ラインで次のように確認できます。"Bitbucket Server is currently under heavy load and is not able to service your request. Please wait briefly and try your request again"
  • A warning message will be logged for every time a request is rejected due to the resource limits, using the following format:
    "A [scm-hosting] ticket could not be acquired (0/12)"
  • リクエストの却下から 5 分の間、サーバーが負荷状態にある旨を警告する赤いバナーが Bitbucket Server の UI に表示されます。

マシンレベルのハード制限は OS およびハードウェアに大きく依存するため、ご利用の Bitbucket Server インスタンスに合わせて調整する必要がある場合があります。たとえば、サーバーの CPU でハイパースレッディングが有効化されている場合、十分な数の同時 Git 操作によってマシンの I/O が完全に埋もれてしまう可能性があります。このような場合、マルチコア マシンの既定値を下げて開始することをおすすめします。ホスティング処理が再び稼動するようになったらあとで値を増加させることができます。このような既定設定は経験に基づいて導き出されます。 

Additional resource types may be configured by defining a key with the format throttle.resource.<resource-name>
When adding new types, it is strongly recommended to configure their ticket counts explicitly using this approach.

データベース要件

Bitbucket Server に必要なデータベースのサイズの大部分は、リポジトリの数と、それぞれのリポジトリにあるコミットの数に依存します。

非常に大まかな目安は、100 + ((すべてのリポジトリを横断したコミットの合計数) / 2500) MB です。

たとえば、それぞれが平均 25,000 コミットを持つ 20 個のリポジトリがある場合、データベースには 100 + (20 * 25,000 / 2500) = 300 MB が必要です。

Last modified on Mar 30, 2020

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

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.