The overall behavior of this statistic was improved for release 6.0, so that it does normally increase 1:1 when load disappears, never faster than that.
However the dump-related behavior is still a problem. This is a known problem of substantial age ... it was first filed against release 1.1. It's on my list, but I probably won't get to it for a while yet.
Chris Thompson wrote:
bbadyk@cncx.com writes:
Hello everyone, I have been trying to extract the cache age from a couple different filers and can't seem to locate an SNMP OID that will contain that info..The only other option i can think of is extracting it from an rsh sysstat..Has anyone retrieved that using snmp?
It would appear that the netapp.mib that comes with DOT 6.0 (version 1.2) has such an OID (1.3.6.1.4.1.789.1.2.2.23):
| miscCacheAge OBJECT-TYPE | SYNTAX INTEGER | ACCESS read-only | STATUS mandatory | DESCRIPTION | "Age in minutes of the oldest read-only blocks | in the buffer cache. This indicates how fast | read operations are cycling through system | memory; when the appliance is reading very | large files (larger than the machine's memory | size), buffer cache age will be very low."
I've got a query about the way the "Cache Age" in sysstat output behaves. Many releases ago it mostly looked like a genuine age of the oldest object in a cache with a LRU replacement strategy: heavy activity would push the age down, and if the load disappeared it would increase by 1 minute per minute until it became ">60".
Nowadays (in 5.3.x, say) the behaviour is often more complex, with large leaps upwards as well as downwards. In particular, there's an effect that occurs during dumps. During the dump, the age will be pushed down, as one would expect, ending up at, say, 38 mins (to take an example from one I have just run). If there's no significant load after the dump finishes, the age does *not* increase, but sticks at 38 mins for a long time, until it suddenly jumps to >60, e.g.
CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 17% 79 0 0 200 301 7366 315 0 7214 42 27% 78 0 0 185 174 4675 1986 0 2942 38 11% 46 0 0 59 118 742 852 0 567 38 6% 109 0 0 227 583 273 334 0 0 38 4% 48 0 0 79 117 110 186 0 0 38 [... long section omitted ...] 3% 25 0 0 36 21 32 159 0 0 38 3% 26 0 0 20 26 46 97 0 0 38 6% 137 0 0 185 730 548 92 0 0 >60 7% 127 0 0 454 153 152 839 0 0 >60
What is one to interpret the number as meaning to make sense of this?
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.