Linux, gobs of RAM, RAID and performance suckage...

[Dave Johnson]

Paul Lussier writes:
> Yesterday we added 2GB of RAM and our memory utilization now looks like this:
> 
>  active     - 793M
>  inactive   - 2.3G
>  unused     - 213M
>  cache      - 2.9G
>  slab cache - 194M
>  swap cache -   2M
>  apps       -  71M
>  buffers    - 313M
>  swap       - 4.5M

When you are in this condition, how large is Dirty and Writeback in
/proc/meminfo?

If you have a large amount of Dirty (read: >300MB) and the underlying
filesystem is using ordered journaling (the default for ext3) you can
cause very long delays if a process requests a fsync on a file (vi
does this alot).  Instead of writing a single file to disk right away
the filesystem must write all other outstanding data to disk first!

If your clients are write heavy and you are using ext3 you should
consider data=writeback when mounting the filesystem.

I've run into this issue on a server with 64GB of RAM with dirty
commonly exceeding 4GB under load.  Poor users of vi had to keep
waiting for the server to write out 4GB of data every time they saved
a file. data=writeback helped tremendously as only the previous
metadata is forced to disk on a fsync() instead of everything.


> Correct.  The nfsd's on the server get pushed to the bottom of the
> queue (in top) and what I see is [kupdated] and tar (from the backups)
> rotating between the top position.  There was one or two other
> processes up there too, one of which I think was a kernel thread
> ([bdflush] ?).  As far a I know, the tar's were not making processes,
> but I can't be totally sure of that.  Nothing *else* was making
> progress, that's for sure.

kupdated?!?! A 2.4 kernel??!?!? 


-- 
Dave