On 5.4.2012 17:17, Cesar Martin wrote:
> Well, I have installed megacli on server and attach the results in file
> megacli.txt. Also we have "Dell Open Manage" install in server, that can
> generate a log of H800. I attach to mail with name lsi_0403.
>
> About dirty limits, I have default values:
> vm.dirty_background_ratio = 10
> vm.dirty_ratio = 20
>
> I have compared with other server and values are the same, except in
> centos 5.4 database production server that have vm.dirty_ratio = 40
Do the other machines have the same amount of RAM? The point is that the
values that work with less memory don't work that well with large
amounts of memory (and the amount of RAM did grow a lot recently).
For example a few years ago the average amount of RAM was ~8GB. In that
case the
vm.dirty_background_ratio = 10 => 800MB
vm.dirty_ratio = 20 => 1600MB
which is all peachy if you have a decent controller with a write cache.
But turn that to 64GB and suddenly
vm.dirty_background_ratio = 10 => 6.4GB
vm.dirty_ratio = 20 => 12.8GB
The problem is that there'll be a lot of data waiting (for 30 seconds by
default), and then suddenly it starts writing all of them to the
controller. Such systems behave just as your system - short strokes of
writes interleaved with 'no activity'.
Greg Smith wrote a nice howto about this - it's from 2007 but all the
recommendations are still valid:
http://www.westnet.com/~gsmith/content/linux-pdflush.htm
TL;DR:
- decrease the dirty_background_ratio/dirty_ratio (or use *_bytes)
- consider decreasing the dirty_expire_centiseconds
T.
