Luis Chardon <[EMAIL PROTECTED]> wrote:
>
> Yeah, that might be it. Is there a way to flush it besides "sync"?
>
> Here is the output:
>
> total used free shared buffers cached
> Mem: 687708 489396 198312 0 198588 139984
> -/+ buffers/cache: 150824 536884
> Swap: 401584 0 401584
>
> Call me paranoid but I don't like seing around 200M in buffers :)
Well, sync won't even help, really, because 'most' of that 'should be'
(awaiting truly knowledgable folks to step in here and quantify 'most'
and 'should be' ;-) just read buffers, not write buffers. (Sync, will,
of course, help greatly with that ratio of read-to-write buffer use ;-).
On a side note, I had a sparc once with like 256 meg of ram, and I was
doing network performance tests. I did an ftp to myself to see what
the networking overhead was. Wrote the numbers down, then for some
reason did it again. YOW! the numbers like tripled or more (I forget the
exact increase). Then I realized what I'd done - I'd just loaded the
cache with the data on the first run, then used THAT data the second
run. Which gave me a better idea of network and processing overhead
without disk delays, which was interesting...
Anyway, I would not be surprised to find that having all that buffer
space IMPROVES your ability to get (write) data to the disk quicker,
since your chances of having a cache hit go up with more stuff in
the cache, so your disk is more free to go write the pending writes.
(Tell ya what - I'll take some of that ram from you, then you won't have
so much buffer space ;-)
So (pending correction by someone who REALLY knows ;-), you're probably
better off with all that 'spare' memory. And I don't know if you can tell
the kernel (or whoever) to NOT use so much free space for buffers - anyone
know if I'm wrong?
just my $.02 - and you KNOW what you paid for it! ;-)
rc
Rusty Carruth Email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
Voice: (480) 345-3621 SnailMail: Schlumberger ATE
FAX: (480) 345-8793 7855 S. River Parkway, Suite 116
Ham: N7IKQ @ 146.82+,pl 162.2 Tempe, AZ 85284-1825