Stash is now known as Bitbucket Server.
See the

Unknown macro: {spacejump}

of this page, or visit the Bitbucket Server documentation home page.



The type of hardware you require to run Stash depends on a number of factors:

  • ユーザーの数。
  • The size of your repositories. On large repositories, many operations require more memory and more CPUs.
  • The frequency of clone operations. Cloning a repository is one of the most demanding operations. One major source of clone operations is continuous integration. When your CI builds involve multiple parallel stages, Stash will be asked to perform multiple clones concurrently, putting significant load on your system.

The following are rough guidelines for choosing your hardware:

  • Estimate the number of concurrent clones that are expected to happen regularly (look at continuous integration). Add one CPU for every 2 concurrent clone operations.
  • リポジトリ サイズの平均値を見積もるか計算し、1.5 * 同時クローン操作の数 *

Understanding Stash's resource usage

Most of the things you do in Stash involve both the Stash server and one or more Git processes created by Stash. For instance, when you view a file in the Stash web application, Stash processes the incoming request, performs permission checks, creates a Git process to retrieve the file contents and formats the resulting webpage. In serving most pages, both the Stash server and Git processes are involved. The same is true for the 'hosting' operations: pushing your commits to Stash, cloning a repository from Stash or fetching the latest changes from Stash. 

As a result, when configuring Stash for performance, CPU and memory consumption for both Stash and Git should be taken into account.

Stash basic flow


When deciding on how much memory to allocate for Stash, the most important factor to consider is the amount of memory required for Git. Some Git operations are fairly expensive in terms of memory consumption, most notably the initial push of a large repository to Stash and cloning large repositories from Stash. For large repositories, it is not uncommon for Git to use up to 500 MB of memory during the clone process. The numbers vary from repository to repository, but as a rule of thumb 1.5 x the repository size on disk (contents of the .git/objects directory) is a rough estimate of the required memory for a single clone operation for repositories up to 400 MB. For larger repositories, memory usage flattens out at about 700 MB.

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

Stash 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 Stash 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 Stash. The maximum amount of memory available to Stash can be configured in or setenv.bat.

The memory consumption of Git is not managed by the memory settings in or setenv.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.


In Stash, much of the heavy lifting is delegated to Git. As a result, when deciding on the required hardware to run Stash, the CPU usage of the Git processes is the most important factor to consider. And, as is the case for memory usage, cloning large repositories is the most CPU intensive Git operation. When you clone a repository, Git on the server side will create a pack file (a compressed file containing all the commits and file versions in the repository) that is sent to the client. While preparing a pack file, CPU usage will go up to 100% for one CPU.

For users that connect to Stash using SSH, the encryption of data adds to overall CPU usage. For day-to-day push and pull operations the overhead will not be significant, but when cloning repositories the overhead will be noticeable.

To get the maximum performance from Stash, we advise configuring automatic build tools to use the http or https protocol, if possible.


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


Git プロセス (青色の線)

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

Stash (red line)

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


Git プロセス (青色の線)

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

Stash (red line)

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



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

Configuring Stash scaling options and system properties

Stash only allows a fixed number of Git commands to be executed concurrently, to prevent the performance for all clients dropping below acceptable levels. Stash has two settings to control the number of Git processes that are allowed to process in parallel: one for the web UI and one for the 'hosting' operations (pushing and pulling commits and cloning a repository).

The settings can be overridden by creating a in STASH_HOME with the following content:

# The maximum number of concurrent requests using git commands using the UI or REST services (e.g. git diff via the UI). Default value is 25.
# Controls how long threads will wait for SCM commands to complete when the system is already running the maximum number of SCM commands. Value is in seconds. Default is 2 seconds.
# The maximum number of concurrent requests using "hosting" commands, git clone, git push, git pull. Default value is 1.5*cpu (1.5 times the number of available cpus/cores).
# Controls how long threads will wait for SCM commands to complete when the system is already running the maximum number of SCM commands. Value is in seconds. Default is 300 seconds (5 minutes).

What happens when the limits are reached?

For the given resource, the request will wait until a currently running request has completed. If no request completes within a configurable timeout, the request will be rejected.

When requests while accessing the Stash UI are rejected, users will see either a 501 error page indicating the server is under load, or a popup indicating part of the current page failed.

When git client commands (pull/push/clone) are rejected, Stash does a number of things:

  • Stash will return an error message to the client which the user will see on the command line: "Stash 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.
  • For five minutes after a request is rejected, Stash will display a red banner in the UI to warn that the server is under load.