0

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.

3 Answers 3

0

Assuming you are already familiar with how to clean up GitLab, 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 for this. Other tools are available.

0

As per the documentation:

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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.