[9273] in Athena Bugs
fs flushvol: it's getting worse...
daemon@ATHENA.MIT.EDU (probe@MIT.EDU)
Mon May 4 23:58:40 1992
From: probe@MIT.EDU
Date: Mon, 4 May 92 23:58:18 -0400
To: bug-afs@MIT.EDU, bugs@MIT.EDU
Cc: jis@MIT.EDU
I previously suspected a cache leak in terms of space... well, here are some
preliminary results:
The number of entries in afs_indexTable and the number of entries in
freeDSList should add up to the total number of disk cache files. At the
beginning, this is true, but over time, I have seen:
731 unaccounted / 831 cache files... Ouch...
We have a leak, alright, but this means that over time the cache becomes less
and less efficient... As I previously stated, if it were at most 5 files
that were not cleared, I could believe it, but the space discrepancies that
I was seeing were on the order of 500k loss after hitting the cache limit,
which is more than the 5*64k maximum I would have expected. (Two hits caused
me to lose 1MB, and the 5*64k should have been a maximum regardless of how
many times I hit it).
We have a leak, and one that will be seriously degrading performance over
time. Initially, the cache works well, but it slowly fails.
My source for this debugging is:
/mit/probe/src/afs/read_dcache.c
if anyone wants to look at it for errors; the problem is that it seems to
print out valid dcache addresses in all its output; if I were misreading
memory, I would expect to have at least one invalid address, but I don't
(and all of them are in the same region of memory, which is correct as one
allocation is done at startup).
For anyone wishing to try to use this program, it can be compiled on VAX and
RT systems. (I don't know if it will work with DECstations, but it certainly
won't work with RISC/6000s). No AFS libraries or include files are required
for compilation (in fact, just type "cc read_dcache.c" to get a binary).
-R
