Contents
Vesta Tip: Running a Private Cache
There are times when it is convenient to run an instance of the Vesta cache server separate from the main one at a site. Here are a few reasons why you might want to do this:
To separate your traffic from that of other users. If you're testing significant changes to a build process, using a separate cache server allows you to easily distinguish by cache entries created by your builds from those created by others builds. You may want to use VCacheStats to collect statistics after performing a build on an empty cache. Doing this for several different builds is one way to compare the effect of changes to your build description code.
To test changes to the cache server tuning configuration variables. (See the configuration section of the VCache man page.)
- To test changes to the cache server itself.
Setup
Start by selecting a machine to run the private cache. In this example we'll use myworkstation.example.com.
You need a directory in which to store your private cache's data. The only restriction is that it should be local to the machine that you're going to run the cache on. (NFS write failures have caused cache problems in the past.) Also, the directory has to be writable by the user that runs the cache server. (Any user can run the cache server, even though the normal method is to run it as vadmin.) Let's suppose the directory to store the cache in is /tmp/my_cache.
Next you'll need to create a Vesta configuration file that overrides a few settings. A good place to put this is inside the directory where the cache will be stored (i.e. /tmp/my_cache/vesta.cfg). It should look like this:
// Start with the normal system-wide vesta.cfg [include /etc/vesta.cfg] // Add overrides in the CacheServer section [CacheServer] // The host that will run the private cache Host = myworkstation.example.com // The directory where the private cache will be stored MetaDataRoot = /tmp/my_cache
(Obviously you should fill in your own hostname and directory.)
After creating the Vesta configuration file, you need to tell the Vesta tools to use it instead of your normal configuration file (probably /etc/vesta.cfg or ~/vesta.cfg if you have a personal one). To do this, set the VESTACONFIG environment variable to point to your new configuration file. If you use csh or tcsh:
% setenv VESTACONFIG /tmp/my_cache/vesta.cfg
Or if you use a System-V style shell (bash, ksh, zsh):
% VESTACONFIG=/tmp/my_cache/vesta.cfg; export VESTACONFIG
Remember that you'll need to repeat this in every terminal where you want to run a command that uses the private cache. Also, don't forgot to unset the the VESTACONFIG environment variable when you're done working with the private cache.
It's a good idea to check that you're using the new config file with vgetconfig or WhichCache
% vgetconfig -L /tmp/my_cache/vesta.cfg % WhichCache Cache information: Hostname: myworkstation.example.com Port number 21773 Stable root: /tmp/my_cache/cache
Lastly, create the directory structure used by the cache server by running CreateCacheDirs:
% CreateCacheDirs Creating cache meta-data at /tmp/my_cache/cache Creating directory: /tmp/my_cache/cache Creating directory: /tmp/my_cache/cache/sCache Creating directory: /tmp/my_cache/cache/sVars Creating directory: /tmp/my_cache/cache/weededLog Creating directory: /tmp/my_cache/cache/cacheLog Creating directory: /tmp/my_cache/cache/emptyPKLog Creating directory: /tmp/my_cache/cache/ciLog Creating directory: /tmp/my_cache/cache/graphLog Creating directory: /tmp/my_cache/cache/weeder Done.
Starting the Cache
To start the cache server, just run VCache. Most people will probably prefer to redirect its output to a file and place it in the background:
% VCache > /tmp/my_cache/cache-messages & [1]
Check whether it's running correctly with VCacheMonitor:
% VCacheMonitor
Hostname: myworkstation.example.com
Port number: 21773
Stable cache: /tmp/my_cache/cache/sCache
Cache version: 1.31, 3-Sep-1998
Intf version: 22
Up since: Fri Feb 28 12:07:55 2003
Current time: Fri Feb 28 12:07:56 2003
Instance FP: 3b79af22bed1d00e f11ad1c7d972142f
FREE LOOK ADD NUM NUM NUM NEW OLD NUM NUM MPK
SIZE RES VARS UP ENT VMPK VPKS ENTS ENTS PKLS ENTS PKLS HF DEL WEED
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
2.4M 1.9M N/A N/A N/A 0 0 0 0 0 0 0 0 0 0
2.4M 1.9M 0 0 0 0 0 0 0 0 0 0 0 0 0
(You may want to leave VCacheMonitor running in a terminal window while you use your private cache server.)
Using the Cache
For the most part, you can just perform builds as usual. (But don't forget to set the VESTACONFIG environment variable if you use multiple terminals.)
When you want to stop the cache server, you can just use control-C or the kill command.
Other commands that are useful with a private cache:
FlushCache: Force the cache server to write to disk all recently created entries it is holding in memory. (You can see how many there are by looking at the "NEW ENTS" column in VCacheMonitor.)
VCacheStats: Collect statistics about what's in the cache. (This only reads on-disk entires, so you probably want to use FlushCache first.)
EraseCache: If you want to start over with an empty cache, you can use this utility. You need to stop the cache server first and restart it after you erase the cache.
Warning: Effect of Weeding
Whenever the weeder is run, your private cache will be invalidated and you should erase it (by stopping it if it's running and using EraseCache).
In more detail, the weeding process only talks to one cache server. While the entries in your private cache server will continue to exist, any derived files referenced by entries it stores (i.e. result files written by tools) will be deleted by the weeder.