Answers: <p>Assuming you are already familiar with <a href="https://docs.gitlab.com/ee/user/project/repository/reducing_the_repo_size_using_git.html" rel="nofollow noreferrer">how to clean up GitLab</a>, the best way to track the disk use and predict growth is to monitor it. Based on the mounting data you can see the trend.</p>
  <p>The problem with calculating the growth in storage is that the git heuristics make it unpredictable. Git is optimizing storage as you commit, a bit like a real time compressed archive.</p>
  <p>By monitoring the storage, you can see the rate of growth and add an alarm for when it falls below a safe threshold.</p>
  <p>I use <a href="https://www.datadoghq.com/" rel="nofollow noreferrer">DataDog</a> for this. Other tools are available.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-06-04T18:12:28.967Z
Answers: 2023-06-04T18:12:28.967Z
Answers: Fenton
Answers: <p>As per the <a href="https://docs.gitlab.com/ee/install/requirements.html" rel="nofollow noreferrer">documentation</a>:</p>
  <blockquote>
  <p>GitLab package requires about 2.5 GB of storage space for installation</p>
  </blockquote>
  <p>and</p>
  <blockquote>
  <p>The necessary hard drive space largely depends on the size of the
  repositories you want to store in GitLab but as a guideline you should
  have at least as much free space as all your repositories combined
  take up.</p>
  </blockquote>
  <p>What you are describing seems to relate more to logs not being properly rotated or docker images not regularly purged.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-06-07T12:33:48.917Z
Answers: 2023-06-07T12:33:48.917Z
Answers: YoshiMbele
Answers: <p>Number of commits is not a good heuristic for determining storage size on a server. Commits will vary by size, and 1 commit with a large blob can consume more than the 100s of commits before it. This further escalates if you don't have any measures in place to block commits with large files from being pushed to your instance.</p>
  <p>Commits aside, repos themselves will almost certainly not be the largest source of storage space on your instance. Metadata (MRs, comments, attachments, etc.) will likely consume far more even than even the most poorly managed of repositories.</p>
  <p>Ultimately, having proper monitoring and alerting on your instance for consumed storage, and being able to scale up rapidly is far more important than being able to forecast the approximate future storage. Forecasting the storage is impractical and infeasible.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-07-25T20:26:32.707Z
Answers: 2023-07-25T20:26:32.707Z
Answers: Preston Martin
Body: <p>How to estimate the space a git repository will take on a source version control server?
  For example, given k commits every day, with x kB of code per commit, my repository will take n GB of server storage after 1 month.</p>
  <p><strong>Context:</strong><br />
  I am trying to investigate increased storage usage on a server I use solely for hosting an instance of Gitlab. No CI/CD (yet), just source version control.
  I recently realized that one year of using the server compounded to about 80GB of storage, while our repositories barely come up to 1GB, as seen in the GitLab Project menu.<br />
  GitLab is installed via <a href="https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/docker/Dockerfile" rel="nofollow noreferrer">Docker</a>.</p>
  
Tags: <docker><gitlab><git><storage>
Title: Estimate storage space for a git server
UserDisplayName: user2315856
ThreadText: # Estimate storage space for a git server
  
  (Asked by: username_0 on 2023-06-02)
  
  How to estimate the space a git repository will take on a source version control server?
  For example, given k commits every day, with x kB of code per commit, my repository will take n GB of server storage after 1 month.
  
  **Context:**  
  I am trying to investigate increased storage usage on a server I use solely for hosting an instance of Gitlab. No CI/CD (yet), just source version control.
  I recently realized that one year of using the server compounded to about 80GB of storage, while our repositories barely come up to 1GB, as seen in the GitLab Project menu.  
  GitLab is installed via [Docker](https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/docker/Dockerfile).
  
  **Tags:** docker, gitlab, git, storage
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2023-06-04. Score: 1
  
  Assuming you are already familiar with [how to clean up GitLab](https://docs.gitlab.com/ee/user/project/repository/reducing_the_repo_size_using_git.html), the best way to track the disk use and predict growth is to monitor it. Based on the mounting data you can see the trend.
  
  The problem with calculating the growth in storage is that the git heuristics make it unpredictable. Git is optimizing storage as you commit, a bit like a real time compressed archive.
  
  By monitoring the storage, you can see the rate of growth and add an alarm for when it falls below a safe threshold.
  
  I use [DataDog](https://www.datadoghq.com/) for this. Other tools are available.
  
  
  ---
  
  ### Answer by username_2 on 2023-06-07. Score: 0
  
  As per the [documentation](https://docs.gitlab.com/ee/install/requirements.html):
  
  > GitLab package requires about 2.5 GB of storage space for installation
  
  and
  
  > The necessary hard drive space largely depends on the size of the
  > repositories you want to store in GitLab but as a guideline you should
  > have at least as much free space as all your repositories combined
  > take up.
  
  What you are describing seems to relate more to logs not being properly rotated or docker images not regularly purged.
  
  
  ---
  
  ### Answer by username_3 on 2023-07-25. Score: 0
  
  Number of commits is not a good heuristic for determining storage size on a server. Commits will vary by size, and 1 commit with a large blob can consume more than the 100s of commits before it. This further escalates if you don't have any measures in place to block commits with large files from being pushed to your instance.
  
  Commits aside, repos themselves will almost certainly not be the largest source of storage space on your instance. Metadata (MRs, comments, attachments, etc.) will likely consume far more even than even the most poorly managed of repositories.
  
  Ultimately, having proper monitoring and alerting on your instance for consumed storage, and being able to scale up rapidly is far more important than being able to forecast the approximate future storage. Forecasting the storage is impractical and infeasible.
  
  
  ---
  
  