Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!bloom-beacon!think!ames!ucbcad!ucbvax!UMKCVAX1.BITNET!KIERSTEI From: KIERSTEI@UMKCVAX1.BITNET Newsgroups: comp.os.vms Subject: File cache hit rates Message-ID: <8707181838.AA13992@ucbvax.Berkeley.EDU> Date: Thu, 16-Jul-87 12:38:00 EDT Article-I.D.: ucbvax.8707181838.AA13992 Posted: Thu Jul 16 12:38:00 1987 Date-Received: Sun, 19-Jul-87 01:15:25 EDT Sender: parhi@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 32 I've been watching my file system caches lately, and have noticed that the hit rate on all of them was quite low. So, I increased the sizes of the caches and things worked well for the directory index (ACP_DINDXCACHE), file extent (ACP_EXTCACHE), file ID (ACP_FIDCACHE), file header (ACP_HDRCACHE), and bitmap (ACP_MAPCACHE) caches. The hit rates on the directory FCB (ACP_SYSACC), and the directory data (ACP_DIRCACHE) caches were still low, so I increased the sizes on those again. When I did this, the hit rate went *down*; I mean _through the floor_. So, I've shrunken the caches back a bit, and I'm back to where I was before. Am I misunderstanding something here? In general, the larger a cache is the better the chances that you'll find something in it. This doesn't seem to be the case with at least some of the XQP caches. I had the same problem when I raised the header cache. At the time, I remembered a note on Info-vax that mentioned something about some cache they were working with was actually set to a lower default value after they raised it due to not enough pool space to accomodate the increase. I then did the parameter change in autogen, which promptly raised my paged pool. The parameter change then increased the hit rate, rather than lowering it. One note: If your paged pool increases in size, increase sysmwcnt to keep the system paging at the previous level. If anyone has a more detailed explanation, let us know. Barry Kierstein Kierstei@Umkcvax1.Bitnet