Bitbucket Server がリソース制限に達しつつある場合

お困りですか?

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

コミュニティに質問

This article only applies to the Atlassian server platform. Learn more about the differences between cloud and server.

はじめに

この記事では、インスタンスで表示される場合がある "Bitbucket Server is reaching resource limits..." バナーの背景について説明します。

Bitbucket Server では次のように 2 つの異なるバナーが表示される可能性がある点にご注意ください。

  • 黄色のバナーは、Bitbucket Server がリクエストをキューに含めていることを示します。
  • 赤色のバナーは、リクエストが実際に拒否されていることを示します。

高負荷状態での黄色のバナーの表示は正常な動作です。この段階では構成パラメータの変更は行わないでください。構成の上限を増やす前に、サーバーの CPU、メモリ、I/O 負荷を監視し、サーバー自体で問題が発生していないことを確認します。これを行わない場合、チケット上限を増やすとインスタンスのパフォーマンスが悪化する可能性があります。詳細の説明については以降のセクションをご確認ください。

メモリ割り当て

Bitbucket Server に割り当てるメモリの量を決定する際に考慮すべき最も重要な要素は、git 操作に必要なメモリの量です。Bitbucket Server のヒープ サイズはホスティング操作に影響しないため、当社の経験では、Bitbucket Server の既定の JVM メモリ構成 (-Xms512m -Xmx1024m) を大規模環境のお客様でも使用できます。Bitbucket Server を実行しているサーバーでのメモリの用途のほとんどは、フォークされた git プロセスです。git 操作はメモリを大幅に消費します。したがって、Bitbucket Server の JVM に割り当てるメモリを増やしても、インスタンスの拡張性やパフォーマンスの改善は期待できません。この場合の効果は正反対になる可能性があります。Bitbucket Server の JVM がほとんどのメモリを使用しているために、git 操作に必要なメモリをサーバーで利用できない場合、git 個の同時操作が開始されると、サーバーではそれ以上の git プロセスをフォークするためのメモリがないため、パフォーマンスが低下します。

ほとんどの場合、Bitbucket Server の既定のメモリを調整するべきではないことはわかりました。では、サーバーのメモリはどのように予測できますか?

簡単な式を使用できます。メモリ使用量を計算するには、Bitbucket Server が許可する同時ホスティング チケットの数と、単一のクローンが使用するメモリ量に焦点を当てる必要があります。

  • 単一クローン運用によるメモリ使用量

    経験則として、ディスクのリポジトリ サイズ (.git/objects ディレクトリのコンテンツ)の 1.5 倍により、400 MB までのリポジトリでの単一クローンに必要なメモリ量の概算を算出できます。大規模なリポジトリの場合は、メモリ使用量は約 700 MBで平坦化する傾向にあります (しかし理論的には Git が使用できるメモリに最大値はありません)。たとえば、単一のホスティング操作の場合、ホスティング操作全体で Bitbucket Server のメモリ使用量はおよそ 800 MB (既定) で一定となるため、先ほど説明したルールにしたがって Git のメモリ使用量が上昇します。
    サーバーのリソース使用量の詳細な分析については、「Bitbucket Server の拡張 - クローンの検討」と「Bitbucket のキャッシュ」をお読みください。

  • Bitbucket Server で許可される同時操作の数

    バージョン 4.11 以降、Bitbucket Server では、システム リソースを監視することによって実行できる Git 操作の数の定義に、 FIZME アダプティブ スロットリング メカニズムを使用しています。
    Git チケットにサーバー リソースの完全な提供が許可されない場合、次のメッセージがログに記録されます。

    INFO  [spring-startup]  c.a.s.i.t.ResourceThrottleStrategyProvider [scm-hosting] This machine's total available memory cannot safely support a maximum of XXX tickets. Reducing maximum tickets to XX instead


    バージョン 4.10 以前では、すべてのクライアントで許容不可能なパフォーマンスが発生するのを防ぐため、Bitbucket Server は同時に実行できる Git 操作の数を制限します。これらの制限は調整できます。「Bitbucket Server の構成プロパティ」を参照してください。
    これに使用されるパラメータ (throttle.resource.scm-hosting) はサーバーの CPU の数に基づき、式は 1.5 x cpu です。

  • サーバーで Bitbucket Server を安全に実行するために必要なメモリ量を計算できるようになりました。

    はい、確認すべきことはそれだけです。一般的な Bitbucket Server での割り当ては次のようになります。
    • Bitbucket Server: 768MB
    • Git: 1.5 * (4 CPU) * 700 MB = 4200 MB
    • オペレーティング システム: 1024 MB
    • 合計: 5992 MB
    • 40 % の安全マージン: ~ 8 GB
    • バンドルされた Elasticsearch: 1 GB (これは、既定設定にしたがって Bitbucket Server 4.6.0+ をバンドルされた Elasticsearch と実行する場合に追加します)
    このインスタンスを実行するサーバーが Bitbucket Server のみを実行する場合、8 GB (4.6.0 以降の場合は 9 GB) の RAM メモリを用意することが推奨されます。これらの数字は見積り値であり、実際の数字は基盤となるハードウェアおよび OS の I/O、CPU、およびメモリの特徴に応じて異なる可能性がある点にご注意ください。
  • 詳細については、「Bitbucket Server の拡張」を参照してください。

質問と回答

UI に "Bitbucket Server is queuing requests" appears and it is followed later by "Bitbucket Server is reaching resource limits" というメッセージが表示されました。これはどういう意味ですか。

メモリ割り当て」セクションの例をご確認ください。"ステージ1 " では、4 CPU の場合、Bitbucket Server では 6 SCM のホスティング操作を同時に実行でき、それぞれを Git のプロセスにフォークします。サーバーが 6 SCM を超えるリクエストを受け取る場合、サーバーのメモリの枯渇を回避するために、これらのリクエストはキューに入れられ、Git のプロセスにフォークされません"ステージ 2 " では、最初にフォークされた Git プロセスの一部は処理を終了し、Bitbucket Server はこれらのスロットを埋めるために SCM キューからリクエストを取得します。第 3 ステージでは、Bitbucket Server はそれらをリクエストを新しい Git プロセスにフォークします。

リクエストが 1 分以上キューに入れられている場合は "Bitbucket Server is queueing requests..." メッセージが Bitbucket Server によって表示される点にご注意ください。

リクエストが 5 分以上キューに入れられている場合 (throttle.resource.scm-hosting.timeout)、それらは却下され、git clone/fetch/push 操作は失敗します。この時点で "Bitbucket Server is reaching resource limits..." メッセージが表示されます。このメッセージは、リクエストが却下されなくなってから 5 分が経過すると (throttle.resource.busy.message.timeout、Bitbucket Server 3.0+ の場合は server.busy.on.ticket.rejected.within) 非表示になります。これらの制限は調整できます。「Bitbucket Server の構成プロパティ」を参照してください。

以下に、拒否された SCM リクエストの種類ごとにログに記録されるデータの例を紹介します。

A [scm-hosting] ticket could not be acquired (0/12)

atlassian-bitbucket.log

2015-08-28 11:41:00,327 WARN [ssh-scm-request-handler] Access key user (drohan@localhost) @16NVUP5x701x17836x333 1z0lim3 10.10.10.122 SSH - git-upload-pack '/alpha/apple.git' c.a.s.i.t.SemaphoreThrottleService A [scm-hosting] ticket could not be acquired (0/24)

2015-08-28 11:41:00,334 INFO [ssh-scm-request-handler] Access key user (drohan@localhost) @16NVUP5x701x17836x333 1z0lim3 10.10.10.122 SSH - git-upload-pack '/alpha/apple.git' c.a.s.s.t.ThrottledScmRequestFactory A scm-hosting request was denied due to heavy server load. Please see http://docs.atlassian.com/bitbucket/docs-0212/Scaling+Bitbucket Server for performance guidelines.

A [scm-command] ticket could not be acquired (0/1)

atlassian-bitbucket.log

2015-08-28 11:41:05,327 WARN [http-nio-7990-exec-9] usera @16NVUP5x701x17836x3 0:0:0:0:0:0:0:1 "GET /projects/TEST/repos/test/commits HTTP/1.1" c.a.s.i.t.SemaphoreThrottleService A [scm-command] ticket could not be acquired (0/1)



これらのステージについては以降の図をご参照ください。

メッセージは慎重に確認することをおすすめします。リクエストが却下されていて、それが定期的に発生している場合、インスタンスのサイズが適切に設定されていない可能性があります。

この問題を回避するために取るべきアクション

最善の方法は、JMX 監視を実装することです。

上述のように、多数のホスティング チケットを持つキューをシステムで素早く処理する必要があります。キューが小さいが、チケットの却下が開始される前に空になる場合、問題は発生しません。よくある構成ミスについて説明します。これらはパフォーマンス低下につながるため、行わないでください 

  • Bitbucket Server JVM のメモリの量を増やすことこの操作は行わないでください。通常、この操作を行うことによって、サーバーの大量のメモリが JVM に割り当てられ、Bitbucket Server によってフォークされた Git プロセスが利用できる余分の空きメモリが減少します。これは悪い状態で、メモリの空き容量不足のために Git プロセスが満杯状態になるため、メモリ不足や malloc 関数の失敗など、git プッシュの失敗で説明したような副作用が生じる可能性があります。 
  • throttle.resource.scm-hosting を調整してホスティング チケットの数を増やすことこの操作は行わないでくださいこの操作を行わない理由は、前述のとおりです。システムはチケットの解放を最大で 5 分 (throttle.resource.scm-hosting.timeout の既定設定) 待機します。このため、ホスティング チケットの数を減らすと、キューへの影響はありますが、I/O の競合が軽減するために個々のクローンの処理速度が向上し、それによってタイムアウトよりも前にチケットが解放される可能性があります。一方、Bitbucket Server が処理できるホスティング チケット数を増やすことによって、処理するチケットが増え、結果的にタイムアウト前にチケットが解放される可能性が低くなるため、フォークされた Git プロセスの CPU 処理時間が増えることになります。

Bitbucket Server がホスティング チケットをより迅速に処理するのに役立ついくつかの操作を説明します。これらの項目を検討してください

継続的インテグレーション ポーリング

CI サーバーが Bitbucket Server のリポジトリを確認する頻度を減らします。これはこの問題が発生した顧客からの報告に共通する点です。Bitbucket Server で多数の Git 操作の数が発生する場合、"Bitbucket Server is reaching resources limits..." メッセージが表示される可能性が高くなります。CI サーバーが Bitbucket Server に必要に応じてアクセスしていることを確認し、可能な場合はポーリングの頻度を減らします。「 継続的インテグレーションのパフォーマンスのために Bitbucket Server を拡張する」を参照し、SCM キャッシュ プラグインが有効化されていて、最新であることを確認します。

CI サーバーからのコール数をさらに減らすには、Post-receive hook をセットアップしてポーリング方法を変更します。

SSL 処理

Bitbucket Server までのすべての経路での SSL の実行は、この問題が発生するお客様の事例に共通するもう 1 つの問題です。パフォーマンスを向上させるには、Bitbucket Server の手前にプロキシをセットアップする必要があります。効率の観点で、Java SSL スタックはこれらのいずれにもおよばず、SSL スタックを除去すれば Bitbucket Server のパフォーマンスがはるかに向上します。この変更を実行する方法については「Bitbucket Server のプロキシ設定と保護」を参照してください。

Ref advertisement キャッシュ  

Bitbucket のキャッシュ」ページと「継続的インテグレーションのパフォーマンスのための Bitbucket Server の拡張」の「キャッシュ」セクションの説明にあるように、ref advertisement 機能が既定で無効化されています。これを有効化すると、負荷が大幅に軽減します。これを行うために Bitbucket Server を再起動する必要はありません。「キャッシュの有効化と無効化」で説明されている REST API コールを使用していつでも変更できます。


  • REST API (再起動は不要)

    GET
    /rest/scm-cache/latest/config/refs/enabled
    ref advertisement キャッシュが有効化されているか (true) 無効化されているか (false) を取得します。
    PUT
    /rest/scm-cache/latest/config/refs/enabled/{status}

    ref advertisement キャッシュを有効化 (status = true) または無効化 (status = false) します。

    以下は、ローカル インスタンスでのサンプル コマンドです。Bitbucket Server の URL と "username:password" パラメーターを適宜調整するようにします。

    # Check Ref advertisement caching STATUS
    curl -H "Content-Type:application/json" -H "Accept:application/json" --user charlie:charlie -X GET http://mybbs:7990/rest/scm-cache/latest/config/refs/enabled
    false
     
    # Enable Ref advertisement caching
    curl -H "Content-Type:application/json" -H "Accept:application/json" --user charlie:charlie -X PUT http://mybbs:7990/rest/scm-cache/latest/config/refs/enabled/true
    
    
    # Disable Ref advertisement caching
    curl -H "Content-Type:application/json" -H "Accept:application/json" --user charlie:charlie -X PUT http://mybbs:7990/rest/scm-cache/latest/config/refs/enabled/false
    
  • bitbucket.properties 経由

    bitbucket.properties ファイルが存在しない場合は Bitbucket Server のホーム ディレクトリshared フォルダに作成します。次のプロパティを追加してアプリケーションを再起動します。

    plugin.bitbucket-scm-cache.refs.enabled=true


サーバ リソース

以下の内容を確認することが重要です。

  • メモリの容量
  • CPU の数

サーバーに適宜リリースを割り当てます。これを実行する方法の詳細については、「メモリ割り当てセクションおよび「Bitbucket Server の拡張」を参照してください。

  • プラグイン: 前述のように、この問題は処理に大きな関わりがあります。パフォーマンスに影響をおよぼしているプラグインがないことを確認します。このような問題は Awesome Graphs で確認されています。これは優れたプラグインですが、このプラグインによるインデックス作成は CPU と IO に負担をかけ、Bitbucket Server インスタンスのパフォーマンスに著しい影響を与える可能性があります。システムにすでに高い負荷がかかっている場合、ユーザーがインストールしたすべてのプラグインを無効にして、しばらく様子を見ることをお勧めします。「UPM をセーフ モードに設定する」の手順をご利用ください。
  • 処理: ここでの戦略として、現在のシステムのデフォルトの同時実行の上限を維持しながら、マシンに複数のCPUを追加することが考えられます。システムで 4 個のCPUを持っているとします。現在の SCM ホスティング チケットの数は 6 です。より多くの CPU を追加しながら同時実行のキューを過去の状態に保つことにより、これらの 6 つのホスティング チケットを素早く処理し、追加のリクエストのキュー時間を短縮して、チケットのフローを改善できます。したがって、サーバーでのホスティング操作の処理中に、同じ負荷を処理するキャパシティを保ちながら、全体的なパフォーマンスを改善できます。

次の構成を bitbucket.properties に追加することで同時実行の上限を保持できます(ファイルが存在しない場合は作成し、Bitbucket Server を再起動して新しいファイルを読み込みます)。

# Limits the number of SCM hosting operations, meaning pushes and pulls over HTTP or SSH, which may be running concurrently.
# This is intended primarily to prevent pulls, which can be very memory-intensive, from pinning a server's resources.
# There is limited support for mathematical expressions; +,-,*,\ and () are supported. You can also use the 'cpu'
# variable which is resolved to the number of cpus that are available.
throttle.resource.scm-hosting=6


スレッド ダンプ解析を使用せずに SCM ホスティング チケットの使用状況を監視する方法

パフォーマンスを監視する JMX カウンターを有効化して、チケットの統計情報を確認します。

パフォーマンスの問題の原因を特定できない場合 

アトラシアン サポートでサポート チケットを起票してください。次の内容を行っていることをご確認ください。

  • ログ パーサー ツールをダウンロード済みで、ページの手順に従い、Bitbucket Server の atlassian-bitbucket-access*.logsgenerate-access-logs-graph.sh を実行済みであること。グラフを課題に添付します。ツールを実行できない場合も問題ありません。いただいたサポート zip を使用して弊社側でツールを実行いたします。
  • インスタンスでデバッグ ログが有効化されていること。
  • インスタンスでプロファイル ログが有効化されていること。これは終了に時間がかかるプロセスを特定するのに役立つため、非常に重要です。
  • 問題が起こった後にサポート zip ([管理] > [アトラシアン サポート ツール] > [作成]) を生成していること。サポート リクエストのチケットに添付し、[ファイル サイズの制限] が選択されていないことを確認します。



説明 This article aims to explain the meaning of the "Bitbucket Server is reaching resource limits..." banner that you might be seeing on your instance.
製品Bitbucket
プラットフォームサーバー
最終更新日 2019 年 7 月 15 日

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

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