Sirs,
I am interested in understanding how tot tune the 2.6
kernel such that I can get the WM to write out data
that is held within the "cache".
My situtation is that I have a NFS file server that
gets data in bursts. The first couple of burst move
quickly, but once the system memory becomes filled,
mostly held in "cache", then my NFS performance drops.
The issue here is how to get the VM to write out the
data held within the cache when times are slow (which
amounts to 90% of the time)? I have played a little
bit with the /proc/sys/vm/dirty_ratio, etc with out
much help.
Any suggestions?
Thank you for your valuable time.
Phy Prabab
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25?
http://photos.yahoo.com/ph/print_splash
Phy Prabab <[email protected]> wrote:
>
> Sirs,
>
> I am interested in understanding how tot tune the 2.6
> kernel such that I can get the WM to write out data
> that is held within the "cache".
>
> My situtation is that I have a NFS file server that
> gets data in bursts. The first couple of burst move
> quickly, but once the system memory becomes filled,
> mostly held in "cache", then my NFS performance drops.
> The issue here is how to get the VM to write out the
> data held within the cache when times are slow (which
> amounts to 90% of the time)? I have played a little
> bit with the /proc/sys/vm/dirty_ratio, etc with out
> much help.
Setting dirty_background_ratio lower might smooth things out.
On Mon, 19 Apr 2004, Andrew Morton wrote:
> Phy Prabab <[email protected]> wrote:
> > quickly, but once the system memory becomes filled,
> > mostly held in "cache", then my NFS performance drops.
> Setting dirty_background_ratio lower might smooth things out.
Hmmm, I wonder if the "system gets slower" thing could be
measured somehow (IO request queue filling up?) and used
as a way to self-tune pdflush a bit ?
I'll take a look ...
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan