Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!UMKCVAX1.BITNET!KIERSTEI From: KIERSTEI@UMKCVAX1.BITNET Newsgroups: comp.os.vms Subject: File cache hit rates (2nd try) Message-ID: <8707222332.AA10394@ucbvax.Berkeley.EDU> Date: Tue, 21-Jul-87 15:15:00 EDT Article-I.D.: ucbvax.8707222332.AA10394 Posted: Tue Jul 21 15:15:00 1987 Date-Received: Fri, 24-Jul-87 07:00:51 EDT Sender: daemon@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