KIERSTEI@UMKCVAX1.BITNET (07/21/87)
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.Bitnetgkn@SDS.SDSC.EDU (07/22/87)
From: <KIERSTEI%UMKCVAX1.BITNET@wiscvm.wisc.edu>
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.5076Thx-1138@KL.SRI.COM:WILLIAMS@EDWARDS-2060.ARPA (Williams@Edwards-2060) (07/23/87)
Just a little tidbit for the XQP cache hackers among us: When you increase the cache sizes, Autogen is wizzy enough to increase the LOCKIDTBL and RESHASHTBL (if they need it). However, it doesn't seem to increase SRPCOUNT based on the size of those two tables, which is what will get eaten by the greater number of lock blocks that will be consumed (since the XQP is "remembering" file activity for longer periods). The RSBs will eat both the SRPLIST and the IRPLIST, it seems. So, if you had your nonpaged pool closely trimmed, you'll probably have to go through another iteration to size it (or take lookaside list expansion taps). Now a question: In a sort of related area, I've noticed that SHOW PROCESS/CHANNELS in ANALYZE/SYSTEM on my 8650 doesn't give out the filenames--just the file ids. This is apparently due to the fact that all of our disks are hanging off an HSC-50 (a different node?), since our 11/785s with MASSBUS disks report the filenames just dandily. Is there something I can do to repair this sad state of affairs? Failing that, does anybody have any FID-to-Filename ditties they'd be willing to distribute? (SDA uses a Bliss routine called LIB$FID_TO_NAME out of some DEC-developer-only library, which doesn't seem to live on "normal" VMS systems.) Otherwise, I guess it's hi-ho, hi-ho, off to the ACP I go! Cheers, Marc (Williams@Edwards-2060.ARPA) -------