Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mimsy!oddjob!hao!ames!sdcsvax!ucbvax!SDS.SDSC.EDU!gkn From: gkn@SDS.SDSC.EDU Newsgroups: comp.os.vms Subject: RE: File cache hit rates (2nd try) Message-ID: <870722202753.003@M5.Sdsc.Edu> Date: Wed, 22-Jul-87 16:27:52 EDT Article-I.D.: M5.870722202753.003 Posted: Wed Jul 22 16:27:52 1987 Date-Received: Sat, 25-Jul-87 05:01:37 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 50 From:Subject: File cache hit rates (2nd try) Date: Tue, 21 Jul 87 14:15 CDT 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. I used AUTOGEN, but it did not see fit to increase the amount of paged pool that I had, so I told it to. My file system caches have started working. Swimming in pool, gkn -------------------------------------- Arpa: GKN@SDS.SDSC.EDU Bitnet: GKN@SDSC Span: SDSC::GKN (27.1) USPS: Gerard K. Newman San Diego Supercomputer Center P.O. Box 85608 San Diego, CA 92138 AT&T: 619.534.5076