0

My team is using JFrog Artifactory 2.6.7.1 Pro. We have plans to upgrade to 3.x but they are being slowed down for non-technical reasons.

In the mean time our 2.6.x install is using over 190GB of disk. Most of that is in repo/data/filestore.

I have already run the following maintenance options and freed up some disk:

  • zapped caches
  • deleted versions
  • run storage garbage collection (this was most effective, got back whole 2GB)
  • compressed the database
  • pruned unused data
  • run unused artifacts cache cleanup

I specifically reviewed the "snapshots to keep" setting for repos which could have snapshots. It was set to a reasonable value (less than 10) for those repos.

What settings should I review to free up some disk space?

Freiheit
  • 201
  • 1
  • 2
  • 15

2 Answers2

3

Some of the operations you mentioned (zapping caches, pruning unused data, etc.) are one-time operations, that might have some temporary effect, but I am not sure how useful they are on the normal operation basis. After all, the caches are there for a reason.

Others, like GC, are ran by default by Artifactory (e.g. GC is running every 4 hours).

All the storage managing details are listed in one Artifactory User Guide page.

Practically, there are 5 configuration options that can help you control the storage size on a routine basis:

  • Setup snapshot cleanup policy.
  • Delete Unused Cached Artifacts.
  • Delete old builds by using the Jenkins Artifactory Plugin.
  • Write a script that uses REST API cleanup calls.
  • Write a user plugin that implements any cleanup logic that is correct in your case. Here are some examples to get you started.
JBaruch
  • 166
  • 3
2
  1. you need to move backup of artifactory server from another server it will give you more space.
  2. USE AQL to manage cleanup issues.

First let’s find old artifacts, those that were created over a year ago (assuming today is May 18, 2015). This one’s easy with AQL: items.find({"type":"file", "created":{"$lt":"2014-05-18T"}})

Note how we can use comparison operators like “$lt” with dates, and that we’re taking advantage of the default built into AQL that multiple criteria are compounded using “$and”.

wants to delete something if it hasn’t been downloaded in the last 6 months:So let’s add another criterion to our query, this time using the “downloaded” field in the “stat” domain:

items.find({"type":"file", "created":{"$lt":"2014-05-18T"}, "stat.downloaded":{"$lt":"2014-11-18T"}})

if you wants to make sure nothing important is deleted, so he will skip “release” repositories. items.find({"type":"file", "created":{"$lt":"2014-05-18T"}, "stat.downloaded":{"$lt":"2014-11-18T"}, "repo":{"$nmatch":"*release*"}})

Here, we added a criterion that the repository name does not include the pattern “release”. Note that if you have any repository with “release” in its name – but it’s not a release repository… it will also be skipped, and you may want to rethink your naming convention.

“large” artifacts bigger than 1000 bytes.

So here is the final AQL query that finds all artifacts in the system that answer all of those criteria: items.find({"type":"file", "created":{"$lt":"2014-05-18T"}, "stat.downloaded":{"$lt":"2014-11-18T"}, "repo":{"$nmatch":"*release*"}, "size":{"$gt":"1000"}})

Community
  • 1
user3571701
  • 21
  • 2