[Other doc versions]
[Doc downloads]
Stash is now known as Bitbucket Server
.
See the
Unknown macro: {spacejump}
of this page, or visit the Bitbucket Server documentation home page.
This page discusses performance and hardware considerations when using Stash Server.
Note that Stash Data Center, not discussed on this page, uses a cluster of Stash nodes to provide Active/Active failover, and is the deployment option of choice for larger enterprises that require high availability and performance at scale.
ハードウェア要件
The type of hardware you require to run Stash depends on a number of factors:
- The number and 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 size of your repositories – there are many operations in Stash that require more memory and more CPUs when working with very large repositories. Furthermore, huge Git repositories (larger than a few GBs) are likely to impact the performance of the Git client – see this discussion.
- ユーザーの数。
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. Note that enabling the SCM Cache Plugin (bundled with Stash from version 2.5.0) can help to reduce the cloning load on the Stash server due to CI polling. See Scaling Stash for Continuous Integration performance.
- リポジトリ サイズの平均値を見積もるか計算し、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.
メモリ
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 setenv.sh or setenv.bat.
The memory consumption of Git is not managed by the memory settings in setenv.sh 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.
CPU
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.
暗号化 (SSH または HTTPS) を有効化している場合、CPU に顕著なオーバーヘッドが見られます。次の表に示すように、SSH と HTTPS にはそれぞれのメリットとデメリットがあるため、これらのどちらかが明確に優れているようなことはありません。
| http | HTTPS | ssh | |
|---|---|---|---|
| 暗号化 | 暗号化の CPU オーバーヘッドはないが、プレーンテキストでの転送やベーシック認証はセキュリティ上許可されない可能性がある。 | 暗号化の CPU オーバーヘッドがあるが、これは別のプロキシ サーバーにオフロードできる (セキュアな接続がそこで終了している場合)。 | 暗号化の CPU オーバーヘッドがある。 |
| 認証 | 認証は低速。LDAP または Crowd サーバーとのリモート認証が必要。 | 認証は高速。単純なルックアップのみが必要。 | |
| クローン | リポジトリのクローンはわずかに高速。最少 2 リクエスト (場合によってはそれ以上) で、それぞれに認証と権限チェックが必要。ただし、追加のオーバーヘッドは 10-100 ミリ秒の範囲に収まる小さな量。 | リポジトリのクローンは単一のリクエスト。 | |
クローンの検証
リポジトリのクローンは CPU およびメモリの観点でもっとも高価な操作であるため、ここではクローン処理を詳細に分析します。次のグラフは 220 MB のリポジトリの CPU およびメモリ使用率を表します。
 |
Git プロセス (青色の線)
Stash (red line)
|
 |
Git プロセス (青色の線)
Stash (red line)
|
 |
このグラフは、同時実行によるクローンの平均レスポンス時間への影響を示します。
このグラフの測定は、4 つの CPU と 12 GB のメモリを持つサーバーで行われました。 同時クローン操作が CPU の数を超えるにつれて、 レスポンス時間は飛躍的に低下しています。 |
Configuring Stash scaling options and system properties
Stash limits the number of Git operations that can be executed concurrently, to prevent the performance for all clients dropping below acceptable levels. These limits can be adjusted – see Stash config properties.
データベース要件
The size of the database required for Stash depends in large part on the number of repositories and the number of commits in those repositories.
非常に大まかな目安は、100 + ((すべてのリポジトリを横断したコミットの合計数) / 2500) MB です。
たとえば、それぞれが平均 25,000 コミットを持つ 20 個のリポジトリがある場合、データベースには 100 + (20 * 25,000 / 2500) = 300 MB が必要です。
概要
コンテンツ ツール
アプリ
Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.