Clean up cache directory

We have some unexpected behaviour going on in our cache directory that I'd
like to clean up. Some background first:

Squid 2.2stable4, Solaris 2.6, on Sun Enterprise 250, 1x400MHz CPU, 1Gb
RAM, 4x9Gb disks striped with Volume Manager for the cache directory.

cache_dir 30000 64 256

Currently the cache is about half full and cache manager is reporting a
mean object size of 21KB.

Squid was restarted a few times in it's first few months of operation, each
time the cache files started back at number 00000000. We noticed that
there were a few entries like:

storeSwapInFileOpened: /cachedir/1E/C7/001EC789: Size mismatch: 217(fstat)
!= 343(object)

in cache.log when it was reusing cache files. It didn't seem to cause a
problem for our clients, so we wern't too worried. About a week ago, I
realised we were close to "wrapping" directories, Squid has been running
for 4 weeks and was almost through our 64 top level directories and I was
ready for an increase in the cache.log as above. To my surprise, Squid
started back at top level directory "00", but didn't start back at
00000000, it just kept incrementing to 00400000 and continued on from
there.

When we originally compiled Squid, we didn't change from truncate to
unlink, we'd carefully planned for inode usage based on 256 files in the
second level directories. Unfortunately since the old files are truncated,
not unlinked and Squid isn't reusing them, we've got a lot of zero length
files scattered through our cache directory tree.

How can we go about cleaning them up? I'm not keen to do "find /cachedir
-size 0c -exec rm {}\;", and I'm not keen on stop/starting squid on a
regular basis to go back to 00000000 and have it produce Size mismatch
entries as above. I realise a recompile to use unlink instead of truncate
may be the best option, but are there any other options? What happens when
the cache file number eventually gets to FFFFFFFF?

thanks for your help,

Robert Rose
Unix Systems Administrator

PS. If anyone is interested in performance of Squid on this hardware, we're
seeing 30 client HTTP requests / sec and Squid is using about 20 percent of
the CPU. Client request median service time is around 0.05sec, a miss is
around 0.06sec and a hit is 0.01sec. We're currently seeing around 18%
HTTP hits and 42% ICP hits from the 20 child proxies and hundreds of client
browsers. Email me if you want any more statistics.
Received on Thu Oct 14 1999 - 18:55:31 MDT