Is it safe for removing SHA1 folder contents from C:\Program Files (x86)\BigFix Enterprise\BES Server\wwwrootbes\bfmirror\downloads\sha1 folder?
You can, but they’ll clean up on their own if there is no associated Fixlet/Task.
1 Like
@AlexaVonTess It’s not getting clear automatically, as i have seen there are lots of old files (since 2013 and 2014) are there under SHA1 folder…
So was just assuming if i will delete these, then the task will not going to complete as this will give some error or not able to store cache to server… kindly suggest.
My understanding is that they are deleted, eventually, when there is NO fixlet associated with the SHA.
If there still is a fixlet, which certainly will be the case if you’re speaking fixlets from IBM External sites, then you can delete them. They’ll just download again if the fixlet is ever taken action on.
This is why you often set your BES Cache high (250GB for example), your Top Level Relays medium (200GB) and your child relays low (25GB). Then you don’t have to worry about it…
Currently i have 1 TB HDD in which this particular (SHA1) folder is taking around 600GB.
And i did not see such settings in BES Root server in below path…
“HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\BigFix\Enterprise Server\GatherService”. I believe i am looking into a right path?.
Could you also assist, how can i set this cache for BES Root server to overcome such issue in future. Thanks in advance
See task id 148 in the Bes Support site.
Your implementation seems to have had the configuration changed already - the default cache is really small (1GB).
1 Like
Thanks @trevor, i have just manually added the default value i.e. 358.4 GB on BES Root Server in below path.
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\BigFix\EnterpriseClient\Settings\Client\_BESGather_Download_CacheLimitMB ;Value-REG_SZ=358400My understanding is the sha1 content is cleaned on a daily basis. When the size of the sha1 folder exceeds _BESGather_Download_CacheLimitMB the server removes the least-recently-used files until you get below the limit again. The cleanup does not check whether the file is still referenced in a fixlet, just the files’ last times used.
Normally the server will just re-download the file if you manually delete it and it’s needed again, but if you manually precache files (as in the JRE upgrades on Windows) you would need to take care of those again.
2 Likes
Please see the following article as reference: http://www-01.ibm.com/support/docview.wss?uid=swg21505905
Jason’s description is quite accurate, however, the download cache is not cleaned on a scheduled basis, but rather on-demand (i.e. as a new download request is made, the Root Server will make room by removing the least recently used files until the cache is below the configured limit).
2 Likes
Thanks @Aram and @JasonWalker for additional information.
@Varun I’d also like to plug the cache management tool out of BigFix labs:
I don’t really want to show you my relays, but it allows for total cache management/visibility. So far it has been pretty helpful!
Best,
Josh
1 Like
dang, that’s useful. for some reason, only one of my several relays are showing up in there though. not able to determine why based on the relevance :(. they show up in other analysis built for relays.
Be careful with Bigfix Labs. If I recall correctly, the Analysis involved in retrieving the cache size/content is set to evaluate on Every Report. As my cache size is 1.5 TB, the BES Server was spending a lot of time retrieving cache info.
1 Like
Oh, you’re right-- that’s incredible. In any case, you might be able to use it periodically and not leave it on.