We’re using Nexus 3.6.2. We have a Maven repository group that contains four separate Maven repos. Each of these Maven repos has its own blob store. The Maven group also has its own blob store, required for reasons that aren’t entirely clear (it was asked, but not definitively answered, here. A
Nexus reports the size of the Maven group’s blobstore as 1.7gb, which might make sense if it’s storing some metadata. Checking the disk usage on the physical box though and it’s 109gb (over x60 the difference). That’s very significant and I can’t understand why a blobstore for a repository group would be that large in any case. The only unusual thing I can see is that this blob store - which I thought would rarely be used - has over 100x more blobs than the blob store used by repos that are in active use (such as our -snapshots repo).
What’s going on here? Why the difference? I’d like to be able to claim back a good chunk of this 100gb.
Thanks!
Answering my own query… I noticed that the “Compact Blob Store” task had not been run on the Maven group’s blob store and, after running this, it shrank down from 100gb to 1.4gb…
It’s still unclear though as to why it would have grown to this size if it’s effectively just acting as a front for other blob stores and why there were so many “extra” files just sitting there, marked for deletion. What created these millions of files that seemed to serve no purpose?
Is it possible I’m hitting this issue? We’ve been running the rebuild repository metadata task against this (and all other repos) but, unlike the others, we weren’t compacting until now.
Is it possible I’m hitting this issue? We’ve been running the rebuild repository metadata task against this (and all other repos) but, unlike the others, we weren’t compacting until now.
It certainly sounds possible. Why are you running rebuild repository metadata? There is no reason to do this under normal operation. Metadata is maintained automatically.