In <1992Jan10.212602.1549wolfgang@netcom.COM> wolfgang@netcom.COM (Wolfgang Henke) writes:
>Lets look at a couple systems:
>4/65 (SS2)
>nbuf<19> headers<39> cachesize<19> reads<15115544> hits<13956679> hit ratio<92>
>cache allocation: AGE<763721> LRU<1329090> SLEEP<670> Total:<2093500>
>
>4/280
>nbuf<41> headers<41> cachesize<41> reads<1921279> hits<1872038> hit ratio<97>
>cache allocation: AGE<37137> LRU<19618> SLEEP<3> Total:<56799>
>3/60
>nbuf<51> headers<51> cachesize<51> reads<9896> hits<9739> hit ratio<89>
>cache allocation: AGE<85> LRU<23> SLEEP<0> Total:<159>
>If you just look at cachsize, the 3/60 seems to have the largest?
Nah, I believe we're taking two DIFFERENT concepts of "cache" here.
>From looking at my systems, this is obviously the "meta-data" cache.
That is, it isn't "file" data, but inode data. There is a fixed-size
cache of this stuff in SunOS. You can increase the size of the buffer
by caching the kernel, which gives you a win for file serving on a
busy server, etc. This is more or less documented in a paper Sun
presented at a Sun USER Group meeting a while back. If anyone
needs it I can probably dig out the reference. Anyway, it isn't
the dynamically allocated file buffer cache that we're looking at
here.
My 4/65 reports 31 nbufs, but I increased it on this machine.
-- Steve Hanson - FERMILAB, Batavia, Il. (708)840-8043 hanson@calvin.fnal.gov or hanson@fnal.fnal.gov
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:34 CDT